Need IPTables config Centos/OpenSBC to IP BX

projects
projects used Ask the Experts™
on
I've always used hardware firewalls and have not learned about IPTables other than very basic things such as adding a port or two. I have an application where I would prefer using Centos as a firewall because what I need through it is very simple, only two services. Of course, it would have to be  totally, completely, absolutely protected.

Here is what I need.

Centos 5.x, latest, fully updated. Bare minimum services/applications installed. Just want to use it as a router running opensbc.

Public to WAN would be only SIP/RTP, 5060 TCP/UDP and 10000-20000 UDP.

NIC0 (192.168.1.5/16) would be connected to the LAN side.
NIC1 (x.x.x.x) would be connected to the WAN side, direct to the router.

This server would have to co-exist with a main firewall on the LAN side which is at 192.168.1.1 (gateway conflict perhaps?). Traffic which comes into this server would have to be forwarded to 192.168.1.230/16 and that server would in turn reply. I cannot give the IP PBX at 192.168.1.230 a default gateway of the Centos server because I need two of them, one per WAN in order to use DNS SRV load balancing.

The reason I wanted to post this question here is the forum suggestions I've been given seem to have holes in them. I thought that perhaps posting this here, if someone posts the proper IPTables file, then others could agree or not in order to get a final, VERY secure but working config.

I wish to thank you in advance for perhaps taking this small challenge on.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
nociSoftware Engineer
Distinguished Expert 2018

Commented:
For public ONLY allow SIP 5060 and use statefull inspection and use the iptable- connectiontracker for SIP.
Then the statefull inspection + connection traccker will take care of RTP connections.

The Inside & Outside of a gateway box need to have different address ranges.
If you inside is 192.168.0.0/16 then the outside needs to be something different.

You would need to load the modules:

nf_nat_sip
nf_conntrack_sip

