Greg | 1 Sep 15:19 2011
Picon

netflow v9 in 3.0.5

Hi, I noticed 3.0.5 source already has tidbits referring to netflow v9 
support, but I wasn't able to get that functionality working yet. Is v9 
support still highly beta?

Thanks,
Greg

Carter Bullard | 1 Sep 17:18 2011

Re: netflow v9 in 3.0.5

Hey Greg,
The netflow v9 support is a part of our flow-tools, sflow, jflow, netflow v9 support effort, which started
in argus-3.0.5.
We have full flow-tools support now, and most of sflow, although I need more time and data to make progress.

For netflow v9, we should be recognizing that the stream is netflow, is version 9, and we should be able to at
least run through the stream, recognizing the templates, options, and the flow set Id's, but we aren't
parsing any
data yet.

Do you have some v9 data that you can share?

Carter

On Sep 1, 2011, at 9:19 AM, Greg wrote:

> Hi, I noticed 3.0.5 source already has tidbits referring to netflow v9 support, but I wasn't able to get
that functionality working yet. Is v9 support still highly beta?
> 
> 
> Thanks,
> Greg
> 

Attachment (smime.p7s): application/pkcs7-signature, 5901 bytes
Carter Bullard | 1 Sep 17:44 2011

Re: Ragraph top talker

Hey Fiorenzi,
If you are interested in input and output metrics, "in/out", for a subset of data,
you will want to run rabins() against your primitive data,  first, and then graph
the subset of IPs from that output.

Try this :
   rabins -M rmon -m saddr -M time 10s -r file -w ipAddrs.10s.out - ip

This will generate in/out metrics for every IP address,  for each 10 second
interval.  Read the ipAddrs.10s.out file using ra() to see what we did:

   ra -r ipAddrs.10s.out | less

Now you can graph this data, filtering out the addresses you are interested in.
rabins() put the IP addresses in the saddr field, so you can use "src" filters.
   
   ragraph sbytes dbytes saddr -M 10s -r ipAddrs.10s.out  - src net 10.x.y.0/24
   ragraph spkts dpkts saddr -M 10s -r ipAddrs.10s.out - src net 10.x.y.0/24

I'm going to be in Rome, for just the weekend.  How is the weather?

Carter



On Aug 29, 2011, at 6:13 AM, Fiorenzi Alessandro wrote:

Hi, I am trying to graph which are top talkers on my network, I get it using this:

 

Top Talker:

/usr/local/bin/ragraph bytes saddr -M 10s -r /var/log/argus/argus.out -title "Realtime Top Talker Trafffico No proxed network  10.x.y.0/24" -m saddr -w "/var/www/realtime/Top-Talker-y.png" - src net 10.x.y.0/24&

 

And this work fine for me.

 

Now I would split traffic of toptalkers into up/down to have  a graph with tap talkers and bytes transferred up and down. Anybody have already do this?

 

Thanks

 

Alessandro Fiorenzi


Prima di stampare, pensa all'ambiente ** Think about the environment before printing

Il presente messaggio, inclusi gli eventuali allegati, ha natura aziendale e potrebbe contenere informazioni confidenziali e/o riservate. Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il mittente e di cancellarlo.
E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o diffusione non autorizzata del contenuto di questo messaggio o di parte di esso.
Pur essendo state assunte le dovute precauzioni per ridurre al minimo il rischio di trasmissione di virus, si suggerisce di effettuare gli opportuni controlli sui documenti allegati al presente messaggio. Non si assume alcuna responsabilità per eventuali danni o perdite derivanti dalla presenza di virus.

Per lo svolgimento delle attività di investimento nel Regno Unito, la società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza limitata della Financial Services Authority. Maggiori informazioni in merito ai poteri di vigilanza della Financial Services Authority sono a disposizione previa richiesta..

Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale di Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in Inghilterra & Galles sotto No.FC016201, Branch No.BR000036

***

This email (including any attachment) is a corporate message and may contain confidential and/or privileged and/or proprietary information. If you have received this email in error, please notify the sender immediately, do not use or share it and destroy this email. Any unauthorised use, copying or disclosure of the material in this email or of parts hereof (including reliance thereon) is strictly forbidden.
We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment of this message. We accept no liability for loss or damage caused by software viruses.

