iptables und seine Folgen

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ich will mal ein paar Erfahrungswerte mitteilen und auch Eure Meinungen und fachlichen Tipps erbitten:

vor einiger Zeit wurde es auf unseren Servern zu bunt mit ssh-Angriffen und ähnlichen Versuchen, unberechtigt in den Server zu kommen. Ich habe daher zuerst fail2ban installiert. Das leistet schon eine Menge.

Als zweite Maßnahme habe ich dann ein Skript erstellt, dass regelmäßig das fail2ban.log auswertet und wiederkehrende Angreifer per iptables vollkommen aussperrt. Das leistet nun auch seinen Dienst. Seitdem sind die Chinesen erheblich weniger geworden.

Noch offen sind die echten Trickser, die nur im auth.log auflaufen. Die legen es nicht erst darauf an, im fail2ban-log aufzulaufen, sondern wählen die Zugriffe und die IPs aus ihrem Netzsegment so, dass fail2ban sie nicht registiert. das steht also noch auf dem Zettel.

Anders dieser Hansel hier:

IP | Zugriffe 43.229.52.137 | 1 43.229.52.140 | 2 43.229.52.141 | 2 43.229.52.147 | 1 43.229.52.151 | 1 43.229.52.162 | 2 43.229.52.164 | 1 43.229.52.165 | 3 43.229.52.166 | 1 43.229.52.171 | 1 43.229.52.181 | 1 43.229.52.184 | 2 43.229.52.185 | 1 43.229.52.186 | 1 43.229.52.191 | 1 43.229.52.193 | 1 43.229.52.199 | 1 43.229.52.200 | 1

ca. 20 mehr, innerhalb von ca. 10 Stunden.

Mit irgendeinem Whois ließ sich dann das Netz auch ermitteln (das normale auf unseren Linux-Hosts hat leider keinen Eintrag ermitteln können). Ein Netz aus Honkong. Da wir da keine Kunden haben, habe ich sie nach Rücksprache mit Chefchen auch ausgesperrt.

Nun endlich meine Fragen:

Kann das sein, dass durch das Aussperren erst die Attraktivität der Hosts erhöht wird in gewissen Kreisen? Haben die informelle Netze, in denen der Eine dem Anderen sagt: da musst du mal gukcen, die lassen mich nicht mehr rein?

Sollte ich generell unser Skript erweitern, dass es auch diese Häufungen innerhalb eines Netzes automatisch aussperrt und wie weit sollte ich dabei gehen? Unsere eigenen IPs von den Standorten habe ich schon mal sicherheitshalber auf eine Sonderfunktion gelegt g

Spirituelle Grüße
Euer Robert
[e-mail]

[Sandro]

Tag.

Kann das sein, dass durch das Aussperren erst die Attraktivität der Hosts erhöht wird in gewissen Kreisen? Haben die informelle Netze, in denen der Eine dem Anderen sagt: da musst du mal gukcen, die lassen mich nicht mehr rein?

Welchen Sinn sollte das ergeben? In Einbrecherkreisen wird sicher auch niemand Tipps geben à la "Die haben eine Alarmanlage an der Haustür, der Hausbesitzer ist wohl auf der Hut. Rüttele du doch mal an der Terrassentür."

Falls überhaupt, dann geht das eher in die Richtung "Unter [eure IP] waren die letztes Jahr schon zu dusselig, ihr [Software nach Wahl] auf aktuellem Stand zu halten, da bin ich prima reingekommen. Mal schauen, was es heute gibt."

Ich würde aber eher sagen, dass die Ursache für deine Beobachtung lediglich der ganz normale Wahnsinn des automatisierten Abgrasens ist.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Ich würde aber eher sagen, dass die Ursache für deine Beobachtung lediglich der ganz normale Wahnsinn des automatisierten Abgrasens ist.

Könnte sein. Aber es sind noch genügend chinesische IPs offen. Da kommt aber fast nix mehr. Dafür kommen die Leute aus USA, Hongkong, Indien und sonstigen kleineren Staaten nun immer öfter.

Ich glaube zwar auch nur der Statistik, die ich selbst gefälscht habe, aber die Zahlen sprechen trotzdem für eine deutliche Verschiebung in bisher unauffällige Bereiche.

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Ich würde aber eher sagen, dass die Ursache für deine Beobachtung lediglich der ganz normale Wahnsinn des automatisierten Abgrasens ist.

Könnte sein. Aber es sind noch genügend chinesische IPs offen. Da kommt aber fast nix mehr. Dafür kommen die Leute aus USA, Hongkong, Indien und sonstigen kleineren Staaten nun immer öfter.

Na ein Glück, dass es davon (momentan) nur 193 gibt.

… die Zahlen sprechen trotzdem für eine deutliche Verschiebung in bisher unauffällige Bereiche.

