[cod] Hey everyone

Boyd G. Gafford Ph.D. drboyd at westportresearch.com
Fri Feb 24 11:49:19 EST 2012


That would be great if the actual flooders IP was in the attack.  
Unfortunately they are nearly always spoofed and hence any report based 
on them would end up being inaccurate.  Because UDP packets are one-way, 
spoofing the source IP still makes it through routers as most only go 
off the destination IP.

If routers at the starting ISP were to check on the source IP of all 
packets, and not let any packets through that do not match the source 
IPs assigned (static or DHCP), then the ability to UDP flood with a 
spoofed IP would be impossible, and your idea would work.

This may eventually happen some day, but don't expect it anytime soon.

/Boyd/


On 02/24/2012 10:29 AM, escapedturkey wrote:
> Crazy idea and brainstorming: A way to validate the abusive IP, see 
> who owns it (i.e. actual datacenter or ISP), checks the FQDN .. sends 
> a formal complaint style email to abuse@ admin@ with attached sample 
> proofs.
>
> On Fri, Feb 24, 2012 at 11:05 AM, Boyd G. Gafford Ph.D. 
> <drboyd at westportresearch.com <mailto:drboyd at westportresearch.com>> wrote:
>
>     If every Linux server had the iptables getstatus reflection
>     throttle rule, it would be harder to do massive reflection attacks
>     like this.
>
>     Unfortunately, even if every Linux admin did this, there would
>     still be at least 20 servers that don't, and the attackers would
>     just pick the ones that don't to do the attack.
>
>     Such a pain.
>
>     :(
>
>
>     On 02/23/2012 06:15 PM, NewLight Systems wrote:
>>     Yes that's very annoying . The problem is that is very easy to do
>>     a distributed attack with this gameserver's bugs.
>>
>>     And of course, any gameserver is probably on a dedicated line
>>     with 100 or 1000 MBPS bandwidth, so 20 "zombie" gameservers
>>     throwing reflection attacks = 50 MBPS = 1 GBPS of distributed attack.
>>
>>     I don't mind our cpus, are fast, but we are real capped at the
>>     bottleneck that represents 1 GBPS of fast ethernet
>>
>>     El 24/02/12 00:15, Boyd G. Gafford Ph.D. escribió:
>>>     Yep, thats getting towards the saturated side lol.  It must be a
>>>     distributed DOS UDP flood, as I can't imagine many script
>>>     kiddies with that kind of bandwidth for a single attack spoofing
>>>     20 IPs.
>>>
>>>     At that point, a lot of your CPU is just handling the incoming
>>>     IP packets.  Not much to do in that situation.  Even if you
>>>     bonded four GbE's together, you're still looking at needing
>>>     quite a chunk of CPU just to offload throwing away that 1Gbps.
>>>
>>>     Even if you were to dynamically interact with your router to
>>>     tell it to drop the packets, your incoming bandwidth would still
>>>     be hammered.  It almost has to happen at the carrier (preferably
>>>     at the carriers of the flooders) to do anything to help, and we
>>>     all know how likely that is to happen unfortunately.
>>>
>>>     Good luck,
>>>
>>>     /Boyd/
>>>
>>>
>>>     On 02/23/2012 04:46 PM, NewLight Systems wrote:
>>>>     The problem is that we are receiving for example 1 GBPS attacks
>>>>     to one IP from serveral sources ( maybe 15 - 20 ips )
>>>>
>>>>     That means that 1 GB of inbound is occupied. We have iptables
>>>>     rules, of course, but is affecting all services on that
>>>>     dedicated server
>>>>
>>>>     El 23/02/12 23:42, Boyd G. Gafford Ph.D. escribió:
>>>>>     Hey there, thanks for responding.
>>>>>
>>>>>     I'm not sure I understand what you mean by "the line is
>>>>>     occupied anyway."  If you mean the bandwidth to the server is
>>>>>     saturated by the flood, then yeah, its going to affect game
>>>>>     play.  Fortunately most servers at data centers have high
>>>>>     enough bandwidth to them that a typical attack doesn't saturate.
>>>>>
>>>>>     If your game server port is the target of a single IP UDP
>>>>>     flood attack, then typically an iptables drop rule handled by
>>>>>     the kernel is more efficient than the game server itself,
>>>>>     especially if the flooded packets are server commands that are
>>>>>     being processed by the game server, which is sending out UDP
>>>>>     reply packets.  That takes up much more CPU than a
>>>>>     kernel-level packet drop.
>>>>>
>>>>>     Under those circumstances, the cheap VPS we use in Dallas has
>>>>>     endured 64Mbps attacks for hours and the game server is still
>>>>>     very playable.  It would be nice if the flood was blocked at
>>>>>     the router or carrier level, but still iptables is pretty
>>>>>     amazing when the kernel drop is your last line of defense.
>>>>>
>>>>>     Thanks,
>>>>>
>>>>>     /Boyd/
>>>>>
>>>>>
>>>>>     On 02/23/2012 04:22 PM, NewLight Systems wrote:
>>>>>>     It's ok but this isn't working if the UDP floods to your
>>>>>>     server because the line is occupied anyway.
>>>>>>
>>>>>>     If you are the target, there's nothing you can do in a
>>>>>>     dedicated server level.
>>>>>>
>>>>>>     This type of attack ( allways if you are the target ) have to
>>>>>>     be erradicated in a higher level ( router or carrier ) if you
>>>>>>     want to preserve your connection
>>>>>>
>>>>>>     El 23/02/12 23:12, Boyd G. Gafford Ph.D. escribió:
>>>>>>>     Hey everyone, EscapedTurkey told me about this group, and so
>>>>>>>     I Just wanted to say a quick hello.
>>>>>>>
>>>>>>>     I'm the guy who got frustrated enough with UDP flood attacks
>>>>>>>     that I wrote ServerArk to deal with the majority of them. 
>>>>>>>     If anyone has any questions about the program, or any ideas
>>>>>>>     on what they would like to see in it in the future, by all
>>>>>>>     means let me know.
>>>>>>>
>>>>>>>     Since I've been using it on our JA (Q3 protocol) servers
>>>>>>>     (http://elitewarriors.net) its blocked about 20 high volume
>>>>>>>     attacks (one at 64Mbps) successfully over the past few
>>>>>>>     months.  As long as the source IP of the UDP flood is not
>>>>>>>     random, it works really well.
>>>>>>>
>>>>>>>     I have a few new ideas on flood detection on random IP
>>>>>>>     attacks I will ping off your guys over the next few days to
>>>>>>>     see what you think.
>>>>>>>
>>>>>>>     Also kudos to whoever did the "I don't want to participate
>>>>>>>     in reflection attacks" iptables rule that matches off of the
>>>>>>>     'getstatus' UDP packet payload.  If everyone who had a Q3
>>>>>>>     protocol server (COD, JA, etc) had that rule running
>>>>>>>     reflection attacks would be a LOT less potent.
>>>>>>>
>>>>>>>     :)
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>
>>>>>>>     /Boyd/
>>>>>>>
>>>>>>>     /__________________________________
>>>>>>>     Boyd G. Gafford Ph.D.
>>>>>>>     Manager of Software Development
>>>>>>>     Westport Research Associates Inc.
>>>>>>>     7001 Blue Ridge Blvd
>>>>>>>     Raytown, MO 64133
>>>>>>>     (816) 358-8990 <tel:%28816%29%20358-8990>
>>>>>>>     drboyd at westportresearch.com <mailto:drboyd at westportresearch.com>
>>>>>>>     /
>>>>>>>
>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     cod mailing list
>>>>>>>     cod at icculus.org  <mailto:cod at icculus.org>
>>>>>>>     http://icculus.org/mailman/listinfo/cod
>>>>>>
>>>>>>     -- 
>>>>>>
>>>>>>
>>>>>>     *David Aguilar Valero*
>>>>>>
>>>>>>     Dpto. Comercial y Soporte técnico
>>>>>>
>>>>>>     NewLight Systems
>>>>>>
>>>>>>     *Servidores de juegos, HW, Dedicados*
>>>>>>
>>>>>>
>>>>>>     *crk01 at nls.es* <mailto:c>
>>>>>>
>>>>>>     crk01 at newlightsystems.com <mailto:crk01 at newlightsystems.com>
>>>>>>
>>>>>>     tecnico at newlightsystems.com <mailto:tecnico at newlightsystems.com>
>>>>>>
>>>>>>     #NewLight_Systems @ irc-hispano.org <http://irc-hispano.org>
>>>>>>
>>>>>>     *www.newlightsystems.com* <http://www.newlightsystems.com/>
>>>>>>
>>>>>>     *www.nls.es* <http://www.nls.es/>
>>>>>>
>>>>>>     This email and any files or attachments transmitted with it
>>>>>>     are intended solely for the use of the intended recipient.
>>>>>>     This email is confidential and may contain legally privileged
>>>>>>     information. If you are not the intended recipient you should
>>>>>>     not read, disseminate, distribute, or copy this email. If you
>>>>>>     have received this email in error, please notify the sender
>>>>>>     immediately and delete it from your system.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     cod mailing list
>>>>>>     cod at icculus.org  <mailto:cod at icculus.org>
>>>>>>     http://icculus.org/mailman/listinfo/cod
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     cod mailing list
>>>>>     cod at icculus.org  <mailto:cod at icculus.org>
>>>>>     http://icculus.org/mailman/listinfo/cod
>>>>
>>>>     -- 
>>>>
>>>>
>>>>     *David Aguilar Valero*
>>>>
>>>>     Dpto. Comercial y Soporte técnico
>>>>
>>>>     NewLight Systems
>>>>
>>>>     *Servidores de juegos, HW, Dedicados*
>>>>
>>>>
>>>>     *crk01 at nls.es* <mailto:c>
>>>>
>>>>     crk01 at newlightsystems.com <mailto:crk01 at newlightsystems.com>
>>>>
>>>>     tecnico at newlightsystems.com <mailto:tecnico at newlightsystems.com>
>>>>
>>>>     #NewLight_Systems @ irc-hispano.org <http://irc-hispano.org>
>>>>
>>>>     *www.newlightsystems.com* <http://www.newlightsystems.com/>
>>>>
>>>>     *www.nls.es* <http://www.nls.es/>
>>>>
>>>>     This email and any files or attachments transmitted with it are
>>>>     intended solely for the use of the intended recipient. This
>>>>     email is confidential and may contain legally privileged
>>>>     information. If you are not the intended recipient you should
>>>>     not read, disseminate, distribute, or copy this email. If you
>>>>     have received this email in error, please notify the sender
>>>>     immediately and delete it from your system.
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     cod mailing list
>>>>     cod at icculus.org  <mailto:cod at icculus.org>
>>>>     http://icculus.org/mailman/listinfo/cod
>>>
>>>
>>>     _______________________________________________
>>>     cod mailing list
>>>     cod at icculus.org  <mailto:cod at icculus.org>
>>>     http://icculus.org/mailman/listinfo/cod
>>
>>     -- 
>>
>>
>>     *David Aguilar Valero*
>>
>>     Dpto. Comercial y Soporte técnico
>>
>>     NewLight Systems
>>
>>     *Servidores de juegos, HW, Dedicados*
>>
>>
>>     *crk01 at nls.es* <mailto:c>
>>
>>     crk01 at newlightsystems.com <mailto:crk01 at newlightsystems.com>
>>
>>     tecnico at newlightsystems.com <mailto:tecnico at newlightsystems.com>
>>
>>     #NewLight_Systems @ irc-hispano.org <http://irc-hispano.org>
>>
>>     *www.newlightsystems.com* <http://www.newlightsystems.com/>
>>
>>     *www.nls.es* <http://www.nls.es/>
>>
>>     This email and any files or attachments transmitted with it are
>>     intended solely for the use of the intended recipient. This email
>>     is confidential and may contain legally privileged information.
>>     If you are not the intended recipient you should not read,
>>     disseminate, distribute, or copy this email. If you have received
>>     this email in error, please notify the sender immediately and
>>     delete it from your system.
>>
>>
>>
>>     _______________________________________________
>>     cod mailing list
>>     cod at icculus.org  <mailto:cod at icculus.org>
>>     http://icculus.org/mailman/listinfo/cod
>
>     _______________________________________________
>     cod mailing list
>     cod at icculus.org <mailto:cod at icculus.org>
>     http://icculus.org/mailman/listinfo/cod
>
>
>
>
> -- 
> EscapedTurkey.com Billing and Support
> https://www.escapedturkey.com/helpdesk
>
>
>
> _______________________________________________
> cod mailing list
> cod at icculus.org
> http://icculus.org/mailman/listinfo/cod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20120224/bcb561d6/attachment-0001.htm>


More information about the cod mailing list