Hi all,

http://ilikewordpress.com/278/cleani...hacker-attack/
I would like to know whether snort can log such attack.
It seems most of attack of web application are using base64 encode and most of scanner can not detect it. It would be great if snort or any rule set can solve this issue.

Any reply are appreciated.

Thanks,
Frankie

Sure Snort can handle encoding. Just list a Base64 string like 'content:"8FI0MxBcdcOwU0QzEFL0MwBXBDMQWsS2wFIkMxBcdcOgUqQz";' (Netsky: SID 2001283). However the attack isn't in Base64. That's just planted there for decoding Javascript. Look for other entry points. Start with your WP version. IDS deployment comes with a performance penalty. Not all tools suit all situations. Stacking tools covers risks best. So I wonder if Snort on its own would be such a good idea: 0) there must have been a vulnerability in WP or an installation or administration failure to begin with which should have been fixed timely, 1) you could have gotten your "early warning" well in advance by using say Logwatch for reading logs and reporting (it would have shown the probes resulting in 40[0-9]s), 2) the Snort rule sets need tweaking, 3) and Snort is "just" one class of IDS. While not IDS solutions in your case hashing and checking hashes files could show changes ('sha1deep -r /var/www/html'), as could checking your database for '%<(iframe|noscript|display)%', iptables could help limit traffic ('iptables -m recent') and mod_security could help detect other web stack probing and attacks.

1 members found this post helpful.

Thank You for your reply.
However in my case, we have quite a number of web server and each of them has around 300 virtual hosting on it, it is difficult to use sw like tripwire or checksum for the file integrity and file may change often since client may upload some files. Besides wordpress, some of clients are using osc and joolma and client's default behavior is change to 777 permission and it leads many injection or attack on it.
our web server has mod_sec running, however in the base64 decode attack, mod_sec can not detect it.
We are planning to have some IDS to protect our web server, but can snort can detect these attack with random pattern like the above base64 attack?
Do snort has some rule set specially for osc, wp and joolma?
We are also consider for the web application firewall, are there any brand name are reliable?

Thanks,
Frankie

Thanks for pointing that out in your original post...


Make it the responsibility of and mandatory for your clients to deploy and use something along those lines? Like the WP plug-in for checking default installation file hashes there's a similar thing for Joomla.


That means some of your clients lack the knowledge to admin a web stack properly. You'll have to invest time and teach them.


Like I told you before this is not, I repeat NOT, a "base64 attack".


Not that I'm aware of.


I don't know. Best start at http://www.owasp.org/index.php/Web_Application_Firewall.

Is there some way to have your HTTP server evaluate the input URI before it acts on that URI? If you could tell it to always strip out certain characters, like %7B (ASCII for "{"), so that attacks of this nature would fail? Surely there's something in PHP ("HyperText PreProcessor" has to mean something) that would do the job...

I use CSF and mod_security and they work quite well together. Both are extremely configurable, and so far, it's worked very well for us.

Yeah, I second mod_security. It will see and block such activity if that is what you want. Note that mod_security isn't something you can install in one day. It requires some time to set up and tune. It may well block legitimate traffic out-of-the-box, but even IPSs run into this issue.

You can also use Snort inline but I believe mod_security is the better tool. With Snort, it is trivial to customize your own rules to detect this type of traffic (it is easier to create rules in Snort than it is with mod_scurity, IMO).

Ugh.. Tell me about it. I've been running it for about 6 months now, and I still have to go in and fine tune every now and then. Lately, I've been having issues when someone tosses up a new proxy server and doesn't have it playing nicely with the rest of the Internet.