(unless it's an old kernel, the might be named ipt_conntrack...)

iptables -P INPUT ACCEPT
iptables -F
iptables -I INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ALLOW    # allow access for ssh from the inside
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD -p tcp --dport 5060 -i NIC1 -m state --state NEW -j ACCEPT
iptables -I FORWARD -p udp --dport 5060 -i NIC1 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i NIC0 -j ACCEPT                     # allow outgoing
iptables -t nat -I POSTROUTING -o NIC1 -j SNAT --to-source ?????????? # nat outgoing....
iptables -t nat -I PREROUTING -i NIC1 -j DNAT --to-destination 192.168.1.230....

You may get away (partly) with the routing problem to also use SNAT on the inside for connections to the PBX.
The PBX will not see public addresses but 192.168.1.5, YMMV on this.

Author

Commented:
Hi, thanks for the input. I think my question might have been too vague. When I read it, it sounds like I need help with everything including building the server which is not the case. The server would be centos updated to current.

I just need the iptables config so that I could try centos as a stand alone firewall for nothing but sip/rtp.

Connections would be coming INTO my network and on to an IP PBX. For the same of simplicity, let's say asterisk but I do use a couple of different types.

>The Inside & Outside of a gateway box need to have different address ranges.
>If you inside is 192.168.0.0/16 then the outside needs to be something different.

I had mentioned that nic0 would be a private IP, in fact, it would be 192.168.1.234 in this case.
Then nic1 would be connected to one of my public routers so would have it's own public IP.

My intention is to use OpenSBC on two of these centos servers which will act as proxy registration points for the IP PBX. I would have one on each WAN load balanced using DNS SRV.

Unfortunately, since I've never used iptables, I have no idea if the above is complete. I was sure that one setup I once used had some NAT settings in there as well.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
The bottom two lines (iptables -t nat) are the NAT setup.
Not complete because you need to specify the correct IP addresses.

The Postrouting is for outgoing traffic, the PRErouting is for incoming traffic.

I don't know which version of iptables you have seen (the one from Linux 2.4 or from 2.6).
11/26 Forrester Webinar: Savings for Enterprise

How can your organization benefit from savings just by replacing your legacy backup solutions with Acronis' #CyberProtection? Join Forrester's Joe Branca and Ryan Davis from Acronis live as they explain how you can too.

Author

Commented:
I need to quickly build a server so that I can give better feedback. I'll get on that first thing tomorrow.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
If you are running some kind of proxy things need to change. As FORWARD will not be used, but INPUT will.
Alsot the proxy needs to manage the RTP stack...

Author

Commented:
Right now, the setup is using vyatta with an application which handles sip/rtp proxy.
What I want to replace is vyatta because other than iptables, I better understand centos than I do vyatta.

The centos server would act as the firewall, the application would handle the sip/rtp.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
If you do not exactly need session management (accounting, billing etc) then you dont need an application for sip...

Author

Commented:
I need the SBCs for load balancing and for better reliability. Users connect to the SBCs, register there, then the SBCs talk with the PBX.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Right then that actualy acts as a proxy.
So you need INPUT rules, the nat rules are not needed for SIP then.
Because the kernel doesn't see FORWARDed SIP packets it cannot track the connections for RTP, so you need to handle RTP forwarding also in your SBC.
(You will need the conntrack module to open up RTP ports for access to your SBC.)
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Normal activation:

modprobe nf_conntrack_sip

iptables -P INPUT ACCEPT
iptables -F
iptables -I INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ALLOW    # allow access for ssh from the inside
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT -p tcp --dport 5060 -m state --state NEW -j ACCEPT
iptables -I INPUT -p udp --dport 5060 -m state --state NEW -j ACCEPT

#the RTP sessions are allowed through because they are related to a SIP session + the connection tracking.
this also needs to be made persistent.

Author

Commented:
I have installed a new server so that I can test this. It took a little longer than I had hoped.

So what I am hoping for is to paste something into iptables that will get things up and running. Fine tuning can come after that.

NIC0 is connected on the LAN side, 192.168.1.234.
NIC1 is connected to the router. Let's say the IP is 1.2.3.4/24

The lan side already has a router/firewall and it is at 192.168.1.1.

I wish to allow from public port 5060 UDP and TCP and ports 10K to 30K UDP only.

I will install opensbc on the same server. It will route the SIP/RTP traffic to the PBX on the LAN side.

nociSoftware Engineer
Distinguished Expert 2018

Commented:
http:#26550310 is a good starting point.

Author

Commented:
I have been trying to use the information but not really understanding iptables, I'm getting nowhere. This is why I was hoping for a complete config that I could paste in, go from there.

Not being lazy, just never, ever use iptables to going through the learning curve is what I'm hoping to avoid for this one quick test.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
You need to add the rules to the current config and then store that permanently.

I assume you have iptables service started by default, and that they are default:
You can check that with:

chkconfig | grep iptable

There should be a Yes after 3 and/or 5

Then you can issue the commands:
iptables -I INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ALLOW  
iptables -I INPUT -p tcp --dport 5060 -m state --state NEW -j ACCEPT
iptables -I INPUT -p udp --dport 5060 -m state --state NEW -j ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
service iptables save

to save it.

nociSoftware Engineer
Distinguished Expert 2018

Commented:
And for the conenction tracking you need:

echo "modprobe nf_conntrack_sip" > /etc/sysconfig/modules/nf_sip.modules
 chmod +x /etc/sysconfig/modules/nf_sip.modules

modprobe nf_conntrack_sip

Author

Commented:
Guess I have to look into this some more, none of the above commands worked :).

# chkconfig | grep iptable
chkconfig version 1.3.30.1 - Copyright (C) 1997-2000 Red Hat, Inc.
This may be freely redistributed under the terms of the GNU Public License.

usage:   chkconfig --list [name]
         chkconfig --add <name>
         chkconfig --del <name>
         chkconfig [--level <levels>] <name> <on|off|reset|resetpriorities>
[root@sbc9 sysconfig]# iptables -I INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ALLOW
iptables v1.3.5: Couldn't load target `ALLOW':/lib/iptables/libipt_ALLOW.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

Author

Commented:
The nf_conntrack_sip item doesn't seem to be installed. I only installed a very bare system to start with. What package is this with that I can yum it into the server?
nociSoftware Engineer
Distinguished Expert 2018

Commented:
ok, I only have Gentoo systems currently available.

chkconfig --list | grep iptable

If iptable is not available then chkconfig --add iptables should add it.

should work...
ALLOW should be ACCEPT.   (thinking about allowing traffic.., so the other two are OK).