Vielleicht fallen die ja auch nur mehr auf, weil andere geblockt werden und in der Statistik nicht auftauchen.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

… die Zahlen sprechen trotzdem für eine deutliche Verschiebung in bisher unauffällige Bereiche.

Vielleicht fallen die ja auch nur mehr auf, weil andere geblockt werden und in der Statistik nicht auftauchen.

Sooo doof ist die Statistik nun auch nicht. Die arbeitet mit absoluten Zahlen und nicht mit Prozentsätzen ;-P

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

… die Zahlen sprechen trotzdem für eine deutliche Verschiebung in bisher unauffällige Bereiche.

Vielleicht fallen die ja auch nur mehr auf, weil andere geblockt werden und in der Statistik nicht auftauchen.

Sooo doof ist die Statistik nun auch nicht. Die arbeitet mit absoluten Zahlen und nicht mit Prozentsätzen ;-P

Dass einzelne Zugriffe in tausenden anderen untergehen könnten, ist aber abwegig?

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Sooo doof ist die Statistik nun auch nicht. Die arbeitet mit absoluten Zahlen und nicht mit Prozentsätzen ;-P

Dass einzelne Zugriffe in tausenden anderen untergehen könnten, ist aber abwegig?

Klar, es reicht ja auch DER EINE TREFFER aus, um dich lahmzulegen. Und wenn der Das geschickt macht, merkt man erstmal nix.

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Kann das sein, dass durch das Aussperren erst die Attraktivität der Hosts erhöht wird in gewissen Kreisen? Haben die informelle Netze, in denen der Eine dem Anderen sagt: da musst du mal gukcen, die lassen mich nicht mehr rein?

Welchen Sinn sollte das ergeben? In Einbrecherkreisen wird sicher auch niemand Tipps geben à la "Die haben eine Alarmanlage an der Haustür, der Hausbesitzer ist wohl auf der Hut. Rüttele du doch mal an der Terrassentür."

Natürlich gibt es das.

Falls überhaupt, dann geht das eher in die Richtung "Unter [eure IP] waren die letztes Jahr schon zu dusselig, ihr [Software nach Wahl] auf aktuellem Stand zu halten, da bin ich prima reingekommen. Mal schauen, was es heute gibt."

Das ist genau das gleiche Szenario wie oben, nur mit einer anders herum aufgezogenen Logik.

Grundsätzlich sollte man sich aber auch nicht um Kopf und Kragen sorgen. Es wird immer Angriffsversuche geben. Das wurde dem TO hier auch schon ans Herz gelegt. Und es wird immer abzuwägen sein, ob es sinnvoll ist, alle möglichen Adressen auszusperren oder ein gewisses Maß hinzunehmen und mit dem angemessenen Maß an Gleichmut zu reagieren.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Grundsätzlich sollte man sich aber auch nicht um Kopf und Kragen sorgen. Es wird immer Angriffsversuche geben. Das wurde dem TO hier auch schon ans Herz gelegt. Und es wird immer abzuwägen sein, ob es sinnvoll ist, alle möglichen Adressen auszusperren oder ein gewisses Maß hinzunehmen und mit dem angemessenen Maß an Gleichmut zu reagieren.

Stimmt schon. Aber wenn jemand 1128 Mal in etwas mehr als 48 Stunden versucht (unter einer IP), in den Host zu kommen unter den verschiedensten Standard-Usernamen für irgendwelche Dienste und das so geschickt timed, dass er eben nicht in fail2ban auffällig wird, dann frag ich mich doch, was dahinter stecken könnte.

BTW:

Gibt es Netzwerkkarten, bei denen man per Hardware-Jumper den Promiscuous Mode unterbinden kann?

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Grundsätzlich sollte man sich aber auch nicht um Kopf und Kragen sorgen. Es wird immer Angriffsversuche geben. Das wurde dem TO hier auch schon ans Herz gelegt. Und es wird immer abzuwägen sein, ob es sinnvoll ist, alle möglichen Adressen auszusperren oder ein gewisses Maß hinzunehmen und mit dem angemessenen Maß an Gleichmut zu reagieren.

Stimmt schon. Aber wenn jemand 1128 Mal in etwas mehr als 48 Stunden versucht (unter einer IP), in den Host zu kommen unter den verschiedensten Standard-Usernamen für irgendwelche Dienste und das so geschickt timed, dass er eben nicht in fail2ban auffällig wird, dann frag ich mich doch, was dahinter stecken könnte.

Wo ist das Problem? Soweit ich verstanden habe, protokollierst du die Zugriffe und sperrst auffällige IPs. That's it. Mehr kannst du ohne Heckmeck nicht machen und mehr musst du nicht machen, um den Übeltäter deines obigen Szenarios zu erwischen.

Tschö, Auge

[woodfighter]

Tach,

Gibt es Netzwerkkarten, bei denen man per Hardware-Jumper den Promiscuous Mode unterbinden kann?

