IRC attack on apache

[madan.cpanelnet]

There has been a continuous attack on Apache in cpanel...

The http error logs show attack pattern as follows .....

tail -f /usr/local/apache/logs/error_log


[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK jrtfc\\rUSER csmxaohd
\\"\\" \\"\\" :gpab\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK jjjhnl\\rUSER nlawdw
\\"\\" \\"\\" :kcnt\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK kdumxigr\\rUSER gtqxa
\\"\\" \\"\\" :xvbdxmkn\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK qmpxknxi\\rUSER dnxelvf
\\"\\" \\"\\" :mtccg\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK ualo\\rUSER xnrure
\\"\\" \\"\\" :qcqyu\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK yyhvj\\rUSER hrpjunq
\\"\\" \\"\\" :kryorv\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK qwte\\rUSER hcgrwvt
\\"\\" \\"\\" :popmvl\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK mygfhb\\rUSER putfuil
\\"\\" \\"\\" :rmog\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK gkunh\\rUSER bvvi
\\"\\" \\"\\" :bgbfvms\\r
[Sat Oct 21 17:47:52 2006] [error] [client 219.110.29.162] request failed:
erroneous characters after protocol string: NICK fayhqcdx\\rUSER dyoyyx
\\"\\" \\"\\"



We have added the NICK pattern to modsec rules.. but this doesnot resolve the
issue..



Please advise.

 

[madan.cpanelnet]

can we negotiate it with IPtables?

 

[Messiah]

It looks like they're all coming from one IP, so yeah you should be able to block it with iptables:
iptables -A INPUT -s 219.110.29.162 -j DROP
iptables -A INPUT -d 219.110.29.162 -j DROP

This will block all traffic to and from the offending IP.

 

[mikidouglas]

Irc??

you have mentioned IRC ... try blocking the port for the same??

 

[NightStorm]

Blocking standard IRC ports won't make a difference in this case, mikidouglas. What that log says is that some kiddie with a zombie bot is telling the bot to connect to IRC, but to use port 80 instead of port 6667.
The best thing I can suggest is to do a grep "protocol string: NICK" of your Apache logs, and then go down the list and block the IPs. Between that and the mod_security, it should help to cut it down.
Short of that, though, you would need to develop some sort of filtering script that intercepts the packet before it reaches Apache, and passes it on to your firewall if the pattern matches. In this case, I would look into a Snort custom rule with Snortsam.

 

[madan.cpanelnet]

Thanks to NightStorm in particular.

The attack is distributed and uses various source IP. It connects to port 80 on the server from any source port. The NICK pattern is alreay added to the modsec rule. Although the NICK pattern does show much now.... but still the http processes on the server increases enormously.

[email protected] [/var/cpanel/rvglobalsoft/rvsitebuilder/var]# ps -A | grep httpd | wc -l
45

[email protected] [/var/cpanel/rvglobalsoft/rvsitebuilder/var]# ps -A | grep httpd | wc -l
90

 

[NightStorm]

As I mentioned, try installing Snort and Snortsam, and using this ruleset:

alert tcp $HOME_NET any -> $EXTERNAL_NET !6661:6668 (msg: "BLEEDING-EDGE ATTACK RESPONSE IRC - Nick change on non-std port"; flow: to_server,established; dsize: <64; content:"NICK "; nocase; offset: 0; depth: 5; tag: session,300,seconds; classtype: trojan-activity; sid: 2000345; rev:5; fwsam: src, 5min

I of course invite someone to clean it up, as it's merely the closest rule I can find from Bleeding Edge Rules that would work in this situation. The basic idea is that Snort intercepts the packet before it reaches Apache (or very soon after) and firewalls the source IP for 5 minutes (adjustable through the fwsam tag) preventing further connections from that IP.