Dailydave mailing list archives
Re: DefCon CTF
From: Holt Sorenson <hso () nosneros net>
Date: Sun, 17 Aug 2008 00:54:16 +0000
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
Current thread:
- Re: DefCon CTF, (continued)
- Re: DefCon CTF Red Dragon (Aug 15)
- Re: DefCon CTF Chris Eagle (Aug 15)
- Re: DefCon CTF jesse michael (Aug 15)
- Re: DefCon CTF Doc Brown (Aug 15)
- Re: DefCon CTF Jason Lewis (Aug 16)
- Re: DefCon CTF Doc Brown (Aug 15)
- Re: DefCon CTF Holt Sorenson (Aug 16)
- Re: DefCon CTF Chris Eagle (Aug 16)
- Re: DefCon CTF Trygve Aasheim (Aug 16)
- Re: DefCon CTF Holt Sorenson (Aug 16)