4 ms·
a) Move SSH off port 22. (Really limited security gain when implementing the rest of the suggestions, but saves spam in your logs.) b) Software firewall via
by patio11 13y ago
a) Move SSH off port 22. (Really limited security gain when implementing the rest of the suggestions, but saves spam in your logs.)
b) Software firewall via e.g. IPtables is generally the first thing I turn on after rebooting SSHd with the new settings.
c) (Optional) Consider using an architecture where you have N boxes and SSH only listens on a local interface on N-1 boxes, with the Nth box running nothing but your VPN. (This is also a good architecture choice for admin consoles, folks. www.example.com resolves to a public IP, admin.example.com resolves to a private IP, so even if they're technically speaking on the same box/boxes you won't lose the admin console if someone unwisely uses the same password for a WordPress blog somewhere.)
- dsl 13y agoMy honeypots have been seeing scans on 2022, 2222, 3022, etc. for years now. You should be setting proper ACLs for 22 and not moving to another port.
- RKearney 13y agoHostGator uses port 2222 for all their shared hosting. I never understood this, given how easy it would be to modify an attack to use the new port.
- voltagex_ 13y agoACLs as in allow/deny? What if I'm using a dynamic IP on my client? In that case, should I just be using a "trusted" SSH gateway?
- bigiain 13y agoConsider fail2ban. It can be configured to automatically add (and later remove) ip addresses to iptables based on login failures (found by running regexes on logfiles). I've got rules blocking ip addresses with multiple failed ssh or wordpress login attempts for an hour to be very effective. I've still got a bit of "brute force poop" in the logfiles, but much less than before. I've seen a suggestion for adding an additional fail2ban "recursive rule" - dropping any ip address with repeated fail2ban lockouts for much longer times - if you trigger multiple 1 hour lockouts for ssh auth failures, you might get dropped for a week or more. I haven't felt the need to implement that one yet.
- Domenic_S 13y agoThe name for c), assuming you harden the box a bit is a bastion host http://en.wikipedia.org/wiki/Bastion_host http://en.wikipedia.org/wiki/Bastion_host
- lmm 13y agoI've never understood the logic behind these software firewalls. If you have one enabled it's inspecting all incoming packets, exposing a large surface of what's often quite complicated C code. Any service that has bound to a public-facing port on a machine I run has done so because I wanted it to; if I had a firewall I'd need to add an exception for it. Any service that's only meant to be accessed from the same machine has bound on loopback. Services that are accessed from another "internal" machine are properly authenticated, which means the network doesn't have to be trusted; spoofing packets won't help an attacker at all. Frankly if your defences rely on the idea that all packets from ip xxx.xxx.xxx.xxx are "safe" you're going to get burned. Where's the value in a software firewall supposed to be?
- cdjk 13y agoWhat if you want to do something between "everyone can access it" and "only local host can access it?". For example, I have to run a recursive DNS resolver on a port other than 53 because my ISP intercepts DNS traffic. I've limited access to only my ISPs IPs at the software firewall, so as not to unwittingly take part in a DNS amplification attack. Or what if I want to run a mail relay but only allow machines I control to access it. Or block a user who's doing something nefarious? Sure, most services allow you to control access by ip, but I'd much rather manage it all in one place. And the ports show up as closed if you block at the firewall.
- lmm 13y ago>What if you want to do something between "everyone can access it" and "only local host can access it?". For example, I have to run a recursive DNS resolver on a port other than 53 because my ISP intercepts DNS traffic. I've limited access to only my ISPs IPs at the software firewall, so as not to unwittingly take part in a DNS amplification attack. Hmm. In that specific instance it makes sense, because spoofing the IP is the whole point of the attack. I'd argue that's basically unique to DNS though, in which case the advantage of managing it in the same place as your other services goes away. >Or what if I want to run a mail relay but only allow machines I control to access it. Then you use a real authentication mechanism (i.e. SMTP AUTH). Otherwise it would seem perfectly possible for a spammer to spoof one of your IPs and use your relay.