📜 ⬆️ ⬇️

Fast transit traffic analysis

Before any system administrator, sooner or later there is a problem of quantitative analysis of the traffic (from / to, through which protocols / ports, in what volumes, etc.) passing through its network. It is especially unpleasant when this task arises spontaneously, as a side effect of DDoS, and, as usual, there is no money for serious solutions from Cisco or Arbor. And it's good if the gateway for the network is a server on which you can run tcpdump or wireshark, but what to do if:


An additional spoon of tar in this “barrel of honey” of the task is also added by the absence of both the tcpdump and tshark miraculous keys “group, sum up / average and sort”.

So, with all the reluctance to reinvent the wheel, I had to roll up our sleeves and write a tool that meets the following requirements:
')

It was on this basis that PCAParse was written - as simple as possible tool for obtaining generalized information about traffic passing through the network. To use it, in the simplest case, a D-Link DGS-3XXX switch or equivalent from other manufacturers is enough and running on the aforementioned sflowtool or tcpdump file server on the office gateway. As practice shows, these devices have long ago lost their exotic status and can be found even in small offices.

In order to make it clear what is at stake, I will give a small example:

Sample script output
 $ tshark -c 100 -w - |  pcaparse
 Filename: -
 File size: -
 Parsed: 100 samples in 4.90 seconds
 Matched: 100 samples / 104.21kB
   tcp: 20 samples / 2.04kB
   udp: 76 samples / 101.79kB
   icmp: 4 samples / 392B
   other: 0 samples / 0B

                             Samples Average
 Destination count size
 212.XX.XXX.XX 86 102.43kB 1.19kB
   tcp: 10 660B 66B
   udp: 76 101.79kB 1.34kB
   icmp: 0 0B 0B
   other: 0 0B 0B
 212.XX.XXX.XX 5 550B 110B
 212.XX.XXX.XX 5 878B 176B
 212.XX.XXX.XXX 4 392B 98B


Of course, an awkward working time immediately catches the eye, but in reality it is the result of tshark, and not a script. Its real performance on AMD A8-6600K @ 3.9 GHz / 8 GB RAM is 15-25 kilopackets / s depending on the data source (read from file, sFlow, etc.).

More demanding users may request more detailed information:

Expanded sample script output
 $ tcpdump -w - |  pcaparse -f - -d 212.XX.XX.XX
 Filename: -
 File size: 32.65MB
 Parsed: 280692 samples in 27.58 seconds
 Matched: 4383 samples / 3.75MB
   tcp: 4 samples / 513B
   udp: 4378 samples / 3.75MB
   icmp: 0 samples / 0B
   other: 0 samples / 0B

                             Samples Average
 Destination count size
 212.XX.XX.XX 4.38k 3.75MB 897B
   tcp: 4 513B 128B
     80 (http) 4,513B 128B
   udp: 4378 3.75MB 898B
     7 (echo) 2819 2.82MB 1.02kB
     3389 (ms-wbt-server) 659 670.15kB 1.02kB
     5538 273 86.15kB 323B
     9584 87 24.62kB 290B
     18002 92 26.55kB 295B
     27186 167 55.68kB 341B
     32302 279 89.50kB 328B
   icmp: 0 0B 0B
   other: 0 0B 0B


If we take into account that the dump for the example is taken for a regular web server, this information allows you to judge whether there is a DoS / DDoS attack by udp: * on the resource. Well, this knowledge allows us to take some adequate measures. For the convenience of further data processing, a parser-friendly output is provided:

Parser-friendly output
 $ pcaparse -f tcpdump-212-XX-XX-XX -d 212.XX.XX.XX -p
 212.XX.XX.XX total 4382 3931684 897
 212.XX.XX.XX tcp 4 513 128
 212.XX.XX.XX tcp: 80 4 513 128
 212.XX.XX.XX udp 4378 3931171 897
 212.XX.XX.XX udp: 7 2819 2955528 1048
 212.XX.XX.XX udp: 3389 659 686237 1041
 212.XX.XX.XX udp: 5538 273 88222 323
 212.XX.XX.XX udp: 9584 87 25208 289
 212.XX.XX.XX udp: 18002 92 27185 295
 212.XX.XX.XX udp: 27186 167 57019 341
 212.XX.XX.XX udp: 32302 279 91644 328
 212.XX.XX.XX icmp 0 0 0
 212.XX.XX.XX other 0 0 0

The script is written in perl-e using the Net :: PCAP and NetPacket :: * modules, which provides sufficient performance and cross-platform functionality. At least, on fresh linux and FreeBSD, there were no problems with startup and operation.

Of the known cons:


PS after the fact it turned out that there is a similar tool - Fastnetmon, but, nevertheless, it is focused on "stationary" use, because it implies the use of a data collector, with which the client part interacts.

References:

Source: https://habr.com/ru/post/280986/


All Articles