It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.
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...
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.
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.
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!
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."
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.
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.
It's just caution. Using port knocking by itself would be a recipe for security disaster. As an addition to an already secure system, it's okay if you just want to reduce junk in your logs, perhaps. Many would ask, in that case, why use port knocking at all?
The is the usual thing I hear. It is so incredible naive, though.
Any service, no matter how locked down and properly configured, still presents an attack surface. SSHD is a program like any other, and it can have bugs.
When you use port knocking with a properly configured SSHD, you are much more secure because that attack surface has been removed.
Recent Google Cloud Engine images have Sshguard enabled by default.
Now I do wonder: does this 'exploit' still cause a log line immediately after each attempt? And also, do iptables firewall rules also apply to open connections, or just to new ones? In the latter case, Sshguard and fail2ban are circumvented for a rather high number of attempts.
One of the common gotchas though is that if you add a rule to allow "Established" connections, and then try to add a new rule after that which says "block IP X", that will not sever existing connections.
To block existing connections you can remove that entry from the connection tracking table, or you can insert your "block IP X" rule above your "allow Established connections rule".
iptables rules can (trivially) apply to all traffic, or they can be sensitive to connection state.
In the case of cracking, you'd just want to apply a blanket blan: completely black-hole any packet whatsoever coming from that IP to your box. That will freeze all existing connections.
To ban new connections, you'd have a rule that applies to TCP connections in the NEW state, leaving the ESTABLISHED ones alone.
As I understand it this will log all passwords anyone enters -- even correct ones. This seems like a terrible idea, or at the very least should be used only after careful consideration. Even logging incorrect passwords is a bad idea, due to slight typos by legitimate users.
You are correct. The patch is meant for IT security research and honeypots. The purpose is to see what passwords the SSH brute-force bots are using. It should not be used on production systems where legit users are logging in via SSH. That would be unethical and possibly criminal (depending on location).
Also, with SSH, I use keys, not passwords. I encourage others to do that as well. You could have this patch on a honeypot and by using a SSH key, your account password would not be in play.
reply