hosts.deny apparently ineffectual

I'm running a RedHat ES mail server (Postfix, Amavis, ClamAV), which has been barraged lately by the Zafi worm.  

Messages arrive from "" and one of three (so far) IP numbers.  

My hosts.deny file looks like this:


But these settings appear to have no effect (I restarted xinetd and have infact rebooted since changing settings).

I have an AT&T managed router and have had them deny the first two IP's, but almost immediately messages began to appear from a third.  I'd like to be able to take care of the denial on the server rather than the router (just to avoid needing to bug the AT&T people).

Would appreciate any suggestions.  I've never had to deny a host access before and feel like I'm missing something terribly obvious.  Points are based on some urgency.

Thank you!
Who is Participating?
ahoffmannConnect With a Mentor Commented:
is amavisd called by the portmapper from inetd? or runs it as daemon?
In the latter case host.deny is not used, except amavisd does it itself, you need to check your docs
i.g. if your MTA (postfix) runs as daeomon hosts.deny is not in use
You need to tell postfix from which IPs to accept mail

and some more are your friends ..
suzdorrAuthor Commented:
Good information, ahoffman.  Don't think it'll be my solution, unfortunately.

Amavisd gets the mail first and does virus and spam checking before sending it on to post fix.  I'd like the mail rejected from the outset, since the whole process of virus scanning, message bouncing, and administrative notification consumes so much server time and log space.  (I'm getting a Zafi message every few seconds -- so my log is full of this junk.)

I've put the IP number and name in my Amavisd blacklist, but that seems to have no effect.  Now that I know hosts.deny has no effect (thanks!) I'll do some further study of amavisd.conf to see what I might have missed.  If anyone has any thoughts about that, I'd be grateful.

MysidiaConnect With a Mentor Commented:
Generally hosts.deny is not used unless  the program is run from inetd using tcpd  or was linked against
the tcp wrappers library when compiled.

I think your best off installing/enabling Netfilter on the system and using iptables to filter out the connections earlier on
using the firewall configuration, i.e.

iptables -A INPUT -s  --dport 25 -j DENY

(and make sure firewall settings are saved in some manner so that the rules will reload at boot)

your other blacklist is still useful in case they get a new ip with the same domain
Lego_ManiacConnect With a Mentor Commented:
If you don't have iptables installed, you can also do the "poor man's firewall".  
Basically route the IP addresses into a black hole, so that return traffic can't reach the offending IP addresses.
SMTP requires a bidirectional communication, so if your traffic can't get back to them, they effectively can't open the SMTP connection (or any connection)

route add gw
(pick any unused IP that's local to your network)

This will cause some ARP-WHO IS traffic, but you can cure that with static arp entries:
arp -s aa:bb:cc:dd:ee:ff
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.