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.