This CentOS wiki may help:

http://wiki.centos.org/HowTos/Network/IPTables

Akemi

Akemi, That was helpful (I should have checked the wiki:>).

After reading that and the RH related links, I think I have what I need but I am unclear about one aspect. What is the correlation between filtering LAN based connections destined to be masqueraded out and what can even get to the internal NIC? I see the chains are obviously distinct from each other, and I assume the tables are as well. So to control what may ingress an interface destined for the server itself, you write a rule for the default table's INPUT chain, to control what may be masqueraded/DNAT'ed, you write a rule for the either the NAT tables PREROUTING chain or the default table's FORWARD chain, or both?

In looking at examples for setting up NAT, I don't see people typically lockdown what may masqueraded, so I am not seeing how to do this. Buy my inclusion of at least one rule, am I properly prohibiting anything else? Is there any significance to the order in which I setup masquerading and then lockdown what hits the FORWARD chain?

Do you not need to setup default policies for the chains on the nat table?

Thanks! jlc

****************************************** #!/bin/bash

WAN="eth0" LAN="eth1"

# Flush all current rules from iptables iptables -F

# Set default policies for INPUT, FORWARD and OUTPUT chains iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT

# Set access for localhost iptables -A INPUT -i lo -j ACCEPT

# Accept packets belonging to established and related connections iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Setup masquerading on WAN interface iptables -A FORWARD -i $WAN -o $LAN -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i $LAN -o $WAN -j ACCEPT iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE

# Allow incoming DNS/DHCP/HTTP/SIP connections from internal clients on LAN iptables -A FORWARD -i $LAN -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT iptables -A FORWARD -i $LAN -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT iptables -A INPUT -i $LAN -m state --state NEW -m udp -p udp --dport 67 -j ACCEPT iptables -A INPUT -i $LAN -m state --state NEW -m udp -p udp --dport 68 -j ACCEPT iptables -A INPUT -i $LAN -m state --state NEW -m udp -p udp --dport 5060 -j ACCEPT iptables -A INPUT -i $LAN -m state --state NEW -m udp -p udp --dport 10000:60000 -j ACCEPT

# Allow incoming SIP connections from both of the provider's RTP Servers on WAN iptables -A INPUT -s xx.xx.xxx.162/32 -i $WAN -m state --state NEW -m udp -p udp --dport 5060 -j ACCEPT iptables -A INPUT -s xx.xx.xxx.163/32 -i $WAN -m state --state NEW -m udp -p udp --dport 10000:60000 -j ACCEPT iptables -A INPUT -s xx.xx.xxx.162/32 -i $WAN -m state --state NEW -m udp -p udp --dport 5060 -j ACCEPT iptables -A INPUT -s xx.xx.xxx.163/32 -i $WAN -m state --state NEW -m udp -p udp --dport 10000:60000 -j ACCEPT

# Forward smtp connections to mail server from WAN iptables -A FORWARD -i $WAN -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT iptables -t nat -A PREROUTING -i $WAN -p tcp --dport 25 -j DNAT --to 192.168.0.3:25

# Save settings service iptables save ******************************************

On Fri, May 23, 2008 at 12:25 PM, Joseph L. Casale JCasale@activenetwerx.com wrote:

In terms of Cisco ACL's, how does iptables work, does it simply continue processing until it sees something explicitly denying if the default policy is ACCEPT, versus DROP, will it continue processing until it sees something explicitly allowing?

iptables will process rules until a match. If the match is -j ACCEPT/REJECT/DROP, it will end processing there. If it's -j another_chain, it will jump to the other chain. If it matches a rule in the other chain with -j ACCEPT/REJECT/DROP, it will stop processing there. Otherwise, if no rules in this inner chain matches, it will resume processing in the outer chain just after the rule which jumped to the inner chain.

...

#Finally dropping all other traffic (positive list firewall): iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP

So here you know restate the default policy? I thought you could only define this once?

You define the default policy for every built-in chain: INPUT, OUTPUT and FORWARD.

Does this -F not reset the above stated policy?

No, it doesn't.

HTH, Filipe

On Sat, May 24, 2008 at 2:49 AM, Joseph L. Casale JCasale@activenetwerx.com wrote:

Appreciate the help, but I think I am still unsure of that last point. If the default policy for INPUT is DROP, and a rule "allowing" traffic is not matched, once it gets to the end it performs the default policy action from what I have gathered now.

What I meant was, if you create an user defined chain, when you get to the end of the chain without matching anything, you will get back to the original chain and resume processing there. If you get to the end of an internal chain (which are INPUT, OUTPUT and FORWARD), then the default policy will apply.

Consider this example (just for illustrating the issue)

# iptables -N testing # iptables -A FORWARD -d 192.168.5.88 -p tcp --dport 80 -j ACCEPT # iptables -A FORWARD -i eth0 -j testing # iptables -A testing -d 192.168.5.99 -p tcp --dport 22 -j ACCEPT # iptables -A FORWARD -d 192.168.5.77 -p tcp --dport 443 -j ACCEPT # iptables -P FORWARD DROP

# iptables -nvL ... Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.5.88 tcp dpt:80 0 0 testing all -- eth0 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.5.77 tcp dpt:443 ... Chain testing (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.5.99 tcp dpt:22

If the packet is to HTTP in host 192.168.5.88, it will match the first rule of FORWARD and will end processing there. Otherwise, but if the packet is from eth0, it will enter the "testing" chain. If it is SSH to 192.168.5.99, then it will match the (only) rule in "testing" and will end processing there. Otherwise, it will resume processing on the third rule of FORWARD. If the packet is HTTPS to 192.168.5.77, it will match that rule, accept the packet, and end processing there. Otherwise, as it's the end of the FORWARD chain, it will use the default policy, which in this case was set to DROP (the default is ACCEPT).

Is it clear now?

HTH, Filipe

On Friday 23 May 2008 21:31, Fajar Priyanto wrote:

Actually I have written a small tutorial on iptables, but I haven't translated it into english. I'll let you know when it's done. Hopefully it will be useful for others.

Please have someone, or for that matter a few people, who have a good understanding of firewalls look over your tutorial before it is published. While you show a basic understanding of how firewalls work you lack the knowledge of true security. Just my observation.

Fajar Priyanto wrote:

On Saturday 24 May 2008 10:25:41 Robert Spangler wrote:

...

On Friday 23 May 2008 21:31, Fajar Priyanto wrote:

...

Actually I have written a small tutorial on iptables, but I haven't translated it into english. I'll let you know when it's done. Hopefully it will be useful for others.

Please have someone, or for that matter a few people, who have a good understanding of firewalls look over your tutorial before it is published. While you show a basic understanding of how firewalls work you lack the knowledge of true security. Just my observation.

You observation is most welcome, Robert. By all mean, I'm surely not an expert. Just someone who wants to help other by guiding a little 1 or 2 tiny steps along the great jungle of Linux knowledge. Everyday is a lesson for me. So, if you please, I really want to know what true security is. Thank you.

Fajar,

There is already an iptables tutorial on the Wiki:

http://wiki.centos.org/HowTos/Network/IPTables

Rather than reinventing the wheel, perhaps you would like to take a look at that and consider contributing and/or helping to improve it if you see areas that you consider are weak.

Regards,

Ned

On Friday 23 May 2008 11:03, Fajar Priyanto wrote:

On Thursday 22 May 2008 22:30:29 Joseph L. Casale wrote:  > I have a dual homed server in an install for someone who is very cost  > sensitive. This server originally is being setup as an Asterisk server,  > but now the simplest thing for me to do is also set it up to provide  > internet access for the small shop as well.  >  > So it will have one external, WAN  facing nic that needs all incoming  > ports except UDP 5060 and 10000 -> 60000 blocked for all but two ips.  >  > The internal, LAN facing  NIC will need all ports except voip/dns/http  > blocked to it, and need to provide masquerading.  >  > I have limited experience with iptables and would love some guidelines.  > Any pointers would be greatly appreciated!

Hi JLC,  There are 2 ways to implement firewall: negative list and positive list. Looks like you want a very strict one that is positive list.

Assuming eth0 is WAN, and eth1 is LAN (assuming 192.168.0.0/24)(please mind the word wrap):  #Clear all rules and policies first:  iptables -P INPUT ACCEPT  iptables -P OUTPUT ACCEPT  iptables -P FORWARD ACCEPT  iptables -F  iptables -t nat -F

Since you believe that he wants a very strict firewall why are you setting the default policy's to ACCEPT?  Security 101, strict firewall drops everything from the start.  Then you open the access you require, not the other way around.

#Give access for localhost:  iptables -I INPUT -i lo -j ACCEPT  iptables -I OUTPUT -o lo -j ACCEPT

#To make life easier:  iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT  iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

#Allowing needed ports:  iptables -A INPUT -i eth0 -m multiport -p udp --dport 5060,10000:60000 -s  ipthatyouwantallow -j ACCEPT  iptables -A INPUT -i eth1 -m multiport -p udp --dport  53,80,5060,10000:60000 -j ACCEPT  iptables -A OUTPUT -m multiport -p udp --dport 53 -j ACCEPT  iptables -A FORWARD -m multiport -p udp --dport 53,5060,10000:60000 -s  ipthatyouallow -j ACCEPT  iptables -A FORWARD -m multiport -p tcp --dport 80 -j ACCEPT

First question you need to ask yourself is there any hosting services on this box that will require a connection form the WAN side.  If not then you should change your input statements to allow only the LAN.  You do not require the INPUT statements for packets that pass through the box as the FORWARD will handle all traffic passing through.

Second question is if you are using ESTABLISHED,RELATED why are you not using NEW in the above rules?

Third question is have you enables connection tracking?  If you are using ESTABLISHED,RELATED then the system needs a way to keep track of the connection.

If you want a 100% secure firewall then you will not allow any INPUT.  All modification would have to be done from the box using a keyboard.  If this is not an option then you can allow access from a trusted IP only and setup other security options.

#For masquerading:  iptables -t nat -A POSTROUTING -o eth0 -d ! 192.168.0.0/24 -j MASQUERADE

If the WAN port is connected directly to the Internet then you should MASQ all out going traffic and anything that is heading to 192.168.0.0/24 should be dropped.

#For logging (troubleshooting):  iptables -A INPUT -m limit --limit 2/m --limit-burst 2 -j LOG --log-prefix '** INPUT DROP ** '  iptables -A FORWARD -m limit --limit 2/m --limit-burst 2 -j  LOG --log-prefix '** FORWARD DROP ** '  iptables -A OUTPUT -m limit --limit 2/m --limit-burst 2 -j  LOG --log-prefix '** OUTPUT DROP ** '

Logging any packets that make it this far is a good idea.

#Finally dropping all other traffic (positive list firewall):  iptables -P INPUT DROP  iptables -P OUTPUT DROP  iptables -P FORWARD DROP

This should be at the top for the firewall not the ACCEPT you have there now.

#Don't forget to save it:  service iptables save

I might make some mistakes up there, so the logging is very important. You

Just a few.  :)

For your reading enjoyment.

http://iptables.rlworkman.net/chunkyhtml/index.html

On Sunday 25 May 2008 20:50, Fajar Priyanto wrote:

On Saturday 24 May 2008 21:55:57 Robert Spangler wrote: First of all, thank you Robert for pointing some points. For the sake of discussion, may I say something too?

Certainly.

...

Since you believe that he wants a very strict firewall why are you setting the default policy's to ACCEPT?  Security 101, strict firewall drops everything from the start.  Then you open the access you require, not the other way around.

This is my mistake I think. It's because I was assuming the setting of the firewall is done from another machine (ssh). Those rules are to prevent unaware lockout.

It doesn't matter if you are trying to prevent unwanted lockout or not. Once the rules are loaded they are set. If they are set so that another machine (ssh) is not to have access then it will not have access.

...

...

#Allowing needed ports:  iptables -A INPUT -i eth0 -m multiport -p udp --dport 5060,10000:60000 -s ipthatyouwantallow -j ACCEPT  iptables -A INPUT -i eth1 -m multiport -p udp --dport  53,80,5060,10000:60000 -j ACCEPT  iptables -A OUTPUT -m multiport -p udp --dport 53 -j ACCEPT  iptables -A FORWARD -m multiport -p udp --dport 53,5060,10000:60000 -s ipthatyouallow -j ACCEPT  iptables -A FORWARD -m multiport -p tcp --dport 80 -j ACCEPT

First question you need to ask yourself is there any hosting services on this box that will require a connection form the WAN side.  If not then you should change your input statements to allow only the LAN.  You do not require the INPUT statements for packets that pass through the box as the FORWARD will handle all traffic passing through.

The OP said that it's an Asterisk box. So it surely needs some open ports, doesn't it?

