5 ms·

The biggest rules about securing things is don't be in security. Just do your diligence to put your hosts several layers away from public access and make all im

The biggest rules about securing things is don't be in security. Just do your diligence to put your hosts several layers away from public access and make all images and containers hardened with no elevated permissions. Sure vulnerabilities will still exist... if the only thing that can access the container is through a narrowed proxy you are not going get some dumb levels of attacks on your systems. AWS allows you to ssh into your hosts from within AWS. You just manage that security. NO ONE needs public ssh access, no one needs vpn ssh access just AWS ssh access. DON'T OVER COMPLICATE THINGS! I agree with you. I am not gonna say don't follow a system engineers advice. I say follow everyone's advice but pick out the things that seem most reasonable. If it is extra work then you're doing it wrong, simplify everything so that the time spent on resolving issues is faster. Faster resolution means faster security fixes.

gettodachoppa 3y ago
I'm also a "non-sysadmin" like the OP. I'm much more casual than you are: 1. Install LTS server with a sudo admin user and complex password (yes, password, not key. I still end up using keys for backup automation because it's easier.) 2. apt install fail2ban. Don't even need to configure it: its default configuration will auto-ban any IPs trying to brute-force SSH. 3. apt install unattended-upgrades (nowadays installed by default) I'd like to see anyone hack that. You mention running containers with no elevated permissions. I've taken a liking to Docker because, in addition to its many benefits, it lets me separate MY processes from those of the OS. It's just so simple when I can identify the server's running services with "docker ps". I'm curious, when was the last time a Docker exploit could escape the container and modify the host? I read it happened in the early days of Docker but is that still a risk? They would need to: a) exploit a bug in a service you're relying on (eg nginx), b) use the former bug to exploit a bug in Docker, c) defeat the Linux kernel's namespace/cgroup isolation. Is that a realistic threat in 2023?
- Sparkyte 3y ago
  Always a threat if the a host container is on the same HV. You get all sorts of bleed bugs identified every other year. Literally the last one was a few months ago I think. None as large scale as when it first happened.
fmitga 3y ago
When you say "no one needs vpn ssh access" vs "AWS ssh access", what is the difference between the two ?
- mrkstu 3y ago
  As mentioned you then just need to lock down AWS, rather than AWS AND outside access to servers via VPN. Lessen the attack surface.
- Sparkyte 3y ago
  The console in AWS allows access within its system. There is no point increasing the access area to the hosts. More surface area the easier it is to be penetrated by ssh vulnerabilities. You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. What you want to do is avoid fault, improve tolerance, but extend liability to the provider.
  - AdieuToLogic 3y ago
    > AWS allows you to ssh into your hosts from within AWS. This is where your argument breaks down IMHO. Unless you are saying "don't expose port 22 to the world...", which is a common (small) part of security-in-depth. > You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. This appears to be an instance of the "appeal to authority"[0] fallacy and is of little solace should server(s) one is responsible for become compromised. 0 - https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority
    - Sparkyte 3y ago
      You still have to do your diligence. You established what is supposed be a secure system yet that system failed due to provider security. AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? You are breaking convention, reinventing the wheel and complicating an already simple system. This isn't fallacy it is reducing a businesses cognitive load.

gettodachoppa 3y ago

I'm also a "non-sysadmin" like the OP. I'm much more casual than you are: 1. Install LTS server with a sudo admin user and complex password (yes, password, not key. I still end up using keys for backup automation because it's easier.) 2. apt install fail2ban. Don't even need to configure it: its default configuration will auto-ban any IPs trying to brute-force SSH. 3. apt install unattended-upgrades (nowadays installed by default) I'd like to see anyone hack that. You mention running containers with no elevated permissions. I've taken a liking to Docker because, in addition to its many benefits, it lets me separate MY processes from those of the OS. It's just so simple when I can identify the server's running services with "docker ps". I'm curious, when was the last time a Docker exploit could escape the container and modify the host? I read it happened in the early days of Docker but is that still a risk? They would need to: a) exploit a bug in a service you're relying on (eg nginx), b) use the former bug to exploit a bug in Docker, c) defeat the Linux kernel's namespace/cgroup isolation. Is that a realistic threat in 2023?

Sparkyte 3y ago
Always a threat if the a host container is on the same HV. You get all sorts of bleed bugs identified every other year. Literally the last one was a few months ago I think. None as large scale as when it first happened.

fmitga 3y ago

When you say "no one needs vpn ssh access" vs "AWS ssh access", what is the difference between the two ?

mrkstu 3y ago
As mentioned you then just need to lock down AWS, rather than AWS AND outside access to servers via VPN. Lessen the attack surface.
Sparkyte 3y ago
The console in AWS allows access within its system. There is no point increasing the access area to the hosts. More surface area the easier it is to be penetrated by ssh vulnerabilities. You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. What you want to do is avoid fault, improve tolerance, but extend liability to the provider.
- AdieuToLogic 3y ago
  > AWS allows you to ssh into your hosts from within AWS. This is where your argument breaks down IMHO. Unless you are saying "don't expose port 22 to the world...", which is a common (small) part of security-in-depth. > You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation. This appears to be an instance of the "appeal to authority"[0] fallacy and is of little solace should server(s) one is responsible for become compromised. 0 - https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority
  - Sparkyte 3y ago
    You still have to do your diligence. You established what is supposed be a secure system yet that system failed due to provider security. AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? You are breaking convention, reinventing the wheel and complicating an already simple system. This isn't fallacy it is reducing a businesses cognitive load.