This talk about distributed attacks is interesting because I am seeing none of it. I continue to see the "traditional" attack every 5 seconds or so from one IP which gets banned on the 6th attempt by the script I use.

I wonder if the distributed attacks are not common, or if they are just targeted at IP addresses of known high-value targets.

I've noticed the same thing, starting around November of '08. I talked about it a little bit in post #7 on this thread: http://www.linuxquestions.org/questi...ilures-685110/

I have had to take some extra security measures because now there are only a couple attacks coming from each IP (not enough to get banned - or delayed in my case).

I think you're missing the point. If the attackers can dodge your fail2ban, that's one thing. If you're layering your security properly, the new trend of attack will fail...BUT most people tend to totally rely on (key word here) passwords and tools such as denyhosts and fail2ban. A key point is the fact that you keep mentioning strong passwords. Key-based authentication is the stronger solution. There are also other solutions that you can apply to the SSH config file. max-tries itself could stop attacks...that doesn't make the attacks go away, though. There are a lot of misconceptions around SSH that should be put to rest. With the amount of headlines on SSH compromises this year, you'd think that people would learn to harden their systems...they aren't, which is why we post here in the security forums.

The reason why I mentioned the new trend was that there is very little mention of it on these forums. That is a critical change in trending and one that will not be apparent unless you look at your logs with the understanding that one IP showing 30 times in a log could be a concerted attack.

I don't think that this is trivial. A very large percentage of the US (I don't know world stats) is broadband-capable. With dual-core machines and broadband access, factored with scaled attacks of distributed bruteforcing of passwords, the chance of success is much higher than if it were one machine conducting the attacks. And, keep in mind that the average user isn't particularly focused on security as we are here, so the success rate in attacking such an individual's system will be even higher.

So, yeah, this is dependent upon how well you harden your services and FWs. The security oriented won't have issues, but this forum is only a sub-segment of a large forum. Sometimes, big organizations need to have a service as open to the internet as possible. It helps in organizing your security posture if you know the methods that malicious users are using to go under the radar.

I've lost count of the amount of posts in these forums that state that an admin has a compromised machine and that it was compromised because they were unaware of some attack that has been around for ages...

BINGO! Cool!

The most concerning thing to me is the fact that I don't see this being somehow tracked using security event management tools (BASE, ArcSight, and such). This isn't particularly a thing to worry about for the average user, but I work with a huge managed security services provider...I don't think we track such attacks (which means we may not be seeing things that companies are paying us to see). :/

This does sound like something that Snort may be able to detect, provided there are good SSH rules in place to detect such activity.

In my prior post, I mentioned using an ids to trigger on dead-zone queries, not each host. Invalid port attempts on clients could be summarized and analyzed before triggering an alert.

I do get your main point however, that a large bot net could try a large number of possibilities against a large number of targets with little or no repetition of IP addresses, and be able to take their time about it. Using repeated behavior from a single IP will not offer any protection.

My point is that legitimate connections will never do certain things, like trying to logging in as root. You don't need to detect repetition. A single attempt against root or system account is enough to ban an IP. Quick and Easy. You don't need to be alerted every time. To quote the Don from Godfather's pizza, "Just Do It". Combined with other measures like using public key authentication (as I already mentioned) and "AllowUsers", a bot net can't guess a password if you don't use one. Trying password authentication at all is enough evidence to ban that IP. Legitimate users won't use password authentication. By changing your own behavior from password authentication to using keys, you have made the behavior of the attacker very easy to detect.

The dead-zone and booby trapped ports example I gave would have fewer false positives than very complicated and comprehensive ids rules. I was extending my argument of using certain behavior as definite evidence to inside the firewall. By triggering on items that are definitely illegitimate, you could have that IP be blocked by the host automatically without alerting you each time. Besides, I'm sure your tools can analyze, issue periodic summaries and only send out an alarm if there is an emergency. If you are having a distributed attack launched from inside your firewall, than someone should get 400 alerts an hour to wake them up to that fact.

You were posting about a certain change in behavior in the attacks that evade simple detection based on repetition. There are other behaviors, like port and IP discovery that are just as easy to detect. Maybe I should have stated it this way from the onset. I'm not saying you should abandon your more thorough and comprehensive tools. I'm saying that very simple, layered techniques can be employed automatically to eliminate the low hanging fruit, so that your commercial tools can concentrate on the dedicated attacker.

---
P.S.
AFAIK, we are paying attention to the links.

I know that distributed hits will not trigger listing tools, however, I thought I would mention a useful tool that is built right in to iptables. You do not need another tool to add to your allow or deny files. Just use iptables to do the job:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent
--update --seconds 60 --hitcount 4 --name SSHATTEMPTS --rsource -j DROP

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent
--set --name SSHATTEMPTS --rsource

This will add any connections to port 22 to a list, and after 4 hits in 60 seconds, it will drop them. So alter to your wishes.

Yeah, this is similar to what I use with pf.

I've been getting a LOT of these in the past few months in my logs too. I assumed it was a botnet or something, because most of them are coming from valid websites, that I'm guessing were compromised. The thing that makes me think its a botnet is that it's usually almost exactly the same users and passwords they try each time. Won't get into any reasonably secure system that way, but some users will leave their username as their password, and if they have a common name..., and I've seen tons of boxes with the user "guest" and password "guest" or "test" and "test" or variations thereof.

if you are on DSL or a cable modem you will see them almost daily. Its not uncommon at all to get scanned like 10-15x a day from a cable modem.

With proper system security configurations you _should_ be fine and not lose sleep over it.