Posts by ehlers

    Ich nutze Debian Buster und war mit dessen fail2ban nicht vollkommen glücklich. Ziemlich viele Loginversuche wurden nicht erkannt, Ich habe dann an den Rules herumgeschraubt, das hat dann einigermaßen gepasst. Ich finde die fail2ban-Lösung aber recht aufwendig. Der Openssh-Server hat keine wirklichen Performance-Probleme bei den "üblichen" Loginversuchen. Nur wenn das einer übertreibt sollte man ihn auf die Finger hauen.


    Ich habe also die fail2ban-Lösung durch ein RateLimit der Firewall ersetzt, hier ein Auszug meiner nftables Regeln:


    Code
    1. chain input {
    2. ct state invalid drop
    3. ct state { established, related } accept
    4. iif "lo" accept
    5. tcp dport { http, https } accept
    6. ip version 4 tcp dport ssh meter ssh4blocked size 1024 { ip saddr & 255.255.255.0 timeout 1h limit rate 1/minute burst 10 packets} counter name "ssh_connections" accept
    7. ip6 version 6 tcp dport ssh meter ssh6blocked size 1024 { ip6 saddr & ffff:ffff:ffff:ff00:: timeout 1h limit rate 1/minute burst 10 packets} counter name "ssh_connections" accept
    8. tcp dport ssh counter name "ssh_rate_limit" reject

    Die Syntax ist angepasst an die etwas angestaubte Version von nftables in Debian Buster, für aktuelle Versionen siehe https://wiki.nftables.org/wiki-nftables/index.php/Meters.


    Damit darf jedes /24 IPv4-Netz bzw. /56 IPv6-Netz einen ssh-Verbindungsaufbau pro Minute machen, der Burst von 10 erlaubt ein Überschreiten dieses Limits um bis zu 10 Verbindungsaufbauten. Alles was drüber liegt, wird von der Firewall abgeschmettert.


    Mit einem kurzen Script hole ich mir alle 3 Strunden eine Statistik:


    Shell-Script
    1. conn=$(/usr/sbin/nft reset counter inet filter ssh_connections | awk '$1 == "packets" { print $2 }')
    2. [ -z "$conn" ] && exit 1
    3. rl=$(/usr/sbin/nft reset counter inet filter ssh_rate_limit | awk '$1 == "packets" { print $2 }')
    4. [ -z "$rl" ] && exit 1
    5. logger -p auth.info -t nftables "SSH connections: $conn, rate limit exceeded: $rl"


    Hier mal ein Auszug aus dem Log:

    Code
    1. Nov 17 15:00:01 netcup nftables: SSH connections: 43, rate limit exceeded: 0
    2. Nov 17 18:00:01 netcup nftables: SSH connections: 68, rate limit exceeded: 0
    3. Nov 17 21:00:01 netcup nftables: SSH connections: 35, rate limit exceeded: 4
    4. Nov 18 00:00:01 netcup nftables: SSH connections: 72, rate limit exceeded: 4
    5. Nov 18 03:00:01 netcup nftables: SSH connections: 40, rate limit exceeded: 0
    6. Nov 18 06:00:01 netcup nftables: SSH connections: 105, rate limit exceeded: 98
    7. Nov 18 09:00:01 netcup nftables: SSH connections: 80, rate limit exceeded: 0


    Ich bekomme also so etwa 80 Requests/3 Stunden, die vom ssh-Server bearbeitet werden müssen, heftigere Scans blockt die Firewall ab. Das ganze auf dem Standardport 22. Diese recht simple Konfiguration hat sich bislang bestens bewährt. Die "normalen" Scans kann der ssh-Server locker ab, heftigere Scans filtert die Firewall weg.

    Prinzipiell wäre es smarter das zu splitten, aber dann fühle ich mich blöd wenn bspw. Minecraft für einige Monate uncool ist aber ich dann trotzdem noch extra für einen Server reinbuttere.

    Auch die Root-Server bekommt zu mit unterschiedlichen Vertragslaufzeiten (1, 6, 12 Monate). Wenn du unsicher bist, kannst du ja mit einem 1-Monats Vertrag anfangen.

    Ich würde keine große Arbeit in die SCP-Statistiken stecken. Sie sind als Überblick ganz nützlich, für genauere Statistiken schlage ich die Installation von Servermonitoring-Software wie munin vor, bei größeren Anforderungen gerne auch grafana/prometheus.

    Mit den obigen Befehlen änderst du nur die Destination IP in deinen Paketen, dein Router versucht dann die Pakete direkt an dein Handy zurückzusenden ohne die Rückroute über deinen Server zu nutzen. Du musst auch noch die Source IP über POSTROUTING auf die des Servers ändern.

    Skl Hast du das schon probiert?


    Hier ein Artikel, wie man die Weiterleitung mit iptables realisieren kann:

    http://jensd.be/343/linux/forw…t-using-nat-with-iptables

    Git's eigentlich einen Artikeln, weche Regeln hier so gelten? Ich habe nichts gefunden.


    Ich würde sowas im Forum Informationen / Aktuelle Informationen als angepinnten Artikel erwarten.

    Seit dem letzten Herunterfahren/Neustart habe ich diese Meldung auch, vorher war sie nicht da. Merkwürdig ist, dass die Meldung direkt nach dem Start weg ist, sie taucht erst nach einiger Zeit auf. Habe natürlich den Status des qemu-guest-agent kontrolliert, sieht sauber aus.


    Da der qemu-guest-agent wohl nicht erkannt wird, habe ich ihn gerade deinstalliert. Ich habe die erweiterten Features im SCP eh nicht genutzt.

    Da mein E-Mail Server ebenfalls auf der Maschine liegt, kann ich auch keine Mails vom Support empfangen.

    Das halte ich für keine gute Idee. Ich würde die email-Adresse für den Supportkontakt in den CCP-Stammdaten auf eine Adresse setzen, die komplett unabhängig von Netcup ist. Also irgendwo eine kostenlose email-Adresse holen und diese im CCP eintragen, das kannst du ja auch jetzt noch machen.


    Damit du nicht dauernd diese separate email-Adresse prüfen musst, kannst du ja eine Weiterleitung an deine normale email-Adresse einrichten. Hauptsache die eMails werden nach der Weiterleitung nicht sofort automatisch gelöscht, damit du auf die auch im Fehlerfall noch zugreifen kannst.

    Ich finde man sollte zwischen Sicherheit und Schutz vor unnötiger Last unterscheiden.


    Ein Server muss sicher sein, egal wie der Angreifer versucht reinzukommen. Ein Änden des SSH-Ports ändert nach meiner Einschätznung nicht die Sicherheit. Es macht nur die Anzahl der dummen Angriffe etwas geringer, die sollten aber eh keine Chance haben.


    Aber ein Server soll auch nicht mit unnötigen Aufgaben belastet werden. Gut, die SSH-Scans erzeugen wohl keine große Last. Aber es ist auch lästig, wenn die Logfiles mit Einträgen von Einbruchsversuchen geflutet werden.


    Allerdings macht die Nutzung eines alternativen Ports die gewollte Nutzung etwas umständlicher. Aus meiner Sicht sollte man beide Aspekte abwägen und sich entsprechend entscheiden, beide Alternativen sind überlegenswert.

    Du hast dich sehr unglücklich ausgedrückt. Du sprichst in der Überschrift und im ersten Beitrag davon deine Domain nach Netcup umzuziehen. Das versteht tab und ich so, dass du die Domain bei deinem alten Registar kündigen und zu Netcup unziehen willst. Dabei würden Kosten auflaufen, eine Domain kostet halt. Bei deinem Produkt sind allerdings 12 .de Domains schon inklusive.


    Deinem zweiten Beitrag interpretiere ich so, dass du deine Domains beim bisherigen Registar behalten willst, nur die Webseite soll zu Netcup umziehen. Das nennt Netcup "externe Domains" und bis zu 12 sind in deinem Produkt kostenlos, egal ob DE, ORG, COM, ....


    Doku: https://www.netcup-wiki.de/wiki/Produkte_CCP#Externe_Domains


    Da ich selber keinen Webspace nutze, kann ich nicht weiter ins Detail gehen.

    Keine Sorge. Als ich auf meinen VPS mit der Produktbezeichnung VPS 2000 G8 Plus den weiter oben gemachten Test durchgeführt habe, hat sich mein Server währenddessen eher gelangweilt.

    Du teilst aber nicht nur CPU, sondern auch Festplatte und Netzwerk mit den anderen VPS. Wenn du unnötig Last auf der Festplatte erzeugst, bremst du andere damit aus. Das ist auch der Hintergrund des Posts von Bodenhaltung .


    Ansonsten finde ich, dass netcup etwas Mitschuld trägt. Wenn die zumindest eine grobe Aussage zu IOPS machen würden, wären die vielen Benchmarks überflüssig. So hat man jetzt zumindest einen Anhaltspunkt.

    Netcup hat keinen eigenen DYNDNS-Dienst.


    Prinzipiell gibt es 3 Lösungen:

    1. Du nutzt einen beliebigen DYNDNS-Dienst und setzt einen CNAME für einen Namen in deiner Domain, der auf die DYNDNS-Domain zeigt.
    2. Falls du nicht Netcup als DNS-Registar nutzt, sondern einen externen und dieser externe DNS-Registrar einen DYNDNS anbietet, kannst du den natürlich nutzen.
    3. Selber bauen, schau mal bei https://forum.netcup.de/entwic…12-eigener-dyndns-dienst/ vorbei, da wurde ausführlich diskutiert wie man das macht. Das wird natürlich einiges an Arbeit machen.

    es gibt noch ein paar welche man auf jeden Fall vermeiden sollte,

    sobald via NFS, SMB, CIFS, ... von anderen OS zugegriffen werden soll ...

    Genau, : und \ sind in Unix/Linux zwar erlaubt, haben unter Windows aber eine spezielle Bedeutung.


    Weiterhin sind nicht-druckbare Zeichen zwar erlaubt, ich würde sie aber auch nicht nutzen. Ein Backspace im Dateinamen kann erhebliche Irritationen erzeugen.

    Kleine Ergänzung zum Beitrag von Lukay


    CPU - mOP/s = Mega Operations/sec = Millionen CPU instruktionen/Sekunde

    Festplatte IOPS - OP/s = I/O Operations/sec, getrennt nach Lesen/Schreiben

    Netzwerk PPS - PPS = Pakete/sec, getrennt nach RX(empfangen) / TX (senden)

    Netzwerk Bytes - Bytes pro Messintervall, getrennt nach RX(empfangen) / TX (senden)


    Das Messintervall beträgt je nach dem gewählten Zeitraum:

    6 Stunden: 1 Minute

    24 Stunden: 10 Minuten

    7 Tage: 30 Minuten

    31 Tage: 60 Minuten


    Es wird der Durchschnittswert innerhalb diesen Messintervalls angezeigt. Ausnahme ist "Netzwerk Bytes", da wird die Anzahl der übertragenen Bytes innerhalb des Intervalls angezeigt.


    Alle Werte sind absolute Werte, so dass es schwierig ist, die Werte zu interpretieren. Der CPU-Wert (mOP/s) ist erst einmal ziemlich nichtssagend. Zur Einordnung habe ich bei meinem VPS 200 (1 Core) die CPU auf Maximallast gebracht, das waren 75% (25% waren Steal). Das ergab 716 mOP/s. Also grob geschätzt sind 10 mOP/s etwa 1% CPU-Last auf einem Core.


    Bei "Netzwerk Bytes" ermittelt man die Übertragungsrate in Bit/s durch:

    Bytes/Messintervall * 8 / Messintervall in Sekunden


    Beispiel: 100 MB / Minute ergibt sich also 100.000.000 * 8 / 60 = 13 MBit/s


    Bei den Netzwerk PPS ist ein "Grundrauschen" von 10-20 PPS an empfangenen Paketen normal, das sind hauptsächlich ARP und ND im Netcup-LAN.


    Ansonten nutze ich die aktuellen Werte zum Vergleich mit der Vergangenheit. Damit sehe ich, ob es ungewöhnliche Änderungen gibt, z.B. viele Netz-Anfragen (Netzwerk PPS geht hoch) oder CPU geht hoch ohne dass die Anfragen aus dem Netz entsprechend mehr werden.

    2. BCC-Felder: Wie kann ich erkennen, an welche E-Mail Adresse eine E-Mail ging, wenn ich mehrere E-Mail Adressen einem Postfach zugewiesen habe und die Adresse im BCC-Feld stand?

    Wie schon von Steini beschrieben entfernt der Sender die BCC-Felder, so dass der Empfänger sie nicht mehr sieht. Beim SMTP-Transport muss der Sender aber natürlich dem Empfänger mitteilen, für wen die Mail gedacht ist. Das passiert im "RCPT TO"-Headers des Envelope. Die meisten Mailserver kopieren diese Adresse als Delivered-To in den Mailheader. Daran kannst du also erkennen, an wem die Mail geht, selbst wenn der Sender diesen als BCC eingetragen hat. Evtl. kannst du die Envelope-Informationen auch aus dem Log des Mailserver ermitteln.

    Mein Netcup-Webhosting basiert noch auf Debian-Jessie. Wie in https://wiki.debian.org/LTS/Jessie dokumentiert ist, wird das inklusive dem PHP 5.6 noch bis 30. Juni 2020 von Debian unterstützt. Wann nun Netcup das Betriebssystem des Webhosting updated, weiß vermutlich nur die Glaskugel. Und was beim Update mit PHP 5.6 passieren wird, ist mir zumindest unbekannt. Vermutlich kann man das danach nicht mehr nutzen.


    Wenn du dir einen Root-Server oder vServer zulegst und Debian Jessie installierst hast du zumindest bis Mitte 2020 PHP 5.6 mit Debian-Support. Danach muss du entweder deine Anwendungen updaten, PHP auf eigenes Risiko weiterbetreiben (auf einem dann nicht mehr unterstütztem Betriebssystem) oder eine Firma finden, die PHP 5.6 weiter supported.

    Da der nächste SYN-Flood glücklicherweise auf sich warten lässt, habe ich mit hping3 meinen Server selbst mit SYN-Paketen beschossen. Wie der User "customer" schon mitgeteilt hat, ist Linux ab v4.4 gegen SYN-Attacken gehärtet, nochmals vielen Dank für die Info. Ich habe testweise meinen VPS-200 mit 3500 SYN-Paketen/Sekunde beschossen. Die CPU-Last erhöhte sich marginal um 5-6% und ich konnte weiterhin problemlos mit dem Server arbeiten, als wenn nichts geschehen sei. Also (fast) alles im grünen Bereich.


    Worauf man allerdings achten sollte, ist dass der Server als DDoS-Verstärker dienen kann. Jedes nicht beantwortetes SYN-ACK-Paket wird normalerweise 5 mal wiederholt. Wenn jemand ein SYN-Paket mit einer gefälschten Absende-IP schickt, die den SYN-ACK nicht beantwortet, schickt unser Server sechs SYN-ACK-Pakete. Durch verringern des Kernel-Parameters net.ipv4.tcp_synack_retries kann man die Anzahl der SYN-ACK-Wiederholversuche verringern. Damit verstärkt der Server nicht mehr so stark wie andere Server und wird dadurch weniger interessant. Der Parameter sollte aber auch nicht zu klein sein, sonst werden Paketverluste nicht mehr ausgeglichen.


    Alles was bleibt ist also in einer Konfigurationsdatei in /etc/sysctl.d den Kernel-Parameter net.ipv4.tcp_synack_retries = 2 zu setzen. Meine vorherigen Konfigurationsvorschläge sind glücklicherweise überflüssig.

    elbst Debian oldstable/9/stretch hat da schon einen viel aktuelleren Kernel, deswegen verstehe ich nicht warum das hier empfohlen wird?

    Ganz einfach, ich wusste es nicht besser. Ich habe jetzt erst einmal alle meine Einstellungen rausgenommen und werde den nächsten SYN-Flood abwarten. Wenn sich zeigt, dass man gar nichts machen muss, um so besser.

    Da habe ich doch tatsächlich IPv6 nicht beachtet.


    Die Lösung ist einfach: Ergänzend zu den iptables Kommandos diese durch ip6tables ersetzen und zusätzlich ausführen.


    Alt:

    Code
    1. # Allow only SSH/HTTP/HTTPS from the outside
    2. iptables -t mangle -I PREROUTING 1 -i lo -j ACCEPT
    3. iptables -t mangle -I PREROUTING 2 -p tcp -m multiport \! --dports 22,80,443 -j DROP
    4. ...
    5. # iptables rules for SYNPROXY
    6. iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
    7. iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
    8. iptables -A INPUT -m conntrack --ctstate INVALID -j DROP


    Neu: