Re: Firewalls that generate new packets..

["Darden, Patrick S." <darden () armc org>]

Hey Darren,

A few of my emails didn't make it to the list.  The below
missive doesn't make much sense since it references
"all the reasons I have outlined before".

Here is most relevant missing email:

It depends on the MITM exploit.  If you just want to monitor
a stream of traffic, then you are correct.  If, however, you
want to hijack the conversation it can be more difficult:

To quote from the certiguide site (very well written
imho) http://www.certiguide.com/secplus/cg_sp_144ManintheMiddle.htm

"Second, an attacker has TCP Sequence numbers to contend with. In a 
nutshell, every TCP/IP connection negotiates a TCP Sequence between 
both hosts. Subsequently, every TCP packet sent between them has a 
TCP Sequence number included in the packet header. This number is 
changed for every packet by a prearranged formula, decided on during the TCP handshake stage.

This allows both hosts to ensure they are receiving all the packets 
in a TCP conversation, and to ensure that the packets are being 
assembled in the correct order. In other words, the TCP Sequence 
number is responsible for the quality control of the protocol. If 
the sequence number of a packet is wildly out of sequence or just 
plain wrong, the packet is discarded (with a few additional 
checks). If an attacker is unable to break the TCP Sequence formula, 
they won't be able to initiate an MITM attack. Tools such as Nmap75,
 mentioned earlier, have options to check the TCP Sequence formula 
of the IP stack on a machine and inform you how difficult it would 
be to "break" it. This particular attack strategy is called TCP 
Sequence Prediction, and crackers have access to tools that do it, 
so the stronger your TCP/IP implementation in this regard, the better."

SANS and Neohapsis also have materials covering tcp sequence 
prediction, and its role in foiling hackers.

--Patrick Darden


Marcus J. Ranum

Don't any and all MITM attacks work successfully against
any unencrypted (and even a few encrypted) streams?
I didn't even mention MITM because they're pretty much
shooting fish in a barrel.







-----Original Message-----
From: firewall-wizards-bounces () listserv icsalabs com
[mailto:firewall-wizards-bounces () listserv icsalabs com]On Behalf Of
Darren Reed
Sent: Wednesday, November 28, 2007 2:17 PM
To: Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Firewalls that generate new packets..


Darden, Patrick S. wrote:
> Marcus J. Ranum
> ...
> > The hard thing I had to wrap my brain around was the
> > observation that between a router+ACLs combined
> > with the state that is held in the TCP stack of the
> > target, you've got exactly the same thing (and often
> > quite a bit better!) than a "stateful" firewall.
> >     
>
> I respecfully disagree for all the reasons I have outlined
> before....  Sum: tcp sequence #s make a difference.
>   

So long as you mean "tcp sequence#s" to mean modelling the entire
TCP connection state, yes.  The implication that you're missing is that
the TCP window also needs to be tracked (including whether or not
window scaling is being used), along with which flags appeared at
which sequence numbers so you know what to expect next.  e.g
the SYN and FIN flags impact sequence numbers without there being
an explicit change in the headers.

If you go to the extreme of only allowing in sequence TCP packets
and ensure that retransmitted data is always the same as the original,
you could argue that the "stateful inspection" mode here becomes a
layer 5 firewall rather than layer 3 or 4.  And that's without a proxy :)

Darren

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards