argus client obfuscation

Scott A. McIntyre s.a.mcintyre at gmail.com
Mon Jan 23 15:32:05 EST 2012


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





More information about the argus mailing list