What I told about the sequence number stuff was partially true read these 3 links and you will get a bit more info about it
http://www.camtp.uni-mb.si/books/Internet-Book/TCP_ISN.html http://www.camtp.uni-mb.si/books/Internet-Book/TCP_SEQPrediction.html http://www.networkcomputing.com/unixworld/security/001.txt.html So... there is a possibility to inject fake packets on established connections through a firewall 1 firewall. But then it depends on the machine at the end of the connection if it accepts 2 ISN numbers that he doesnt know of because in each TCP connection the return or the source is a new ISN number.. So you need to guess the new source ISN number to be able to hijack the connection. And if you have a machine that does more random ISN number generation it will be a bit hard to hijack a connection. It means that the source IP address will give a new ISN each time he sends a packet to the destination IP address. The destination will reply the packet with its own NEW ISN in the source and as destination the previous ISN (from the source) with +1. So there was a little BS on my part about the ISN stuff Regards, Brenno > -----Original Message----- > From: Hiemstra, Brenno > Sent: vrijdag 1 februari 2002 16:59 > To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] > Subject: RE: Statefull failover in High Availabilty /clustering > firewalls > > Erik, > > <..snip..> > If you have a firewall product that tracks continuous session > information like Sequence numbers, on a heavily loaded FW doesn't > the > synchronization of the session table to the standby machine cause > considerable performance issues? > <..snip..> > > First... If you have a heavily loaded firewall its time to upgrade or > do some bandwidth management on your network to make the firewall > less heavy loaded. > > <..snip..> > That is, tracking every state of every > packet for 200,000 sessions and pushing it to a standby machine and > expecting it flawlessly transition during a failover seems a bit > overwhelming for a FW to handle. > <..snip..> > > Firewall 1 doesnt sync state with every packet... You set up a tcp (or > udp) > connection from one point to the other. This connection (source > ip + source port <-> destination ip + destination port) is entered > into the "state tabel" of firewall... all the packets in "this" > connection > doesnt need to be keep stated because its already in the "state table" > and doesnt need to be synchronised with the other member. > > The firewall needs to see that there is a FIN or RST packet that ends > the session and the session is then out of the "state table" of firewall > 1. > This is then also synchronised with the other cluster members. > > Basically what needs to be synchronised is new established connections > and ended synchronisations... current synchronisations are still there > so they dont need to be removed from the "state table". > > <..snip..> > Also, if the HA solution does keep state, but not of the sequence > numbers, isn't the risk of session hijacking greater? > <..snip..> > > If a firewall keeps state on sequence numbers you can still hijack > a connection. Most of the established connections the sequence > number will be +1 of the previous sessions (if I have understand this > correctly). So, in theory, you can hijack every session > > The point is when you want to hijack a starting session you need > to guess the beginning sequence number... Thats why you need > fully random sequence numbers in your OS to prevent sequence > numbers guessing and therefor also session hijacking > > But this is what I think about it... maybe someone can shed a light > on the whole session hijacking and sequence numbers subject. > > <..snip..> > Are there any FWs out there that can keep session and track Sequence > and > securely transition? > <..snip..> > > As far as I know, IPFilter, PF and netfilter / iptables can handle the > sequence number tracking. I know that Checkpoint firewall 1 doesnt > keep state on sequence numbers. So in theory you could inject, > on established connections, fake ACK packets with a totally different > sequence number and have it accepted by the firewall. Of course the > source IP address + port and destination IP address+ port need to be > in the "state table" of FW1. > > I hope you now know a little bit more... Pretty interesting subject > if you think about it.... > > And I hope I am not talking BS either :o) > > Regards, > > > Brenno > > _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
