DOS vs. SPI

I'm currently studying how our hardware firewall works as I write this, and in doing so just got introduced to the concept of stateful packet inspection (SPI), which is the method our firewall uses. From what I understand, SPI prevents DOS attacks by inspecting packets and dropping packets that result from multiple pings from the same location.

So, my question is this: Is there a way an attacker could get around our SPI to successfully launch a DOS against us? At first glance, it wouldn't seem so since the packets would be dropped, but there's almost a way around everything. Perhaps an attacker could succeed using multiple zombies so that packets wouldn't come from the same location and thus not be dropped?

dropped or not they're still traffic on the pipe. you get enough of them and your going to be deprived of service. not as easiely as hogging the server's resources but a DoS just the same

Angelic:

There are two type of DoS. There's the kind that confuse, crash or overwhelm the target with packets that are malformed or conatin data/instructions designed to do that and the kind where you "fill the pipe" with so much traffic that nothing valuable can occur until the "flood" has stopped.

The first can be stopped by patches or systems that recognize the attempt and intercept the traffic or by sgutting down the affected service thus allowing other services to continue. The second type you are helpless to prevent. You need, at a minimum your ISP to drop the packets if he can. If not, grab a beer and hope they give up before you have to drive home.... ;)

SPI will not stop a D0S attack unless the packets do not appear to be part of an established session. SPI checks to make sure that a packet coming inbound is a valid part of an ongoing conversation that began on the inside. What you are talking about is thresholding where a firewall is intructed that should it see too many packets of the same type in a given time period it is to drop all packets regardless since it is likely those packets are part of a DoS. That's fine if the packets are designed to max out the TCB's, (Transmission Control Blocks), created after an initial SYN arrives at a service you provide and deny service that way but if they are part of a flood type DoS that fills the pipe then you are still up the river without the proverbial paddle because the traffic in your pipe is blocking valid requests anyway so the firewall dropping the invalid ones is of no help.

Yeah, the packets that were dropped were still analyzed (though not that thoroughly in only a network-layer firewall) and still required resources to be spent. You get a big enough flood of rapid traffic and the router will cease to allow you any further service as it will be saturated with packets (dropping them, analyzing them, etc.) and since this is your default gateway to the internet -your border router to the core router (backbone ISP traffic), you won't have any access to the outside WAN until it subsides. The internal LAN would be jumbled from this as well. Depending on the router, it's acl's, total amt. of memory, cpu, resources spent and the overall flood and size of the traffic. There's many variables in this. The attack type.. as tiger was talking about would play a role too. Whether it's syn flooding, udp/icmp flooding etc etc.

Common DoS attacks normally aren't a problem for routers to deal with but the minute that DoS attack becomes distributed (DDoS) then you might have a problem depending again on all of those variables mentioned above including how many zombies are being used in the attack and their connection's throughput. Things like threshold, rate-limiting, and other measures are good to have in a firewall. I'll give you some good links to check out... you'll know more than enough about both application-layer firewalls and network-layer firewalls (even transport-layer aka circuit-layer gateways) by the time you're done reading them.

http://secinf.net/info/fw/firewall.htm

http://www.faqs.org/faqs/firewalls-faq/

Great! Thanks for all the input guys. I'm soakin' it all in.

Ok, new question -- It's unrelated to SPI, but I didn't think it was big enough a question to merit starting a new thread on it, and it is a factor of the same firewall in question.

My firewall can have SNMP enabled on it so that it reports to an administrative group trap messages. So, everything I just said in that last sentence is entirely greek to me. :)

To get started, I read this tutorial on SNMP to get myself acquainted with it:
http://www2.rad.com/networks/1995/snmp/snmp.htm

So, it's a management information protocol. Got that. But it looks like this is something you need special software for in order to impliment. Is that correct? I suppose I can't just enable SNMP reporting on the firewall and reap its benefits then. Is this a situation where'd you'd have an SNMP server managing SNMP clients?

Also, can someone elaborate on what trap messages are exactly?

You need a software (designed for that) to receive traps.
Trap is a "trap". :P
When you are configuring snmp traps, you define what parameters / conditions should be matched to "activate" the trap.
When that combination occur, a (snmp) trap occurs and a message is sent to to machine that you have configured to receive the trap. Just that.
I personally dont like snmp traps on FW. I dont even like snmp installed or enable on a FW.
I prefer instead to use FW capability to syslog to other computer. And on that computer i can do whatever i want with FW messages.

BTW just for adding something about statefull inspection:
Statefull inspection
PRO: allow you to do a deeper analysis since it can track sessions and correlate packets between sessions (such FTP-CONTROL and FTP-DATA)
CON: it is slower that normal one
Packet filter (without Statefull inspection)
PRO: Very fast
CON: hard to track correlate packets