Partial Fragments
elof2 at sentor.se
elof2 at sentor.se
Fri Oct 24 06:31:59 EDT 2014
Hi Carter!
spkts dpkts sbytes dbytes state ltime
...
...
02:56:56.508553 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.508553
02:56:56.509244 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.509244
02:56:56.509580 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.509580
02:56:56.516669 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.516669
02:56:56.516748 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.516748
02:56:56.531167 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.531167
02:56:56.531575 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.531575
02:56:56.531704 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.531704
02:56:56.535491 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.535491
02:56:56.536158 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.536158
02:56:56.537324 M F udp 10.20.20.20.59297 <-> 10.10.10.10.443 8725 44994 1273843 45412854 CON 02:57:01.718200
02:56:56.540186 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.540186
02:56:56.541504 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.541504
02:56:56.543402 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.543402
02:56:56.546622 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.546622
02:56:56.550524 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.550524
02:56:56.552348 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.552348
02:56:56.560982 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.560982
02:56:56.566569 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.566569
02:56:56.568299 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.568299
02:56:56.570430 e f udp 10.10.10.10 -> 10.20.20.20 1 0 135 0 INT 02:56:56.570430
...
...and so on for tens of thousands of lines...
So, 10.20.20.20:59297 is talking to 10.10.10.10:443 via UDP.
44994 of the responses over the next minute was matched and hence
connected to the above udp flow.
Within this traffic (and/or in the 8725 packets from the client), there
were fragments, so this flow is flagged with a "F".
However, over this minute (and before), there seem to also have been tens
of thousands of "partial fragments" (flagged "f").
Each such UDP packet gets logged as a new flow.
Result: the argus logfile grows exponentially in size.
(I noted this because the traffic logged above ran constantly for two
hours, filling my harddrive)
Questions:
Q1: When is argus flagging something as a "Partial Fragment" ("f") and
not a Fragment ("F")?
Q2: Why don't these packets also get matched to the udp flow, and
increase the 44994 counter by the tens of thousands instead?
/Elof
More information about the argus
mailing list