brute forces
Juergen Koenig
Ich bin schon wieder einen Schritt weitergekommen. Die Ursache für Probleme,
die ich schon früher beschrieben habe, sind Brute-force Attacken auf den
ssh-Port. Das habe ich aber auch erst heute morgen gelernt. Da nützt das
nichts, was ich mir überlegt habe (siehe frühere Postings).
Nun habe ich mich ein wenig durch das Internet gelesen und eine
Lösungsmöglichkeit gefunden, die ich aber nicht ganz verstehe. Vielleicht
kann hier jemand weiterhelfen. Mit iptables und dem recent-modul kann man
die Attacken eindämmen.
Meine Fragen:
1) Woran erkenne ich, dass mein iptables das recent-modul hat? man iptables
hat mich nicht weiter gebracht.
2) Habe ich es richtig verstanden, dass ich dann einfach nur ein script aus
den drei oder vier Zeilen erstellen muss und dieses Script in die
boot.local eintragen muss.
Eine weitere, wenn auch nicht wünschenswerte Lösung, wäre es das
portforwarding für port 22 in fli4l abzustellen. Gibt es noch andere
Möglichkeiten. Ich habe gelesen, dass man auch sshd auf einem anderen Port
lauschen lassen könnte. Ok, ich habe diesen Eintrag in der config gefunden.
Dann muss ich aber auch entsprechend das portforwarding in fli4l ändern,
wenn ich das richtig verstehe. Welche ports wären denn dann sinnvoll?
Gruss Jürgen
Jan Greve
> Hi
>
hi
> Ich bin schon wieder einen Schritt weitergekommen. Die Ursache für Probleme,
> die ich schon früher beschrieben habe, sind Brute-force Attacken auf den
> ssh-Port. Das habe ich aber auch erst heute morgen gelernt. Da nützt das
> nichts, was ich mir überlegt habe (siehe frühere Postings).
> Nun habe ich mich ein wenig durch das Internet gelesen und eine
> Lösungsmöglichkeit gefunden, die ich aber nicht ganz verstehe. Vielleicht
> kann hier jemand weiterhelfen. Mit iptables und dem recent-modul kann man
> die Attacken eindämmen.
> Meine Fragen:
> 1) Woran erkenne ich, dass mein iptables das recent-modul hat? man iptables
> hat mich nicht weiter gebracht.
guck dir die kernel-module an... entweder im kernel selbst oder in
/usr/lib/modules irgendwo
> 2) Habe ich es richtig verstanden, dass ich dann einfach nur ein script aus
> den drei oder vier Zeilen erstellen muss und dieses Script in die
> boot.local eintragen muss.
sinnvoll waere es, das bestehende script abzuaendern (du routest ja
schon, hast also schon ein iptables-script laufen)
>
> Eine weitere, wenn auch nicht wünschenswerte Lösung, wäre es das
> portforwarding für port 22 in fli4l abzustellen. Gibt es noch andere
> Möglichkeiten. Ich habe gelesen, dass man auch sshd auf einem anderen Port
> lauschen lassen könnte. Ok, ich habe diesen Eintrag in der config gefunden.
> Dann muss ich aber auch entsprechend das portforwarding in fli4l ändern,
> wenn ich das richtig verstehe. Welche ports wären denn dann sinnvoll?
"kein anderer" waere die strikte antwort - "jeder andere" tuts aber
auch, wenn dir standards egal sind :)
ansonsten hilft es oft schon, seine ip nicht staendig auf ein schild zu
malen und zu irgendwelchen hackern zu werfen oder aber ssh mal fuer ein
paar tage zu deaktivieren.
achja: ssh ist nicht der router sondern auf dich forwarded, oder? wie
waers, wenn du den router nimmst und von da aus auf dich weiter machst -
waere nochmal ne stufe schwieriger.
>
> Gruss Jürgen
mfg jan
Christoph Sorge
> Ich bin schon wieder einen Schritt weitergekommen. Die Ursache für Probleme,
> die ich schon früher beschrieben habe, sind Brute-force Attacken auf den
> ssh-Port. Das habe ich aber auch erst heute morgen gelernt. Da nützt das
> nichts, was ich mir überlegt habe (siehe frühere Postings).
Welche Probleme entstehen da?
> Nun habe ich mich ein wenig durch das Internet gelesen und eine
> Lösungsmöglichkeit gefunden, die ich aber nicht ganz verstehe. Vielleicht
> kann hier jemand weiterhelfen. Mit iptables und dem recent-modul kann man
> die Attacken eindämmen.
Da wäre ich erst einmal vorsichtig; bei Bekannten sind bei solchen
Versuchen aufgrund eines Bugs im Recent-Modul Probleme aufgetreten.
Christoph
Helmut Hullen
Du (mkjtravel) meintest am 10.09.05:
> Ich bin schon wieder einen Schritt weitergekommen. Die Ursache für
> Probleme, die ich schon früher beschrieben habe, sind Brute-force
> Attacken auf den ssh-Port. Das habe ich aber auch erst heute morgen
> gelernt. Da nützt das nichts, was ich mir überlegt habe (siehe
> frühere Postings).
Ich gehe da mehrstufig vor (Arktur 3.4):
siehe http://hullen.de/Arktur/Schutz/index.html#ssh
Wenn der SSH-Zugang von draussen erlaubt ist, dann darf er natürlich
weder in "/etc/hosts.allow" noch in den "iptables"-Regeln komplett
unterbunden werden.
"PermitRootLogin" sollte ganz gewiss nicht auf "yes" stehen.
Das auf der o.g. Seite auch genannte Skript "vollblock" ist zwar
vielleicht politisch nicht korrekt, blockiert aber einige der Haupt-
Einflugschneisen sehr wirksam.
Viele Grüße!
Helmut
Juergen Koenig
> Juergen Koenig schrieb:
>
>> Ich bin schon wieder einen Schritt weitergekommen. Die Ursache für
>> Probleme, die ich schon früher beschrieben habe, sind Brute-force
>> Attacken auf den ssh-Port. Das habe ich aber auch erst heute morgen
>> gelernt. Da nützt das nichts, was ich mir überlegt habe (siehe frühere
>> Postings).
>
> Welche Probleme entstehen da?
Ich habe so etwa zweimal zwei Stunden pro Tag Dauereinlogversuche, die immer
von der selben IP kommen. Am nächsten Tag ist es dann einen andere
Quell-IP. Durch diese Dauerbeschäftigung wird der Proxy auf diesem Server
ziemlich langsam. Mir ist es selbst noch nicht aufgefallen, aber die
Kollegen klagen und es würde mit den Zeiten, die im log stehen, passen.
Gruss
Jürgen
Christoph Sorge
>> Welche Probleme entstehen da?
>
> Ich habe so etwa zweimal zwei Stunden pro Tag Dauereinlogversuche, die immer
> von der selben IP kommen. Am nächsten Tag ist es dann einen andere
> Quell-IP. Durch diese Dauerbeschäftigung wird der Proxy auf diesem Server
> ziemlich langsam. Mir ist es selbst noch nicht aufgefallen, aber die
> Kollegen klagen und es würde mit den Zeiten, die im log stehen, passen.
Es wundert mich, ehrlich gesagt, daß das eine solche Last erzeugt
(vielleicht zu den Zeiten mal "top" aufrufen?).
Ich würde unter diesen Umständen aber vielleicht doch mal die von Dir
angesprochenen iptables-Regeln ausprobieren. Der Bug im Recent-Modul,
den ich erwähnte, tritt erst nach rund drei Wochen auf (dann läuft ein
Zähler über), also mußt Du, bis es einen Patch gibt, halt gelegentlich
mal neu booten.
Oder eben den SSH-Server auf einem anderen Port als 22 lauschen lassen.
Christoph
Juergen Koenig
Helmut Hullen hat geschrieben:
>> Ich bin schon wieder einen Schritt weitergekommen. Die Ursache für
>> Probleme, die ich schon früher beschrieben habe, sind Brute-force
>> Attacken auf den ssh-Port. Das habe ich aber auch erst heute morgen
>> gelernt. Da nützt das nichts, was ich mir überlegt habe (siehe
>> frühere Postings).
>
> Ich gehe da mehrstufig vor (Arktur 3.4):
>
> siehe http://hullen.de/Arktur/Schutz/index.html#ssh
>
> Wenn der SSH-Zugang von draussen erlaubt ist, dann darf er natürlich
> weder in "/etc/hosts.allow" noch in den "iptables"-Regeln komplett
> unterbunden werden.
> "PermitRootLogin" sollte ganz gewiss nicht auf "yes" stehen.
Das habe ich auch als erstes nach meiner Internetrecherche abgestellt. Dann
wollte ich ein wenig mit den Parameter MaxStartup herumbasteln, habe mich
aber dabei selbst ausgeschlossen. Also abends nochmal in die Schule, sshd
gestartet und wieder nach Hause.
Gruss
Jürgen
Juergen Koenig
Helmut Hullen hat geschrieben:
> Ich gehe da mehrstufig vor (Arktur 3.4):
>
> siehe http://hullen.de/Arktur/Schutz/index.html#ssh
Unter der Adresse bekomme ich eine Fehlermeldung.
Gruss
Jürgen
Juergen Koenig
Jan Greve hat geschrieben:
> ansonsten hilft es oft schon, seine ip nicht staendig auf ein schild zu
> malen und zu irgendwelchen hackern zu werfen oder aber ssh mal fuer ein
> paar tage zu deaktivieren.
??? Wir bekommen täglich eine neue IP-Adresse. Welches Schild meinst Du
hier?
> achja: ssh ist nicht der router sondern auf dich forwarded, oder? wie
> waers, wenn du den router nimmst und von da aus auf dich weiter machst -
> waere nochmal ne stufe schwieriger.
Verstehe ich nicht. Auf dem fli4l-Router wird der Port 22 auf den Server im
lokalen Netz und dort auch auf port 22 geforwarded und dort sitzt auch der
sshd, nicht auf dem Router. Was soll ich also machen?
Gruss
Jürgen
Juergen Koenig
Christoph Sorge hat geschrieben:
> Es wundert mich, ehrlich gesagt, daß das eine solche Last erzeugt
> (vielleicht zu den Zeiten mal "top" aufrufen?).
>
> Ich würde unter diesen Umständen aber vielleicht doch mal die von Dir
> angesprochenen iptables-Regeln ausprobieren. Der Bug im Recent-Modul,
> den ich erwähnte, tritt erst nach rund drei Wochen auf (dann läuft ein
> Zähler über), also mußt Du, bis es einen Patch gibt, halt gelegentlich
> mal neu booten.
Wobei da immer noch nicht beantwortet ist, wie ich herausfinde, ob ich das
recent modul habe. lsmod führte nicht zum Ziel und ein
Verzeichnis /usr/lib/modules habe ich nicht. Das kann jetzt Suse spezifisch
sein.
> Oder eben den SSH-Server auf einem anderen Port als 22 lauschen lassen.
Das werde ich so machen, denn das läßt sich mit meinen Kenntnissen schnell
und unproblematisch realisieren.
Danke für die Hilfe
Gruß
Jürgen
Marcel Noe
> Wobei da immer noch nicht beantwortet ist, wie ich herausfinde, ob ich das
> recent modul habe. lsmod führte nicht zum Ziel und ein
> Verzeichnis /usr/lib/modules habe ich nicht. Das kann jetzt Suse spezifisch
> sein.
/lib/modules evtl.? Evtl. ist es auch fest in den Kernel einkompiliert.
Gruss Marcel
Helmut Hullen
Du (mkjtravel) meintest am 10.09.05:
> Ich habe so etwa zweimal zwei Stunden pro Tag Dauereinlogversuche,
> die immer von der selben IP kommen. Am nächsten Tag ist es dann
> einen andere Quell-IP. Durch diese Dauerbeschäftigung wird der
> Proxy auf diesem Server ziemlich langsam.
Da wäre ich skeptisch.
Solche Versuche sehe ich hier recht oft (eher täglich als alle zwei
Tage) durchaus eine Stunde lang) - die wirken sich hier nicht auf den
sonstigen Datendurchsatz aus.
Viele Grüße!
Helmut
Helmut Hullen
Du (mkjtravel) meintest am 10.09.05:
>> Ich gehe da mehrstufig vor (Arktur 3.4):
>>
>> siehe http://hullen.de/Arktur/Schutz/index.html#ssh
> Unter der Adresse bekomme ich eine Fehlermeldung.
Nächster Versuch:
http://hullen.de/helmut/Arktur/Schutz/index.html#ssh
Viele Grüße!
Helmut
Christoph Sorge
Juergen Koenig schrieb:
>> Ich würde unter diesen Umständen aber vielleicht doch mal die von Dir
>> angesprochenen iptables-Regeln ausprobieren. Der Bug im Recent-Modul,
>> den ich erwähnte, tritt erst nach rund drei Wochen auf (dann läuft ein
>> Zähler über), also mußt Du, bis es einen Patch gibt, halt gelegentlich
>> mal neu booten.
>
> Wobei da immer noch nicht beantwortet ist, wie ich herausfinde, ob ich das
> recent modul habe. lsmod führte nicht zum Ziel und ein
> Verzeichnis /usr/lib/modules habe ich nicht. Das kann jetzt Suse spezifisch
> sein.
Mhm, spricht etwas dagegen, das einfach auszuprobieren? Der Regelsatz
aus <4310E3D6...@mkr-tech.ch> erscheint mir (mit der genannten
Einschränkung) vernünftig:
iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m
recent --set
iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m
recent --update --seconds 60 --hitcount 4 -j LOG --log-prefix
"SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m
recent --update --seconds 60 --hitcount 4 -j REJECT
Zum Ausprobieren die drei Befehle als Root in jeweils einer Zeile
eintippen. Auf den mittleren kannst Du ggf. verzichten, der ist nur zum
Loggen.
>> Oder eben den SSH-Server auf einem anderen Port als 22 lauschen lassen.
>
> Das werde ich so machen, denn das läßt sich mit meinen Kenntnissen schnell
> und unproblematisch realisieren.
Würde ich unter diesen Umständen auch so machen.
Grüße,
Christoph
Gernot Zander
> Ich bin schon wieder einen Schritt weitergekommen. Die Ursache für Probleme,
> die ich schon früher beschrieben habe, sind Brute-force Attacken auf den
> ssh-Port. Das habe ich aber auch erst heute morgen gelernt. Da nützt das
> nichts, was ich mir überlegt habe (siehe frühere Postings).
> Nun habe ich mich ein wenig durch das Internet gelesen und eine
> Lösungsmöglichkeit gefunden, die ich aber nicht ganz verstehe. Vielleicht
> kann hier jemand weiterhelfen. Mit iptables und dem recent-modul kann man
> die Attacken eindämmen.
Ich habe:
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN limit: avg 3/min burst 3
drin. Das stört in der Praxis das "gute" Einloggen nicht, das
Script der Hacker gibt nach offenbar kurzer Zeit auf (und
nimmt die nächste IP ins Visier, aber die ist dann nicht
meine).
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Die Signatur ist der schwerste Teil dieser Nachricht und befindet sich daher
unten. (Nico Hoffmasnn)
Kai Jung
die netfilter-Module findest Du unter
/lib/modules/<kernelversion>/kernel/net/ipv4/netfilter
und bei einem 2.6er Kernel muesstes Du dort die Datei
ipt_recent.ko
finden.
Noch viel Erfolg
KJ
Kai Jung
ich vermute, Du spielst auf einen Artikel mit dem Titel
"Mit iptables gegen SSH Brute Force Attacken" an, in dem die Verwendung des
recent-Moduls beschrieben ist.
Normalerweise brauchst Du Dich um das Laden von Modulen garnicht zu kümmern,
wenn Du im Kernel das automatische Laden aktiviert hast.
Das setzt aber voraus, dass Du ein Firewallskript hast, in dem das Modul
verwendung findet.
Ob das Modul bei Dir installiert ist, siehst Du im Verzeichnis
/lib/modules/<kernelversion>/kernel/kernel/net/ipv4/netfilter
dort musstes Du die Datei ipt_recent.o finden.
Bei einem 2.6er kernel heisst es natuerlich ipt_recent.ko - ob auch ein
2.4er Kernel dieses Modul hat, weiss ich leider nicht.
Mit einem Vierzeiler in der boot.local ist es leider nicht getan, sondern Du
musst herausfinden, an welcher Stelle im System bei Dir die iptables-Regeln
stehen, und dort an geeigneter Stelle die besagten Zeilen einfuegen.
Eine Umleitung auf einen anderen Port nuetzt meiner Meinung nach wenig, denn
mit einem Portscanner laesst sich leicht herausfinden, welche Ports bei Dir
offen sind, und diese lassen sich auch mit SSH Attacken ansprechen. Das in
besagtem Artikel beschriebene Verfahren habe ich nicht getestet, und ich
kannte auch das recent Modul noch nicht. Ich kann also nicht sagen, ob die
beschriebene Verwendung (syntaktisch) richtig ist.
Viel Erfolg
KJ
Helmut Hullen
Du (hifi) meintest am 10.09.05:
> Ich habe:
> ACCEPT tcp -- anywhere anywhere tcp
> dpt:ssh flags:SYN,RST,ACK/SYN limit: avg 3/min burst 3
> drin.
Wo "drin"?
"iptables" mag diese Zeile nicht.
Viele Grüße!
Helmut
Gernot Zander
in schule.internet.technik Helmut Hullen <HHull...@t-online.de> wrote:
> Du (hifi) meintest am 10.09.05:
>> Ich habe:
>> ACCEPT tcp -- anywhere anywhere tcp
>> dpt:ssh flags:SYN,RST,ACK/SYN limit: avg 3/min burst 3
>> drin.
> Wo "drin"?
> "iptables" mag diese Zeile nicht.
Das ist der Output von iptables -L.
Die Zeile zum Erzeugen ist irgendwo vergraben, Moment...
Da:
iptables -A INPUT -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 22 \
--syn -m limit --limit 3/minute --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 22 \
--syn -j DROP
(Backslash zeigt manuellen Umbruch.)
Bis jetzt bewährt sich das (auf mehreren im Netz stehenden
Rechnern), ich sehe ab und zu Versuche, aber immer nur drei,
die Scripte geben dann scheinbar auf. Ich selbst bin immer
reingekommen.
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Hinweis: die Information steckt primaer im schwarzen Teil des
Schwarz/Weiss-Musters auf Deinem Bildschirm, wird als solche jedoch nur
in der spezifischen Abgrenzung gegen Weiss deutlich. (E. Moenkeberg)
Helmut Hullen
Du (hifi) meintest am 14.09.05:
> Die Zeile zum Erzeugen ist irgendwo vergraben, Moment...
> Da:
> iptables -A INPUT -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 22 \
> --syn -m limit --limit 3/minute --limit-burst 3 -j ACCEPT
> iptables -A INPUT -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 22 \
> --syn -j DROP
> (Backslash zeigt manuellen Umbruch.)
Danke - eingebaut.
Mal sehen, ob das zu weniger Protokollzeilen führt - einige der
Idioten haben ihren Automaten durchaus eine Stunde lang laufen lassen.
Viele Grüße!
Helmut
Christoph Sorge
> Eine Umleitung auf einen anderen Port nuetzt meiner Meinung nach wenig, denn
> mit einem Portscanner laesst sich leicht herausfinden, welche Ports bei Dir
> offen sind, und diese lassen sich auch mit SSH Attacken ansprechen.
Darum geht es aber auch gar nicht. Das offenbar kursierende Skript fährt
Brute-Force-Angriffe auf Port 22, mehr nicht. Da es sich hier um sehr
viele Login-Versuche handelt, ist das Umbiegen des SSH-Ports eine
erfolgversprechende Methode, wenn man sein Logfile klein halten will
oder sonstwie genervt wird.
Sicherheit, gar gegen gezielte Angriffe, bietet das natürlich nicht.
Ich persönlich habe den SSH-Port gelassen, wo er war - aber nur aus
ästhetischen Gründen ;-)
Gruß,
Christoph
Helmut Hullen
Du (hifi) meintest am 14.09.05:
>> Wo "drin"?
>> "iptables" mag diese Zeile nicht.
> Das ist der Output von iptables -L.
> Die Zeile zum Erzeugen ist irgendwo vergraben, Moment...
> Da:
> iptables -A INPUT -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 22 \
> --syn -m limit --limit 3/minute --limit-burst 3 -j ACCEPT
> iptables -A INPUT -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 22 \
> --syn -j DROP
> (Backslash zeigt manuellen Umbruch.)
In der "linuxmuster"-Mailingliste hat Flörian Frank diese Idee noch
ein wenig verbessert:
-------------------- Zitat ein ------------------
Absender : floria...@pingos.org (Florian Frank)
Das lässt allerdings nur 3 Verbindungsanfragen auf Port 22 pro Minute zu,
und zwar insgesamt, was einem DoS Tür und Tor öffnet. Also während
jemand Passwörter probiert bekommt selbst der Admin keinen Login mehr.
Prinzipell besser finde ich sowas (sofern ipt_recent auf der lml vorhanden
ist; eth0 ist durch das externe Interface zu ersetzen)
# ssh (in;eth0)
$IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW \
-m recent --set --name SSH
$IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW \
-m recent --update --seconds 60 --hitcount 4 --rttl --name SSH \
-j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW \
-j ACCEPT
Das macht im Prinzip das selbe, allerdings pro Absender-IP. Pro
Absender-IP dürfen also 3 Verbindungsanfragen pro Minute kommen.
Damit kann man sich noch einloggen, auch wenn von einer anderen IP gerade
gescannt wird.
-------------------- Zitat aus ------------------
Weitere Verbesserung: "eth0" wird durch "ppp+" ersetzt, die 3 Zeilen
werden dann kopiert und "ppp+" wird in diesen 3 Zeilen durch "ippp+"
ersetzt.
Dann gilt die Anweisung für alle "ppp"- und "ippp"-Interfaces.
Viele Grüße!
Helmut
Gernot Zander
in schule.internet.technik Helmut Hullen <HHull...@t-online.de> wrote:
> Das lässt allerdings nur 3 Verbindungsanfragen auf Port 22 pro Minute zu,
> und zwar insgesamt, was einem DoS Tür und Tor öffnet. Also während
> jemand Passwörter probiert bekommt selbst der Admin keinen Login mehr.
Ich weiß. Aber das ist in der Praxis noch nicht vorgefallen,
das Script gibt einfach auf:-), ich selbst bin immer reingekommen.
Daher habe ich nicht noch mehr Mühe darauf verwendet.
Ich hatte sogar mal einen drin (auf einer Kiste, auf der
"mysql" mit "mysql" existierte). Der war dann noch zu blöd,
was damit anzufangen. Log sah etwa so aus:
Failed password for root ...
Accepted password for mysql
5 Minuten später:
Accepted password for mysql
password changed for user mysql
und dann 10 s später:
Failed password for mysql
Failed password for mysql
Failed password for mysql
Ich hab mich weggeschmissen, als ich das Log gelesen habe:-)
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Die meisten Servicetechniker deklassieren sich aber mit dem Begriff
"Einschicken" schon in der ersten Runde. (Marcel Müller)