Massenhafte node/add Versuche durch anonymen Nutzer

an deiner Domain zu erfreuen, und es intensiv zu versuchen.

Du kannst den IP-Range bestimmen, und per .htacces diese Adressbereiche ausschließen.

Wahrscheinlich sind die russische oder chinesische Adressräume.

Wenn du keine Angebote für diese Länder vorsiehst, kannst du das ganze Land ausschließen.

Evtl. hat es auch etwas damit zu tun http://www.drupalcenter.de/node/52197

Das hat nichts mit der Sicherheitslücke zu tun - solche Versuche gibt es schon seit Ewigkeiten.

Das sind Scripte die automatisch nach Drupalsystemen suchen in denen anonyme User Nodes erstellen dürfen (soetwas gibt es scheinbar) um Spamlinks absetzen zu können. Die rufen daher automatisch node/add auf und das zu prüfen .... ich habe solche Versuche ein bis zweimal pro Minute und das schon seit Jahren.

Ein Aussperren der IPs bringt nicht wirklich etwas da die Spammer/Script-Kiddys hunderte IPs verwenden und immer wieder neue IP-Bereiche dazukommen. Hat man einmal eine Block-Liste angefertigt, geht das am nächsten Tag, mit neuen IPs, wieder los .... das ist ein Kampf gegen Windmühlen ....

Das beste ist -> ignorieren!

aber wenn du China und Russland sperrst, hast du etwa 90% weniger.

Ja, es gibt auch welche mit deutschen und US-Adressen.

Ich habe bei mir mehrmals Adressen aus Venezuela gefunden.

Die Masse kommt jedoch aus China und Russland.

Und wieder mal ist Russland und China dafür verantwortlich... ich kann auch über einem russischen Server Spam aussenden...

Nein, jetzt im ernst! Das Problem hatte ich auch und die beste Lösung ist dieses Modul: "trick-question"
Spammer verstehen kein Wort DEUTSCH. http://www.altertuemliches.at/node/add/brancheneintrag

Beste Grüße

Andreas

Das arbeitet wie Honeypot nur auf anderer Basis und verhindert zuverlässig Spam Einträge, aber das Problem ist ja das trotzdem die Protokollnachrichten mit hunderten node/add Versuchen zugemüllt werden und das nervt einfach, auch wenn die es nicht schaffen sich zu registrieren.

Ich habe dieses Modul noch nicht selbst getestet, meine Spammer sind sehr wenig geworden durch sperren einzelner IPs, hier könnte man ganze IP Kreise sperren soweit man sich die herauspulen will.
https://www.drupal.org/project/ip_ranges

Grüße Jenna

Man kann bei mir sich auch ohne wenn man registriert ist, einen Eintrag ( node/add) durchführen und an dieser Stelle verwende ich es auch!
Wie schon gesagt, seit ich es verwende gibt es keine Spam Einträge mehr! Das Modul ist einfach aufgebaut und sehr wirksam bzw,
ein Kunde von mir hat mich auf die Idee gebracht, dieses Modul zu verwenden, da er es auch beim php2-Forum verwendet.

Siehe ganz unten "Wieviel ist neun + zwei als Zahl ausgeschrieben?: " : http://www.altertuemliches.at/node/add/brancheneintrag

Beste grüße Andreas

Macht es denn dann vielleicht doch Sinn die Drupal 7 Angabe aus dem Seitenquelltext auszubauen? Bzw. wo suchen die, wäre doch vermutlich im Quelltext unter?:

meta name="Generator" content="Drupal 7 (http://drupal.org)"

Grüße Jenna

Ich bin nicht sicher ob wir von dem selben Problem sprechen, das Modul an sich ist Klasse, aber hast du dadurch auch "keine" node/add Versuche mehr unter Protokollnachrichten? Es geht nicht um das Verhindern von Einträgen, sondern überhaupt den Versuch /node/add aufzurufen vorher zu verhindern, sich also vorher schon unsichtbar für die Nervbolde zu machen.

