TIPS Incredible PBX IPtables IAX2 port open?

bobkoure

Member
Joined
May 22, 2013
Messages
173
Reaction score
20
I was away from home this last week - and noticed that I could connect to my PBX (IncrediblePBX on CentOS minimal 64b) whether I'd port-knocked or not.
I wasn't super worried as IAX2 (udp 4569) is the only port forwarded in to my PBX, I'm using a 200+ char 'secret', and, as I don't have any of my DIDs on auto-renew, the most I'd lose is around $25.

But it's a puzzle, and I'd like to figure it out. I'm starting to come up to speed on iptables* today.
I generated an iptables text file with iptables-save > /etc/sysconfig/iptables. I've uploaded this file, renamed to iptables.txt (so the uploader will accept it)
Code:
# Generated by iptables-save v1.4.21 on Sat Feb 28 11:08:44 2015
*filter
:INPUT DROP [322:115893]
# lines deleted
-A INPUT -p tcp -m tcp --dport 113 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT
-A INPUT -p udp -m udp --dport 4569 -j ACCEPT
-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 32976 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4445 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -p udp -m udp --dport 69 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9022 -j ACCEPT
-A INPUT -p udp -m udp --dport 5353 -j ACCEPT
# lines deleted

The line with 4569 I take to read
append to INPUT chain, protocol UDP port 4569 ACCEPT
Which I think means 4569 is open.
Is that right?
Thanks!


*I see it's not standard on CentOS7, they have their own firewall app/service; I'm assuming Ward's script disables/hides that service and installs iptables/netfilter
 

Attachments

  • iptables.txt
    9.5 KB · Views: 3

bobkoure

