I keep getting this error, have no clue what is going on and why its happening. Could anyone tell what this is and how i can resolve the issue. Very, very new to asterisk and don’t know where to go from here.
here is the error:
[Aug 30 16:59:05] NOTICE[2947]: chan_sip.c:16835 handle_request_register: Registration from ‘“217” sip:217@71.***.88.***’ failed for ‘180.87.43.83’ - Wrong password
[Aug 30 16:59:05] NOTICE[2947]: chan_sip.c:16835 handle_request_register: Registration from ‘“217” sip:217@71.***.88.***’ failed for ‘180.87.43.83’ - Wrong password
Please any and all help would be greatly appreicated.
but when i look at the cli, that is all that is there, is there a way to stop this. I am using a dialing software called vicidial. Please i have tried to block the ip with iptables. I also ran asterisk -rx “database deltree SIP/Registry” and then rebooted and i am still seeing this in the asterisk cli. Any useful tips i can try to stop this??
How did you tried to block this in iptables? Something as simple as “iptables -I INPUT -s 180.87.43.83 -j DROP”, assuming 180.87.43.83 is the source IP should work.
you do know that rebooting neutralizes that rule (unless you save your firewall configuration), right Just don’t reboot after you add the iptables rule(s).
Fail2ban is greate to have, a bit slow sometimes but does it’s job!
And as SGM is saying, a reboot will also clear the firewall rules that
fail2ban have done!
Here is another tip! (old one)
<sip.conf>
[general]
...
context=bogus
allowguest=no
alwaysauthreject=yes
...
If you are NOT going to have phones connecting to you from the outside keep allowguest=no!
alwaysauthreject=yes will give the script kiddis the same respons from your PBX when they try to guess the password whether or not they guessed a valid username.
@nypon: One addition:
Setting allowguest=no has the affect, that no outsidecall can go to the inside logic without a matching peer and (assuming that all peers are password-detected) without a succesful registrytion with Asterisk. This has also the side effect, that the box will not be reachable for ENUM-calls for which one may wish to allow guests. Assuming ENUM-calls should be possible the config should be better in a way like:
Assuming 123456789 is the destination defined for ENUM.
Another security approach is to use contactdeny/contactpermit for the phones in sip.conf if the IP-adresses/adress-ranges are known from which a valid reagistration attempt could come from.
@abw1oim: That is correct about allowguest=no and a empty default context for the incoming.
But to start with if you are a new Asterisk admin and you think you are being hacked, it can be a good thing to have allowguest=no, a empty default context and the alwaysauthreject=yes set.
I’m doing the same as you with the enum.
My default incoming context is [uri_in] and in that context I have:
exten => home,1,Macro(stdexten,SIP/6000,6000@intern-ank,)
exten => nypon,1,Macro(stdexten,SIP/Nypon,6002@intern-ank,IAX2/Nypon)
...
...
With this I can get called in by a eMail addresses: sip:home@example.com, sip:nypon@example.com
One nice thing would be to be able to use the MAC address of the connecting computer/phone instead of the IP-adresses.
But i’m not sure if this is possible!
I’m using Asterisk 1.4.
I agree with You, in the very beginning a “closed” system would be the easier start - however it’s a common misconception to set up allowguest=no, define no context (or any) and pack all diallogic together into this one and somtimes after this switch to allowguest=yes in order to be able to receive ENUM/Peer2Peer-calls without redesigning the dialplan logic. That’s why I prefer to define an abstract enum-guest-context from the very beginning …
Your question: Unfortunately the MAC-address is not part of any standard protocol header and therefor You won’t be able to detect it. The only way to achieve this is either a special additional header (depends on caller) or to “hack” the TCP/IP-protocol, but this seems to be a lot of overhead as even the MAC-address could be manipulated therein.
you do know that rebooting neutralizes that rule (unless you save your firewall configuration), right 
Just don’t reboot after you add the iptables rule(s).