Re: DefCon CTF

[Holt Sorenson <hso () nosneros net>]

On Sat, Aug 16, 2008 at 08:21:23PM +0200, Trygve Aasheim wrote:
> 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...

Dunno. Since FreeBSD users can choose from ipfilter, pf, or ipfirewall
KenShoto has several options available. Also, they've got coding skillz
and could have extended the code base of any of these to suit their
needs.

There was a point at which they said that they had to restart the
firewall because it was no longer properly forwarding traffic.
When it came back up, it immediately jumped to ~10k connections
that it was trying to handle and it began having problems forwarding
packets again. They told the team captains that if this continued
that they would track down the offender and deal with the team that
was causing the problems.

> 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...

Sure, for established sessions. If you're rapidly starting new sessions,
then...

Also, they use NAT to make it difficult to track back to a source so that
you couldn't block attacking team packets and only allow packets from the
scoring server that are part of a connection that is going to check SLA.

I was not specifically referring to "state" in the strict sense where a
firewall tracks transitions in a protocol like TCP using a set of code
such as a state machine, but in the general sense that includes
sessions/flows, NAT state, routing state, etc. Apologies for overloading
terms and not being more lucid in the previous post.

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

Postfix was running on port 25 and sshd was running on port 22.

> Firewalls usually have issues with small packets (that's why vendors 

Yep. I can't speak for what work the firewall was having to do to
connections before it was NAT'd coming towards our system (read: jail)
as I did not have visibility into the side of the firewall where these
connections were initiated. Given the plethora of tools available for
causing all sorts of mischief that persons could have used while at CTF
and given that there are more than one or two people at CTF that have
the capability to be creative and channel that creativity into building
network tools, it's anybody's guess what the initiated traffic looked
like before the firewall transformed it and forwarded it on to
destination hosts.

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

Agreed.

> 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.

FreeBSD jails with assumed unknown customizations are used. There is
a lot being asked of the OS and the hardware it's running on.

For obvious reasons, KenShoto is terse about the details of what they've
built to run the game.

-- 
Holt Sorenson
hso () nosneros net
www.nosneros.net/hso

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave