In some mail from Brain21, sie said:
>
> 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.
Firewall.
> 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?
No, don't look inside the data bit. Just look at the ACK/SEQ numbers.
If you have one packet saying "I haven't sent any more data" after receiving
data and checking with the claimed sender, they you have reason to dump it.
I'd say one negative would be enough to make this decision. How do you know
what the right ACK/SEQ numbers should be ? Keep track of state/connection
flow for a TCP connection (which is what I hear FW-1 does).
This assumes the hijacker is taking over an idle connection or tries to
insert data which doesn't match the current flow.
> > 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 the
> 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
> size, etc.
Right. Now, given the above scenario, you might include a flood of TCP
packets against a single port as part of a detection scheme.
> > 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
> whatever.
This presumes your packet is used instead of the other. ie you want yours
to get their first, so you watch and predict the next data packet size.
Watching isn't enough for this because yours will then always be (unless
the other is dropped) juat another duplicate. I guess you could always
try influence what gets dropped...(see above).
> 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.
Right (which I pointed out earlier).
And of course, now that they've read this discourse, they'll probably all
be modified to work this way RSN (if not already...)
darren
References:
|
|
