session hacking with drupal 4.6 and php5
robertgarrigos - May 27, 2008 - 16:05
I'm having a problem with an old drupal 4.6.7 running on php5. The site is having some requests from hackers for not found files. This is ending with multiple entries in the sessions table because each of those requests is having a new session id assigned. There is not an update of their session id. So they are overloading the server and the ddbb.
I'm requesting the same not found file and my anonymous session id is being updated while theirs is not. Why? Is there anything we could do about it?
>requests from hackers for
>requests from hackers for not found files
It is normal for bots to be doing this.
>each of those requests is having a new session id assigned
Probably the bots are not handling cookies, so as far as Drupal is concerned they are all new sessions.
And while you are at it, if you are worried about the security of your site I suggest you update at least to 4.6.11, but preferably to 4.7.11 or 5.x.. See http://drupal.org/node/3060/release.
gpk
----
www.alexoria.co.uk
I wasn't aware of the 4.6.11
I wasn't aware of the 4.6.11 release. Thanks. Of course I would upgrade.... if the clients pays for it ;-)
I imagined that they were bots using no cookies. My concerns were because I never found myself, nor any of my clients, in this situation and I was scared that this was due to a security issue with an unsported version. I'll see if this is fixed with 4.6.11 and, obviously, recommend the client to upgrade.
Again, many thanks.
---
Robert Garrigos
Professional site: http://garrigos.cat
Catalan Drupal Users Group: drupal.cat
I see that this is not
I see that this is not specially resolved with the latest 4.6 release. I wonder if server load hacking technique has been specially addressed with 4.7 o newer versions of Drupal, as I've never come across with this problem with any of those versions.
---
Robert Garrigos
Professional site: http://garrigos.cat
Catalan Drupal Users Group: drupal.cat
>server load hacking
>server load hacking technique
There's no particular Drupal "hole" in this regard that I am aware of - as you know any site can be brought to its knees by a denial of service attack, obviously this is easier if the server has to PHP process each request rather than just serve a static file.
However in 5.x Drupal was enhanced to reduce the page processing time for a 404 (by not outputting the sidebars). You might need to go for the the dev version to get full benefit since there was still some unnecessary processing going on (tho' without checking the code I'm not sure if this was the case for a 404 http://drupal.org/cvs?commit=111168).
Having said that if the same URLs keep getting hit then cacheing would be the best way forward, and if you are using it already then there's probably not much more can be done from the Drupal side unless you go for more advanced cacheing options. Might be a matter of configuring Apache to reject the DOS attempts.
Edit: actually, upgrading to 4.7 should help with the {session} table getting "spammed". From http://api.drupal.org/api/function/sess_write/4.7:
In 4.6 every anon page request causes a hit on {sessions} - for existing sessions it is in sess_write(), for new sessions an INSERT occurs in http://api.drupal.org/api/function/sess_read/4.6 while the session is being instantiated.
So the bottom line is that yes, newer major releases of Drupal have additional logic to help cope with the load caused by (spam)bots.
gpk
----
www.alexoria.co.uk
The INSERT is in sess_read
The INSERT is in sess_read in 4.6, actually, yes. This is the code:
if (!db_num_rows($result)) {db_query("INSERT INTO {sessions} (sid, uid, hostname, timestamp) VALUES ('%s', 0, '%s', %d)", $key, $_SERVER["REMOTE_ADDR"], time());
$result = db_query("SELECT u.* FROM {users} u WHERE u.uid = 0");
}
So changing it to this:
if (!db_num_rows($result) && (count($_COOKIE)) {db_query("INSERT INTO {sessions} (sid, uid, hostname, timestamp) VALUES ('%s', 0, '%s', %d)", $key, $_SERVER["REMOTE_ADDR"], time());
$result = db_query("SELECT u.* FROM {users} u WHERE u.uid = 0");
}
would fix this, as I believe, as only users with cookies will have a new session added. Would this have any side effect?
---
Robert Garrigos
Professional site: http://garrigos.cat
Catalan Drupal Users Group: drupal.cat
Well given that looks like a
Well given that looks like a direct crib from 4.7 it should work fine! The (side) effect I would reckon is precisely to only create the entry on the visitor's 2nd page view. You'll have to test it but I can't image there will be a problem.
gpk
----
www.alexoria.co.uk
Thanks for your help
Thanks for your help :-)
---
Robert Garrigos
Professional site: http://garrigos.cat
Catalan Drupal Users Group: drupal.cat