So its a major security flaw for asterisk to respond to an unregistered access attempt. It shouldn’t send a “fake auth” and let the hacker know he found a hot server, it should just sit quiet and let him think there is no server there at all.
I have “allowguest=no”, but the hacker just keeps hammering me.
So is there a way to stop the “fake auth” responses and force asterisk to ignore unregistered access? Even if allowguest=yes, it should still ignore guest access attempts to invalid extensions.
Is there a way to get his IP address?
Sorry for the negative tone, but this guy is really pssing me off.
If your firewall is open to SIP requests from the attacking network, it means that you could potentially have legitimate registrations from peripatetic phones, if not from that network, form large numbers of different networks. If the only incoming SIP requests are from your ITSP, you should, already, have firewall rules restricting them to the ITSP’s address range.
In that case, ignoring the request would make it difficult to debug connection failures from those phones.
Ok, sorry about that. I should have mentioned that I am using asterisk 1.8. The asterisk machine is a router running Tomato. The machine is outside the NAT directly on the internet with a static ip.
In addition to not having a super fast processor, the “Hard drive” is actually flash memory - so every time this idiot takes a swipe at me, he is literally physically damaging my machine because there is a limit to how many times you can write to flash.
In my setup, I need for anybody anywhere, with the proper credentials, to be able to register on my box. This is because I frequently travel and have to be able to get back into it with my android soft phone and hot spot. So just using a firewall isn’t going to work because the IP address I’m calling from is not known beforehand.
So far, the only thing I can think of is to find some non-standard port and switch to that. But that only postpones the problem as he would probably find that too in short order.
I’ve heard of Fail2Ban before, but where does it get the guy’s IP from? The only IP in the logs is my own.
I too use * on a router. I have no need to remotely access the Asterisk server and use callcentric, CSipSimple on an Android Handset. This is really your best option in the sense that it requires the least work and is effective.
If you must log into the system, ensure that there is encryption (TLS) when sending credentials. Using fail2ban is a good technique to limit attacks.
Sounds like we have nearly identical setups. I am using entware asterisk 1.8.10.1 on a toastman tomato usb build. I tried optware first, but asterisk crashed every time it went to play a sound file. With the entware, that problem went away. We are using the same router.
I currently don’t have TLS working, but that is the plan. I want to get everything else running good before I switch to encrypted. Also, I have one person who has an older grandstream that doesn’t support TLS, but he can stay non-TLS because he is on a fixed hard line. I’m mostly interested in TLS for when I’m at a public hot spot.
Where does Fail2Ban get the IP addresses of the bad guys from? They aren’t in the logs.
Do you know where there are any compiling instructions for asterisk on tomato based routers? Its starting to look like the only way this is going to stop is if I edit the chan_sip.c file and comment out the code that is responsible for advertising asterisk’s existence to hackers.
The advantage with DD-WRT is that OTRW is known to work with RT-N16 and Asterisk. OTRW standard services include stophack\stophammer which is very similar to fail2ban.
I would suggest using CSipSimple with a service like callcentric or use Talkatone with GV instead of trying to setup TLS. However, that being said, if you are interested in setting up TLS for the experience, then go for it! I would be very interested in the lessons learned and any configuration files you are willing to share.
I have been reviewing the sip protocol and it seems that they transmit a digest version of the password in a way that an eavesdropper could not use it. So TLS/SSL is not mandatory for reasonable password security while at a hotspot abroad. Its not going to stop people from listening in, but I don’t care so much about that.
I’m pretty sure that asterisk can be modified to stop sending responses to hackers. For those reading this that don’t know, here is the simplified asterisk<->user authentication:
[ul][li]The client registering first makes an attempt at registering that is always rejected. [/li]
[li]In the reject message from asterisk it tells the user-agent exactly how it wants the username and password sent. [/li]
[li]The user-agent then sends the authentication in the required MD5 format.[/li][/ul]
On the surface, it looks like asterisk has no choice but to come out of the port closet and admit that it exists. But there is still enough information in the original register packet to determine that the user-agent that is attempting to register is probably authentic. For example, the extension and caller-ID could be matched before sending a response. If they don’t match known values, then no response is sent and the hacker is not made aware of the server.
Also, in my testing, some UA’s (grandstream) send an MD5 hash of the password in their first attempt. This makes it very easy to separate the hackers from the users. Unfortunately, they don’t all do that.
While this isn’t enough to allow access to the server, its enough to grant them a response so they can properly log in.
So the bottom line is that it can be done, but it means that someone will have to modify chan_sip.c.
If the attacker has reasonable grounds to believe there is a SIP server associated with the address, alwaysuthreject actually gives less information. Failing to get any response makes it more likely that there is a SIP server; if you really wanted to discourage people you would send an ICMP for no such port, although you might find that those are dropped by over zealous firewalls.
Um, not really. I suppose that could be true if we were talking about a publicly known voip server such as voip.callcentric.com. In that case, the hacker knows exactly what IP’s and ports are used in advance. He doesn’t need to test to see if a server is there.
For everyone else, by staying quiet when a bad register attempt comes in, the hacker doesn’t know your machine from a machine not running voip. And if you use a non-standard sip port on top of that, any hacker attempts are him psing in the wind and he will soon realize that.
By staying silent, he gets the same response as he would if he was firewalled.
I looked at the source code for chan_sip last night. Its about 1M in size. I’ve never really worked on a source file that big before. That’s definitely not a good way to do it, but I think I can manage.
In addition to stealth mode, I’m going to look into the possibility of adding a netmask to the “AllowGuest” variable. That way, the options are “NO” = nobody can get in as a guest, “YES” = anybody can get in as a guest, and “xx.xx.xx.xx/yy” = only people with IP’s in the xx.xx.xx.xx/yy range can get in as guest. This is a patch specifically to get around callcentric’s security bug.
The existing “alwaysauthreject” doesn’t seem to do a whole lot. The normal response is “Hey you got the username right now try to guess the password.” With “AlwaysAuthReject” its more like “Sorry, try again”. In either case, the server is advertising its willingness to play with the hacker.
Sending a “port unreachable” ICMP message sounds interesting, but it would only work if all other ports return identical responses. Otherwise, its like knocking on someone’s door and hearing them yell “We’re not home” from behind the door. Of course, its also dependent on whether the hacker even looks at ICMP messages or not and if he can even receive them. But that brings up an interesting point - if the router normally returns ICMP messages for bad port attempts, then asterisk should return an identical ICMP message when unauthorized requests come in.