New blog location

I won’t be using this blog anymore. For new content, go to


Posted in dcid | Tagged | Leave a comment DNS and Content modified

If you visit you will notice a pretty new design and a new home for it. The server was officially moved to a Trend server and is now being managed by Vic Hargrave ( and the Trend team. If you notice anything wrong there (or broken links), please let Vic know and he will get it sorted out.

I also want to thank Marcus Maciel (from for hosting the server/site during all this time (almost 8 years).

Changing topics, this is the notification I got from sucuri a few minutes after the DNS was changed to point to the new location:

< has address

> has address


Posted in ossec | Leave a comment

Faking (all) user agents

If you are going to fake a user agent, do it right :) Seeing some web scanners faking all possible browsers out there in one single request:

  • Firefox/3.6
  • Chrome/9
  • Firefox/3.0
  • Opera/9.99?
  • Safari
  • and more..

This is the actual log (searching for vulnerable oscommerce files):


I wonder if it is a bug in their scanners or they did on purpose to bypass user agent restrictions.

Posted in log analysis, webattacks | Tagged , , | Leave a comment

OSSEC rule for the PHP-CGI vulnerability

I am seeing many scans for the PHP-CGI vulnerability in the wild and put up a quick OSSEC rule to detect/block those:

It looks for the possibly dangerous options (-d,-s,-a,-b and -w) and alerts if it sees those. This is the alert it generates when detected:

This rule is also in my repository and you can download the latest from here.

Posted in ossec, webattacks | Tagged , , | Leave a comment

Database Logging (PostgreSQL and MySQL)

Nobody cares about database logging, but I really recommend enabling them to see what is happening behind the scenes (specially for web applications).

To enable on PostgreSQL (and be compatible with OSSEC):


To enable the generic Query log on MySQL (the error log in on by default), you need to start MySQL with –log:

The best option is to modify /etc/init.d/mysqld (if using Centos) and inside the –log in there.

Nothing new, but I was searching for this information online and couldn’t find much info.

Posted in log analysis, ossec | Tagged , , , | Leave a comment

Alexa toolbar and https (not best friends)

For some reason (don’t ask my why), I decided to install the Alexa toolbar for Chrome to try it out. It works well for what it does, and I didn’t see anything wrong with it besides the expected privacy violation (tracking) of them sending all your traffic to their servers.

So every time you visit a site, a request is made to their servers to query the site rank:

192.168.1.X.44210 >
GET /data/ABCD?cli=10&ver=alxg-1.1.0&dat=ns&url=http%3A// HTTP/1.1
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.91…
Accept: */*

If you are using it, you expect those requests to be made (wich is supposed to be anonymous), so not a problem.

However, I just noticed one big issue is that they also do that for all your HTTPS traffic. So if you are visiting a https site (which would be encrypted in the wire), you are also leaking the sites you are visiting via their rank requests. So if I go to (https), a HTTP request is made at the same time:

192.168.1.X.47733 >
GET /data/ABCD?cli=10&ver=alxg-1.1.0&dat=ns&url=https%3A// HTTP/1.1
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.91…
Accept: */*

I actually thought their plugin (extension) would not work for HTTPS or would at least have a setting to disable it. This is specially bad because now you are leaking all your encrypted traffic browsing for anyone that is watching the wire.

*I know, I know, if you are using that toolbar you probably don’t care about privacy, but it is something to keep in mind. A simple fix is to just remove it and move on.

Posted in alexa | Tagged , | Leave a comment

Good passwords: It is not about their size or complexity

Every time I read a password recommendation or policy, I get frustrated. It is always about their length and complexity, and they miss the real issue with passwords and how they get compromised.

So I wrote this small (non technical) paper on my thoughts on passwords and how I define a good password:

Comments are welcome.

Posted in dcid | Tagged , | 1 Comment

Back into blogging?

This blog has been neglected a bit lately. Too much going on and not enough time to post here.

Anyway, I pushed some of my old papers/texts here:, including a few that I thought had disappeared (specially log analysis for intrusion detection).

Now back to work.

Posted in Uncategorized | Tagged | 1 Comment

3WoO: Alerting on DNS (IP Address) changes

If you keep your DNS outside and you can’t monitor the zone files directly, a nice way to make sure the integrity of your DNS is intact is by checking remotely that it hasn’t been changed.

With OSSEC, you can do it using the command monitoring output.

First, download the latest version from here and install it.

You will see a new tool in the /var/ossec/bin directory:

# /var/ossec/bin/
/var/ossec/bin/ addfile <filename> [<format>]
/var/ossec/bin/ addsite <domain>
/var/ossec/bin/ adddns <domain>

Example: /var/ossec/bin/ adddns
Example: /var/ossec/bin/ addsite

So, you can just run the command “ adddns” and it will add the domain specified to be monitored:

# /var/ossec/bin/ adddns

In this case, we added the domain In the backend, it will add those new entries:

     <command>host -W 5 -t NS; host -W 5 -t A | sort</command>

   <group name="local,dnschanges,">
   <rule id="150013" level="10">
     <check_diff />
     <match>^ossec: output: ’host -W 5 -t NS</match>
     <description>DNS Changed for</description>

So you get a nice alert when your IP address changes.

Posted in ossec, v27 | Tagged , | 1 Comment

Detecting outdated (web) applications with OSSEC

For the last few days I started working (again) on the system auditing module for OSSEC and one thing that can make it more useful is to detect outdated applications (specially web apps).

Things like WordPress, Joomla, Wikis and others that can be easily used to compromise a server if not upgraded.

To get started, I added a few rules for WordPress, Joomla and osCommerce, so if you try the latest snapshot it will alert you if it finds any of them not updated:

* Alert 1316458742.1014: mail – ossec,rootcheck,
2011 Sep 19 15:59:02 testdev->rootcheck
Rule: 519 (level 7) -> ‘System Audit: Vulnerable web application found.’
System Audit: Web vulnerability – Outdated WordPress installation. File: /var/www/

But I really think we can expand it a lot more. What web applications and tools we should check? What other things we can look in the server that are important to be alerted on? I would love more ideas to expand it more.

Example of the system auditing rule:

[Web vulnerability - Outdated WordPress installation] [any] []
d:$web_dirs -> ^version.php$ -> r:^\.wp_version && >:$wp_version = ’3.2.1′;

[Web vulnerability - Outdated Joomla (v1.0) installation] [any] []
d:$web_dirs -> ^version.php$ -> r:var \.RELEASE && r:’1.0′;

I am thinking on things like PHPmyadmin, timthumb, uploadify and other tools that are easy to forget to update and had serious security vulnerabilities in the recent past.

Posted in log analysis, v27, webattacks | Tagged , | 9 Comments