Re: [Sshguard-users] New patterns for Asterisk, how to cope with color codes?

[Mij <mi...@ss...>]

On Nov 29, 2010, at 13:57 , Joe Greco wrote:

> Related to http://www.sshguard.net/support/submission/detail/49ce7182028d8b6f3e3d/
> 
> Asterisk is a telephony PBX application; it handles VoIP and POTS phone
> traffic.  Because a PBX is essentially a switch for voice traffic, it's
> theoretically susceptible to attack, and in fact since many people use
> numeric extensions and trivial passwords, many times it turns out to be
> actually susceptible to brute force attacks.

This is a relevant and significant addition. Thanks for the accurate report,
I'll bring this up as prio. As we're in RC, it won't make it in trunk before 1.5
stable, but I can provide you with a separate snapshot to test with.


> VoIP typically uses UDP transport, so an attacker trying to guess at 
> your passwords will bombard your server with hundreds or thousands of
> packets per second of UDP traffic, essentially DoS'ing your server. 
> sshguard sitting live on a logfile from syslogd looks like the ideal 
> application to handle this.  Many other people are running things like
> fail2ban but it strikes me as suboptimal and requires python anyways,
> so a fast compiled daemon is a better choice.

People choose based on what Google lists higher, and google lists based
on what people link. So it's a spiral where elder stuff starts advantaged.
It's awesome to read enthusiastic feedback from people, but if you really want
to make a concrete difference you need to blog about it, or twitter it, or 
about it, or link to it.


> The patterns needed are
> 
> .*Registration from '.*' failed for '<HOST>' - Wrong password
> .*Registration from '.*' failed for '<HOST>' - No matching peer found
> .*Registration from '.*' failed for '<HOST>' - Username/auth name mismatch
> .*No registration for peer '.*' (from <HOST>)
> .*Host <HOST> failed MD5 authentication for '.*' (.*)
> .*Failed to authenticate user .*@<HOST>.*
> 
> But so far I'm having a little trouble getting even just the first one
> to work.  Maybe I'm just getting the rule structure wrong, but there's
> another difficulty: Asterisk may bless its logfiles with color escape
> codes.  I'm not sure the best way to cope with that.  I was trying just
> ".*" to cover for it.  Shouldn't that work?

Wildcards must be used with a grain of salt. They make the tool "dumb"
about what the log entry actually mean, and this can easily lead to log
injection vulnerabilities (another of the reasons why SSHGuard favors its
context-free parser over bare regular expressions). 

Does the default configuration dump color codes? We do favor solutions
working out-of-the-box, so if this is not the case we can just match the color
bytes with non-ascii ranges.


> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
> With 24 million small businesses in the US alone, that's way too many apples.
> 
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users