Tag: Log Retention & Aggregation

After posting my paper about Remote log injection, most of the feedback I received was regarding how “bad” these tools (e.g. DenyHosts, BlockHosts, etc) are and how bad the idea of log-based automatic response is.

Some people even said that the best approach is to just ignore these logs, since they are just noise. Yes, ignore their sshd/ftpd logs… Of course that I don’t share this opinion. SSH/FTP scans are real attacks and some systems can end up being compromised because of them (well, if they had good passwords, they wouldn’t, but that’s another discussion). Not only we should monitor for failed password attempts, but also for failed passwords followed by success, every success login, etc. Again, that’s another discussion.

Anyway, instead of blaming these tools, I would also put the “blame” on the applications that generate log messages without any good formatting or consistency. In the case of ssh, it uses spaces as a “field separator”, while the user name itself can have spaces. Not a good choice at all. The same applies for Vsftp that uses a bracket as a separator while, again, user names can have brackets.

Logs are there for a reason: to be analyzed, monitored, etc. If they are not consistent or can easily be modified based on remote log injection, they lose their value. That’s why a lot of people just ignore them…

What do I mean by consistent logging? I mean a log that is well defined and uses good separators making it easy for anyone to parse and automatic analyze them. A good example is the ProFTPD logs:

proftpd[12564]: test (hostname[192.168.1.1]) – USER xx: Login successful

Why do I think it is well formatted? Well, it starts with the hostname, followed by IP. These are not user provided input, so they can not influentiate the other fields. The second good point is that the user name separator is a “:” (colon) which is a not valid character for user names. Because of that, log analysis tools can use a simple regex looking for “:” as the end of the user name. Third, it has a descriptive message of the event (in this case, login success)…

There is a lot more on consistent logging that I would like to talk. Hopefully when CEE is really out it will address some of these issues. Comments?

I just finished an article about “Remote log injection”, that among other things, exposes some vulnerabilities on DenyHosts, Fail2ban and BlockHosts that can lead to arbitrarily injection of IP addresses in /etc/hosts.deny. To make it more “interesting” (i.e. worse), not only IP addresses can be added, but also the wild card “all”, causing it to block the whole Internet out of the box (bypassing white lists).

The paper is available here: https://dcid.me/texts/attacking-log-analysis-tools.html

Snippet from the article:

The purpose of this article is to point out some vulnerabilities that I found on open source log analysis tools aimed to stop brute force scans against SSH and ftp services. Since these tools also perform active response (automatically blocking the offending IP address), they would be good examples. However, any tool that parse logs can be equally vulnerable.

We will show three 0-day denial-of-service attacks caused by remote log injection on BlockHosts, DenyHosts and fail2ban.

This paper talks about remote log injection, where an external attacker can modify a log, based on the input it provides to an application (in our case OpenSSH and vsftpd). By modifying the way the application logs, we are able to attack these log analysis tools. We are not talking about local log modification or “syslog injection”.

In the snort mailing list there was a thread about detecting authentication failures (on ssh, apache, ftp, etc) using Snort. I love Snort, but using a NIDS (Network-Based IDS) for this kind of stuff is trying to use the right tool for the wrong reasons (yes, we could even write a syslog parser using it).

That’s why we need LIDS (Log-based Intrusion detection). Check out my reply to this thread:

That’s what I would call using the right tool for the wrong reasons (or something like that).

The provided sshd signature does not detect brute force attacks, but multiple connections from the same
source ip (failed or not). The HTTP signature can easily generate false positivies since you are just
looking for the content “404″, and it would not work with SSL…

My point is: why not use log analysis to detect failed logins (and brute force attacks)? Both sshd, apache,
apache-ssl, ftp, telnet, etc ,etc log every failed login attempt (and every successful login attempt)?

By using log analysis you can reliably detect every failure and you don’t need to worry about encrypted
traffic. Plus, you can do more useful stuff, like detecting multiple failed login attempts followed
by a success (successful brute force attack) and monitoring every successful login to your systems.

I wrote a paper while back with some patterns that we can look in authentication logs:

http://www.ossec.net/en/loganalysis.html

And if you are looking for an open source tool to monitor all your logs (from Apache to sshd, proftpd,
Windows logs, etc, etc), with the ability to execute active responses based on them (blocking ips,
disabling users, etc), you can try ossec*:

Home

http://www.ossec.net/wiki/index.php/FAQ

*note that I am the author of this tool.

hope it helps.