Hacker News Reader

Comment by DrTung | Hacker News Reader

Have you tried fail2ban? It really helps to keep the hacking attempts down on your ssh-server(s), especially if you increase the bantime from the default 600 seconds to a couple of million...

View on HN

Note that Fail2ban doesn't support IPv6 at all [1]. I'm currently using sshguard [2] instead.

Edit: Thinking about it, I guess that blocking single IPv6 addresses, as sshguard does, doesn't really help at all, as it's easy to obtain huge subnets. (This might even open the door to an iptables DDoS?) Blocking whole subnets, on the other hand, doesn't sound clever either. (Who knows how many users are sharing the same subnet?)

So, should I just close port 22 on IPv6 altogether? Not a very sustainable solution. This needs more research!

[1] https://github.com/fail2ban/fail2ban/issues/39

[2] http://www.sshguard.net/

I'm very curious about IPv6 banning best practices.

I imagine banning /64 networks is completely harmless, but I'm not really confident on that. I'd be wary of banning anything bigger, but getting a bigger address range is very cheap, so that may be required.

I've recently written a banning layer over my email server, in case somebody tries to guess the computer's passwords. It's a certainty that an attack exploiting IPv6 will go through, so I'm interested on the subject. By the other side, no attack it received up to now cared enough to read the EHLO reply and see that the server does not support login authentication, so I'm not that concerned, I guess I'll fully migrate to public key before any brute-force attempt is successful.

I think /64 would be the correct subnet size to ban in most cases.

My understanding is that /64 has become the de-facto standard subnet size for IPv6 sites. For example, I think that most home and business internet connections would be likely to receive a /64 allocation from their provider.

Moreover, many times the hosts will be generating themselves a new random address (within the /64) from time to time. So blocking a single IPv6 address probably won't block the user for long.

Conceptually, whenever a site (or hosted server, etc) would have been allocated a single address (/32) under IPv4, I think the analogous allocation for IPv6 is a /64, i.e.: 1.8 x 10^19 addresses.

If you look at RFC5375, you can see why /64 would be common:

- "An allocation of a prefix shorter then 64 bits to a node or interface is considered bad practice..."

- "Using subnet prefixes shorter than /64 would rarely be useful..."

- "Using subnet prefixes longer than /64 is not recommended for general use, and using them for links containing end hosts would be an especially bad idea..."

- "Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery, Secure Neighbor Discovery, privacy extensions, parts of Mobile IPv6, PIM-SM with Embedded-RP, and Site Multihoming by IPv6 Intermediation, among others."

It is all fun and games until you ban yourself for a couple of million seconds...

Far too many people ban themselves with fail2ban.

I rolled my own log-monitoring solution. I have it so that there have to be N unsuccessful attempts in M seconds. There are multiple such thresholds (different combinations of N and M) with different banishment periods. The system will react to an acute flood, like when > 30 attempts are made in just a few seconds, say (which you would never do if you're clumsily mis-typing your password). The software also discriminates whether the same account is being tried multiple times, versus different accounts. If the same client IP address is trying different user ID's, it will be banned more easily than a client trying the same account. Someone trying three or more accounts is almost certainly an intruder, since a legit user on my system knows at most two accounts: their personal one and possibly root. Trying root is punished more swiftly than non-root, also. All these inputs contribute to a score, and the score determines the position on the banishment scale which translates to a period.

Oh, and a successful login will clear the record: the software scrubs all records of that IP from its cache, so then if you make new logins from the same IP with mistyped passwords, you're starting with a clean slate.

I've never locked myself out.

I use key-based authentication and fail2ban. Since that won't fail like passwords, it works wonderfully and the chances of my being banned are nil.

* Until you have too may keys on your agent

* Until you have a script repeatedly attempt w/o your keys unlocked

* Until you try from a new computer on the same network and fail to setup your keys first.

Ask me how I know :)

Important to note: You can whitelist IPs if you are worried about getting locked out from work/home. They may change periodically, but that's pretty easy to update as well.

Just make sure to whitelist known-good IPs.

Sharp tools are sharp.

Why are you using a circular saw to cut your fingernails?

What's the point of fail2ban (for ssh)? It definitely won't stop you from getting hacked, nor will it provide any useful data.

Especially since any sane bruteforcers iterate over IP addresses instead of passwords to avoid just this.

It's useful as part of a layered strategy. Your passwords still need to be secure enough that they can't be guessed easily. If they're easily brute-forced, fail2ban might slow things down, but it won't stop it.

Once you have that though, fail2ban does do a nice job of making the perpetual brute force attacks significantly less obnoxious. I've seen machines effectively DDoSed by brute-force ssh attempts, either with the network overloaded or filling up disk with ssh's logs of the failed attempts. Not as bad as getting hacked, but still annoying. A serious botnet attack will be able to spread it over thousands of IP addresses, but IME, those are relatively rare. Most attacks are still coming from a handful of hosts at a time and fail2ban basically stops them dead in their tracks.

The other useful thing to do with fail2ban is to use it along with a whitelisted range of networks. Even if you aren't on a private network, not every server needs ssh open to the entire world. You can often get away with whitelisting the local network and maybe a few ISPs' ranges where admins are likely to access it from. I run fail2ban even on machines on private networks. If one of the other machines gets hacked, one of the first things they'll usually do is start trying to brute-force other machines on the network. Since it will probably only be a couple compromised machines, fail2ban is useful here.

I find that it does also give me useful data as well. Eg, I have simple graphite metrics based on the number of bans/minute. If it gets unusually high, I can get an alert and perhaps notice that other hosts have been compromised, or do a quick firewall rule or two to drop packets from an entire network for a while.

I don't even think you need to pump the ban time up that high. Most of these driveby brute-force attacks are just a bot that will give up and move on to some other server as soon as it's banned.

Never seen the need for fail2ban when you can do the same thing with a couple of iptables rules.

Mind sharing those ? (Or do you mean you add them manually at each attempt ?)

You can rate limit connections and connection rate with the iptables connlimit module[0]. What exactly does fail2ban gain over this?

[0] http://www.cyberciti.biz/faq/iptables-connection-limits-howt...

Just as easy to block yourself from the server with iptables as well ;-)

Reply on news.ycombinator.com