Ainsofs Blog: Technology insights from the Pacific Islands

  SSH ports Self hosted Gitlab normally uses port 22 for SSH access. When running docker this is not ideal as its usually used by the server. Its best to map it to another port. The Gitlab docs provides an example of using port 2224. Gitlab Web UI booted up great! But I could not clone or push to the repos using port 2224. First this port is blocked by my organisations firewall. Using online tools I checked if it was accessible outside of our network. Nada! We proxy our traffic using Cloudflare. To get it working, I used one of the allowed non-caching ports. This allows me to have my Web UI proxied but still have access to SSH for git cloning. There are other options available . Server specs I used a cloud server and initially set the specs too low. Ensure to check the minimum server requirements before selecting your specs. Boot time Although docker compose reports that the container is running as soon as you issue the docker compose up -d command, it takes a while f...

These are my key takeaways from the DrupalSouth '22 talk - "The Pragmatic Guide to Defending Drupal". It covered ways to defend Drupal from cyber attacks but can also be used in other stacks. They are categorised into the following environments:  local dev - your day to day development environment pull request/ deployment - the process of pushing your code to your repo hosting/prod environment - your production environment Key takeaways Have an incident response plan (local dev environment) Can be as simple as using your README.md file with the following headings If you look after multiple sites, use a central document or handbook for the organisation to refer to It tells owners what to do in case of an incident Use a CDN (hosting/prod environment) Cloudflare, Fastly and Akamai were mentioned (I work with Cloudflare, it has many defense mechanisms) Amazon Cloudfront - recommended if you are already hosting with AWS CDNs provide a way to mitigate the attack at the proxy...