I have set up entries in /etc/hosts.allow and /etc/hosts.deny as follows:
/etc/hosts.allow sendmail : 10.0.0.0/255.0.0.0 sendmail : LOCAL
/etc/hosts.deny sendmail : ALL
When I try to connect to port 25 from an Internet host via telnet, the server still responds as usual. The only difference I see is this in my /var/log/maillog:
Apr 24 15:41:49 server sendmail[20691]: m3OKfna20691: tcpwrappers (otherserver.example.com, xx.xx.xx.xx) rejection
How do I make tcpwrappers simply drop the connection? I would prefer to do this with TCP Wrappers, at least until we get our official IPTables firewall policy worked out.
thanks
Sean
On Thu, 2008-04-24 at 15:45 -0500, Sean Carolan wrote:
I have set up entries in /etc/hosts.allow and /etc/hosts.deny as follows:
/etc/hosts.allow sendmail : 10.0.0.0/255.0.0.0 sendmail : LOCAL
/etc/hosts.deny sendmail : ALL
When I try to connect to port 25 from an Internet host via telnet, the server still responds as usual. The only difference I see is this in my /var/log/maillog:
Apr 24 15:41:49 server sendmail[20691]: m3OKfna20691: tcpwrappers (otherserver.example.com, xx.xx.xx.xx) rejection
How do I make tcpwrappers simply drop the connection? I would prefer to do this with TCP Wrappers, at least until we get our official IPTables firewall policy worked out.
$ ldd /usr/sbin/sendmail.sendmail | grep wrap libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00319000)
tcp_wrappers never sees the connection directly. sendmail handles it from start to end.
Sean Carolan wrote:
$ ldd /usr/sbin/sendmail.sendmail | grep wrap libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00319000)
tcp_wrappers never sees the connection directly. sendmail handles it from start to end.
Thanks for this info. I will set up an iptables rule to block this access.
I'm confused. I'd expect the above symbol listing to show that sendmail is in fact using the libwrap library and it should be doing what the allow/deny files say.
Regardless, the simple way to tell sendmail what you want to permit is to use the /usr/mail/access file.
I'm confused. I'd expect the above symbol listing to show that sendmail is in fact using the libwrap library and it should be doing what the allow/deny files say.
Regardless, the simple way to tell sendmail what you want to permit is to use the /usr/mail/access file.
My goal was to block *ALL* IP access to port 25. Incidentally I found some other ports that shouldn't have been exposed so those were closed off as well.
thanks
Sean
Sean Carolan wrote:
I'm confused. I'd expect the above symbol listing to show that sendmail is in fact using the libwrap library and it should be doing what the allow/deny files say.
Regardless, the simple way to tell sendmail what you want to permit is to use the /usr/mail/access file.
My goal was to block *ALL* IP access to port 25.
In that case you might as well just shut down sendmail. Or if you only want it to listen on an 'inside' interface, set the appropriate address in the DAEMON_OPTIONS entry in /etc/mail/sendmail.mc (which you must have already modified since the default is to only use the loopback interface 127.0.0.1). But you can still control connections completely in /etc/mail/access.
On Thu, Apr 24, 2008 at 5:32 PM, Ignacio Vazquez-Abrams ivazqueznet@gmail.com wrote:
$ ldd /usr/sbin/sendmail.sendmail | grep wrap libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00319000)
This means that sendmail is a valid option for hosts.allow or hosts.deny as sendmail has been compiled with support for libwrap.
~Jeffrey
Jeffrey Tadlock wrote on Thu, 24 Apr 2008 22:48:19 -0400:
This means that sendmail is a valid option for hosts.allow or hosts.deny as sendmail has been compiled with support for libwrap.
Sure. The point was that the poster expected tcpwrapper to take and process the connection and not sendmail. But this could only happen if sendmail were not running as a standalone daemon and tcpd were responsible for port 25 via inetd. Support for libwrap just means that sendmail can make use of it while *it* is processing the mail.
Kai
-
Ignacio Vazquez-Abrams -
Jeffrey Tadlock -
Kai Schaetzl -
Les Mikesell -
Sean Carolan