nf_conntrack_sip is a kernel module, it should be part of the kernel.
hm. if the kernel is below i thought 2.6.27 it might still be called ip_conntrack_sip

so try
modprobe ip_conntrack_sip

....

Author

Commented:
Ok, guess I wasn't really thinking but I didn't add the path or go into the /sbin directory.
From there;
# chkconfig --list | grep iptable
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off

But yes, it's a new server so iptables is on by default.

#modprobe ip_conntrack_sip
The above command returned nothing but then since I've never run it before, I don't know if it's supposed to or not.

So next, I'm wanting to add the commands you've suggested;

# iptables -I INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ALLOW
iptables v1.3.5: Couldn't load target `ALLOW':/lib/iptables/libipt_ALLOW.so: cannot open shared object file: No such file or directory

Author

Commented:
Since the above didn't work, I just edited the additions into the file but that doesn't work either. I'm rather confused at this point anyhow. Earlier in this thread, some of the iptables entries included FORWARD and NAT settings but later on, just a few lines. I've entered those which doesn't work as I still seem to be missing things.

# more iptables
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
-I INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ALLOW
-I INPUT -p tcp --dport 5060 -m state --state NEW -j ACCEPT
-I INPUT -p udp --dport 5060 -m state --state NEW -j ACCEPT
-I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
COMMIT

# /etc/init.d/iptables start
Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: filter                    [  OK  ]
Unloading iptables modules:                                [  OK  ]
Applying iptables firewall rules: iptables-restore v1.3.5: Couldn't load target `ALLOW':/lib/iptables/libipt_ALLOW.so: cannot open shared object file: No such file or directory

Error occurred at line: 20
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Please change the ALLOW to ACCEPT, it was a typo from me.
iptables has been started yep.

modprobe returning nothing is OK.
you can check what modules were loaded by:
lsmod

You still need to get ip_conntrack_sip loaded on boot.

echo "modprobe ip_conntrack_sip" > /etc/sysconfig/modules/ip_sip.modules
 chmod +x /etc/sysconfig/modules/ip_sip.modules

Author

Commented:
There is no ALLOW in the current config, see above.

Author

Commented:
Ok, never mind that last post, I fixed it and it loads now.

Author

Commented:
Ok, so this now appears to be part one right?
I mean, I see rules for 5060 but not for the 10k-30k range or NAT or outside router as indicated earlier in the thread.

nociSoftware Engineer
Distinguished Expert 2018

Commented:
The RTP packets should be picked up by ip_conntrack_sip from the SIP packets.
The SIP packets are allowed through as an ESTABLISHED session,
the RTP packets are allowed as a RELATED session. And a temporary internal rule to allow them is created when the SIP INVITE passes.

