3 ms·

With respect to port blocking / iptables / firewalls, what do you need to do other than shut off all ports other than the one(s) you're serving on? And for upd

by d23 4y ago

With respect to port blocking / iptables / firewalls, what do you need to do other than shut off all ports other than the one(s) you're serving on? And for updates, I don't know that any other provider does this any differently. You'll have to do some work, but that's what I'd prefer anyway; the last thing I'd want is AWS automatically upgrading the OS of live production systems without me testing it first.

conductr 4y ago
It's a good question and the answer is I don't know what I don't know when it comes to this stuff. Perhaps I've been overthinking it, but I feel like there's some gapping hole I'm leaving exposed. If that's all there is to it then I feel better already about a DIY approach. But for instance, SSH port has to remain open just so I can get in. I read occasionally about OpenSSH, or some foundational level service, being exploited. Is it common to just have to follow the security issues of every service and rush to patch accordingly, or is there something that helps automate this part? I do agree that there are some core services that I don't want changing out from under me without my notice/prior testing. But then there's also a lot of stuff installed that I don't use directly (eg OpenSSH) in my application and I'm not sure if those are attack vectors.
- stevenhuang 4y ago
  The gist is, yes, that really is all there is to it. Setup unattended upgrades for your distro of choice, setup fail2ban, only make internet accessible the ports you need, upgrade out of date software (i.e., don't fall behind LTS). Make sure your software behaves with good security practices (don't trust user input, etc). Any modern guide these days should just about cover it. For more complex deployments you'll enter the world of reverse proxies, custom VLANs, automation abstraction, intrusion detection systems (i.e., applications that proactively monitor access logs for suspicious activity), logging systems, alerting systems... But for simple app deployments, getting a reasonably secure system setup is actually not that hard. Maintaining it and keeping it secure is another matter (keep private keys secret, don't use simple passwords for SSH, etc), dealing with large upgrades, don't deploy debug to prod...
beambot 4y ago
> what do you need to do other than shut off all ports other than the one(s) you're serving on? A bit cheeky, but to highlight the point: you just locked yourself out of SSH.
- barrucadu 4y ago
  Why would you block the port you're serving SSH on?

by d23 4y ago

conductr 4y ago

It's a good question and the answer is I don't know what I don't know when it comes to this stuff. Perhaps I've been overthinking it, but I feel like there's some gapping hole I'm leaving exposed. If that's all there is to it then I feel better already about a DIY approach. But for instance, SSH port has to remain open just so I can get in. I read occasionally about OpenSSH, or some foundational level service, being exploited. Is it common to just have to follow the security issues of every service and rush to patch accordingly, or is there something that helps automate this part? I do agree that there are some core services that I don't want changing out from under me without my notice/prior testing. But then there's also a lot of stuff installed that I don't use directly (eg OpenSSH) in my application and I'm not sure if those are attack vectors.

stevenhuang 4y ago
The gist is, yes, that really is all there is to it. Setup unattended upgrades for your distro of choice, setup fail2ban, only make internet accessible the ports you need, upgrade out of date software (i.e., don't fall behind LTS). Make sure your software behaves with good security practices (don't trust user input, etc). Any modern guide these days should just about cover it. For more complex deployments you'll enter the world of reverse proxies, custom VLANs, automation abstraction, intrusion detection systems (i.e., applications that proactively monitor access logs for suspicious activity), logging systems, alerting systems... But for simple app deployments, getting a reasonably secure system setup is actually not that hard. Maintaining it and keeping it secure is another matter (keep private keys secret, don't use simple passwords for SSH, etc), dealing with large upgrades, don't deploy debug to prod...

beambot 4y ago

> what do you need to do other than shut off all ports other than the one(s) you're serving on? A bit cheeky, but to highlight the point: you just locked yourself out of SSH.

barrucadu 4y ago
Why would you block the port you're serving SSH on?