Nicht dass ich wüßte, aber da jemand der Promiscuous Mode aktivieren könnte, auch die Rechte hätte die Firmware des Netzwerkinterfaces zu flashen, wäre das ziemlich nutzlos.

mfg
Woodfighter

[Sandro]

Kann das sein, dass durch das Aussperren erst die Attraktivität der Hosts erhöht wird in gewissen Kreisen? Haben die informelle Netze, in denen der Eine dem Anderen sagt: da musst du mal gukcen, die lassen mich nicht mehr rein?

Welchen Sinn sollte das ergeben? In Einbrecherkreisen wird sicher auch niemand Tipps geben à la "Die haben eine Alarmanlage an der Haustür, der Hausbesitzer ist wohl auf der Hut. Rüttele du doch mal an der Terrassentür."

Natürlich gibt es das.

Es soll Einbrecher geben, die anderen empfehlen, in ein allem Anschein nach gut gesichertes Gebäude einzusteigen?

Interessant.

Natürlich würde ich da nur nennen, dass man damit natürlich unliebsame, selten dämliche Einbrecherkonkurrenz ausschalten kann. Selten dämliche Dummheit seitens des Tippnehmers hatte ich jetzt aber einfach mal ausgeschlossen.

Falls überhaupt, dann geht das eher in die Richtung "Unter [eure IP] waren die letztes Jahr schon zu dusselig, ihr [Software nach Wahl] auf aktuellem Stand zu halten, da bin ich prima reingekommen. Mal schauen, was es heute gibt."

Das ist genau das gleiche Szenario wie oben, nur mit einer anders herum aufgezogenen Logik.

Der Tipp, in ein gut gesichertes Gebäude einzusteigen ist genau das gleiche Szenario wie der Tipp, in ein Gebäude einzusteigen, dass in der Vergangenheit schlampig gesichert war?

Einer von uns beiden hat eine Lese- und Verständnisschwäche. Ich definitiv nicht.

[Auge]

Hallo

Kann das sein, dass durch das Aussperren erst die Attraktivität der Hosts erhöht wird in gewissen Kreisen? Haben die informelle Netze, in denen der Eine dem Anderen sagt: da musst du mal gukcen, die lassen mich nicht mehr rein?

Welchen Sinn sollte das ergeben? In Einbrecherkreisen wird sicher auch niemand Tipps geben à la "Die haben eine Alarmanlage an der Haustür, der Hausbesitzer ist wohl auf der Hut. Rüttele du doch mal an der Terrassentür."

Natürlich gibt es das.

Es soll Einbrecher geben, die anderen empfehlen, in ein allem Anschein nach gut gesichertes Gebäude einzusteigen?

Interessant.

Nochmal: ja.

Falls überhaupt, dann geht das eher in die Richtung "Unter [eure IP] waren die letztes Jahr schon zu dusselig, ihr [Software nach Wahl] auf aktuellem Stand zu halten, da bin ich prima reingekommen. Mal schauen, was es heute gibt."

Das ist genau das gleiche Szenario wie oben, nur mit einer anders herum aufgezogenen Logik.

Der Tipp, in ein gut gesichertes Gebäude einzusteigen ist genau das gleiche Szenario wie der Tipp, in ein Gebäude einzusteigen, dass in der Vergangenheit schlampig gesichert war?

Es wird ein Tip gegeben. Ob es nun der Tip ist, nicht zu X zu gehen, weil die Sicherung bei X gut ist oder zu Y gehen, weil die Sicherung bei Y „schlampig“ ist, ist unerheblich. Warum es deiner Meinung nach keine Tips geben soll, gefährliche Situationen zu meiden, aber sehr wohl Tips, ungefährliche zu suchen, bleibt dein Geheimnis.

Einer von uns beiden hat eine Lese- und Verständnisschwäche. Ich definitiv nicht.

pfft

Tschö, Auge

[MudGuard]

Hi,

Der Tipp, in ein gut gesichertes Gebäude einzusteigen ist genau das gleiche Szenario wie der Tipp, in ein Gebäude einzusteigen, dass in der Vergangenheit schlampig gesichert war?

Es wird ein Tip gegeben. Ob es nun der Tip ist, nicht zu X zu gehen, weil die Sicherung bei X gut ist oder zu Y gehen, weil die Sicherung bei Y „schlampig“ ist, ist unerheblich.

Oder der Tipp lautet: bei X ist sehr gut gesichert, da muß besonders viel zu holen sein!

cu,
Andreas a/k/a MudGuard

[Christian Kruse]

Hallo robertroth,

du machst dir zu viele Gedanken. fail2ban einschalten (damit die Logfiles nicht so vollgespammt werden), Password-Authentifizierung abschalten und fertig.

LG,
CK

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Hallo robertroth,

