[cod] Hey everyone

Fri Feb 24 14:34:21 EST 2012

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
>