> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 6 June 2000 11:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Re(2): Re(2): Firewall
>
[snip]
>
> My point was that you can "imitate" a stateful filter by specifying
> flags. Stateful filtering right in the code makes life a bit easier.
> Instead of specifying answers to former connections, you can just
> specify that the ACK bit is set. And voila, you've got a "stateful"
> firewall. You can still specify ports and such. It's just that the
> stateful-ness is being done manually, instead of automagically.
No, that's not right at all. Maybe if I explain it a little differently. The
"stateful" bit of a stateful filter means it keeps state (no I'm not trying
to be facetious). What _that_ means is that somewhere inside the brain of
the filter it has a little table (aka state table) of all the connections
that are currently established through the firewall - it's like a phone
switchboard knowing what lines are busy.
If you don't have one of these state tables you just don't have a stateful
filter. The state table is the prior knowledge that the filter needs to make
smarter decisions about what to permit and what to deny.
Just keeping an eye on TCP flags doesn't require any state at all - you
don't need any prior knowledge to work out whether to permit a new packet
because all you need to check is that it has the right flags set.
Where a stateful filter will beat out a static filter is in the granularity
of control it can apply to TCP and also the fact that it can mimic some sort
of stateful control over stateless protocols like ICMP UDP etc (yes, this is
what several people have said). Example - a stateful filter can enforce
sequence numbers, source and destination port on both ends, RFC behaviour
for session establishment and teardown etc. This is very hard to do with
static rules.
> > I think, session hijacking is also a bit more difficult
> through a stateful
> > packet filter, but I'm not sure about that.
>
> Again, I'm not too clear on session hijacking, but from all the
> theories behind it, I'd say not. All you're doing is sending a few
> messages to redirect the source or dest IP (whichever you're taking
> over). You don't interrupt the protocol flow. Yes, there is
> a problem
> sending the redirects if a MASQ'ed firewall is being used, but you can
> do it without a problem if you've got a copy of an original packet.
That's not exactly right either. You can't hijack a session with redirects
(I assume you mean ICMP). The "normal" way is to keep an eye on the traffic,
then you do this:
1. Knock one of the hosts out of the conversation - flood it, DoS it, crash
it, whatever.
2. Impersonate this host (victim) to the other host (target)- spoof victim's
IP address and step into the existing session with an ACK packet to target
with all the correct sequence numbers etc.
3. Target will now continue the conversation with you. Odds are that you'll
need to keep sniffing the traffic because your layer 2 address won't be
correct (to get sent the packet at layer 2) unless you do something tricky
in between.
Session hijacking isn't much harder through a stateful filter though -
that's because to hijack a session you need to emulate all the state to
trick the remote TCP stack.
Cheers,
--
Ben Nagy
Network Consultant, Volante IT
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
