Subscription for Syn or Rst attacks

[josemic]

1) Assume you want to warn because of Syn attacks:

• Here a Syn is sent by the attacker and an Ack sent by the server, but the attacker never responds with in Ack. Thus the server keeps repeatedly sending Ack messages.

2) Assume you want to warn because of Rst attacks:

• Here the attacker sends randomly Rst-packages in the hope to match a valid sequence number of an ongoing connection and to reset that ongoing connection.

Currently it is only possible to subscribe all packages including payload packages. This causes high traffic. Therefore it might be useful to subscribe for just Syn and Ack packages for 1) or just for Rst packages for 2). Optionally it might be useful to restrict the subscription to certain port number / port number range or a certain IP-address / IP-subnet.

[ates]

You may specify the range of ports by passing they as a filter.

epcap should not work with traffic data, it just must capture all(depends of pcap filter) traffic.

[msantos]

See pcap-filter(7). For example:

• SYN flag set

tcp[tcpflags] & tcp-syn != 0 && tcp[tcpflags] & tcp-ack == 0

• RST flag set

tcp[tcpflags] & tcp-rst != 0

It's also possible to limit the amount of the packet returned to the headers using the {snaplen, int()} option.

[josemic]

Great!! Some kind of filter like this exactly what is needed to keep the Erlang traffic low. I've set snaplen e.g. to 64. This crashed the decoding of the ipv4 option field in pkt (line 3):

options(Offset, Binary) ->
    Length = (Offset - 5) * 4,
    <<Options:Length/binary, Payload/binary>> = Binary,
    {Options, Payload}.

Should Length be tested for being greater or equal to Payload length before decoding or is it better to crash the decoding of the whole packet? Note: It should be possible to build option fields of almost any length, just by adding the same option over and over again. Thus it is not possible to set a useful snaplen boundary.

[msantos]

pkt:decapsulate/1 only works with whole packets. If I were using the snaplen option, I would probably roll my own function to decode each layer in a try/catch.

Re: options/2, not sure, my feeling is it should crash.

About snaplen: the maximum size of the IPv4 header is 60 bytes + 20 bytes TCP header. If you are testing for .e.g., TCP flags then that should be sufficient.

[josemic]

Agree, a custom decoding function makes sense. Thus we can close this issue.

[josemic]

Note: Here is some follow-up. See changes to decode and decapsulate: https://github.com/msantos/pkt/issues/9