By default, sendmail only listens on the localloop:
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
But by default to allow sendmail to even work the iptables entry is:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
Without this, sendmail can't even connect to localloop. But should I handedit this line to something like:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
And once you handedit iptables, you can't use the gnome firewall applet, I suspect...
On 11/22/2010 9:11 AM, Robert Moskowitz wrote:
By default, sendmail only listens on the localloop:
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
But by default to allow sendmail to even work the iptables entry is:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
Without this, sendmail can't even connect to localloop. But should I handedit this line to something like:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
And once you handedit iptables, you can't use the gnome firewall applet, I suspect...
Every security decision has its own tradeoffs, so first you need to consider what you are trying to protect against. If you don't have a program listening on a port, it doesn't matter whether it is explicitly firewalled or not. A program needs root access to listen on ports below 1024 - and anyone with root access can change the iptables settings too...
On 11/22/2010 10:43 AM, Les Mikesell wrote:
On 11/22/2010 9:11 AM, Robert Moskowitz wrote:
By default, sendmail only listens on the localloop:
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
But by default to allow sendmail to even work the iptables entry is:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
Without this, sendmail can't even connect to localloop. But should I handedit this line to something like:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
And once you handedit iptables, you can't use the gnome firewall applet, I suspect...
Every security decision has its own tradeoffs, so first you need to consider what you are trying to protect against. If you don't have a program listening on a port, it doesn't matter whether it is explicitly firewalled or not. A program needs root access to listen on ports below 1024 - and anyone with root access can change the iptables settings too...
Ah, there is the combination I missed. I was concerned about sendmail doing what I thought it was suppose to do: only listen on loopback. If something could change that behaviour, it could also change any iptables settings.
I have 25 blocked on the firewall anyway. But just looking at the i(s) and t(s). (while trying not to stuff more angels on the pinhead or some such metaphor).
On 11/22/2010 10:06 AM, Robert Moskowitz wrote:
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
But by default to allow sendmail to even work the iptables entry is:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
Without this, sendmail can't even connect to localloop. But should I handedit this line to something like:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
And once you handedit iptables, you can't use the gnome firewall applet, I suspect...
Every security decision has its own tradeoffs, so first you need to consider what you are trying to protect against. If you don't have a program listening on a port, it doesn't matter whether it is explicitly firewalled or not. A program needs root access to listen on ports below 1024 - and anyone with root access can change the iptables settings too...
Ah, there is the combination I missed. I was concerned about sendmail doing what I thought it was suppose to do: only listen on loopback. If something could change that behaviour, it could also change any iptables settings.
I have 25 blocked on the firewall anyway. But just looking at the i(s) and t(s). (while trying not to stuff more angels on the pinhead or some such metaphor).
Yes, it is always better to deny anything questionable - and to block at your border router(s) too, but realistically if someone can get that far you are fried anyway. Also, even if sendmail does accept remote connections, it won't relay for them without additional changes to the config.
Am 22.11.2010 16:11, schrieb Robert Moskowitz:
By default, sendmail only listens on the localloop:
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
But by default to allow sendmail to even work the iptables entry is:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
Without this, sendmail can't even connect to localloop.
No, that is not correct. You miss to see the following rule
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
in the default /etc/sysconfig/iptables config file. So there is no problem where you see one.
But should I handedit this line to something like:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
And once you handedit iptables, you can't use the gnome firewall applet, I suspect...
Alexander
On 11/22/2010 05:52 PM, Alexander Dalloz wrote:
Am 22.11.2010 16:11, schrieb Robert Moskowitz:
By default, sendmail only listens on the localloop:
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
But by default to allow sendmail to even work the iptables entry is:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
Without this, sendmail can't even connect to localloop.
No, that is not correct. You miss to see the following rule
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
in the default /etc/sysconfig/iptables config file. So there is no problem where you see one.
Last week I built a new Centos 5.5 server. I installed logwatch and run logwatch to 'force' the output. Before I did that, I had created /root/.forward with my email address.
Sendmail could not send the message. I went into the gnome firewall applet and allowed smtp, adding the rule I showed and still nothing. Then I figured that the message was queued (that is what maillog said) and would stay there for a while, so I restarted sendmail, and the message went right out.
So empirical evidence strongly supports the need of this rule.
-
Alexander Dalloz -
Les Mikesell -
Robert Moskowitz