Das würde mich wundern, wäre natürlich toll wenn es so wäre, aber die Bots fragen ja einfach tausendfach domainname.endung/node/add ab, und ich kann mir nicht vorstellen das diese Versuche durch dein Modul aufhören, da ja die Bot-Abfragen völlig unabhängig von deiner Unterseite auf der das Form ist, stattfinden.

Korrigiere mich bitte wenn es anders ist, hast du deine Protokollnachrichten unter Module aktiviert und dort mal nachgesehen? Oder es war einfach noch kein Bot bei dir und deswegen hast du diese /user/login und node/add Crashes gar nicht drin, das kann natürlich auch sein.

Zum Verständnis, ich betreue eine kleine Seite mit offenen Guestbook, Honeypot verhindert zu 100% seit 1.5 Jahren jeglichen Spam Eintrag, trotzdem sehe ich unter Berichte "hunderte" Versuche pro Woche, die weniger werden da ich aus Spaß die IPs gelegentlich händisch sperre.
Aber an den Versuchen kann auch das Modul nichts ändern, es kann nur den Eintrag blocken.

Grüße Jenna

Ich habe generell keine Angaben in den Metas die auf Drupal hinweisen - trotzdem sind die Spammer da.

Das kann man mit dem Modul nicht verhindern!

Wie ich schonmal sagte .... per Hand eine IP-Sperrliste zu pflegen ist wie ein Kampf gegen die Hydra ... schlägt man einen Kopf ab, wachsen zwei nach. Auf Dauer verbraucht an dazu unendlich viel Zeit und es bringt im Endeffekt nicht wirklich was (ich habe China, Indien und Russland komplett gesperrt und trotzdem zwischen ein und zwei Versuche pro Minute).

Ich könnte mir vorstellen, dass es auf irgendwelchen "Hacker-Boards" Hacking-Kits zu kaufen gibt die jeder Donk für 39 Dollar kaufen kann! Nach der Installation auf einem Server/Hoster, fangen die dann mit dem spidern einer riesigen Domainliste an um Sicherheitslücken oder ungesicherte System zu finden. Da hat man dann hunderte oder tausende Scriptkiddys die solche Scripte Tag und Nacht laufen lassen und täglich kommen ein paar neue Kiddys (mit neuen IPs) dazu (die das auch probieren). Zusätzlich hat man dann die "Profis" die scheinbar ganze Serverbänke angemietet haben und dann auch täglich neue IP-Bereiche (die noch in keiner Sperrliste vorhanden sind) dazukaufen.

Man müsste ein Modul schreiben das soetwas automatisch erkennt und dann die IP blockt aber da kommt man dann schnell zum Problem, dass die htaccess überläuft und zu einem Performancekiller wird denn dort sammeln sich schnell hunderte oder gar tausende deny-ip-rules und die bremsen den Server auf jeden Fall aus (las ich zumindest mal). Als ich das mal per Hand machte, war meine htaccess schon nach kurzer Zeit riesig und das war alles nur noch völlig unhantlich. Selbst wenn das nicht über die htaccess macht, sondern über einen anderen Weg, hat man trotzdem eine Sperrliste mit z.B. eintausend Einträgen und diese muss, vor jedem Request, abgearbeitet werden - das killt aber Performance in jedem Fall (meiner Meinung nach).

[quote]Korrigiere mich bitte wenn es anders ist, hast du deine Protokollnachrichten unter Module aktiviert und dort mal nachgesehen? Oder es war einfach noch kein Bot bei dir und deswegen hast du diese /user/login und node/add Crashes gar nicht drin, das kann naürlich auch sein.[/quot]

Kannst du mir bitte sagen unter welchen Menüpunkt ich nachsehen soll bzw. den Menüpunkt Berichte gibt es...

Unter admin/reports/dblog

Dafür muß aber unter Module "Database Logging" aktiviert sein, ab dann werden alle Zugriffe etc. aufgezeichnet.

Grüße Jenna

Danke Ionit, ich hatte in irgendeinem Thread dazu gelesen das es eventuell etwas bringen könnte, aber dann kann man sich die Arbeit ja auch sparen.

Grüße Jenna

Danke, habe es deaktiviert gehabt... ...wegen performance ...habe mal aktiviert

so aktiv... werde später nochmals reinsehen und das ergebniss posten...

nur von irgendwelche spam versuche sehe ich nichts...

Dann freu dich, ich hab auch Installationen die noch nicht von Bots heimgesucht wurden, aber wenn sie dich finden, siehst du die Aufrufe mit pfad in dieser Liste.

Was sind denn das für PHP Errors in deiner Ausgabe die von "Gast" erzeugt werden?
Für so etwas sind die Protokolle eben auch sinnvoll, um Fehler jeder Art auszumerzen.

Grüße Jenna

So habe jetzt auch auf einer anderen Installation nach gesehen, was ca. 100.000 Seiten hat und auch dort verwende ich das Modul und auch da gibt es keine Bots...

So viel ich mich erinnern kann, hatte ich auch mal Problem, dass ich zugemüllt wurde, nur seit ich das Modul verwende ist ruhe damit bzw. bin mir aber nicht mehr 100% sicher!

Ja leider die Website hat sehr viele Fehler, nur um die alle zu beheben fällt mir leider die Zeit...

die solche Scripte produzieren.

Die Masse macht es.

Ich habe in meinen Logs so manchen gefunden, der einfach alle möglichen Kombinationen ausprobiert.

Da sind dann Aufrufe drin, denen man ansieht, dass sie auf Jommla, auf Typo3 oder andere System zielen.
Ein Aufruf aus einer Serie ist dann auch der Drupaltypische node/add oder user/register Aufruf.

Es gibt offenbar sogar ein halbwegs intelligentes Script, das einen user zu registrieren versucht, und den weiteren Zugriff davon abhängig macht, dass der User anmeldbar ist.

Hallo,

das mit dem htmspecial_char und node/add
sind ganz sicher Versuche durch SA-CORE-2014-005 den Server zu infiltrieren.
Oben wurde das schon mal erwähnt
http://www.drupalcenter.de/node/52197

Dieser Angriff ist im Metasploit Framework enthalten und heisst drupal_drupageddon.
Ich habe es selbst ausprobiert und es ist erstaunlich, was dieses Skript (durch SQL Injection) alles macht:
1. es legt einen neuen Benutzer an
2. Aktiviert das PHP Filter Modul
3.Liest die Admin Role id
4.Gibt dem angelegten Benutzer die Admin Rolle
5.Legt einen neuen Artikel an (Dieser enthält eine PHP reverse Shell)
6.Schaut die Page im Preview an (Der Server Verbindet sich mit dem Angreifer)

Da das ganze durch SQL Injections geschieht, hat man auch keine Protokolleinträge.
Man sieht nur Fehler wie htmlspecial_chars und addslashes, welche auf die SQL Injections deuten.

Mancher wird sich fragen, wie kommen die auf mich?
Bei Google intitle:"User account" inurl:"user/login"
Die Drupal Versionen 7.x bis 7.2 sind wohl von diesem Exploit betroffen.
Darunter und darüber funktionert dieser exploit wohl nicht.

MfG

Robert

Sh..., dann habe ich auch auf Probleme mit D6, da bei mir im Log File lauter htmlspecialchars() expects parameter 1 to be .. gibt...

Detail siehe bitte Anhang!

Wie soll ich da am besten vorgehen

Beste Grüße

Andreas

Hallo Andreas,

da Du Drupal 6 hast glaube ich nicht dass dieser Exploit bei Dir funktioniert hat.
Schau mal unter admin/people ob da Benutzer angelegt wurden die Admin Rechte haben.
Wenn nicht, dann sollte es gut sein.

MfG

Robert

