IP blacklist restart on march 30

Status
Not open for further replies.

AWS2P

Silver Partner
Basic Certified
Joined
Jan 9, 2014
Messages
5,076
Reaction score
1,096
Hi ,
since several months nothing new was collected in pbxs blacklist,(great) today march 30 i've seen 2 same IP blacklisted on several pbx.
1585605179639.png

Is there a way to know if these IPs had already been blocked in 3CX global blacklist and freed after a while and restarting to attack pbxs or if they are completely new ?

Could it be posible to give in 3CX console, in blacklist section, an history info on this in front of each IPs ?
 
once local pbx blacklist block ips , is it possible to clear the list ? are they staying in global blacklist even deleted locally?
 
Thanks for the explanations. Still, I think this one is targeted to 3CX systems. Before, I never noticed the user agent 3CXPhoneSystem, but now always. And they are not thousands a day, just 5 or 10 or so, but all the other affected users in this thread report the same IPs in the same order (and probably on the same day). This would be an unbelievable coincidence if it was a generic attack against any SIP system.
 
Please folks just stop. 3CX knows what they are doing and they provided an excellent explanation. This is not 3CX specific. This is how script kiddies work. The fact that you see 3CX as the UA just means that 3CX has become popular enough for hackers to include them in their kits. That's actually a good thing from the perspective as 3CX being recognized as a player in the VoIP market.

As to why you see it hit some instances and not others it's really simple. They tell their script to scan certain IP blocks and they let it run and generally IP blocks belong to a single provider/ISP. As long as you stick with 3CX defaults (complex extension passwords, extensions not accessible from the outside) and you turn on the global blacklist you are fine. You aren't special enough to be specifically targeted. At best these script kiddies are looking to perform toll fraud which setting appropriate country restrictions and alerts will let you know well before it gets out of hand.

If you are really worried about security, you need to work with someone with a security background like @BrenttG . This isn't 3CX specific.
 
Last edited:
Shame all these cloud hosting providers don't have a firewall system that allows utilising constantly updated country lists that contain the IP blocks for a particular country. i.e. Only allow traffic from Australian IP's, resulting in 99% of attacks removed and remote users / users on mobile phone data connections to still connect.
 
Pretty sure most do, it's just not part of the 'free' firewall which is basically emulating a basic NAT device.You also have the option of setting up a software appliance of your favorite firewall if you want extr security like that.
 
Shame all these cloud hosting providers don't have a firewall system that allows utilising constantly updated country lists that contain the IP blocks for a particular country. i.e. Only allow traffic from Australian IP's, resulting in 99% of attacks removed and remote users / users on mobile phone data connections to still connect.

Country based IP Blocks can help, and also hurt, ISPs are known to trade these blocks around, sometimes between countries as needed, usually not very rapidly, but still you can end up with blocks registered in one country, while actually being in another. So this isnt as bulletproof as it sounds.

Restricting your PBX to only Australian IPs for example would actually cause your PBX to cease to operate also, because it has to talk to 3CX's licensing servers, webmeeting servers, update servers, stun servers, lets encrypt servers to be able to update certificates, the Debian updates repository servers, the android and apple push servers.

Then you also prevent your people from working abroad, or going on business trips abroad with their 3CX Extensions on their mobile phones due to only allowing those IPs.

Please folks just stop. 3CX knows what they are doing and they provided an excellent explanation. This is not 3CX specific. This is how script kiddies work. The fact that you see 3CX as the UA just means that 3CX has become popular enough for hackers to include them in their kits. That's actually a good thing from the perspective as 3CX being recognized as a player in the VoIP market.

@cobaltit is right on point here! The useragent part is forged by hackers for three reasons:
1. So that their hit on the blocklist appears harmless to a Sysadmin, and they ignore it.
2 So that their hit on the blocklist appears harmless to a Sysadmin, and a gullible sysadmin white-list's it and mistakes it as a user having problems.
3. To get past any useragent specific blocking done by Firewalls and WAF systems.
They are trying to fool dummies, nothing more.

As to why you see it hit some instances and not others it's really simple. They tell there script to scan certain IP blocks and they let it run and generally IP blocks belong to a single provider/ISP. As long as you stick with 3CX defaults (complex extension passwords, extensions not accessible from the outside) and you turn on the global blacklist you are fine. You aren't special enough to be specifically targeted. At best these script kiddies are looking to perform toll fraud which setting appropriate country restrictions and alerts will let you know well before it gets out of hand.

@cobaltit is absolutely on point here also, but i will add to it, Many scanning tools can also randomize the order of the IPs they scan these days, so that a Sysadmin does not see a scanner hitting each servers IP address in sequence and block it early in their scan attempt. They are trying to fly under the radar, but also scan as quickly as possible, that is how they try to accomplish both goals. So when you see IPs being skipped, that is why.

Setup 3CX's global blacklist as @cobaltit says, and i agree, and you will not have any issues, 3CX has more protection in its code below the surface that you don't see without looking under the hood, just because you don't see it does not mean it isnt there, I have seen it btw. Make sure all your extensions and your admin password follow strict password policies, at least equal to those 3CX uses within, if your really worried, make them longer manually.

99.99995% of the time those scans are automated, unless you have made an enemy, noone is actually at the keyboard attacking your 3CX Server, there are far easier methods to trick somebody into letting them in, usually with E-Mails.

