FOOD FOR THOUGHT Safe from hacking?

rchalk

Member
Joined
Feb 19, 2010
Messages
278
Reaction score
21
Location
N.E. GA, USA
I have a requirement for a PBX to be completely accessible using ATA's, and with various IP addresses, so firewall and port knocking are not practical. If I set up long complex extension numbers, and long random passwords such as are generated by FreePBX when adding extensions, and if my outbound routes only allow calls from these specified extension numbers, and if I use a non-standard SIP signalling port, is this reasonably safe? The server will be located behind a NAT router, and only the non-standard SIP port will be forwarded. Setup will only be possible by using VPN into the network via the router's VPN server.

Does anyone have any additional suggestions to make the system more secure, and still allow the ATA's to connect from various locations/IP addresses?

Thanks for any suggestions you may have.
 

jerrm

Guru
Joined
Sep 23, 2015
Messages
491
Reaction score
204
  1. Make sure fail2ban is setup correctly for the non-standard ports. I avoid fail2ban whenever possible, but if you need to be open to the world, it is worthwhile.

  2. If using long extension numbers anyway, start with a specific sequence and filter appropriately. ie:
    Code:
    iptables -I INPUT -p udp  -m multiport --dports 5060,5061  -m  string ! --string "sip:59237"  --algo bm --to 65535 -j DROP

  3. I'm a fan of geoblocking. It shouldn't give a false sense of security, but it can greatly cut down on the work fail2ban has to do.

  4. If there is any consistency of the "anywhere" endpoints, only allow the appropriate user agent(s).
    Code:
    iptables -I INPUT -p udp  -m multiport --dports 5060,5061  -m  string ! --string "User-Agent: Grandstream"  --algo bm --to 65535 -j DROP

  5. If option 4 won't work, at least filter out the common scanner user agents - a quick google should give a list and sample rules.
All the above can be hacked around if you are being targeted, but will greatly reduce visibility of the system overall.
 
Last edited:

phonebuff

Guru
Joined
Feb 7, 2008
Messages
880
Reaction score
58
I have a requirement for a PBX to be completely accessible using ATA's, and with various IP addresses, so firewall and port knocking are not practical.
I have the same requirement and I use a Dynamic DNS to track the location of the ATA's and allow the ISP to change them as they like (Although most stay very stable). Then I just use the Traveling Man capabilities to limit the connections to the 10 IPs that the various ATA's are sitting on at any given time.

Security through obscurity is going to be hacked sooner or latter -- I am still vulnerable, but to only 10 possible IP addresses instead of the entire internet.. Which is where the rest of what you discribed fits.
 

rchalk

Member
Joined
Feb 19, 2010
Messages
278
Reaction score
21
Location
N.E. GA, USA
phonebuff: the problem with ddns is that the ATA's do not have a client for updating, and the user does not have access to the routers at the various locations. There are potentially hundreds of locations, so this is impractical. Thanks for the suggestion though...
 

jerrm

Guru
Joined
Sep 23, 2015
Messages
491
Reaction score
204
phonebuff: the problem with ddns is that the ATA's do not have a client for updating, and the user does not have access to the routers at the various locations. There are potentially hundreds of locations, so this is impractical. Thanks for the suggestion though...
I swear I read somewhere someone had "re-purposed" a provisioning or firmware update url in an ATA to perform a dyndns update. As long as you could enter a url with a query string it should be pretty easy. This would work well with existing IPBX tools, but assumes some consistency in the enpoints.

On second thought, almost all atas/phones/softphones/etc support multiple accounts. A second, dummy pbx could be setup with nothing to compromise (no provider accounts, isolated from lan, etc). A registration to the dummy pbx could be required before allowing an IP past the firewall of the real pbx. Essentially the same concept as dyndns, easier to maintain than certificates, and should work with virtually any device or softphone. The real pbx would remain completely invisible to the world at large, only clients pre-authenticated to the dummy could see it. Some script work would be required, but nothing too heavy. Hmmm... this is off the cuff, but might be worth thinking through.
 
  • Like
Reactions: wardmundy

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
14,954
Reaction score
2,579
:chef::chef::chef::chef::chef:

