[asterisk-users] Playing with sipvicious ..

[Paul Hayes]

On 18/08/10 17:10, Gordon Henderson wrote:
>
> ... using it as a tool and understanding what it does...
>
> So one part of it's toolset identifys valid SIP accounts - and I was under
> the impression that alwaysauthreject=yes was supposed to stop this...
>
> However, it sends a request for a highly probably non-existent account,
> then sends requests for probably existing accounts and I guess compares
> the results - account not found vs. bad username or password... It thus
> trivially, and very quickly finds valid accounts when fed with a list of
> accounts to try in the first place (e.g. 100-999, or 1000-9999, etc.)
>
> I wonder if it's time to introduce yet another parameter  to it - which
> will cause asterisk to return the same error code for all 3 conditions -
> and return the "not found" error, even on bad username or password.
>
> It breaks the RFC even more, but might it be worth it?
>
> (I've just had 30GB of sipvicious traffic sent to my hosted servers in a
> 12-hour period - it came from what looked like a VPS host in France -
> trivially firewalled out, but even dropping the packets didn't stop the
> flood! It's so badly written it appears to just ignore any return codes
> that it doesn't want, or even no returns at all!)
>
> Gordon

I've been playing with this a fair bit recently too, if only to gain 
myself a better understanding of the attacks so as to be able to prevent 
them better.

I found that when sending Registers to Asterisk (I was testing with 1.4 
since all my deployments are 1.4), alwaysauthreject does actually stop 
it from being able to determine real extension numbers.  However I also 
found that making it send Invite requests means it can determine real 
extensions that are currently Registered.

I've been using OSSEC to block source IPs that attacks come from.  So 
far it seems to work well.  Once you start silently dropping the inbound 
SIP traffic from the attacker they seem to go away very quickly (once 
the door is shut, no point them carrying on).  I'm yet to see a more 
intelligent attack using distributed source IPs but I'm sure it'll 
happen.  The scans I see happening usually come from random dynamic DSL 
addresses and the like from all over the place (inc within the UK) so I 
suspect these are virus infected zombies, so a distributed attack is 
surely easily possible.

Something else I noticed is that once OSSEC is doing it's job (or 
whatever other automatic blocking script you use), the attacks stop.  I 
have my systems set up to email me when an attack is blocked and after a 
few days, the attacks stop.  Which I interpret as a sign that attackers 
are maintaining lists of known vulnerable IP addresses, which is common 
for things like ssh attacks, spam relays etc...

I don't believe modifying Asterisk code to send non-RFC compliant relies 
is a good idea, I prefer the security layer to be handled by something 
else on top of Asterisk.

I have also seen attacks exploiting bugs in Asterisk too, I'm not going 
to go into them here for obvious reasons but I guess these types of 
attacks will get more commonplace once people start getting a bit wiser 
to the current fairly basic port scan and extension enumeration attacks.

cheers,
Paul.