Prévenir l'usurpation d'identité IP address à l'aide du filtrage du chemin inverse

Ce message concerne l'administration du système et n'a rien à voir avec Python. Alors pourquoi l'afficher ici ? Parce que je pense qu'il y a beaucoup de gens comme moi qui gèrent un ou plusieurs serveurs web et qui rencontrent parfois ces problèmes.

Dans l'article précédent, j'ai écrit que mon serveur ISPConfig Debian faisait l'objet d'un balayage de ports, etc. et qu'il apparaissait que 95 % de toutes les requêtes provenaient de Chine, à moins que ... ces IP address n'aient été usurpés, bien sûr.

Je n'ai jamais cherché à savoir ce qu'il en était, il y avait parfois des problèmes mais ils ne duraient que peu de temps. Plus récemment, c'est devenu très fréquent, plusieurs fois par jour. J'ai dû creuser et il s'est avéré que la vérification de l'adresse source n'était PAS activée pour mon serveur. Cela signifie également que des IP addresses tout à fait normaux et usurpés sont (temporairement) bloqués par fail2ban, ce qui est le contraire de ce que nous voulons !

Pourquoi ces tutoriels d'installation ne vous disent-ils jamais cela ? Ou est-ce que c'est TL;DR ? Après avoir activé la vérification de l'adresse source, le nombre de IP addresses du scanner de port a chuté de façon spectaculaire, et je n'ai plus vu de IP address en provenance de Chine. Cela signifie que les pirates, ou plutôt les script kiddies, abusent des IP addresses des entreprises chinoises pour leurs activités criminelles.

Quoi qu'il en soit, j'écris ci-dessous les premières étapes de ce que j'ai fait, tout est également sur internet bien sûr, voir les liens à la fin de ce post.

Mon serveur est un VPS connecté à l'internet via les routeurs de mon hébergeur. Il utilise Debian 11 (Bullseye), ISPConfig, et est connecté à l'internet en utilisant une seule ipv4 IP address. Cela signifie que les instructions ci-dessous ne concernent que l'ipv4. Vous pouvez également ignorer tout cela si vous avez un hébergeur qui a déjà mis en place toutes ces protections pour vous.

Empêcher l'usurpation de IP address en utilisant le filtrage de chemin inverse

Il existe plusieurs types d'usurpation de IP address . La première étape consiste à rejeter les paquets provenant de IP addresses qui ne sont pas routables. La vérification de l'adresse source est disponible sur les serveurs Linux en tant que filtrage du chemin inverse. Celui-ci est contrôlé par le paramètre 'rp_filter' du noyau. Vous pouvez définir les paramètres du noyau dans le fichier :

/etc/sysctl.conf

Vous pouvez les définir à l'aide d'une commande, par exemple :

sysctl -w 'net.ipv4.ip_forward=1'

Pour vérifier les paramètres actuels, nous pouvons utiliser la commande 'sysctl' et filtrer le paramètre. Exemple :

sysctl -ar '\.rp_filter'

Résultat :

net.ipv4.conf.all.rp_filter = 0
...
net.ipv4.conf.default.rp_filter = 0
...
net.ipv4.conf.eth0.rp_filter = 0
...

Ces valeurs peuvent être trouvées dans les fichiers du répertoire /proc/sys, par exemple :

cat /proc/sys/net/ipv4/conf/eth0/rp_filter

Notez les valeurs 'all', 'default' et 'eth0'. La valeur 'default' est utilisée pour les nouvelles interfaces.

Important : ces valeurs sont parfois AND-ed, parfois OR-ed, parfois la valeur maximale est utilisée. Ceci est spécifié dans le document '/proc/sys/net/ipv4/* Variables', voir les liens ci-dessous. Si vous ne suivez pas ce document, certains paramètres ne fonctionneront pas, ou vous risquez de désactiver ou d'activer un paramètre par accident !

Pendant que nous y sommes, nous définissons également d'autres paramètres du noyau, voir le document '4.18. Sécurisation de l'accès au réseau', voir les liens ci-dessous. J'ai ajouté les lignes suivantes au fichier :

/etc/sysctl.conf

Et je n'ai modifié que les paramètres de l'interface 'eth0' !

...

# 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

Voici les notes sur les paramètres du noyau utilisés :

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)

Après avoir effectué les changements, nous les chargeons en utilisant :

sysctl -p

Nous avons également activé la journalisation des paquets martiens, c'est-à-dire des paquets dont l'adresse source est manifestement erronée, car il n'est pas possible d'acheminer le trafic vers cette adresse. Pour voir ces loglines :

grep martian /var/log/messages

Résultat :

...
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

Prochaines étapes

Ce qui précède n'est qu'une première étape dans le renforcement de votre serveur contre toutes sortes d'attaques. Par exemple, dans le document "DDoS Protection With IPtables : The Ultimate Guide" (voir les liens ci-dessous), d'autres mesures sont décrites.

Vérifiez vos journaux

Une autre chose que vous devriez faire est de vérifier vos journaux ! De mauvais services ou des services mal configurés peuvent causer toutes sortes de problèmes, y compris rendre votre serveur plus vulnérable. Comment ces choses peuvent-elles se produire ? Par exemple, vous passez à une nouvelle version de Debian. Cela peut interrompre certains services ou les laisser dans un mauvais état, même si votre serveur semble fonctionner correctement.

En vérifiant /var/log/syslog, j'ai trouvé des lignes comme (j'ai remplacé le IP addresses etc.) :

...
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
...

Je n'ai jamais vu cela auparavant. Il peut s'agir de spammeurs qui envoient des courriels à mon serveur et les marquent comme provenant de faux domaines. Il semble que leur nombre ait considérablement diminué après avoir activé le filtrage des chemins inversés. Il faudra que je me penche sur ce point un des prochains jours.

Script de surveillance simple

Je voulais voir ce qui se passe minute par minute et j'ai créé ce petit script qui envoie quelques informations de base dans un fichier en utilisant quelques utilitaires de ligne de commande Linux :

#!/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}"

Après avoir ajouté ce script à CRON, le fichier journal ressemblera à ceci :

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 

Résumé

Cela a pris du temps. Il est devenu extrêmement important de protéger votre serveur contre les attaques, car Internet n'est PAS un endroit sûr. Je sais que l'administration de systèmes est très difficile et je respecte les personnes qui s'en chargent. Mais je suis ici, un programmeur qui fait tourner un VPS, qui est connecté à l'internet, lui-même, donc j'ai besoin de connaître certaines de ces choses. Ce n'est pas une perte de temps d'apprendre cela, mais des connaissances essentielles lorsque vous avez des serveurs connectés à l'internet.

L'utilisation du paramètre kernel rp_filter pour activer le filtrage des chemins inversés n'a pas été difficile, et j'ai également modifié quelques paramètres parce que le serveur n'est pas un routeur. Le résultat a été étonnant : il n'y a presque plus de scanners de ports. De plus, en regardant à nouveau les journaux, j'ai remarqué quelque chose qui n'était pas là avant, je dois examiner cela.

Notez que si quelqu'un veut vraiment faire tomber votre serveur, il n'y a pas grand-chose que vous puissiez faire, si ce n'est passer à un réseau protégé contre les attaques DDoS. Créer est difficile, détruire est facile.

Liens / crédits

/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