IP address spoofing voorkomen met omgekeerde padfiltering

Deze post gaat over systeembeheer en heeft niets te maken met Python. Waarom dit dan hier posten? Omdat ik denk dat er velen zijn die net als ik een of meer webservers draaien en soms tegen deze problemen aanlopen.

In de vorige post schreef ik dat mijn ISPConfig Debian server onderhevig was aan port scanning, etc. en dat het bleek dat 95% van alle requests uit China kwamen, tenzij ... deze IP address's natuurlijk gespoofed waren.

Ik heb hier nooit naar gekeken, er waren soms problemen maar die duurden maar kort. Recenter werd het heel frequent, meerdere keren per dag. Ik moest graven en het bleek dat verificatie van bronadressen NIET was ingeschakeld voor mijn server. Dit betekent ook dat misschien volledig normale, gespoofde IP addresses (tijdelijk) worden geblokkeerd door fail2ban, het tegenovergestelde van wat we willen!

Waarom vertellen deze installatie tutorials je dit nooit? Of is het TL;DR? Nadat ik bronadresverificatie had ingeschakeld, daalde het aantal IP address's van de poortscanner drastisch en ik zag geen IP address 's meer uit China. Dit betekent dat hackers, of moet ik ze scriptkiddies noemen, IP address's van Chinese bedrijven misbruiken voor hun criminele activiteiten.

Hoe dan ook, hieronder schrijf ik de eerste stappen op van wat ik heb gedaan, alles staat natuurlijk ook op het internet, zie de links aan het einde van dit bericht.

Mijn server is een VPS die verbonden is met het internet via de routers van mijn hoster. Het draait Debian 11 (Bullseye), ISPConfig, en is verbonden met het internet via een enkele ipv4 IP address. Dit betekent dat de onderstaande instructies alleen voor ipv4 gelden. En je kunt dit ook allemaal overslaan als je een hoster hebt die al deze beveiligingen al voor je heeft geïmplementeerd.

IP address spoofing voorkomen met omgekeerde padfiltering

Er zijn verschillende soorten IP address spoofing. De eerste stap is pakketten te laten vallen van IP addresses die niet routeerbaar zijn. Bronadresverificatie is beschikbaar op Linux servers als omgekeerde padfiltering. Dit wordt geregeld door kernelparameter 'rp_filter'. Je kunt kernelparameters instellen in het bestand:

/etc/sysctl.conf

Je kunt ze instellen met een commando, bijvoorbeeld:

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

Om de huidige instellingen te controleren, kunnen we het 'sysctl' commando gebruiken en de parameter filteren. Voorbeeld:

sysctl -ar '\.rp_filter'

Resultaat:

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

Deze waarden zijn te vinden in bestanden de directory /proc/sys, bijvoorbeeld:

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

Let op de 'all', 'default' en 'eth0'. 'default' wordt gebruikt voor nieuwe interfaces.

Belangrijk: Deze waarden worden soms AND-ed, soms OR-ed, soms wordt de maximale waarde gebruikt. Dit wordt gespecificeerd in het document '/proc/sys/net/ipv4/* Variables', zie onderstaande koppelingen. Als je dit document niet volgt, zullen sommige parameters niet werken, of kun je een instelling per ongeluk uitschakelen of inschakelen!

Nu we toch bezig zijn, stellen we ook enkele andere kernelparameters in, zie het document '4.18. Beveiligen van netwerktoegang', zie onderstaande links. Ik heb de volgende regels toegevoegd aan het bestand:

/etc/sysctl.conf

En ik veranderde alleen de instellingen voor de 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

Hier zijn de opmerkingen over de gebruikte kernelparameters:

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)

Nadat we de wijzigingen hebben aangebracht, laden we ze met:

sysctl -p

We hebben ook het loggen van martiaanse pakketten ingeschakeld, dat wil zeggen pakketten met een bronadres dat duidelijk fout is, het is niet mogelijk om terug te routeren naar dat adres. Om deze loglines te zien:

grep martian /var/log/messages

Resultaat:

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

Volgende stappen

Het bovenstaande is slechts een eerste stap in het hardenen van je server tegen allerlei aanvallen. Bijvoorbeeld in het document 'DDoS Protection With IPtables: The Ultimate Guide', zie onderstaande links, worden nog veel meer maatregelen beschreven.

Controleer je logs

Andere dingen die je moet doen is je logs controleren! Slechte of verkeerd geconfigureerde services kunnen allerlei problemen veroorzaken, waaronder het kwetsbaarder maken van je server. Hoe kunnen deze dingen gebeuren? Nou, bijvoorbeeld je upgrade naar een nieuwe versie van Debian. Dit kan sommige services breken of in een slechte staat achterlaten, zelfs als je server goed lijkt te draaien.

Bij het controleren van /var/log/syslog vond ik regels als (Ik heb de IP addresses etc. vervangen):

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

Nooit eerder gezien. Kunnen spammers zijn die e-mail naar mijn server sturen en deze markeren als afkomstig van nepdomeinen. Het lijkt erop dat hun aantal aanzienlijk is afgenomen nadat ik Reverse Path Filtering heb ingeschakeld. Hier moet ik de komende dagen naar kijken.

Eenvoudig monitorscript

Ik wilde van minuut tot minuut zien wat er gebeurde en maakte dit kleine script dat wat basisinformatie naar een bestand stuurt met behulp van enkele Linux commandoregelhulpprogramma's:

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

Nadat je dit script aan CRON hebt toegevoegd ziet het logbestand er als volgt uit:

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 

Samenvatting

Dit heeft tijd gekost. Het harden van je server tegen aanvallen is extreem belangrijk geworden, het internet is GEEN veilige plek. Ik weet dat systeembeheer erg moeilijk is en respecteer de mensen die dit doen. Maar hier ben ik dan, een programmeur die zelf een VPS beheert die verbonden is met het internet, dus ik moet een aantal van deze dingen weten. Geen tijdverspilling om dit te leren, maar essentiële kennis als je servers hebt die verbonden zijn met het internet.

Het was niet moeilijk om de kernelparameterinstelling rp_filter te gebruiken om Reverse Path Filtering in te schakelen, en ik veranderde ook een paar parameters omdat de server geen router is. Het resultaat was verbluffend, bijna geen poortscanners meer. Daarnaast zag ik door nog eens in de logs te kijken iets dat er eerder niet was, ik moet hier nog naar kijken.

Merk op dat als iemand echt je server wil uitschakelen, je niet veel kunt doen behalve verhuizen naar een DDoS-beveiligd netwerk. Creëren is moeilijk, vernietigen is makkelijk.

Links / credits

/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