The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

$MyNick

Discussion in 'General Discussion' started by chae, Jan 5, 2007.

  1. chae

    chae Well-Known Member

    Joined:
    Apr 19, 2003
    Messages:
    145
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Auckland, New Zealand
    Our server is currently under a Ddos attack, see extract from apache error logs...

    [Fri Jan 5 01:40:20 2007] [error] server reached MaxClients setting, consider raising the MaxClients setting
    [Fri Jan 5 01:40:24 2007] [error] [client 75.3.137.129] request failed: erroneous characters after protocol string: $MyNick [usa][il]Nashu|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.694ABCABC|
    [Fri Jan 5 01:40:24 2007] [error] [client 75.3.137.129] request failed: erroneous characters after protocol string: $MyNick [usa][il]Nashu|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.694ABCABC|
    [Fri Jan 5 01:40:25 2007] [error] [client 161.184.66.107] request failed: erroneous characters after protocol string: $MyNick [RO][RDS]pixmap|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.698ABCABC|
    [Fri Jan 5 01:40:40 2007] [error] [client 80.178.8.206] request failed: erroneous characters after protocol string: $MyNick stip|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.674ABCABC|
    [Fri Jan 5 01:41:15 2007] [error] [client 86.35.212.137] request failed: erroneous characters after protocol string: $MyNick [RO][BC][ADSL]PETRICA|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.674ABCABC|
    [Fri Jan 5 01:43:12 2007] [error] [client 84.2.168.2] request failed: erroneous characters after protocol string: $MyNick [HUN]robi7777|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.698ABCABC|
    [Fri Jan 5 01:43:12 2007] [error] [client 84.2.168.2] request failed: erroneous characters after protocol string: $MyNick [HUN]robi7777|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.698ABCABC|
    [Fri Jan 5 01:43:13 2007] [error] [client 89.36.80.66] request failed: erroneous characters after protocol string: $MyNick [-CooL-]SHOBY|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.668ABCABC|
    [Fri Jan 5 01:43:14 2007] [error] [client 68.228.209.83] request failed: erroneous characters after protocol string: $MyNick stefano7|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.306ABCABC|
    [Fri Jan 5 01:43:15 2007] [error] [client 86.106.118.146] request failed: erroneous characters after protocol string: $MyNick [RO](A-computers)ZuZu|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.306ABCABC|

    Done a search high & low for this, had the same thing happen way back in April but it stopped as soon as it started. Anyway we've had no appache now for nearly 7 hours, our DC support said there's nothing they can do but null route the servers IP...which was a no go as about 250 sites use it. They said they'll pass the ticket onto Network guys to see if they can filter traffic but still waiting...

    Had one lad [R1CH] come back with this solution...

    ======================================
    In case you didn't know, the protocol you are being hit with is Direct Connect. DC is a file sharing system that uses a central hub, if a hub is full or if an admin wishes, he can redirect users to a iport of his choosing. Perhaps for some reason your web server has been on the receiving side of such a redirect. Naturally the clients auto-reconnect if they are unable to connect the first time...

    To filter this is tricky, it likely can't be done in Apache since it isn't a valid HTTP request so the modules like mod_security never get called. My (horrible) suggestion would be to use the netfilter "string" module and firewall any packets to port 80 with a size less than x bytes (x being the biggest packet you've seen which contains the DC login string) that contain "$MyNick". Use a -j REJECT --reject-with tcp-reset to reset the connection so it isn't hogging resources.

    Untested:
    iptables -A INPUT -p tcp --dport 80 -m length --length 0:x -m string --string '$MyNick' -j REJECT --reject-with tcp-reset

    Unfortunately, the string module isn't a common module and isn't built by default. It may only be available in very recent kernel versions too.
    ======================================

    Our servers running Centos 4 with the latest datacenters kernel

    How can I find the size of packets being used, currently I'm looking at apache error logs ???

    Untested:
    iptables -A INPUT -p tcp --dport 80 -m length --length 0:x -m string --string '$MyNick' -j REJECT --reject-with tcp-reset

    0:x <--- packet size going in there correct ?

    Tried also cranking up the MaxClients figure in apache conf but all that did was knock the load up to the 400+ mark (aaahhhh) so have put that back to normal settings as it didn't really help. The servers got dos deflate & mod_evasive plus I added in a secfilter rule in mod_security for $MyNick but as R1CH mentioned it would work anyway.

    Can anyone shed some light on how to stop this attack & get apache back up again, hopefully I'll get a solution here before my DC techos get back to me.

    Thanks in advance

    Chae
     
  2. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    There's probably very little you can do. If the DC doesn't have the hardware to filter out this type of attack then you're going to have to either switch your IP's as they null route your existing ones, or if it's an attack against a particular domain, switch it to some other IP in DNS and have that null routed and hope the attack against it goes away.
     
  3. chae

    chae Well-Known Member

    Joined:
    Apr 19, 2003
    Messages:
    145
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Auckland, New Zealand
    Hi Yah Chirpy,

    That's exactly what we ended up doing, problem was initially we only knew what IP was being hammered, this was a resellers shared IP. Luckily they only had about a dozen sites, switched them all onto dedicated IP's then we could pin-point which site was being attacked, then null routed the IP.

    Ended up we didn't have the ip module built into our kernel, DC were going to recompile kernel with it but said it wouldn't be supported & it'd cost us to get it all done. So went the easy way & null routed ;)

    Thanks for the reply
     

Share This Page