[cod] Hey everyone

Fri Feb 24 15:23:30 EST 2012

It varies.  For most of the attacks I've seen in the past few months, 
its been from valid IP's that are spoofed, and not bogons.  A smaller 
percentage were attacks with a random rolling IP address, where the IP 
changed every packet, and they rolled through the non-bogons.

On 02/24/2012 01:34 PM, Robert Mount wrote:
> When they spoof, are they using bogus (random) IPs, or are they using
> a target as the source (bounce attack)?
>
> Make sure you're all Bogon filtering, may help with the bogus case:
> http://www.team-cymru.org/Services/Bogons/
>
> DShield is another good one: http://feeds.dshield.org/block.txt
>
> --Rob
>
> On Fri, Feb 24, 2012 at 11:49 AM, Boyd G. Gafford Ph.D.
> <drboyd at westportresearch.com>  wrote:
>> 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>  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
>>> drboyd at westportresearch.com
>>>
>>>
>>>
>>> _______________________________________________
>>> cod mailing list
>>> 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
>>>
>>> crk01 at newlightsystems.com
>>>
>>> tecnico at newlightsystems.com
>>>
>>> #NewLight_Systems @ irc-hispano.org
>>>
>>> www.newlightsystems.com
>>>
>>> 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
>>> http://icculus.org/mailman/listinfo/cod
>>>
>>>
>>>
>>> _______________________________________________
>>> cod mailing list
>>> 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
>>>
>>> crk01 at newlightsystems.com
>>>
>>> tecnico at newlightsystems.com
>>>
>>> #NewLight_Systems @ irc-hispano.org
>>>
>>> www.newlightsystems.com
>>>
>>> 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
>>> http://icculus.org/mailman/listinfo/cod
>>>
>>>
>>>
>>> _______________________________________________
>>> cod mailing list
>>> 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
>>>
>>> crk01 at newlightsystems.com
>>>
>>> tecnico at newlightsystems.com
>>>
>>> #NewLight_Systems @ irc-hispano.org
>>>
>>> www.newlightsystems.com
>>>
>>> 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
>>> http://icculus.org/mailman/listinfo/cod
>>>
>>>
>>> _______________________________________________
>>> cod mailing list
>>> 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
>>
>>
>> _______________________________________________
>> cod mailing list
>> cod at icculus.org
>> http://icculus.org/mailman/listinfo/cod
>>
> _______________________________________________
> cod mailing list
> cod at icculus.org
> http://icculus.org/mailman/listinfo/cod
>