Hi,

I've disabled email relaying but spammers are finding ways to send spam via the formmail scripts on my server. Read about it here: http://www.newsbytes.com/news/02/174174.html

Changing the formmail scripts on the server is useless as the above article points out: "no official version of FormMail is safe from clever spammers"

I'm using RH 7.1, is there a way to configure the server to only relay the formmail script's email to an address on the server? Or any other suggestions?

hi, the same thing happened to me some time ago. First thing I did was to rename formmail.pl to somethingstrange.pl and it helped. Sure... if somebody looks at the source code of the plain html... well this idea becomes useless.

If you want to be 100% sure... I would try to look for another form mailer (cgi-resources.com) I'm sure you will find some where it will not be possible to override the hardcoded RCPT field.

I did not install another script... no spam happened since I've renamed the script. I guess there are some proggys out there which automatically look for formail.cgi and pl and abuse it.

Further, hemmm:stickout could you pls tell me how you did disable relaying? I'm using qmail+vpopmail and I'm getting crazy

http://www.webhostingtalk.com/showthread.php?s=&threadid=44072

Sorry for posting a help request while trying to help :rolleyes:

Relaying option is set to "closed" in PSA 2.5. I have over 2000 domains on my server, simply renaming the scripts will not work as clients can still upload dodgy scripts again and again. Keeping track and asking clients to change their scripts will be a huge task.

Any other suggestions?

This problem is critical and therefore I'm offering $100 to anyone who can provide a SUITABLE solution.

How many formail.pl scripts do you have on your server?
I ended changing all formmail.pl scripts on one of my servers.

I have 100 too many. Anyway, what's the point of upgrading your formmail scripts?

Changing the formmail scripts on the server is useless. Please offer me a REAL solution.

Originally posted by topwiz
I have 100 too many. Anyway, what's the point of upgrading your formmail scripts?

Changing the formmail scripts on the server is useless. Please offer me a REAL solution.


Sorry, I see no other solutions.
Even pair has changed all the scripts.
http://www.pair.com/pair/support/notices/formmail.html

http://www.webhostingtalk.com/showthread.php?s=&threadid=40126

I had the same problem

Please contact me via PM

Cheers Pete

Originally posted by bitserve
http://www.webhostingtalk.com/showthread.php?s=&threadid=40126

I like the idea of disabling formmail.pl or formmail.cgi but what's to stop clients from re-uploading a renamed form-to-email script e.g. spamdelight.pl the very next minute? Kindly elaborate.

Besides informing clients of this ban, are there any other drawbacks to this plan?

I don't think that any strong conclusions were made in that thread, but we discussed it a lot. And some ways that others are handling it was mentioned.

I think that the ultimate solution would be to make a mail wrapper that checks to see what program is calling it, so that you could only let CGI programs that have been verified to use it.

But each web hosting customer would have to request for you to verify their program, and then you would have to make their program so that they couldn't edit it, after you did. This would be a lot of work.

And of course block your users from using the local SMTP service, so that they didn't use scripts that used SMTP instead.

The best way to handle it so that customers wouldn't be inconvenienced might be to just search their programs for references to the mail binary, and audit new programs as they appear or are modified. This would also be a lot of work.

So far, I have not heard of a really good, easy solution. There may not be one.

For a solution to this problem please look at www.pwebtech.com/support.html we have an exact SECURE replica of formmail ready for use you can d/l it there.

Originally posted by jayglate
For a solution to this problem please look at www.pwebtech.com/support.html we have an exact SECURE replica of formmail ready for use you can d/l it there.

Seems to be similar to some of the solutions discussed. A policy along with providing a secure form mail script. How are you enforcing the policy? How do you identify other formmail scripts?

We monitor the systems files and for mp3 and formmail.pl and .cgi as well as the volume of mail coming out of the system to detect spam.

You're just going to have problems, if you use any Matt Wright script. The problem, of course, is that every day, another client decides to try out a new CGI or PHP script on their web site and all sorts of problems happen. I actually created a script to be ran via a cron job every 12 or 24 (or whatever) amount of hours, that launches a script that will go in, search and seek out any Matt Wright script on the server and delete it (just kidding) -- but it does seek out anything that's a script with the word "mail" in it (in any case), and auto-patches it, by replacing, removing and adding better functions to effectively "fix" that horrible script and prevent SPAMMERs from exploiting any of it's shortcomings.

