CrackerTracker Professional Updated (v 3.1.0)

[Stoebi]

Sorry,

nach einer Runde Mütze Schlaf, habe ich wieder diese Zeile in der URL Leiste eingefügt, neugierig, wie ich nun mal bin, und es kam schon wieder zu einer Fehlermeldung. Jedenfalls habe ich nicht schlecht gestaunt:
http://localhost/board/admin/index.php? ... 5d26ea143f

Fehlermeldung:
Warning: session_begin(./ctracker/loginprotect.php): failed to open stream: No such file or directory in D:\apachefriends\xampp\htdocs\board\includes\sessions.php on line 87

Mir ist nur noch eine Idee eingefallen, die bis jetzt als Einzige vernünftig zu funktionieren scheint.
Ich habe die Zeile 87 wieder hergestellt like cback und den Ordner ctracker aus dem phpbb_root Ordner in den Ordner includes kopiert ( nicht verschoben ;-) ) und anschliessend den Inhalt des Ordners ctracker im includes Ordner bis auf loginprotect.php gelöscht.

Ich weiss nicht, warum $php_root_path in der Zeile 87 nur manchmal mitspielt. Andere wesentliche Änderungen sind in der sessions.php nicht gemacht worden.

Ist definitiv auch der einstige Fehler, der mir bisher so unter die Augen gekommen ist. ?


Gruß Stöbi

[cback]

Naja sagen wir mal so der loginprotect.php fängt bei Dir es ab, zeigt nur seine Meldung nicht. Die Session ID war hier wohl ungültig. Warum des so is k.A kann ich nicht nachstellen.

[Chrisu]

Hallo,

mit der suche habe ich gerade gemerkt ist nicht so schön [...]

Könnte man den Floodschutz bei der Suche nicht dahingehend (für den Anwender) entschärfen, dass dieser für registrierte und eingeloggte User nicht zum Einsatz kommt?

Gruß,
Christian

[Christian_N]

hab ich mir zur erst auch gedacht ob man das mache könnte nur net getraut zu frage *g* und denk mal das es auch ein grund hat von cback wieso es so ist.

denk mal ein grund könnt auch sein das sich dann die würmer dahnen als eingeloggte User und so gotte spruch dann "hey bin eingeloggt darf die suche benutze ohne floodschutz *höhö*"´weiss aber net ob die so gluck wirklich sind und das wirklich machen können sich soweit zu dahnen, kenn mich da net aus cback kann da eher sagen wie gluck die sind und wieweit die sich dahnen können und alles machen können genau

[cback]

Man kanns shcon machen wenn man einfach nur if ($userdata['username'] == 'Anonymous') als zusätzlichen Scanpunkt eingibt aber man reißt sich damit ein Sicherheitsloch hinein, da ja nicht nur würmer eine solche Attacke starten. Angenommen jemand is sauer auf Euer Board, ein Mensch. Registriert sich, startet ein Floodskript bei eingeloggtem Zustand, schon liegt eure DB Flach. Er müsste sich nur einmal registrieren und könnte sich sogar bei mehreren Plätzen autentifizieren mit einem einigzen Account damit die DB per DDoS lahmlegen.

[Stoebi]

[quote="cback - So 14.Aug, 2005 14:17";p="41650"]Naja sagen wir mal so der loginprotect.php fängt bei Dir es ab, zeigt nur seine Meldung nicht. Die Session ID war hier wohl ungültig. Warum des so is k.A kann ich nicht nachstellen.[/quote]

Ich weiss nicht, was da abgefangen wird. Wenn die Session-ID ungültig ist, und das war ja auch b eabsichtigt, gelange ich entweder zur Login- oder Forumübersicht. Meinst du diese Aktion?


Gruß Stöbi

[Chrisu]

Hallo,

Angenommen jemand is sauer auf Euer Board, ein Mensch. Registriert sich, startet ein Floodskript bei eingeloggtem Zustand, schon liegt eure DB Flach.

Hmm, schön und gut, aber würde ein Mensch nicht beinahe immer irgendwelche Mittel und Wege finden ein Board derart zu attakieren? Wenn die Suchfunktion geschützt ist, dann zielt er mit dem Floodskript halt einfach auf andere Datenbankabfragen ab.

Vielleicht könnte man es so einrichten, dass jeder eingeloggte Benutzer pro Tag eine bestimmte Anzahl an Suchaufrufen (ohne Floodschutz) frei hat, erst danach greift der Floodschutz (falls z. B. wirklich mutwillige Absichten dahinterstecken).

Gruß,
Christian

[cback]

Hmm, schön und gut, aber würde ein Mensch nicht beinahe immer irgendwelche Mittel und Wege finden ein Board derart zu attakieren?

Nich direkt. Die Suche ist die härteste Datenbankabfrage alle anderen sind im vergleich mager und machen nichts. Und gegen andere Attacken über Exploits oder Session fakes schützt CTracker ja auch.

[Bootenks]

@CBack: Mir ist aufgefallen, dass seitdem ich das Update auf die 3.1.0 bzw. 3.1.1 gemacht habe, keine Angriffe mehr verzeichnet werden. Ich meine ich könnte mich ja freuen, aber vor dem Update gabe es trotzdem täglich regelmäßig 5-10 Angriffe ;_; und nun nichts mehr? Zufall? Hier im Board bei oxpus hat sich die Anzahl von 1602 auch nicht geändert... Ich frag ja nur ;-)

[cback]

Kannst ja mal testen, allerdings werden suchteiler und so nicht mehr gecountet.

[AmigaLink]

Hier bei oxpus waren es vor 2 tagen noch 1600. Von daher sollte es eigentlich Funktionieren.

Aus sicht eines einfachen Besuchers, muss ich aber sagen das die 30 Sekündige Flood sperre, in der suche, ganz schön hinderlich ist.
Beim einsatz des UPI2DB kann man dadurch, nach aufruf der ungelesenen Beiträge, noch nichteinmal einzelne Beiträge als gelesen markieren ohne gleich den Flood hinweis zu erhalten.
Ich denke mal die Wartezeit sollte zumindest auf 15 Sekunden runtergesetzt werden.

[blondi]

Ich denke mal die Wartezeit sollte zumindest auf 15 Sekunden runtergesetzt werden.

habe ich bei mir auch auf 15 gesetzt ;-))

[Stoebi]

Guten Morgen,

betrifft Lesezeichen. Mein Board: phpBB2 Plus 1.52

Für verschiedene Beiträge habe ich Lesezeichen gesetzt.

Klicke ich auf den Link Lesenzeichen, werden mir alle gesetzten Lesezeichen angezeigt. Soweit so gut ;-)

Das eigentliche Problem ist, ich muss 30 Sekunden warten, bis markierte Lesezeichen gelöscht werden können. Klicke ich früher auf Löschen, wird der Zähler immer wieder zurück gesetzt. Erst wenn die 30 Sekunden nach dem Aufruf des Menüpünktes Lesezeichen abgelaufen sind, werden auch die markierten Lesezeichen nach dem Klick auf Löschen entfernt.

Und irgendwie können 30 Sekunden verdammt lange sein. Vorallen rechnet man nicht damit, dass man bei der Auswahl und anschliessenden Klick nun plötzlich eine Wartezeit Meldung kommt.


Kann man da nicht was machen?


Gruß Stöbi

[cback]

Der Mod ist so konzepiert das die aktuelle Technik gegen Wurmfloods effektiv vorgehen kann, leider ist jede änderung an dieser Struktur ein Eingriff in die Sicherheit. Natürlich kannst Du die Zeit noch auf 15 Sekunden runtersetzen, da offensichtlich Zusatzmods wie Upi2DB und dieses Lesezeichen System viele Funktionen der Suche nutzen wies scheint, doch wenn Du das System ganz irgendwo rauslässt, dann reißt Du Dir exakt an dieser stelle ein großes Loch für würmer rein.

Beispiel:
Ein Cracker versucht Dein Board zu attackieren, merkt den Timeout bei der Suche. Als nächstes entdeckt er, dass das Lesezeichen-System diesen Schutz nicht hat. Er ändert die Ziel URL im Wurmskript und schon kann er seinen Angriff machen ohne das CTracker ihn davon abhalten wird.

Oder Beispiel 2: Man setzt $userdata['username'] == "Anonymous" noch mit in den Blockstring im suchskript rein. Dies hätte für eingeloggte zur Folge, dass man immer ohne Timeout suchen kann und nur bei Gästen der Timeout vorhanden ist. Der Nachteil hier: Der Cracker schaut ob es im eingeloggten Zustand auch ohne diese Sperre geht, hat erfolg, macht sich einen einzigen Account der sich von mehreren Plätzen gleichzeitig autentifizieren kann und schon kann er wieder einen erfolgreichen Angriff starten ohne das ihn das Schutzsystem hindert.


Leider sind Schutzsysteme immer mit einer kleinen Einschränkung der Usability verbunden. Bei Firewall und Virenscannerprogrammen wird die CPU dauerhaft belastet, bei CTracker muss man beim Search Flood Protection hin und wieder mit einer Wartezeit leben.

[Twins]