Thinking out loud... the simple way to do this would be to have the user login to the authentication server which then would automatically send a PortKnocker-like command to the PBX using the user's actual IP address. This could be a permanent whitelist entry or a temporary one for a day or 3 hours or whatever. Then it could redirect the user to the IP address of the PBX, or not, if you used a web interface to obtain the credentials. Probably much more secure to not redirect the user since the bad guys would have no idea where to go to login to the PBX even if they succeeded in breaking into the authentication server.


Look at /etc/knockd.conf. The line you need to emulate is...

/sbin/iptables -A INPUT -s %IP% -j ACCEPT (temporary whitelist until iptables-restart)

/usr/local/sbin/iptables-knock %IP% (permanent whitelist)

You could send the command to the PBX by following this tutorial:

https://malcontentcomics.com/systemsboy/2006/07/send-remote-commands-via-ssh.html

It would look something like this: sshpass -p your-password root@FQDN.yourpbx.com "iptables-knock $IP"

This obviously could be very dangerous if someone logged into the authentication server and was smart enough to look in their .bash_profile script. Your PBX's root credentials will be in there. So the safe way (I think) is to make sure trap '' 2 is the first line in the script to disable Ctrl-C. Then see below for what comes next. Then the last line would be logout to force the user out of the authentication server immediately after sending the iptables enabling command to your PBX.

Code:
#useradd -m username
#passwd username
# create .bash_profile in /home/username
# .bash_profile for each user looks like this on CentOS 6 platform
# REMOVE THESE COMMENTS BEFORE USE
trap '' 2
ME=`whoami`
IP=`last -10 -i | grep "still logged in" | grep "$ME" | tr -s " " | cut -f 3 -d " "`
echo "Hello $IP"
# IPtables SSH command goes here
logout
 
Last edited:

DadinVa

New Member
Joined
Apr 20, 2016
Messages
9
Reaction score
2
You may be able to adapt my post to work with ATA's - just have user enter their IP address in the web site instead of havng the site automatically determine it. The technique uses a cheap cloud server as a relay. The user enters their id and a password and the site sends it to the asterisk machine. No port knocking, and the only ip address you need to allow in is the cheap cloud server. The post is https://pbxinaflash.com/community/threads/version-of-travelin-man-cheap-cloud-server-as-gateway.22857/
 

kyle95wm

Phone Genius Owner
Joined
Apr 16, 2016
Messages
519
Reaction score
88
Location
Midhurst, ON, Canada
I have iptables rules that help with this situation:

