Linuxhelp > Firewall (iptables) blocking sendmail some how

Full Version: Firewall (iptables) blocking sendmail some how

ganz_friedrich

Feb 15 2006, 06:49 AM

Hello,

I have iptables set to accept input and output on port 25 (conf below for reference), yet for some reason when I have the firewall enabled, emails won't send.

Are there some other ports sendmail needs to send emails?

Thanks

IP tables set-up script
-----

CODE

*mangle
:PREROUTING ACCEPT [444:43563]
:INPUT ACCEPT [444:43563]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [402:144198]
:POSTROUTING ACCEPT [402:144198]
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
COMMIT

*filter
:INPUT DROP [1:242]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:LOG_DROP - [0:0]
:LOG_ACCEPT - [0:0]
:icmp_packets - [0:0]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j LOG_ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -p icmp -j icmp_packets
-A INPUT -j DROP

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -d 127.0.0.1 -j ACCEPT
-A OUTPUT -p icmp -j icmp_packets
-A OUTPUT -j DROP

-A LOG_ACCEPT -j LOG --log-prefix "[IPTABLES ACCEPT] : " --log-tcp-options --log-ip-options
-A LOG_ACCEPT -j ACCEPT

-A icmp_packets -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A icmp_packets -s 127.0.0.1 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 8 -j DROP
-A icmp_packets -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT
COMMIT

Robert83

Feb 15 2006, 08:29 AM

Hi,

when the client is behind the firewall that is trying to use smtp ... that is actualy the FORWARD rule.

So you need to make a Forward rule to allow smtp from local interface to external interface

Sincerely
Robert B

ganz_friedrich

Feb 15 2006, 09:32 AM

Thanks very much for the reply, but what is the rule I should use?

I've tried

-A FORWARD -p tcp -m tcp --dport 25 -j ACCEPT

and

-A FORWARD -s 127.0.0.1 -j ACCEPT

but to no avail.

(That is correct: I am trying to send from the same server that runs sendmail and iptables)

ganz_friedrich

Feb 15 2006, 10:33 AM

Just to add:

I've had an unsuccessful time understanding sendmail: I've read you can just invoke a script to send emails and you don't have to run the sendmail service, but I've been unable to do this - the sendmail service needs to be running to send emails. (someone - who should know - even said that sendmail is not a server, but just a script???).

So anyway, the point is that I only want to make sendmail avaliable on the server that it's running on. I'm not even sure how sendmail works - whether by default it just allows anyone to use and abuse it. Since the whole "invoke" thing doesn't seem to work - I was glad to see in netstat that at least the service seems to be restricted to localhost.localdomain - which is good.

So what exactly is happening with this forwarding? Does php (which is trying to send I guess via Apache), try to access sendmail listening on localhost from the Internet address on which apache is listening - and then sendmail tries to access the internet from localhost?

I would be truely grateful if you could explain this a little.

Thank you

DS2K3

Feb 15 2006, 01:42 PM

PHP on UNIX is slightly different to PHP on Windows. On UNIX, it uses sendmail directly. Sendmail is a binary program, not a server as such, which other programs use to send emails to another server, or to deliver them directly. On windows, PHP requires that an SMTP server is listening for emails.

There is probably a sendmail log somewhere which will give you more information. Have a poke around in /var/log and see if anything looks releveant.

D

ganz_friedrich

Feb 16 2006, 04:36 AM

The FORWARD rules do not seem to be the problem. I have set to accept forward by default, and it still does not work. Also, I made sure that the mangle rules were not the problem by resetting them to accept all and the problem was not avoided.

So what is going on???

ganz_friedrich

Feb 16 2006, 06:47 AM

In case anyone is looking for the same answer, someone on lq helped me out:

Sendmail needs to resolve domains so the server must have access to dns (port 53). Rules:

-A INPUT -p udp --sport 53 -s <nameserver> -j ACCEPT
-A OUTPUT -p udp --dport 53 -d <nameserver> -j ACCEPT

---

Anyway, thanks for trying to help me out - I appreciate it. Glad this one's solved - it was beginning to piss me off.

ganz_friedrich

Feb 16 2006, 11:39 AM

Also, just to mention, the point about the FOWARD rules was also true - so thanks for that.

Robert83

Feb 16 2006, 12:49 PM

You're welcome

I just hope that next time we'll be able to help you more

Sincerely
Robert B

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.