hosts.deny should work straight off, nothing needs restarted. One thought though, look for a /usr/local/etc/hosts.deny (or one under /usr/local anyway) I've discovered on some systems a hosts.deny in there that seems to be the active one. Also its worth look in hosts.allow for any quirkiness.

I spent 30 minutes trying to figure out why a block I added to /etc/hosts.deny wasn't working only to discover a hosts.deny in /usr/local. It may be worth blocking their whole subnet through iptables, along with reporting the abuse to their ISP/Hosting firm. If they don't care to deal with the abuse issue, you shouldn't care to receive traffic from them.

Make sure the ALL: PARANOID is not commented (Remove the #). That is why it probably isn't working. It only blocks SSH otherwise.

-ZeroDamage

well, no matter what I do, hosts.deny does not work.

I just logged to a remote server and used 'links' to test if I can connect to my forum. I could. Then I added the domain of the remote server to hosts.deny like this

ALL: .domain

I tried links and I still could connect. Then I tried the above with exact IP of the server, still no success.

/etc/hosts.allow is empty, there is no additional hosts.deny at /usr/local/etc/

AFAIK, hosts.allow and hosts.deny are the conf files for the tcpd wrapper. These are usually read only when a new connection arrives that triggers inetd, which in turn has to launch the appropriate daemon.

Some other applications (e.g. ssh) were designed to obey their contents as well, but they are not forced to.

Which web server do you use? Are you sure it chose to obey these files? If yes, are you sure it re-reads them at every access, or it just reads them once at startup?

What does 'tcpdchk' say?
Have you tried 'tcpdmatch'?

Last but not least: if your web server's not started from (x)inetd or isn't built with tcpwrappers support /etc/hosts.{allow,deny} won't work.
If that's the case use iptables/netfilter.

rjc