Code:
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ICMPALL - [0:0]
:IPSPF - [0:0]
:ASIP - [0:0]
:DPTS - [0:0]
:RLMSET - [0:0]
-A INPUT -p tcp --dport 5060:5082 -m conntrack --ctstate RELATED,ESTABLISHED -m recent ! --rcheck --name MYSIP -j DROP
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m recent --update --name RLM --seconds 600 --hitcount 1 -j DROP
-A INPUT -p icmp --icmp-type 255 -j ICMPALL
# Allow DHCP traffic
-A INPUT -p udp --sport 67:68 --dport 67:68 -j ACCEPT
-A INPUT -i eth+ -j IPSPF
# Replace YOUR_SSH_PORT with your server's SSH port!
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -j ASIP
-A INPUT -j DPTS
-A INPUT -m limit --limit 10/min -j LOG
-A INPUT -j DROP
-A ICMPALL -p icmp --fragment -j DROP
-A ICMPALL -p icmp --icmp-type 0 -j ACCEPT
-A ICMPALL -p icmp --icmp-type 3 -j ACCEPT
-A ICMPALL -p icmp --icmp-type 4 -j ACCEPT
-A ICMPALL -p icmp --icmp-type 8 -j ACCEPT
-A ICMPALL -p icmp --icmp-type 11 -j ACCEPT
-A ICMPALL -p icmp -j DROP
# Drop packets FROM bogon IPv4 addresses
# Delete the line below if your server uses this range:
-A IPSPF -s 10.0.0.0/8 -j DROP
# Same as above
-A IPSPF -s 172.16.0.0/12 -j DROP
# Save as above
-A IPSPF -s 192.168.0.0/16 -j DROP
-A IPSPF -s 0.0.0.0/8 -j DROP
-A IPSPF -s 100.64.0.0/10 -j DROP
-A IPSPF -s 127.0.0.0/8 -j DROP
-A IPSPF -s 169.254.0.0/16 -j DROP
-A IPSPF -s 192.0.0.0/24 -j DROP
-A IPSPF -s 192.0.2.0/24 -j DROP
-A IPSPF -s 198.18.0.0/15 -j DROP
-A IPSPF -s 198.51.100.0/24 -j DROP
-A IPSPF -s 203.0.113.0/24 -j DROP
-A IPSPF -s 224.0.0.0/4 -j DROP
-A IPSPF -s 240.0.0.0/4 -j DROP
-A IPSPF -s 255.255.255.255 -j DROP
# Drop packets TO broadcast/multicast/loopback IPs
-A IPSPF -d 0.0.0.0/8 -j DROP
-A IPSPF -d 127.0.0.0/8 -j DROP
-A IPSPF -d 224.0.0.0/4 -j DROP
-A IPSPF -d 255.255.255.255 -j DROP
# These are some bad TCP flags used in attacks:
-A IPSPF -p tcp --tcp-flags ALL NONE -j DROP
-A IPSPF -p tcp --tcp-flags ALL ALL -j DROP
-A IPSPF -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
-A IPSPF -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
-A IPSPF -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A IPSPF -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
-A IPSPF -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN -j DROP
# Reject NEW TCP packets w/ ACK flag. Someone could be sending packets with your server's IP as his fake IP
-A IPSPF -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset
# Drop NEW TCP packets w/o SYN flag
-A IPSPF -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
# Drop empty UDP packets (lengths 0 to 28)
-A IPSPF -p udp -m length --length 0:28 -j DROP
# Limit incoming NEW TCP connections to 10/sec for each IP (configurable)
-A IPSPF -p tcp --syn -m recent --update --name INSYN --seconds 1 --hitcount 11 -j DROP
-A IPSPF -p tcp --syn -m recent --set --name INSYN -j RETURN
-A IPSPF -j RETURN
# Change to ACCEPT if FTP server:
-A DPTS -p tcp --dport 21 -j DROP
# Remember to change your SSH port first!
# If you use port 22, change this to ACCEPT!
-A DPTS -p tcp --dport 22 -j ACCEPT
-A DPTS -p tcp --dport 23 -j RLMSET
# Change to ACCEPT if MAIL server:
-A DPTS -p tcp --dport 25 -j RLMSET
# Note: Port 80 and/or 443 are needed to access the FreePBX GUI.
# For security, do NOT open them here. Use SSH port forwarding instead.
-A DPTS -p tcp --dport 80 -j DROP
-A DPTS -p tcp --dport 443 -j DROP
-A DPTS -p tcp --dport 1433 -j RLMSET
-A DPTS -p tcp --dport 3128 -j RLMSET
# Change to ACCEPT if Internet-facing MySQL server:
-A DPTS -p tcp --dport 3306 -j RLMSET
-A DPTS -p tcp --dport 3389 -j RLMSET
-A DPTS -p tcp --dport 4899 -j RLMSET
-A DPTS -p tcp --dport 5900 -j RLMSET
-A DPTS -j RETURN
-A RLMSET -m recent --set --name RLM -j DROP
-A ASIP -p tcp --dport 5060:5082 -j ACCEPT
-A ASIP -p udp --dport 5060:5082 -m recent --update --name MYSIP -j ACCEPT
-A ASIP -p udp --dport 5060:5082 -j DROP
-A ASIP -p udp --dport 10000:20000 -j ACCEPT
-A ASIP -j RETURN
COMMIT
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:BADSIP - [0:0]
:TCPSIP - [0:0]
:UDPSIP - [0:0]
:NEWSIP - [0:0]
# IMPORTANT: Replace "YOUR_HOSTNAME.no-ip.com" with the dynamic IP hostname you have set up!
-A PREROUTING -i eth+ -m recent --update --name MYSIP -j ACCEPT
-A PREROUTING -i eth+ -p tcp --dport 5060:5082 -m string --string "sip:YOUR_HOSTNAME.no-ip.com" --algo bm --icase -j NEWSIP
-A PREROUTING -i eth+ -p udp --dport 5060:5082 -m string --string "sip:YOUR_HOSTNAME.no-ip.com" --algo bm --to 1500 --icase -j NEWSIP
-A PREROUTING -i eth+ -m recent --update --name BADSIP -j DROP
-A PREROUTING -i eth+ -p tcp --dport 5060:5082 -j TCPSIP
-A PREROUTING -i eth+ -p udp --dport 5060:5082 -j UDPSIP
-A TCPSIP -m string --string "sundayddr" --algo bm -j BADSIP
-A TCPSIP -m string --string "sipsak" --algo bm -j BADSIP
-A TCPSIP -m string --string "sipvicious" --algo bm --icase -j BADSIP
-A TCPSIP -m string --string "friendly-scanner" --algo bm -j BADSIP
-A TCPSIP -m string --string "iWar" --algo bm -j BADSIP
-A TCPSIP -m string --string "sip-scan" --algo bm -j BADSIP
-A TCPSIP -m string --string "sipcli" --algo bm -j BADSIP
-A TCPSIP -m string --string "eyeBeam" --algo bm -j BADSIP
-A TCPSIP -m string --string "VaxSIPUserAgent" --algo bm -j BADSIP
-A TCPSIP -m string --string "sip:[email protected]" --algo bm -j BADSIP
-A TCPSIP -m string --string "sip:[email protected]" --algo bm -j BADSIP
-A UDPSIP -m string --string "sundayddr" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "sipsak" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "sipvicious" --algo bm --icase --to 1500 -j BADSIP
-A UDPSIP -m string --string "friendly-scanner" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "iWar" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "sip-scan" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "sipcli" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "eyeBeam" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "VaxSIPUserAgent" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "sip:[email protected]" --algo bm --to 1500 -j BADSIP
-A UDPSIP -m string --string "sip:[email protected]" --algo bm --to 1500 -j BADSIP
-A BADSIP -m recent --set --name BADSIP -j DROP
-A NEWSIP -m recent --set --name MYSIP -j ACCEPT
COMMIT
 
  • Like