du machst dir zu viele Gedanken. fail2ban einschalten (damit die Logfiles nicht so vollgespammt werden), Password-Authentifizierung abschalten und fertig.

Das mit der Passwordauthentifizierung AUS habe ich noch nicht ganz durchschaut.

Das heißt dann doch, dass nur noch ein Key ausreicht, um ins System zu kommen? Auch wenn der beliebig lang ist, verliere ich doch eine Information, oder?. Kann ich bei Fehlversuchen trotzdem noch genau feststellen, auf wessen Account der Versuch nun abgezielt hat?

Spirituelle Grüße
Euer Robert
[e-mail]

[Christian Kruse]

Hallo robertroth,

Das heißt dann doch, dass nur noch ein Key ausreicht, um ins System zu kommen?

Ja: so wie bisher also auch.

SSH hat mehrere Authentifizierungsmodule. Eins davon ist Passwort-Eingabe, da wird dann via PAM im Server geprüft, ob das Passwort stimmt. Ein anderes Modul ist Authentifizierung über SSH-Key. Das ist ein Public-Private-Key-Verfahren, da wird geprüft, ob du den zugehörigen Private Key hast. Falls ja, darfst du rein.

Auch wenn der beliebig lang ist, verliere ich doch eine Information, oder?

Nein, warum? Es wird immer nur Username und ein Token benutzt zur Authentifizierung, auch bei der Passwort-Authentifizierung. Nur dass das Verfahren Public-Private-Key deutlich sicherer ist, da die Keys länger und schlechter zu raten sind als dein Passwort.

Kann ich bei Fehlversuchen trotzdem noch genau feststellen, auf wessen Account der Versuch nun abgezielt hat?

Klar. Den Usernamen musst du ja weiterhin angeben.

LG,
CK

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Nein, warum? Es wird immer nur Username und ein Token benutzt zur Authentifizierung, auch bei der Passwort-Authentifizierung. Nur dass das Verfahren Public-Private-Key deutlich sicherer ist, da die Keys länger und schlechter zu raten sind als dein Passwort.

Kann ich bei Fehlversuchen trotzdem noch genau feststellen, auf wessen Account der Versuch nun abgezielt hat?

Klar. Den Usernamen musst du ja weiterhin angeben.

Ok. Dann lese ich nochmal. Hoffentlich verstehe ich alles gleich ;-)

Spirituelle Grüße
Euer Robert
[e-mail]

[Jörg Reinholz]

Moin!

http://www.fastix.org/r/ssh-authentifizierung_durch_schluesseldatei.pdf

Wäre nett, Du würdest es lesen und ein Feedback geben, ob es verständlich war und wie Du sonst damit zu recht gekommen bist.

Jörg Reinholz

[Jens]

Tach,

http://www.fastix.org/r/ssh-authentifizierung_durch_schluesseldatei.pdf

Wäre nett, Du würdest es lesen und ein Feedback geben, ob es verständlich war und wie Du sonst damit zu recht gekommen bist.

aus dem Text:

Die Option „-b 1024“ sorgt dafür, dass ein 1024 bit- langer Schlüssel erzeugt wird. Ohne diese Angabe wird ein 2048 bit langer Schlüssel erzeugt, der etwas übertrieben ist.

Das ist falsch und gefährlich (ja, ich habe gesehen, dass die Datei 8 Jahre alt ist), die Empfehlung ist seit spätestens 2 Jahren mindestens 2048 Bits zu nutzen (heute gehen wir davon aus, dass 1024 Bit-Keys mit spezieller Hardware nach etwa einem Tag knackbar ist). Es gibt keinen Grund neue Keys nicht gleich mit 4096 Bits zu erzeugen (solange man nicht auf alter embedded Hardware oder ähnlichem arbeitet) oder noch besser RSA gleich links liegen lassen und ECDSA einsetzen.

Der zweite Schritt sollte durch eine Version mit ssh-copy-id ersetzt werden, authorized_keys2 ist deprecated (seit 2001)

3. Schritt: die Angabe des Schlüssels mit "-i" ist fast immer unnötig.

mfg
Jens

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

http://www.fastix.org/r/ssh-authentifizierung_durch_schluesseldatei.pdf

Wäre nett, Du würdest es lesen und ein Feedback geben, ob es verständlich war und wie Du sonst damit zu recht gekommen bist.

aus dem Text:

Die Option „-b 1024“ sorgt dafür, dass ein 1024 bit- langer Schlüssel erzeugt wird. Ohne diese Angabe wird ein 2048 bit langer Schlüssel erzeugt, der etwas übertrieben ist.

Das ist falsch und gefährlich (ja, ich habe gesehen, dass die Datei 8 Jahre alt ist), die Empfehlung ist seit spätestens 2 Jahren mindestens 2048 Bits zu nutzen (heute gehen wir davon aus, dass 1024 Bit-Keys mit spezieller Hardware nach etwa einem Tag knackbar ist). Es gibt keinen Grund neue Keys nicht gleich mit 4096 Bits zu erzeugen (solange man nicht auf alter embedded Hardware oder ähnlichem arbeitet) oder noch besser RSA gleich links liegen lassen und ECDSA einsetzen.

Sehe ich auch so. Was sind schon 2048 Bit? Das entspricht mal gerade 16 Bytes,

@Jörg:

Ich habe das sofort quergelesen - genauer folgt noch.

Was mir allerdings aufstößt: Die Voraussetzungen weniger persönlich formulieren, dafür aber expliziter auf die unterschiedlichen Clients beziehen. Man steht als Anfänger doch erstmal im Wald. Wie fange ich jetzt an, wenn ich meinen Server im Netz mit meinem WinDOOFs-Client (oder Linux-Client, oder schwarzem Fenster im irgendwas-OS) in Zukunft mit RSA-Key besuchen will und nicht mehr mit Passwort?

Als zweites dann die Maßnahmen auf dem Host, das finde ich ok so.

Und zum Schluss die Sciherheitsüberlegungen: Wo lasse ich meinen RSA-Key, wie verhindere ich, dass der eventuell noch auf meinem Client herumvagabundiert, usw?

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Sehe ich auch so. Was sind schon 2048 Bit? Das entspricht mal gerade 16 Bytes,

console.assert( 2048 / 8 === 16 );

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Sehe ich auch so. Was sind schon 2048 Bit? Das entspricht mal gerade 16 Bytes,

console.assert( 2048 / 8 === 16 );

Na, sag ich doch! Noch schlimmer!

Da habe sich zwei Gedanken im Kopf verknotet. Das entspricht ungefähr der Sicherheit eines Passwortes mit 16 Stellen. Das war einer der Gedanken. Der andere war: ups 4096 Bit sind man gerade 16 Bytes :-)

Nur Gut, dass Du aufgepasst hast ;-P

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Da habe sich zwei Gedanken im Kopf verknotet. Das entspricht ungefähr der Sicherheit eines Passwortes mit 16 Stellen.

Ein 16-stelliges Passwort in ASCII-Kodierung hat 16 * 1 Byte = 16 * 8 Bit = 128 Bit Entropie. Ein 256 Zeichen langes Passwort hätte 2048 Bit Entropie.

Das war einer der Gedanken. Der andere war: ups 4096 Bit sind man gerade 16 Bytes :-)

4096 Bits sind aber 512 Bytes.

Um deinen Knoten auszulösen. 1 Byte entrpicht 8 Bit.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Da habe sich zwei Gedanken im Kopf verknotet. Das entspricht ungefähr der Sicherheit eines Passwortes mit 16 Stellen.

Ein 16-stelliges Passwort in ASCII-Kodierung hat 16 * 1 Byte = 16 * 8 Bit = 128 Bit Entropie. Ein 256 Zeichen langes Passwort hätte 2048 Bit Entropie.

Das war einer der Gedanken. Der andere war: ups 4096 Bit sind man gerade 16 Bytes :-)

4096 Bits sind aber 512 Bytes.

Um deinen Knoten auszulösen. 1 Byte entrpicht 8 Bit.

Irgendwas läuft hier schief. Ich mach erst mal eine Pause :-O

256 Möglichkeiten = 8 Bit ;-)

Bis später dann

Spirituelle Grüße
Euer Robert
[e-mail]

[woodfighter]

Tach,

Ein 16-stelliges Passwort in ASCII-Kodierung hat 16 * 1 Byte = 16 * 8 Bit = 128 Bit Entropie. Ein 256 Zeichen langes Passwort hätte 2048 Bit Entropie.

ASCII hat nur 7 Bit und davon muss man dann i.A. die Steuerzeichen abziehen, also statt 256^16=340282366920938463463374607431768211456 verschiedenen Zuständen kann ein 16 Zeichen ASCII-Passwort nur 95^16=44012666865176569775543212890625 Zustände haben, also etwa ein Faktor 7731464 oder knapp unter 23 Bit weniger. Hinzu kommt, dass Passwörter üblicherweise nicht durch einen guten Zufallsgenerator erzeugt werden, weshalb man mit Tools wie UNhash die Trefferrate nochmal vergößern kann.

mfg
Woodfighter

[1unitedpower]

Ein 16-stelliges Passwort in ASCII-Kodierung hat 16 * 1 Byte = 16 * 8 Bit = 128 Bit Entropie. Ein 256 Zeichen langes Passwort hätte 2048 Bit Entropie.

ASCII hat nur 7 Bit und davon muss man dann i.A. die Steuerzeichen abziehen