Member
Joined
May 22, 2013
Messages
173
Reaction score
20
I looked at iptables a bit more (mostly trying to figure what exactly ACCEPT does - turns out it does just what you'd think).
From above, the following ports are open, no matter the inbound IP address
tcp 113 ident service
tcp 1723 PPTP
tcp 4445 HTTP/HTTPS proxy
tcp 32976 LogMeIn
tcp 9022 Private Ark Remote Agent
udp 10000:20000 VOIP
udp 123 NTP
udp 4569 IAX2
udp 5353 multicast DNS
udp 69 t*f*t*p
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
19,168
Reaction score
5,199
Not sure what your question is?? INPUT DROP in IPtables drops/discards all input that doesn't match an ACCEPT rule. At the time that version of Incredible PBX was released, 4569 was not viewed as posing a security threat because IAX2 has its own calltoken mechanism to safeguard access. In newer Incredible PBX builds, IAX2 is treated just like SIP. You need a WhiteList entry to gain access regardless of the calltoken setting. The reason for the change was that almost everybody started disabling call tokens without really appreciating what they were doing.

Be very careful using native iptables commands with Travelin' Man whitelists. iptables-save, for example, converts all FQDN entries into permanent IP addresses so you lose the flexibility of ever using dynamic DNS services.
 

bobkoure

Member
Joined
May 22, 2013
Messages
173
Reaction score
20
The question was, pretty much: hey! it looks like the IAX2 port is open in iptables. Is that right? (read up on iptables, travelin'man, fail2ban, knockd). Yeah, pretty sure it's open Is that a security hole? There's a raft of ip-specific rules that specifically open it up. So maybe it shouldn't just be open-in-general(?).

Newer versions have this port shut? Did something change to make it a security problem now? Time to go read up on call tokens (which I have not turned off).

Re travelin' man, yes I know that FQDN lookup happens when a rule is created (potentially becoming multiple rules), but thank you for the reminder. (I've been using iptables -nL -v to see what I've actually got).

Thanks!
 

bobkoure

Member
Joined
May 22, 2013
Messages
173
Reaction score
20
Came back to this thread to answer that question, once it occurred to me that'd you'd said exactly what the issue was.
I've been looking at IAX2 security - it looks pretty good.

Thanks!
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
19,168
Reaction score
5,199
Re travelin' man, yes I know that FQDN lookup happens when a rule is created (potentially becoming multiple rules), but thank you for the reminder.

The point is that, if you use a command such as iptables save, that permanently converts all FQDN entries in /etc/sysconfig/iptables to static IP addresses. So you would lose the flexibility of ever using dynamic DNS manipulation again.
 

bobkoure

Member
Joined
May 22, 2013
Messages
173
Reaction score
20
You mean this?
Just a word of caution. IPtables stores its setup in /etc/sysconfig/iptables, but it actually runs from an image in memory on your Linux server. As part of the load process, IPtables converts all FQDNs stored on disk to static IP addresses. This speeds up firewall processing enormously. While it's possible to add IPtables rules in memory without writing them to disk (as in the original Travelin' Man design), don't do it with Travelin' Man 3! You will lose these settings whenever IPtables is restarted by running any of the above scripts or whenever a refresh of FQDN IP addresses becomes necessary. Whatever you do, never ever run the command: service iptables save. This command is used to write the IPtables entries in memory to disk. In doing so it writes only static IP addresses to disk. This will erase (a.k.a. ruin) your Travelin' Man 3 FQDN setup and force you to start over with Step #1. Otherwise, none of your FQDN's would ever get refreshed because they've all disappeared and become static IP addresses.
 

bobkoure

Member
Joined
May 22, 2013
Messages
173
Reaction score
20
Looking at secure_iptables (from Travelin' Man 3).
If you don't mind my asking, why isn't there a
-A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT
?
Is it that established/related doesn't do well with SIP, so it makes sense to individually set the providers?
 

synack

Guru
Joined
Dec 31, 2013
Messages
227
Reaction score
56
I suspect there are a few wrinkles with UDP and connection tracking that makes it more stable the other way.
 

bobkoure

Member
Joined
May 22, 2013
Messages
173
Reaction score
20
Color me slow.
The script secure-iptables, that builds the iptables to be loaded under travelin' man comes with a file iptables.orig. Iptables.orig is used as the head of the file and, indeed, has an 'accept established/related' rule.
cp $basedir/iptables.orig $basedir/iptables

Actually... I might see an issue with secure-iptables.
The iptables.origthat comes with travelin' man is copied from /root/sysconfig - but only if there isn't already an iptables.orig there. The iptables.orig that's used as a base is the one in /etc/sysconfig.
My version of CentOS (minimal 64b) came with an iptables.orig in /root/sysconfig - and it's wide open ( :INPUT ACCEPT [0:0] ). And, because it already exists,it's not overwritten by the one that comes with travelin' man and so gets used as a base.

I'd suggest replacing
Code:
basedir="/etc/sysconfig"
if [ ! -f $basedir/iptables.orig ];
then
echo "Saving base iptables setup as iptables.orig."
cp /root/iptables.orig $basedir/iptables.orig
echo "Backup up original iptables as iptables.b4travman."
cp $basedir/iptables $basedir/iptables.b4travman
echo "done."
with
Code:
basedir="/etc/sysconfig"
if [ -f $basedir/iptables.orig ];
then
if grep -Fxq ":ACCEPT" $basedir/iptables.orig
  then
  cp $basedir/iptables.orig $basedir/iptables.orig.b4travman
  fi
else
echo "Saving base iptables setup as iptables.orig."
cp /root/iptables.orig $basedir/iptables.orig
echo "Backup up original iptables as iptables.b4travman."
cp $basedir/iptables $basedir/iptables.b4travman
echo "done."
fi

...or something like that
 

Attachments

  • CentOS_iptables.orig.TXT
    550 bytes · Views: 4

jackal

New Member
Joined
Sep 17, 2015
Messages
25
Reaction score
2
I looked at iptables a bit more (mostly trying to figure what exactly ACCEPT does - turns out it does just what you'd think).
From above, the following ports are open, no matter the inbound IP address
tcp 113 ident service
tcp 1723 PPTP
tcp 4445 HTTP/HTTPS proxy
tcp 32976 LogMeIn
tcp 9022 Private Ark Remote Agent
udp 10000:20000 VOIP
udp 123 NTP
udp 4569 IAX2
udp 5353 multicast DNS
udp 69 t*f*t*p
Bumping an older thread here, but I noticed some odd t*f*t*p activity (random IPs in Asia requesting a nonexistent file named /x) and was surprised to discover in my iptables rules the exact same set-up mentioned in the OP.

This is on a RentPBX image I set up October of 2015 with their PBX in a Flash Incredible PBX 13-12 with Incredible GUI (Centos 6.6) image, which was new at the time. I secured iptables and set up Travelin' Man 3 as instructed in the tutorials, so I was surprised to see such a gaping hole.

I've killed the port 69 rule to stop the t*f*t*p probes (since individual IPs that need access to t*f*t*p are already taken care of with Travelin' Man) but wanted to make sure there wouldn't be any unintended consequences from killing all of the other ones except the udp 10000:20000 range. I don't use IAX2, and none of the other services look familiar.

Any advice before I nuke the rest of those open ports?
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
19,168
Reaction score
5,199
You shouldn't even need the UDP 10000-20000 rule. In fact, it may be safer without it given the recent issues with RTP.
 

Members online

No members online now.

Forum statistics

Threads
25,779
Messages
167,505
Members
19,199
Latest member
leocipriano
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top