Hi,

I have installed Elastix server (ISO install) with full yum update

I am no expert, but learning my way thru.

Can someone please share their firewall script ?
It will help me get a head start and then I can modify rules (if needed) for my network.

My Elastix server is on a live IP with 5 extensions from our office (192.168.1.x) and 3 different trunks from different providers. SSh is on non-standard port and FTP port is closed. Postfix relay is blocked (standard install).

Thank you all in advance.

Best regards,
Vai

Firewalling is generally done at the router level, not on the box itself in my experience?

I suggest using IPTABLES. It allows you to stick a public IP directly on the box without needing something to NAT or Xlate for you.. ridding NAT traversal.

My approach is simple... allow traffic originated from the box to the WAN. Deny all inbound connections accept the ones I want. Throw this into a file and sh it, the IPTABLE rules should be saved and load upon reboot of the box:

Eham: May I ask if you find that your posted rule is sufficiently restrictive for you?



/sbin/iptables -A INPUT -s 0.0.0.0 -i eth0 -j ACCEPT



rocky.eld.leidenuniv.nl/joomla/

IMHO would be a good starting point, for a robust iptables script (It's what I use, Thank you Arno)

Dicko, You really don't leave anything unturned

I changed 0.0.0.0 for the purpose of keeping my trusted host ip off of a forum. But yes, anyone wanting to use the above output will need to substitute 0.0.0.0 with a real host IP address. I have several and so far my above IPTABLES example has held up against everything thrown at it. Your mileage may vary, but if you can truly trust the host this will suffice for any VoIP/Web/Hylafax you need to do (at least I've had great success with it).

Your script only denies a few "well known" exploits and (with respect) even if you had a trusted host plugged in, how then would it accept inbound calls from your various VSP's/external extensions?, or even internal calls as you only have eth0 defined and one trusted IP.

It is necessary to shape the allow bit to actually be a firewall that meets a VOIP server's needs, you need to allow SIP/IAX2, http(s), email (in and out) etc. and only these to your trusted hosts. Arno's script actually does that restrictively and is a template for adding SIP etc. by port (not IP) and then by host/network as appropriate, you need your VSP's and external extensions allowed, and any external management allowed by host/network.

This is why there will likely ever be a definitive script for VOIP/Elastix/all the other stuff you added, as each and everyone has a different set of needs.

regards
dicko

Dicko, there certainly isn't an all-in-one solution. My profession over the last few years has been engineering enterprise soft switches- such as Metaswitch and Genband. Anything public-facing preferably use Session Border Controllers to the signaling gateway (Elastix in this case). Good SBCs (such as Acmepacket and Covergence) will control DDOS floods and most other criteria considered malicious. Anything web facing (portals, etc) are typically behind DMZs such as Cisco PIX or ASA (..Sonicwall, Patton, m0n0wall, PfSense etc etc). Enterprise-grade VoIP will literally cost hundreds of thousands of $USD some in the Millions.

I posted a request some time ago about OpenSBC integration, in hopes to cover some of the potential abuse from the public internet. Though my IPTABLES example may not be incredibly flexible it is secure. If you can find a way around mine, I will paypal you $5USD personally

With only one trusted IP allowed through iptables, I still don't understand how people can actually call each other with your script, never mind me making five bucks trying to penetrate an anonymous /32 network that will only accept connections from one other nominated /32 network. Although I must concede that the trusted host can listen to his voicemails to himself and even configure Elastix/FreePBX/Asterisk

I am also a little confused as to why anything "behind DMZs" should be considered particularly secure.

Following is my IPTables script.
Critical inputs welcome!

dicko wrote:
With only one trusted IP allowed through iptables, I still don't understand how people can actually call each other with your script, never mind me making five bucks trying to penetrate an anonymous /32 network that will only accept connections from one other nominated /32 network. Although I must concede that the trusted host can listen to his voicemails to himself and even configure Elastix/FreePBX/Asterisk

I am also a little confused as to why anything "behind DMZs" should be considered particularly secure.

It's all about convention, and my convention deals with trusted endpoints that have static IPs, with multiple trusted endpoints added to the IPTABLES permit (my example has just one but add as many as you need). My deployment consists of the Elastix box with a SIP trunk to the Class5 softswitch trusted IP and a few other endpoints for the IP phones. I don't trunk to other Elastix boxes or have dynamic users.. I let the softswitch take care of those (the company I work for as invested in it, so why not?) This doesn't help roaming users or users that don't have the luxury of a static IP as you well know.

I used to allow 5060 and RTP ports open everywhere until someone got a hold of a x-lite softphone config file and ended up making fraudulent call campaigns via my Elastix box. Now you know why I lock mine down so tightly The Softswitch vendors recommend DMZ at minimal, I personally use XLATE over a pair of High Availability Cisco Pix. If anyone is interested in a simple Pix xlate config I can post it here. Dicko, I would pay you $5usd for being a great patron of the Elastix community, and as you said there's not much chance for penetration on the above said IPTABLES code, which is exactly my goal (and thus your mileage may vary).

I'm glad this security topic has been brought to life, as it is a tremendous liability. I would like to see additional security measures implemented into Elastix (such as removing root login, OpenSBC or a basic firewall GUI) for the sake of simplicity and wider use.