Wenn du nach htmlspecialchars() expects parameter 1 bootstrap.inc googelst, gibt es viele Einträge zu dem Thema weit vor der Drupal Attacke und in Bezug auf verschiedene Module / Themes.

Also könnte diese Fehlermeldung sich auch auf eine simple Angelegenheit beziehen, ist aber nur eine Vermutung meinerseits und soll keine trügerische Sicherheit vermitteln.

Vielleicht findest du in den Beiträgen Hinweise auf Module die du auch im Einsatz hast und kannst auf einer Testinstallation die vorhandenen Patches ausprobieren?

Grüße Jenna

Unter admin/reports/dblog gibt es keinen Benutzer bzw. habe mir alle Benutzer mal angesehen und da gibt es keinen der Adminrechte hat ausser ich...

Deshalb wirst du recht haben, dass D6 nicht betroffen ist! Werde mal wenn es mir die Zeit zulässt, denn Fehler etwas intensiver ansehen!

Nur für mich bleibt noch immer die Frage offen: sind die Probleme mit dem node/add lösbar mit dem Trick Modul?
Oder bin ich für die Spanner nicht relevant!

Beste Grüße

Andi

Hallo Andi,

ich denke, das Dir das Trick Modul die node/add Einträge sparen kann.
Und zwar speziell bei Dir, da D6 für diesen Exploit (SQL Injekt) nicht anfällig
ist.
Bei D7 würde Dir das nichts nützen, da der Benutzer (admin) schon angelegt wurde,
bevor der node erstellt wird.
Der Angreifer könnte sich einfach anmelden und den benötigten node (Backdoor) per Hand erstellen.

@Jenna
Die htmlspecialchars() Einträge sind versuchte SQL Injections.
Sehr stark hat sich das verbreitet, mit dem drupageddon skript und die Server werden
gesannt und im Minutentakt von irgendwelchen Leuten attackiert.
Es ist erstaunlich wievele Angriffe durch dieses Skript ich zu verzeichnen habe,
obwohl die Seite erstmal 1 Woche online ist.

LG

Robert

Hallo Robert,
ich verwende das Trick Modul auch bei der Registrierung!
http://www.altertuemliches.at/user/register

Vielleicht wäre das die Lösung auch bei D7?

Beste grüße Andi

Hallo Andi,

nein bloss nicht !
Das Trick Modul nützt Dir nichts wenn Du Drupal 7.x< 7.31 hast.
Danach wurde das SQL Injection Problem gelöst.
Bei einer solchen Injection nutzten Dir solche Module wie Captcha,Honeypot,Trick,Flood nichts.
Da der Angriff direkt über SQL auf die Datenbank geht, greifen keine Drupal Hooks.
Du hast einfach Glück, das Deine Webseite für diesen neuen Exploit zu alt ist ;-)

MfG

Robert

...danke Hyp1

@artweb, dann bitte meine Hinweise nicht beachten, Hyp1 hat da wesentlich mehr getestet als ich, hatte nur die Hoffnung auf eine schnelle einfache Lösung.

Grüße Jenna

Für Seiten, die keine Registrierung erlauben hilft eventuell der Eintrag in der .htaccess um die Zugriffe zu stoppen. Damit wären zumindest die Datenbankzugriffe, Sessioneinträge und die aus den Drupal Logfiles raus:

RewriteEngine On
RewriteCond %{QUERY_STRING}
^q=(node/add|user/register|node/add/|user/register/)$
RewriteRule ^ - [F,L]

