Website gegen Angriffe schützen

[tophirsch]

Moin,

also, wie der Titel schon sagt, möchte ich eine Website vor Hackerangriffen schützen.
Da ich es sich um meine erste Website überhaupt handelt, habe ich da keinen blassen Dunst davon. Also haltet euch mit Hinweisen nicht zurück, so selbstverständlich sie euch auch erscheinen.(Ok, die Zugangsdaten sind nicht "admin" und "123456"...)

War schon eine Menge Arbeit, sich in html, php und css einzufuchsen, wenn man vorher noch keinen Kontakt damit hatte. Die Seite läuft mit Drupal, falls es da spezifische Sicherheitsvorkehrungen geben sollte.
Ist auch "nur" ne kleine Seite für eine befreundete Band, also jetzt nichts extrem sicherheits-kritisches. Sonst hätt ich mich ja auch nicht drauf eingelassen, weil ich ja eben prinzipiell keine Ahnung hab.

Benutzer können sich keine registrieren, es gibt nur die Bandmitglieder als Schreiberlinge, die News schreiben, Bilder hochladen oder Termine ansetzen können. Wenn die was kaputt machen, kriegen se paar vorn Sack
Unangemeldete Benutzer können nur Kommentare verfassen und evtl. die Suche benutzen(momentan abgeschaltet, weiß noch nicht, ob ich sie noch aktiviere)

So, das zur Vorgeschichte...


Nun würd ich gerne erfahren, was es eigentlich alles so an bekannten Sicherheitslücken gibt, die man unbedingt beachten sollte. Denn auch wenn es nur ein kleines Projekt ist, so möchte ich doch möglichst "professionelle" Arbeit abliefern und "typische Anfängerfehler" möglichst vermeiden.

Habe mir auch schon die Security-Seiten auf Drupal.org durchgelesen, aber nicht alles nachvollziehen können.

Momentan versuche ich die Rechte an den Dateien korrekt zu vergeben, wie dort im ersten Unterpunkt beschrieben. Ich raff aber nicht, wo die nun ne Kommandozeile herhaben, wo die das ganze einstellen.
Ich benutze FileZilla um die Daten auf den Server zu schieben, dort kann man auch irgendwelche Dateiberechtigungen setzen. Sieht so aus:

Das wird ja wohl was miteinander zu tun haben, aber ich seh da keine Benutzernamen o.ä. Woher weiß ich jetzt, was für den Server ist und was für mich ist.
Ich denke mal, da wird für mich jemand Licht ins dunkel bringen können...scheint keine Hexerei zu sein, ich stell mich nur zu blöd an.


Irgendwo hab ich auch schon gelesen, das man FTP vermeiden sollte. Was soll das bitte heißen? Wie sonst sollte ich meine Dateien auf den Server schieben?


Nochwas zu Backups:
Momentan sichere ich mir die gesamte Verzeichnisstruktur per FTP und die Datenbank mit My SQLDumper. Das herunterladen der vielen Files dauert schon immer seine Zeit, gibts da ne elegantere Lösung? Eigentlich müsste man ja nur die Files herunterladen, die sich geändert haben...

Ich hoffe dass sich ein paar Leute die Zeit nehmen und mir unter die Arme greifen können.
Danke schonmal.

 

[p3Eq]

Wenn du magst, kannst du uns den Link zur Seite schicken (gerne auch per PN) und ich schaue mal, ob ich ein paar Sicherheitslücken finde. So auf Anhieb ist es einfacher, die Fehler zu korrigieren, als dir nun alle möglichen Sicherheitslücken zu erklären, denke ich. Die Dateirechte auf dem FTP sind sicherlich nicht zu vernachlässigen, aber primäres Angriffsziel ist wohl eher die Seite selbst. Meistens lassen sich Schwachstellen in Form von XSS oder SQL-Injection finden.

 

[tophirsch]

Die Seite befindet sich momentan noch im Wartungsmodus, also nur mit Login einsehbar. Habe noch kein Impressum drin und wollte sie deshalb noch nicht öffentlich zugänglich machen. Ich weiß ja nicht, wie schnell so Abmahnanwälte sind. Meint ihr, man kanns riskieren? Dann kann ich die Seite auch mal "live" schalten.

edit:
Mir is grad eingefallen, das ich den Wartungsmodus ja garnicht abschalten brauch...
Wer noch Zeit und Lust hat kann sich per PN melden, dann könnte ich einen Benutzeraccount erstellen, der es erlaubt die Seite im Wartungsmodus zu benutzen.

 

[DerLadendieb]

Über Google findet man diesbezüglich recht viele Tutorials. Ich nenne dir mal die wohl am häufigsten ausgenutzten Sicherheitslücken: sqli, xss, lfi, rfi usw.

Du kannst dir auch ein Tool wie Acunetix herunterladen und deine Website scannen um Lücken aufzudecken.

 

[aNtiCHrist]

Unangemeldete Benutzer können nur Kommentare verfassen

Dann solltest du davon ausgehen, dass Spam dein Hauptproblem sein wird.

Nun würd ich gerne erfahren, was es eigentlich alles so an bekannten Sicherheitslücken gibt, die man unbedingt beachten sollte.

Wenn du fertige Software nutzt (die nicht gerade als chronisch unsicher bekannt ist), werden die Schwachstellen am ehesten in einer ungeeigneten Konfiguration zu finden sein. Dazu findet man bei den Anbietern oft entsprechende Empfehlungen, darauf bist du aber offenbar selbst schon gestoßen. Ansonsten ist es sinnvoll, permanent über aktuelle Versionen der verwendeten Software informiert zu sein, sodass man nicht unnötig lang veraltete Versionen mit bekannten Schwachstellen verwendet. Teilweise bieten die Anbieter dazu Security-Mailinglisten an, in denen idealerweise auch vor Schwachstellen in Fremdmodulen gewarnt wird.

Ich raff aber nicht, wo die nun ne Kommandozeile herhaben, wo die das ganze einstellen.

Dort wird offenbar davon ausgegangen, dass du einen Shell-Zugang zu dem System hast. Entweder weil man direkt physischen Zugang dazu hat, oder aber halt per SSH. Wenn du nur ein preiswertes Webhosting-Paket hast, ist meist kein SSH-Zugang verfügbar.

Das wird ja wohl was miteinander zu tun haben, aber ich seh da keine Benutzernamen o.ä.

Sehen solltest du sie eigentlich schon können, aber Änderungen sind AFAIK über FTP nicht vorgesehen.

Irgendwo hab ich auch schon gelesen, das man FTP vermeiden sollte. Was soll das bitte heißen?

FTP ist ein ziemlich antikes Protokoll, das zwei TCP-Verbindungen nutzt. Bei der Nutzung von NAT oder hinter Firewalls wird es dadurch recht kompliziert. Hinzu kommt, dass FTP die Authentifizierungsdaten und die Inhalte im Klartext überträgt. Das stellt ein unnötiges Sicherheitsrisiko dar. Abhilfe für der Klartext-Problem schafft FTPS (nach RFC 4217), was FileZilla ebenalls unterstützt. Allerdings muss es auch der Server unterstützen. Die bessere Alternative ist SFTP (SSH File Transfer Protocol), was nur eine Verbindung vom Client zu einem festen Port des Servers benötigt, ebenfalls von FileZilla unterstützt wird, aber wiederum auch die Unterstützung auf der Serverseite benötigt. Bei einem Webhoster, der weder das eine, noch das andere anbietet, sollte man besser den Anbieter wechseln.

 

[tophirsch]

Dann solltest du davon ausgehen, dass Spam dein Hauptproblem sein wird.

Um den Kommentar abzuschicken, ist ein Captcha nötig, ich hoffe mal, dass automatischer Spam damit Einhalt geboten wird. Wenn "menschlicher" Spam überhand nimmt, dann muss eben eine vorherige Freigabe von Moderatoren vorgesehen werden.

Dort wird offenbar davon ausgegangen, dass du einen Shell-Zugang zu dem System hast. Entweder weil man direkt physischen Zugang dazu hat, oder aber halt per SSH. Wenn du nur ein preiswertes Webhosting-Paket hast, ist meist kein SSH-Zugang verfügbar.

Da die Band keine Kohlen dafür hat, handelt es sich um einen Freehoster. Da wird das wohl unmöglich sein.

Sehen solltest du sie eigentlich schon können, aber Änderungen sind AFAIK über FTP nicht vorgesehen.

Ändern kann ich das schon, aber ich sehe wie auf dem Bild eben nur die 3 Kategorien Besitzer, Gruppe und öffentlich. Habe da ein bissel Schiss, was falsches einzustellen. Nachher komm ich dann selbst nicht mehr an die Daten ran. Habe wie gesagt davon keine Ahnung, sieht nach Linux aus. Ich nutze Windoof, obwohl ich mir schon seit geraumer Zeit mal einen Umstieg auf Linux vorgenommen hab...