Try it. (I have no rules on my firewall to open up 1000's of random assigned ports.
Just the 5060 and the connection tracking for SIP  (& FTP)

Author

Commented:
Just to confirm, this is what I have right now.

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
-I INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ACCEPT
-I INPUT -p tcp --dport 5060 -m state --state NEW -j ACCEPT
-I INPUT -p udp --dport 5060 -m state --state NEW -j ACCEPT
-I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
COMMIT

At this point, I can install, compile, build my opensbc application and you feel this is complete? What happened to the NAT and other settings early on in this thread?

I wish I would have learned iptables by now but it's something I just never had a use for.

The final part of the question has to do with having multiple firewalls on the LAN. You see, I have a multi-wan juniper firewall which is the main gateway device at 192.168.1.1. I will want one of these centos servers connected to each wan router on the public side so that I can load balance incoming connections.
Because these servers are going to be firewall devices for all intents and purposes, will this conflict with my already in place gateway? I cannot change the NAT IP on the asterisk servers to point to these because I can only have one gateway so don't want to confuse things.

Author

Commented:
Actually, my intended use of this is to run opensbc servers but I have two types of IP PBXs.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Nat is needed if you forward traffic, then the kernel needs to take care of changing the address on the way out.

Now you have a session listening or connecting from the device itself. So the socket will use the right address by definition.

Well you will never connect from the inside directly to the outside it you use a proxy. You will allways tell the PBX. to connect to your opensbc server, which will connect to the outside world.

You need to configure your SBC to also handle the RTP traffic, because SIP is not forwarded and handled by the kernel, the kernel also cannot directly handle RTP.

If a PBX is allowed direct access to the outside then you will get a challenge when to use which method....

On the outside the SBC servers need to have a different address from your Juniper FW's.

You might also want to take out the following rule:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
as it allows SSH access from the outside.

Author

Commented:
Yes, I don't want public side access to any services, especially ssh :).
So as far as things stand, it's ready.

How long can I keep the question open so that I can test it and report? It'll take a couple of days to get to that.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
I dont mind.

Author

Commented:
Can I close it but we can continue if you're ok with that?

Author

Commented:
On the public interface now, do I simply set up my NIC1 with the public IP/mask?
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Yes, and setup the correct default gateway. (your upstream router).
The password needs to be different from your current Juniper box off course.

Author

Commented:
Hi again.

So the default gateway of this centos server will have the router and my pbx will continue to have it's juniper gateway right.

What password, do you mean the centos box?

Author

Commented:
Not working yet, setup seems to be ok NIC wise. Should I post iptables again?

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xxx.xxx.xxx.64    *               255.255.255.240 U     0      0        0 eth1
169.254.0.0     *               255.255.0.0     U     0      0        0 eth1
192.168.0.0     *               255.255.0.0     U     0      0        0 eth0
default         xxx-xxx-xxx-78-Mi 0.0.0.0         UG    0      0        0 eth1

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0E:7F:B3:56:9E
          inet addr:192.168.10.9  Bcast:192.168.255.255  Mask:255.255.0.0
          inet6 addr: fe80::20e:7fff:feb3:569e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4985 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2181 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:363687 (355.1 KiB)  TX bytes:533508 (521.0 KiB)
          Interrupt:185 Memory:f7ef0000-f7f00000

eth1      Link encap:Ethernet  HWaddr 00:0E:7F:B3:56:7B
          inet addr:xxx.xxx.xxx.76  Bcast:xxx.xxx.xxx.79  Mask:255.255.255.240
          inet6 addr: fe80::20e:7fff:feb3:567b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2481 errors:5 dropped:0 overruns:0 frame:0
          TX packets:654 errors:0 dropped:0 overruns:0 carrier:0
          collisions:4 txqueuelen:1000
          RX bytes:232461 (227.0 KiB)  TX bytes:95576 (93.3 KiB)
          Interrupt:193 Memory:f7ff0000-f8000000

Author

Commented:
Using iftop on the server itself, I see no connections making it in.
Using wireshark on the pre-firewall/wan side, I see port 5060 connections which appear to be randomly changing which won't work. The pbx requires 5060.

I'm also receiving spoof errors from the main juniper firewall as we test this;

[00001] 2010-02-14 13:37:09 [Root]system-alert-00008: IP spoofing! From xxx.xxx.xxx.76:5353 to 224.0.0.251:5353, proto UDP (zone Untrust, int ethernet0/1). Occurred 4 times.

Of course, those ports aren't anything I am playing with.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Your PBX needs to be told that all conversations need to be handled by the SBC. The SBC is an active component in that story.
The same is for the reverse, you need to tell everybody to use the IP of the SBC and not the one of the Juniper to access your PBX.

There should be no need for the PBX to have a default route to the internet at large as it should not access that directly. (You only need that for default route for access to you internal network if that has multiple IP network segments.

About the password, Sorry that's for answering late at night I meant public IP address not password.

5060 is only the destination port the source port (from the PBX, SHOULD be different otherwise you can only open one communication channel).

The spoofing errors are from a multicast protocol known as mDNS (port 5353) ,
othernames are: avahi, zeroconf, howl.
mDNS can resolve names in a LAN it won't work  well on the internet.
you can block those with

iptables -I OUTPUT -o NIC1 -p udp --dport 5353 -j DROP

(and saving your iptables, or edit the saved one and load them).

Author

Commented:
>Your PBX needs to be told that all conversations need to be handled by the SBC.
>The SBC is an active component in that story.

Am I missing something in what you mean above?

Because the SBC is taking care of the NAT portion, the SBC and the PBX can simply talk over the LAN using a private IP now. At least, that is the intention. And since I will have multiple SBC on different WAN connections, I cannot give the PBX (multiples) any of one SBC since they allow for load balancing into the lan.

>The same is for the reverse, you need to tell everybody to use the IP of the SBC and not
>the one of the Juniper to access your PBX.

Yes, I do that through dns, pointing to the SBCs. In fact, it did appear to be working after all. Some of the remote phones I still have out in the field started registering yesterday so I think the setup is working at least to some extent.

>There should be no need for the PBX to have a default route to the internet at large as
>it should not access that directly. (You only need that for default route for access to
>you internal network if that has multiple IP network segments.

Not the Internet, I was asking about the lan side. You see, someone was telling me that the PBX needs to have the SBC (the centos server we just built) as it's gateway because of the fact that there is also a default gateway. That seems to complicate things a great deal. Plus, since there are multiple pbx, that doesn't work anyhow.

>5060 is only the destination port the source port (from the PBX, SHOULD be different
>otherwise you can only open one communication channel).

Alright, let's see if I am getting this.
Since SIP is the initiator, the remote will always initiate first. From there, once a SIP session is started, the RTP will flow automatically because it is being sent from inside of my network so ports are being opened dynamically.

In the documentation for one of the pbx I use, there is a very specific requirement about using statis ports which I might need in this setup. This pfsense link describes it exactly; http://doc.pfsense.org/index.php/Static_Port

>The spoofing errors are from a multicast protocol known as mDNS (port 5353) ,

It's installed by default in the centos iptables. In fact, are there things in there which are probably not needed or even should not be in there to make things safer?

>iptables -I OUTPUT -o NIC1 -p udp --dport 5353 -j DROP

I have DNS servers on the lan side and for public use so probably don't even need mdns then.

Author

Commented:
You mentioned dropping the mdns but my configuration is a bit different. Here is the entire file as it stands now;

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
-I INPUT -p tcp --dport 22 -s 192.168.0.0/16 -j ACCEPT
-I INPUT -p tcp --dport 9999 -s 192.168.0.0/16 -j ACCEPT
-I INPUT -p tcp --dport 5060 -m state --state NEW -j ACCEPT
-I INPUT -p udp --dport 5060 -m state --state NEW -j ACCEPT
-I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
COMMIT

What ever I don't need in there, could I not just remove it? All I need from public is SIP/RTP, nothing else.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
mDNS queries are done by various tools through libraries... like DNS queries.
You can block them with the rule I mentioned.

the port 631 mentioned in you config are CUPS (printing daemon) you probably can do without.
-p 50 & -p 51 are IPSEC you can probably live without.
All ICMP has to do with network control (i.e. it is needed by IP to say machines are unavailable or not.) so you need it!
The REJECT rule is a friendly blocker as opposed to DROP REJECT mentions failure to connect back to the originating system.
About 5353, the reception is allowed. And modern network more and more are going to rely on mDNS. So you should probably allow it on you LAN.
(Windows really needs it nowadays to find the Domain controllers)

The output rule I mentioned before BLOCKS outgoing mDNS traffic, theone in by default ALLOWS incoming mDNS, so they work quire differently (look for the differences).

Now there are two modes of operation:

Kernel handles SIP:
==> connection tracking can handle RTP forwarding
there is no session management etc. like SBC products do, connection tracking will ensure that RTP follows the SIP /INVITE messages.

SBC handles SIP:
==> you either have to open up on ALL port, and will have trouble when you have more then one PBX access your SBC.
So your SBC application also needs to handle RTP (forward in the right direction, going to the inside).

Author

Commented:
Ok on the above info, thanks very much.

Now there are two modes of operation:

>Kernel handles SIP:

The SBC application handles this.

SBC handles SIP:
>you either have to open up on ALL port, and will have trouble when you have more then
>one PBX access your SBC. So your SBC application also needs to handle RTP
>(forward in the right direction, going to the inside).

Yes, it does this. It is aware via DNS SRV about the PBX on the LAN side.

You feel that this is done, complete, safe, nothing else to add? It is such a small config file, I am somewhat surprised but certainly appreciative that I have something I can test with now.

Is there anything else I should be doing to secure the server other than iptables?
About the only other thing I can think of would be to remove all software/tools which are not required, for example, but anything else?
nociSoftware Engineer
Distinguished Expert 2018

Commented:
DNS SRV is request normally through mDNS....
So you will need the answer to the 5353 request
and you will need to block them outgoing.

Like you said remove all unneeded tools, you might look into enabling SELinux
then you get role based access... But be aware that you need profiles on all applications to prevent disasters from happening.
Your opensbc does need a profile to be setup.

Another thing would be to not allow login to your system by root
(/etc/ssh/sshd_config)

And allow some users (f.e. the ones in the wheel group) to use sudo to elevate their privileges.

Author

Commented:
I wasn't aware that port 5353 was used in dns srv. I have seen mDNS in wireshark but thought it was a bradcast or something.

Once set up, there is really no need for remote access, only from the console.

I have never used SELinux either :).
Does it also use ports or when you say roles, do you mean user roles?
Software Engineer
Distinguished Expert 2018
Commented:
You need to define all aspects of interactions between the program and the OS.
What directories it may access, what files it may open etc. etc. and how it may be done.

Don't experiment with it unless you tried it on a test system. It's too easy to lock yourself out of your own system... ;-) or break perfectly working applications.
But it also will prevent access outside what is explicitly allowed by the description.
(And yes you don;t need root to manage parts of a system).

You can remove ssh access by not allowing port 22, but i advise against blocking it from the inside, it might just save you some walking to the console during all kinds of trouble shooting.
Also keep some tools like tcpdump available for trouble shooting.
(tcpdump is the ascii version of wireshark).

And do make a good backup of your system once it is stable, for obvious reasons.

Author

Commented:
Well, I'm not going to bother you with SELinux, my question was IPTables which you've certainly answered. I'll capture this entire thread, review it and as I begin to use these servers, will expand on what you have shown and taught me.
I thank you very much for your help, you have been nothing but patient and helpful!

Author

Commented:
Incredibly patient and helpful input. I wish all experts were more like this, so many would learn rather than being frustrated with RTFM replies :).

