madan.cpanelnet

Well-Known Member
Apr 1, 2006
69
0
156
INDIA
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.
 

Messiah

Member
PartnerNOC
Jul 5, 2006
22
0
151
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.
 

NightStorm

Well-Known Member
Jul 28, 2003
286
4
168
cPanel Access Level
Root Administrator
Twitter
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

Well-Known Member
Apr 1, 2006
69
0
156
INDIA
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

Well-Known Member
Jul 28, 2003
286
4
168
cPanel Access Level
Root Administrator
Twitter
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.