I have three honeypots looking for web attacks/scans and lately all three of them detected scans looking for sqlmanager (mysqlmanager). It is the first time I see them looking for it and I couldn’t find any reference to new vulnerabilities related to it. I changed my honeypots to respond successfully to these scans to be able to see what the exploits are all about.
Received From: hn1->/var/log/httpd/error_log
Rule: 30114 fired (level 10) -> "Multiple attempts to access non-existent files (web scan) from same source."
Portion of the log(s):
[Mon May 28 15:56:00 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/p
[Mon May 28 15:56:00 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/mysqlmanager
[Mon May 28 15:55:59 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/sqlmanager
[Mon May 28 15:55:59 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/pma2006
[Mon May 28 15:55:59 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/PMA2006
[Mon May 28 15:55:59 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/dbadmin
[Mon May 28 15:55:59 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/admin
[Mon May 28 15:55:59 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/PMA
[Mon May 28 15:55:59 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/web
[Mon May 28 15:55:59 2007] [error] [client 75.xx.xx.xx] File does not exist: /var/www/html/db
–END OF NOTIFICATION
Any ideas out there? Did I miss something?
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:
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*:
*note that I am the author of this tool.
hope it helps.
If anyone is noticing that I am too quiet lately, it is because of looong hours in the plane (first Canada to Poland, now Canada to Australia). Anyway, this week I will be representing OSSEC at AusCERT 2007 and my presentation will be “Log-based Intrusion detection using OSSEC“. If you want to learn more about OSSEC and log analysis, it is a good opportunity.
Btw, if there is any OSSEC user attending the conference, let me know and we can get together and chat somewhere. Specially considering that they reduced my talk to only 35 minutes, I will not be able to talk about everything I wanted…
We are pleased to announce the availability of OSSEC version 1.2. This new version comes with lots of new features, including:
- Support for OpenBSD PF logs.
- Support for compiled (c-based) decoders.
- New options for composite rules: “srcport”, “dstport”, “same_src_port”, “same_dst_port” and
- Additional granular e-mail options. We added “sms” format output and many other options.
- Support for Zeus WebServer logs.
- Support for daily/chained checksum of alert logs.
We also completed a large re-design of the internal architecture of analysisd (ossec process responsible for decoding and analysis), greatly improving performance and organization.
A list with all the new functionality and bug fixes is available at the Changelog.
Download the new version: http://www.ossec.net/en/downloads.html
OSSEC will be represented at CONFIDENCE 2007 where I will be speaking about Log analysis using ossec. If you live in Poland (or near by), and want to learn a little more about OSSEC, make sure to attend. Some great speakers will be there, including Anton Chuvakin, Richard Bejtlich, etc.
I will make sure to provide a link to the presentation once the conference is over.
Our logo/mascot contest has just finished and we have a winner (and a brand new logo)! The Winner is Andres Armeda from Applied Watch with the following design:
We also want to thank all the other designs that were sent to us, and say that they were all great! We really appreciate the contribution.
Check out all the submissions here and the final contest page.
Thanks again everyone!! I want so much a t-shirt out of this logo.. 🙂
OSSEC v1.2 is soon to be released and we need some help beta testing it. As I always say, trying out our beta releases is a simpler and very effective way of helping the project.
Where can you download it?
v1.2 beta for Unix/Linux
v1.2 beta for Windows
What kind of things do we need to be tested?We need to make sure it compiles fine on all platforms and operating systems. We changed the internals quite a bit and we may have missed something. Try on Solaris, NetBSD, FreeBSD, AIX, HP-UX, any Linux distribution that you have.Make sure your local rules still work and it can parse all your logs.Try the new features, including the log signing and the granular e-mail configuration that I mentioned on previous posts.On Windows, make sure there are no false positives regarding our new NTFS ADS check.
Let us know if you find anything wrong…
One of the most popular feature requests for ossec that I received lately was the availability of granular e-mail alerting options. Well, if you have been waiting for it, it is now available to be used… Just try our first beta release of version 1.2 and let us know how it goes.
Here are some examples of what you can do:
If you want to e-mail firstname.lastname@example.org for every event in the group syslog you can add the following to ossec:
To e-mail (sms format) email@example.com for every event with severity higher than 10 (Note that the SMS format is not grouped, so the e-mail is sent immediately):
To e-mail firstname.lastname@example.org for every event from rule 123 or rule 124:
To e-mail email@example.com for every event with severity higher than 12, from agent qwert, without any delay (immediately):
You just need to tweak it for you own needs. Send any questions to our mailing list or here in the comments.
Download it from here (always use the latest package available): beta snapshots.
OSSEC v1.2 will come with support for daily/chained checksums enabled by default. Basically, what it means is that at the end of each day, ossec will generate the md5/sha1 sum of the currently logs plus the md5/sha1 sum of the checksum from the logs of the previous day.
To exemplify, at the end of Apr 23, ossec will create the following file:
# cat ossec-alerts-23.log.sum
MD5 (/logs/alerts/2007/Apr/ossec-alerts-23.log) =
SHA1 (/logs/alerts/2007/Apr/ossec-alerts-23.log) =
MD5 (/logs/alerts/2007/Apr/ossec-alerts-22.log.sum) =
SHA1 (/logs/alerts/2007/Apr/ossec-alerts-22.log.sum) =
If you look at the checksum of Apr 22, it will have its own plus the one from the day 21 (and the same will happen back until the first day that the chain started).
What do we get from that? First, any modification on the old logs will require changing all the next checksums. Second, if you e-mail them to you every day (or post somewhere publicly), you can have a valid case to prove that they were not tampered.
If you want to try this feature, please check a pre-beta version: snapshots