How to setup IPTables for Asterisk 1.6.2 on CentOS 5.4

So recently, a friend of mine setup his very first linux server.  Since he’s planning on setting it up as a web-server sitting out on the internet with a public IP, I advised he setup and use iptables.  Now I know there are other options out there (some would argue better options), iptables is what I like to use on my own servers, so that’s what I helped him set up.  Since I tend to setup iptables and forget about it, I had to go and look for some iptables tutorials.  While I was looking around, I didn’t find many that covered setting up iptables for use with asterisk, along with the other typical uses you may have on a server.  So that’s what this how-to is all about.

First things first, I want to point out, if you’re not careful when you’re setting up your iptables settings, there’s a very real possibility of blocking all remote access to your server.  If you’re working on your server remotely, be very careful, and be sure to read all of this article before proceeding!

First, let’s make sure we’ve already got iptables installed on our box.  It should be installed by default on most CentOS 4.x and 5.x installs.

# rpm -q iptables
iptables-1.3.5-5.3.el5_4.1

# lsmod | grep ip_tables
ip_tables              17029  1 iptable_filter
x_tables               17349  5 xt_state,ip_tables,ip6t_REJECT,xt_tcpudp,ip6_tables

With that out of the way, we can look at how iptables is currently setup, using the “iptables -L” command.  The following should be the default rules on a fresh CentOS 5.4 install.

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere            icmp any
ACCEPT     esp  --  anywhere             anywhere
ACCEPT     ah   --  anywhere             anywhere
ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:mdns
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

If for some reason iptables isn’t running yet, you can enable it by running

# system-config-securitylevel

Now, the defaults are fine and good for defaults, but they aren’t really what we’re looking for.  So at this point we’re going to clear them out, and setup a very basic default set of access rules.  I like to use the basic ruleset from the CentOS wiki, located here.

# iptables -P INPUT ACCEPT
# iptables -F
# iptables -A INPUT -i lo -j ACCEPT
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT

Let’s take a look at what we did here:

iptables -P INPUT ACCEPT – This sets the default policy on the input chain to ACCEPT, so we don’t lock ourselves out if we’re connected remotely via ssh.

iptables -F – This is the command to flush the current rule set and only use the defaults (which we just set to ACCEPT on inbound connections, which gives us a blank slate to work with without locking us out of our own box).

iptables -A INPUT -i lo -j ACCEPT – This is a simple rule to allow all access from the loopback adapter.  The -A switch means we’re Appending a new rule to the chain.  -i means this rule has to do with all traffic flowing through a network interface (in this case, the lo, or loopback, interface).  -j means to Jump to the ACCEPT action.  A lot of applications expect to be able to talk with the loopback adapter, so be sure to include this rule.

iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT – You should already recognize some parts of this line.  What’s new here is the -m switch, which we use to load a module (in this case, the ‘state’ module). The state module is able to examine the state of a packet and determine if it is NEW, ESTABLISHED or RELATED. NEW refers to incoming packets that are new incoming connections that weren’t initiated by the host system. ESTABLISHED and RELATED refers to incoming packets that are part of an already established connection or related to an already established connection.

iptables -A INPUT -p tcp –dport 22 -j ACCEPT – This rule is a very important rule, at least it’s important if you’re connecting remotely!  This rule is appended to the INPUT chain and says that any packets coming in on the tcp protocol (-p), on port 22 (–dport 22), should be accepted.  Port 22 is of course the default ssh port.  If you’ve changed your ssh port in your sshd_config, you would of course alter this line accordingly.

iptables -P INPUT DROP – Remember our first rule?  When we set the default policy for the INPUT chain to ACCEPT?  This line changes the default policy for the INPUT chain back to DROP, which is what is required if you want to actually block traffic coming into your server.  If you correctly set the previous line to allow ssh traffic, you shouldn’t lock yourself out at this point.

iptables -P FORWARD DROP – This rule is pretty much the same as the previous one, except that we’re setting the default policy for the FORWARD chain, which handles traffic flowing through our system from one interface to another (i.e if you’re using your server as a router, which in this case we’re not).

iptables -P OUTPUT ACCEPT – And finally, this rule allows all traffic to flow outwards from your server.

Now that we’ve got these new rules, we should save them so that they’re applied the next time we restart the iptables service.

# iptables-save

or

# service iptables save

If you want to learn more about iptables and the various switches available to you, I recommend you read the IPTables How-To on the CentOS wiki I linked to earlier.  There’s a lot of useful information there.

Now, if you want to run asterisk on your server that you’ve got protected with IPTables, you’ll need to setup a few specific rules.  Let’s go over those here:

# iptables -A INPUT -p udp -m udp --dport 5060 -j ACCEPT
# iptables -A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT
# iptables -A INPUT -p udp -m udp --dport 4000:4999 -j ACCEPT
# iptables -A INPUT -p udp -m udp --dport 4569 -j ACCEPT
# iptables -A INPUT -p tcp -m tcp --dport 5038 -j ACCEPT

Let’s take a look at what we’re doing here:

iptables -A INPUT -p udp -m udp –dport 5060 -j ACCEPT – This rule and the next are needed if you have SIP endpoints or a SIP connection to your ITSP.  UDP port 5060 is the port used for SIP traffic.  If you don’t want to accept SIP traffic from anyone, anywhere, you can further restrict this line by adding source IP addresses or networks with the -s switch:

# iptables -A INPUT -p udp -m udp -s 172.19.240.24 --dport 5060 -j ACCEPT
# iptables -A INPUT -p udp -m udp -s 172.23.129.58 --dport 5060 -j ACCEPT
# iptables -A INPUT -p udp -m udp -s 172.36.15.0/24 --dport 5060 -j ACCEPT

iptables -A INPUT -p udp -m udp –dport 10000:20000 -j ACCEPT – This rule goes hand in hand with the previous rule.  This is the rule that allows RTP traffic.  By default, asterisk uses a large range of rtp ports to establish rtp connections, and you have to set a large range of udp ports as well.  If you’re uncomfortable with this idea, you can trim down on the number of ports used for your RTP traffic in asterisk’s /etc/asterisk/rtp.conf file.

# cat /etc/asterisk/rtp.conf
[general]
rtpstart=10000
rtpend=10050

# iptables -A INPUT -p udp -m udp --dport 10000:10050 -j ACCEPT

A good rule of thumb is to have 4 ports per concurrent call you plan on having flow through your system, plus 10% for breathing room.  So if you plan on having at most 10 concurrent calls on your system at any time, configure asterisk to use 44 ports (10 calls x 4 ports = 40, 40 * 1.10 = 44).  Be sure the range in your firewall matches the range in your rtp.conf file.

iptables -A INPUT -p udp -m udp –dport 4000:4999 -j ACCEPT – This rule is used to allow udptl traffic, which is a T.38 transport protocol.  If you don’t plan on doing faxing, you can skip this rule.  I don’t have any handy rules of thumb for the number of udptl ports used per T.38 fax, so you may want to leave this rule at it’s default.  You can try changing it down, but until I hear otherwise from the folks at Digium, I’ll leave the defaults as the recommended.

iptables -A INPUT -p udp -m udp –dport 4569 -j ACCEPT – This rule is for IAX2 connections.  IAX2 is another VoIP protocol, much like SIP.  Unlike SIP, it only needs one port open on your firewall for both control traffic and audio / data traffic.  You don’t need to open any ranges of ports to allow multiple concurrent calls using IAX2 either, as it’s all handled through the one port.  If you plan on making any IAX2 connections through your firewall, be sure to open this port.

iptables -A INPUT -p tcp –dport 5038 -j ACCEPT – This rule is to allow connections to the Asterisk Manager Interface, or AMI.  If you’re not accessing AMI remotely, you should leave this rule off your firewall.

Now that you’ve got your rules in place, go ahead and test your system.  If everything seems to be working properly, save your new rules to your iptables config by running one of the following commands:

# iptables-save

or

# service itpables save

And that’s it!  You should be all set now.  If you have any questions, please feel free to leave a comment below.

Next week we’ll cover using Fail2Ban along with IPTables to secure your asterisk server from malicious and costly attacks.