Raspberry Pi SBC Exposed my WAN?

[PatrickMcLean]

I kept getting CM102001 Authentication failed requests every 10-20 seconds, all with a "Record-Route" linking to my Raspberry Pi's local IP, and a "To:" field linking to a random number@mywanIP (For example, [email protected].123).

Every attempt was a new number. Every attempted was blocked and blacklisted eventually (after reducing my authorization attempts from 25 to 3).

As soon as I turned off my Raspberry Pi SBC, they stopped.

I'm not an expert when it comes to Security, what did I do wrong, if anything? Is it safe to have my SBC running if people having determined the WAN IP and are making authorization attempts?

 

[leejor]

I'm assuming that this is a Raspberry Pi running the PBX and not an SBC. Attempts like this are actually quite common. Hacker Bots scan for a PBX , usually port 5060, then make brute force attempts to get in. 3CX is very good a blocking them, but you can also make use of a firewall for more security. I would increase the blacklist time, significantly.

 

[PatrickMcLean]

Sorry I should have been more clear, the PBX is running on Windows 7 virtual machine hosted on ESXI 6.0.

The Raspberry Pi is just being used for SBC.

 

[leejor]

Re-read and saw that you also had a RP SBC. So, this is originating from your SBC? The extension numbers involved are valid, on your PBX? Are users reporting issues? The SBC should be using the tunnel for calls.

 

[PatrickMcLean]

the TO: and FROM: field are both from my WAN IP of the SBC, which is a different WAN IP from the PBX. The extensions are NOT valid.

The "record-Route" value is the local IP of the Raspberry pi.

I would post the whole entry log here but I'm not sure what to blank out and what not to.

 

[leejor]

So the attempts are using the IP and not the FQDN?

 

[PatrickMcLean]

Yes, full WAN ip, not FQDN.

 

[leejor]

The fact that the extension numbers (have there been any PSTN numbers show up?), are not valid numbers, on your PBX, certainly suggests a hacking attempt. With attempts on my system, their IP is clearly shown, and can be blacklisted permanently.

 

[PatrickMcLean]

The "Contact" form shows a different IP, one I don't recognize, so I assume that is the hacker's IP, but they are sending the request "To:" and "From" the Raspberry Pi.

 

[leejor]

If the SBC is set to use the tunnel, the SBC should only be using port 5090, and traffic between it and the PBX, encrypted. Unless you are using an old version. Perhaps they are spoofing the SBC IP?
https://www.3cx.com/docs/3cx-tunnel-session-border-controller/

 

[PatrickMcLean]

I thought the SBC used port 5060?

 

[AWS2P]

No 5090 by default

 

[leejor]

5060 on the LAN side, from devices, but 5090 (WAN side) to and from the PBX. Read over the link I posted. If you are using an older version, then it may not be using the tunnel.

 

[PatrickMcLean]

I couldn't get my SBC to work (configure) unless I forwarded the Raspberry PI (where SBC was installed) IP to 5060. Once I did that, it worked and connected no issue.

 

[Saqqara]

Have you setup port Forwarding for 5090 , protecting the 3cx Server.

setup required for the firewall https://www.3cx.com/docs/manual/firewall-router-configuration/

as above communication between the sbc and 3cx server is on port 5090, but you need https port portwarded on the firewall as this is used by provisioning of the phones.

have you unticked the ’ Allow sbc ******’ under extension options

make sure you configure the phones to use sbc https://www.3cx.com/sip-phones/

 

[PatrickMcLean]

All the correct ports are forwarded for the server.

I just couldn't get my SBC to find to connect to my PBX until I forwarded port 5060 for the SBC ip.

I have since deleted that port forwarding rule and my SBC still works, no idea what that was all about. I haven't seen any authorization failed on that WAN or SBC since, but I am now receiving some on the WAN ip of my server, and also noticed a few "Malformed SIP requests" from "sipvicious".

 

[SteveITS]

I forwarded port 5060 for the SBC ip.

You shouldn't need to forward any ports to the SBC. It connects out to the 3CX server. They were probably just connecting in on port 5060 and hitting the SBC, so trying things to hack in or make calls.