For the conduct of investment business in the UK, the Company is authorised by Banca d’Italia and subject to limited regulation in the UK by the Financial Services Authority. Details about the extent of our regulation by the Financial Services Authority are available from us on request.

In the UK Intesa Sanpaolo S.p.A. operates through its London Branch, located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales under No.FC016201, Branch No.BR000036

Attachment (smime.p7s): application/pkcs7-signature, 5901 bytes
Ricardo S | 14 Sep 14:32 2011
Picon

Possible bug on output of racluster

Hello all,

I'm trying to cluster my flow information by source port. It seems
that racluster is doing it fine. But when printing the results, it
seems to lose information of source and destination IPs and ports. To
better understand the problem, see example below.

Did anyone also experience the same problem? Solutions? (or maybe, my
commands are right?)

Thanks,
Ricardo.

Example: I have a file with flows already generated with argus. I use
the client "ra" to collect only flows from a specific IP address. Then
I use the client "racluster" to get information per source port.
However, the output I receive from "racluster" does not contain the IP
addresses or ports and, consequently, is useless.

Command: ra
# ra -r flows.argus -w ra-output.argus - 'ip and src host sss.sss.sss.sss'

Command: racluster
# racluster -r ra-output.argus -m saddr sport -s saddr sport daddr dport sbytes

Output from racluster:
           0.0.0.0                   0.0.0.0                 128
           0.0.0.0                   0.0.0.0                 128
           0.0.0.0                   0.0.0.0                 111
           0.0.0.0                   0.0.0.0                 111
           0.0.0.0                   0.0.0.0                 582
           0.0.0.0                   0.0.0.0                3759
           0.0.0.0                   0.0.0.0                  64
           0.0.0.0                   0.0.0.0                 582
           0.0.0.0                   0.0.0.0                3512
           0.0.0.0                   0.0.0.0                4745

Ilija Baniski | 22 Sep 19:52 2011

Argus 3.0 / 32-bit overflow / backward compatibility

Hello all,

I am doing some testing prior to upgrading to 3.0. 64-bit byte counters 
are an important reason for the upgrade, while the ability of the 3.0 
clients to read argus 2.0 data make the switch that much sweeter. 
However, I haven't been able to get either of these two features to 
work. I have the latest argus-3.0.4 and argus-clients-3.0.4.1 built. I 
know these two are not very closely related, but I'll ask both questions 
here.

I read that these two features should be supported here:
http://permalink.gmane.org/gmane.network.argus/3601
http://article.gmane.org/gmane.network.argus/3782

1.
To test the 4GB byte overflow I performed a ~5GB file transfer twice: 
once with STATUS_INTERVAL=60 and then with STATUS_INTERVAL=600. These 
were the results:

# ./ra -Xnr /opt/data/argus/var/log/argus.out - host 192.168.111.39
    11:45:51.241371  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22       674666  691670398   CON
    11:46:51.241496  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22       728665  746638654   CON
    11:47:51.241563  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22       729780  748390504   CON
    11:48:51.241597  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22       733293  752190798   CON
    11:49:51.241631  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22       733537  752519850   CON
    11:50:51.241659  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22       734255  752514878   CON
    11:51:51.241729  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22       732836  751412980   CON
    11:52:51.241770  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22       374739  384106534   FIN
# ./racluster -Xnr /opt/data/argus/var/log/argus.out - port 49460
    11:45:51.241371  e d       tcp    192.168.111.137.49460     ->     
192.168.111.39.22      5441771 5579444596   FIN

Which shows the transfer of the ~5GB file. Now with only a single 
interval for the transfer:

# ./ra -Xnr /opt/data/argus/var/log/argus.out - host 192.168.111.39
    11:33:23.249123  e d       tcp    192.168.111.137.47119     ->     
192.168.111.39.22      5443943 1284774452   FIN
# ./racluster -Xnr /opt/data/argus/var/log/argus.out - port 47119
    11:33:23.249123  e d       tcp    192.168.111.137.47119     ->     
