[Home]

Summary:ASTERISK-16137: Proposed method of avoiding registration probing bots
Reporter:John Covert (jcovert)Labels:
Date Opened:2010-05-24 12:39:29Date Closed:2011-06-07 14:00:25
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:As every Unix hacker knows, you can enter bogus usernames at the login: prompt and you'll still get a password prompt (except for an account which deliberately has no password).  This is so that someone cannot feed a dictionary of possible usernames at a system looking for valid usernames to crack.

SIP registration, however, immediately returns "404 not found" for bogus usernames, allowing just such an attack, and these attacks are now happening ALL THE TIME from bots located all over the internet.

I propose (and plan to implement, if no one else has) a modification to SIP registration which, when presented with a bad username, will treat it as though it were good, challenging for authentication, which will, of course, fail.  My client (who was just hacked to the tune of many thousands of dollars in calls [which I am certain did not transfer information; they just ran up the bill] to Sierra Leone) wishes to have this working this week, and I plan to implement it this Wednesday.

****** ADDITIONAL INFORMATION ******

As every Defcon hacker knows, VMS has been banned from Defcon as uncrackable, primarily because of its default configuration of taking evasive action when it comes under attack.  In addition to the above, but not quite as quickly, I intend to propose a design for and implement login failure evasion.  And who better to do it than me, who wrote some of the code (not the evasion code) in VMS LOGINOUT.
Comments:By: Jason Parker (jparker) 2010-05-24 12:49:48

This is exactly what alwaysauthreject=yes does.
By: John Covert (jcovert) 2010-05-24 13:06:34

good.

Then I propose making it the default.  I strongly believe that it is important to do so.
By: John Covert (jcovert) 2010-05-24 13:09:03

(and I also propose adding the evasion, later)
By: John Covert (jcovert) 2010-05-24 13:41:02

The scanning is really getting bad.  In the case below, a machine at amazon-ec2 has been compromised and is scanning:

[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"mike"<sip:mike@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"daniel"<sip:daniel@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"jacob"<sip:jacob@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"michael"<sip:michael@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"ethan"<sip:ethan@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"joshua"<sip:joshua@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"alexander"<sip:alexander@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"anthony"<sip:anthony@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"william"<sip:william@my.ip.address>' failed for '79.125.51.55' - No matching peer found
[May 24 09:31:46] NOTICE[29697]: chan_sip.c:19961 handle_request_register: Registration from '"christopher"<sip:christopher@my.ip.address>' failed for '79.125.51.55' - No matching peer found
By: Paul Belanger (pabelanger) 2010-05-24 14:08:05

I would suggest asterisk-dev mailing list or #asterisk-dev on IRC for more active discussion.
By: John Covert (jcovert) 2010-05-24 23:54:43

alwaysauthreject=yes takes care of the REGISTER case, but the INVITE case is a little bit different.

"Main" PBXs need to be able to accept "guest" access for ENUM, ISN, and SIPurl (on business card) calls.  Unfortunately, as currently implemented, if allowguest=yes, then alwaysauthreject applies only to REGISTER, not to INVITE.

One solution is to have one IP address for these types of access, and another IP address for registered devices.  With asterisk, as it exists today, we would need two separate asterisk instances, since we can't have one SIP address:port combo set to "allowguest=yes" and another set to "allowguest=no".

But another solution (which I propose implementing) is for "alwaysauthreject=yes" to still mean "alwaysauthreject" on INVITES -- ask those guest users for authentication.  They'll authenticate with whatever they're configured for (typically a null password).

You then let EVERYONE in -- your real users who authenticated correctly into their proper context, and everyone else into the default=x context (the "safe" guest context), so that the "prober" again cannot tell whether he has found a valid username or not.

/john
By: Paul Belanger (pabelanger) 2010-06-25 09:12:32

Suspending for now. As mentioned before this should be discussed on asterisk-dev mailing list or #asterisk-dev on IRC.  

Any patches are welcome.
---
Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines