views:

217

answers:

2

I find myself needing to process network traffic captured with tcpdump. Reading the traffic is not hard, but what gets a bit tricky is spotting where there are "spikes" in the traffic. I'm mostly concerned with TCP SYN packets and what I want to do is find days where there's a sudden rise in the traffic for a given destination port. There's quite a bit of data to process (roughly one year).

What I've tried so far is to use an exponential moving average, this was good enough to let me get some interesting measures out, but comparing what I've seen with external data sources seems to be a bit too aggressive in flagging things as abnormal.

I've considered using a combination of the exponential moving average plus historical data (possibly from 7 days in the past, thinking that there ought to be a weekly cycle to what I am seeing), as some papers I've read seem to have managed to model resource usage that way with good success.

So, does anyone knows of a good method or somewhere to go and read up on this sort of thing.

The moving average I've been using looks roughly like:

avg = avg+0.96*(new-avg)

With avg being the EMA and new being the new measure. I have been experimenting with what thresholds to use, but found that a combination of "must be a given factor higher than the average prior to weighing the new value in" and "must be at least 3 higher" to give the least bad result.

+2  A: 

I would apply two low-pass filters to the data, one with a long time constant, T1, and one with a short time constant, T2. You would then look at the magnitude difference in output from these two filters and when it exceeds a certain threshold, K, then that would be a spike. The hardest part is tuning T1, T2 and K so that you don't get too many false positives and you don't miss any small spikes.

The following is a single pole IIR low-pass filter:

new = k * old + (1 - k) * new

The value of k determines the time constant and is usually close to 1.0 (but < 1.0 of course).

I am suggesting that you apply two such filters in parallel, with different time constants, e.g. start with say k = 0.9 for one (short time constant) and k = 0.99 for the other (long time constant) and then look at the magnitude difference in their outputs. The magnitude difference will be small most of the time, but will become large when there is a spike.

Paul R
Interesting. Since I'm doing off-line processing, that ought to be relatively simple to do as well. Do you think it's worth experimenting with chunk size as well (I've tried hourly and daily in the past)?
Vatine
It depends on whether your data is regularly sampled. If not then you might want to collect data into equal duration bins or chunks or whatever you want to call them to give the equivalent effect of a fixed sampling interval.
Paul R
The tcpdump data has a time stamp that can be assumed to be accurate to at least "sub-second" resolution, but the interval for incoming data is, well, not really that regular, being network traffic and all, so I guess binning/chunking it to fixed-sized intervals makes sense.
Vatine
0.96 is a very large gain for a low-pass filter. You're throwing out almost all the history at each step. Try dropping that to 0.1. You might also run the data through different detectors for each day of the week - each running it's own average.
phkahler
@phkaler - sorry - I didn't look closely enough at the OP's filter equation - I've now edited my answer to properly specify a unity gain single pole IIR where the time constant will be sensible for k < 1.0.
Paul R
+5  A: 

This is widely studied in intrusion detection literature. This is a seminal paper on the issue which shows, among other things, how to analyze tcpdump data to gain relevant insights.

This is the paper: http://www.usenix.org/publications/library/proceedings/sec98/full_papers/full_papers/lee/lee_html/lee.html here they use the RIPPER rule induction system, I guess you could replace that old one for something newer such as http://www.newty.de/pnc2/ or http://www.data-miner.com/rik.html

Vinko Vrsalovic
Interesting reading, for sure. At the moment, detection of increased traffic levels is enough for what I need, but it's certainly something to consider for the future.
Vatine