Предотвращение спуфинга IP address с помощью фильтрации обратного пути

Этот пост посвящен системному администрированию и не имеет никакого отношения к Python. Тогда зачем размещать это здесь? Потому что я думаю, что многие, как и я, управляют одним или несколькими веб-серверами и иногда сталкиваются с этими проблемами.

В предыдущем посте я писал, что мой сервер ISPConfig Debian подвергался сканированию портов и т.д. и что оказалось, что 95% всех запросов приходили из Китая, если ... эти IP address не были подделаны, конечно.

Я никогда не исследовал это, иногда возникали проблемы, но они длились недолго. В последнее время это стало происходить очень часто, по несколько раз в день. Мне пришлось покопаться, и оказалось, что проверка адреса источника НЕ была включена для моего сервера. Это также означает, что, возможно, совершенно нормальные, поддельные IP addresses (временно) блокируются fail2ban, что противоположно тому, чего мы хотим!

Почему эти руководства по установке никогда не говорят вам об этом? Или это TL;DR? После того, как я включил проверку адреса источника, количество портовых сканеров IP address резко снизилось, и я больше не видел ни одного IP address из Китая. Это означает, что хакеры, или лучше назвать их скриптовыми детьми, используют IP addresses от китайских компаний для своей преступной деятельности.

В любом случае, ниже я описываю первые шаги того, что я сделал, все также есть в интернете, конечно, смотрите ссылки в конце этого сообщения.

Мой сервер - это VPS, подключенный к интернету через роутеры моего хостера. Он работает под управлением Debian 11 (Bullseye), ISPConfig, и подключен к интернету через один ipv4 IP address. Это означает, что приведенные ниже инструкции предназначены только для ipv4. И вы также можете пропустить все это, если у вас есть хостер, который уже реализовал все эти защиты для вас.

Предотвращение подмены IP address с помощью фильтрации обратного пути

Существует несколько типов подделки IP address . Первый шаг - отбрасывание пакетов от IP address, которые не подлежат маршрутизации. Проверка адреса источника доступна на серверах Linux как фильтрация обратного пути. Это контролируется параметром ядра 'rp_filter'. Вы можете установить параметры ядра в файле:

/etc/sysctl.conf

Вы можете установить их с помощью команды, например:

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

Чтобы проверить текущие настройки, мы можем использовать команду 'sysctl' и отфильтровать параметр. Пример:

sysctl -ar '\.rp_filter'

Результат:

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

Эти значения можно найти в файлах каталога /proc/sys, например:

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

Обратите внимание на 'all', 'default' и 'eth0'. 'default' используется для новых интерфейсов.

Важно: Эти значения иногда AND-ed, иногда OR-ed, иногда используется максимальное значение. Это указано в документе '/proc/sys/net/ipv4/* Variables', см. ссылки ниже. Если вы не будете следовать этому документу, некоторые параметры не будут работать, или вы можете случайно отключить или включить параметр!

В процессе работы мы также установили некоторые другие параметры ядра, см. документ '4.18. Защита доступа к сети", см. ссылки ниже. Я добавил в файл следующие строки:

/etc/sysctl.conf

И я изменил только настройки для интерфейса '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

Вот примечания по используемым параметрам ядра:

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)

После внесения изменений мы загружаем их с помощью:

sysctl -p

Мы также включили логирование марсианских пакетов, т.е. пакетов с адресом источника, который явно неверен, и невозможно проложить обратный маршрут к этому адресу. Чтобы увидеть эти логи:

grep martian /var/log/messages

Результат:

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

Следующие шаги

Вышеописанное является лишь первым шагом в укреплении вашего сервера против всех видов атак. Например, в документе 'DDoS Protection With IPtables: The Ultimate Guide', см. ссылки ниже, описано гораздо больше мер.

Проверьте ваши журналы

Еще одна вещь, которую вы должны сделать, это проверить журналы регистрации! Плохие или неправильно настроенные службы могут вызвать всевозможные проблемы, в том числе сделать ваш сервер более уязвимым. Как это может произойти? Ну, например, вы обновляетесь до новой версии Debian. Это может нарушить работу некоторых служб или оставить их в плохом состоянии, даже если ваш сервер работает нормально.

Проверяя /var/log/syslog, я обнаружил строки вроде (Я заменил IP addresses и т.д.):

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

Никогда не видел их раньше. Это могут быть спамеры, отправляющие письма на мой сервер и помечающие их как приходящие с фиктивных доменов. Похоже, что их количество значительно уменьшилось после включения фильтрации обратного пути. Придется изучить этот вопрос в один из ближайших дней.

Простой скрипт мониторинга

Я хотел посмотреть, что происходит минута за минутой, и создал этот крошечный скрипт, который выводит некоторую базовую информацию в файл, используя некоторые утилиты командной строки 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}"

После добавления этого скрипта в CRON лог-файл будет выглядеть следующим образом:

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 

Summary

Это заняло время. Усиление защиты вашего сервера от атак стало чрезвычайно важным, интернет НЕ является безопасным местом. Я знаю, что системное администрирование очень сложно, и уважаю людей, которые этим занимаются. Но вот я, программист, управляющий VPS, который подключен к интернету, сам, поэтому мне нужно знать некоторые из этих вещей. Это не пустая трата времени, а необходимые знания, когда у вас есть серверы, подключенные к интернету.

Использование параметра ядра rp_filter для включения фильтрации обратного пути не составило труда, и я также изменил несколько параметров, поскольку сервер не является маршрутизатором. Результат был поразительным, сканеров портов больше почти не было. Кроме того, снова заглянув в журналы, я заметил кое-что, чего там раньше не было, придется это изучить.

Обратите внимание, что если кто-то действительно хочет уничтожить ваш сервер, вы мало что можете сделать, кроме как переехать в сеть, защищенную от DDoS. Создать сложно, уничтожить легко.

Ссылки / кредиты

/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