[asterisk-bugs] [Asterisk 0017386]: Proposed method of avoiding registration probing bots

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17386 
====================================================================== 
Reported By:                jcovert
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17386
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.2.8-rc1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-05-24 12:39 CDT
Last Modified:              2010-05-24 23:54 CDT
====================================================================== 
Summary:                    Proposed method of avoiding registration probing
bots
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0122352) jcovert (reporter) - 2010-05-24 23:54
 https://issues.asterisk.org/view.php?id=17386#c122352 
---------------------------------------------------------------------- 
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 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-24 23:54 jcovert        Note Added: 0122352                          
======================================================================