Argus vs. DDoS

Carter Bullard carter at
Wed Feb 20 14:19:59 EST 2013

Hey Jesper Skou Jensen,
The key to controlling the memory used by argus, are the flow status queue and the protocol idle queue timers, so that argus can forget about its flow caches as soon as possible.  I use a 5 sec status timer, which controls the size of the active queue, but we still have a number of idle queues that hold the caches for little while longer.  Once argus times out the flows in these queues, it completely forgets about the flow, which, when being DoSed, is a good thing.  When not being attacked, the side effect of making these changes are that you will end up with some status records that don't know the direction, ( '?' ) in the dir field, not a huge problem.

The timers can be configured from the argus.conf file, so turn those all down to say 5 sec, and you should ride the storm out a bit better.

Residual memory is odd and maybe a bug.  It maybe that your kernel doesn't report that the deallocated memory pages are inactive?  You have memory, but the kernel does report it as available?

Ok, dropped packages, I say packets, you say packages?
When you're getting DoS'd, the port mirrors can be saturated, which will drop packets, and your libpcap can drop packets.  You can change your PCAP_MEMORY environment variable, using the argus.conf file, which can help immensely to improve probe packet loss, that maybe the best knob for you to turn.

Hope that helps, send more email if I'm missing something.  and I hope all will be most excellent, sooner than later,


On Feb 20, 2013, at 6:45 AM, Jesper Skou Jensen <jesper.skou.jensen at> wrote:

> Hi guys,
> Recently one of the links my Argus box is monitoring has been DDoS'ed a number of times, everything from UDP to ICMP and Syn-Floods has been thrown at us. When this happens, especially syn-floods the Argus process starts eating a lot of RAM and CPU.
> When the attack is done the CPU load drops to normal levels, but the RAM (Virt and Res) remains high. Until I manually restart the Argus process.
> What's worse is that the Argus process appears to be dropping packages. When I afterwards analyze the traffic, eg. by running it through ragraph I can see that during the attack the bytes/s counters are very low but the packages/s goes through the roof.
> I'm guessing it's because Argus is trying to keep a state-table for each and every TCP session, and since we are usualy flooded by thousands/millions of IPs the state-table grows very fast.
> Can you guys recommend any tweaks to Argus, eg. some config settings or similar, that can help preventing this excessive CPU/RAM usage to happen?
> Regards
> Jesper Skou Jensen

More information about the argus mailing list