Web Hosting Talk







View Full Version : Apache Regexp format, to fight SPAM through formmail < 1.9


jucebro
10-29-2001, 01:35 PM
I'm trying to setup apache, on a Cobalt Raq 4, to not allow spammers to use vanurable FormMail's. The Idea is to not allow anyone access to the site / server if they are trying to send the recipient varaible to formmail :

"..../formmail.pl?recipient=..."

-- or --

"...../formmail.pl?X=whatever&Y=whatever&recipient=..."

basicaly, if "formmail.pl" & "recipient=" are both in the Apache Request_URI, in upper or lower case, I would like apache to not allow the request.

here is what I have so far:


SetEnvIf Request_URI ".*(formmail\.pl).*(recipient=)" spammer=true

SetEnvIf spammer true keep_out

<Directory /home/sites/site*/web/cg*/>

Order Allow,Deny
Allow from all
Deny from env=keep_out

</Directory>


This works nice untill I try doing more then "formmail.pl" as the regexp. I'm a newbie to the Regular Exp. sceen, anybody know what regexp pattern would do what I need done above?

I have thought about replaceing the "SetEnvIf" line with:

SetEnvIf User-Agent "^Microsoft URL Control" spammer=true

But i don't really want to just deny everyone using the MS control from accesing the server, just because some spam tool out there uses it.text to color.

It would be nice to be able to do something like "If User-Agent == Microsoft URL Control AND Request_URI has formmail.pl in it, THEN Deny", however this is proving to be a pain to figure out.

Thanks in advance

Tim Greer
11-01-2001, 02:45 PM
Are you processing just the GET method, or the POST method too? If this is just grabbing the URL, for example, which will only show with the GET method, it would be far simpler to just deny the GET method in all the formmail scripts (Which you can write a quick script to go through, check and add a condition to all the formmail scripts on the server) and the SPAMMER would have to use a form to post (which would add hassle due to the referrer field) -- so they'd have to create a script on their server to simulate a POST method to that script on your server and fake the referral (which can be done, but that would just be far too much of a hassle and few SPAMMER's know how to do that anyway).

That would maybe be a faster solution, but your idea is workable -- but again, if you're just going to check GET in the URL Query_String, you would be better off just doing what I said above and it would save processing overhead on all the requests that didn't have any bearing on that aspect.

jucebro
11-01-2001, 03:21 PM
Good thinking. Just deny the GET method in the FormMail script, less demanding on the server and should be fairly easy to write a shell script to do what you sugested. I thnk I'll try out that route.


Thanks!

Tim Greer
11-01-2001, 03:57 PM
I wrote a perl script to seek out any file named "formmail.pl" and "formmail.cgi", it would open up any and if it found it was one of those crappy Matt Wright scripts, it would process the file and add some routines to make sure that you had to use the POST method, which stops at least (literally) 99.9% of the SPAMMERs that seek out that script to SPAM through.

Additionally, and with your client's permission, of course, you should not allow these scripts to have the "from" address passed to it as a value from the HTML form that posts to it, so you can see who it's from for one thing, especially if you have your scripts all running as the web server's global user. Have them specify it in the script itself, or provide some interface that they can use to change it in the script that way.

Finally, to ensure that they are using the referrer checking field, in case they aren't and then put in a one, two or three second delay to control how often the script can be accessed. Put in some message like "You must wait 2 or 3 seconds between submitting information to this mail form script". Again, with the user's permission, this can really help, to where even if someone fakes the post method and referrer, that they still are subjected to only being able to access to form each 2 or 3 seconds, it would be a huge waste of time.

You can also go further and just make the script log any IP of any user (even set a cookie too, I know this is a little much, but hey!) and have it block any IP that is A: trying to use the GET method from using the script. B: blocks access to any IP from using the script, that accesses it more than so-many times within a certain duration. Like over 5 times in 5 seconds, over 20 times in a minute or over 50 times in an hour or whatever is most appropriate. Even with Matt Wright's horrible formmail script, those simple modifications will make it pretty much secure from exploits and SPAMMERS. Just some ideas, and again, a script to seek out and check and automatically add these things to these horrible scripts that plague us administrators.

Of course, all that said, I think it's apparent, that it would be better to just ask people not use Matt Wright's crappy scripts altogether and provide then with alternatives and end up avoiding all the other exploits and problems those scripts have anyway. Good luck.

jucebro
11-02-2001, 01:15 PM
Thanks for the input tim, You've shed new light on this. It sucks haveing to be a maintaince Programer for some not-so-well designed mail script, but it's worth it if it stops even one SPAMMER.

Tim Greer
11-02-2001, 01:30 PM
I completely agree. There's never too much effort, time or work when it's for an effort of keeping idiot SPAMMERs from abusing your site/server or your client's scripts. You can do everything to secure your server, and a poorly written (or purposely written) script that can be used for such things as SPAM, is just no fun. It's great that people take steps to stop it, because (as I'm sure you know) few hosts take those steps or seem to care or be able to stop it. It's hard to catch up though, with all the code user's themselves write, not to mention the one's that they buy, have coded for them or more usually and worse, the free one's they sometimes download. The best idea, is to educate your client's on what to use or not, as well as provide them with alternative suggestions -- or just offer them an alternative from some quality in-house code/script that you can give to your client's to use. Other than that, we can see above the hassles of dealing with the negative aspects of just one badly written/designed script, and there's a lot more than that. Basically, stay away from any script coded by Matt Wright, seriously. That's a good start. :-)