Da muss ich dir Recht geben, ich habe deshalb ASCII gewählt, weil mit einer Mulitbyte-Kodierung wie UTF8, die Rechnung wesentlich schwieriger gewesen wäre, ebenso habe ich Steuerzeichen der Einfachheit halber ignoriert. Extended ASCII hätte 8 Bit pro Zeichen, aber auch darin kommen Steuerzeichen vor, die man bei exakter Rechnung noch berücksichtigen müsste.

[woodfighter]

Tach,

Da muss ich dir Recht geben, ich habe deshalb ASCII gewählt, weil mit einer Mulitbyte-Kodierung wie UTF8, die Rechnung wesentlich schwieriger gewesen wäre, ebenso habe ich Steuerzeichen der Einfachheit halber ignoriert.

Schon klar, aber bei Sicherheitsthemen ist Exaktheit manchmal sehr nötig. Mit regelbasierten Ansätzen wie dem erwähnten UNhash, kann man häufig noch viel mehr scheinbare Entropie entfernen, wenn ich z.B. weiß, dass es eine Passwortrichtlinie gibt, die ein „Sonderzeichen“ voraussetzt, kann ich im allgemeinen raten, dass bei den meisten Passwörtern an genau einer Stelle ein Sonderzeichen ist (und das ist in den meisten Fällen dann an erster oder letzter Stelle) und schwups habe habe ich im Falle von ASCII statt 52 Buchstaben nur noch 32 Sonderzeichen zu checken (bzw. realistisch noch weniger, nämlich die auf der Tastatur einfah zu erreichenden). Die Entropie von Passwörtern wird durch eine einfache Rechnung halt deutlich überschätzt.

Extended ASCII hätte 8 Bit pro Zeichen, aber auch darin kommen Steuerzeichen vor, die man bei exakter Rechnung noch berücksichtigen müsste.

Welche Version der Extension, ANSI, ISO-8852-15, …? ;-)

mfg
Woodfighter

[1unitedpower]

Die Entropie von Passwörtern wird durch eine einfache Rechnung halt deutlich überschätzt.

Full ACK. Man kann (und sollte) meine urprüngliche Aussage also noch schärfer formulieren:

Um 2048 Bit Entropie zu erreichen, müsste ein ASCII-Passwort mindestens aus 256 Zeichen bestehen, de fakto müssen es noch wesentlich mehr sein, weil wegen den von dir genannten Gründen.

Auf der anderen Seite ist der tatsächliche Zeichenvorrat komplexitätstheoretisch(*) vernachlässigbar. Man nehme zum Beispiel ein Passwort der Länge 10 über 26 Buchstaben. Es gibt also 26^10 Möglichkeiten, ein Passwort zu wählen. Erhöht man bei gleichbleibender Länge den Zeichenvorrat auf 29 Zeichen, ergeben sich 29^10 Möglichkeiten. Fixiert man nun statt der Länge, das zugrunde liegende Alphabet und erhöht die Länge des Passworts um 3 Zeichen, ergeben sich 26^13 Kombinationsmöglichkeiten. Der Einfluss der Länge ist also exponentiell in der Größe des Zeichenvorrats beschränkt, der Einfluss des Zeichenvorrats ist dagegen nur linear in der Länge des Passworts beschränkt.

*) Soweit die Theorie. In der Praxis hat der Nutzer eigentlich nur die Möglichkeit die Länge zu varrieren und kann auf den Zeichenvorrat überhaupt keinen Einfluss nehmen.

Ein Comic sagt mehr als 1000 Worte:

(Quelle: https://xkcd.com/936/)

Extended ASCII hätte 8 Bit pro Zeichen, aber auch darin kommen Steuerzeichen vor, die man bei exakter Rechnung noch berücksichtigen müsste.

Welche Version der Extension, ANSI, ISO-8852-15, …? ;-)

Diejenigen, die kompatibel mit den ersten 128 Zeichenkodierungen aus UTF-8 sind. Also die einzigen mit Existensberechtigung :P

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Ein Comic sagt mehr als 1000 Worte:

(Quelle: https://xkcd.com/936/)

... wobei die Zeit zum Erraten vermutlich falsch berechnet wurde. Statistisch gesehen, darf nur die Hälfte der Zeit angesezt werden, also nur 225 Jahre ;-)

Spirituelle Grüße
Euer Robert
[e-mail]

[Jörg Reinholz]

Moin!

... wobei die Zeit zum Erraten vermutlich falsch berechnet wurde. Statistisch gesehen, darf nur die Hälfte der Zeit angesezt werden, also nur 225 Jahre ;-)

Und jetzt rechne nach, was passiert, wenn der Angreifer 254 Hosts hat und nach 5 Fehlversuchen mit einer Zwangspause bedacht wird, die sich nach 3 Wiederholungen (recidiver Ban, bei dem fail2ban die eigene Logdatei untersucht) auf eine Woche ausdehnt...

/etc/fail2ban/jail.conf (Auszug)