I suppose you could use an alternative, but people still upload and use these other scripts. I tried to help out a client before, and I did the renaming thing and they were still hit, I also had made it require a POST method (which few SPAMMER's bother to try and do) along with checking the referrer (and denying anyone that didn't have a referrer). This also didn't work. The SPAMMER seemed to have specifically targeted this domain and actually created (or used an existing) script to just fake the referrer, use the POST method and have his SPAM sent through again. This pissed me off, to say the least, since I thought it was one of those lame SPAM bots -- obviously not. I continued to try and get the client to use an alternative, but they had this all customized with their own layout, etc. I told them that they can recreate that layout, and that we simply can not use this script and it will have to be taken offline if they continue. I told them that all of this could be avoided to, but they have to hard code their RCPT address in the script -- but then a SPAMMER would just end up SPAMMING them a few thousand times.

So, I tried another thing, where I made it so the script could only be accessed up to so-many (5 in this case) times by the same IP within an hour and would either block them from using it for an hour (or better yet, and what I did; it would block them/ban them). Still, alternating sources of sending this. So, that didn't help either. I got sick of it and I just said "Let's keep in all the stuff we have now, since it's there and it helps prevent abuse still, but we'll hard code in your address (and we can make it have multiple choices and even depend on what page it's from -- you can use a system like a hidden tag and rather than the email, you put a number or any type of specification, and that will call to the corresponding email address that can be held in a text file that you have control over to specify the RCPT addresses, as well as the sender, etc. too). At that point, we tear out the "$to" variable and we simply make it so anyone that specified a $to variable (POST, GET, or whatever method) will automatically be blocked and logged (and log the environment) and report them to the administrator of the source of these SPAM attacks" -- or something to that effect.

This had completely stopped the SPAM attacks and after being automatically blocked from about 50 IP's, that SPAMMER finally moved ON! With those above steps, it stopped the SPAMMER and any other SPAMMER -- it simply wasn't possible to SPAM through it. Further, even if they could, it would block them by their 5th attempt and none of the SPAMS' would go out (and more than one RCPT address would cause it to fail as well (plus not allowing CC or BCC)). I created some intelligent logic in a replacement script to go in, recognize if it's a Matt Wright form mail-type of script and auto-fix it every so-many hours. Of course, you'll need to inform the client about this before doing this or create a policy about that you will and have it automatically send an email alert to their account and contact email address so they are informed about what was done, how and why. This will stop any SPAMMER's from exploiting those scripts, at least -- and they are one of the more popular one's that are used by SPAMMER's. I found that with enough servers, with enough clients, that it was just better to implement a policy and simply create a script to run automatically every so-often and check for any new un-patched scripts and make the appropriate changes to their forms and scripts without any constant monitoring or manual searching, etc. Be it automatic or not, you can see that even with a horrible, insecure and inefficient script, as long as it's popular and rampant and used by a lot of newbies, that there are ideas that you can have to stop it from being the cause of more headaches.

Implementing monitors and other tools to not allow user's to run too many instances of scripts, or anything that will access certain tools/programs or use too much resources, or too often, will also prevent a lot of other problems. You should configure your server to be able to deal with and prevent, by some means, any script or program from being abused or being the cause of abuse by implementing reasonable limitations and whatnot. You should be okay then and you can deal with the occassional problematic issues that will still surely arise -- but just planning well will prevent the majority of problems.

Hi,

today we was hit by same thing. Somebody from our competitor hosting companies network tried to spam through formmail.cgi script on one of our server. :angry:

We gone mad searching out who is spamming. Then finally somehow after rotating many many logs searching here and there i found somebody was using formmail.cgi to spam. :kaioken:

Man this is crazy stuff. We have many formmail and such scripts installed on many servers. how do we search for holes in every scripts. :unhappy:

Do anyone have the script which search for such holes or we have to go through each and every script manually?

Many thanks to tim greer for his suggestions and help. :)