For example, here is a trace for a non existent requested resource:

2011/12/29 16:13:33 [error] 3212#0: *241787 open() "/opt/foo/default/admin/phpmyadmin/index.php" failed (2: No such file or directory), client: 58.19.239.205, server: , request: "GET //admin/phpmyadmin/index.php HTTP/1.1", host: "88.191.135.71"

So, to be able to detect such hack tentative and block it, create a file named nginx-noscript.conf, and put:

[Definition]
failregex = open\(\) "/\S*(\.php|\.asp|\.exe|\.pl)\S*" failed.*client: <HOST>,.*
ignoreregex =

Then, add its definition in an entry in the /etc/fail2ban/jail.conf:

[nginx]
enabled = true
port = http,https
filter = nginx-noscript
logpath = /var/log/nginx*/*error.log
maxretry = 6

Here, if there are more than 6 occurences of a failed 404 request in less than 600 seconds (the default value, modifiable with the ‘findtime’ variable), the ip will be added to the ban list.

I ran it on several of the blogs I manage, and all of them were vulnerable to XSS (wp-scanner also tests other vulnerabilities) :-(
I followed the advices on blogsecurity’s website and modified all of the search functions I could find. Now wp-scanner doesn’t report any vulnerability (it doesn’t mean it is cracker-proof, but it’s a good start).

So if anybody else uses the Redoable theme like me, you should patch the header.php file. Near the top of the file, find the "Search for" string, and enclose the $s string with the htmlspecialchars() method:

Search for <?php echo htmlspecialchars($s); }

Do the same for the searchform.php file:

searchform” action=”<?php echo htmlspecialchars($_SERVER['PHP_SELF']);

An even better protection would be to use the mod_security module for Apache/Apache2, which can detect and block these kind of attacks. But this requires that you control your server.
To prevent web visitors from sending tags, you can add the following rule in your virtual host:

SecFilter “<(.|\n)+>”

Now, when someone requests < anything >, the visitor gets a 403 error, and in your audit log, you now have:

==36d82a37==============================
Request: www.gradstein.info 82.67.175.56 – - [11/Jun/2007:11:10:56 +0200] “GET /?s=%3Cwpscan%3E HTTP/1.1″ 403 202 “-” “Mozilla/5.0″ – “-”
—————————————-
GET /?s=%3Cwpscan%3E HTTP/1.1
mod_security-message: Access denied with code 403. Pattern match “<(.|\\n)+>” at REQUEST_URI [severity "EMERGENCY"]
mod_security-action: 403
HTTP/1.1 403 Forbidden
Content-Length: 202

Please note, that mod_security does not correct your application. Here if you only use mod_security, WordPress theme will still be vulnerable on the underlaying level. It is OK to use mod_security, but it is much much more advisable to correct the origin of the problem and not cover it.

I just found two, none of them being really useful:

• forgotten_name: It works, but the bad point is that the inner working is to test the upgrade for ALL packages, which is quite slow…
• tiger: They cheated a little, as they made a “static” file used to compare to a filesystem.

So I decided to make my own. Alas, the people responsible for Debian security
don’t seem to give any easy way to get the DSA in a stable/correct way.

Here are the different possibilities, and why they’re hard/impossible to use:

• There’s a “search engine” that is supposed to allow you to search for CVE entries, but it doesn’t work (has it worked at one time?) and now you only get a message “Debian Search disabled”.
• You can get the “latest” security alerts (DSA) from the Debian security page, even in a RDF format. That would be cool, except:
  • It’s just the 15 or less last alerts
  • The contents are just a title, a link, a two words description and the issued date
• There is the security-announce mailing list. Not really practical.

To correct the problem of the 15 or less entries in the distributed RDF file, I took instead the “year” page which gives exactly the same thing but in HTML. Some regexp, and we get the same result as the RDFs, but with the whole list of DSAs (but still not enough information).

Next, to get the detailed data, that is, the affected packages and the corrected version numbers (the most important things) we need to download the corresponding DSA page. For example, for the DSA 1174, you would get the content of the page http://www.debian.org/security/2006/dsa-1174 .

Here begins the fun. That page doesn’t have a static structure at all! Many inconsistencies are making the parsing of the page unreliable.
For example, let’s just start with the DSA number. For example, for the DSA 1174, you find that on the details page, it’s 1174-1.

Next, you would think that with the use of templates, that page would have some kind of fixed format. Que nenni! The text is not always the same. For example, the text ‘has been fixed in’ isn’t always formatted the same way.

About the affected packages, you have a paragraph named ‘Affected Packages’, which is inconsistent with the really affected packages (never more that one package), which can be found later in the page in ‘Fixed in’.

Redhat is submitting its alerts to OVAL, which uses a really nice format and also gives an interpreter for the language. I saw just one or two messages on the OVAL mailing list about debian :-(