NEWS FLASH New TM3 Firewall for Wazo & RasPi 3

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
14,957
Reaction score
2,582

Just an FYI that we've streamlined the TM3 Firewall design for Incredible PBX for Wazo and Incredible PBX for Raspberry Pi 3. It's rolling out now with all new installs. We'll work on a retrofit for existing servers soon. The new version preserves the original WhiteList design meaning access to your server is limited to those on the same private LAN, those that you've WhiteListed with the access privileges you've specified, and SIP providers that we've WhiteListed for SIP/IAX access only as part of the original install. Nobody else can even see your server!

Background

IPtables always has had a couple of serious design flaws (in our opinion). While it allows FQDNs (as opposed to IP addresses) in the main config file, if one of them happens to be off-line when IPtables loads, then the entire firewall comes crashing down. Same goes for a typo in an FQDN. We worked around this with a testing methodology incorporated into iptables-restart, but it still was kludgey. The other flaw was, if an administrator accidentally executed iptables save, all of the FQDNs were permanently converted to IP addresses and you permanently lost the ability to support dynamic DNS.

New Design


In the new design, we've separated your custom IP addresses and FQDNs into a new file: /usr/local/sbin/iptables-custom. These settings get loaded individually AFTER the IPtables firewall is up and running. If an FQDN is off-line, then the rule simply doesn't get loaded, but it doesn't blow your firewall out of the water. You still manage your custom IP addresses (add-ip) and FQDNs (add-fqdn) in the same way. And you remove entries (del-acct) just as you did before. Finally, ipchecker still is used to test FQDNs for changes in dynamic IP addresses, and we've added a reminder in add-fqdn to make sure you add your entries to the ipchecker array if you want them checked and refreshed. We've also added HTTPS (port 443) support to the Web option when you add an IP address or FQDN. With the new design, you still reload the firewall, your custom rules, and Fail2Ban by running iptables-restart.

HINT: If you run /etc/init.d/iptables restart by mistake, then your custom rules and Fail2Ban don't get loaded.

PortKnocker Addition

PortKnocker previously let a remote user ping the server with a 3-digit code to temporarily add the remote user's IP address to the IPtables Firewall so that they could gain access. We now are adding the ability to make successful PortKnocks permanent just as if you had used add-ip on the server to add an IP address. You still can remove these entries using del-acct although you will have to know the date and time that the entry was added. The file names consist of timestamp.iptables in /root and the additions are made to the custom WhiteList in /usr/local/sbin/iptables-custom.

To enable permanent PortKnocker additions, run command: iptables-knock activate

Upgrading Existing TM3 Setups on Incredible PBX for XiVO or Wazo ONLY

You can upgrade existing XiVO and Wazo implementations of Incredible PBX only! If you already have WhiteListed one or more IP addresses with add-ip or FQDNs with add-fqdn, you will have to remove all of them with del-acct, perform the upgrade, and then add them back again with add-ip and add-fqdn. WARNING: Do NOT remove the WhiteList entry for the IP address from which you are making these changes or you may lock yourself out of your server. All of the new entries are stored differently now and are not part of the main IPtables config file. This makes starting and restarting the firewall more reliable. Be sure you remove them before performing the upgrade!

Once you have made note of your custom entries and removed all of them, issue the following commands while logged in as root:
Code:
chattr +i /etc/rc.local
cd /
wget http://incrediblepbx.com/tm3-xivo.tar.gz
tar zxvf tm3-xivo.tar.gz
rm -f tm3-xivo.tar.gz
chattr -i /etc/rc.local
sed -i 's|-A INPUT -p udp -m udp --dport 69 -j ACCEPT|#-A INPUT -p udp -m udp --dport 69 -j ACCEPT|' /etc/iptables/rules.v4
Now add your custom entries again with add-ip and add-fqdn. Be sure to add the IP address of the machine from which you are performing the upgrade FIRST so you don't inadvertently lock yourself out of your server! Customizing ipchecker is no longer required to keep FQDNs with dynamic IP addresses current. Don't forget to activate the new PortKnocker feature if desired.



 
Last edited:

krzykat

Guru
Joined
Aug 2, 2008
Messages
1,487
Reaction score
390
Location
South Florida
Ward, did you ever get a chance to look at the methodology we used for virtual whitelisting which utilizes a combination of registration on a restricted port, mac address, and DNS name instead of IP addresses to auto-add to the whilelist? We're using it for all our remote sites now and its working great.
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
14,957
Reaction score
2,582
Ward, did you ever get a chance to look at the methodology we used for virtual whitelisting which utilizes a combination of registration on a restricted port, mac address, and DNS name instead of IP addresses to auto-add to the whilelist? We're using it for all our remote sites now and its working great.
Yet another item that has fallen through the cracks. Thanks for the reminder, but where was it?? I can't find it. Senility is a bitch. :rolleyes:
 
Last edited:

sukasem

Guru
Joined
Sep 13, 2008
Messages
143
Reaction score
26
I always forget to uncomment or add account[@] line in ipchecker.
So I modified ipchecker a bit to automatically locate account.

#!/bin/bash
# Insert the account filenames to be checked below
# Remember to increment the account[#] for new entries

