Fkiws with destination port 0 and TCP SYN flag set

Mailman List Mirror (Read Only)
1

Hi,

I am doing some flow analysis within our network primarily for understanding application flows to aid in network segregation activity and mainly understand what is going on inside the network. To do this I have been using netflow where the switches/firewalls support it. In some cases I have used a monitor port and fed full packet capture into the nfdump toolset for conversion into flows.

There is a portion of our network where the switches only support sflow which is not ideal, but hopefully will be able to gather enough data over time to be useful. One of the things I was trying to identify was flow initiation, i.e. the client and server in the flow- so filtered for TCP packets with SYN flag set.

It was at this point that I saw TCP SYN packets with a destination port of 0. I have seen this discussed before in this thread http://www.gossamer-threads.com/lists/nanog/users/155141

It was stated in that thread that netflow reports source/dest port 0 for non-initial fragments. My question was is this what I am seeing here, so any SYN packet with dest port 0 is a non-initial fragment seen by the tool? Therefore should I always see a corresponding response with Ack and Reset flags set? I do see a set of flows with R and A set with a source port of 0, all the dest port 0 flows have the SYN flag set, but it's hard to find ones that match a SYN packet due to only receiving a sample of flows.

Some notes on the setup:

Capture is from inside one VLAN
Switches are sending sflow back to analysis tools, sampling rate of 1/1024 packets
Using nfdump suite of tools for analysis. sfcapd as as the collector

Thinking about this, is what I am seeing a symptom of the fact that the tools don't see all packets, i.e. the tools don't see the initial fragment due to sampling. However I still don't quite understand it appearing with the SYN flag set?

I am starting to think that for these purposes I might be better abandoning sflow and go with setting up collectors on the switches to get full flow information for my purposes.

Any clarification/input much appreciated.

Regards

MH

2

Fragmentation in this context only applies to UDP packets.

