How to make Apache (2.2.4) less greedy, or Sendmail less polite? [semi-solved]

Howard MITCHell Feldman hfeldman at
Tue May 8 16:10:29 UTC 2007

Here's what I do with spammers and others I want to keep out of my server...

I make an IP entry into my /etc/hosts.deny file of those I want to deny 
access to my server.  Then I make an entry in my /etc/hosts.allow file 
that denies access to all in my hosts.deny file.  That entry is the 
first non-commented entry in the hosts.allow file and looks like:

ALL: /etc/hosts.deny: deny


Olaf Greve wrote:
> Hiya all,
> Well, I promised you guys a follow-up on this, and here's what I have 
> found out (first the situation and solution, and then two small 
> questions)....
> The situation:
> Firstly, I took some measures to figure out where the issues came 
> from, and using Apache's "server-status" handler (tnx for that 
> recommendation!), I noticed the script that caused Apache to choke up 
> (i.e. grab an excessive amount of resources), was a PHP script that 
> shows entries of photographic events that I organise from time to 
> time. This didn't happen for all entries, but only for specific ones.
> I then wondered why, as this script never caused trouble before, and 
> while checking the server status I did already notice that the "store 
> comments" script (allowing visitor's feedback to the entries) was 
> called very often. Too often. I checked out the sizes of the comments 
> files (which normally are very small plain text files, of perhaps some 
> 4Kb size at most), and lo and behold: some of them were as big as 
> 18Mb! The main issue then becoming that when these files were parsed as
> text by PHP when an entry is shown, this either took a long time to 
> complete, or in the worst case caused even a core dump to be generated 
> by the over-excessive load on the server's resources.
> Next, when checking the contents of those files, it became apparent 
> that they were completely hammered with all sorts of typical 
> commercial spam, referring to vi*gr* websites, etc. I think this is 
> known as "forum spam" (or so), but my site uses custom scripts, so 
> someone must have found the URL, and made use of it by manually 
> figuring out the parameters and it's functionality.
> The (partial) "solution":
> For now, I have configured the webserver so, that ANY call to this 
> "store comments" script is forbidden, and will simply generate a 
> standard server error (hopefully the spammers will signal these server 
> errors, and will stop the hack attempt), while I am looking into a 
> better solution (e.g. by having to type additional text (anti-spam 
> challenges) when posting a comment). But then, as mentioned above, 
> someone went through the trouble of figuring out how to manipulate my 
> code, and hence caused me a LOT of time being wasted, so I want to 
> "reward" them for their trouble, by punishing the responsible people 
> as much as possible. Therefore, I will go through the Apache access 
> log to work out the IP addresses of
> the machines that were used for this, and I will report them to the 
> proper anti spam authorities, such that they will be blacklisted 
> Internet wide. If anyone knows of good places to do so (the more, the 
> merrier), I welcome hearing about them...
> The questions:
> -Can anyone recommend me proper anti spam authorities to whom I can 
> report the IP addresses that caused the issues on my machine?
> -At present, in Apache I have added:
> <Location ~ "store_comments_script.php">
>     Order deny,allow
>     Deny from all
> </Location>
> Can anyone tell me of a good way to only ever allow calls to this 
> script coming from the proper previous script, or should this be 
> handled from PHP itself?
> Perhaps this question isn't very clear, but what I'm looking for is a 
> way to block any and all direct calls to this script, that originate 
> from anywhere but from the photography site itself.
> Can anyone help me perhaps with those two thingies?
> Tnx once more, and cheers!
> Olafo
> _______________________________________________
> freebsd-amd64 at mailing list
> To unsubscribe, send any mail to "freebsd-amd64-unsubscribe at"

More information about the freebsd-amd64 mailing list