I really don't know. I do not know this setup. If it does then I would look into using an old 486 or Pentium for a firewall and setting this box up to be in a DMZ.

...

Second question is if you are using ESTABLISHED,RELATED why are you not using NEW in the above rules?

It depends on the context and level of details needed. Pls CMIIW, if we allow NEW in the above rules, then ALL traffic will be matched, and thus rendering all subsequent rules useless. Again pls CMIIW :)

With IPTABLES once a rule matches and is accepted it stops processing the packet and sends it on it's way. NEW does not stop IPTABLES from processing the packet as it is supposed to, it just applies the rule if the packet is new. This is why you place ESTABLISHED,RELATED at the top of your rule sets and use the NEW statement in your rules.

Let us take a look at the following rules set for an example. This could be applied to a web server in a DMZ.

iptables INPUT -p DROP iptables OUTPUT -p DROP iptables FORWARD -p DROP iptables INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables INPUT -i eth0 -p tcp --dport 80 -m state --state NEW -j ACCEPT iptables INPUT -i eth0 -j DROP **(I always place this statement)** iptables OUTPUT -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables OUTPUT -o eth1 -j DROP **(I always place this statement) **

First an explanation. This rules set allows connections to a web server but does not allow the web server to start it's own connections. It is used to block an affected web server from infecting other systems. On the OUTPUT rule set if you place a LOGing rule you would then see when the server was affected and just how much traffic it tries to push.

As a packet enters the firewall for port 80 and checks it against it's rule set.

The first rule it comes to is ESTABLISHED,RELATED. Since there is nothing in the conntrack table for an entry. Since none are there it sends the packet on it's way.

The next rule is for port 80. The packet is compared to this rule to see if it matches. It also checks the conntrack table to see if it is there. since it is not it is considered a NEW connection so the rule say it is a match. It adds the information needed to the conntrack table and ACCPEPTs the packet. Processing finished.

Now the next packet enters the firewall and it is first checked by the ESTABLISHED,RELATED rule. Since this packet comes from the same source and there is an entry in the conntrack table for this source the rule matches and the packet is allowed to pass. Processing is finished.

This continues all the time. Every packet is checked against the ESTABLISHED,RELATED rule and if the source is listed for that port then the firewall allows it through without further processing. This is done to speed up the firewall. Every rule has to be processed until one is matched as ACCEPT. This requires processing power. The less the system has to process a packet the faster it becomes.

Now lets say you don't use the NEW as in your rules set. Now every packet has to traverse the rule set each time because there is no NEW rule to add it to the conntracking table. Now lets say that you have a couple hundred rules in your firewall. Now the packet has to traverse the entire rule set everything it comes in. This will slow down your firewall. This type of firewall is known as CONNECTIONLESS. meaning it doesn't care if the packet was seen before or not, it must traverse the chain.

I hope this has given you a better understanding of how IPTABLES works.

...

Third question is have you enables connection tracking?  If you are using ESTABLISHED,RELATED then the system needs a way to keep track of the connection.

I believe Centos has them enabled and it will automatically loaded when the rules are fired up. Pls CMIIW.

It load the conntracking table but there are more. This was just to get you thinking.

...

If you want a 100% secure firewall then you will not allow any INPUT.  All modification would have to be done from the box using a keyboard.  If this is not an option then you can allow access from a trusted IP only and setup other security options.

Yes, this is my mistake assuming wrongly. Worth noted for the OP and everyone.

...

...

#For masquerading:  iptables -t nat -A POSTROUTING -o eth0 -d ! 192.168.0.0/24 -j MASQUERADE

If the WAN port is connected directly to the Internet then you should MASQ all out going traffic and anything that is heading to 192.168.0.0/24 should be dropped.

You mean it should be: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ?

Correct. If you are not MASQ all traffic that leave this interface and it leave with 192.168.0.0/24 then the machine on the Internet will not know how to get back to your network. 192.168.0.0/24 is not routed on the Internet.

...

...

#Finally dropping all other traffic (positive list firewall):  iptables -P INPUT DROP  iptables -P OUTPUT DROP  iptables -P FORWARD DROP

This should be at the top for the firewall not the ACCEPT you have there now.

For your reading enjoyment. http://iptables.rlworkman.net/chunkyhtml/index.html

Yes, the Oscar's tutorial seems to be the most popular one.

Yes there is a lot of good information in there.

I hope I was able to help you with your quest.