nociSoftware Engineer
Distinguished Expert 2018

Commented:
IMHO, gaining a better understanding helps better in the long run..., too many people are fixed on short term fixes.... ;-), Thanks

Author

Commented:
I agree but one can't take everything on, there's only so much room in the brain and time in the day :).
Sometimes, it's easier to ask someone to help you when it's a quick fix that you won't be messing with all that often than to spend time learning something you'll barely ever use again.

In my case, learning about iptables would make little sense as this is one of the few times I'll want to use it.

BTW, did you get a chance to look at the URL I posted in this thread? I forgot to confirm if this was the case or not with the setup I now have.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
you mean the static port...,
It is about something different. That talks about being able to fingerprint the sources system by trying to follow the behaviour for various systems, even if they are beyond a firewall) w.r.t. source port assignment. and to what extend pfsense can help there for certain protocols.
And no...
SIP & RTP have a relationship. SIP uses a known port to go to an exchange an exchange goes to the other endpoint (if it is subscribed and signals failure otherwise)... and then through the exchange the RTP end to end connection is negotiated.  The RTP channels MAY go through the PBX or it may not (at the discretion of the PBX).
Checkout SIP/INVITE & REINVITE.
This is exactly the type of thing your SBC must do.


w.r.t. Finger printing this tool does a job by just monitoring the TCP session setup....:
http://lcamtuf.coredump.cx/p0f.shtml

Author

Commented:
>Most firewalls randomize ports (rewrite the source port) of outbound traffic. This is problematic for some >protocols (like PPTP, IPSEC and SIP).   sipXbridge needs static port NAT, or symmetric signalling in order
>to work properly. This means when sipXbridge makes an media connection at port 30001, it must be
>sent out on port 30001 (not rewritten by the firewall), and also come back on the same port.

I cannot use ALG firewalls for this particular pbx and need to ensure the above.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
But if you use sipXbridge on this system this is a moot point, as there is no NAT involved.

Linux 2.6 with NAT tries to keep original source ports until there are conflicts. Then source port is changed to allow a connection.
w.r.t. pfsense this is considered a bad thing as it allows finger printing on protected servers.

Author

Commented:
Right, and sipxbridge is not used with sbc's.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial