Alternatively, is there a way to just end the process with NO return to the user, or effectively black hole the request with NO reponse?
The
MyApache2::BlockIP2 mod_perl example will, for blacklisted IPs, simply abort the connection without sending any reply to the client.
| [reply] |
That is probably the best solution, BUT it will only work on an Apache2 server.
CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
| [reply] |
One option I have considered is to forward to my server on a port I have a sentry on, which will block the IP at the firewall, so there will be no further contact (and no write to the logs!) I set up a return REDIRECT, but that sends a 302 with the new URL, and that hits my logs. NOT a good solution.
Why not also push a specialized log handler onto the stack that will prevent logging for that namespace?
| [reply] |
You can also configure conditional logging using the mod_log_config (Apache) module. I would imagine that any Perl module doing the job has to address that eventually.
| [reply] |
Thanks for the help so far- I have been thinking a few different ways to proceed.
OK, the SetEnv looks like a good solution. Not quite sure how to set that in the mod_perl script...
Is it as simple as:
env="spammer"
or more like:
$r->headers_out->{"env"} = "spammer";
(Sorry, I told you I was a novice!)
Dave
| [reply] |
| [reply] |
Might be overkill but you could add some mod_rewrite rules to your apache config to match against your referrers.
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
D
| [reply] |
I am writing an Apache Module, based on an existing script Apache::BlockIP. The existing script will block IP addresses (contained on a text file). Basically, you abuse my site, your IP gets written to this file, and Apache::BlockIP will block you from further activity.
Hmm... once this file gets big, looking through this flatfile for every single request might be getting too expensive. There most be a way to make it faster...
You could, as the document page referred to by one of the previous replies, indeed use a dbm database... or a SQLite database could work too. You'd have to compare the results in a benchmark.
As this is for modperl, you probably could just as well store them in an in-memory hash. It'll be fast. It could eventually be big, too, depending on how many IPs you have blocked...
If you have more than one webserver (that could be just child processes of the same mother web server) and they share this database (probably), you may still have to set up a make like set-up: you load the data from the file into the hash at startup, and every time you notice the modification date of the text file has changed, for example.
One the hash gets too big, there might be a way to optimize this into something that's like a hash, but using much less memory. For example, you could use nested trees, splitting each IP address into bytes, and have a 256 entry array for each... and use vec at the last (4th) level, storing just a single bit, that'll use just 32 bytes for a block of 256 IP addresses. But it won't be as fast as a straight hash.
It might even be a good idea to turn the latter into an XS module.
| [reply] |
The best place for dropping packets is at the firewall, just add a rule to DROP packets from those addresses.Now, to get perl back involved, write a script to modify the firewall rules as it automatically detects log file spammers. -Scott | [reply] |