[quote="cback - Mi 17.Aug, 2005 19:15";p="41902"] bei CTracker muss man beim Search Flood Protection hin und wieder mit einer Wartezeit leben. [/quote]
Das kann ich echt nicht verstehen...Viele regen sich über die Wartezeit auf, aber das ist doch zur gunsten der Sicherheit.Und wenn sie die Sicherheit ni9ch wollen, dann sollen sie nachher auch nicht meckern.Und ich finde, jeder halbwegs verantwortungsbewusste Admin sollte die Suche nicht unter 15 Sekunden setzen.Ich habe damit keine Probkeme, obwohl ich das Timeout sogar auf 40 Sekunden angehoben habe.Und bei den alten Flood-Schutz haben sich auch wieder einige aufgeregt, das ihr PHP-Interpreter das nicht umsetzen kann und die dann auf den Schutz vernichten müssen.Da kann weder cback, noch der CrackerTracker was für.Also Sicherheit muss sein, oder man brauch sich nachher nicht zu beschweren, aber wie einige das hier machen... *kopfschüttel*
Aber ich sage es nochmal: Ich bin mit cback, den CrackerTracker und Orion VOLLKOMMEN zufrieden!!!
EDIT
Sorry, aber ich möchte keinen anschwärtzen oder beschuldigen...Aber meiner Meinung nach muss das mal gesagt werden...Ist aber gegen keinen ein persönlicher Angriff, ich meine das "sachlich"...

[cback]

das ihr PHP-Interpreter das nicht umsetzen kann und die dann auf den Schutz vernichten müssen.

ein System welches ich auch nicht weiterführen konnte. Zwar war es in Bezug auf die usability beim Forenbetrieb gut, das war ein Pluspunkt, doch leider gabs 3 nachteile:

- Die ersten Würmer (bzw. nein ich denke es waren lebendige Personen, da ich einen solchen Wurm noch nicht gefunden habe) haben im Quellcode die FID ausgelesen, da dies ein Hidden Field ist und daher auch Sichtbar. So konnte der Schutz also theoretisch umgangen werden.

- Bei externen Suchboxen war das Problem, dass die Leute auch nicht mehr suchen durften und aufwendige Anpassungen am Forum durchführen wollten.

- Funktionen wie z.B ein selbst programmiertes Suchfeld oben im Firefox als AddOn (wie die Google oder Wikipedia Suche im Firefox, das kann man z.B auch für sein Forum machen) kann nicht mehr genutzt werden. Oder Desktop search und solche Dinge.




Der neue Schutz hat einen einzigen Nachteil, aber auch nur mit vielen Mods die die Suchfunktionalität nutzen. Bei Standard Boards oder einer Mod Kombi wie Orion fällt das z.B nicht so auf, denn auf einer Such-Ergebnisseite ist man normalerweise länger als 30 Sekunden unterwegs v.a. wenn man noch sich Themen ansieht.

Die Vorteile sind natürlich:

- Zeit ist unumgänglich, kein Wurm wird je in die Zukunft reisen können um ne DoS Attack zu starten.

- Jedes Suchfeld ist automatisch geschützt ohne angepasst zu werden

- Die Kompatibilität ist höher

- Das Engine braucht nur einen bruchteil der Resourcen der alten variante da nicht noch zusätzliche Dateien eingebunden werden müssen.

[Chrisu]

Hallo,

Oder Beispiel 2: Man setzt $userdata['username'] == "Anonymous" noch mit in den Blockstring im suchskript rein. Dies hätte für eingeloggte zur Folge, dass man immer ohne Timeout suchen kann und nur bei Gästen der Timeout vorhanden ist. Der Nachteil hier: Der Cracker schaut ob es im eingeloggten Zustand auch ohne diese Sperre geht, hat erfolg, macht sich einen einzigen Account der sich von mehreren Plätzen gleichzeitig autentifizieren kann und schon kann er wieder einen erfolgreichen Angriff starten ohne das ihn das Schutzsystem hindert.

Vorschlag: Gäste müssen wie gehabt die 30 Sekunden abwarten, eingeloggte Besucher zunächst (noch) nicht. Es wird aber überwacht wieviele Suchanfragen (in einer bestimmten Zeitspanne) ein eingeloggter/registrierter Benutzer startet. Überschreitet diese Zahl einen eingestellten Wert, wird die 30-Sekunden-Sperre auch für diesen Benutzer (für eine bestimmte Zeit, beispielsweise 24 h) aktiv.

Ich könnte mir vorstellen, dass man das so gut abstimmen könnte, das es für registrierte Benutzer keine sichtbaren Einschränkungen gibt, böswillige User aber im Falle des Falles trotzdem geblockt werden.

Andere Anregung die sich im Skript leicht umsetzen lassen sollte:
Man führt eine automatische Fallunterscheidung ein: Gäste bekommen 30 Sekunden, registrierte Benutzer automatisch 15 Sek.