192.168.111.39.22      5443943 1284774452   FIN

Which shows that the byte count has wrapped after 4GB (1284774452 + 
4x1024x1024x1024 = 5579741748).

So I guess the question is, what am I doing wrong? Do I need to compile 
argus in a certain way or configure it differently? Or perhaps this is 
related to the clients (unlikely since racluster seems to have no 
problem showing the 5GB if the data is there).

2.
To check the backward compatibility I used the ra tool from the 
argus-clients-3.0.4.1 to try and read a file written by argus 2.0. Here 
are some output snippets of me trying to read the file with both, an old 
client and new one:

The old:
# ra -h
Ra Version 2.0.6.fixes.1
...
# ra -r argus.2011-09-13-07-00-01.gz | head -2
09-07-11 11:18:07.535387           man                    10.2.1.37  
v2.0                                     1 0          0        0         
0            0           STA
09-13-11 02:49:01.914562           tcp                    
10.2.2.86.8280        ->                69.184.252.19.8292       
3        6         384          435         CON

and the new:
# ./ra -Xh
Ra Version 3.0.4.1
...
# ./ra -Xr argus.2011-09-13-07-00-01.gz
<no output at all>

So back to the same questions: what am I doing wrong/how can I use the 
new clients to read the old data? In my random attempts to make this 
happen I did try to unzip the file first, but that made no difference.

Thanks for any help,
Ilija

Carter Bullard | 22 Sep 20:29 2011

Re: Argus 3.0 / 32-bit overflow / backward compatibility

Hey Ilija,
Argus itself doesn't support 64-bit counters, but the clients do.  It is the difference between flow
data generation and flow data processing.

We do not recommend running argus such that it holds flow information for very large periods of time.
I run with ARGUS_FLOW_STATUS_INTERVAL set to 1s or 5s in every installation I do, and as
a result the 32-bit counter strategy has worked quite well.  For 10-100 Gbps interface monitoring,
I think the 32-bit value is still the way to go, with the clients aggregating the status reports to generate the
final flow record, where we do support 64-bit reporting.

If you think this is a flaw, then lets discuss.  Adding 64-bit counters will increase the flow cache
for every flow tracked by 48 bytes (src and dst pkt, byte, and appbyte counters) and for TCP we'll need to
add another 64 bytes or so, as we have a lot of other counters.  Can be a huge deal if we're tracking
1M flows, but our current cache size is pretty big, when you add jitter and other features.

Not sure what is up with your argus-2.0 data, as we should be able to read it with out issue.
argus-clients-3.0.5.19, in the developers section, may be able to read it fine, if there was a but.
If you can share the 2.x file, I'll check out what might be the issue.

Carter

On Sep 22, 2011, at 1:52 PM, Ilija Baniski wrote:

