phpBB.de

naja laut dem forum hat der typ ja den schwanz eingezogen und die daten sind noch garnicht im umlauf...

es kann auch einfach nur subjectiv mehr spam sein
oder zufall

Jan

Jan500 hat geschrieben:es kann auch einfach nur subjectiv mehr spam sein
oder zufall

... oder die Aussage von dem Typen war ein Fake um die Allgemeinheit wieder zu beruhigen und vom verdienten Geld macht er jetzt erstmal 12 Wochen Urlaub auf Mauritzius

miccom hat geschrieben:Mal was anderes: habt ihr heute Spam von verwandschaftstest.net auf eure phpBB.de-E-Mail-Adresse bekommen?

Nicht am 7. aber dafür am 5.
verwandschaftstest-heute.net


Kann mir einer die Zeile erklären?
Was wird das versucht?


Habe es wie weiter oben beschrieben mit mod_rewrite nun abgewehrt. Die Anfragen werden nach hause (127.0.0.1) weiter geleitet. Ist das die beste möglichkeit oder kann man sie noch anders blocken?

S.

Also soviel Spam merk ich da nicht als Unterschied, hab nun 3 Spam Emails bekommen das wars!

An wen kann man sich wenden, um seinen Account loeschen zu lassen? Ich bin inaktiv, von daher+

micky_maus123 hat geschrieben:An wen kann man sich wenden, um seinen Account loeschen zu lassen? Ich bin inaktiv, von daher+

Erklär uns mal, warum du gerade diesen Thread für deine Frage ausgesucht hast? Interessiert mich aus reiner Neugier.

btw:

Antwort 1:
Lösch deine personenbezogenen Daten im Profil und gut ists.

Antwort 2:
Schick dem Team ein PN.

Könnte ja sein das irgendein TaliberoneDreieckshusein im Namen von Micky Mausis Mailadresse dem großen Häuptling in USA einen Liebesbrief schickt....

Tüte Popcorn bitte

ot
Den konnt ich mir nicht verkneifen nachdem ich den Thread durchgeackert habe....

cback hat geschrieben:

Da hilft dann auch kein Backup mehr.

Nein ich meinte auch nicht das die Leute ein Backup machen, sondern das sie dieses Tool aus ihrem Forum entfernen

Schon klar. Meine Bemerkung war auch auf irgendein Backup bezogen, nicht auf eines des Tools

magicwizard hat geschrieben:bei 60.000 passwörtern lohnt sich brute-force und vergleich mit wörterbüchern^^

Brute-Force mit allen denkbaren Zeichen ist ziemlicher Unsinn. Das hat mit der Menge an Passwörtern keinen Zusammenhang, da man die gebruteforcten Hashes auch erstmal speichern muss.

Also macht ein Hacker folgendes. Er lässt eine Schleife laufen und bei jedem neuen Hash schaut er in den bestehenden Datenbank nach Übereinstimmungen. D.h. bei 8+ Stellen inkl. Sonderzeichen braucht er einige Jahre plus viiiieel Speicherplatz, wenn er die Hashes noch speichert.

Und der Einsatz von Wörterbüchern widerspricht meiner Aussage. Passwörter die länger als 8 Stellen sind und Sonderzeichen enthalten, findest Du in keinem Wörterbuch.

Bill B. hat geschrieben:Ich wollte nur wissen, woran man merkt, dass jemand heimlich die DB kopiert hat. ... Wonach sucht man in den Logs? Und gibt es da ein Tool oder kontrolliert Ihr die per Handarbeit? Das ist ganz schon zeitintensiv? Täglich???

Wenn Du Deine Logs studierst ist es schon zu spät. Der Angriff ist erfolgt und demnach zeigt es Dir auch nicht, ob dieser erfolgreich war oder nicht. D.h. die Analyse der Logdateien bringt Null und kostet Zeit.

Besser ist es sich mit der Abwehr zu beschäftigen. D.h. man schaut auf einschlägigen Seiten, versucht die verschiedenen Tools (cback.de, php-ids.org, etc.) zu verstehen und schließt entsprechende Lücken.

