Linux Iptables firewall

I'm not a newbie to firewalls or networking, but I don't have a degree in them either. I noticed something interesting just now, and I hoped someone could explain this.

I was configuring a fairly simple firewall for my home server, which is behind a NAT router. Since it is a mail server, I needed to open port 25, as well as local ports. Take a look:

(This is a rule on the input table on Iptables, and in plain english):

If protocol is TCP and destination is 192.168.2.196 and input interface is eth0 and destination port is 1024:65535 and source port is 25, Accept.

I was thinking about this, and this basically means as long as the person making the request forges it so that their request comes from port 25, they can basically access any non-service port on my server, right?

Is that possible?

Thanks

Hey im not good at this either but i'll give it a try....

Quote:

---

destination port is 1024:65535 and source port is 25, Accept.

---

Doesn't that mean that they can access through any port between 1024 and 65535 as long as the request come from port 25 ... doesnt that still expose yo to risk, since they can exploit port 25 and you give them access to every port 1024:65535...?

If someone can explain this better, im curious to ! Shouldnt you just allow port 25 to make connections if it is a mail server ?

Thanks for your reply, DreamDown. Its required that I open the local ports, since it talks to other mail servers and the way tcp works, its needed to do that (unless there's a more secure way to write that rule, anyone?)

I thought Hping did something like that, could be wrong though, trying to remember from a similair post. Anyway, it would be possible for someone to tunnel a connection to a different port over 25 and then exploit another service.

im supposing that 192.168.2.196 is your mail server (with Netfilter on) ip address.

# So to allow external guys connect to it:

iptables -A INPUT -p tcp -dport 25 -m state --state NEW -j ACCEPT

# to allow you to access external e-mail servers

iptables -A OUTPUT -p tcp -sport 25 -m state --state NEW -j ACCEPT

# allow only related and established sessions on both ways

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

so you dont need to open user ports. why you should?

Thanks for your replies. Cacosapo, those two rules at the end of your post would work for all services then? So for example, if I also wanted to put a webserver online, I would open port 80 incoming and outgoing (like the two first rules in your post), and the other already existing rules would take care of the local ports? Please correct me if I misunderstood.

kr5kernel, how can you tunnel a connection through port 25 to a different service? I didn't know that was possible..

As cacosapo posted, you really only need to give people access to TCP/25 (SMTP). If you want to have some fun once you are comfortable, look into playing with the owner module for netfilter.

WoW ..a lot going on here!!

I’m drunk now, so bare with me ..

Quote:

---

If protocol is TCP and destination is 192.168.2.196 and input interface is eth0 and destination port is 1024:65535 and source port is 25, Accept.

---

as DreamDown said, you want everyone to connect to any port between 1024 and 65535 if their source port is 25 ?? Or do you want them to connect to port 25, the port the smtp will listen to?

Back to basics. You said it is behind a NAT router. How is this configured? You should be NATing port 25 to the mail server ( port 25 ) already, not allowing any other port requests from outside to be going to it? What interface is connected to the router? ( I suppose eth0 is connected to the LAN you want to access the mail server: ie. eth0 is facing the LAN? )


Ok, now back to the firewall.
First I must say here Logging everything will help you both identify problems with the firewall when you set it up and also keep track of who and what is connecting.

What cacosapo said about the INPUT should work, but I would not be using the stateful part of Netfilter quite yet.
To allow connections to port 25 on eth0
iptables -A INPUT -p tcp -i eth0 --dport 25 -j LOG --log-level info --log-prefix "smtp in eth0: "
iptables -A INPUT -p tcp -i eth0 --dport 25 -j ACCEPT

Quote:

---

how can you tunnel a connection through port 25 to a different service? I didn't know that was possible..

---

Of course it is, if they find another exploit! That port should be bound to the smtp engine.

If eth1 is facing the NAT router, to connect to other outside mail servers
iptables -A OUTPUT -p tcp -i eth1 --dport 25 -j LOG --log-level info --log-prefix "smtp out to net: "
iptables -A OUTPUT -p tcp -i eth1 --dport 25 -j ACCEPT

Here, correct me if I am wrong, your mail server should be using a different port ( between 1024 and 65535 ) to send its information to other servers listening to port 25.

So you have your LAN connecting to the smtp box via eth0, your box connecting to outside smtp servers via eth1 ... but what about the other way around? What about outside servers trying to relay incoming mail to your server?

iptables -A INPUT -p tcp -i eth1 --dport 25 -j LOG --log-level info --log-prefix "smtp in from net: "
iptables -A INPUT -p tcp -i eth1 --dport 25 -j ACCEPT

The requests from the LAN, both sending and receiving should still originate from the LAN and go to port 25, thus using the above rule.

THEN, to maintain the connections, both inside and outside the LAN you would use the “stateful” properties of Netfilter:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Quote:

---

those two rules at the end of your post would work for all services then?

---

Yes! Just remember, Netfilter ( and IPTables ) works in a top-down method. Those rules would be AFTER the rules which allowed the original connections.

Also note you should include such things as

At the begining to clear all rules and make the default policy to drop everything you don’t explicitly allow:

iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
# ------Set default policies for packets going through this firewall box-------- #
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

at the end of your firewall rules:

# ---log all packets that hit the default policy ---- #
iptables -A INPUT -j LOG --log-level info --log-prefix "input_default_drop: "
iptables -A OUTPUT -j LOG --log-level info --log-prefix "output_default_drop: "
iptables -A FORWARD -j LOG --log-level info --log-prefix "forward_default_drop: "


Hope this helps ..... and I didn’t screw it up while drunk!

Quote:

---

Originally posted here by IKnowNot
Yes! Just remember, Netfilter ( and IPTables ) works in a top-down method.

---

This is incorrect. The number and location of rules in your file is unrelated to their situation in the actual rule chain. It works by following every rule on the chain until it hits an exit target (ACCEPT, DROP, DNAT, etc). Note LOG is not an exit target.

Thanks everyone for your help, I fixed everything now. The nat router only lets port 25 in, and the rules that cacosapo mentioned worked perfectly.

1st, ,I'm glad to see yanksfan got it working.

Quote:

---

This is incorrect. The number and location of rules in your file is unrelated to their situation in the actual rule chain.

---

ruleset:
iptables -A INPUT -p tcp -i eth1 -j DROP
iptables -A OUTPUT -p tcp -i eth1 --dport 25 -j ACCEPT
iptables -A INPUT -p tcp -i eth1 --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp -i eth1 -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

What would happen to ANY packet coming in on eth1 ?
Would any packet be ESTABLISHED ?


I probably should not have made such a general statement and thus prompt such a response. ( usually only have to watch myself when that closely when talking to lawyers. ) But it was not incorrect. I assumed the original poster had at least some knowledge of Netfilter.
And the location IS important, but important per chain.

My thoughts here were that NO ruleset would contain just what was listed. Before the stateful rules mentioned above, or the other rules, it is a VERY good idea to drop malformed packets, packets leaving to the net side with private IP addresses, packets coming in from the net side with private IP addresses, packets coming from the LAN outside the LAN IP range, etc.
And yes, I do yield, you could put the port ACCEPT rule after the stateful ESTABLISHED rule as they would be working on different packets and the ESTABLISHED packets would only be ESTABLISHED after the connection was established after the original packet was accepted by the port rule. ( ??? )
But why? Why confuse the issue? It is best to keep the rulsets as straight forward and logical as possible, isn't it?

Quote:

---

Originally posted here by IKnowNot
[...]I probably should not have made such a general statement and thus prompt such a response. ( usually only have to watch myself when that closely when talking to lawyers. ) But it was not incorrect.

---

Yes, actually it is incorrect.
ruleset:
iptables -A INPUT -j DROP # Drop all incoming.
iptables -I INPUT 1 -p TCP --dport 80 -j ACCEPT # Accept TCP/80 (HTTP)
According to you, file order matters, however here hits will still come in to port 80. Using append-only may make sense to some people, however in medium- and semi-large- rulesets it can be more efficient to use non-linear (in a file sense) rulesets. Usually insert is best used when using custom chains, or when using specific-use NF modules, but I've used it quite often in scripts to perform drop-all at the beginning and then adding whatever needs to be accepted -- in fact, the ruleset on the box I'm on is done in such a manner.

I guess none of you use webmin (www.webmin.com), but that's what I used to configure iptables. A big security downside of webmin is that the entire program is run by root, but since I only allow my computer from the LAN to access it (and only I use it), I think that its pretty safe. Let me know what you think about webmin.

No, I’ve never used webmin, so I can’t comment on it. I’m just overly paranoid and don’t like any service I don’t need running. And sorry to have hijacked this thread, was not my intent.

Quote:

---

And the location IS important, but important per chain..

---

Yes, you can insert, but you are then inserting into the chain at a specific location.
The chain is then modified, and STILL goes top-down, from one rule to another.

As far as the file goes, if I’m building a table for a workstation I can just take the rulesets and list them, print them, then the computer does the work listing them in the top-down order for me, the way the rulsets will be followed; I can be sloppy. But if I’m building or diagnosing a stand-alone firewall or a firewall for a server I may not have print services running. No GUI, limited shells, etc. Now with large rulesets trying to track down a problem or open a new have-to-have service for some meathead can very quickly become a nightmare trying to follow all those inserts and deletes. Again, why? Why not take a little more time to do it in a logical step-down order the way the kernel will read them?

If you are trying to diagnose a running ruleset the insert and delete make perfect sense. Or you if are scrambling to shut something down during an attack. Yes, I use append mostly and use insert and delete very sparingly on a final version.

Where I may use it in a final ruleset is at the end of my rules, something like
# -----now that tables are finished remove absolute stops and pray ------ #
iptables -D INPUT -i ! lo -j DROP
iptables -D OUTPUT -o ! lo -j DROP
iptables -D FORWARD -i ! lo -j DROP

and I want these at the very end, not somewhere in the middle which would defeat the purpose.
Just because you can do something does not mean you should.

Quote:

---

Originally posted here by IKnowNot
Just because you can do something does not mean you should.

---

It also doesn't mean you shouldn't. There are very valid reasons for logically separating things in a file and using very many inserts that can make loads of sense. For a workstation this may not be the case, however don't dismiss it as being an invalid approach because you have never encountered a situation where it is the most logical method of designing rulesets. My point was your statement that:

Quote:

---

Yes! Just remember, Netfilter ( and IPTables ) works in a top-down method. Those rules would be AFTER the rules which allowed the original connections.

---

In the context of file layout isn't actually correct. It is important to not give a newbie unclear information, and I merely posted to clarify something.

Yes, I do understand and agree. But I enjoyed the exchange. It gave me a necessary break and maybe someone else could get something out of it.

Some people call me Anal Retentive but red wine and oatmeal are helping clear that up!