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:
# Allow only SSH/HTTP/HTTPS from the outside
iptables -t mangle -I PREROUTING 1 -i lo -j ACCEPT
iptables -t mangle -I PREROUTING 2 -p tcp -m multiport \! --dports 22,80,443 -j DROP
...
# iptables rules for SYNPROXY
iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROPNeu:
# Allow only SSH/HTTP/HTTPS from the outside
iptables -t mangle -I PREROUTING 1 -i lo -j ACCEPT
iptables -t mangle -I PREROUTING 2 -p tcp -m multiport \! --dports 22,80,443 -j DROP
ip6tables -t mangle -I PREROUTING 1 -i lo -j ACCEPT
ipt6ables -t mangle -I PREROUTING 2 -p tcp -m multiport \! --dports 22,80,443 -j DROP
...
# iptables rules for SYNPROXY
iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
ip6tables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
ip6tables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
ip6tables -A INPUT -m conntrack --ctstate INVALID -j DROPHabe den Server mit Debian 10 (Buster) neu aufgesetzt, mit dem default systemd. Meine Konfiguration musste nur in einem Punkt geändert werden.
Ab Linux-Kernel v4.19 gibt's das Modul nf_conntrack_ipv4 nicht mehr, es wird durch nf_conntrack ersetzt. /etc/modules sieht also jetzt so aus:
nf_conntrack/etc/rc.local funktioniert weiterhin, kann also unverändert übernommen werden.
Ich hatte als Idee das ganze auf nftables umzustellen und sauber in systemd zu integrieren. Leider ist das nft_synproxy-Modul erst ab Linux-Kernel v5.3 verfügbar. Da werde ich noch einiges warten müssen, bis das bei Debian stable ankommt.
Wie alt ist denn Dein OS? Wir haben heute bereits Systemd anstelle der Init-Scripte.
Ich nutze Debian 9 (Stretch), werde demnächst auf Debian 10 (Buster) updaten. Beide Versionen bieten den Systemd-Dienst "rc-local", der /etc/rc.local beim Start ausführt. Wie üblich unter Linux gibt's viele andere Wege um zum gleichen Ziel zu gelangen, sicher auch welche die besser in die systemd-Philosophie passen.
Per Zufall habe ich bemerkt, dass auf meinem vServer netstat -tuna viele TCP-Verbindungen im Status SYN_RECV zeigte. Eine Überprüfung mit `tcpdump` zeigte, dass mein Server viele TCP-SYN-Pakete empfing. Mein Server war Ziel einer SYN-Attacke.
Bei der SYN-Attacke werden Verbindungsaufbaupakete (SYN) gesendet, die Bestätigung vom Server (SYN+ACK) wird allerdings nicht beantwortet. Linux wartet normalerweise 60 Sekunden, bis der Verbindungswunsch abgebrochen wird, solange wird sie mit dem Status SYN_RECV in der Tabelle der Netzwerkverbindungen geführt.
Es ergeben sich 2 Angriff-Szenarien:
Bei meiner Recherche bin ich auf das folgende Webseite gestoßen. Sie beschriebt, wie man DDoS-Angriffe auf Linux-Server abwehren kann.
https://javapipe.com/blog/iptables-ddos-protection/
Ich habe mich auf die Abwehr von SYN-Angriff beschränkt und meinen Server entsprechend konfiguriert. Einerseits kommt der Server nun mit erheblich mehr SYN-Paketen/sec klar, andererseits findet kein Verstärkungseffekt mehr statt. Der Server schickt nur noch ein SYN+ACK-Paket pro SYN-Paket.
Damit wurde mein Server anscheinend uninteressant für die Angreifer, nach 2 Wochen war wieder Ruhe.
Es folgt nun die Konfiguration von meinem Debian 9 (Stretch) Server.
Vorweg eine wichtige Warnung:
Nutzung auf eigene Gefahr.
Solche tiefgreifenden Änderungen im System können leicht fatale Folgen haben. Ihr müsst sehr gut verstehen, was die Konfigurationsänderungen bewirken und wie ihr etwaige Probleme selber löst. Weder netcup noch ich können euch da groß unterstützen.
Das Modul nf_conntrack_ipv4 muss frühzeitig geladen werden, damit die Kernel-Parameter für die Firewall gesetzt werden können.
nf_conntrack_ipv4Ich habe mich dazu entschieden, die Kernel-Parameter und die Firewall-Einträge in /etc/rc.local einzutragen.
Die Ports, die von außen erreichbar sein sollen, müssen angepaßt werden. Bei mir sind 22(SSH), 80(HTTP) und 443(HTTPS) erlaubt.
# Allow only SSH/HTTP/HTTPS from the outside
iptables -t mangle -I PREROUTING 1 -i lo -j ACCEPT
iptables -t mangle -I PREROUTING 2 -p tcp -m multiport \! --dports 22,80,443 -j DROP
# Kernel settings for SYNPROXY
sysctl -q -w net.ipv4.tcp_synack_retries=1
sysctl -q -w net.ipv4.tcp_syncookies=1
sysctl -q -w net.ipv4.tcp_timestamps=1
sysctl -q -w net.netfilter.nf_conntrack_max=10000000
sysctl -q -w net.netfilter.nf_conntrack_tcp_loose=0
# iptables rules for SYNPROXY
iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
