argus-clients-3.0.5.30 now available

[Carter Bullard]

Ooops !!!!!
The link to the new argus-clients is:

   http://qosient.com/argus/dev/argus-clients-latest.tar.gz

Sorry for the typo !!!!
Carter



On Jan 23, 2012, at 10:31 PM, Carter Bullard wrote:

> Gentle people,
> The new clients development thread, argus-clients-3.0.5.30 is on the server:
> 
>    http://qosient.com/argus/dev/argus-clients.latest.tar.gz
> 
> This has changes  to address issues with password obfuscation in the user data buffers,
> when printed in ASCII.  There are changes in support/Config/rarc, ra.1 manpages, and
> the client library, to change the default printing behavior.
> 
> Consider updating your ~/.rarc file with the example in ./support/Config/rarc.
> 
> We are no longer obfuscating by default.  We now have an ARGUS_ASCII_OBFUSCATE
> printer that can be specified on the command-line (-M printer=<printer>) or in the rarc
> config files, that will do password obfuscation, and do a better job than before.
> 
> This version has many fixes to ratop.1, and some minor fixes for all the clients
> Radium got some attention for a problem with tracking remote clients that don't send
> any greeting strings (like scanners).
> 
> We've added port range filtering, so this type of filter now works.  
> 
>    ra -r file - udp port 23-512
> 
> There is a need for the range to not have any spaces in them, as the token "-"
> by itself is an arithmetic operator. I'll need to upgrade argus to understand the
> new filters, so if you try this and argus returns with "remote filter error",  use the "local"
> keyword before the filter, so that ra* doesn't send the filter to the remote argus.
> 
>    ra -S argus - local udp port 23-512
> 
> I've added these to the ra.1 manpage.
> 
> There should be an new argus-3.0.5.10 coming out next, to match the filter changes,
> and that contains some minor fixes.  I hope to have that out later this week.
> 
> Thanks for all the help !!!!!!!!
> 
> Carter
> 
> Carter Bullard
> CEO/President
> 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 23, 2012, at 3:58 PM, Carter Bullard wrote:
> 
>> Hey Scott,
>> Thanks for the email !!!!
>> Yes, this whole thing is chocked full of issues.  And the behavior that you point out is / was a bug that pretty much highlights why its probably a bad idea to be clever.
>> That bug is now fixed in argus-clients-3.0.5.30.
>> I've put up the new code, I'll announce it when I get back from lunch,
>> 
>> Carter
>> 
>> 
>> On Jan 23, 2012, at 3:32 PM, Scott A. McIntyre wrote:
>> 
>>> Hi,
>>> 
>>> I realise that this topic is pretty much covered, but, I had an actual use-case from overnight which I thought I'd share.
>>> 
>>>> 
>>>> I am very happy that the list worked as well as it did on this topic.  While I personally think that some form of protection
>>>> is necessary, many on the list pointed out a problem that I hadn't considered; how the obfuscation may mislead users,
>>>> which seems in the end to be more damaging.  I do hope everyone sees this as a good group solution.
>>> 
>>> There's some sort of a brute-force FTP "attack" going on at the moment - many thousands of attempts against admin and Administrator; in looking at the Argus flows, the current attempt at obfuscation is resulting in inconsistent results:
>>> 
>>> s[84]=USER admin..PASS xxxxxxx..USER admin..PASS fish..USER admin..PASS pimp..USER admin..	
>>> 
>>> d[235]=220 ProFTPD 1.3.2e Server ()[1.2.3.4]..331 Password required for admin..530 Login incorrect...331 Password required for admin..530 Login incorrect...331 Password required for admin..530 Login incorrect...
>>> 
>>> I've removed the other data, but, as you can see from the srcUdata and dstUdata, sometimes the passowrd is being xxx'd out, sometimes not - likely due to how the attacking script is recycling connections (dozens of attempts per second at the moment).
>>> 
>>> When faced with this type of data, it's tough to know if the password being used is actually xxxxxxx or something else.
>>> 
>>> Anyway, looking forward to the change!!
>>> 
>>> Scott
>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120123/3f1454de/attachment.html>
-------------- 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/20120123/3f1454de/attachment.bin>