Wireless Carriers, Floating IPs, Responsive Firewall, ChanSIP & Other Plagues

General Help
1

I have roll-my-own distro installations of FreePBX 14/Asterisk 13 on AWS, Linode, Vultr (takes ISO direct from FPBX), and Digital Ocean. No problems except my Grandstream phones that worked under FPBX <14 needed reconfiguration. My issue. Glad to be on Centos 7 and nearing N or N-1 on Linux apps. Vanilla is good.

Fair warning: The following information will make perfect sense to super geeks, and should be avoided by FreePBX novices. It is extremely easy to render yourself inoperative with improper firewall rules.

The Responsive Firewall is great and has withstood hundreds of attacks from the usual countries and trolls without a single successful intrusion. I have left Chan_SIP enabled because my remote endpoints are behind variable telco IPs or softphones on roaming mobile phones. The latest hack hitting me has been sip-external attempts on the devices. None have been successful as I use oddball extension numbers and very complex passwords. However, I wanted to close this loophole without having to revert to No-IP (works great) or similar which just creates another point of failure in the system. Plus, allowing all those unsuccessful hacks is a bandwidth and processor drain.

My answer - turn off Chan_SIP in Responsive Firewall and go back to explicit permissions “by type.” Here is what I mean when I say “by type.” I noticed that I have never been hacked by a telco or mobile provider IPs. This is probably because it would be expensive - and traceable - to use mobile devices as hotspots for high volume devices running hundreds of thousands of transactions an hour. It is also traceable to use a telco IP address for such purposes. The question was, how to prevent the majority - if not all - bad guys while allowing responsible good guys to get into my system without leaving SIP ports open to the Internet at large.

There is a very handy Website https://whoer.net/checkwhois which provides very useful information when you input an IP address. For instance, when I put in the IP address currently assigned to my home, the site tells me the entire IP range to which my IP belongs. So, when I gave it ###.###.###.### it came back with ###.###.0.0/14. Now rather than relying on No-IP, I simply open up the entire 65K+ IPs which could possibly be assigned to me and remove that point of failure.

The Website above is very useful if you know the IP address - but what if you have no clue such as in the case of mobile providers? Now we resort to a Web site tracemyip.org and some geekery. This site will allow you to search an org name and show you all IPs which have been reported active recently. You can then take these individual IPs and scrape them into Excel or your favorite data sift and sort tool and use the Website above to get ranges. There are specific search terms to find each of the providers. I do not represent that these searches will provide an exhaustive list. To some extent this is up to your persistence and sleuthing. AT&T actually provides a listing of IPs for developers but I found that this list excludes most specific IPs which might be assigned to individual mobile phones and rather concentrates on infrastructure IPs. I used their list combined with the method above to develop my trusted list for AT&T Wireless. I used a posting in this forum plus the technique above to develop my Verizon Wireless list.

Remember, the data will not be handed to you on a plate by these sites. You must develop and refine your own. I just decided it was better to trust good, relatively safe people and lock down the world rather than continue refining blocklists. The load on my machines will be lower and the burden on me personally will almost go away.

I also highly recommend an app called Subnet Plus which allows you to fiddle around with blocks of IPs to reduce your firewall exceptions. It is available in the Apple App Store. Sorry Androids, I don’t know or care if it is available there! :smirk: In any event, it is that app tool and a combination of the techniques above which allowed me to develop these rules.

Once I had entered these rules, I tested by REMOVING all of my No-IP hostnames from the firewall rules. I watched my softphones deregister and immediately reregister using the carrier rules instead of No-IP permissions. Calls completed about 2 seconds faster simply because a step (and more importantly a point of failure) had been removed from the equation. Once I confirmed my rules were working I turned off Chan_SIP in the Responsive Firewall, power cycled my mobile, rebooted my premise endpoints and…success! Take that Palestinian, Russian, Chinese, Yemeni, and other trolls from this weekend!

