Wie per Mail schon gesagt möchte hier noch anmerken dass diese Query nicht aus CyStats kommt:
UPDATE wp_vh_TABLE_STATISTICS_RAW SET cid='' WHERE stamp<1219139982
SELECT * , IF (DATE_ADD(link_updated, INTERVAL 120 MINUTE) >= NOW(),
1,0) as recently_updated , UNIX_TIMESTAMP(link_updated) AS
link_updated_f FROM wp_vh_links INNER JOIN wp_vh_term_relationships AS
tr ON (wp_vh_links.link_id = tr.object_id) INNER JOIN
wp_vh_term_taxonomy as tt ON tt.term_taxonomy_id = tr.term_taxonomy_id
WHERE 1=1 AND link_visible = 'Y' AND ( tt.term_id = 3 ) AND taxonomy =
'link_category' ORDER BY link_name ASC
SELECT * , IF (DATE_ADD(link_updated, INTERVAL 120 MINUTE) >= NOW(),
1,0) as recently_updated , UNIX_TIMESTAMP(link_updated) AS
link_updated_f FROM wp_vh_links INNER JOIN wp_vh_term_relationships AS
tr ON (wp_vh_links.link_id = tr.object_id) INNER JOIN
wp_vh_term_taxonomy as tt ON tt.term_taxonomy_id = tr.term_taxonomy_id
WHERE 1=1 AND link_visible = 'Y' AND ( tt.term_id = 8 ) AND taxonomy =
'link_category' ORDER BY link_name ASC
SELECT * , IF (DATE_ADD(link_updated, INTERVAL 120 MINUTE) >= NOW(),
1,0) as recently_updated , UNIX_TIMESTAMP(link_updated) AS
link_updated_f FROM wp_vh_links INNER JOIN wp_vh_term_relationships AS
tr ON (wp_vh_links.link_id = tr.object_id) INNER JOIN
wp_vh_term_taxonomy as tt ON tt.term_taxonomy_id = tr.term_taxonomy_id
WHERE 1=1 AND link_visible = 'Y' AND ( tt.term_id = 9 ) AND taxonomy =
'link_category' ORDER BY link_name ASC
SELECT * , IF (DATE_ADD(link_updated, INTERVAL 120 MINUTE) >= NOW(),
1,0) as recently_updated , UNIX_TIMESTAMP(link_updated) AS
link_updated_f FROM wp_vh_links INNER JOIN wp_vh_term_relationships AS
tr ON (wp_vh_links.link_id = tr.object_id) INNER JOIN
wp_vh_term_taxonomy as tt ON tt.term_taxonomy_id = tr.term_taxonomy_id
WHERE 1=1 AND link_visible = 'Y' AND ( tt.term_id = 5 ) AND taxonomy =
'link_category' ORDER BY link_name ASC
Alles anzeigen
Die Ursache war der Spamangriff (die 23000 Zugriffe erstreckten sich vom Anfang bis zum Ende eines Logfiles, dauerte wahrscheinlich noch länger). Da CyStats als Statistikplugin die Zugriffsdaten natürlich verarbeitet und in die Datenbank speichert entsteht dadurch natürlich eine massive Überbeanspruchung der Datenbank. Hat mich zum Nachdenken gebracht ob man für eine Statistik wirklich Robot-Zugriffe braucht - oder ob nicht nur die Daten identifizierter menschlicher Besucher ausreichen.
Auch zwecks dem Verhindern solcher Angriffe habe ich heute Mittag schon per Mail geantwortet:
Der Angreifer liefert einen leeren Querystring, die IP wechselt manchmal, eine IP wird aber definitiv am meisten genutzt, Server aus der Ukraine.
Query the RIPE Database
Man kann diese IP oder den ganzen IP-Bereich zukünftig mit .htaccess blocken, eventuell könnte man dabei auch überprüfen ob
- der USER_AGENT leer ist
- eine URL mit dem Ende /trackback aufgerufen wurde.
Leider kenne ich mich mit .htaccess nicht unbedingt gut aus, daher nur die Idee und keine Copy&Paste-Lösung.
Bisher ergoogelt (unformatiert, vom ersten Snippet habe ich leider keinen Link mehr):
* # permanently redirect ranged IP request for single page
* RewriteEngine On
* RewriteBase /
* RewriteCond %{REMOTE_HOST} 22\.22\.22
* RewriteCond %{REQUEST_URI} page-with-form-on.php$
* RewriteRule .* http://www.destinationwebsite.com/ [R=301,L]
solariz.de | .htaccess Security Options
# # Block requests without useragent
# RewriteCond %{REQUEST_METHOD} =POST
# RewriteCond %{HTTP_USER_AGENT} ^-?$
# RewriteCond %{REQUEST_URI} !^/(index.php).* [NC]
# RewriteRule .* - [F,NS,L]
http://www.ap4a.co.uk/archives/2007/…h-mod_rewrite/:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} =""
RewriteRule .* - [F,L]
