Just a thought, I wonder if it would be possible to extend the LSQL IP banning to static pages, in particular the home page, by way of a javascript function or something similar which checks the banned list on page load?

The function would grab the users IP, check it against the banned list, and either continue loading the html page, or displayed the banned template dending on the outcome.

Maybe the funciton could just call a cgi file which does this.

I think I could write the cgi, but I am sure I don't know how to do the javascript side of it.

The other problem is, a user could just disable javascript in their browser I suppose and by-pass the security. Hmmmmmmm.


http://www.iuni.com/...tware/web/index.html
Links Plugins

Two suggestions:

1) add deny from IPaddress in your .htaccess file.

2) You could probably use SSI to run the check in "static" web pages. I don't think that javascript would be a good approach with the limitations you've outlined.
========================================
Buh Bye!

Cheers,
Me

Thanks for the suggestions.

I am interested in point 1, you have mentioned.

I'll search google for the syntax.


http://www.iuni.com/...tware/web/index.html
Links Plugins

order allow,deny
deny from 123.45.6.7
deny from 012.34.5.
allow from all




http://www.iuni.com/...tware/web/index.html
Links Plugins

<LIMIT GET POST>
Order Deny,Allow
Deny From some ip
Allow From All
</LIMIT>

Thanks Paul... I realised last night after searching google that I needed the <Limit GET>... </Limit>, but what is the POST part for?


http://www.iuni.com/...tware/web/index.html
Links Plugins

Basically, the POST restricts access to the METHOD="POST" within cgi scripts.

More info: http://hoohoo.ncsa.uiuc.edu/.../tutorials/user.html

Found via searching Google:

http://www.google.com/...=LIMIT+POST+htaccess


BTW: If you really want to be jazzy with this solution, you might want to consider dynamically updating the .htaccess file or updating it on a nightly basis via querying your BANNED IP table and then inserting the appropriate codes into your .htaccess file. Although in terms of risk in corrupting the file, it may be wise to update it on a daily basis rather than on-the-fly.
========================================
Buh Bye!

Cheers,
Me

GET is the method of downloading a page when you request it via your browser, if you only block GET requests then some nasty spammer could still POST to your site via your web forms.

For safety I use:

<LIMIT GET POST PROPFIND>

I know you are going to ask so before you do:

PROPFIND:

The World Wide Web Distributed Authoring and Versioning (WebDAV) PROPFIND Method retrieves properties for a resource identified by the request Uniform Resource Identifier (URI). The PROPFIND Method can be used on collection and property resources.

Thanks stealth and paul.

Very interesting, and this is a really big help... as I do have a reasonable list of "unfriendly" types that are spammers etc, I need to safely block.

I am going to add the PROPFIND, thanks for that too!

I'm be reading up on this topic a little more... thanks for the links also.


http://www.iuni.com/...tware/web/index.html
Links Plugins

Just want to say thanks for your info in this thread.

I've been looking for a way to block specific spammers by IP address. In my case they'd been using the POST method through another script, probably one of those directory spamming programs, and whilst I'd updated my add.cgi script to check banned IP addresses it was only catching them if they submitted via a browser.

This .htaccess method of blocking them works great and since it covers non-browser POST requests I've now got it covered on all sides

One note though; in my case I found that it does seem to matter which way round you put the allow and deny. To get it to work on my server I had to 'allow from all' BEFORE I 'deny from xxx' (order allow,deny).

Cheers
Shaun

Just an update to my problem of being spammed with submissions; which is now cured.

In my worst case the IP address reported from $ENV{'REMOTE_ADDR'} appears to have been spoofed (false address) so any solution based on the reported IP address failed, including the 'deny' in .htaccess

However after looking at my access_log file I found the acutal[/i] IP address was slightly different and once I'd added a 'deny' the problem was sorted - instantly

Just thought I'd mention it in case anyone else has a similar problem.

All the best
Shaun

I always thought $ENV{REMOTE_ADDR} would have been the same as the logged address...I guess perl generates it differently to apache.

Paul,

I'm not exactly sure of the technicalities, however I use the $ENV{REMOTE_ADDR} to get the IP address for the submission form (extra field in the form) and when I tried blocking that reported address nothing happened, either through a routine in add.cgi or via htaccess itself.

However, when I looked in my access_log file it was a different IP address that was making all the POST requests so I assumed they'd spoofed the env. variable somehow?

Maybe I'm barking up the wrong tree - I'm not exactly a know-it-all when it comes to server management - but all I know is that it stopped all the crap submissions and that's good enough for me ... for now anyway

All the best
Shaun