FTP ist ein ziemlich antikes Protokoll, das zwei TCP-Verbindungen nutzt. Bei der Nutzung von NAT oder hinter Firewalls wird es dadurch recht kompliziert. Hinzu kommt, dass FTP die Authentifizierungsdaten und die Inhalte im Klartext überträgt. Das stellt ein unnötiges Sicherheitsrisiko dar. Abhilfe für der Klartext-Problem schafft FTPS (nach RFC 4217), was FileZilla ebenalls unterstützt.

SFTP wird leider nicht unterstützt. Habe jetzt in FileZilla "Explizites FTP über TLS" eingestellt, danke für den Hinweis!


---------------------------------------------
So ich habe auch versucht in der Zwischenzeit mal ein paar "Hausaufgaben" zu machen und nicht nur faul auf Antworten gewartet

Ich nenne dir mal die wohl am häufigsten ausgenutzten Sicherheitslücken: sqli, xss, lfi, rfi usw.

XSS:
Da habe ich mich erstmal ein wenig in die Materie eingelesen und auch ein paar Möglichkeiten von hier ausprobiert - zum Glück ohne Erfolg. Drupal bietet standardmäßig ein Filter-Modul und ich habe nur die Tags <em> <strong> <blockquote> <del> erlaubt. Nun kommt es natürlich noch darauf an, wie gut der Filter funktioniert. Ich könnte mich darauf verlassen, das die Entwickler gute Arbeit geleistet haben, womit ich sicherlich auch gut beraten wäre, aber ich möchte ja auch was lernen.
Habe mich also mit meinen selbst erworbenen, rudimentären PHP Kenntnissen mal auf die Suche gemacht und erstmal herausgefunden, das vom Kommentar-Modul beim Absenden in der Funktion comment_submit die Funktion check_markup bzw. check_plain aufgerufen wird um schädlichen code zu entfernen. Zumindest denke ich mir das so.

