[Fwd: Broken Reset Filter, possible bug]
Nick Diel
ndiel at engr.colostate.edu
Mon Mar 10 15:16:09 EDT 2008
The ones below were aggregated, but I checked my original argus files
(non aggregated) and found they contain the same problem. I generated
my original argus files by reading pcap files, perhaps that is where the
problem lies?
Do you need a sample pcap file that generated one of these flows?
Nick
Carter Bullard wrote:
> Hey Nick,
> Hmmmm, looks like its an argus bug, in that we have a flow
> status indication of reset, but we don't have the TH_RST bit
> flipped in the flags field, which is what the filter is looking at.
>
> So the question is, did these records come straight from argus()
> or did they get aggregated along the way?
>
> Carter
>
>
> On Mar 10, 2008, at 1:03 PM, Nick Diel wrote:
>
>> I am not sure if this lists block emails with attachments (my
>> original didn't go through). So I am sending this without the
>> attachment. Let me know if I need to send attachments through other
>> channels.
>>
>> Nick
>>
>> -------- Original Message --------
>> Subject: Broken Reset Filter, possible bug
>> Date: Mon, 10 Mar 2008 10:37:22 -0600
>> From: Nick Diel <ndiel at engr.colostate.edu>
>> To: argus-info at lists.andrew.cmu.edu
>>
>>
>>
>> It appears that the filter "not reset" only works some of the time. I
>> noticed this trying to use the filter: "not ((syn or synack) and (fin or
>> finack or reset)." Then doing the following command gave me lots of
>> entries with resets.
>>
>> diel at morte:~$ ra -r /lander/dump-110707/argus/port80/argus.out -z - "not
>> ((syn or synack) and (fin or finack or reset))" | egrep "(s|S).*R"
>> 09:01:29.947638 e tcp 184.3.136.54.3000 ->
>> 87.123.62.161.www 9 3331 sSER
>> 09:01:29.949058 e tcp 184.3.136.54.3001 ->
>> 87.123.62.149.www 9 3545 sSER
>> 09:01:29.950426 e tcp 184.3.136.54.3002 ->
>> 87.123.62.169.www 17 7560 sSER
>> 09:01:29.952302 e tcp 165.72.129.19.1170 ->
>> 34.208.115.191.www 27 7275 sER
>> 09:01:29.958305 e d tcp 184.3.136.54.3003 ->
>> 87.123.62.145.www 12 4352 sSER
>> 09:01:29.959940 e tcp 184.3.136.54.3004 ->
>> 87.123.62.134.www 12 6051 sSER
>> 09:01:29.960089 e tcp 184.3.136.54.3005 ->
>> 87.123.62.148.www 12 6247 sSER
>> 09:01:29.968459 e tcp 164.34.224.106.3188 ->
>> 201.79.50.56.www 22 13350 sSER
>> 09:01:29.997532 e tcp 165.1.181.212.3415 ->
>> 50.17.254.186.www 5 1076 sER
>> 09:01:30.032242 e tcp 164.109.105.182.www ->
>> 35.69.108.245.11889 2 120 SR
>> 09:01:30.044153 e tcp 165.1.181.212.3416 ->
>> 50.17.254.187.www 5 1076 sER
>> 09:01:30.067214 e tcp 111.237.214.170.www ->
>> 157.216.170.55.2676 3 180 SR
>> 09:01:30.089935 e s tcp 184.3.186.45.2907 <?>
>> 192.48.235.79.www 188 107626 EfR
>> 09:01:30.100910 e tcp 166.240.172.90.59566 ->
>> 87.123.62.128.www 13 6634 sSER
>> 09:01:30.103517 e tcp 164.61.150.68.3211 ->
>> 110.11.67.104.www 12 4974 sSER
>> 09:01:30.115002 e tcp 166.240.172.90.59567 ->
>> 87.123.62.187.www 20 10100 sSER
>> 09:01:30.136030 e tcp 154.188.62.27.44895 ->
>> 192.48.236.65.www 45 25645 sER
>> 09:01:30.196479 e tcp 164.34.106.254.4943 ->
>> 111.101.7.193.www 94 89890 sSER
>> 09:01:30.203517 e tcp 37.41.109.12.www ->
>> 161.164.184.133.49588 26 8562 SER
>> 09:01:30.219369 e tcp 138.123.105.215.3823 ->
>> 164.34.222.121.www 474 39800 sER
>> 09:01:30.227540 e tcp 110.87.125.122.1297 ->
>> 164.61.200.76.www 7 2018 sSER
>> 09:01:30.262842 e tcp 36.177.74.81.www ->
>> 184.3.145.197.1789 13 13719 SEfR
>> 09:01:30.309841 e tcp 36.7.245.63.www ->
>> 161.164.204.185.4015 4 1043 SER
>> 09:01:30.346086 e tcp 164.109.84.242.www ->
>> 93.188.153.157.1149 35 24250 SER
>> 09:01:30.398819 e tcp 154.188.84.193.35920 ->
>> 36.132.97.243.www 7 1326 sSER
>> 09:01:30.422082 eI S tcp 62.122.56.21.1760 ?>
>> 165.72.184.212.www 4 240 ER
>> 09:01:30.476588 e tcp 110.87.125.122.14990 ->
>> 164.61.200.229.www 66 59404 sSER
>> 09:01:30.477389 e tcp 186.218.90.219.8462 ->
>> 37.28.161.174.www 10 3217 sSER
>> 09:01:30.493936 e tcp 186.218.123.100.57084 ->
>> 192.48.236.127.www 11 3698 sER
>> 09:01:30.528469 e tcp 157.216.249.22.3938 ->
>> 201.79.50.57.www 16 9274 sSER
>> 09:01:30.574783 e tcp 165.72.159.144.49402 ->
>> 192.48.236.205.www 7 3187 sER
>> 09:01:30.608215 e d tcp 161.164.237.92.2270 ->
>> 192.73.184.102.www 42 33320 sSER
>> ..........
>>
>>
>> I have attached a file with a few flow entries in them that have this
>> behavior.
>> Notice this unusual output with this sample file:
>>
>> diel at morte:~$ ra -r resetExample.argus -z
>> 09:01:44.589353 e tcp 164.109.174.238.42969 ->
>> 36.174.95.100.www 34 20482 sSER
>> 09:01:44.925242 e tcp 164.109.174.238.42970 ->
>> 36.174.95.100.www 74 38620 sSER
>> 09:01:45.112644 e tcp 164.109.174.238.42971 ->
>> 36.174.95.100.www 69 36967 sSER
>> 09:02:12.675158 e tcp 164.109.174.238.42973 ->
>> 36.174.95.100.www 108 68948 sSER
>> 09:03:41.503642 e tcp 164.109.174.238.42975 ->
>> 36.174.95.100.www 51 33970 sSER
>> 09:06:27.431113 e tcp 164.109.174.238.42998 ->
>> 36.174.95.100.www 7 2681 sSER
>>
>> versus
>>
>> diel at morte:~$ ra -r resetExample.argus -z - not reset
>> 09:01:44.589353 e tcp 164.109.174.238.42969 ->
>> 36.174.95.100.www 34 20482 sSER
>> 09:02:12.675158 e tcp 164.109.174.238.42973 ->
>> 36.174.95.100.www 108 68948 sSER
>> 09:03:41.503642 e tcp 164.109.174.238.42975 ->
>> 36.174.95.100.www 51 33970 sSER
>>
>>
>> Nick
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20080310/5e4e0388/attachment.html>
More information about the argus
mailing list