Your results may vary. All I know is I can now just look at Bria Mobile as a single point of failure and not have to ask users “Is your No-IP app running? What does it say? Refresh the IP. Now what does it say? OK now let’s go to Bria while I step in front of this oncoming bus…”

I can confirm that the Verizon rules work - that is my carrier. Here are the searches for the major mobile carriers:

Verizon Wireless
https://tools.tracemyip.org/search–isp/verizon+wireless

AT&T Wireless
https://tools.tracemyip.org/search–org/at%26t+wireless
The AT&T-provided list to which I refer above can be found here - remember this is not exhaustive:
https://developer.att.com/technical-library/network-technologies/ip-addresses

T-Mobile
https://tools.tracemyip.org/search–isp/T-Mobile+USA

Sprint PCS
https://tools.tracemyip.org/search–isp/Sprint+PCS:-v-:&gTr=51&gNr=50

And to get you started, here are several million IP addresses for Verizon and AT&T, just cut and paste into your console or paste into a bash file. If pasting into bash, remember to remove all non-fwconsole lines or comment text lines out. If you find when you are using a softphone on a mobile device that you can not get in do one of two things: a) check your phone to see what IP address is currently assigned, b) check your Responsive Firewall to see which IP is currently blocked and then use the instructions above to add a new block to the permitted list for your carrier. Remember that carriers like AT&T, Sprint, and Verizon also have landline and business services with separate IP ranges. You should not need to enter those ranges for mobile softphone usage.

You must have the commercial sysadmin module (only $25, just buy it - your time is worth more than that) for all the firewall features to work.

Happy New Year!

Verizon Wireless

fwconsole firewall add trusted 166.128.0.0/9
fwconsole firewall add trusted 174.192.0.0/10
fwconsole firewall add trusted 97.128.0.0/9
fwconsole firewall add trusted 70.192.0.0/11
fwconsole firewall add trusted 69.96.0.0/13
fwconsole firewall add trusted 69.82.0.0/15
fwconsole firewall add trusted 66.174.0.0/16
fwconsole firewall add trusted 72.96.0.0/11
fwconsole firewall add trusted 75.192.0.0/10
fwconsole firewall add trusted 97.0.0.0/10

ATT Wireless

Note: The ranges below are expanded beyond the above technical reference for coding simplicity (200 line reduction!)

All addresses are AT&T Wireless - not AT&T - addresses

fwconsole firewall add trusted 107.64.0.0/10
fwconsole firewall add trusted 160.170.220.0/22
fwconsole firewall add trusted 166.128.0.0/13
fwconsole firewall add trusted 166.136.0.0/15
fwconsole firewall add trusted 166.138.0.0/16
fwconsole firewall add trusted 166.147.104.0/25
fwconsole firewall add trusted 166.170.0.0/19
fwconsole firewall add trusted 166.170.32.0/20
fwconsole firewall add trusted 166.170.48.0/21
fwconsole firewall add trusted 166.170.56.0/22
fwconsole firewall add trusted 166.171.56.0/22
fwconsole firewall add trusted 166.171.120.0/22
fwconsole firewall add trusted 166.171.184.0/22
fwconsole firewall add trusted 166.171.248.0/22
fwconsole firewall add trusted 166.172.56.0/22
fwconsole firewall add trusted 166.172.60.0/22
fwconsole firewall add trusted 166.172.120.0/22
fwconsole firewall add trusted 166.172.184.0/22
fwconsole firewall add trusted 166.172.188.0/22
fwconsole firewall add trusted 166.173.56.0/22
fwconsole firewall add trusted 166.173.60.0/22
fwconsole firewall add trusted 166.173.184.0/22
fwconsole firewall add trusted 166.173.248.0/22
fwconsole firewall add trusted 166.175.56.0/22
fwconsole firewall add trusted 166.175.60.0/22
fwconsole firewall add trusted 166.175.184.0/22
fwconsole firewall add trusted 166.175.188.0/22
fwconsole firewall add trusted 166.176.56.0/22
fwconsole firewall add trusted 166.176.120.0/22
fwconsole firewall add trusted 166.176.184.0/22
fwconsole firewall add trusted 166.176.248.0/22
fwconsole firewall add trusted 166.177.56.0/22
fwconsole firewall add trusted 166.177.120.0/22
fwconsole firewall add trusted 166.177.184.0/22
fwconsole firewall add trusted 166.177.248.0/22
fwconsole firewall add trusted 166.216.133.103/32
fwconsole firewall add trusted 166.216.133.208/28
fwconsole firewall add trusted 166.216.133.231/32
fwconsole firewall add trusted 166.216.133.231/32
fwconsole firewall add trusted 166.216.133.64/28
fwconsole firewall add trusted 166.216.157.0/24
fwconsole firewall add trusted 166.216.158.0/24
fwconsole firewall add trusted 166.216.159.0/24
fwconsole firewall add trusted 166.216.165.0/24

