If I'm following your statement correctly, I can confirm
the DoS possibility, at least on Firewall-1. Back with 2.0,
I was getting frequent crashes where the firewall was complaining
of being unable to allocate "cookies" and other things (I don't
know exactly what Checkpoint means by cookie in this
contetext, but evidently, I'd run out.)
The symptom was that CPU usage would max out, and I'd have
to reboot the machine to clear the problem. Sometimes the CPU
wpuld be pegged so bad that I'd have to reboot ungracefully, sometimes
corrupting files. The corrupting of files seemed to be the worst
consequence
of this problem. If it was *has* to max out, refusing new connections
is the "correct" way to deal with it, though I'd obviously have liked
to see it be a bit more graceful.
I'm not privy to the internals, but I don't believe this was case
of the state table being corrupt, just full.
The fix was to allocate more memory to the firewall
(fwhmem, whatever part of the firewall that is.)
Recently, I'd wiped my firewall clean, and reloaded the OS. I'd
forgotten to put the fwhmem line back in (it goes in /etc/system on
my SOlaris machine.) I was running FW1 3.0 at this point, and it
ran happily for a few months that way, so I assume Checkpoint
has changed some default allocations, or improved the way they
handle that table, or something.
It was fine, until I ran the ISS security scanner from the inside, to the
outside
of my FW1. That caused the symptoms I'd seen with 2.0. So, I conclude
that enough new connections can still fill up the state table. I've put
the fwhmem parameter back, but haven't retried the ISS scan yet.
Near as I can tell, that san represented 10's of thousands of connections
withing a few minutes.
Again, while I would have like to have seen something more graceful
than screeching to a halt, it didn't appear to have corrupted the state
table, just filled it. I see this as being roughly analogous to the
TCP SYN DoS problem. OS vendors have gotten smarter about
how they deal with that. Presumably, if lots of folks started doing this
type of attack against FW1's, Checkpoint would get smarter about how
they handle it. I've had proxy's behave similar (SOCKS 4) in that the
proxy would stop responding under low memory/underpowered
machine circumstances.
I see the problem of filling SPF state tables up vs. whatever problems
AGs exhibit under extream load as being different, but not neccessarily
worse.
Ryan
StoutW @
pios .
com on 01/09/98 09:59:03 AM
To: Firewalls @
GreatCircle .
COM
cc: (bcc: Ryan Russell/SYBASE)
Subject: RE: RE: Stateful Inspection Anyone? Session limits on
state-tracking systems?
I'd like someone to verify this:
One interesting thing I've noticed is that for a high-session site,
state-based filters have a smaller established session capacity than
services it protects. The memory-resident state-table which maintains
session state can only be so big in stack shims and router-based
state-systems. I would think that disk-based state-table would have a
bit of an impact on performancenwriting/reading to disk for a for every
new packet, not helping the situation. If the webserver (farm) is
serving many established sessions with small packets, the state-based
system appears to become overwhelmed, the packet-filter locks up, and
needs to be hard-booted to recover. Theoretically state-based systems
can be DOS'd by establishing, holding, and queueing up more TCP sessions
to (protected) servers than the state-based system can handle. A proxy
server on the other hand acts like the application it protects, so no
'weirdness' occurs.
Note this is not a bandwidth issue, but an established TCP session
issue.
Bill Stout
|
|