If the destination of a TCP SYN is being reported as 0 (what's the source port?), either it's a reporting artifact of some kind or in fact a SYN destined to TCP/0 (we see this with SYN-floods, sometimes, as well as with attacks attempting to bypass ACL/firewall rules and related to compromise).

3

Hi

Thanks for the response. There are lots of different source ports all above 10,000 (e.g. 42628,42927,39050). It is always two redhat machines generating the traffic, can't be 100% sure due to the sampling but pretty sure the capture has been running for 24 hours or so. It is always the same destination servers and in normal operations these source and destination hosts do have a bunch of legitimate flows between them. I was leaning towards it being a reporting artifact, but it's interesting that there are a whole set of Ack Reset packets from the destination hosts with a source port of 0 also. Does this not indicate that it probably isn't a reporting artifact?

Maybe I need to setup collectors and span ports on all the switches involved to get to the bottom of this. Just feeling like we need to look at *all* the packets not the sample!

Regards,

MH

4

It is always the same destination servers and in normal operations
these source and destination hosts do have a bunch of legitimate flows
between them. I was leaning towards it being a reporting artifact,
but it's interesting that there are a whole set of Ack Reset packets
from the destination hosts with a source port of 0 also.

So the destination host is sending ACK+RST with the *source* port
set to zero, or the *destination* port?

Does this not indicate that it probably isn't a reporting artifact?

I would just tcpdump on one of the source machines to find out.

~Marcin

5

Concur 100%.

6

Hi,

The destination host is sending an ACK+RST with the source port set to zero. The destination IP is always one of the two hosts that are generating the SYN packets with a destination port of 0. The destination port however is hard to match up to a source port in the original SYN packet due to the fact that we don't have all the packets.

It's actually going to be difficult to get the access and procedural sign off etc. to run tcpdump on the machines involved. What might be easier is to set up a span port for the hosts access port on the switch and grab that via the collector laptop I have.

Thanks,

MH

7

Hello!

Looks like it's silly hping3 flood:

12:43:08.961024 IP 192.168.0.127.10562 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961031 IP 192.168.0.127.10563 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961039 IP 192.168.0.127.10564 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961046 IP 192.168.0.127.10565 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961054 IP 192.168.0.127.10566 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961062 IP 192.168.0.127.10567 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961070 IP 192.168.0.127.10568 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961077 IP 192.168.0.127.10569 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961085 IP 192.168.0.127.10570 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961093 IP 192.168.0.127.10571 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961101 IP 192.168.0.127.10572 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961108 IP 192.168.0.127.10573 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961116 IP 192.168.0.127.10574 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961123 IP 192.168.0.127.10575 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961131 IP 192.168.0.127.10576 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961139 IP 192.168.0.127.10577 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961146 IP 192.168.0.127.10578 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961154 IP 192.168.0.127.10579 > 216.239.32.21.0: Flags [.],
win 512, length 0

Just try:
hping3 --flood target_host.

8

It's better to collect as much information you have without perturbing the systems involved, anyways.

9

Hmm, no flags set in your output though?

10

Hello!

Just add --syn flag:

12:51:51.150085 IP 192.168.0.127.14628 > 216.239.34.21.0: Flags [S],
seq 680218921, win 512, length 0
12:51:51.150092 IP 192.168.0.127.14629 > 216.239.34.21.0: Flags [S],
seq 2073100941, win 512, length 0
12:51:51.150100 IP 192.168.0.127.14630 > 216.239.34.21.0: Flags [S],
seq 1003157405, win 512, length 0
12:51:51.150108 IP 192.168.0.127.14631 > 216.239.34.21.0: Flags [S],
seq 466773687, win 512, length 0
12:51:51.150115 IP 192.168.0.127.14632 > 216.239.34.21.0: Flags [S],
seq 338869897, win 512, length 0
12:51:51.150123 IP 192.168.0.127.14633 > 216.239.34.21.0: Flags [S],
seq 1513724122, win 512, length 0
12:51:51.150130 IP 192.168.0.127.14634 > 216.239.34.21.0: Flags [S],
seq 1971827612, win 512, length 0
12:51:51.150138 IP 192.168.0.127.14635 > 216.239.34.21.0: Flags [S],
seq 168197290, win 512, length 0
12:51:51.150146 IP 192.168.0.127.14636 > 216.239.34.21.0: Flags [S],
seq 1079714921, win 512, length 0
12:51:51.150153 IP 192.168.0.127.14637 > 216.239.34.21.0: Flags [S],
seq 1634213253, win 512, length 0
12:51:51.150161 IP 192.168.0.127.14638 > 216.239.34.21.0: Flags [S],
seq 1220755012, win 512, length 0
12:51:51.150168 IP 192.168.0.127.14639 > 216.239.34.21.0: Flags [S],
seq 351031228, win 512, length 0
12:51:51.150176 IP 192.168.0.127.14640 > 216.239.34.21.0: Flags [S],
seq 286599236, win 512, length 0
12:51:51.150184 IP 192.168.0.127.14641 > 216.239.34.21.0: Flags [S],
seq 125907752, win 512, length 0

hping3 --flood --syn host.com

11

Agreed. Might see if I can get netstat -antp output from the operators at some point though.

I will start with one of the hosts, looks like the whole flow capturing exercise for this LAN will need to be done using multiple laptops connected to the different access ports for the hosts. No RSPAN support on these switches and no netflow :frowning:

12

So, progressed to grabbing full packet dumps via monitor ports. This confirmed that indeed the two hosts in question are generating traffic to the same four destinations with a destination port of zero. Now that I have a full packet dump I see reset + ack packets coming back from source port 0 for every single one of the initial SYN packets. Also it does look like a "scan" of some sort as the source port numbers are increasing by two or three every time and roughly 3-4 SYN packets per second being sent. I am guessing this would be process binding to the next available TCP port on the source machine.

As far as I can tell to progress the analysis I need to move to doing forensics on the host itself. It could be (as Pavel pointed out) be a utility like hping3 that someone has left running and forgotten about. On the other hand it could be something more malicious I just don't know at the moment. Any advice on this aspect would be great, unless considered off topic.

Finally I don't see how it could be, but be interested to hear peoples thoughts, no legitimate application could be generating this traffic could it? I mean I don't see what use an application could make of such a TCP conversation. Discarding network analysis etc. This machine runs a whole host of proprietary control system protocols, so haven't discarded the possibility totally- but I just can't see what an application protocol could find useful in a bunch of reset + ack packets being received from the destination hosts.

Regards,

MH

13

NANOG isn't really the right alias for this sort of thing.

TCP port-scanning on TCP/0 is a common reconnaissance mechanism.

Suggest you take this to a more appropriate alias like one of the bugtraq lists.

14

Okay, setting aside the malicious possibilities, it may be that someone
felt they needed something like ping but without the need for a raw
socket. I would worry about such code as there is usually sufficient
proof the host is alive due to ongoing or new sessions. Still, in
process control it may be reasonable to check aliveness if, for example,
there has been no normal activity for a seemingly small period of time,
e.g., 50ms. Such a test is only sufficient to prove that the TCP stack
will respond, not the programs (which is where aliveness within the
protocols is far more useful, classically PING and PONG).

Or perhaps a fence-post bug, e.g., a program is doing its own port
selection with a max of 65535 where it accidentally uses max+1 which for
a 16 bit unsigned value turns out to be 0, i.e., fixing the port number
(setting it to the min value) after it is used rather than before.

/mark

15

Hi,

I'm investigating some of the protocols and will start looking at the processes on the machines. Someone else rightly pointed out this getting off topic for NANOG, so thanks to everyone that responded.

Regards,

MH