On Fri, 29 Dec 1995, Darren Reed wrote:
> The key to doing it this way is caching the TCP packets before passing
> them on. If I cache a TCP datagram, before passing it on, send back some
> sort of ACK and wait twice the average RTT to the other end (caclulated
> during session activity) for a reply, survey all the replies and look for
> one which disagrees with the correctness of the received data, that is
> enough to suggest that I've received "bad data".
Wait. Where are you caching it? If I am on your subnet sniffing all of
your packets, I can see them going out, and I can see the ACKs coming back.
Basically it sounds like you are caching the packets, both the hijacker's
and the real ones, and looking inside the data portion of the packet.
How are you going to make judgements based upon the data to determine
which are "good" and which are "bad" since the headers should be exactly
the same between the two packets. What are you going to look for?
> As the attacker, you might get away with sending the same size as the real
> host is, but your packets are going to arrive later and end up being
> duplicates, even though the data is different, unless the data stream is
> predicable (ie telnet/rlogin, etc).
If you slow down the other machine by flooding the proper port thje
hijacker's packets will get there first. They HAVE to, or it won't
work. If the hijacker's packets get there second, then they will be
thrown away as duplicates. When you are actively sniffing the packets
you can do just as much as the cache in determining things like packet
> > I would really only consider this a partial solution to the problem, and
> > if someone (the attacker) figured out that this is what the progam was
> > doing, they could then easily circumvent that as described above, unless
> > *I* am missing something?
> And they'd circumvent it how ?
Well, if it relies on detecting ACK wars, then you can just send one
packet in the stream with "bad" data. Then only one packet will get
thrown out, and there will not be an ack war to detect. Then all you
need to do is rlogin, or login with the new password that you changed, or
Basically, if this is done well, I don't see how the firewall can
distinguish between the forged and real packets, since they should be
completely identical except for the data, and that can be padded too.