Below Added 1/8/2018

T-Mobile

fwconsole firewall add trusted 162.160.0.0/11
fwconsole firewall add trusted 172.32.0.0/11
fwconsole firewall add trusted 208.54.0.0/17
fwconsole firewall add trusted 208.54.128.0/19
fwconsole firewall add trusted 100.128.0.0/9
fwconsole firewall add trusted 50.28.192.0/18

Sprint PCS

fwconsole firewall add trusted 173.96.0.0/11
fwconsole firewall add trusted 174.155.64.0/18
fwconsole firewall add trusted 24.221.0.0/16
fwconsole firewall add trusted 66.87.0.0/16
fwconsole firewall add trusted 99.200.0.0/13
fwconsole firewall add trusted 70.12.0.0/15
fwconsole firewall add trusted 70.8.0.0/14
fwconsole firewall add trusted 70.14.0.0/16
fwconsole firewall add trusted 70.0.0.0/13
fwconsole firewall add trusted 107.32.0.0/11
fwconsole firewall add trusted 107.24.0.0/13
fwconsole firewall add trusted 108.102.0.0/16
fwconsole firewall add trusted 108.96.0.0/11
fwconsole firewall add trusted 184.204.0.0/16
fwconsole firewall add trusted 68.24.0.0/13
fwconsole firewall add trusted 68.240.0.0/13
fwconsole firewall add trusted 66.1.0.0/22
fwconsole firewall add trusted 72.56.0.0/13
fwconsole firewall add trusted 100.48.0.0/12

1 Like
2

If you are a “super geek” and looking for a scriptable network discovery tool, (no apple or excel needed), try

http://ipwhois.readthedocs.io/en/v0.15.1/

we aren’t allowed to post full scripts here but essentially, after building it and installing jq, then

.
.

TARGET=(whatever)
.
.
IP=$(getent ahosts $TARGET|grep STREAM|head -1|cut -d ’ ’ -f1)
ipset create -exist $IPSET hash:net comment 2>/dev/null
ipset test $IPSET $IP 2>/dev/null&&exit
JSON=$(ipwhois_cli.py --addr $IP --json --disallow_permutations 2>/dev/null)
[[ $JSON ]] || { echo $JSON ; exit; }
ENTITY=$(echo $JSON|jq ‘.entities[0]’)
NAME=$(echo $JSON|jq “.objects.$ENTITY.contact.name”|sed ‘s/"//g’)
CIDR=$(echo $JSON|jq “.network.cidr”|sed ‘s/"//g’)
CCODE=$(echo $JSON|jq “.asn_country_code”|sed ‘s/"//g’)
NETNAME=$(echo $JSON|jq “.network.name”|sed ‘s/"//g’)
REGISTRY=$(echo $JSON|jq “.asn_registry”|sed ‘s/"//g’)
.
.

is a core of what I use in my “ip2route.sh” bash script for both white and black ipset’s, add that to you fail2ban “action” , and sit back and watch . . .

3

Thanks Dicko! Since I always learn from your posts I will try this out tomorrow. I will be very sad if it does what I just spent 6 hours doing in a few minutes, but will be glad to further automate my processes!

2 Likes
4

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.