[ssh_root]
enabled  = true
port     = all
filter   = sshd_root
logpath  = /var/log/auth.log
maxretry = 2
bantime  = 3600


[recidive]
enabled  = true
port     = all
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = iptables-allports[name=recidive]
           sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime  = 604800  ; 1 week
findtime = 86400   ; 1 day
maxretry = 3

/etc/fail2ban/filter.d/sshd_root.conf

[INCLUDES]
before = common.conf

[Definition]
_daemon = sshd
failregex = ^%(__prefix_line)sFailed password for root from <HOST> port \d+ ssh2$
            ^%(__prefix_line)sFailed password for admin from <HOST> port \d+ ssh2$
            ^%(__prefix_line)sFailed password for invalid user .* from <HOST> port \d+ ssh2$
ignoreregex = 

/etc/fail2ban/filter.d/recidive.conf

[INCLUDES]
before = common.conf

[Definition]
_daemon = fail2ban\.actions
_jailname = recidive
failregex = ^(%(__prefix_line)s|,\d{3} fail2ban.actions:\s+)WARNING\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$
ignoreregex = 

Jörg Reinholz

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

... wobei die Zeit zum Erraten vermutlich falsch berechnet wurde. Statistisch gesehen, darf nur die Hälfte der Zeit angesezt werden, also nur 225 Jahre ;-)

Und jetzt rechne nach, was passiert, wenn der Angreifer 254 Hosts hat und nach 5 Fehlversuchen mit einer Zwangspause bedacht wird, die sich nach 3 Wiederholungen (recidiver Ban, bei dem failtoban die eigene Logdatei untersucht) auf eine Woche ausdehnt...

Gute Idee, packe ich mir gleich mal auf den ToDo-Stapel. Wenn ich begriffen habe, wie der Mechanismus genau funktioniert (ich muss schon erklären können, was die Zeilen bewirken, die ich in die Konfiguration einbaue) dann werde ich das mal vorschlagen. Damit sollten meine beiden Chefchen dann zufrieden sein können.

Die Geschichte mit den RSA-Keys lasse ich vorerst lieber. Die müssen ja irgendwo gespeichert werden und die Herren lassen jetzt schon überall ihre USB-Sticks und ihre Handies liegen. Sooo schnelle Turnschuhe habe ich nicht mehr, dann immer die PrivateKeys hinterherzutragen, nachdem ich sie dann natürlich jedes Mal schnellstens ändern muss...

/etc/fail2ban/jail.conf

[ssh_root]
enabled  = true
#port    = ssh
filter   = sshd_root
logpath  = /var/log/auth.log
maxretry = 2
bantime  = 3600


[recidive]
enabled  = true
port     = all
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = iptables-allports[name=recidive]
           sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime  = 604800  ; 1 week
findtime = 86400   ; 1 day
maxretry = 3

/etc/fail2ban/filter.d/sshd_root.conf

[INCLUDES]
before = common.conf

[Definition]
_daemon = sshd

failregex = ^%(__prefix_line)sFailed password for root from <HOST> port \d+ ssh2$
            ^%(__prefix_line)sFailed password for admin from <HOST> port \d+ ssh2$
            ^%(__prefix_line)sFailed password for invalid user .* from <HOST> port \d+ ssh2$
ignoreregex = 

/etc/fail2ban/filter.d/recidive.conf

[INCLUDES]
before = common.conf
[Definition]
_daemon = fail2ban\.actions
_jailname = recidive
failregex = ^(%(__prefix_line)s|,\d{3} fail2ban.actions:\s+)WARNING\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$

Jörg Reinholz

Spirituelle Grüße
Euer Robert
[e-mail]

[woodfighter]

Tach,

das ist natürlich wieder für einen Kombinationsangriff anfällig (je wörtlicher man das Comic nimmt, desto schlimmer). Insgesamt kann man sagen, dass merkbare Passwörter in eher näherer Zukunft endgültig der Vergangenheit angehören werden.

mfg
Woodfighter

[Matthias Apsel]

Hallo woodfighter.

Herzlich Willkommen im neuen Forum. Ich freue mich, wieder von dir zu lesen.

Bis demnächst
Matthias

[woodfighter]

Tach,

Herzlich Willkommen im neuen Forum. Ich freue mich, wieder von dir zu lesen.

thx

Woodfighter

[Jörg Reinholz]

Moin!

Das ist falsch und gefährlich (ja, ich habe gesehen, dass die Datei 8 Jahre alt ist),

Oh ja. Das Ding braucht dringend ein Update. Bin schon dabei. Auch die Wünsche von Robert bezüglich alternativer Betriebssysteme (z.B. Windows, Android oder Mac) als SSH-Client sollten wohl endlich berücksichtigt werden.

Jörg Reinholz

[woodfighter]

Tach,

Das ist falsch und gefährlich (ja, ich habe gesehen, dass die Datei 8 Jahre alt ist),

