6

I need support understanding these 4 lines. looks like tcp dump but im actully not understanding what exactly is happening here.

13:13:22.407445 IP 192.168.246.128.54955 > 192.168.246.13.80: S 2910497703:2910497703(0) win 5840 <mss 1460,sackok,timestamp="" 518611="" 0,nop,wscale="" 6="">
13:13:22.407560 IP 192.168.246.13.80 > 192.168.246.128.54955: S 3762608065:3762608065(0) ack 2910497704 win 64240 <mss 1460,nop,wscale="" 0,nop,nop,timestamp="" 0="" 0,nop,nop,sackok="">
13:13:22.407963 IP 192.168.246.128.54955 > 192.168.246.13.80: . ack 1 win 92 <nop,nop,timestamp 518611="" 0="">
13:13:22.408321 IP 192.168.246.128.54955 > 192.168.246.13.80: R 1:1(0) ack 1 win 92 <nop,nop,timestamp 518611="" 0="">
Hrvoje Špoljar
  • 5,245
  • 26
  • 42
Kell90
  • 69
  • 1
  • 1
  • 2

2 Answers2

16

Seems like client 192.168.246.128 tried to connect to web server 192.168.246.13 but client's window size of 92 bytes was refused by a slow-read attack prevention mechanism.

Xavier Lucas
  • 13,095
  • 2
  • 44
  • 50
  • 6
    good catch with that window size – Hrvoje Špoljar Nov 17 '14 at 21:47
  • 1
    That can also be caused by a messed up router/firewall. See https://lwn.net/Articles/92727/ – Zan Lynx Nov 18 '14 at 02:05
  • 1
    Note it's the client that resets the connection, not the server. And the client sent that 92 bytes window size. So that seems more like a port scan to me that like a slow read attack prevention. – Guntram Blohm Nov 18 '14 at 08:25
  • @GuntramBlohm There's no indication in the OP on where the capture is taken. Many things can happen along the path. However, you could certainly post your interpretation as an answer. – Xavier Lucas Nov 18 '14 at 09:31
  • The server only sends one packet, and it's a normal conversation. It's the client that's behaving strangely. – quadruplebucky Nov 18 '14 at 11:00
  • I've updated my answer and it seems this is `TCP connect scan` footprint; thx @GuntramBlohm – Hrvoje Špoljar Nov 18 '14 at 11:14
  • Why the downvote ? *Server* and *client* is a vague notion as the place where the packet is captured is not specified at all. – Xavier Lucas Nov 18 '14 at 11:35
  • @XavierLucas it's not relevant where the capture happened, one is behaving as a client (initiating) and the other is not. – quadruplebucky Nov 18 '14 at 11:38
  • @quadruplebucky I'm sorry but that doesn't prevent an intermediate appliance to modify the conversation at all. The direction of the conversation has absolutely nothing to do with this. If you don't know where the trace is taken and what's belong the path, such a statement is incorrect. – Xavier Lucas Nov 18 '14 at 11:51
  • @XavierLucas of course anything intermediate can modify the conversation but the 4 lines posted look like a pathological client (client being anything not the server). I believe that it is wrong to interpret that as a server preventing a slow-read. – quadruplebucky Nov 18 '14 at 12:23
  • @quadruplebucky You can't say it's wrong or not to interpret this in a way or in an other way if you don't know the network topology and structure. Btw my answer starts with *seems like* for a reason. Because it's interpretation based on the few details given. I already saw such a behaviour resulting of DPI in high security environment, so the server closes the socket on its side while the original client will gets a reset on the next packet. – Xavier Lucas Nov 18 '14 at 12:26
  • 1
    @XavierLucas fair enough, I should not say wrong but "isn't necessarily right". Thus "I believe" as in "seems like". Agreed. – quadruplebucky Nov 18 '14 at 12:31
  • 1
    This could be an IDS detecting the slow-read attack. Some IDS systems work by sending `RST` packets to both ends of the conversation, forging the other end's IP as the source. To each system, it looks like the other end reset the connection. – Barmar Nov 18 '14 at 19:09
9

EDIT after reading comment by @GuntramBlohm on answer by @XavierLucas I did a quick check how do certain nmap scans look like on the wire and it seems pattern in OP is match for nmap -sT known as TCP connect scan

e.g. case with port 80 open

# nmap -sT localhost -p80
11:06:20.734518 IP 127.0.0.1.58802 > 127.0.0.1.80: Flags [S], seq 2064268743, win 32792, options [mss 16396,sackOK,TS val 3605220739 ecr 0,nop,wscale 8], length 0
11:06:20.734540 IP 127.0.0.1.80 > 127.0.0.1.58802: Flags [S.], seq 2269627608, ack 2064268744, win 32768, options [mss 16396,sackOK,TS val 3605220739 ecr 3605220739,nop,wscale 8], length 0
11:06:20.734551 IP 127.0.0.1.58802 > 127.0.0.1.80: Flags [.], ack 1, win 129, options [nop,nop,TS val 3605220739 ecr 3605220739], length 0
11:06:20.734718 IP 127.0.0.1.58802 > 127.0.0.1.80: Flags [R.], seq 1, ack 1, win 129, options [nop,nop,TS val 3605220739 ecr 3605220739], length 0

case with port 80 closed

# nmap -sT localhost -p80
12:18:07.737075 IP 127.0.0.1.58294 > 127.0.0.1.80: Flags [S], seq 2548091563, win 32792, options [mss 16396,sackOK,TS val 672612170 ecr 0,nop,wscale 7], length 0
12:18:07.737085 IP 127.0.0.1.80 > 127.0.0.1.58294: Flags [R.], seq 0, ack 2548091564, win 0, length 0

END EDIT original interpretation of tcpdump output

Line by line 13:13:22.407445

13:13:22.407445 IP 192.168.246.128.54955 > 192.168.246.13.80: S 2910497703:2910497703(0) win 5840 <mss 1460,sackok,timestamp="" 518611="" 0,nop,wscale="" 6="">

  • IP : 192.168.246.128 with source port 54955 tries to connect to IP 192.168.246.13 port 80 (http)

  • TCP Connection start is initiated by setting SYN flag indicated by letter S

  • sequence number of connection attempt is 2910497703

  • window size is 5840, maximum segment size 1460

Second line at 13:13:22.407560

13:13:22.407560 IP 192.168.246.13.80 > 192.168.246.128.54955: S 3762608065:3762608065(0) ack 2910497704 win 64240 <mss 1460,nop,wscale="" 0,nop,nop,timestamp="" 0="" 0,nop,nop,sackok="">

  • IP 192.168.246.13 with source port 80 responds to connection attempt from 192.168.246.128 src port 407445 with flags SYN+ACK indicated by letter S and ack

  • sequence number 3762608065 and sequence number from line above is incremented by one to get 2910497704

  • window is set to 64240 , maximum segment size (mss) 1460

Third line is final packet of three way handshake

13:13:22.407963 IP 192.168.246.128.54955 > 192.168.246.13.80: . ack 1 win 92 <nop,nop,timestamp 518611="" 0="">

enter image description here

  • it has same srcIP:port - dstIP:port pair as above with only ACK flag set.

Last line

13:13:22.408321 IP 192.168.246.128.54955 > 192.168.246.13.80: R 1:1(0) ack 1 win 92 <nop,nop,timestamp 518611="" 0="">

This line reads that connection between 192.168.246.128:54955 and 192.168.246.13:80 is reset (RST flag) and ACK flag which indicates data transmitted so far has been accepted as expected. More info on this can be found here

Community
  • 1
Hrvoje Špoljar
  • 5,245
  • 26
  • 42