Security Considerations

you have a file called

/etc/sysconfig/iptables

expanding on this file will be more than sufficient to protect your access.

you do not need to change SSH ports, but instead alter the port22 access to only allow from specific subnets. Example:

lets say you only wanted to have access from a block of IP's you own..

-s 69.64.0.0/20

-s means source address

your biggest security risk is who you allow access to your AMI (tcp 5038) port.

so make a firewall using Ip tables will be fine?
what about changing port 80 (http) to a different one? it will be a good idea?
What ports do you recommend to stay open?
Please advice.
Thank you.

i dont run webmin on port 80, thats a collosal mistake. Change webmin back to port 10000 but also set up 443

then install (if it isnt already) the CPAN module Net::SSLEay and turn on SSL for your wemin. This will turn your portal into an HTTPS access so that uesrs arent transmitting their passwords in plain text.

This will also free up your port 80 to use for Apache to do other things such as running HTTP, FTP, TFTP provisioning all from the same directory.

I changed webmin port and enabled ssl as you recommended, noy y have to put in the URL the following: https://ip.address.com:10000 to get in.

Is it necesary anyway to block ports with ip tables after the changes I did on webmin?
Thanks for you help.
Roque.

does anyone know how to install a certificate or where could i find some how to's for Net::SSLEay I installed a new certificate, sadly i revoked the old one before making sure the new one works and now my customer have no access to the server

thanks

hare is how i did it

To request a certificate, follow these steps :

• Run the command openssl genrsa -out key.pem 2048 . This will create the file key.pem which is your private key.
• Run the command openssl req -new -key key.pem -out req.pem When it asks for the common name, be sure to enter the full hostname of your server as used in the URL, like www.yourserver.com. This will create the file req.pem, which is the certificate signing request (CSR)
• Send the CSR to your certificate authority by whatever method they use. They should send you back a file that starts with -----BEGIN CERTIFICATE----- which can be put in the file cert.pem.
  Combine the private key and certificate with the command cat key.pem cert.pem >/etc/webmin/miniserv.pem
• Re-start webmin with the command /etc/webmin/stop and /etc/webmin/start (making sure it is in SSL mode) to use the new key .

I am looking for a firewall to put between multi-tenant thirdlane and the public internet.

Customers will be connecting to thirdlane both from a private intranet and through the public internet. I do not want a DOS attack on the public interface to affect service on the private intranet. If i run iptables on thirdlane a DOS attack could potentially hose the whole box. If instead I have a separate firewall protecting the public interface a DOS attack should only potentially hose that firewall and thus only affect calls coming in over the public internet, which in my case is the minority (<1%).

The firewalls I am currently evaluating are the Sonic Wall NSA 2400 and the Juniper SSG5.

Up until now I haven't opened up any asterisk server to the public internet. Any firewall suggestions would be appreciated.

Thanks.

public IP on the actual asterisk box and the firewall routes between two public networks?

Hopefully this clears up my application:

I have dedicated connections (T1s) to my customer's place of business. All of the calls they place come over their T1 into my data center and do not go through the public internet. At the moment there is no access to the TL server from the public internet. Now my clients want to take their phones home occasionally, and to allow that I would have to allow access to the TL server from the public internet. For this application I want to get a hardware firewall and route all the traffic originating on the public internet through this firewall to the TL server.

The Juniper SSG5 is spec'd for 96 concurrent calls and has DOS and DDOS protection built in, dynamic rtp port allocation, etc... so that is what I am leaning towards at the moment.

I will only say this once.. so listen carefully.

you are a fool if you try and run asterisk on RFC1918 addresses so that NAT occurs. I asked this question already and you sidestepped my question. Any attempt to run on RFC1918 addresses with NAT work-arounds are just that... work-arounds. They are no substitute for properly routed IP addresses. You need real IP addresses on both sides of your firewall. SIP is not designed to deal with nat, workarounds do not resolve the fact that the payload itself has URL's built in referencing networks that differ from the IP packet headers.

Sorry for my mis-use of the words public and private. I am *not* using RFC 1918 addresses on my server. We are an ISP and I am drawing a distinction between voip traffic that originates and terminates on my network (ie: originates at customer premises that are connected to my network with dedicated connections) versus voip traffic that originates with some other ISP (ie: my customer's home office where he has verizon fios) and terminates on my network. I want all traffic that originates from other ISP's to go through this new firewall as I am concerned about DOS attacks originating from other ISPs.

yea, if your running routable ip's everywhere you shouldnt have a problem. Stay away from sonicwall.. I've got evidence that they strip QoS headers off the ip packets which will prevent your customers from doing something with your traffic once it does reach their network.

So do we have a consensus that using iptables as your sole firewall leaves a gaping vulnerability to DOS attacks?

no I don't think that a generic assumption like that is fair at all. I have found plenty of firewalls with inadequate network interface hardware which doesn't reveal itself until you start really pushing the packets per second. if the dos attack is sufficient enough to kill a box, killing the firewall in front of it will still result in denying service because you'll have a loss of route. 92 concurrent calls isnt a whole lot especially if the PBX has sip trunks to an external carrier, every call would count as 2 lowering it to 46 concurrent calls.

Erik, your comment “Stay away from sonicwall.. I've got evidence that they strip QoS headers off the ip packets” again contradicts everything I have seen in production for 2 years. (I have commented before regarding you stating this). We have over 60 of these units under our management and all are passing DSCP values just fine. Is your evidence current? On a current generation box? With Enhanced OS? I have boxes that are a couple generations behind that are passing DSCP values just fine.

We have had the same problems as Erik, sonic walls have problems with SIP, we have not been able to get bran new or older models working. One of our IT people spent over 10 hours on the phone with sonic support on a brandnew unit and were unable to get it to to work 100%. There are to many other good units out there its not worth the trouble.

As of then if you want to use a sonic wall take your business else were we are not interested..

George