5 ms·
Exactly what fail2ban needed: a web UI for people to exploit. If I could eliminate any Linux service, it would probably be fail2ban. As an SSH security measure
by akerl_ 12y ago
Exactly what fail2ban needed: a web UI for people to exploit.
If I could eliminate any Linux service, it would probably be fail2ban. As an SSH security measure, it's more than useless. If your SSH credentials can be brute forced, that's the problem, and it's easy to fix. Fail2ban just gives somebody a way to lock you out of your own system or to pin a core on your system by overloading it.
If you're trying to add security layers to SSH, here are some suggestions for doing so:
* fwknop (http://www.cipherdyne.org/fwknop/ http://www.cipherdyne.org/fwknop/) -- Single Packet Auth based on GPG
* google_authenticator (https://code.google.com/p/google-authenticator/ https://code.google.com/p/google-authenticator/) -- PAM support for TOTP
* knockknock (https://github.com/moxie0/knockknock https://github.com/moxie0/knockknock) -- Single Packet Auth using symmetric encryption
- ChikkaChiChi 12y agoI thought Fail2Ban hooked directly into iptables? How would you get locked out or overloaded? I don't necessarily think Fail2Ban needed a GUI, but I guess I never thought it was a "bad" thing?
- akerl_ 12y agoIt uses iptables, but it detects things to block by reading log files, and it's not exactly efficient in doing so. As such, if an attacker can pump lines in (like by having their botnet SSH to your system), they can get it to spin a core.
- deleted 12y ago[deleted]
- fred_durst 12y agoYes, the reality is that "baseball" is a bad password, and ssh as root is a bad idea but getting auth.log spammed into oblivion is also a bummer. It feels like a web GUI would help less experienced sysadmins not just apt-get remove fail2ban when they get themselves locked out for the first time.
- akerl_ 12y agoroot is no worse from a security standpoint than any other user. If knowing your username helps somebody guess your password or bruteforce your key, the username isn't the problem. Using multiple users is great from a compartmentalization / user_management standpoint, but it doesn't protect against brute-force.
- ryan-c 12y agoAdd http://www.heiho.net/pam_shield/ http://www.heiho.net/pam_shield/ and http://www.snafu.priv.at/mystuff/pam_recent.c http://www.snafu.priv.at/mystuff/pam_recent.c to that list. I use use some iptables voodoo with them to auto-whitelist on successful auth and blacklist on failed auth attempts. Three things to note about google authenticator: 1. ssh keys bypass it unless you have a patched version of OpenSSH with multiauth 2. It can be configured to have you append your one time code to your password for interop with things that can't handle keyboard-interactive auth 3. It is self contained and doesn't use any google services to function.
- Sean-Der 12y agoIf you are in a real production environment you shouldn't be opening up SSH to the world, most people that are accessing SSH have enough know how tunnel through a VPN. So for most of my uses this is a non-issue. fail2web for me is used on Asterisk servers to watch HTTP auth and SIP. Most of the customers I work with have very strict corporate IT policies, they have to review every piece of hardware and most of the time I can only get an ATA approved. So I drop an ATA on their network with SIP/TLS and ZRTP and they setup the client. However, I don't want to make the assumption that their network is 100% safe, so fail2ban serves me well here. Also to your point of fail2ban being overloaded, this has never happened to me. I see scans/brute forces all the time add after five fails I usually block the small subnet, and the problem goes away. All of the solutions you posted are 100% a no go for the problems I am trying to solve.