i=0
for fn in `ls *.iptables`
do
testip=`cat $fn | cut -f 2 -d " "`
if [ "$testip" != "" ]
then
account[$i]=$fn;
let i=i+1;
fi
done

#account[0]=sukasem0.iptables
#account[1]=sukasem1.iptables
#account[2]=home.iptables
#account[3]=sukasem2.iptables
Hope it useful for someone :)
 
  • Like
Reactions: wardmundy

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
14,957
Reaction score
2,582
You now can use PortKnocker to permanently add IP addresses to your WhiteList. This should simplify remote management. See above for details.

Tutorial for upgrading existing Incredible PBX for XiVO/Wazo servers with all of the new features has been added. See above for the procedure.
 

krzykat

Guru
Joined
Aug 2, 2008
Messages
1,487
Reaction score
390
Location
South Florida
I found a fun new piece to add to the IPtables. If you were so inclined to let people have access that attempted to get in with your DNS name and not your IP address:

A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:myname.com" --algo bm -j ACCEPT

I'm working on locking it down even further. The reason I'm working on this is for remote portable devices - primarily Bria - that will have IP's changing via the mobile network.

It is my firm belief that anyone trying to hack you will send SIP to 10.10.10.10 and not to myname.com
 

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
634
Reaction score
231
I found a fun new piece to add to the IPtables. If you were so inclined to let people have access that attempted to get in with your DNS name and not your IP address:

A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:myname.com" --algo bm -j ACCEPT

I'm working on locking it down even further. The reason I'm working on this is for remote portable devices - primarily Bria - that will have IP's changing via the mobile network.

It is my firm belief that anyone trying to hack you will send SIP to 10.10.10.10 and not to myname.com
It is technically impossible for anyone to successfully connect to your box on 10.n.n.n. as it is not routable through the internet, if you see traffic apparently coming from that address, it is either internal traffic, or traffic roufed through your external IP and spoofed, or a totally incompetent provider, myname.com can only respond in a 10.0.0.0/8 network internally and only with a badly configured name-server or as I said before an incompetent provider
 
Last edited:

krzykat

Guru
Joined
Aug 2, 2008
Messages
1,487
Reaction score
390
Location
South Florida
It is technically impossible for anyone to successfully connect to your box on 10.n.n.n. as it is not routable through the internet, if you see traffic apparently coming from that address, it is either internal traffic, or traffic roufed through your external IP and spoofed, or a totally incompetent provider, myname.com can only respond in a 10.0.0.0/8 network internally and only with a badly configured name-server or as I said before an incompetent provider
LOL - of course not. I just didn't want to give out any public IP addresses and was using that as reference. Let's say 178.32.x.x if it makes you feel better. I was talking philosophy and not literal names.
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
14,957
Reaction score
2,582
And, just for the record @dicko, Amazon S3 does route "non-routable" IP addresses (172.16.0.0/12) which is why we stopped supporting that platform. Anyone with an S3 account in your area of the world could access the private IP address of your server unless you also locked down the private subnet.
 
Last edited:

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
14,957
Reaction score
2,582
I found a fun new piece to add to the IPtables. If you were so inclined to let people have access that attempted to get in with your DNS name and not your IP address:

A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:myname.com" --algo bm -j ACCEPT

I'm working on locking it down even further. The reason I'm working on this is for remote portable devices - primarily Bria - that will have IP's changing via the mobile network.

It is my firm belief that anyone trying to hack you will send SIP to 10.10.10.10 and not to myname.com
We've actually used this on some of our demo servers but I wouldn't want to risk it for a real server running FreePBX.
 

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
634
Reaction score
231
oofed through your external IOP.
And, just for the record @dicko, Amazon S3 does route "non-routable" IP addresses (172.16.0.0/12) which is why we stopped supporting that platform. Anyone with an S3 account in your area of the world could access the private IP address of your server unless you also locked down the private subnet.

That is EXACTLY the problem with many cloud services, you share a network with "non routeable " networks because you are actually in one, therefore you expose your machine to every other palestinian knuckledragger in that same network, go think about it . . . I think you will find the same with OVH, tiscali and others. For me everyone of those networks, internal or external are hopefully in my ipset that drops them
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
14,957
Reaction score
2,582
@dicko: By default, no private LAN addresses are handed out to your servers with OVH, Vultr, Digital Ocean, or even CloudAtCost.
 

ou812

Guru
Joined
Oct 18, 2007
Messages
462
Reaction score
70
Ward, did you ever get a chance to look at the methodology we used for virtual whitelisting which utilizes a combination of registration on a restricted port, mac address, and DNS name instead of IP addresses to auto-add to the whilelist? We're using it for all our remote sites now and its working great.
Are you willing to post this configuration.

Gary.
 

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
634
Reaction score
231
@dicko: By default, no private LAN addresses are handed out to your servers with OVH, Vultr, Digital Ocean, or even CloudAtCost.

But the network's they hand out are often populated by "bad actors" even Frontier do that ( they inherited Verizon's copper here) , But if you don't have a problem with that, . . .
 

Members online

No members online now.

Latest Posts

PIAF 5 - Powered by 3CX

Forum statistics

Threads
22,273
Messages
136,528
Members
14,505
Latest member
athan