Gruß,
Christian

[Twins]

@cback: Aha, danke.Hört sich interessant an.
Also wenn dann, würde ich das so machen:
Gäste 30 Sekunden
User 15 Sekunden
...

[cback]

@Chrisu: Das Problem ist, dass bei dem Scannen wer wie oft sucht erstens mal ein zusatzfeld benötigt wird und dann natürlich die Datenbankaktivität zunimmt, das ist dann wiederum ein nachteil. Das andere ist mit einem Else zweig machbar also die aktuelle deklaration als else if machen und davor die gleiche bedingung nur als If wie es jetzt ist nur halt mit noch userdata...... Aber das is eigentlich nicht nötig 15sec reichen auch schon aus.

[AmigaLink]

Oh mann, da hab ich ja was losgetreten.
Ich wollte doch nur anmerken das die 30 Sekunden, hier bei oxpus, verdammt hinderlich sind und 15 Sekunden wohl erheblich weniger ins Gewicht fallen würden! :rolleyes:
An dem eigentlichem Schutzsystem wollte ich garnichts bemängeln!!!

[cback]

Hab (zumindest ich) auch nicht so aufgefasst. Hab auch nur mal näher wollen erklären wie das so funktioniert und warum das mit der ID nun zum Timer geworden is

[volker58]

habe da auch nochmal ne frage bzw. auch vorschlag, kannst du im Auto Update irgendwie mit einbinden wenn es eine mod änderung gibt? also ich mein wenn zb. version 3.1.2 rausgekommen ist

[Stoebi]

Hallo

@cback. Danke für deine verständliche Aussage. Ich hab die Wartezeit auf 15 Sekunden herunter gesetzt.

Warum funktioniert bei Oxpus lighter, also Suchbegriffe werden hier farblich hervorgehoben, und bei mir nur highlight? Das verstehe ich nicht wirklich.

Hatte ja vorher auch lighter in search.php und viewtopic.php. Aber erst, als ich lighter in highlight ersetzen liess, wurden bei mir die Suchbegriffe wieder farblich hervorgehoben???

Gruß Stöbi

[Chrisu]

Hallo,

@Chrisu: Das Problem ist, dass bei dem Scannen wer wie oft sucht erstens mal ein zusatzfeld benötigt wird und dann natürlich die Datenbankaktivität zunimmt, das ist dann wiederum ein nachteil.

Hmm, ok. Andere Anregung: Anstatt für jeden einzelnen Benutzer die Suchabfragen zu zählen, werden nur noch insgesamt alle Suchabfragen mitgezählt. (Das könnte man ja auch komplett ohne Datenbank mittels einer kleinen Zählerstand-Datei realisieren.) Erreicht dieser Counter einen vorgegebenen Wert, wird die Suchfunktion wie gehabt für jeweils 30 Sekunden blockiert. Einmal täglich wird der Zählerstand wieder auf Null zurückgesetzt.

cback, kann man ungefähr sagen, ab wievielen Suchabfragen (je Zeiteinheit) die Datenbank schlapp macht? Lassen sich da ungefähre Erfahrungswerte angeben? (Entsprechend müßte man den Counter dann justieren.)

Gruß,
Chris

[cback]

@Volker: Nö damit halte ich mir bei mir die Premium User warm, die kriegen Mailbenachrichtigung über neue Mods, muss ja auch irgendwie die Serverkosten decken können und Traffic

@Stoebi:
Bei der alten Version hab ich highlight durch lighter ersetzt, das ist nun aber wieder anders um zu künftigen phpBB Updates die bedienbarkeit zu erleichtern. Das das ersetzen der Variable erforderlich war hatte ich oben ja schon mal angesprochen war nur in einer alten Updateanleitung untergegangen.

@Chrisu:
Nö es kommen schnell viele Suchanfragen, das als allgemeinlösung zu machen würde schnell dazu führen, dass das Board überhaupt keine Suchanfragen mehr zulässt. Ist also auch nicht das Ding. VBulletin hat ebenfalls für die Suche ein Zeitsystem eingebunden um gegen Flood Würmer zu schützen, das System wies nun in CTracker läuft, da sind sich die Sicherheitsexperten momentan einig, is das non plus ultra. Sparsames Engine und dennoch absolut ausreichender Schutz. Die Anzahl der Abfragen pro sekunde bis zum erliegen des DB Servers kommt natürlich auf den Server selbst an, eine allgemeine Richtlinie kann man da nicht setzen. Ein 4-Core XEON Server für die Datenbank mit 16GB RAM wird hier auch eine Flood Attacke ohne schutz locker wegstecken ohne das man was davon merkt.