> Hello all,
> 
> I am doing some testing prior to upgrading to 3.0. 64-bit byte counters are an important reason for the
upgrade, while the ability of the 3.0 clients to read argus 2.0 data make the switch that much sweeter.
However, I haven't been able to get either of these two features to work. I have the latest argus-3.0.4 and
argus-clients-3.0.4.1 built. I know these two are not very closely related, but I'll ask both questions here.
> 
> I read that these two features should be supported here:
> http://permalink.gmane.org/gmane.network.argus/3601
> http://article.gmane.org/gmane.network.argus/3782
> 
> 1.
> To test the 4GB byte overflow I performed a ~5GB file transfer twice: once with STATUS_INTERVAL=60 and
then with STATUS_INTERVAL=600. These were the results:
> 
> # ./ra -Xnr /opt/data/argus/var/log/argus.out - host 192.168.111.39
>   11:45:51.241371  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22       674666  691670398   CON
>   11:46:51.241496  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22       728665  746638654   CON
>   11:47:51.241563  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22       729780  748390504   CON
>   11:48:51.241597  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22       733293  752190798   CON
>   11:49:51.241631  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22       733537  752519850   CON
>   11:50:51.241659  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22       734255  752514878   CON
>   11:51:51.241729  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22       732836  751412980   CON
>   11:52:51.241770  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22       374739  384106534   FIN
> # ./racluster -Xnr /opt/data/argus/var/log/argus.out - port 49460
>   11:45:51.241371  e d       tcp    192.168.111.137.49460     ->     192.168.111.39.22      5441771 5579444596   FIN
> 
> Which shows the transfer of the ~5GB file. Now with only a single interval for the transfer:
> 
> # ./ra -Xnr /opt/data/argus/var/log/argus.out - host 192.168.111.39
>   11:33:23.249123  e d       tcp    192.168.111.137.47119     ->     192.168.111.39.22      5443943 1284774452   FIN
> # ./racluster -Xnr /opt/data/argus/var/log/argus.out - port 47119
>   11:33:23.249123  e d       tcp    192.168.111.137.47119     ->     192.168.111.39.22      5443943 1284774452   FIN
> 
> Which shows that the byte count has wrapped after 4GB (1284774452 + 4x1024x1024x1024 = 5579741748).
> 
> So I guess the question is, what am I doing wrong? Do I need to compile argus in a certain way or configure it
differently? Or perhaps this is related to the clients (unlikely since racluster seems to have no problem
showing the 5GB if the data is there).
> 
> 
> 2.
> To check the backward compatibility I used the ra tool from the argus-clients-3.0.4.1 to try and read a
file written by argus 2.0. Here are some output snippets of me trying to read the file with both, an old
client and new one:
> 
> The old:
> # ra -h
> Ra Version 2.0.6.fixes.1
> ...
> # ra -r argus.2011-09-13-07-00-01.gz | head -2
> 09-07-11 11:18:07.535387           man                    10.2.1.37  v2.0                                     1 0          0        0         0            0           STA
> 09-13-11 02:49:01.914562           tcp                    10.2.2.86.8280        ->                69.184.252.19.8292       3        6         384          435         CON
> 
> and the new:
> # ./ra -Xh
> Ra Version 3.0.4.1
> ...
> # ./ra -Xr argus.2011-09-13-07-00-01.gz
> <no output at all>
> 
> So back to the same questions: what am I doing wrong/how can I use the new clients to read the old data? In my
random attempts to make this happen I did try to unzip the file first, but that made no difference.
> 
> 
> Thanks for any help,
> Ilija
> 

Attachment (smime.p7s): application/pkcs7-signature, 5901 bytes
Ilija Baniski | 22 Sep 21:36 2011

Re: Argus 3.0 / 32-bit overflow / backward compatibility

Hey Carter,

Thanks for the quick response and provided insight. You are right, with 
the correct configuration 32-bit counters should be sufficient for the 
good majority of the cases. However, setting the 
ARGUS_FLOW_STATUS_INTERVAL to a very low value would be an unnecessary 
overhead for most flows, I think. So, how does an alternative 
configuration feature (or perhaps this is something that already exists 
and I have missed?) where argus will produce "flow status" on its own 
when it has a byte counter that is ready to overflow? Such an option 
should allow for less aggressively outputting to disk while making it 
harder to loose data by having a poorly configured argus.

As for the backwards compatibility, unfortunately I did not have much 
luck even with the newest development release. I also ran it across a 
number of files in the argus archive I have available. I am attaching 
one of the smallest argus 2.x files that I have (unsuccessfully) tested 
against.

Thanks,
Ilija

