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. -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