Weiterhin sollten gewisse Einstellungen spätestens über die htaccess deaktiviert werden. Siehe:
http://www.phpbb.de/viewtopic.php?p=839257#839257

Typische Angriffsformen sind http:// und UNION SELECT in der URL. Ich bastel gerade eine kleine "Abwehrdatei" für mein phpBB. Ich denke ich werde es in Kürze veröffentlichen, da auch andere Interesse daran hegen könnten. Ich teste nur gerade, ob es auch gegen internal file inclusion ankommt und ob es nicht zu hart ist.

Richtig große Betreiber und die sensible Daten verwalten, haben selbstentwickelte Monitoring-Systeme im Einsatz, die melden, wenn bestimmte IP-Adressen auffällig viele Dateien öffnen (Bot) und welche Parameter sie übergeben. Auch werden häufig vorkommende Fehlermeldungen der Datenbank, die auf Grund einer IP vorkommen ebenfalls analysiert.

Wenn man aber ein Script einsetzt, was bereits eine Lücke enthält, dann reicht nur ein Angriff und dieser lässt sich nicht mehr verhindern oder früh genug erkennen.

Kermit hat geschrieben:Ach ja, und zum Thema SPAM ... Die meisten Hoster bieten einen Account an der solche Filter beinhaltet, wie z.B. bei all-inkl.com. Seit meinem Upgrad vor über einem Jahr kommen vielleicht 2 oder 3 in der Woche durch den Filter rein. (Ja auch diese Woche war es noch nicht mehr!)

Ich muss an dieser Stelle ebenfalls die Filter von all-inkl.com loben. Der Policed-Weight und der Grey-Listing Filter sind die besten, die ich jemals hatte. Als weiteren Tipp kann man noch sagen, dass man niemals *@domain.com-Weiterleitungen bzw. Postfächer nutzen sollte. Die meisten Spammer "raten" nämlich die Emailadressen und deren Tests gehen dann alle durch, was noch mehr Spam zur Folge hat.

@ phpbb.de
Danke für die Erklärung zur Lücke. Dankt magic_quotes_gpc on brauche ich mir über solche Angriffsarten keine Gedanken machen.

@ all
Übrigens empfiehlt php "magic_quotes_gpc off" nur wegen der Performance. D.h. durch aktiviertes Escaping wird minimal Leistung verbraucht (da jede Variable escaped werden muss). Wie sich dieser Performance-Nachteil auswirkt weiß ich nicht. Es gibt keine mir bekannten Benchmarks zu dem Thema. Ich könnte mir aber vorstellen, dass es kaum nachzuvollziehen sein müsste.

Gruß

mgutt hat geschrieben:Und der Einsatz von Wörterbücher widerspricht meiner Aussage. Passwörter die länger als 8 Stellen sind und Sonderzeichen enthalten findest in keinem Wörterbuch.

Wie wäre es denn mit einem chinesischen Zeichensatz

Aber mal Spass beiseite. Was mich immer wieder Wundert, insbesondere bei so großen Projekten wie z.B. phpBB ist, wie viele - für den Webzugriff - nicht benötigte Dateien doch im Webroot liegen.

Solche Dinge wie /includes/* /language/* usw. könnten doch ganz bequem in einem Ordner liegen der per Web nicht erreichbar ist.

Ok, wird bei normalen Webaccounts nicht möglich sein, aber wo es auf einem (V)Server läuft und man den entsprechenden Zugriff hat ...

Das würde doch schonmal eine Vielzahl von möglichen Angriffspunkten ausschließen. Letztendlich würden eigentlich nur die Hauptdateien übrig bleiben die erreichbar sind, alles andere wäre vor dem Zugriff von "aussen" Sicher

Jo das stimmt. Meist wendet man das ja nur auf config-Dateien an, die Passwörter enthalten, aber so ist es natürlich noch besser. Aber ich meine es könnte da zu Konflikten mit open_basedir kommen oder nicht? Weil damit schafft man ja auch eine gewisse Sicherheit, dass man eben nicht aus dem HTML Verzeichnis rauskommt mit seinen Anfragen. Aber das ist jetzt nur eine Vermutung.