SSH Brute-Force unterbinden?

  • Wer erkennt die IP vom ISP?

    Wenn ich mich über putty auf den selbigen Server verbinde auf dem auch der VPN-Server läuft. Der nginx / apache welcher auf dem gleichen Server läuft, erkennt ebenfalls meine reale IP und nicht die vom VPN.


    Alle anderen Server / Dienste / Websites auf die ich mich verbinde wird korrekt die IP vom VPN angezeigt.



    In deiner Client Config ist dein Server als Peer eingetragen. In dieser Peer Config hast du einen Eintrag namens "AllowedIPs".

    Dort musst du, wenn du allen Traffic durch dieses VPN schieben magst, 0.0.0.0/0, ::/0 als Wert eintragen.

    Jup, genauso wurde wireguard clientseitig konfiguriert. Wie gesagt auf allen anderen Servern / Diensten funktioniert das auch nur halt nicht auf dem Server wo der VPN-Server selbst gehostet wird.


    P.S. Zuvor habe ich OpenVPN genutzt wo selbiger "Fehler" auftrat.

  • Mal ganz doof nachgefragt: Wenn ich mich mit aktiven VPN per ssh mit dem Server, auf dem auch der VPN Server läuft, verbinde, wird meine IP vom ISP erkannt und nicht mehr die vom VPN.


    Kann ich dies irgendwie aushebeln / umgehen? (Debian 10 / wireguard)

    Gar nicht.


    Der VPN Client muss ja mit dem VPN Server kommunizieren, während der restliche Traffic über den VPN Server abläuft.

    Sei 10.8.0.0/24 dein VPN Subnet, 1.2.3.4 die öffentliche IP deines Servers und 192.168.0.1 die IP deines Routers, so erstellt jeder VPN Client mit der Config: Surfen über den VPN, folgende Routingtabelle:


    default via 10.8.0.1 dev tun0

    1.2.3.4/32 via 192.168.0.1 dev eth0


    Folgerichtig wird jeder Traffic, der an deinen Server direkt geht (SSH, nginx etc.) über deinen Router geschickt.

    Du könntest dir jetzt eine Routingtabelle basteln, die den Destinationport in betracht zieht und wirklich nur die UDP Packete zum Server routet und den Rest über den VPN, oder du könntest dir eine extra IP bestellen, die nur für den VPN verantwortlich ist, oder du hast einen extra Server, der nur VPN als Dienst anbietet.

  • oder du könntest dir eine extra IP bestellen, die nur für den VPN verantwortlich ist

    So, jetzt habe ich soweit eine zusätzliche IP auf meinem Debian 10 System konfiguriert. Jetzt ist nur das Problem, dass ich zwar über die zusätzliche IP per wireguard connecten kann aber nach wie vor die Haupt IP des Servers (eth0) als ausgehende IP Adresse angezeigt wird.


    Gibt es eine Möglichkeit den eingehenden Traffic von wg0 (wireguard) auf eth0:1 (zusätzliche IP) "umzurouten"? Ich hab mir schon mehrere Sachen im Bezug auf ip route angeschaut, jedoch hab ich die Befürchtung, dass bei einer Fehlkonfiguration dann gar nicht mehr geht ^^

  • Gibt es eine Möglichkeit den eingehenden Traffic von wg0 (wireguard) auf eth0:1 (zusätzliche IP) "umzurouten"? Ich hab mir schon mehrere Sachen im Bezug auf ip route angeschaut, jedoch hab ich die Befürchtung, dass bei einer Fehlkonfiguration dann gar nicht mehr geht

    Du sprichst von deiner ausgehenden NAT Config?

    Anstatt -j MASQUERADE ein -j SNAT --to-source zusätzlicheIP in der iptables

  • Du sprichst von deiner ausgehenden NAT Config?

    Anstatt -j MASQUERADE ein -j SNAT --to-source zusätzlicheIP in der iptables

    Danke für deine Mühe!


    hab jetzt PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source <zusätzlicheIP> in der wireguard config drin stehen was auch beim starten akzeptiert wird jedoch wird nach wie vor die Haupt IP als ausgehende IP angezeigt. Soweit sind aktuell zum testen auch keine weiteren Firewall Regeln aktiv.


    Woran kann es liegen?

  • Woran kann es liegen?

    Evtl. ist da noch ein Eintrag in der nat Tabelle drinne? Ansonsten kannst du statt -A auch -I verwenden, damit die Regel weiter oben steht.

    iptables -t nat -S


    Ich würde dir empfehlen die NAT Regel noch weiter einzugrenzen, weil -o eth0 ist sehr weit definiert und könnte Traffic beinhalten, den du nicht im NAT möchtest.

  • Evtl. ist da noch ein Eintrag in der nat Tabelle drinne? Ansonsten kannst du statt -A auch -I verwenden, damit die Regel weiter oben steht.

    iptables -t nat -S

    Sehr sehr schön, es waren wirklich noch alte Einträge vorhanden :sleeping:


    Vielen Dank!


    Ich würde dir empfehlen die NAT Regel noch weiter einzugrenzen, weil -o eth0 ist sehr weit definiert und könnte Traffic beinhalten, den du nicht im NAT möchtest.

    Für mich ist wichtig das der öffentliche Traffic der von wg0 kommt über die zusätzliche IP geroutet wird. Gibt es hierzu eine explizite Regel, die dies einfach eingrenzt oder kommt es immer auf den Einzelfall an?

  • Für mich ist wichtig das der öffentliche Traffic der von wg0 kommt über die zusätzliche IP geroutet wird. Gibt es hierzu eine explizite Regel, die dies einfach eingrenzt oder kommt es immer auf den Einzelfall an?

    Das sinnvollste ist hier die Source Adressen einzuschränken. Im Wireguard hast du ja ein Allowed-IPs statement, diese IPs kannst du auch als Source-Einschränkung für dein NAT verwenden.

    -i wg0 -o eth0 dürfte auch funktionieren, allerdings bin ich mir da nicht sicher.

  • Meine Frage: Ist das wirklich normal? Finden wirklich dauerhaft Brute-Force Angriffe auf Server statt? Oder bin ich hier außergewöhnlich stark betroffen?

    ...

    Oder gibt es andere Ansätze, die ich treffen könnte?

    Das ist absolut normal. Die SSH PasswordAuthentication abstellen ist das erste was man in einem offen zugänglichen Server machen muss. Bei CentOS/RedHat z.B. in /etc/ssh/sshd_config -> "PasswordAuthentication no".
    Aber vorher noch SSH keys anlegen und hochladen, sonst sperrst du dich selber aus ;) (siehe ssh-keygen und ssh-copy-id. Oder Windows Putty... damit kenn ich mich aber nicht aus.)


    Wenn man das gemacht hat ist (zumindest bei SSH) erstmal Ruhe. Dann kriegen sie mit, dass sie mit einem Passwort sowieso nicht reinkommen.


    Quote

    Habe nun DenyHosts oder fail2ban entdeckt, werde vermutlich eines von beiden testen. Kann jemand Erfahrungen dazu teilen?


    Fail2ban hab ich neulich auch entdeckt, und installiert weil ich brute force Attacken auf mehrere Mailserver hatte. Funktioniert da ganz gut. Für SSH würde ich mich aber nicht ausschließlich darauf verlassen.