Verhinderung von IP address -Spoofing mit Reverse Path Filtering
Das Setzen des Kernelparameters rp_filter=1 verhindert auch, dass fail2ban legitime IP addresses blockiert.
Dieser Beitrag handelt von der Systemverwaltung und hat nichts mit Python zu tun. Warum posten Sie ihn dann hier? Weil ich glaube, dass es viele wie mich gibt, die einen oder mehrere Webserver betreiben und irgendwann auf diese Probleme stoßen.
Im vorigen Beitrag habe ich geschrieben, dass mein ISPConfig Debian -Server einem Port-Scanning unterzogen wurde usw. und dass anscheinend 95% aller Anfragen aus China kamen, es sei denn ... diese IP addresses waren natürlich gefälscht.
Ich habe mir das nie angeschaut, manchmal gab es Probleme, aber die dauerten nur kurz an. In letzter Zeit traten sie sehr häufig auf, etwa mehrmals am Tag. Ich musste nachforschen und es stellte sich heraus, dass die Überprüfung der Quelladresse für meinen Server NICHT aktiviert war. Das bedeutet auch, dass vielleicht ganz normale, gefälschte IP addresses (vorübergehend) von fail2ban blockiert werden, das Gegenteil von dem, was wir wollen!
Warum wird das in den Installationsanleitungen nie gesagt? Oder ist es TL;DR? Nachdem ich die Überprüfung der Quelladresse aktiviert hatte, sank die Anzahl der Portscanner IP addresses drastisch, und ich sah keine IP address es aus China mehr. Das bedeutet, dass Hacker, oder sollte ich sie Skript-Kiddies nennen, IP addresses von chinesischen Unternehmen für ihre kriminellen Aktivitäten missbrauchen.
Wie auch immer, unten schreibe ich die ersten Schritte auf, die ich gemacht habe, alles ist natürlich auch im Internet zu finden, siehe Links am Ende dieses Beitrags.
Mein Server ist ein VPS, der über die Router meines Hosters mit dem Internet verbunden ist. Es läuft Debian 11 (Bullseye), ISPConfig, und ist mit dem Internet über eine einzelne ipv4 IP address verbunden. Das bedeutet, dass die folgenden Anweisungen nur für ipv4 gelten. Und Sie können das alles auch überspringen, wenn Sie einen Hoster haben, der all diese Schutzmaßnahmen bereits für Sie implementiert hat.
Verhindern Sie IP address -Spoofing mit Reverse Path Filtering
Es gibt mehrere Arten von IP address -Spoofing. Der erste Schritt ist das Verwerfen von Paketen von IP addresses, die nicht routbar sind. Die Überprüfung der Quelladresse ist auf Linux -Servern als Reverse Path Filtering verfügbar. Dies wird durch den Kernel-Parameter 'rp_filter' gesteuert. Sie können Kernel-Parameter in der Datei einstellen:
/etc/sysctl.conf
Sie können sie z. B. mit einem Befehl setzen:
sysctl -w 'net.ipv4.ip_forward=1'
Um die aktuellen Einstellungen zu überprüfen, können wir den Befehl 'sysctl' verwenden und den Parameter filtern. Beispiel:
sysctl -ar '\.rp_filter'
Ergebnis:
net.ipv4.conf.all.rp_filter = 0
...
net.ipv4.conf.default.rp_filter = 0
...
net.ipv4.conf.eth0.rp_filter = 0
...
Diese Werte sind z. B. in Dateien im Verzeichnis /proc/sys zu finden:
cat /proc/sys/net/ipv4/conf/eth0/rp_filter
Beachten Sie den 'all', 'default' und 'eth0'. default' wird für neue Schnittstellen verwendet.
Wichtig: Diese Werte werden manchmal UND-verknüpft, manchmal ODER-verknüpft, manchmal wird der Maximalwert verwendet. Dies wird in dem Dokument '/proc/sys/net/ipv4/* Variables' beschrieben, siehe Links unten. Wenn Sie sich nicht an dieses Dokument halten, werden einige Parameter nicht funktionieren, oder Sie können eine Einstellung versehentlich deaktivieren oder aktivieren!
Wenn wir schon dabei sind, setzen wir auch einige andere Kernelparameter, siehe das Dokument '4.18. Absicherung des Netzwerkzugangs', siehe Links unten. Ich habe die folgenden Zeilen in die Datei eingefügt:
/etc/sysctl.conf
Und ich habe nur die Einstellungen für die Schnittstelle 'eth0' geändert!
...
# Ignore ICMP broadcasts
net/ipv4/icmp_echo_ignore_broadcasts = 1
# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
# Turn on Source Address Verification to prevent some spoofing attacks
net.ipv4.conf.eth0.rp_filter = 1
# Log Martians
net.ipv4.conf.eth0.log_martians = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Do not accept IP source route packets (we are not a router)
net.ipv4.conf.eth0.accept_source_route = 0
Hier sind die Hinweise zu den verwendeten Kernel-Parametern:
accept_redirects - BOOLEAN
Accept ICMP redirect messages.
accept_redirects for the interface will be enabled if:
- both conf/{all,interface}/accept_redirects are TRUE in the case
forwarding for the interface is enabled
or
- at least one of conf/{all,interface}/accept_redirects is TRUE in the
case forwarding for the interface is disabled
accept_redirects for the interface will be disabled otherwise
default TRUE (host)
FALSE (router)
send_redirects - BOOLEAN
Send redirects, if router.
send_redirects for the interface will be enabled if at least one of
conf/{all,interface}/send_redirects is set to TRUE,
it will be disabled otherwise
Default: TRUE
rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
is not the best reverse path the packet check will fail.
By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against the FIB
and if the source address is not reachable via any interface
the packet check will fail.
Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.
The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.
Default value is 0. Note that some distributions enable it
in startup scripts.
log_martians - BOOLEAN
Log packets with impossible addresses to kernel log.
log_martians for the interface will be enabled if at least one of
conf/{all,interface}/log_martians is set to TRUE,
it will be disabled otherwise
accept_source_route - BOOLEAN
Accept packets with SRR option.
conf/all/accept_source_route must also be set to TRUE to accept packets
with SRR option on the interface
default TRUE (router)
FALSE (host)
Nachdem wir die Änderungen vorgenommen haben, laden wir sie mit:
sysctl -p
Wir haben auch das Logging von Martian-Paketen aktiviert, d.h. von Paketen mit einer offensichtlich falschen Quelladresse, zu der es nicht möglich ist, zurück zu routen. Um diese Logzeilen zu sehen:
grep martian /var/log/messages
Ergebnis:
...
Jun 14 15:52:53 <server> kernel: [ 3.742674] IPv4: martian source <dst-ip-address> from <src-ip-address>, on dev eth0
Jun 14 15:52:53 <server> kernel: [ 3.743462] IPv4: martian source <dst-ip-address> from <src-ip-address>, on dev eth0
Jun 14 15:52:53 <server> kernel: [ 3.743468] IPv4: martian source <dst-ip-address> from <src-ip-address>, on dev eth0
Nächste Schritte
Die obigen Maßnahmen sind nur ein erster Schritt, um Ihren Server gegen alle Arten von Angriffen abzusichern. In dem Dokument 'DDoS Protection With IPtables: The Ultimate Guide', siehe Links unten, werden noch viel mehr Maßnahmen beschrieben.
Prüfen Sie Ihre Logs
Außerdem sollten Sie Ihre Protokolle überprüfen! Schlechte oder falsch konfigurierte Dienste können alle möglichen Probleme verursachen und Ihren Server anfälliger machen. Wie kann so etwas passieren? Nun, wenn Sie zum Beispiel auf eine neue Version von Debian aktualisieren. Dies kann dazu führen, dass einige Dienste nicht mehr funktionieren oder in einem schlechten Zustand sind, auch wenn Ihr Server scheinbar einwandfrei läuft.
Bei der Überprüfung von /var/log/syslog habe ich Zeilen wie (I replaced the IP addresses etc.) gefunden:
...
Jun 14 10:23:33 server123 named[743]: REFUSED unexpected RCODE resolving 'iwnde.ro/MX/IN': 198.51.100.167#53
Jun 14 10:39:04 server123 named[743]: REFUSED unexpected RCODE resolving '203.0.113.183.in-addr.arpa/PTR/IN': 198.51.100.12#53
...
Das habe ich noch nie gesehen. Es kann sich um Spammer handeln, die E-Mails an meinen Server senden und sie als von gefälschten Domänen stammend markieren. Es sieht so aus, als ob ihre Anzahl nach dem Einschalten der Umkehrpfadfilterung deutlich zurückgegangen ist. Ich werde mir das in den nächsten Tagen ansehen.
Einfaches Monitor-Skript
Ich wollte sehen, was im Minutentakt passiert, und habe dieses kleine Skript erstellt, das mit Hilfe einiger Linux -Befehlszeilendienstprogramme einige grundlegende Informationen in eine Datei ausgibt:
#!/bin/bash
# syslpcm.sh
# Append system information to logfile
# - l oad averages
# - p rocess count
# - c onnection count
# - m emory available / swap free
#
# add these two lines to (root) cron to run every minute:
# # syslpcm
# * * * * * /root/syslpcm.sh
LOGDIR=/root
LOGFILE=${LOGDIR}/syslcpm.log
load_averages=$(uptime | awk -F'[a-z]:' '{ print $2}')
processes_count=$(ps -e | wc -l)
connections_count=$(netstat -an | wc -l)
mem_available=$(awk '/MemAvailable/ { printf "%.3f \n", $2/1024/1024 }' /proc/meminfo)
swap_free=$(awk '/SwapFree/ { printf "%.3f \n", $2/1024/1024 }' /proc/meminfo)
dt=`date "+%Y-%m-%d %H:%M:%S"`
progress_message="${dt} load avgs: ${load_averages} procs: ${processes_count} cons: ${connections_count} mem_avail: ${mem_available} swap_free: ${swap_free}"
echo "${progress_message}" >> "${LOGFILE}"
Nachdem Sie dieses Skript zu CRON hinzugefügt haben, wird die Logdatei wie folgt aussehen:
2023-06-14 17:14:01 load avgs: 1.07, 0.98, 1.04 procs: 447 cons: 1252 mem_avail: 1.744 swap_free: 3.596
2023-06-14 17:15:17 load avgs: 1.28, 1.05, 1.06 procs: 451 cons: 1342 mem_avail: 1.731 swap_free: 3.430
2023-06-14 17:16:01 load avgs: 12.59, 4.66, 2.32 procs: 446 cons: 1326 mem_avail: 1.900 swap_free: 3.376
2023-06-14 17:17:01 load avgs: 5.76, 4.13, 2.28 procs: 442 cons: 1272 mem_avail: 2.004 swap_free: 3.323
2023-06-14 17:18:01 load avgs: 3.29, 3.69, 2.24 procs: 443 cons: 1333 mem_avail: 2.110 swap_free: 3.175
2023-06-14 17:19:02 load avgs: 2.13, 3.25, 2.18 procs: 437 cons: 1381 mem_avail: 2.348 swap_free: 3.160
2023-06-14 17:20:01 load avgs: 1.13, 2.75, 2.07 procs: 442 cons: 1297 mem_avail: 2.338 swap_free: 3.160
2023-06-14 17:21:01 load avgs: 0.51, 2.28, 1.95 procs: 441 cons: 1301 mem_avail: 2.333 swap_free: 3.138
2023-06-14 17:22:02 load avgs: 0.50, 1.96, 1.86 procs: 440 cons: 1323 mem_avail: 2.233 swap_free: 3.139
Zusammenfassung
Das hat Zeit gekostet. Die Absicherung Ihres Servers gegen Angriffe ist extrem wichtig geworden, das Internet ist KEIN sicherer Ort. Ich weiß, dass Systemadministration sehr schwierig ist und respektiere die Leute, die das tun. Aber hier bin ich, ein Programmierer, der selbst einen VPS betreibt, der mit dem Internet verbunden ist, also muss ich einige dieser Dinge wissen. Es ist keine Zeitverschwendung, dies zu lernen, sondern essentielles Wissen, wenn man Server hat, die mit dem Internet verbunden sind.
Die Kernel-Parametereinstellung rp_filter zu verwenden, um die Filterung des umgekehrten Pfades zu aktivieren, war nicht schwierig, und ich änderte auch ein paar Parameter, da der Server kein Router ist. Das Ergebnis war verblüffend: fast keine Port-Scanner mehr. Außerdem ist mir bei einem erneuten Blick in die Logs etwas aufgefallen, was vorher nicht da war, dem muss ich nachgehen.
Beachten Sie, dass Sie nicht viel tun können, außer in ein DDoS-geschütztes Netzwerk umzuziehen, wenn jemand Ihren Server wirklich ausschalten will. Erstellen ist schwer, zerstören ist leicht.
Links / Impressum
/proc/sys/net/ipv4/* Variables
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
/proc/sys/net/ipv4/* Variables (other link)
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/networking/ip-sysctl.txt?h=linux-4.15.y
40 Linux Server Hardening Security Tips [2023 edition]
https://www.cyberciti.biz/tips/linux-security.html
DDoS Deflate
https://github.com/jgmdev/ddos-deflate
DDoS Protection With IPtables: The Ultimate Guide
https://javapipe.com/blog/iptables-ddos-protection
Don’t Get Swept Away: The Most Common DDoS Attacks are SYN and UDP Floods
https://www.masterdc.com/blog/how-ddos-attack-work-types-of-ddos-syn-udp-floods
How to Disable ICMP Redirects in Linux for security (Redhat,Debian,Ubuntu,SuSe tested)
https://www.itsyourip.com/Security/how-to-disable-icmp-redirects-in-linux-for-security-redhatdebianubuntususe-tested/
How to interpret Linux martian source messages
https://www.thegeekdiary.com/how-to-interpret-linux-martian-source-messages
How to protect my Ubuntu server ?
https://medium.com/@d_danailov/how-to-protect-my-ubuntu-server-6a2ecc056722
IP Spoofing
https://www.imperva.com/learn/ddos/ip-spoofing
Ispconfig 3 - DDOS attack mitigation
https://forum.howtoforge.com/threads/ispconfig-3-ddos-attack-mitigation.82316
rp_filter and LPIC-3 Linux Security
https://www.theurbanpenguin.com/rp_filter-and-lpic-3-linux-security
Securing Debian Manual - 4.18. Securing network access
https://www.debian.org/doc/manuals/securing-debian-manual/network-secure.en.html
What is IP Spoofing? Types of IP Spoofing
https://www.interserver.net/tips/kb/ip-spoofing-types-ip-spoofing
What is IP Spoofing? Types of IP Spoofing
https://www.interserver.net/tips/kb/ip-spoofing-types-ip-spoofing
What is the difference between "all", "default" and "eth*" in /proc/sys/net/ipv[46]/conf/?
https://unix.stackexchange.com/questions/90443/what-is-the-difference-between-all-default-and-eth-in-proc-sys-net-ipv
Neueste
- Ausblenden der Primärschlüssel der Datenbank UUID Ihrer Webanwendung
- Don't Repeat Yourself (DRY) mit Jinja2
- SQLAlchemy, PostgreSQL, maximale Anzahl von Zeilen pro user
- Anzeige der Werte in den dynamischen Filtern SQLAlchemy
- Sichere Datenübertragung mit Public Key Verschlüsselung und pyNaCl
- rqlite: eine hochverfügbare und distverteilte SQLite -Alternative
Meistgesehen
- Verwendung von Pythons pyOpenSSL zur Überprüfung von SSL-Zertifikaten, die von einem Host heruntergeladen wurden
- Verwendung von UUIDs anstelle von Integer Autoincrement Primary Keys mit SQLAlchemy und MariaDb
- Verbindung zu einem Dienst auf einem Docker -Host von einem Docker -Container aus
- PyInstaller und Cython verwenden, um eine ausführbare Python-Datei zu erstellen
- SQLAlchemy: Verwendung von Cascade Deletes zum Löschen verwandter Objekte
- Flask RESTful API Validierung von Anfrageparametern mit Marshmallow-Schemas