Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

during SYN scans, many small tcp packets are sent to multiple ports to determine which ports are open or not. But when you're streaming media, aren't you receiving many

One type of ID system, the Dendritic Cell Algoritithm is used to determine if SYN scans are occurring on a host. Now, one portion (out of 7) determines the ratio of TCP packets to total packets that are being sent to a "malicious host". How would this portion be able to determine whether the (would be victim) host is seeding a torrent, or if they were being SYN scanned by an attacker?

The next portion of this DCA calculates the average size of packets and the standard deviation. The average packet size becomes 40 bytes because much of the traffic is just ~40 byte SYN packets. Now the reason for the standard deviation being included is that many of the infinite combinations of network packet sizes could average to 40 bytes so this is a safeguard. This seems pretty secure, but I don't know much information about this, are there other common types of packets that one can send in large quantities to a network (to multiple ports or even a single port) that are about 40 bytes?

share|improve this question
add comment

2 Answers

But when you're streaming media, aren't you receiving many?

Streaming media is slightly different to your usual TCP connection in that typically you stream media over UDP. The reason for this is that the cost of building in sequence verification real time into streaming media is, while not prohibitive, potentially enough to interrupt the stream.

UDP, on the other hand, is a "blast and forget" protocol. You send the current segment of the media a number of times and hope the other end received it. If it didn't, the other end is responsible for finding a suitable way to handle that missing information - error correction at the codec level is a possibility.

... determines the ratio of TCP packets to total packets that are being sent to a "malicious host". How would this portion be able to determine whether the (would be victim) host is seeding a torrent, or if they were being SYN scanned by an attacker?

I know very little about the bittorrent protocol, however, I think you're general point that the two might be indistinguishable is probably right. According to what I have read, bittorrent uses a number of small tcp connections to transmit data. If the syn scan is limited to a small range and the bittorrent seeding to a large range I expect it might be difficult to statistically differentiate the two.

However, there are some possibilities. Firstly, the valid ports range for a bittorrent seed is likely to not involve reserved ports which might be used by other services. As a result of this, it is also likely to use a narrower range of ports generally, whereas a syn scan is likely to try every port it can.

So, I suspect it depends on the network, but it still may be possible to differentiate the two. Indeed, another dimension is that you could analyse the traffic patterns generally. Syn scans do not involve data transfer, whereas bittorrent does, meaning the timings between syn/ack would be different.

Another observation - bittorrent syn connections should (you would expect) to be acknowledged, whereas a syn scan is likely to make many connections to closed ports.

This seems pretty secure, but I don't know much information about this, are there other common types of packets that one can send in large quantities to a network (to multiple ports or even a single port) that are about 40 bytes?

It is possible. According to this stackoverflow answer the minimum size for a UDP packet is 28 bytes with an empty datagram. If you wanted to confuse the statistics, you could send udp requests to the host with a payload of 12 bytes.

That said, I do not know of any protocol in genuine full time use that is exactly 40 bytes with any such regularity (i.e. the standard deviation would be very small). I suspect this is quite an accurate measure.

share|improve this answer
add comment

SYN packets are a TCP concept. TCP is about opening then using a connection, i.e. a bidirectional tunnel. A connection begins with the three-way handshake: a packet with the SYN flag from the client, then a packet with the SYN and ACK flags from the server, then a packet with the ACK flag from the client. So there will be, for a normal connection, a single incoming packet with the SYN flag, even if gigabytes are data are then exchanged over the connection.

With UDP, there is no "SYN" at all. "SYN" is a flag written in the TCP header of some packets. No TCP, no TCP header, hence no SYN.

For a server which "streams media", the ratio of SYN packets ought to be very low: either the streaming protocol uses TCP, in which case there is only one incoming SYN per connection, or the streaming protocol uses UDP, in which case there is no SYN at all.


Using packet size as a way to detect SYN packets seems kinda stupid. A SYN packet can be unambiguously recognized as such by virtue of the SYN flag being written on it. Any decent IDS system ought to be able to decode TCP and UDP headers, see what packet is which, and look at the SYN flag. See the TCP standard for the header format: the SYN flag is 7th bit of the 14th byte of the header. Relying on the packet size, instead of simply looking at that bit, smells like incompetence.

Also, packet size is not guaranteed. A "SYN" packet is an IP packet which contains a TCP header which features the SYN flag. Both the IP header and the TCP header can contain "options", allowing the size to be changed at will. A SYN packet is not necessarily 40-byte long; this is just the usual size. If IDS systems begin to use packet size as a way to detect scans, then scanners will soon randomize the size of their SYN packets as a countermeasure.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.