Aber das erfolgt innerhalb
[src=php]if (trim($comment->subject) == '') {[/src]
Also eigentlich bedeutet das doch, nur wenn subject(also die Betreffszeile) leer ist, wird gefiltert?

Um die Funktion check_markup zu analysieren, reichen meine Kenntnisse dann schon nicht mehr...


Das hier konnte ich auch nicht wirklich nachvollziehen...Is nun ein MITM erforderlich dafür oder nicht?


LFI/RFI:
Dazu hab ich hier mal nachgelesen und auch ein bissel rumprobiert. All meine Versuche führten zu einem "Not Found", was wohl so richtig ist. Leider habe ich hier erstmal keine Ahnung, wo ich den Code suchen soll, wo die Parameter aus den URLs verarbeitet werden. Bin dazu erstmal hierauf gestoßen, aber konnte mich noch nicht durch die Funktionen kämpfen...
Auch diesen Exploit kann ich erstmal nicht nachvollziehen.

You must go to the profile folder and create a file with .profile extension.[...]

Dafür müsste man doch erstmal Dateien erstellen dürfen? Oder hab ich da was falsch verstanden? Wird hier vielleicht von entsprechen unsicheren Dateiberechtigungen ausgegangen?

SQL Injection:
Hab ich mich noch nicht damit beschäftigt...



Nochmal ein Danke an die bisherigen Hinweisgeber!

 

[aNtiCHrist]

Ändern kann ich das schon, aber ich sehe wie auf dem Bild eben nur die 3 Kategorien Besitzer, Gruppe und öffentlich.

Du verwechselst die Möglichkeit zum Einstellen der Rechte (chmod) mit der zum Einstellen des Besitzers (chown). Nur ersteres geht nach meinen Kenntnissen über FTP.

Habe da ein bissel Schiss, was falsches einzustellen. Nachher komm ich dann selbst nicht mehr an die Daten ran.

Solange du (bzw. das Konto, unter dem der FTP-Server läuft) der Besitzer (b)ist, sollte es da kein Problem geben. Ggf. ist bei zu restriktiven Rechten die Datei nicht mehr von dem Webserver lesbar.

Habe wie gesagt davon keine Ahnung, sieht nach Linux aus.

Dieses Rechte-/Besitzmodell gibt es in der ganzen Unix-Welt, das ist nicht auf Linux beschränkt, auch wenn es heutzutage oftmals darauf hinausläuft.

So ich habe auch versucht in der Zwischenzeit mal ein paar "Hausaufgaben" zu machen und nicht nur faul auf Antworten gewartet

Grundlagenwissen ist sicherlich gut, aber bei einer fertigen Webanwendung, für die du nicht selbst Code schreibst, nicht sonderlich hilfreich, um dich dort gegen Angriffe abzusichern. Es sei denn du traust es dir zu, den Code der Webanwendung und ihrer Module gewissenhaft zu sichten. Konzetriere dich lieber darauf, die Webanwendung entsprechend den Empfehlungen zu konfigurieren und aktuell zu halten. Vorsicht ist bei Modulen von Dritten angebracht, diese haben oftmals eine deutlich geringere Qualität und sind damit anfälliger.

ch könnte mich darauf verlassen, das die Entwickler gute Arbeit geleistet haben, womit ich sicherlich auch gut beraten wäre, aber ich möchte ja auch was lernen.

Der Ansatz wird leider bei halbwegs gängiger Software recht frustrierend sein, weil dort schon andere auf die Idee gekommen sind, nach solchen Fehlern zu suchen. Motivierender dürfte http://google-gruyere.appspot.com/ sein.

Aber das erfolgt innerhalb
[src=php]if (trim($comment->subject) == '') {[/src]
Also eigentlich bedeutet das doch, nur wenn subject(also die Betreffszeile) leer ist, wird gefiltert?

Ich kann nicht erkennen, auf welche Code-Stelle du dich damit beziehst. Ich finde in dem Kontext nur eine behelfsweise Zuweisung von "No subject" (bzw. eine lokalisierte Fassung davon) in den Kommentar-Betreff, wenn dieser durch die Filterung leer geworden ist. Warum dort vermeintliche Tags überhaupt entfernt werden und nicht stattdessen die gefährlichen Zeichen korrekt in Zeichenreferenzen gewandelt werden, erschließt sich mir nicht so ganz, dadurch wird immerhin ggf. auch ein Text verfälscht.

Das hier konnte ich auch nicht wirklich nachvollziehen...Is nun ein MITM erforderlich dafür oder nicht?

Das ist eine recht schwer nachvollziehbare Schwachstelle, die sich wohl auch nur dann ausnutzen lässt, wenn diese Drupal-Version mit einem beliebigen Host-Parameter in der HTTP-Anfrage erreichbar ist. In einer Shared-Hosting-Umgebung werden allerdings virtuelle Hosts genutzt, sodass ohne passende Host-Angabe die Anfrage nicht bis zu der Drupal-Installation gelangen wird. Gelangt die Anfrage aber in einer anfälligen Konfiguration dorthin, wird offenbar der Wert aus dem Host-Headerfeld unsinnigerweise zur Generierung von URIs für eingebundene Inhalte herangezogen. So lassen sich dann Inhalte von einer externen Quelle einbinden. Selbst dann handelt es sich aber offenbar nur um reflexives XSS, sodass man es nur für sich selbst nutzen kann, sofern man nicht als Man-in-the-Middle die Anfrage des Opfers so manipulieren kann, dass das Host-Feld auf eine bösartige Quelle zeigt. Wenn man das kann, kann man aber vermutlich auch genau so gut einfach die zurückgelieferte Webseite selbst verändern. Insgesamt ist diese Schwachstelle also wie bereits dort beschrieben ziemlich unspektakulär, auch wenn sie offenbar durchaus vorhanden ist/war.

Die anderen beiden vorgeblichen Schwachstellen kann ich nicht beurteilen, da die Beschreibungen sehr vage sind und der Code dazu fehlt. Offenbar lässt sich in irgendwelchen Logs der Hotname ebenfalls manipuliueren, das sich dadurch angeblich ergebende Risiko ist mir allerdings unklar. Möglicherweise wird irgendwo der Wert des Host-Parameters ungefiltert ausgegeben, das wäre dann allerdins eine ernsthafte Schwachstelle. Wie man die erwähnten Mails generieren können soll, bleibt völlig offen. Selbst wenn das geht, sehe ich keine Möglichkeit, darüber XSS zu bewirken, die Links zeigen ja aus einer E-Mail auf eine fremde Site. In dem Kontext direkt wird dann ja auch nur noch von Phishing geschrieben.

Auch diesen Exploit kann ich erstmal nicht nachvollziehen.

Es ist wie dort erläutert eben auch prinzipiell keine Schwachstelle. Man könnte lediglich argumentieren, dass es unschön ist, dass PHP-Code in einer Datei ausgeführt wird, die die unverdächtige Endung profile hat. Solange man nicht durch irgendeine unglückliche Konfiguration in die Situation kommt, dass jemand solch eine Datei auf den Server (und in dieses Verzeichnis) hochladen kann, sehe ich da noch kein unmittelbaes Problem.

Wird hier vielleicht von entsprechen unsicheren Dateiberechtigungen ausgegangen?

Auch das allein würde noch nicht reichen. Fehlende Schreibberechtigungen für den Benutzer, unter dem der Webserver läuft, würden aber einen Angiff durch ein nachlässig prüfende Upload-Funktion, bei der man Dateien mit der Endung profile in diesem Verzeichnis ablegen könne, immerhin verhindern können.

 

[tophirsch]

Du verwechselst die Möglichkeit zum Einstellen der Rechte (chmod) mit der zum Einstellen des Besitzers (chown). Nur ersteres geht nach meinen Kenntnissen über FTP.

Da werd ich mich wohl noch mal genauer damit auseinander setzen müssen...

Der Ansatz wird leider bei halbwegs gängiger Software recht frustrierend sein, weil dort schon andere auf die Idee gekommen sind, nach solchen Fehlern zu suchen. Motivierender dürfte http://google-gruyere.appspot.com/ sein.

Das klingt...plausibel...
Der link sieht interessant aus, werd ich bei Gelegenheit mal durchforsten.

Ich kann nicht erkennen, auf welche Code-Stelle du dich damit beziehst. Ich finde in dem Kontext nur eine behelfsweise Zuweisung von "No subject" (bzw. eine lokalisierte Fassung davon) in den Kommentar-Betreff, wenn dieser durch die Filterung leer geworden ist. Warum dort vermeintliche Tags überhaupt entfernt werden und nicht stattdessen die gefährlichen Zeichen korrekt in Zeichenreferenzen gewandelt werden, erschließt sich mir nicht so ganz, dadurch wird immerhin ggf. auch ein Text verfälscht.

Blöd, das es in dem Listing keine Zeilennummern gab...
Hier ist es Zeile 2187-2206, die ich meinte. Vielleicht bin ich mit der Stelle auch auf dem Holzweg...
Also:
[src=php]2187 // Validate the comment's subject. If not specified, extract from comment body.
2188 if (trim($comment->subject) == '') {
2189 // The body may be in any format, so:
2190 // 1) Filter it into HTML
2191 // 2) Strip out all HTML tags
2192 // 3) Convert entities back to plain-text.
2193 $comment_body = $comment->comment_body[LANGUAGE_NONE][0];
2194 if (isset($comment_body['format'])) {
2195 $comment_text = check_markup($comment_body['value'], $comment_body['format']);
2196 }
2197 else {
2198 $comment_text = check_plain($comment_body['value']);
2199 }
2200 $comment->subject = truncate_utf8(trim(decode_entities(strip_tags($comment_text))), 29, TRUE);
2201 // Edge cases where the comment body is populated only by HTML tags will
2202 // require a default subject.
2203 if ($comment->subject == '') {
2204 $comment->subject = t('(No subject)');
2205 }
2206 }[/src]
Aber eigentlich wird doch dort nur geguckt, ob subject leer ist, wenn das der Fall ist, dann wird subject mit den ersten paar Zeichen des eigentlichen Kommentartextes gefüllt. Und der Text wird vorher mit check_markup bzw check_plain gefiltert. Wenn das der Fall ist, wär immer noch nicht geklärt, ob die anderen beiden Eingabefelder(Name und eigentlicher Kommentartext) auch gefiltert werden. Und natürlich, ob auch gefiltert wird, wenn subject nicht leer ist...

Es sei denn du traust es dir zu, den Code der Webanwendung und ihrer Module gewissenhaft zu sichten.

Öhhm sicher nicht, deswegen hör ich jetzt besser auf damit...

Werde mir wie gesagt bei Gelegenheit mal deinen Link anschaun um noch ein bissel mehr von der Materie zu verstehen...

--- Automatisch zusammengeführter Beitrag ---

Noch eine Ergänzung:
Hatte mit p3Eq auch eine Unterhaltung via PN, da ich ihm mal ein Benutzerkonto erstellt hatte. Er hat dann noch einen Hinweis gegeben, den ich hier nicht vorenthalten will, falls später mal Hilfesuchende den thread lesen.

Er hatte das Konto direkt mal gesperrt, wegen zu vieler falscher Logins und gab mir den Hinweis, dass das ja mittels automatischen Scripten jeder tun könnte und man so ausgesperrt würde.

Daraufhin habe ich mich näher damit beschäftigt und herausgefunden, das in Drupal standardmäßig ein Konto nach 5 erfolglosen Logins für 6h gesperrt wird. Dabei wird aber auch die IP vermerkt, von der aus die fehlerhaften Logins erfolgten. Das heißt der wirkliche Benutzer könnte sich von einer anderen IP ungeachtet der Fehlversuche noch einloggen.

Dagegen konterte p3Eq mit "IP-Spoofing".

Das heißt, wenn die IP eines Users bekannt ist, kann der Angreifer diese IP als seine ausgeben und so den User wieder erfolgreich aussperren. Dafür muss man die IP nur erstmal haben. Das könnte sein, wenn der User eine Seite besucht, die IP's loggt und auf die der Angreifer Zugriff hat. Wie realistisch es ist, das sich jemand die Mühe macht, mag jeder anhand der Brisanz seiner Seite selbst beurteilen.
Abhilfe könnte hier ein Captcha schaffen, das nach einer bestimmten Anzahl Fehlversuche eingeblendet wird und so automatische Loginversuche per Script verhindert.


Davon ab war er auch grundsätzlich der Meinung ich sollte mir nicht so große Sorgen um die Sicherheit(vom Code selber) machen, da ich ja mit Drupal ein fertiges CMS verwende. Also eigentlich das, was auch aNtiCHrist meint. Ich konzentriere mich lieber darauf keine Hintertüren durch fehlerhafte Konfiguration offen zu lassen und immer alles aktuell zu halten.
Außerdem habe ich auch den "Security advisories" Feed abonniert um auf dem laufenden zu bleiben.

Danke an Alle!

 

[Kugelfisch]

Zur Begrenzung der Login-Versuche: IP-Spoofing ist an dieser Stelle meines Erachtens kaum ein Problem, da man mit einer gefälschten IP-Adresse nicht ohne Weiteres eine TCP-Verbindung aufbauen (dazu müsste man die Antwortpakete an geeigneter Stelle abfangen oder die Sequenznummer erraten) und daher auch keinen HTTP-Request durchführen kann. Das würde nur funktionieren, wenn der Angreifer Zugang zu einem Netzwerk hat, durch welches die Daten zwischen Server und Client durchgeleitet werden - dann könnte er jedoch auch den Login-Vorgang mitschneiden und die dadurch erzeugte Session übernehmen, sofern du nicht durchgehend eine Ende-zu-Ende-verschlüsselnde Verbindung (HTTPS) einsetzt.
Zum Problem wird das nur dann, wenn Drupal einer im HTTP-Header angegebenen alternativen IP-Adresse (z.B. in einem X-Forwarded-For- oder X-Client-IP-Header, wie ihn einige Proxies erzeugen) vertraut. Dann könnte ein Angreifer nämlich tatsächlich sehr leicht mit mutmasslichen IP-Adressen des Opfers gezielt fehlerhafte Login-Versuche erzeugen.

Grundsätzlich scheint mir die Funktionalität zum Beschränken der Login-Versuche ohnehin verzichtbar, und ich würde sie deaktivieren (oder das Limit sehr stark erhöhen, z.B. auf 50 fehlgeschlagene Anmeldungen hintereinander), schliesslich besteht auch die Gefahr, dass sich ein Benutzer dadurch versehentlich selbst aussperrt. Gegen nicht-triviale Passwörter werden Online-Angriffe ohnehin nicht erfolgreich sein, da sie viel zu ineffizient sind. Viel eher könnte man technisch verhindern, dass Benutzer triviale Passwörter wählen können.

 

[p3Eq]

Stimmt, die Antwort-Pakete vom Server bei der TCP-Verbindung habe ich nicht bedacht. Mein Gedankengang ist oberflächlicherweise nur gewesen, dass ein Angreifer nur fehlerhafte Loginversuche unter falscher IP generieren müsste, die Antwort vom Server aber nicht weiter auswerten müsse (denn die Seite, dass der Login fehlerhaft war, ist ja nicht von Interesse). Dass aber alleine für den Verbindungsaufbau schon ein Antwort-Paket empfangen werden muss, um den Handshake mit einem weiteren Paket abzuschließen, habe ich in dem Moment nicht bedacht. Danke für die Korrektur, Kugelfisch!