Is this a good anti flood script??

[qwikad.com]

I found this script online, but I am not sure if its protection is based on a user's IP address, or is it? Will it stop a user based on how many requests are made from the same IP?

<?PHP
 
IF (!ISSET($_SESSION)) {
    SESSION_START();
}
// anti flood protection
IF($_SESSION['last_session_request'] > TIME() - 2){
    // users will be redirected to this page if it makes requests faster than 2 seconds
    HEADER("location: /flood.html");
    EXIT;
}
$_SESSION['last_session_request'] = TIME();
 
?>

[djr33]

1. That's "faster than 2 milliseconds". (It's almost unimaginable that you could have anyone loading pages that quickly, unless it's a bot with an extremely fast connection.) Use 2000 if you want 2 seconds.

2. Sometimes users do reload that quickly. Maybe you could add in something to allow 1-2 quick reloads per session but no more. (This would be more of the same logic, just storing "$_SESSION['num_flood_requests']" as 0, then adding one to it each time.) And maybe when they've done it 10 or 20 or 100 times you could deny them access from that point forward.

3. Your PHP looks a little strange in all caps. Just for readability (I don't think it's technically necessary for it to work) it should be lowercase for the most part, with the exception of "_SESSION". So "<?php", "if", "time()", "session_start()", "isset()", "exit", "header", etc.

4. This may not actually help very much. This requires PHP to still run a script and respond to a request. It will save your server the effort of processing the whole page (so if it's a very slow page, maybe one with a lot of database requests) it may help some, but it won't entirely fix the problem-- if you get thousands and thousands of requests like this, even though you'll only be serving minimal information back, it could still in theory crash (or just slow down) your server.
The best way to do this would be at the server level, and I'm not sure exactly how that would work. Maybe with .htaccess. But you actually would want to deny the requests rather than just displaying different contact.

To explain a little more clearly, imagine that you are a famous celebrity and the press continuously asks you questions. The best case scenario (for minimal effort) is that you ignore them and do not respond at all. Instead, what your script is doing here is essentially like saying "No thanks!" to every person, every time they ask a question. You can imagine that with enough people asking questions (here, with enough users flooding your site) it would still get tiring and problematic, even if you're only making a short response.

[traq]

Something else to consider is that, in order to work at all, this relies on the attacker accepting your SESSION cookie. It's not at all difficult to circumvent. (It's analogous to using javascript for user authentication - there's just no point in doing it.)

If you really need to deal with flooding (more commonly known as DOS [Denial of Service] attacks), you should look for a solution at the server level (Apache/IIS/whatever you use).

[keyboard]

But what if the user had javascript disabled... wouldn't that stop the session cookie from working?

[djr33]

Javascript has nothing to do with PHP sessions. But if they have cookies disabled, that would probably stop the session from doing that. (Sessions don't necessarily rely on cookies, but just the session ID, which can be sent in other ways such as through a form (post method) or in the URL (get method); but these all DO rely on the user sending the session ID back; if someone specifically wanted to avoid doing that, they certainly could.)

You *could* rewrite it to track IP addresses (using a database) and deny too many requests from any single IP address. (IP addresses are generally unreliable because they change from user to user fairly often for something like a voting script, where the user shouldn't vote again the next day, but they would certainly remain the same during any kind of single session, so in this case they'd work well.)

The only problem with that idea is that sometimes many users are behind a single IP address-- a single family sharing a wireless router, a school, an internet cafe, etc. For that reason you probably can't rely on this method. You could, however, require that no more than 50 requests are made per second from any single IP (or some generally high number like that). But that seems problematic because it really should be dealt with at the server level if you are having that kind of problem (probably a DOS attack like traq mentioned).


By the way, another interesting solution here (that might actually work a lot better) would be to add sleep(2000); to your script. This will delay the page's progress for 2 seconds and I believe that your server will ignore any other requests from that user during that time. So it'll actually delay anything from happening and make it so that they can't request anything more often than 2 seconds, not even the "flood" page. It'll be "silent" as well so it won't bother users but just make their frequent reloads a little bit slower. You'd have to check to see exactly how it changes the load on the server, but I think that might help some, and it makes a little more sense to me than your current setup (which I think would make users reload the page more often when they get frustrated by your flood page).

[qwikad.com]

Ok, let me be more specific.

I need a script that will stop an attack in this way: if let's say 1000 hits came really fast from the same IP address that IP address will be temporarily redirected to an error page.

The emphasis is on this: 1000 hits came really fast (2 or less seconds between each hit) and from the same IP address.

This, for instance, will make it difficult to collect email addresses using email extractors (and it may prevent any other malicious attacks).

Does a script of this kind exist?

I tried to Google it and so far found nothing.

[traq]

Like I said (and Daniel alluded to), there is no such PHP script. Once the request gets to the PHP script, the damage has been done. (In fact, redirecting to an error page would only compound the problem: it's extra work. Instead of 1,000 requests, you're now dealing with 2,000 requests. You should simply "drop" the request with no response.) A sudden flood of requests needs to be handled at the server level, not the PHP level. If you have a decent web host, basic protections should already be set up for you. Talk to your host if you are still having problems.

If this "flood" is not the actual problem you are trying to solve (i.e., if the real issue is that you don't want someone programatically collecting email addresses from you), please let us know, and we may be able to offer an appropriate solution.