On 11-09-22 02:29 PM, Carter Bullard wrote:
> Hey Ilija,
> Argus itself doesn't support 64-bit counters, but the clients do.  It is the difference between flow
> data generation and flow data processing.
>
> We do not recommend running argus such that it holds flow information for very large periods of time.
> I run with ARGUS_FLOW_STATUS_INTERVAL set to 1s or 5s in every installation I do, and as
> a result the 32-bit counter strategy has worked quite well.  For 10-100 Gbps interface monitoring,
> I think the 32-bit value is still the way to go, with the clients aggregating the status reports to generate the
> final flow record, where we do support 64-bit reporting.
>
> If you think this is a flaw, then lets discuss.  Adding 64-bit counters will increase the flow cache
> for every flow tracked by 48 bytes (src and dst pkt, byte, and appbyte counters) and for TCP we'll need to
> add another 64 bytes or so, as we have a lot of other counters.  Can be a huge deal if we're tracking
> 1M flows, but our current cache size is pretty big, when you add jitter and other features.
>
> Not sure what is up with your argus-2.0 data, as we should be able to read it with out issue.
> argus-clients-3.0.5.19, in the developers section, may be able to read it fine, if there was a but.
> If you can share the 2.x file, I'll check out what might be the issue.
>
> Carter
>
> On Sep 22, 2011, at 1:52 PM, Ilija Baniski wrote:
>
>> Hello all,
>>
>> I am doing some testing prior to upgrading to 3.0. 64-bit byte counters are an important reason for the
upgrade, while the ability of the 3.0 clients to read argus 2.0 data make the switch that much sweeter.
However, I haven't been able to get either of these two features to work. I have the latest argus-3.0.4 and
argus-clients-3.0.4.1 built. I know these two are not very closely related, but I'll ask both questions here.
>>
>> I read that these two features should be supported here:
>> http://permalink.gmane.org/gmane.network.argus/3601
>> http://article.gmane.org/gmane.network.argus/3782
>>
>> 1.
>> To test the 4GB byte overflow I performed a ~5GB file transfer twice: once with STATUS_INTERVAL=60 and
then with STATUS_INTERVAL=600. These were the results:
>>
>> # ./ra -Xnr /opt/data/argus/var/log/argus.out - host 192.168.111.39
>>    11:45:51.241371  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22       674666  691670398   CON
>>    11:46:51.241496  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22       728665  746638654   CON
>>    11:47:51.241563  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22       729780  748390504   CON
>>    11:48:51.241597  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22       733293  752190798   CON
>>    11:49:51.241631  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22       733537  752519850   CON
>>    11:50:51.241659  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22       734255  752514878   CON
>>    11:51:51.241729  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22       732836  751412980   CON
>>    11:52:51.241770  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22       374739  384106534   FIN
>> # ./racluster -Xnr /opt/data/argus/var/log/argus.out - port 49460
>>    11:45:51.241371  e d       tcp    192.168.111.137.49460     ->      192.168.111.39.22      5441771 5579444596   FIN
>>
>> Which shows the transfer of the ~5GB file. Now with only a single interval for the transfer:
>>
>> # ./ra -Xnr /opt/data/argus/var/log/argus.out - host 192.168.111.39
>>    11:33:23.249123  e d       tcp    192.168.111.137.47119     ->      192.168.111.39.22      5443943 1284774452   FIN
>> # ./racluster -Xnr /opt/data/argus/var/log/argus.out - port 47119
>>    11:33:23.249123  e d       tcp    192.168.111.137.47119     ->      192.168.111.39.22      5443943 1284774452   FIN
>>
>> Which shows that the byte count has wrapped after 4GB (1284774452 + 4x1024x1024x1024 = 5579741748).
>>
>> So I guess the question is, what am I doing wrong? Do I need to compile argus in a certain way or configure it
differently? Or perhaps this is related to the clients (unlikely since racluster seems to have no problem
showing the 5GB if the data is there).
>>
>>
>> 2.
>> To check the backward compatibility I used the ra tool from the argus-clients-3.0.4.1 to try and read a
file written by argus 2.0. Here are some output snippets of me trying to read the file with both, an old
client and new one:
>>
>> The old:
>> # ra -h
>> Ra Version 2.0.6.fixes.1
>> ...
>> # ra -r argus.2011-09-13-07-00-01.gz | head -2
>> 09-07-11 11:18:07.535387           man                    10.2.1.37  v2.0                                     1 0          0        0         0            0           STA
>> 09-13-11 02:49:01.914562           tcp                    10.2.2.86.8280        ->                 69.184.252.19.8292       3        6         384          435         CON
>>
>> and the new:
>> # ./ra -Xh
>> Ra Version 3.0.4.1
>> ...
>> # ./ra -Xr argus.2011-09-13-07-00-01.gz
>> <no output at all>
>>
>> So back to the same questions: what am I doing wrong/how can I use the new clients to read the old data? In my
random attempts to make this happen I did try to unzip the file first, but that made no difference.
>>
>>
>> Thanks for any help,
>> Ilija
>>

