voipwell.com
Partner PBX
Joined: 20 Sep 2005
Posts: 528
Location: Tannersville, Pennsylvania
|
 Posted: Mon Sep 12, 2011 10:08 am Post subject: Security |
 |
|
1. Brekeke Product Name and version:
2. Java version:
3. OS type and the version:
4. UA (phone), gateway or other hardware/software involved:
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/networkpatterns.html :
6. Your problem:
Most of us have come to expect frequent scanning attacks by scanners trying to guess a password with many login attempts. Brekeke provided a dial plan entry to help deal with it.
However, we saw a new attack recently that used attempted calls to guess the name and password. So, while we were always on the lookout for registration attacks, sending the name and password in call attempts with md5 challenge response was new to us.
We would like to offer our Brekeke community our solution to this problem and solicit others ideas.
We put a dial plan at the bottom of the sip servers dial plans that gives a false reponse. Not a 404 but we used a very uncommon error message. This way they get that dial plan and the false response if they have the wrong name and password or if they didn't match a dial plan. This prevents them from knowing if they matched the name and password correctly until they get both the name and password correct and the dial plan matching rules correct. For example if you require your callers to send calls to your pbx with a 9 prefix, if the hacker doesn't know that and send calls to your pbx without a 9 prefix, they will get the same error message as if they didn't guess the password yet.
The hackers first work on the name and password and after they get that they start getting 404's that let them know they are in but they haven't matched the incoming caller-id or outgoing number format that your dial plan expects. They simply keep trying different patterns for those two variable until they match. You can thwart them by giving them the same error whether they have the auth info wrong or the patterns wrong never allowing them to know why the call failed.
Hope this helps. |
|
