Prevención de la suplantación de identidad IP address mediante el filtrado de ruta inversa

Este post es sobre administración de sistemas y no tiene nada que ver con Python. Entonces, ¿por qué publicar esto aquí? Porque creo que hay muchos como yo que tienen uno o más servidores web y a veces se encuentran con estos problemas.

En el post anterior escribí que mi servidor ISPConfig Debian fue objeto de escaneo de puertos, etc y que parecía que el 95% de todas las solicitudes procedían de China a menos que ... estos IP addresses fueron suplantados por supuesto.

Nunca miré en esto, hubo problemas a veces, pero duró poco tiempo. Más recientemente, se hizo muy frecuente, como varias veces al día. Tuve que investigar y parecía que la verificación de la dirección de origen NO estaba activada para mi servidor. Esto también significa que tal vez completamente normal, IP addresses suplantados son (temporalmente) bloqueados por fail2ban, ¡lo contrario de lo que queremos!

Ahora, ¿por qué estos tutoriales de instalación nunca te dicen esto? ¿O es TL;DR? Después de activar la verificación de la dirección de origen, el número de escáneres de puertos IP addresses disminuyó drásticamente, y ya no vi ningún IP address de China. Esto significa que los hackers, o debería llamarlos script kiddies, abusan de IP addresses de empresas chinas, para sus actividades delictivas.

En fin, a continuación escribo los primeros pasos de lo que hice, todo está también en internet por supuesto, ver enlaces al final de este post.

Mi servidor es un VPS conectado a internet a través de los routers de mi hoster. Se ejecuta Debian 11 (Bullseye), ISPConfig, y está conectado a Internet utilizando un único ipv4 IP address. Esto significa que las instrucciones a continuación son sólo para ipv4. Y también puedes saltarte todo esto si tienes un hoster que ya ha implementado todas estas protecciones por ti.

Prevenir IP address spoofing usando Filtrado de ruta inversa

Hay varios tipos de IP address spoofing. El primer paso es descartar paquetes de IP addresses que no son enrutables. La verificación de la dirección de origen está disponible en los servidores Linux como filtrado de ruta inversa. Esto es controlado por el parámetro del kernel 'rp_filter'. Puede configurar los parámetros del kernel en el archivo:

/etc/sysctl.conf

Puede establecerlos usando un comando, ejemplo:

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

Para comprobar la configuración actual, podemos utilizar el comando 'sysctl' y filtrar el parámetro. Ejemplo:

sysctl -ar '\.rp_filter'

Resultado:

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

Estos valores se pueden encontrar en los archivos del directorio /proc/sys, por ejemplo:

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

Observe 'all', 'default' y 'eth0'. 'default' se utiliza para las nuevas interfaces.

Importante: Estos valores son a veces AND-ed, a veces OR-ed, a veces se utiliza el valor máximo. Esto se especifica en el documento '/proc/sys/net/ipv4/* Variables', ver enlaces más abajo. Si no sigues este documento, algunos parámetros no funcionarán, o puedes desactivar o activar un parámetro accidentalmente.

Mientras estamos en ello, también configuramos algunos otros parámetros del kernel, ver el documento '4.18. Securing network access', ver enlaces más abajo. He añadido las siguientes líneas al archivo:

/etc/sysctl.conf

¡Y he cambiado sólo la configuración de la interfaz '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

Aquí están las notas sobre los parámetros del kernel utilizados:

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)

Después de hacer los cambios, los cargamos usando:

sysctl -p

También hemos habilitado el registro de paquetes marcianos, es decir, paquetes con una dirección de origen que es obviamente errónea, no es posible enrutar de vuelta a esa dirección. Para ver estos loglines:

grep martian /var/log/messages

Resultado:

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

Próximos pasos

Lo anterior es sólo un primer paso para reforzar su servidor contra todo tipo de ataques. Por ejemplo, en el documento 'DDoS Protection With IPtables: The Ultimate Guide', ver enlaces más abajo, se describen muchas más medidas.

Compruebe sus registros

Otra cosa que deberías hacer es comprobar tus registros. Los servicios mal configurados o defectuosos pueden causar todo tipo de problemas, incluso hacer que tu servidor sea más vulnerable. ¿Cómo pueden ocurrir estas cosas? Bueno, por ejemplo actualizas a una nueva versión de Debian. Esto puede romper algunos servicios o dejarlos en mal estado, incluso si su servidor parece funcionar bien.

Revisando /var/log/syslog, encontré líneas como (reemplacé el 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
...

Nunca había visto esto antes. Pueden ser spammers enviando correos a mi servidor y marcarlos como procedentes de dominios falsos. Parece que su número disminuyó significativamente después de activar el filtrado de ruta inversa. Tendré que investigar esto uno de los próximos días.

Simple script de monitorización

Quería ver lo que ocurre minuto a minuto y creé este pequeño script que envía información básica a un archivo utilizando algunas utilidades de línea de comandos 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}"

Después de añadir este script a CRON el archivo de registro tendrá el siguiente aspecto:

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 

Resumen

Esto llevó tiempo. Endurecer tu servidor contra ataques se ha vuelto extremadamente importante, internet NO es un lugar seguro. Sé que la administración de sistemas es muy difícil y respeto a la gente que hace esto. Pero aquí estoy, un programador que ejecuta un VPS, que está conectado a Internet, él mismo, así que necesito saber algunas de estas cosas. No es una pérdida de tiempo para aprender esto, pero el conocimiento esencial cuando se tiene servidores conectados a Internet.

Usar la configuración de parámetros del kernel rp_filter para habilitar el filtrado de ruta inversa no fue difícil, y también cambié algunos parámetros porque el servidor no es un router. El resultado fue sorprendente, casi no más escáneres de puertos. Además, mirando de nuevo en los registros me di cuenta de algo que no estaba allí antes, tienen que mirar en esto.

Ten en cuenta que si alguien realmente quiere tumbar tu servidor, no hay mucho que puedas hacer excepto mudarte a una red protegida contra DDoS. Crear es difícil, destruir es fácil.

Enlaces / créditos

/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