As many of you know, I actually read our various servers' logs quite frequently.

I've been a bit lax over the last few days due to an unfortunate dental problem, but today I happened to be looking at /var/log/secure and found that someone has been trying to guess FTP passwords, but really, really slowly.

Every day for the past few days, said person has been trying to login to four or five different FTP accounts. But only four or five a day, and only one attempt for each one. I don't know what password they have tried, as rather unhelpfully /var/log/secure doesn't show anything. I'm guessing they are trying to use a password identical to the username that they are trying.

Interestingly, they are being methodical about it. They are using an alphabetic list of domains, starting with a. They strip out the TLD and use that for the username.

I can't tell for sure, but it looks as though they have used one of the services that tell you which domains are associated with a particlar IP. I suppose it is also possible that they have a mega-list of domains, and are going through them one by one alphabetically, thus explaining why I'm only seeing four or five attempts per day. But in that case they must have a hell of a long list, as it as taken from five days to get from a to g. It isn't out of the question though, especially since on one day at least I've seen one login attempt at a certain time of day, then three more at a different time.

Anyway, my point is that if I as a human can spot this as being bad, surely we should be able to come up with a rule for it.

e.g. a rule that says "more than 10 failed logins in 3 days = block permanently".

So my feature request is a "slow burn" rule, looking for X "Login failed" in /var/log/secure over Y days that causes the IP to be added to the blacklist as opposed to just the blocklist, as an X minute block would not protect against this type of slow attack.

Thanks,

Faris.

Yes, also seeing an increase in slow attacks to ftp/mailboxes. Whatever method is being employed, it appears to avoid the same IP/domain too often in a given time frame. Often using different IP's in numerous geo locations (proxy/zombie networks), but am certain it originates from the same source.

sounds interesting.

one thing that would cause problems in this case is logrotation.

Yeah, good point. Though from my logs the approach appears to be start slow and build in frequency until the bocking period is detected, then sit just outside that with a fairly constant stream of access attempts on (mainly) mailboxes and ftp accounts. It's annoying that it fills the logs...

I don't know how OSSEC works, but I had rather hoped that it would look for a string (e.g. "Login failed") and record the event in its own DB etc. Then, once the trigger threshold was exceeded for a particular IP, it would then take action.

Repeatedly reading the same logfiles (which can be huge) seems a bit inefficient if that's what it does.

Incidentally, the key thing here is to block and not blacklist. I'm not sure this is possible at the moment? i.e. I though OSSEC could only perform a particular action (by default, add to blocklist)?

We have a few customers who have mailservers configured to collect email from mailboxes that have long since been deleted, causing regular login failures but not frequent enough for them to be blocked using the current rules. A slow burn rule like the one I'm suggesting would obviously blacklist their IPs. But I don't see any other option. They need to fix their config and I suppose blacklisting them will be a good wake-up call.

Sure you can do this, we call this class of attack the "Low and Slow" and its exactly designed to circumvent brute force detectors. There are folks that have done whole phd dissertations about the L&S approach, so there are a many strategies in academia to approach the problem.

OSSEC is going to be able to track an event over as long a period of time as you want, provided the analysis daemon is not restarted. If it does get restarted it would be starting its counters again from scratch.

The current login failure thresholds for FTP are:
* 6 fails over 120 seconds for 1 IP to accounts that exist
* 10 fails over 120 seconds for 1 IP to accounts that do not exist

We are not limited to a single thresholds for these rules. Multiple rules for the same class of event are allowed, for example we can have:
10 fails in 3 seconds == high volume brute force, and call it level 15
100 fails in 24 hours == low volume brute force, and call it level 7
10 fails in 24 hours == suspicious, but maybe not something to block so its a 5

ASL 3 has a "repeat offender" capability, which will also increase the block time each time they come back. The default method we use is for a rule to trigger a block for a fixed number of seconds (600 / 10 minutes) and then it is expired. The new system has the base block time, and a repeat attacker's block time is doubled each time they return (caveat: unless you restart ossec, then this tracking is reset).

You can also associate a specific action with a specific rule, so for example you could set a rule that just grabs login failures and dumps those to a separate file/database/script to allow something else to process it for L&S analysis.

Login failures are also captured in the mysql database (rule id 11203 & 11204 for proftpd), and in addition we have a default report that tracks login failures by IP. Screenshot here:
http://www.atomicrocketturtle.com/asl3-report.png

The example shown are failures against SSH, but its no problem to create additional reports for FTP, SMTP_AUTH, POP, etc.

That sounds very useful. If there are updates to OSSEC signatures does an asl -u reset tracking? Currently blocking offending IP's by hand, so would be interested to see how ASL3 handles these attacks.

Installed ASL3 (from testing repo) on a LAN file server for a few days to take a look at the new features/GUI, very impressed overall. As it is not public/Internet facing no traffic was logged, but I can imagine how it will behave once in the wild.

Question: is it possible to allow specific services to be whitelisted in ASL, eg. CUPS/avahi-daemon? This was the only thing which made me uninstall, would prefer to have an ASL environment for testing.

Suggestion: would it be possible to reduce the height of the GUI header? When running on a smaller monitors the scroll bars only appear in the reporting area beneath, making it a bit cramped/scroll-y (even without bookmark/status bar on a 1440x900 screen).

Many thanks!

Just change SYSTEM_TYPE to "custom" and ASL wont disable any services. That sets the pre-configured profile that only enables the services required for that role (webserver for example is the default, which disables non-web services like X, etc.)

Thanks, I guessed there'd be a nice way of achieving that, make change in /etc/asl/config then asl -s -f?

Exactly

It is possible to have a level>X = blacklist, and level <X block, or are we relying on the repeat offender option to keep the slow bad guys out?

Yes, the new system is designed to create a long term dynamic blacklist through the process of automatically identifying and responding to repeat offenders, and recognizing the sources that are just transient and do not offend in the future.

We will also be looking at other ways to use the data ASL collects to analyze it for more trends as we roll out versions in the 3.x series. We are also exploring the feasibility of a distributed system that would allow any ASL system to share attack data with us in real time (information about the who/what/when etc. of attackers and just suspicious things, or correlative data) to generate and share a realtime a distributed picture to and from anyone that participates and is running ASL. That in turn will be reflected back to all the participating systems to further act as criteria for correlation, and potential blocking, alerting, repeat offender responses, etc. which may result in yet more data being fed back, and so on.

We are also exploring the feasibility of a reflector honeypot that your systems can be configured to participate in, so that repeat offenders get transparently redirected to the honeypot to further teach the system.

Sounds great. Looking forward to seeing it once it is ready.