Zumindest für node/add solltest Du aber Deine eigene IP zulassen (bei einer dynamischen wird's schwierig). Sonst hast Du selbst beim (normalen, manuellen) Hinzufügen neuer Inhalte ein Problem.

Danke für den Hinweis. Aber das geht wunderbar .../node/add/page lässt sich aufrufen. Mit dem Modul "Admin" habe ich meinen Benutzern ein eigenes Adminmenü zum Hinzufügen von Inhalten gebaut.

Was mir eher Sorgen bereitet sind massig Zugriffe auf die Website.
Normalerweise hat sie nur 50 bis maximal 500 Zugriffe im Monat.

Bei Analyse der Statistiken und Ursachensuche warum die Sessions-Tabelle in der Datenbank auf 6 GB angewachsen war stellte ich einen extremen Zuwachs an Zugriffen auf die Seite fest. Hier ein paar Screenshots der Statistiken. Kennt das jemand und hat eine Idee woran das liegt? Im Bezug auf die Suche hatte ich Search, Search 404 und Custom Search im Einsatz. CMS ist Drupal 6

Hi tintin,

ich spekuliere nur, aber Du hast Recht diese Anzahl an Anfragen in
"Monats-Statistik-allgemein.jpg" nur für Monat April
mit Ergebniss 200 OK ca. 54'000'000
ist sehr verdächtig.
Auch "Laender.jpg" sollte verdächtig vorkommen, wenn es eine DE Seite ist (Platz 12).
"URLS-nach-KB.jpg" ist noch verdächtiger.

Würde sagen, dass der Server im besten Fall Opfer einer DOS/DDOS Attacke ist,
oder noch schlechter, der Server wurde bereits gehackt und wird nun weltweit genutzt.

MfG

Robert

Wie kann ich ausschließen dass der Server gehackt ist?
Wie gehe ich vor um das zu prüfen?

Ganz sicher gehe ich wahrscheinlich nur, wenn ich alles neu mache, richtig?
Wäre dies das empfohlene Vorgehen:
- Zugänge ändern Hosting, FTP, Datenbank und Drupal?
- Drupal neu installieren
- Module neu installieren
- Inhalte Rücksichern
- Theme Rücksichern
- ...

Viele Grüße und Dank.

Hmm ich habe mir deine Seite nur mal kurz angesehen bzw. du hast massenweise Backlinks!
Da wird man richtig Neidisch :-)

Sieh mal hier http://openlinkprofiler.org/

Ob deine Seite gehackt worden ist stelle ich in Frage!

Beste Grüße Andreas

Was bezwecken die mit einem Link in der Form:

http://www.meinewebsite/search/node/http%3A/%252Fihrewebsite.com/%3Fdocu...

Beziehungweise ist das eine Lücke in einer der Module die man schließen könnte?

- Search
- Search 404
- Custom Search

???

Das Verstehe ich auch nicht! Was sagt Google Webmaster eigentlich dazu?
https://www.google.com/webmasters/tools/?hl=de

@artweb

Genau das habe ich mir auch gedacht.
Genau diese Zugriffe sehen mir auch nach einer Lücke aus.

MfG

Robert

In der großen Zahl, in der das auch mehrfach pro IP dort drauf ballert, sieht es mir tatsächlich nach einer Lücke aus. Weil so fiese Bots, wenn sie nix finden, meist auch ganz schnell wieder abziehen und sich ein anderes Opfer suchen.

Sagt: alles in Ordnung

Ich habe die Suche deaktiviert, 'Search 404' sowie 'Custom Search' deinstalliert und Zugriff auf den Pfad /search/ per .htaccess komplett blockiert. Ich bin gespannt wie sich die nächsten Tage die Zugriffe verändern werden. Noch steigt die Sessions-Tabelle pro Tag von 0 auf 200 MB und weiter, wenn ich sie nicht leere.

Habe mal das Modul Search 404 bei mir Installiert und es klappt sehr gut! Werde es mal beobachten...

Hast in letzter Zeit sehr viele Spam Einträge gehabt?

Ich habe eine Seite im Netz, mit fast identischer Konfiguration. Diese hat das Problem nicht.
Wobei ich nun auch hier custom search und search 404 vorsorglich deaktiviert habe.

Mangels Kommentierfunktion und deaktivierter Registrierung nicht nein.

Hattest du vorher viele Benutzer Anmeldungen? Bevor du die Registrierung deaktiviert hattest?

Nein, diese ist seit Anfang an abgeschaltet, da der Kunde das so wollte.