Attachment (argus-sample.out): application/octet-stream, 6468 bytes
manaf gharaibeh | 22 Sep 22:39 2011
Picon

Argus and DDoS detection

Hi,

Has anyone used argus for DDoS and scanner detection?
 
-Manaf
Carter Bullard | 23 Sep 01:32 2011

Re: Possible bug on output of racluster

Hey Ricardo,
Sorry for the delayed response. What version of the clients are you using?

It is always good to inspect the data that is in the intermediate file, in order to
see where the breakdown is.  Are the contents in your ra-output.argus file
reasonable?

Be sure and include the 'proto' when you are interested in aggregating by ports,
as the port numbers are somewhat meaningless without the proto that specifies
them.   The newer clients, like argus-clients-3.0.5.19,  should do this automatically.

If you are still having a problem, consider sharing the files so I can figure out
what is going on.

Carter

On Sep 14, 2011, at 8:32 AM, Ricardo S wrote:

> Hello all,
> 
> I'm trying to cluster my flow information by source port. It seems
> that racluster is doing it fine. But when printing the results, it
> seems to lose information of source and destination IPs and ports. To
> better understand the problem, see example below.
> 
> Did anyone also experience the same problem? Solutions? (or maybe, my
> commands are right?)
> 
> Thanks,
> Ricardo.
> 
> 
> Example: I have a file with flows already generated with argus. I use
> the client "ra" to collect only flows from a specific IP address. Then
> I use the client "racluster" to get information per source port.
> However, the output I receive from "racluster" does not contain the IP
> addresses or ports and, consequently, is useless.
> 
> Command: ra
> # ra -r flows.argus -w ra-output.argus - 'ip and src host sss.sss.sss.sss'
> 
> Command: racluster
> # racluster -r ra-output.argus -m saddr sport -s saddr sport daddr dport sbytes
> 
> Output from racluster:
>           0.0.0.0                   0.0.0.0                 128
>           0.0.0.0                   0.0.0.0                 128
>           0.0.0.0                   0.0.0.0                 111
>           0.0.0.0                   0.0.0.0                 111
>           0.0.0.0                   0.0.0.0                 582
>           0.0.0.0                   0.0.0.0                3759
>           0.0.0.0                   0.0.0.0                  64
>           0.0.0.0                   0.0.0.0                 582
>           0.0.0.0                   0.0.0.0                3512
>           0.0.0.0                   0.0.0.0                4745
> 

Attachment (smime.p7s): application/pkcs7-signature, 5901 bytes
Carter Bullard | 23 Sep 01:52 2011

Re: Argus and DDoS detection

Hey Manaf,
argus has been around for a number of years, and has been used for a lot of
DDoS and scanner detection work in the academic literature, and in various
university/corporations security systems.

We provide example programs in the argus-clients distribution, radark.pl is
an automated scanner detector.  It works off the premise that if a node attempts
to access a dark address (non-existing address) in your address space, more
than likely it is a scanner.   You can tell radark.pl what the thresholds should be
and it will provide a list of scanners that it thinks it saw in the flow records it reads.

It generally attempts to determine what is dark solely from the traffic that it sees,
so you can be cleaver and tell it what addresses are ' lit ' by seeding it aggregated
flow data from prior days, etc….

the DDoS stuff is pretty straight forward, but several early cyber forensics books
and magazine articles describe using argus for DDoS detection.  I am personally
interested in Degradation of Service, rather than Denial of Service, so I use argus
for that all the time.  Check out the " Publications " section of the argus web site
and there are some specific links that talk just about DDoS detection.

Carter

On Sep 22, 2011, at 4:39 PM, manaf gharaibeh wrote:

Hi,

Has anyone used argus for DDoS and scanner detection?
 
-Manaf

Attachment (smime.p7s): application/pkcs7-signature, 5901 bytes

Gmane