[asterisk-bugs] [JIRA] (ASTERISK-24506) 403 Forbidden Fix for Big Loaded systems

[HZMI8gkCvPpom0tM (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223422#comment-223422 ] 

HZMI8gkCvPpom0tM edited comment on ASTERISK-24506 at 11/8/14 4:59 AM:
----------------------------------------------------------------------

To Michael L. Young
I am bit not understand what kind of security issue it create. 
Possible 2 different cases to get 403 Forbidden 
1) 403 Forbidden was resend from termination party 
2) 403 Forbidden originated by asterisk itself because not correct Authentication.
We not speak now about 403 for OPTIONS , SUBSCRIBE etc. Only for REGISTER and INVITE.
With 1st case nothing to discuss
second case possible to split in two subcases 
a) remote party sent not right password and got 403 Forbidden (Bad auth)
b) remote party sent not right username and got 403 Forbidden (Bad auth)
So what kind of security issue create my patch ? 
parsing of security log is not an solution because as practice show : on huge systems asterisk log in moment of attack increase extremely fast (we speak about attack 5 k and more new registrations per second per system). Types of attack against asterisk have big variation.  Any log parsing software completely kill system. In moment when server under registration and INVITE flood it not usable at all. Because well known fail2ban like scripts start to use 100 % cpu because all of them cannot work with fast increasing files. In any case i think that we touch now topic which will be interesting not only for people who want to protect their systems. I can give much more detailed description of issue but not sure that it have to be on public. Because we can give a description to somebody how to create effective attacks against asterisk.  
To  Rusty Newton
i completed  license agreement but every time you refuse it. 


was (Author: y2fbo4ievym5ve9u):
To Michael L. Young
I am bit not understand what kind of security issue it create. 
Possible 2 different cases to get 403 Forbidden 
1) 403 Forbidden was resend from termination party 
2) 403 Forbidden originated by asterisk itself because not correct Authentication.
We not speak now about 403 for OPTIONS , SUBSCRIBE etc. Only for REGISTER and INVITE.
With 1st case nothing to discuss
second case possible to split in two subcases 
a) remote party sent not right password and got 403 Forbidden (Bad auth)
b) remote party sent not right username and got 403 Forbidden (Bad auth)
So what kind of security issue create my patch ? 
parsing of security log is not an solution because as practice show : on huge systems asterisk log in moment of attack increase extremely fast (we speak about attack 5 k and more new registrations per second per system). Types of attack against asterisk have big variation.  Any log parsing software completely kill system. In moment when server under registration and INVITE flood it not usable at all. Because well known fail2ban like scripts start to use 100 % cpu because all of them cannot work with fast increasing files. In any case i think that we touch now topic which will be interesting not only for people who want to protect their systems. I can give much more detailed description of issue but not sure that it have to be on public. Because we can give a description to somebody how to create effective attacks against asterisk. 
To  Rusty Newton
i completed  license agreement but every time you refuse it. 

> 403 Forbidden Fix for Big Loaded systems 
> -----------------------------------------
>
>                 Key: ASTERISK-24506
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24506
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 13.0.0-beta2, 13.0.0-beta3, 13.0.0
>            Reporter: HZMI8gkCvPpom0tM
>            Assignee: HZMI8gkCvPpom0tM
>         Attachments: chan_sip403.patch, new.patch
>
>
> On big loaded systems with more than 40k subscribers 403 Forbidden (Bad auth) is only way to detect and block username scans which can create REALTIME database deny of service. As practice show - for frauders absolutely no matter is it 403 Forbidden or 403 Forbidden (Bad auth) they continue to send hundreds thousands registrations and invites with different credentials until finish their list.  Usage 403 Forbidden (Bad auth) best style to detect such attacks and stop them on firewall side instead to pass them through whole infrastructure to database. I included patch which return back 403 Forbidden (Bad auth) in chan_sip. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)