Iptables and Freepbx distro?

Hello,

Just wondering if there are any extra steps needed after installing the freepbx distro with iptables? Do we need to run this

iptables -A INPUT -p udp -m udp --dport 5060 -j ACCEPT ?

If we are behind a router can we simply disable iptables? To risky?

We dont run any iptable rules by default and if you are behind a firewall their is no need unless you want a secondary firewall.

you will find life much easier if you don’t touch iptables and simply use an external firewall

Tony,

For someone who who does want to do this, I’d recommend the following. Presumably, when the FreePBX distro restarts fail2ban from the “Intrusion Detection” settings, it first restarts iptables. That means that changes made in any script called from rc.local (for instance) will get erased.

My two cents, if you either don’t have the ability to do a firewall (for whatever reason) or you do want additional control over your network, is this:

Do what you want to do by learning how to use /etc/sysconfig/iptables

Anything you put in here will be reloaded whenever iptables is restarted, and is therefore in place before fail2ban does its thing.

Like, say you want to protect your iSymphony ports (50000-50003) so that only 74.201.81.0/255.255.255.0 can access it (pretend that’s your public IP space). You can put:

iptables -I INPUT -p tcp -m multiport --dports 50000,50001,50002,50003 -s 74.201.81.0/255.255.255.0 -j ACCEPT
iptables -I INPUT -p tcp -m multiport --dports 50000,50001,50002,50003 -j DROP

That will block anyone who doesn’t come from an IP address in the range 74.201.81.0 through 74.201.81.255 from accessing your iSymphony.

This thread has bee usefull for setting up additional rules for IPTABLES,

The below worked for me,
The additional rules gets loaded up in addition to the fail2ban stuff. Usefull for banning explicitly rather than depending on fail2ban.

----------/etc/sysconfig/iptables--------------
*filter
#The Below is suppose to Run after fail2ban stuff
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
########SIP/RTP###############
#SIP provider
-A INPUT -p udp -m udp -s XX.XX.XX.XX --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp -s XX.XX.XX.XX --dport 10000:20000 -j ACCEPT

PUT ALL other Allow rules here, SSH etc…

##########DROP with Logging
-N LOGGING
-A INPUT -j LOGGING
-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
-A LOGGING -j DROP
COMMIT

Not to nit-pick but I would suggest that one should conversely consider the fail2ban chains as “additional” to iptables (because they are), solid iptable based firewalls should always precurse fail2ban, if you use a “potted” firewall perhaps like csf or apf , ensure that fail2ban is specifically called AFTER setting those rules, don’t rely on the fail2ban chains to be still there if you start them with an init script. . . .

As I said, anything you put in /etc/sysconfig/iptables will be loaded before fail2ban is loaded. So you can block or allow as you see fit.

We run our systems with some major additional firewall rules, once of which is to TARPIT anyone connecting from GeoIP locations that don’t have our customers in them. Since most attacks come from Asia and Eastern Europe, this blocks most of the junk that might otherwise make it through hardware firewalls.

Ahhhhh…the blissful silence of never seeing “unknown peers” in my our log files again! :slight_smile:

dicko,

My point exactly. The whole “FreePBX is secure because we expect you to be behind a firewall” is like saying “we expect your house to be secure because it’s behind a gate.”

Leave the gate open accidentally, and the house is no longer secure.

Always have locks on your doors, in case the door in front of you is accidentally left open.

Oh how agree, and check those locks every week, those guys are NOT stupid, complacency and ignorance defines the stupid ones.