BIONDI Philippe wrote:
>
> You should give more pieces of information to have precise scenario :
> Where are you sniffing this ? (ie on the LAN of A? near a router, from the
> side of A ? Are the TCP ports always the same ?)
>
> In the first case, it could be a deficient link, a packet dropped by B or
> by a firewall before B (with a rule like ipchain DENY one), or maybe a
> scanport on a machine that DENY a lot of ports ?
>
> The second case could be a scanport on B, or a deficient link, or a router
> on the path with a bad return route (in this case, you are on B side).
>
> Anyway, all these sequences are aborted TCP sequences. They should always
> terminate with a TCP_FIN sequence or a TCP_RST packet.
>
> You can look at the RFC for documentation. There is a very clear
> finite state automaton.
>
> Phil
Hi Philippe,
Thanks for your assistance.
Although it's difficult for me to know the physical configuration I
think I'm sniffing this data on the LAN of A just before a router to a
main network.
For the 1st case the source IP,source port, destination IP and
destination port are the same for all 4 SYNS.
For the 2nd case the IP addresses and ports are the same (i.e. a two-way
communication has been established).
Just to clarify things,
- In the first case - if a firewall was so configured then would it
only DROP the SYN packets and not send ANY kind of TCP response (i.e.
not even a RST?)?
- I don't believe a firewall is responsible for the second case as:
(i) Why should a SYN_ACK be sent back in response?
(ii) Because the ACK (3-way connection establishment) is from the same
HOST as the SYN and we saw the SYN then we SHOULD see the ACK (if it was
sent). The only
conclusion would seem to be that the ACK isn't sent. This would violate
RFC793 and so we can only assume that the application which originated
the SYN doesn't really want to establish a valid two-way communication.
- Over the duration of 15 mins I recorded lots of the 1st and 2nd case
type flows. Neither of them were terminated by RST or 4-way handshake
FIN/ACK sequences - which for the second caseleads me to point the
finger at IP Spoofing by a source who doesn't care about terminating the
connection properly - what do you think?
--
Al Milne
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
