Argus-info Digest, Vol 77, Issue 14
Carter Bullard
carter at qosient.com
Thu Jan 19 17:49:13 EST 2012
Hey Jason,
I'll tally you in the "don't want it, don't need it, don't know why
anyone would use it" category :o)
Seriously, I do know where you're coming from, and it does kind of look
like an overly cute idea that may not work all the time, but we put it in
over 8 years ago, for some folks that wanted it, so I'm inclined to keep it.
When I see the string "PASS xxxxxxxx" in some user data printout,
the first thing I think is that something is striking out the actual password,
not that the password is actually xxxxxxxx. I think that /Elof figured it
out, I believe that that is the only reasonable conclusion.
The whole point is to provide some protection for those that don't know
what they are doing. Making it an option that the novice has to turn on
just isn't going to do it.
So, making it a documented feature, I'm hoping, is a good thing.
Configure your .rarc, and you'll never have a problem, at least now.
It is very easy to know when there is a plain text password. There are a
handful of protocols, ftp, pop, telnet, etc… that use them, and the preceding
tags are really easy to spot (PASS). I think a little program that you can
run on a daily file that could alert the user that there is an egg in their file,
maybe a good thing. This will do it:
ra -e PASS -R daily.directory
Carter
On Jan 19, 2012, at 4:29 PM, Jason Carr wrote:
> I'd rather it be an option that was disabled by default and you can enable
> filtering if you choose to. I really don't think it's ra's job to filter
> user data, other apps like ranonymize or simple sed would be better at
> doing this, so completely removing that feature completely is acceptable
> to me.
>
> I'm also looking at it from a network forensics point of view, which is
> not necessarily everyone's use case. I'd prefer untouched data almost
> 100%, if I want data manipulated I'll write a script to handle it.
>
> Any way that it's handled, it should be documented.
>
> I don't think we'd need any client that counts the plaintext passwords.
> Seeing XXXXXX might not be obvious, that might actually be a password.
> Not sure how to let someone know there's a password in there.
>
> Hopefully that's what you meant...
>
> On 1/19/12 1:28 PM, "Carter Bullard" <carter at qosient.com> wrote:
>
>> Hey Jason,
>> Being able to turn it off permanantly in the rarc file is not enough to
>> satisfy? I still think that you are more likely to get burned sharing
>> ascii data as a novice, than sharing binary data after perusing ascii
>> output, but that is just an opinion.
>>
>> I know that with the behavior being undocumented there was potential for
>> lots of problems, but with the new support, you still think its a problem
>> ?
>>
>> Would a specific client that counts plaintext passwords in files be
>> helpful? That may steer the novice into the idea that there maybe
>> passwords in there?
>>
>> Carter
>>
>> Carter Bullard, QoSient, LLC
>> 150 E. 57th Street Suite 12D
>> New York, New York 10022
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>>
>> On Jan 19, 2012, at 11:14 AM, Jason Carr <jcarr at andrew.cmu.edu> wrote:
>>
>>> I'd vote for swapping the behavior or eliminating the feature all
>>> together. I tend to want the user data in an untouched state. If I
>>> need
>>> to display or share data, I will manually hide the credentials or
>>> sensitive data.
>>>
>>> On 1/18/12 6:58 PM, "Carter Bullard" <carter at qosient.com> wrote:
>>>
>>>> OK, the count is now 2 - 2. The issue is valid, that we should not
>>>> set
>>>> incorrect expectations. We could print a warning to stderr, that ra.1
>>>> obfuscated content?
>>>>
>>>> Carter
>>>>
>>>>
>>>> On Jan 18, 2012, at 6:21 AM, elof2 at sentor.se wrote:
>>>>
>>>>>
>>>>> First I thought like CS Lee, that it was backwards to obfuscate
>>>>> without
>>>>> asking for it on the commandline. That's why I reported it to the list
>>>>> in the first place.
>>>>>
>>>>> Though, once Carter explained that the default was to obfuscate, to
>>>>> protect and prevent from accidental copy and paste of sensitive data
>>>>> into e.g. an email, I changed my mind.
>>>>> That is a cheap and simple protection from human mistakes that can get
>>>>> really embarrising/awkward if one paste the wrong data to e.g. a
>>>>> mailinglist.
>>>>>
>>>>> So I vote for the Carter approach. Obfuscate in the clients by default
>>>>> and use -x to reveal the real data.
>>>>>
>>>>> The real problem is that this was an undocumented feature. Once it's a
>>>>> known default (the new man pages), I only see benefits with the
>>>>> default
>>>>> obfuscation.
>>>>>
>>>>>
>>>>> Regarding that there are sensitive data in the binary argus file... It
>>>>> contain so much sensitive data that I always treat it as highly
>>>>> sensitive.
>>>>> I would think three or four times before sending an argus-logfile to
>>>>> e.g. a mailinglist, while a simple copy and paste of some ra output
>>>>> could possibly slip by.
>>>>>
>>>>> /Elof
>>>>>
>>>>>
>>>>> On Tue, 17 Jan 2012, Carter Bullard wrote:
>>>>>
>>>>>> Hey Dave,
>>>>>> Hmmmmm, I can buy this logic, and I'm not against a change. So 2 -
>>>>>> 1
>>>>>> for swapping the -x behavior.
>>>>>>
>>>>>> Any counter arguments ?
>>>>>> Carter
>>>>>>
>>>>>> On Jan 17, 2012, at 9:34 PM, Dave Edelman <dedelman at iname.com> wrote:
>>>>>>
>>>>>>> I have to agree with CS Lee. I think the major problem here is that
>>>>>>> the file contains authentication credentials in clear text. As long
>>>>>>> as
>>>>>>> the clients obfuscate this information is provides a false sense of
>>>>>>> security since it is not obvious that the clear text is stored in
>>>>>>> the
>>>>>>> data and is trivially retrievable.
>>>>>>>
>>>>>>> The logical next step is to craft a client that actually overwrites
>>>>>>> sensitive data in the argus output files and that can be used inline
>>>>>>> w or to produce a new file with w defanged.out
>>>>>>>
>>>>>>>
>>>>>>> (You did ask J )
>>>>>>>
>>>>>>> --Dave
>>>>>>>
>>>>>>> From: argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu
>>>>>>> [mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu]
>>>>>>> On
>>>>>>> Behalf Of Carter Bullard
>>>>>>> Sent: Tuesday, January 17, 2012 5:15 PM
>>>>>>> To: CS Lee
>>>>>>> Cc: argus-info at lists.andrew.cmu.edu
>>>>>>> Subject: Re: [ARGUS] Argus-info Digest, Vol 77, Issue 14
>>>>>>>
>>>>>>> Hey CS Lee,
>>>>>>> Not sure that would provide any help to avoid unintentional
>>>>>>> disclosure. Default behavior, I think, should provide some
>>>>>>> protection
>>>>>>> ? Any other opinions ? Seems we have a tie ?
>>>>>>> Best
>>>>>>>
>>>>>>> Carter
>>>>>>>
>>>>>>>
>>>>>>> , CS Lee <geek00l at gmail.com> wrote:
>>>>>>>
>>>>>>> hi Carter,
>>>>>>>
>>>>>>> My thought on this one - the password obfuscation.
>>>>>>>
>>>>>>> I would rather have default argus client print out the password
>>>>>>> without -x option, and with -x option it will obfuscate when
>>>>>>> printing
>>>>>>> the user data. That way new comers won't be confusing when they
>>>>>>> first
>>>>>>> use argus client. Since you already mentioned underlying data won't
>>>>>>> be
>>>>>>> changed anyway, so by default argus client should print generic data
>>>>>>> and with -x option the passwords will be obfuscated.
>>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>> On Wed, Jan 18, 2012 at 1:00 AM,
>>>>>>> <argus-info-request at lists.andrew.cmu.edu> wrote:
>>>>>>> Send Argus-info mailing list submissions to
>>>>>>> argus-info at lists.andrew.cmu.edu
>>>>>>>
>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>>>> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
>>>>>>> or, via email, send a message with subject or body 'help' to
>>>>>>> argus-info-request at lists.andrew.cmu.edu
>>>>>>>
>>>>>>> You can reach the person managing the list at
>>>>>>> argus-info-owner at lists.andrew.cmu.edu
>>>>>>>
>>>>>>> When replying, please edit your Subject line so it is more specific
>>>>>>> than "Re: Contents of Argus-info digest..."
>>>>>>>
>>>>>>>
>>>>>>> Today's Topics:
>>>>>>>
>>>>>>> 1. Re: Forced obfuscation in user data? (elof2 at sentor.se)
>>>>>>> 2. Re: Forced obfuscation in user data? (Carter Bullard)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> -
>>>>>>>
>>>>>>> Message: 1
>>>>>>> Date: Tue, 17 Jan 2012 15:31:27 +0100 (CET)
>>>>>>> From: elof2 at sentor.se
>>>>>>> Subject: Re: [ARGUS] Forced obfuscation in user data?
>>>>>>> To: Argus Development <argus-info at lists.andrew.cmu.edu>
>>>>>>> Message-ID:
>>>>>>> <alpine.BSF.2.00.1201171530410.75104 at deliverator.sentor.se>
>>>>>>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>>>>>>
>>>>>>> Sounds great!
>>>>>>>
>>>>>>> I'm just curious, what passwords (i.e. what protocols and services
>>>>>>> (or
>>>>>>> patterns?)) will the ra-clients hide?
>>>>>>>
>>>>>>> FTP passwords obviously.
>>>>>>>
>>>>>>> /Elof
>>>>>>>
>>>>>>> On Tue, 17 Jan 2012, Carter Bullard wrote:
>>>>>>>
>>>>>>>> Hey \Elof2,
>>>>>>>> OK, I fixed the bug so we're consistent in the effort, (replace an
>>>>>>>> '
>>>>>>>> if ' with a ' while ')
>>>>>>>> and I documented the feature in the rarc.5 man page, and I've
>>>>>>>> documented
>>>>>>>> the -x option in the ra.1 man page.
>>>>>>>>
>>>>>>>> Just a note. This 'feature' is there simply as a safety, so that
>>>>>>>> the casual
>>>>>>>> user doesn't inadvertently leak captured passwords. Its not
>>>>>>>> intended as
>>>>>>>> a real protection strategy. On the contrary, being able to
>>>>>>>> recover
>>>>>>>> clear
>>>>>>>> text passwords is a good security strategy. Since they are a bad
>>>>>>>> idea,
>>>>>>>> being able to detect them on the wire is the only way to enforce
>>>>>>>> the
>>>>>>>> policy.
>>>>>>>>
>>>>>>>> Thanks !!!!!!!
>>>>>>>>
>>>>>>>> Carter
>>>>>>>>
>>>>>>>> On Jan 17, 2012, at 7:48 AM, Carter Bullard wrote:
>>>>>>>>
>>>>>>>>> Hmmm, thanks, I'll fix that on this next round of clients.
>>>>>>>>> Carter
>>>>>>>>>
>>>>>>>>> On Jan 17, 2012, at 4:29 AM, elof2 at sentor.se wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ah, an undocumented feature.
>>>>>>>>>> -x solved it. Thanks.
>>>>>>>>>>
>>>>>>>>>> BTW, in my logs I found a bunch of plaintext passwords even when
>>>>>>>>>> not using -x. Apparently you only obfuscate the first PASS in a
>>>>>>>>>> session.
>>>>>>>>>> In sessions where the first login attempt(s) fail, ra will reveal
>>>>>>>>>> the password of the second and later attempts.
>>>>>>>>>>
>>>>>>>>>> <- Welcome-banner
>>>>>>>>>> -> USER foo PASS bar1
>>>>>>>>>> <- Login incorrect
>>>>>>>>>> -> USER foo PASS bar!
>>>>>>>>>> <- Login successful
>>>>>>>>>>
>>>>>>>>>> suser data printed by ra (without -x) show:
>>>>>>>>>> s[42]=USER foo..PASS xxxx..USER foo..PASS bar!..
>>>>>>>>>> ^^^^ ^^^^
>>>>>>>>>> while ra -x reveal both passwords:
>>>>>>>>>> s[42]=USER foo..PASS bar1..USER foo..PASS bar!..
>>>>>>>>>>
>>>>>>>>>> /Elof
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, 16 Jan 2012, Carter Bullard wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey /Elof,
>>>>>>>>>>> Yes, that was a request. The obfuscation is done in the ascii
>>>>>>>>>>> printer in the clients.
>>>>>>>>>>> If you use the "-x" option, it will print them out.
>>>>>>>>>>>
>>>>>>>>>>> Carter
>>>>>>>>>>>
>>>>>>>>>>> On Jan 16, 2012, at 11:07 AM, elof2 at sentor.se wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I just looked at the suser data in my argus logfile.
>>>>>>>>>>>> It appears that argus is obfuscating the data even though I'm
>>>>>>>>>>>> not asking for it.
>>>>>>>>>>>>
>>>>>>>>>>>> ra -s suser:120 -r argus.log - dst host 2.2.2.2 and dst port 21
>>>>>>>>>>>> s[116]=USER myloginname..PASS xxxxxxxxx..CWD /foo/bar..TYPE
>>>>>>>>>>>> I..PASV..STOR gazonk.pdf..QUIT..
>>>>>>>>>>>>
>>>>>>>>>>>> The FTP password I entered was "foobar", not "xxxxxxxxx".
>>>>>>>>>>>> Somewhere, all FTP passwords are being obfuscated into
>>>>>>>>>>>> "xxxxxxxxx".
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 1.
>>>>>>>>>>>> Is the obfuscation done in argus (i.e. the logfile never even
>>>>>>>>>>>> contain the true password) or is it done in ra?
>>>>>>>>>>>>
>>>>>>>>>>>> 2.
>>>>>>>>>>>> Can this be turned off? I need the true data for evidence.
>>>>>>>>>>>>
>>>>>>>>>>>> 3.
>>>>>>>>>>>> If the obfuscation is performed in argus, won't this introduce
>>>>>>>>>>>> a
>>>>>>>>>>>> slight performance penalty? ...a few cpu cycles are wasted
>>>>>>>>>>>> verifying if the current packet need to be obfuscated, and if
>>>>>>>>>>>> so,
>>>>>>>>>>>> obfuscate it.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> My argus.conf:
>>>>>>>>>>>> ARGUS_MONITOR_ID=1.2.3.4
>>>>>>>>>>>> ARGUS_INTERFACE=mon0
>>>>>>>>>>>> ARGUS_OUTPUT_FILE=/foo/log/out.log
>>>>>>>>>>>> ARGUS_DAEMON=yes
>>>>>>>>>>>> ARGUS_ACCESS_PORT=0
>>>>>>>>>>>> ARGUS_GENERATE_MAC_DATA=yes
>>>>>>>>>>>> ARGUS_CAPTURE_DATA_LEN=120
>>>>>>>>>>>> ARGUS_FILTER=""
>>>>>>>>>>>>
>>>>>>>>>>>> My ra command:
>>>>>>>>>>>> ra -s suser:120 -r argus.log - dst host 2.2.2.2 and dst port 21
>>>>>>>>>>>>
>>>>>>>>>>>> /Elof
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> Message: 2
>>>>>>> Date: Tue, 17 Jan 2012 09:36:58 -0500
>>>>>>> From: Carter Bullard <carter at qosient.com>
>>>>>>> Subject: Re: [ARGUS] Forced obfuscation in user data?
>>>>>>> To: "Martin Olsson" <martin.olsson at sentor.se>
>>>>>>> Cc: 'Argus Development' <argus-info at lists.andrew.cmu.edu>
>>>>>>> Message-ID: <2FC2A2F9-C20F-4999-B6DD-A31F47D19BC3 at qosient.com>
>>>>>>> Content-Type: text/plain; charset="us-ascii"
>>>>>>>
>>>>>>> Oh, the algorithm is trivial, and if there are other situations, I
>>>>>>> will add.
>>>>>>> We just look for "PASS", and anything that is printable after that,
>>>>>>> unto
>>>>>>> a '\cr' or a '.', we'll put an 'x' in its place. (yes not perfect,
>>>>>>> but fast and
>>>>>>> it works for the most part).
>>>>>>>
>>>>>>> This is only when we printout the buffer. We never change the
>>>>>>> actual
>>>>>>> capture data in the argus record. As a result, we don't exclude
>>>>>>> the
>>>>>>> text while you "grep" the buffers. So you could match a record user
>>>>>>> buffer,
>>>>>>> because your pattern is in someone's password, and when you go to
>>>>>>> print it out, you may not see it in the output. Not sure what to do
>>>>>>> with
>>>>>>> that, but its a side effect of what we're doing.
>>>>>>>
>>>>>>> Carter
>>>>>>>
>>>>>>>
>>>>>>> On Jan 17, 2012, at 9:29 AM, Martin Olsson wrote:
>>>>>>>
>>>>>>>> Sounds great!
>>>>>>>>
>>>>>>>> I'm just curious, what passwords (i.e. what protocols and services
>>>>>>>> (or
>>>>>>>> patterns?)) will the ra-clients hide?
>>>>>>>>
>>>>>>>> FTP passwords obviously.
>>>>>>>>
>>>>>>>> /Elof
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Carter Bullard [mailto:carter at qosient.com]
>>>>>>>>> Sent: Tuesday, January 17, 2012 3:22 PM
>>>>>>>>> To: elof2 at sentor.se
>>>>>>>>> Cc: Argus Development
>>>>>>>>> Subject: Re: [ARGUS] Forced obfuscation in user data?
>>>>>>>>>
>>>>>>>>> Hey \Elof2,
>>>>>>>>> OK, I fixed the bug so we're consistent in the effort, (replace an
>>>>>>>>> ' if '
>>>>>>>>> with a ' while ')
>>>>>>>>> and I documented the feature in the rarc.5 man page, and I've
>>>>>>>>> documented
>>>>>>>>> the -x option in the ra.1 man page.
>>>>>>>>>
>>>>>>>>> Just a note. This 'feature' is there simply as a safety, so that
>>>>>>>>> the
>>>>>>>>> casual
>>>>>>>>> user doesn't inadvertently leak captured passwords. Its not
>>>>>>>>> intended as
>>>>>>>>> a real protection strategy. On the contrary, being able to
>>>>>>>>> recover clear
>>>>>>>>> text passwords is a good security strategy. Since they are a bad
>>>>>>>>> idea,
>>>>>>>>> being able to detect them on the wire is the only way to enforce
>>>>>>>>> the
>>>>>>>>> policy.
>>>>>>>>>
>>>>>>>>> Thanks !!!!!!!
>>>>>>>>>
>>>>>>>>> Carter
>>>>>>>>>
>>>>>>>>> On Jan 17, 2012, at 7:48 AM, Carter Bullard wrote:
>>>>>>>>>
>>>>>>>>>> Hmmm, thanks, I'll fix that on this next round of clients.
>>>>>>>>>> Carter
>>>>>>>>>>
>>>>>>>>>> On Jan 17, 2012, at 4:29 AM, elof2 at sentor.se wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ah, an undocumented feature.
>>>>>>>>>>> -x solved it. Thanks.
>>>>>>>>>>>
>>>>>>>>>>> BTW, in my logs I found a bunch of plaintext passwords even when
>>>>>>>>>>> not
>>>>>>>>> using -x. Apparently you only obfuscate the first PASS in a
>>>>>>>>> session.
>>>>>>>>>>> In sessions where the first login attempt(s) fail, ra will
>>>>>>>>>>> reveal
>>>>>>>>>>> the
>>>>>>>>> password of the second and later attempts.
>>>>>>>>>>>
>>>>>>>>>>> <- Welcome-banner
>>>>>>>>>>> -> USER foo PASS bar1
>>>>>>>>>>> <- Login incorrect
>>>>>>>>>>> -> USER foo PASS bar!
>>>>>>>>>>> <- Login successful
>>>>>>>>>>>
>>>>>>>>>>> suser data printed by ra (without -x) show:
>>>>>>>>>>> s[42]=USER foo..PASS xxxx..USER foo..PASS bar!..
>>>>>>>>>>> ^^^^ ^^^^
>>>>>>>>>>> while ra -x reveal both passwords:
>>>>>>>>>>> s[42]=USER foo..PASS bar1..USER foo..PASS bar!..
>>>>>>>>>>>
>>>>>>>>>>> /Elof
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, 16 Jan 2012, Carter Bullard wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey /Elof,
>>>>>>>>>>>> Yes, that was a request. The obfuscation is done in the ascii
>>>>>>>>>>>> printer
>>>>>>>>> in the clients.
>>>>>>>>>>>> If you use the "-x" option, it will print them out.
>>>>>>>>>>>>
>>>>>>>>>>>> Carter
>>>>>>>>>>>>
>>>>>>>>>>>> On Jan 16, 2012, at 11:07 AM, elof2 at sentor.se wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I just looked at the suser data in my argus logfile.
>>>>>>>>>>>>> It appears that argus is obfuscating the data even though I'm
>>>>>>>>>>>>> not
>>>>>>>>> asking for it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ra -s suser:120 -r argus.log - dst host 2.2.2.2 and dst port
>>>>>>>>>>>>> 21
>>>>>>>>>>>>> s[116]=USER myloginname..PASS xxxxxxxxx..CWD /foo/bar..TYPE
>>>>>>>>> I..PASV..STOR gazonk.pdf..QUIT..
>>>>>>>>>>>>>
>>>>>>>>>>>>> The FTP password I entered was "foobar", not "xxxxxxxxx".
>>>>>>>>>>>>> Somewhere, all FTP passwords are being obfuscated into
>>>>>>>>>>>>> "xxxxxxxxx".
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1.
>>>>>>>>>>>>> Is the obfuscation done in argus (i.e. the logfile never even
>>>>>>>>>>>>> contain
>>>>>>>>> the true password) or is it done in ra?
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.
>>>>>>>>>>>>> Can this be turned off? I need the true data for evidence.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3.
>>>>>>>>>>>>> If the obfuscation is performed in argus, won't this
>>>>>>>>>>>>> introduce a
>>>>>>>>> slight performance penalty? ...a few cpu cycles are wasted
>>>>>>>>> verifying if
>>>>>>>>> the current packet need to be obfuscated, and if so, obfuscate it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> My argus.conf:
>>>>>>>>>>>>> ARGUS_MONITOR_ID=1.2.3.4
>>>>>>>>>>>>> ARGUS_INTERFACE=mon0
>>>>>>>>>>>>> ARGUS_OUTPUT_FILE=/foo/log/out.log
>>>>>>>>>>>>> ARGUS_DAEMON=yes
>>>>>>>>>>>>> ARGUS_ACCESS_PORT=0
>>>>>>>>>>>>> ARGUS_GENERATE_MAC_DATA=yes
>>>>>>>>>>>>> ARGUS_CAPTURE_DATA_LEN=120
>>>>>>>>>>>>> ARGUS_FILTER=""
>>>>>>>>>>>>>
>>>>>>>>>>>>> My ra command:
>>>>>>>>>>>>> ra -s suser:120 -r argus.log - dst host 2.2.2.2 and dst port
>>>>>>>>>>>>> 21
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Elof
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -------------- next part --------------
>>>>>>> A non-text attachment was scrubbed...
>>>>>>> Name: smime.p7s
>>>>>>> Type: application/pkcs7-signature
>>>>>>> Size: 4367 bytes
>>>>>>> Desc: not available
>>>>>>> Url :
>>>>>>>
>>>>>>> https://lists.andrew.cmu.edu/mailman/private/argus-info/attachments/2
>>>>>>> 01
>>>>>>> 20117/8e918136/attachment-0001.bin
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Argus-info mailing list
>>>>>>> Argus-info at lists.andrew.cmu.edu
>>>>>>> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
>>>>>>>
>>>>>>>
>>>>>>> End of Argus-info Digest, Vol 77, Issue 14
>>>>>>> ******************************************
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> CS Lee<geek00L[at]gmail.com>
>>>>>>>
>>>>>>> http://geek00l.blogspot.com
>>>>>>> http://defcraft.net
>>>>
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120119/c210919d/attachment.bin>
More information about the argus
mailing list