Protecting against dDOS bots (was: Newbie php problem)
- From: seeWebInstead@xxxxxxxxxxxxxxxx (Robert Maas, http://tinyurl.com/uh3t)
- Date: Fri, 01 May 2009 04:17:44 -0700
From: Tim Greer <t...@xxxxxxxxxxxxx>
You misunderstood. The form mail script posted that was used,There's no way to prevent a spammer that is manually trying toActually there *is*. You simply require that the sender (spammer or
submit to your form mail script,
anyone else, doesn't matter) get the *permission* of the recipient
before e-mail can be sent,
didn't have any checks to prevent a spammer from submitting to it
via an automated process.
I see two problems with that script. First, it allows the spammer
to e-mail to some recipient who has *not* given permission to that
spammer to send e-mail to that recipient. Thus the spammer can send
e-mail to billions of people as often as he wants and has technical
capability. Second, as you point out now, automated processes are
allowed, without any throttle on the rate, to send e-mail per this
no-permission-needed primary flaw. If you fix the primary flaw,
then allowance for automated sending wouldn't be a problem, because
the only people the spammer could flood with e-mail would be people
who requested the flood of e-mail. If you leave the primary problem
unsolved, but fix the secondary problem, then spamming is still
possible but only at a very low rate that just isn't cost-effective
for spammers.
So who is the idiot that installed that script on their server,
thereby allowing automated no-permission-required spam to be sent
through it?
It really depends on what you're doing and what might be requiredIn addition to that, you would implement a means to have aNo, that discriminates against low-income disabled people who can't
captcha in an image code that must match the requestor's IP and
session.
afford a brand new computers with direct PPP and images hence must
continue to use VT100 dialup through Unix shell and lynx.
and how secure the form is that people submit to, because you could
easily argue that any type of check to prevent abuse is going to
cause someone a problem and quickly end up with a script that lacks
good security measures (this is a maybe).
By "cause someone a problem" do you mean that the person wishing to
send a message is unable to figure out how to pass the check, hence
will be unnecessarily denied access? I see a difference between an
absolute barrier, such as a GIF image or audio output which is
*impossible* to pass through a VT100 dialup, and a test which
requires the applicant to pass some kind of Turing test, whereby
there's no absolute barrier, merely that some people aren't smart
enough to pass the test easily, and might need to think extra hard
to figure out how to pass the test, or might have to ask somebody
for help figuring it out. Please go to any of these:
<tinyurl.com/LinkII> or the similar <tinyurl.com/urlbad>
<tinyurl.com/FilJob>
<tinyurl.com/uh3t> [Contact me]
<tinyurl.com/Portl1> [Temporary link]
and try the various Turing tests and tell me what you think.
It should also be known that when I mention a captcha, that I
don't mean just a jumbled text image, but to have an option for
audio as well
That doesn't do any good here. VT100 doesn't support anything except
US-ASCII text, with some highlighting. No images, no sound.
I'm unsure what you mean about low income users,
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
<http://www.rawbw.com/~rem/NewPub/BadWebSites/DiscrimBad.html>
I'm not aware of any low income users that use Unix shell and
lynx (text) browser,
So you're denying my existance? Or you now retract that because you
are *now* aware of my existance when you weren't before?
You could perhaps have a random key phrase that is posted that
matches their session, which can't be scraped by a bot to
automate it and use that, too (nice and texty).
Please tell more specifics about that. At what point is the phrase
generated, and how is it then introduced into the session, such
that a human could do it but a 'bot couldn't do the same?
By the way, just tonight in a different thread, I saw a great quote
"Pioneers do not wait for the rest areas on the interstate highway
to have sushi bars."
that I'm planning to use in some future missing-text Turing test
for my <tinyurl.com/NewEco>. Why do I feel that's especially
appropriate for NewEco? Because my NewEco will be extremely
bare-bones, formatted for one-inch screen on cell-phones, no
JavaScript or images, except in special applications where you are
supposed to look at images and write intelligent comments about
them or classify them. For info about that class of applications,
see:
<http://shell.rawbw.com/~rem/WAP/projectIdeas.html#Image>
<tinyurl.com/HotNot>
<tinyurl.com/LinkII>
what's to stop someone from making 10,000 requests from one IP in
an hour or 10 minutes time.
IMO it depends on the typical load. Anything suddenly ten times the
typical load should be treated as probably a dDOS flood. My
in-progress NewEco protects itself from requiring either the user
to pass another Turing test before getting more service, or having
some credit remaining on the account and then passing another
Turing test if the account balance ever drops to zero. PHP is
pretty efficient nowadays, about one millisecond of realtime per
running a complete small script, sufficient to check if a Turing
test has been passed and DIE if not. So any flood less than a
thousand PHP-requests per second is no problem for PHP, and
anything larger ought to trigger the sysadmin to take measures at
the TCP/IP stack level to block the flood from continuing to reach
the PHP level, or at the router level to stop the flood from even
reaching the TCP/IP stack.
I said [meant] source code of the page, not the script.... any spammer that actually looked at the source could then useThe PHP source isn't visible to the client/spammer,
that to automate it
OK. If all your secret stuff is in PHP code, not passed to the
client to run in JavaScript, then there's nothing the user can gain
from looking at the HTML source delivered by the PHP script, except
as you note:
Someone could get the fields and automate it without any checks
to stop them from abusing.
Yes, but per my system: If they are using the fields for
no-account-yet (either don't have account, prior to applying for an
account, or haven't yet logged in), then there's hardly anything
that can be done:
- See menu of three things to do (create account, log in, get docs)
- Select any of those options, thereby seeing a create-account
form, or seeing a login form, or seeing a directory of available
documentation.
- Log into the same account repeatedly, which consumes your credit
on that account until your credit reaches zero and you are
challenged with a brand-new Turing test you've never seen before.
- Create thousands of new accounts, each with 5 seconds credit
initially, but then not actually use those accounts for anything
and have them all expunged after a short time.
- Create thousands of new accounts, each with 5 seconds credit
initially, and in each account perform some useful labor for my
"cooperative" system in order to gain additional credit to keep
each such account active longer. (This requires live human, or A.I.)
- Create one account and perform lots of useful labor for my
"cooperative" to gain credit to keep the account active. (This
requires live human, or A.I.)
If you can write an A.I. 'bot which can do useful labor for me just
as well as a real human can, who am I to complain?? For example, if
my system presents your 'bot with some English text and the Chinese
translation as provided by BabelFish, and your 'bot can correct the
Chinese well enough that a native Chinese person can understand it
correctly, then I'd love to have your 'bot working for me in my
NewEco.
If you're added checks since or planned to, then perhaps the
problem is solved. I just thought I'd let you know at the time,
going by what you did post for the code and what you did post for
the HTML, that it was open to have anyone automate a script to
submit thousands of times without limits and (if I recall
correctly) also pass header values to bcc a victim with their spam.
I think you're mixing me up with another poster, because my system
doesn't send any regular e-mail, merely supplies a MAILTO link to
*me* if somebody wants to contact me to inquire about my NewEco and
related proposed technologies. Eventually my system will provide a
totally new kind of e-mail system, with header/command syntax the
same as SMTP, but (1) implemented via HTTP instead of TCP-25, and
(2) never sending to anyone except if they first agree to accept
e-mail from that particular sender, and (3) limit on such e-mail
with refusal to accept any e-mail past that limit, and perhaps (4)
a "pull" instead of "push" system, i.e. sender keeps the body of
the e-mail on his own system, taking space on his own disk, and
only a link to that message is actually sent to the recipient's
database, and for multiple messages the entire catalog of messages
is kept at the sender and only the *count* of messages with URL to
the catalog is sent to recipient's database. Spam will be
impossible with my proposed system.
Agreed, JavaScript as the only way to check against the
submission or to try and implement security is never a good idea.
It's fine for a first level of checks (so the form can talk
directly to the browser (if they have JS enabled) and catch most
people's submission attempts and alert them of problems before it's
actually submitted and processes (wasting resources), but it
shouldn't be relied upon for anything other than trivial checks and
the real checks need to be in the PHP (in this case) script they
submit to.
We're in complete agreement here. I quoted your entire text because
you worded it very well worth showing again.
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
Do you by chance provide any free PHP/MySQL hosting?
If so, I have ideas for supporting it in lieu of the usual pop-up
and banner ads.
.
- Follow-Ups:
- Re: Protecting against dDOS bots
- From: J.O. Aho
- Re: Protecting against dDOS bots
- Next by Date: Re: Protecting against dDOS bots
- Next by thread: Re: Protecting against dDOS bots
- Index(es):
Relevant Pages
|
