On Wed, 10 Sep 2003 00:53:06 +0200, Kevin Pfeiffer <[EMAIL PROTECTED]> wrote:
> [a little OT in a general way...]
>
> This was sent to another list today and I am wondering what the answer might
> be...
>
> > The following data was submitted from the Frequently Asked Questions
> > Form
> >
> > Name: [EMAIL PROTECTED]
> > E-mail: [EMAIL PROTECTED]
> > Telephone Number: '
> > Question: [EMAIL PROTECTED]
> >
> > I googled [EMAIL PROTECTED] and found that this person hit
> > other online forms on the web too.
> >
> > I was wondering if any of you have experienced this and is there a way
> > to prevent it from happening again? It brought down our server because
> > it couldn't handle so many mail requests. We checked the logs and this
> > person spoofed one of our own IP addresses.
>
>
> My thought is to add some simple field validity checking to the form-to-mail
> script. Not perfect, but would at least stop the mail (until the bad guy
> writes a cleverer script). But what about the submission process? How to
> stop someone from scripting 2,000+ form submissions? (If at all)
>
What fields would you validate and how? You could do some simple checking to make sure
the phone number looks real, aka isn't 555-, etc. but that is going to only get
you limited distance, same with the e-mail address, they can be just about anything,
you could do a name lookup but then you run the bigger risk of DoS yourself.
Obviously you could check IPs, but as the OP said it was spoofed so that didn't help.
The best method is not to leave open e-mail forms online for anyone to use, so make
them password protected, etc. The other ironic part was that it was mail that brought
the box down, if the form must be open and DoS attacks are possible I would use local
delivery or even local storage with delayed delivery to help the process. This allows
the web server to respond faster while allowing the mail to be queued for sending at
the mail servers leisure. That is not to say that the web server won't crash because
it is overloaded...
Presumably you could do something at the request level using mod_perl to track the
number of requests made from the same IP over a given period of time and throttle the
responses so that only a certain number of requests can be handled in a short time,
but then you run the risk of preventing image loading, etc. on heavy imaged pages,
etc. The threshold would have to be set fairly high. This also would have impact on a
normally high traffic site visited by lots of people from behind the same proxy, for
example aol.com. Though it might work to do it for specific URLs.
You could probably help stop form submission attacks by using a randomly generated
unique session id in the form and store it server side, then expire it. This would
force the DoS attacker to actually "go through" the form submission process, they
would have to request the form, parse it, and load the fields dynamically rather than
just submitting the same request over and over, but this doesn't help much in the case
of someone committed. It could also make slow typing users mad or those that get up
and grab a bite to eat half way through your form.
Preventing a DoS from someone who is determined is nearly impossible, you have to have
either a bigger pipe and/or a bigger box, short of shutting of all ports to the
machine, but then it wouldn't make a very useful server would it? Theoretically you
could get lower level and do packet throttling or some such, but then we are getting
more OT than before.
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
