|
I placed a packet capture on a particular interface of an ASA firewall with a view to establishing what a device connected to that interface was trying to do and hence what ACL I needed on the interface. Below is an extract from the packet capture, filtered on both source and destination address (anonymised). From what I know about this particular application I believe the device on 10.0.0.1 is trying to initiate a connection to 172.16.0.1 but I am not seeing any SYN packets, only ACK. Can anyone explain why I might not be seeing any SYN packets? 10 0.000351 10.0.0.1 172.16.0.1 TCP 58 64456 → 22 [ACK] Seq=1 Ack=1 Win=65535 Len=0 11 0.000366 10.0.0.1 172.16.0.1 TCP 58 64456 → 22 [ACK] Seq=1 Ack=2721 Win=65535 Len=0 14 0.000611 10.0.0.1 172.16.0.1 TCP 58 64456 → 22 [ACK] Seq=1 Ack=5317 Win=65535 Len=0 27 0.003830 10.0.0.1 172.16.0.1 TCP 58 64456 → 22 [ACK] Seq=1 Ack=8037 Win=65535 Len=0 113 0.013519 10.0.0.1 172.16.0.1 SSH 110 Client: Encrypted packet (len=52) 120 0.229191 10.0.0.1 172.16.0.1 TCP 58 64456 → 22 [ACK] Seq=53 Ack=46581 Win=64823 Len=0 227 4.635380 10.0.0.1 172.16.0.1 SSH 174 Client: Encrypted packet (len=116) 234 4.862343 10.0.0.1 172.16.0.1 TCP 58 64456 → 22 [ACK] Seq=169 Ack=46665 Win=64739 Len=0 931 35.263399 10.0.0.1 172.16.0.1 SSH 262 Client: Encrypted packet (len=204) 932 35.263826 10.0.0.1 172.16.0.1 TCP 58 64456 → 22 [FIN, ACK] Seq=373 Ack=46665 Win=64739 Len=0 2229 94.854500 10.0.0.1 172.16.0.1 TCP 58 64456 → 22 [ACK] Seq=374 Ack=46666 Win=64739 Len=0 Thanks, Phil. |
|
Don't let the fact that seq and ack numbers start from 1 mislead you. Unless you explicitly tell it not to do so, tshark (and Wireshark as well) shows relative values, and takes the values in the very first packet of each tcp session it can see as references, hence the relative values shown for them are 1. However, the first packet seen in the capture may not be the first packet in the session. So unless you are really, really, really sure that the session you've shown here has started later than the capture itself, the simplest explanation is that the session had already been established when you started to capture. Thanks for your response Sindy. So, from the output above, without seeing any SYN packets, is it possible to say for certain that connections are being initiated from 10.0.0.1?
(18 May '16, 07:24)
phil6564
Well, nothing is really certain, but as tcp/22 is a "well-known" port at which the ssh service is listening on servers, while tcp/64456 is a typical client-side ephemeral port (which the client's TCP stack chooses when initiating sessions), and as the contents of those packets seems to make sense to the SSH dissector which tshark has chosen to dissect them based on the use of the tcp/22 port, we can assume that the session has really been initiated by 10.0.0.1 quite safely. What would bother me as a network administrator would be why I can see only packets in one direction. If it is due to your use of capture filter or display filter which hides the other direction from being seen, or due to mirroring of only one direction of a switch port, allright; otherwise (i.e. if no packets are filtered out intentionally), I'd assume that the other direction bypasses the interface at which you capture, which could affect the ability of the ASA to handle the traffic properly.
(18 May '16, 07:40)
sindy
|
