4 ms·
For the time being, would be also a good idea to move the ssh port to something other than 22 to avoid getting carpet-bombed by automated exploiting scripts.
by dryicerx 17y ago
For the time being, would be also a good idea to move the ssh port to something other than 22 to avoid getting carpet-bombed by automated exploiting scripts.
- mariorz 17y agoProbably better to use a port knocker. I recommend fwknop.
- deutronium 17y agoOr possibly set up port knocking, may be overkill though
- tlrobinson 17y agoIs port knocking a common defense these days? I remember reading about it awhile ago, and thought it was a neat idea but didn't really think people would actually use it.
- brk 17y agoI use it. It's really handy, but somewhat cumbersome if you just want to jump on an SSH shell to a box from a new machine. I compromised on some of my boxes and made a non-published/non-linked URL that if you hit it, your source IP will end up on the SSH-allowed list. That plus a non-standard SSH port seems to keep 99.9999% of the risk out of the way without being too overly cumbersome to knock-through when needed.
- deutronium 17y agoI don't think it is that popular too be honest, while it is good at preventing access from port scanners etc., the clients aren't standard utilities. [EDIT] You could always just set up iptables to accept traffic from your ISPs subnet and deny the rest.
- Gibbon 17y agoI use a simplified one port "port knocker" with iptables setup such that an ascending or descending linear port-scan will leave the ssh port closed upon completion. Only one knock is needed to keep the port open for my current IP address indefinitely, or it can be closed immediately without losing my ssh connection. It also precludes the necessity of filling up iptables with boatloads of DROPs to keep out the riff-raff.
- deleted 17y ago[deleted]
- lamnk 17y agoIMO port knocking isn't good defense, people can always use nmap to scan for open ports then try some combinations on them. Certificate authentication is way better (in combination with disabling password login)
- mariorz 17y agoCertificate authorization alone may not protect you from 0-day exploits to your ssh server. Not all port knockers use that pinging ports combination technique. Again, I recommend a look at fwknop which addresses your concerns by using certificates actually.
- ars 17y agoPort knocking doesn't use open ports. It acts as a packet sniffer, and doesn't do anything to the port.
- lanaer 17y agoThat is always a good idea, anyway. Been a long while since I’ve used the standard ssh port on servers under my control.
- buugs 17y agoI don't understand why people don't do this it is so much harder if not impossible for people to break into your server by normal means especially when you add MaxAuthTries 3
- jrockway 17y agoI am pretty sure that 0-day remote exploits don't respect MaxAuthTries.
- lanaer 17y agoSo long as the exploit doesn’t require multiple login attempts at all (which I assume it wouldn’t) yeah. MaxAuthTries protects against other things.
- sho 17y agoMaxAuthTries only logs errors, right? That by itself is not enough. You'd want fail2ban or bansshee or something, which tail those log files and blackhole any IP that causes an auth/username failure too many times in a certain period. However, that wouldn't work in this case anyway because if there's a working exploit in sshd then an auth/username failure would never even be logged. It'd be straight in first try.
- weaksauce 17y agoThe default setting is 6. You are not throttling the attack too much by setting this to 3. I would set it to 0 so if you make one bad attempt you are out. This still does not solve the problem but it is a smallish roadblock. I would also set MaxStartups to 1 if you are the only person to login. This limits the number of unauthenticated people trying to concurrently log in.