And do make sure your system is set with country restrictions reasonably, as stated by @cobaltit The main goal is monetary, they get an extension online, and commit toll fraud.

An alternate i have seen before, though never successfully exploited on 3CX, was a hacker got an extension online to an Avaya IP500 which is shi7-for-brains security wise, and they used it to call people claiming to be microsoft, and extort money claiming to be cleaning up viruses, im sure you have heard of them, they use other peoples PBXs they hack into so the calls are untraceable. I was brought in to investigate strange operations on their network, and discovered they were using the IP500 not only to make fraud calls, but they had breached it enough to pivot into the servers of that facility as well, and were using them to launch paid flood attacks from the servers.

If you are really worried about security, you need to work with someone with a security background like @BrenttG . This isn't 3CX specific.

Im always happy to collect people's money to secure things, you would be surprised how often though that the best practices and common sense approaches are all I have to do to strengthen things significantly because someone else overlooked them, didn't care, or thought they new better falsely.
 
Last edited:
  • Like
Reactions: accentlogic
You can also block your SIP port to everyone but your trunk provider. 3CX Webclient, Mobile client, Windows client, SBC - all these can work with HTTPS or tunnel port just fine.

STUN Phones can also be whitelisted if they are on a static public IP, otherwise your can use the above solutions and avoid STUN altogether
 
  • Like
Reactions: accentlogic
You can also block your SIP port to everyone but your trunk provider. 3CX Webclient, Mobile client, Windows client, SBC - all these can work with HTTPS or tunnel port just fine.

STUN Phones can also be whitelisted if they are on a static public IP, otherwise your can use the above solutions and avoid STUN altogether

Yeah its not impossible, but it can be a bit of work, especially if static IPs are not available for the desk phones.
 
Hi Brentt,
No STUN used ,i'd like to let only SIP provider IP in touch for 5060, don't see what to do as lightsail give just basic rules .
 
That's a limitation of lightsail and why it's cheaper than standard AWS
 
  • Like
Reactions: accentlogic
Guys, it was too long to read why dont you change your SIP Port from default 5060 to something else :) Problems are solved :)
 
That's a limitation of lightsail and why it's cheaper than standard AWS
in my case i choose lightsail as it is a 3cx proposal, not because of the price , and didn't knew about so basic firewall service.

why dont you change your SIP Port from default 5060 to something else
Perhaps this could be an improvement idea for PBX EXPRESS install process to let us choose an alternative port instead of 5060.
 
Guys, it was too long to read why dont you change your SIP Port from default 5060 to something else :) Problems are solved :)

Then other firewalls that scrutinize unknown ports would trigger on it more often where as 5060 is a globally recognized protocol, solve one problem, create the possibility of another :rolleyes:
 
Problems , problems, where is the solution ?

So if we do a resume of situation, 3cx give approved solutions to host on cloud, but with some weak barrier due to poor rules availables on these hoster offer.
Then 3CX say to avoid being so often scanned with PBX reinstall using other port than 5060.
PBX EXpress most used and easy solution for install don't give choice so by default 5060 is automaticly set during install.
Now Brentt say changing 5060 to something else is also a bad idea.

what next?
 
Last edited:
Each option has pro's and con's and will depend on the subtle and non-subtle differences in each persons deployment.
 
Yes, when you know all details you need to take care it's ok to make an advised choice between offers, but when manufacturer validate a solution , you feel confident to use it even they don't explain your public IP will daily bombarded, but you can stay ZEN as we have something extremly robust to protect against attacks.
 
Last edited:
Yes, when you know all details you need to take care it's ok to make an advised choice between offers, but when manufacturer validate a solution , you feel confident to use even they don't explain your public IP will daily bombarded, but stay ZEN we have something robust to protect against bullet.

We are bulletproof!
 

Attachments

  • super-3cx.jpg
    super-3cx.jpg
    39.4 KB · Views: 4
  • Haha
Reactions: AWS2P
Love this Brentt;)
 
aws2p, best option for AWS LightSail is to use a iptables solution on the vps instance. Personally just installed 'ufw', using the following:

sudo apt install ufw
sudo ufw default deny incoming (sets it that any IN traffic not allows by rules below, it dropped)
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw allow 5090/tcp (allow ANY 3CX client / SBC etc to connect to 3CX Tunnel)
sudo ufw allow 5090/udp (allow ANY 3CX client / SBC etc to connect to 3CX Tunnel)
sudo ufw allow 9000:10999/udp
sudo ufw allow from <IP or IP-range/mask of your SIP provider> to any port 5060
sudo ufw allow from <IP or IP-range/mask of your SIP provider> to any port 5061
sudo ufw status numbered (will show all the rules you have entered)
sudo ufw enable (starts it running, make sure you've got your SSH allow entered or you'll boot yourself)


Note: re SSH above will allow from ANY, if you have a static IP(s) that you want to look it down to then you need to amend. If you lock it down, you need to also allow access from the AWS LightSail Internal IP range your on, and the IP range that shows when you enter 'last' when you first login. This is another LightSail IP range that your connections is actually coming from when you SSH in using their webGUI.

List of 3CX Ports - https://www.3cx.com/docs/ports/
 
Last edited:
  • Like
Reactions: AWS2P
Status
Not open for further replies.

Forum statistics

Threads
112,031
Messages
590,388
Members
164,982
Latest member
Costa Georgijevski