smtp and iptables

Tatome · *nix forums beginner Joined: 14 Feb 2005 Posts: 3

Hi, everyone,
I'm trying to get my debian box to send out messages via exim.
Unfortunately this desire seems to collide with my wish to make my
server as secure as possible. I set up a few firewall rules that seem
to effectively make smtp connections impossible although I don't know
how.
iptables -nL INPUT reads as follows:

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp
dpt:113
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT all -- [my.name.server] 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0

As you can see the smtp port as well as the ident port are wide open.
Still exim says "Connection timed out" in the mainlog as long as the
chain policy is "DROP".
One thing I can think of is that there might be some other protocol
required for sending e-mails. I don't know which one though and I
don't find anything on the net.
Any help is greatly appreciated.
Johannes

PS: I'm fairly new to iptables and I guess these aren't the smartest
ever firewall rules. Feel free to tell me if I'm missing something
important.

Jim Ficarra · *nix forums beginner Joined: 22 Feb 2005 Posts: 6

Tatome,

The INPUT chain defines rules coming IN to the box, not out. You had
indicated you want your exim server to send outgoing e-mail. To do this,
you want to add a rule to allow outgoing TCP connections on Port 25 on the
OUTPUT chain.

Source: Your debian box
Destination: 0.0.0.0/0
Protocol: TCP
Dpt: 25

The rules you have listed below allow ANY machine to:

1) Establish an SMTP session with your Debian box (port 25)
If this is the incoming mail server, then this is what you want
2) Use the Ident protocol (port 113) - Unless you really, really, really
need this for a specific reason, don't allow it
I'd get rid of it if I were you.
3) Connect to your debian box using SSH (port 22)
See if you can narrow down the source so that a limited # of machines
can attempt connection
4) Connect to your debian box using their web browser (port 80) assuming you
have Apache or other HTTP Daemon installed
Make sure you have all the security patches installed
5) Allow your name server to connect to this debian box on all protocols and
all ports
Ugh. I'm not sure why you want your name server to connect to you on
any and all ports and protocols. Assuming your debian box does not have
BIND or other DNS Daemon installed, you don't want this. Instead, on the
output chain allow the Debian box to establish outbound connections to your
name server on port 53 using both tcp and udp.
6) Ping your debian box
You might want to consider dropping ICMP packets.

One big, final thing: You should use the "state" feature of iptables to
allow related and established packets back in. If you use this feature, for
example, when establishing your outbound connections on the output chain,
the return packets from the established connection will be automatically
allowed back in. This prevents you from having to explicitly define rules
on the INPUT chain to allow the return traffic.

I hope this helps. If you're really intersted in a good book on IP Tables,
try "Linux Firewalls, 2nd Edition" by Bob Ziegler (ISBN: 0735710996).

Good luck.

-Jim

"Tatome" <gar_keiner@hotmail.com> wrote in message
news:5180178a.0502141526.76ca0e9b@posting.google.com...

Tatome · *nix forums beginner Joined: 14 Feb 2005 Posts: 3

Jim,
thank you very much for your answer. You gave me quite a few pointers
on what to look for to improve my firewall. I'll definetly remove the
rule for identd for example.
Still - even with that rule in the OUTPUT chain permitting outgoing
smtp connections I can't send e-mails. I would've been surprised, too,
if I could: the chain policy for OUTPUT is ACCEPT. It really seems to
be something with the INPUT chain configuration since everything works
just fine if I do iptables -P INPUT ACCEPT.
Last night I checked if the box in question finds out what machine to
connect to. It does. And it can resolve the host name, too. If I
permit returning icmp packages I can even ping the target mail server.
But the smtp connection times out and my guess is that my firewall
filters the mail server's answers, although I don't understand why.
But I really don't know enough about the smtp and tcp protocols.
Thanks again for your help,
Johannes

"Jim Ficarra" <jimficarra@verizon.net> wrote in message news:<4xeQd.21962$ya6.12554@trndny01>...

Jim Ficarra · *nix forums beginner Joined: 22 Feb 2005 Posts: 6

Johannes,

The INPUT chain does need to allow the return traffic for your outgoing SMTP
connection. Your mail server will initiate an outbound connection, going
through the OUTPUT chain, going to the SMTP destination port of 25. The
source port could be any port in in the range of 1024:65535.

So, you will need to allow the return SMTP traffic (coming from port 25 of
the remote server) to the local source port range of 1024:65535. Because
you haven't explicitly added this range on your INPUT chain when you set the
default policy to DROP, this is why it doesn't work. When you change the
default policy to ACCEPT it works, but as you know that makes it wide open.

To allow the port range of 1024:65535 on the INPUT chain, there are two ways
to do this:
1) Explicitly allow traffic from port 25 of any remote host to go to
ports 1024:65535. This will work, but is not really safe and I do not
recommend using it.
2) Use the STATE feature of IPTABLES to accept the return traffic.
(option "--state RELATED,ESTABLISHED" )

Option 2 is what I was referring to in my original response. If you use the
STATE feature, you effectively need to allow only the outbound connection to
port 25 on the OUTPUT chain, and then on the INPUT chain allow the STATE of
RELATED and ESTABLISHED. This will basically allow return traffic from SMTP
(or any other return traffic associated with a valid outgoing session) to
come back in.
RELATED and ESTABLISHED refer to the return packets being related to the
original allowed connection or part of an already established session.
Typically, you allow the STATE of RELATED and ESTABLISHED on all the chains
(built-in or user defined), set the default policy on the chains to DROP,
and then allow only the specific traffic on the appropriate chain (e.g. HTTP
on the INPUT chain to allow incoming browers to hit your web server).

In the case of SMTP, your Debian box not only sends e-mail to other servers,
it also receives it. Your rules would look like this:

To accept SMTP traffic to Exim on your Debian server:

Chain INPUT (policy DROP)
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 <your.ip.address>
state NEW tcp dpt:25

To allow outgoing SMTP traffic from Exim on your Debian Server:

Chain OUTPUT (policy DROP) <--yours is set to ACCEPT, but setting to drop
then allowing only the traffic you want with rules is typical)
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
ACCEPT tcp -- <your.ip.address> 0.0.0.0/0 state NEW
tcp dpt:25

You might want to consider Shorewall (http://www.shorewall.net/). It's a
good tool that provides a cleaner interface to IPTABLES.

Good luck. If you need some more pointers, just ask.

-Jim

"Tatome" <gar_keiner@hotmail.com> wrote in message
news:5180178a.0502160430.6bcd1079@posting.google.com...

Juha Laiho · *nix forums Guru Wannabe Joined: 22 Feb 2005 Posts: 139

gar_keiner@hotmail.com (Tatome) said:

Tatome · *nix forums beginner Joined: 14 Feb 2005 Posts: 3

Thanks a lot!
I just allowed any RELATED and ESTABLISHED traffic and things worked
great. I suppose the high port traffic coming back to my machine and
being blocked was what kept me from resolving domain names earlier,
too - the reason why I ACCEPTed all traffic from my nameserver.
I might buy a book about firewalls and all that sometime... once I'm
through my exams Wink

Again, thank you for your time and patience,
Johannes

ynotssor · *nix forums Guru Wannabe Joined: 09 Mar 2005 Posts: 209

"Tatome" <gar_keiner@hotmail.com> wrote in message
news:5180178a.0502170155.700dbf40@posting.google.com

Google