@basist88
Hi
As Dicko says, you have to change SSH (22) port and HTTPS (443),
Don’t use HTTP (80).
Try to accept all trusted IP addresses and reject the others.
Also, you can install RKHunter. It’s not the top, but it makes the job.
Or maybe…
If you’ve got the possibility to use a VPN, then do it. In this case, you may reject all from WAN (excepted VPN port), and accept all from VPN zone.
Just an idea like that.
You would have to check your logs, but that also assumes the attacked did not modify them. At this point, since I’m thinking you do not have extensive Linux experience I would take the system offline and build another. And go to your other systems to look for any oddness like unexpected calls being made, unexpected logins, etc.
To see who is logged in, can use ‘w’, ‘last’ commands assuming the system hasn’t been hacked in a way to conceal the attacker… Logs are in /var/log.
Thanks for all your suggestions.
As soon a we switched from a standard 5060 sip port to a non standard one, it registered the phones fine, but we started getting some strange NAT problems now. Some endpoints go unreachable after a few seconds of registration, while others are showing reachable. Why did we not get these problems with a standard port? We made sure we changed the binding port in the FreePBX and restarted the asterisk as well as rebooted the whole pbx. Also registered the phones properly with the new port. Some phones still go unreachable and don’t re-register. Some go unreachable and re-register instantly.
What could cause this?
Did you disable your “SIP Helper”
Dicko, where would this be?
On your router/modem , it might have another name, but ALG or SIP/VOIP should be a clue.
Yes, i’m using a Unifi USG. And I tried disabling sip alg, maybe didn’t test good enough.
Do I need to reboot the router and all phones after disabling sip alg on the router?
Also, does sip alg only work with the standard 5060 port?
commit,save should make it active, if your server is inside your LAN you will need to redirect your signalling port and your SDP port range to it.
The phones are remote and the PBX is on a cloud server with a static IP.
Also in this scenario, do I need to specify NAT - no in the sip settings in the PBX when it’s on a cloud server with a public IP? Our extensions are all PJSIP, but the NAT option is on a chan sip settings tab. I was wondering if that would make any difference.
Disabled SIP ALG in the USG but still, after rebooting all the phones, they register, and then most of them go unreachable (while still being registered) in the asterisk cli. So that when you call the endpoint, it says that the person is unreachable.
Did you forwards the traffic appropriately ?
Why do we have to forward anything if the PBX is on a public IP and some phones work fine?
We have never had to forward anything with the default SIP port.
Then that won’t be a problem and everything will work , No?
What do you think is the problem here? I’d really appreciate your input.
Hard to say, If I were you, I would consider the server compromised and build a new one with better protections up front.
We’re actually not using the compromised server anymore and are keeping it just to investigate what happaned to it. This is another server that we’re trying to make work with a custom sip port. While on yet another server, all the phones are able to register and don’t go unreachable. Also behind a USG and actually SIP ALG enabled. The phones are Yealink.
Using a non-standard port for SIP is a fairly weak security measure. The ‘secret’ port will eventually be discovered and the crackers will then beat on it.
As a test system, only allow access to the SIP port from the IP address(es) of your endpoints. In production, if a whitelist is impractical, use a VPN or SIP over TLS.
The USG by default has a 30 second UDP timeout, which is the cause of your registration loss. Although the ALG works around that, it causes other subtle issues and is not recommended.
Please try:
-SIP ALG: Found under firewall settings. Must be disabled. -SPI Firewall: Found under firewall settings. Must be disabled. -UDP Timeout: Found under firewall settings. Usually set to 30 seconds by default. Should be increased to at least 300 seconds. -SIP Transformations: Found under firewall settings. Must be disabled. -Consistent NAT: Found under firewall settings. Must be enabled.
Of the above, just increasing UDP Timeout should fix the registration loss, though the other changes may be needed for audio issues, etc.
However, no port forwarding should be needed.
Just tried setting it to 300 seconds, the phones register and after a few seconds go unreachable.
That indicates that the OPTIONS (qualify) was sent incorrectly by the PBX, not passed properly by the USG, or the reply was routed incorrectly back to the PBX.
At the Asterisk command prompt, type
pjsip set logger on
wait for a phone to register and then go unreachable, paste that section of the Asterisk log at pastebin.freepbx.org and post the link here.
In the GUI, Reports -> Asterisk Logfiles
Or, find the raw file in
/var/log/asterisk/full