Re: DefCon CTF

[Trygve Aasheim <trygve () pogostick net>]

What type of firewall are they running at defcon CTF if the state table 
overflows based on what was in the packets? A state table only keeps 
track of "state" for a session...being SYN, SYN-ACK, ESTABLISHED, 
FIN-ACK etc, and will drop traffic if they are out of state...

If somebody is sending shell code and binary rubbish to a service over a 
session, it shouldn't change the state table in any way...

If there where no services on these ports, and the firewall policy 
reflected this - the sessions wouldn't even enter the state table.

Firewalls usually have issues with small packets (that's why vendors 
don't use the RFC for performance testing (and even pays magazines so 
they don't use it either), but send one insanely long ftp stream through 
they're one-rule-policy-firewall and claim gbit performance), but it has 
nothing to do with the state table.

Logging, packet capture and routing might also decrease the performance 
of a firewall.

On VMs you have a totally new game when it comes to network performance 
though. Trying to do packet capture, run firewalls and such together 
with tons of sessions on virtual machines/interfaces often results in 
strange behavior if the VM is on a host OS and not a hypervisor.




Holt Sorenson wrote:
> On Fri, Aug 15, 2008 at 01:48:16PM -0700, Doc Brown wrote:
> > As for "network problems", I would suspect some of it was teams' firewalls
> > blocking detected attacks, some of it was VM load from all the forking
> > services, some of it was network load.  While key refresh happened every
> > 5-7 minutes, many teams attacked over and over instead of waiting 3
> > minutes or so between attempts.
>
> There was seemingly constant spew to ports 22 and 25 throughout much of
> the game that looked like someone was dumping binary detrititus
> intermixed with shell code (somebody playing with fuzzers?) that I
> talked to Ken Shoto about several times.
>
> Stuff like that doesn't do anything for the game (since all the
> interesting services run on other ports anyway) and seemed to be
> contributing to the state table overflowing in the game firewall.
>
> This was why during the post game debrief meeting that I made the
> point that activity like this is counterproductive and isn't
> going to move your team forward during the game.
>
> Couple this with the factors you cite above and it made for a pretty
> shitty network experience during the game at times.
>
> Hopefully teams in the future are more surgical.
>
> DefCon CTF isn't about carpet bombing, it's about laser guided
> munitions.
>
> (and Doc, I know you're the part of the choir on this too, but I
> needed to rant a bit).
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave