[Fwd: Broken Reset Filter, possible bug]
Carter Bullard
carter at qosient.com
Mon Mar 10 15:23:08 EDT 2008
So I have a fix, or at least something that should fix the problem.
I would rather fix argus, than put some bandaid in the client programs,
but because I don't have any packets to test, we'll have to just put
it in place and see what happens. I will clean up the filters as well,
but they actually look ok at this point.
I'll put up a new argus and clients tonight, if you could pick it
up and give it a run, that would be great. I will later put in a fix
to correct the clients so that the historical data will work as well.
Carter
On Mar 10, 2008, at 3:16 PM, Nick Diel wrote:
> 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/8b423c7c/attachment.html>
More information about the argus
mailing list