Anleitung: ssh2dyn ssh nur von einer IP mit dynanmischer IP erlauben

    Das Folgende dokumentiert mal, was das Skript macht:

    Ausgeführt von einer beliebigen nicht berechtigten IP:

    Code
    1. :~$ ssh root@94.16.xxx.xxx -p 6666
    2. ssh: connect to host 94.16.xxx.xxx port 6666: Connection timed out

    Ausgeführt von der einzigen berechtigten IP:



    Und hier das Ergebnis von nmap ohne Skript von beliebiger nicht zugelassener IP:

    Code
    1. # nmap -sS 94.16.xxx.xxx
    2. Nmap scan report for v2xxxxxxxxxxxxxxx.bestsrv.de (94.16.xxx.xxx)
    3. Host is up (0.036s latency).
    4. Not shown: 999 filtered ports
    5. PORT STATE SERVICE
    6. 6666/tcp open irc
    8. Nmap done: 1 IP address (1 host up) scanned in 38.00 seconds

    Und hier nmap mit Skript von beliebiger nicht zugelassener IP:

    Code
    1. # nmap -sS 94.16.xxx.xxx
    3. Starting Nmap 7.01 ( https://nmap.org ) at 2020-02-15 06:52 CET
    4. Nmap scan report for v2xxxxxxxxxxxxxxx.bestsrv.de (94.16.1xxx.xxx)
    5. Host is up (0.039s latency).
    6. All 1000 scanned ports on v2xxxxxxxxxxxxxxx.bestsrv.de (94.16.xxx.xxx) are filtered
    8. Nmap done: 1 IP address (1 host up) scanned in 40.40 seconds


    Es macht also, was es machen soll.

    Mit Bordmitteln könnte man so das Ziel erreichen:


    1. fail2ban sperrt bereits beim 1. versuchten SSH-Zugriff (unabhängig vom Ergebnis)

    2. Ausser, den DynDNS Namen, der in der ignoreip Konfiguration von fail2ban steht

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

    Meinst du so?


    Ist ja genial, wenn das geht.

    Aber wie reagiert diese Konfiguration denn auf einen Portscan? Wie gesagt, bin kein Netzwerkspezialist.

    Ein SYN-Scan

    nmap -sS könnte da doch durchrutschen, oder?



    "

    Der SYN-Scan ist die schnellste und meistgenutzte Scan-Methode. Sie erlaubt eine zuverlässige Unterscheidung zwischen den Zuständen geschlossen und gefiltert. Wenn das Netzwerk schnell genug ist, dann kann man damit innerhalb weniger Sekunden mehrere Tausend Ports scannen.

    Den SYN-Scan bezeichnet man auch als Halfopen oder Stealth Scan. Er basiert darauf, dass der Drei-Wege-Handshake nur initiiert, aber nicht mit ACK bestätigt, sondern vorzeitig mit RST abgebrochen wird.

    • OPEN: SYN -> SYN+ACK -> RST
    • CLOSED: SYN -> RST (Das Zielsystem antwortet mit einem RST-Paket.)
    • FILTERED: SYN -> keine Antwort (Das SYN-Paket wird beim Zielsystem verworfen.)

    Dadurch, dass man die TCP-Verbindung nicht erst mit ACK bestätigt, sondern sofort mit RST beendet, ist die Scan-Geschwindigkeit um ungefähr 30 bis 40% schneller als beim Full-Connect-Scan.

    Der SYN-Scan bleibt oft unbemerkt, weil in der Regel nur Full-Connects bei der Anwendung protokolliert werden. Nachteilig ist für den Angreifer oder Pentester, das der SYN-Scan von einem IDS erkannt werden kann, weil der Ablauf ziemlich untypisch für eine "normale Verbindung" ist.

    "

    aus https://www.elektronik-kompendium.de/sites/net/2103061.htm

    Ich würde sogar einen neuen Filter auf den "sshd: Connect from..." string im Log machen, damit's schon beim Verbindungsaufbau ein "Found" produziert.


    Um Portscans habe ich mich noch nie gekümmert.

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

    Wenn du IPv6 hast, warum bindest du den SSH Server nicht auf eine zufällige IPv6 Adresse? Die letzten 64 Bit kannst du frei wählen.

    Für den Portscan nimmst du https://github.com/yrutschle/sslh - alles was keinen SSH Protocol Header mitschickt, wandert auf einen Webserver.


    Somit muss der Portscan die richtige IPv6 Adresse, den richtigen Port und das richtige Protokoll sprechen, damit man sieht, dass da überhaupt etwas los ist.


    ostfriese wrote:

    und warum rc.local. Hey, ich will nur ein Python Skript, welches mit 0.0 Cpu-Last dümpelt auf einem vServer mit einem core starten. Wozu systemd?

    Da du Debian nutzt, muss systemd erst rc.local starten. Und rc.local forked dann deinen Prozess.

    Statt also rc.local in systemd zu hinterlegen, kannst du gleich einen systemd Service hinterlegen, der auch überwacht, dass dein Skript nicht abstürzt.


    Edit: Skripte hier zu veröffentlichen, die du auch pflegen möchtest, ist etwas angenehmer über github oder github gists.

    Python 2 ist EOL - Neuentwicklungen sollte man mit Python3 schreiben.

    Du hast natürlich Recht mit Python2.7. Aber als IT Mensch im Ruhestand ist man natürlich ein wenig hinterher. Wenn überhaupt Interesse an dem Skript besteht, werde ich mir die Mühe machen das auf Python3 umzuschreiben.

    Aus dem selben Grund ist mir natürlich auch IPv6 suspekt. Das ist was für deine Generation;)

    Das ist tatsächlich der einzige Grund, warum mein vServer hier überhaupt existiert.

    Vodafone Kabel gibt mir keine echte von 'außen' erreichbare IPv4/die nennen das Dual-Stack-Lite, ist totaler Quatsch). Hab mich versucht in IPv6 einzulesen.

    Aufgegeben. Da wird ja alles, womit ich IT-Technisch 'aufgewachsen' bin über Bord geworfen.

    Also, für mich einfachste Lösung: vServer mit echter IPv4. Openvpn-Client im Netz hinter meiner ipfire-Firewall und dann Client to Client.

    Schon ist alles wieder IPv4 und ich fühl mich zuhause.

    Wie gesgagt, ich bin von Haus aus kein Netzwerker. IPv4 auf hohem 'Hausgebrauch-Niveau' ist ok für mich.

    Und mit dem systemd hast du natürlich auch Recht.

    ostfriese wrote:

    us dem selben Grund ist mir natürlich auch IPv6 suspekt. Das ist was für deine Generation

    Das ist tatsächlich der einzige Grund, warum mein vServer hier überhaupt existiert.

    Vodafone Kabel gibt mir keine echte von 'außen' erreichbare IPv4/die nennen das Dual-Stack-Lite, ist totaler Quatsch). Hab mich versucht in IPv6 einzulesen.

    Aufgegeben. Da wird ja alles, womit ich IT-Technisch 'aufgewachsen' bin über Bord geworfen.

    Wenn du dein Kabelmodem in den Bridge Mode umstellst, bekommst du auf dem ersten Interface eine richtige IPv4 Adresse. Da kannst du dann einen Router anklemmen. Das Modem macht dann nur noch Layer 2.


    Die Adresse ist sogar quasi statisch - ändert sich nur einmal im Jahr. IPv6 geht dann aber gar nicht mehr.

    Den Bridge Mode kannst du im Kundenportal aktivieren.

    Danke für den Tipp. Habe hier einen Gigabit Anschluss mit Docsis 3.1. Da muss ich die Provider Fritzbox nehmen. Die ist kastriert und kann keinen Bridge Mode. Kann auch im Kundencenter nichts umstellen. Das Ding macht bei mir nur Telefonie und dahinter kommt dann eine ipfire Firewall und dann erst mein Netz. Direkt an der Fritzbox hängt nur die Firewall. Habe den vServer im Angebot für 2,75/Monat. Und ein bisschen frickeln hält ja auch die Grauen Zellen jung.:)


    @Gunah

    Ja, habe ich schon was gelesen. Das kommt evtl. für Openvpn Road Warrior in Frage. Obwohl, da ist auch clientseitig Android im Spiel=O

    Da muss man ja sehr viel auf der Clientseite machen. Und 'ne Android App zu schreiben, dass tu ich mir nicht mehr an.

    Ich musste mich mein halbes Berufsleben mit Windoof 'rumquälen. Bin dann privat, Alter macht ja auch Weise;), spät zu Linux umgestiegen

    Aber finde es gut, wie alle hier mitdenken und sinnvolle Vorschläge machen. Danke dafür!


    By the way, ich habe festgestellt, dass fail2ban sich für Portscans gar nicht interessiert, solange keine Verbindung zu Stande kommt.


    hab mal den Vorschlag von @sdellenb umgesetzt. Habe dann von einem Perfect Privacy VPN Gateway(dort teilen sich hunderte Benutzer eine IP , also ein idealer Weg, wenn man Böses im Sinn hat!) Portscanns gemacht. Null Reaktion seitens fail2ban. Nur, wenn ich tatsächlich versuche, eine Verbindung aufzubauen, schnappt die Falle zu.

    wuerde es den Sicherheitsgewinn nicht drastisch erhöhen, in der IPtables die Default Policy auf DROP zu setzen zum einem

    (das erfordert evtl. ein paar zusätzliche Regeln)


    und in Bezug auf Port 22 diesen nur von definierten IPs zu erlauben, und im Falle von dyn. IPs sich einfach einen HE IPv6 Tunnel od. so zu besorgen

    um auf die Art eine fixe IP zu haben, dann kann man sich den Aufwand irgendwas einzupflegen, das nicht zu Standardbordmittel gehört und beim nächsten Update

    sehr wahrscheinlich nicht mehr klappt, komplett sparen;


    ich habe es zum Teil so, bei IPv6 mein HE-IPv6-Tunnel, mein ISP ist immer noch IPv4only;

    und bei IPv4 habe ich das da im iptables file

    Code
    1. -A INPUT -i eth0 -s rangeISP1 -m limit --limit 1/min -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
    2. -A INPUT -i eth0 -s rangeISP2 -m limit --limit 1/min -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
    3. ...
    4. -A INPUT -i eth0 -m tcp -p tcp --dport 22 -m state --state NEW -j DROP

    und Zugriffsversuche durch andere Kunden des selben ISPs enden mit einer abuse-Nachricht an den ISP, von daher nicht das Problem;


    ein Gedanke, wenn man es etwas ausgefuchst, und etwas tricky haben will, ohne irgendwie in die Standard-Boardmittel einzugreifen;

    einfach ein cronjob, welcher z.B. alle 2 Minuten, den dyndns-Namen abfrägt, und im Falle dass die IP eine andere ist,

    einfach folgendes macht

    Code
    1. iptables -D INPUT -i eth0 -s alteIP -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
    2. iptables -I INPUT -i eth0 -s neueIP -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT

    auf keinen Fall auf den Gedanken kommen, vom heimischen Router aus per wget/curl was am Server aufzurufen - egal ob per SSL/TLS od. nicht und auch egal ob passwortgesichert od. nicht - um so die Firewall von 'innen' zu ändern um Zugriff zu erlangen; ;)

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%

    H6G wrote:

    Wenn du dein Kabelmodem in den Bridge Mode umstellst, bekommst du auf dem ersten Interface eine richtige IPv4 Adresse. Da kannst du dann einen Router anklemmen.

    gibts diese Einschränkung ernsthaft ? Da bin ich ja bei UPC richtig gut bedient - bis zu drei IP kann ich direkt übers Kabelmodem (im Bridgemodus) beziehen, da kann man ganz gut testen ;-)

    Gruss

    ostfriese wrote:

    Vodafone Kabel gibt mir keine echte von 'außen' erreichbare IPv4/die nennen das Dual-Stack-Lite, ist totaler Quatsch

    Wenn du bei dre Hotline anrufst und sagst, dass sie dich auf ipv4 umstellen sollen, hast du innerhalb von 20 Minuten und einem Reboot eine echte V4 Adresse.

    Meistens auch echtes Dualstack.

    Ganz ohne Bridgemode...

    @ASS

    Danke für den Tipp. Haben die tatsächlich gemacht. Hatte das vor ca. 6 Monaten schon versucht, da war noch die Aussage, dass geht nur im Business-Tarif. Jetzt habe ich einen echten Dualstack. Werde aber meinen vServer weiter behalten, ist ja auch eine nette Spielwiese.


    @mainziman

    Das Script setzt auf 'Standardbordmittel' es setzt ausschließlich auf iptables-Rules. Ich habe das Ganze jetzt in Python 3 umgesetzt. Also wird das Script solange funktionieren, wie es iptables und Python 3 gibt. Hier ist aber nicht die richtige Stelle um das zu veröffentlichen.


    @H6G

    Habe deine Tipps umgesetzt. Das Script ist jetzt Python 3 und wird über systemd gestartet. Mal schauen, ob ich das auf github oder github gists mache. Ich arbeite noch an der Optimierung.


    Danke für alle sehr hilfreichen Hinweise hier im Forum.