Patrick Darden wrote:
>
> Ben, we disagree on our definition of stateful. RACLs do not store
> session information (e.g. tcp sequence numbers),
If this was true than most stateful packet filters would not be. Just
did a dump on FW-1 & iptables, don't see sequence numbers stored in
either.
> they are easily spoofed (e.g. using nscan syn/ack sets
Not true. In order to get by source IP & port as well as destination IP
& port has to match. Just playing with the flags will not do it. I'm not
a betting man, but I would "guess" that the odds of an outside attacker
correctly guessing all of this info _as well as_ hitting the window when
its open would be astronomical.
Are you thinking of static filtering? This can be fooled by nmap ACKs.
Stateful can not.
> Your definition of stateful is nifty, and I can dig it. However, I
> don't believe it is a commonly accepted industry standard.
<SMILE> No comments here. ;)
> Each time a TCP connection is established from an inside host accessing
> the Internet through the... Firewall, the information about the connection
> is logged in a stateful session flow table. The table contains the source
> and destination addresses, port numbers, TCP sequencing information, and
> additional flags for each TCP connection associated with that particular
> host.
Humm, so what does storing sequence numbers get you besides higher CPU
and memory utilization? If I've sniffed the wire to figure out ports &
IPs, I get sequence numbers as well. IMHO your taking a big performance
hit for a marginal increase in difficulty to pull off the hack.
> ACK bits are too easily spoofed to be relied upon. That is why RACLs was
> a first attempt that Cisco advises not using, except in cases that CBAC
> will not work and a PIX is unacceptable.
Interesting. I've had more than one Cisco engineer tell me I'm better
off with reflexive filtering than CBAC because the performance
difference. Guess it depends on whether your talking to sales or an
engineer. ;)
> However, although I agree with the KISS sentiment, your implication that
> CBAC is more complex than RACL is incorrect.
Have to disagree here as well. I know both and reflexive is far easier,
especially if your are teaching someone that already understands
extended ACLs.
> CBAC is simple, easily
> implemented, very well documented, and secures very well. On the other
> hand, it is very very limited, non-extensible, and power-hungry.
This is what has killed it for many of my clients. Reflexive is built
into the core OS so its a freebie. If I'm going to spend money on CBAC
and will probably spend more on the router for memory & CPU to deal with
it, why not just go with a Pix or FW-1? The delta is relatively small,
especially when you consider the difference in usability.
Cheers,
Chris
--
**************************************
[EMAIL PROTECTED]
* Mastering Cisco Routers
http://www.amazon.com/exec/obidos/ASIN/078212643X/
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