Oh ja. Das Ding braucht dringend ein Update. Bin schon dabei. Auch die Wünsche von Robert bezüglich alternativer Betriebssysteme (z.B. Windows, Android oder Mac) als SSH-Client sollten wohl endlich berücksichtigt werden.

https://wiki.archlinux.org/index.php/SSH_keys sieht nach einer relativ guten Anleitung auf englisch aus, die deutsche Version müsste mal überarbeitet werden; das wäre vermutlich sinnvoller als dein PDF.

mfg
Woodfighter

[Fred]

Moin,

vor einiger Zeit wurde es auf unseren Servern zu bunt mit ssh-Angriffen und ähnlichen Versuchen, unberechtigt in den Server zu kommen. Ich habe daher zuerst fail2ban installiert. Das leistet schon eine Menge.

Ich hatte meinen Raspberry für ssh offen im Internet. Die ssh Zugriffe via Port 22 waren schon heftig. Jetzt habe ich auf der Fritzbox die Config so geändert, das von außen der Port 8022 auf Port 22 zum Raspy geroutet wird und da passiert garnichts mehr.

Fred

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

vor einiger Zeit wurde es auf unseren Servern zu bunt mit ssh-Angriffen und ähnlichen Versuchen, unberechtigt in den Server zu kommen. Ich habe daher zuerst fail2ban installiert. Das leistet schon eine Menge.

Ich hatte meinen Raspberry für ssh offen im Internet. Die ssh Zugriffe via Port 22 waren schon heftig. Jetzt habe ich auf der Fritzbox die Config so geändert, das von außen der Port 8022 auf Port 22 zum Raspy geroutet wird und da passiert garnichts mehr.

Ok, also Standard-Abfragen auf Port 22. Hält die Primitivversuche erst einmal ab.

Ob Obscurity hier bei uns allerdings soviel bringt, wage ich zu beweifeln. Was passiert da jetzt bei Dir, wenn man nun die IP der Fritzbox mit nmap quält? Da antwortet dann eben 8022 mit "ich kann ssh sprechen", oder?

Spirituelle Grüße
Euer Robert
[e-mail]

[Fred]

Hi,

Was passiert da jetzt bei Dir, wenn man nun die IP der Fritzbox mit nmap quält? Da antwortet dann eben 8022 mit "ich kann ssh sprechen", oder?

Ja, richtig, ich habe aber noch nicht festgestellt das da jemand scannt...

Fred

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Anders dieser Hansel hier:

IP | Bans 43.229.52.137 | 1 43.229.52.140 | 2 43.229.52.141 | 2 43.229.52.147 | 1 43.229.52.151 | 1 43.229.52.162 | 2 43.229.52.164 | 1 43.229.52.165 | 3 43.229.52.166 | 1 43.229.52.171 | 1 43.229.52.181 | 1 43.229.52.184 | 2 43.229.52.185 | 1 43.229.52.186 | 1 43.229.52.191 | 1 43.229.52.193 | 1 43.229.52.199 | 1 43.229.52.200 | 1

ca. 20 mehr, innerhalb von ca. 10 Stunden.

Nur nochmal zur Klarstellung. Das waren also nicht Zugriffe, sondern Bans. Für die Zugriffe muss man die also mit dem Faktor für Fehlversuche aus fail2ban multiplizieren.

Spirituelle Grüße
Euer Robert
[e-mail]

[woodfighter]

Tach,

Kann das sein, dass durch das Aussperren erst die Attraktivität der Hosts erhöht wird in gewissen Kreisen? Haben die informelle Netze, in denen der Eine dem Anderen sagt: da musst du mal gukcen, die lassen mich nicht mehr rein?

ne, die Menge an verfügbaren Hosts, die „interessante“ Ziele sind, ist zu groß, als dass das eine Rolle spielen würde, das läuft automatisch ab. Wenn du die Aufmerksamkeit von jemandem mit ausreichend Wissen/Geschick/Zeit/Interesse erweckt hast, wirst du dich gegen einen Angriff nicht wehren können; ab da ist der Job eher Entdecken des Angriffs und Schadenskontrolle (natürlich vorallem durch vorbeugende Maßnahmen).

Sollte ich generell unser Skript erweitern, dass es auch diese Häufungen innerhalb eines Netzes automatisch aussperrt und wie weit sollte ich dabei gehen? Unsere eigenen IPs von den Standorten habe ich schon mal sicherheitshalber auf eine Sonderfunktion gelegt g

Du musst zwei Fälle unterscheiden:

1. dein Loginmechanismus/PW ist sicher genug → dann sind es nur zusätzliche Zeilen im Logfile
2. dein Loginmechanismus/PW ist nicht sicher genug → fail2ban wird dich nicht lange genug schützen oder du wirst dich früher oder später selbst aussperren

mfg
Woodfighter