Reactions: chris_c_

jeffmac

Guru
Joined
Jan 16, 2008
Messages
215
Reaction score
3
There was a time, long ago, when I documented using a unique character string in the "user agent id" field of my ATAs and then used the string matching capabilities of IPTables to "allow" SIP connections where that string was found. Once the connection is allowed the "verify" option will keep it alive, generally. If it ever does close, the next Register with the user agent field in it will "allow" it again. (I also put in a "log" command for every string match that will subsequently be allowed).

The SIP Register command is sent in the clear, of course, so it could be "snooped" but I've never experienced any such attack (please don't consider that as definitive - I recognize that my traffic is not very exciting to the ordinary hacker - but I'm unaware of any incidents that have hacked it). If you have access to update the user agent field (I've used it in Obi's and SPA devices - nothing extremely new) then this might give you some narrowing of exposure.

Jeff
 

atsak

Guru
Joined
Sep 7, 2009
Messages
1,774
Reaction score
169
Can you choose the kind of ATA? Yeastar makes some with an OpenVPN client. That's what I do these days. Set those up with OpenVPN on your PBX (or firewall) and just open the OpenVPN port. Cert is required, very difficult to hack.
 

phonebuff

Guru
Joined
Feb 7, 2008
Messages
880
Reaction score
58
phonebuff: the problem with ddns is that the ATA's do not have a client for updating, and the user does not have access to the routers at the various locations. There are potentially hundreds of locations, so this is impractical. Thanks for the suggestion though...
My solution is to give the users / site manager a URL that handles the resolution update behind the covers and for the people who need it, SOHO we also setup a client on the Android. Lastly I had thought of putting a Pi application together that would just sit and handle IP reassignments.

While I understand your concern able the work load it's better than getting hit.. .
 

Members online

No members online now.

PIAF 5 - Powered by 3CX

Forum statistics

Threads
22,271
Messages
136,510
Members
14,503
Latest member
techwiz