[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