Verhinderung von IP address -Spoofing mit Reverse Path Filtering

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