12 ms·
Two other suggestions would be: 1. Test how your VPS comes back after a reboot. When you make big changes and at least every 6 months due to all the upgrading
by sounds 14y ago
Two other suggestions would be:
1. Test how your VPS comes back after a reboot. When you make big changes and at least every 6 months due to all the upgrading that ubuntu does by default it can break the bootup process and you won't know until that emergency unscheduled reboot at 3AM.
2. As long as you're customizing the firewall you should block pings entirely.
* Really, since the distributions are very compatible I would urge you to consider a distro that has selinux enabled by default. Fedora Core is a great place to start. It also has better tools to manage security and gives you good resume skills.
- darklajid 14y agoWhy would you block icmp ping? I never understood that practice, especially not for standalone machines (in contrast to company networks, on the router). So, why really?
- __alexs 14y agoI commonly see advice to block all ICMP traffic which is even crazier. I think perhaps the general suspicion of ICMP might be related to things like this http://en.wikipedia.org/wiki/Ping_of_death http://en.wikipedia.org/wiki/Ping_of_death which are now mostly irrelevant. Some sort of naive attempt to stop attackers mapping your network too perhaps? It's not exactly a high tech (or effective) means of intrusion detection though.
- deleted 14y ago[deleted]
- thorduri 14y ago>> 2. As long as you're customizing the firewall you should block pings entirely. Why? I've never seen a threat model where filtering icmp doesn't end up being more trouble then it's worth. Then there is even the maintenance headache when basic but powerful tools like ping and traceroute are rendered useless. It's the same BS as with fail2ban, thankfully the OP wasn't spreading the gonorrhea of port knocking/single packet auth. Lock down your sshd like everything else: Disable root, disable tunneled cleartext passwords, enforce proper key usage, use AllowGroups/AllowUsers. EDIT: The BS with fail2ban is moving the ssh port around. I understand this being a problem, but surely iptables has something similar to OpenBSD pf's: block in quick from <brutes> pass in log on $if_ext proto tcp from any to ($if_ext:0) port ssh keep state \ (max-src-conn 3, max-src-conn-rate 4/32, overload <brutes> flush global)
- lesaker 14y agoMind explaining your issue with single packet auth? Port knocking by definition is an extra layer of security through obscurity, in that gaining access requiring hitting the sequence of ports to "knock". Depending on the implementation, this either is very vulnerable to MITM/sniffing attacks (static knock sequence) or quickly gets really complicated (fully dynamic knock sequence). SPA, by contrast, uses actual crypto to securely authenticate the user with the server. I'm a fan of fwknop, which uses GPG to sign a request packet which is read and understood by the server. It protects against 0 day attacks on OpenSSH, lets me drop 22 inbound to eliminate all those pesky attackers, and allows me to securely authenticate with the fwknopd.
- thorduri 14y agoSure. > "Port knocking by definition is an extra layer of security through obscurity" Security through obscurity is not security, it's at best theater. > "It protects against 0 day attacks on OpenSSH" You substitute one problem for another, 0 day attacks on the SPA. Your model isn't safer, it's just different. And personally, I trust the OpenSSH guys way more then any SPA vendor simply because they have a very good track record.
- moe 14y agoYou're making no sense. Moving the SSH port is a trivial way to reduce your attack surface (undirected bulk scans go for 22).
- thorduri 14y agoIf undirected bulk scans are a serious threat to your security, something is up. Properly configured (AllowUsers, Disable root, no clear text passwords only keys etc), I'd say that the undirected bulk scans pose no security risk at all, they are only a nuisance in terms of spamming your logs, which is easy enough to deal with. What I'm really trying to say is that each "trivial way to reduce your attack surface" has both cost and benefits. I'm contending that moving the ssh port around gives you the benefit of less log spam with no security gain, and costs in terms of documentation and maintenance. When I do this Cost/Benefit analysis, I conclude that moving the port around has more costs then it does benefits, so I don't bother.