4 ms·
My #1 install on any server is fail2ban, then it's server specific stuff.
by columbo 13y ago
My #1 install on any server is fail2ban, then it's server specific stuff.
- octo_t 13y agofail2ban should be the first thing to install, first thing to manage via puppet/chef, first thing to have centralized logged etc :p
- stevekemp 13y agoUnless you restrict SSH access to a small set of known-good IP addresses, of course.
- hackerboos 13y agoI've always wanted to do this, but then I thought "What if I suddenly lose my IP address?"
- laumars 13y agoUse ssh keys instead then :-)
- drdaeman 13y agoKeys are additional credentials, so they don't add any security by themselves. You have remove a password from an account (set unusable password). However, there are rare cases where you need to access the server from some remote location, when you don't have your SSH private key at hand, and the only credentials you can use, are the those you keep in your head. Obviously, the most important requirement is a strong password, but protecting against brute-force won't hurt.
- laumars 13y ago> Keys are additional credentials, so they don't add any security by themselves. You have remove a password from an account (set unusable password). Keys add security if you turn off password based logins (this is done in sshd_config - you don't need to mess about with the users passwd) > However, there are rare cases where you need to access the server from some remote location, when you don't have your SSH private key at hand, and the only credentials you can use, are the those you keep in your head. > Obviously, the most important requirement is a strong password, but protecting against brute-force won't hurt. You're point about not having private keys to hand is a very valid one; and why I opt for fail2ban ssh rules against password logins on my own personal servers. But the strength of keys compared to passwords does make key based authentication a good measure against brute force attacks (purely in terms of the time line to to crack a key)
- cheald 13y agoRegarding the "don't have the keys" issue, I solve this with an encrypted TrueCrypt volume in Dropbox. Dropbox has 2FA set up on it, so getting into my servers requires 1) my dropbox password, 2) my phone, 3) the volume passphrase, and finally 4) the key passphrase. As long as I have my phone on me, I can get into my servers, but am reasonably confident that a Dropbox compromise or phone loss would not result in my server credentials being compromised.
- thejosh 13y agoI'm always super paranoid about this too, but usually you can get back into a machine via console (if it's a virtual machine) or via KVM if dedicated. But it still scares me too much...
- laumars 13y agoFail2ban monitors more than just ssh. I uses it against http auth, suspicious http bots, and all sorts (I even have fail2ban watching irc connections on one box)
- moepstar 13y ago>>>(I even have fail2ban watching irc connections on one box) Now you got me curious - watching what?
- euroclydon 13y agoIf you're using SSH keys exclusively, what does fail2ban really buy you? The HTTP monitoring sounds like it might be useful, but also might be an easy way to reject the Googlebot and de-list your site.
- jallmann 13y agoFail2ban can be used to rate-limit nearly all services that have the potential for abuse. I have it set up to track connection and message frequency, bans on message content (not following protocol, overly large, malformed, etc) and so forth. Having a system like F2B is nice because it compartmentalizes abuse handling and you can set up rules in one place for all your services, both user-facing and not. Since the rules/actions are user defined, anything is possible -- I've had actions that send alerts to Twitter, a system that distributes bans to hundreds of servers, and centralized logging that gives very good insight into how users are poking around.
- buro9 13y agoYup. Fail2Ban ModSecurity (for whatever web server, including Nginx) And the OWASP rules for ModSecurity.