БИТУМНАЯ ЯМА может использоваться для того, чтобы тратить ресурсы атакующего, таким образом замедляя его атаки и снижая его способность атаковать другие хосты ... похоже, хорошая идея.
Он предоставляется как Netfilter добавить и может использоваться как любая другая цель IPTables.
Есть ли известные недостатки или уязвимости в этом подходе к борьбе с (D) DoS?
Использование tarpit на сервере общего назначения сопряжено с определенными рисками. Если вы знаете, какие риски, вы можете уменьшить их, в зависимости от вашего уровня комфорта.
К счастью, это все возможно и довольно просто с использованием обычных iptables и ipset.
Вы можете использовать iptables, чтобы ограничить количество хостов, на которых вы TARPIT, без использования слишком большого количества системных ресурсов. См. Пример ниже. Это включает пропускную способность сети, системную память, записи о стабильном состоянии и другие системные ресурсы. Получите слишком много запутанных связей, начните игнорировать их. Если вы организуете свой набор правил в правильном порядке, ни одно из подключенных с задержкой соединений не попадет в ваши таблицы состояний. Также убедитесь, что вы не ведете журнал, если только вы не ведете статистику в реальном времени с помощью чего-то вроде настраиваемого ulog - журналы tarpit Direct iptables могут быстро заполнить диск.
По моему опыту, мои нынешние хосты могут легко удерживать 200+ хостов в тарпите, с небольшим заметным влиянием на использование памяти, трафик или использование процессора. Скорее всего, я мог бы продвинуть это дальше, но пока в среднем я захватываю только около 130 хостов в любой момент.
Причина, по которой я применил ограничения, была указана в другом предложении, потому что мой первый хост tarpit был затоплен. Это было тривиальное решение. С тех пор у меня не было проблем.
ipset это отличный маленький инструмент, который позволяет вам создавать группы объектов для использования в правилах iptables. Более того, поскольку он может содержать объекты в хэш-таблице, чем больше ipset, тем быстрее он сравнивается с эквивалентным линейным набором правил iptables.
В дополнение к этому списки могут включать счетчики (пакеты / байты), тайм-аут и исключения для каждого объекта.
Вы можете добавлять / удалять из ipset с помощью большинства программ, которые автоматически блокируют, например, fail2ban, ossec и других. Поскольку вы можете установить тайм-аут по умолчанию, вы можете гарантировать, что записи истекли независимо от того, какая программа установила запись.
Вот пример, основанный на том, что я использую на управляемых мной серверах, что снижает риски, перечисленные выше:
### Note: This does not account for all possible traffic you might need or want
### This is only an example of mitigating common risks of using a tarpit
### Use at your own risk
# Create the ipset blacklist
# options:
# - create : create a new ipset
# - blacklist : Name of the ipset we'll reference in the iptables rule
# - hash:net : Make blacklist type hash to hold network (ip/mask) data
# - family inet : This is for IPv4 data (inet6 for IPv6)
# - counters : We want packet/byte stats counted for each entry
# - comment : So we can add a comment with each entry (handy)
# - timeout 604800 : Set a default timeout of 604800 seconds (1 week) for each new entry
# - nomatch : Allow us to enter exclusion entries (never match an entry)
ipset create blacklist hash:net family inet counters comment timeout 604800 nomatch
# Create an entry to never blacklist a trusted network
# options:
# - timeout 0 : entry never expires
# - nomatch : Tells IPset to never match this entry (whitelist, in our usage)
ipset add blacklist 123.45.67.0/24 comment "Trusted subnet, causes breakage if blocked" timeout 0 nomatch
# Example to blacklist hosts
# no netmask implies /32 (or /128 for ipv6)
ipset add blacklist 34.56.78.90 comment "SSH Bruteforce"
ipset add blacklist 23.45.67.89 comment "SQL Injection" timeout 12345
# etc...
# Flush the input table
iptables -F INPUT
# Drop the custom flow TAR
iptables -X TAR
# Set default INPUT policy to DROP
iptables -P INPUT DROP
# Create the chain TAR
iptables -N TAR
# Send all blacklisted hosts to the tarpit
iptables -A INPUT -m set --match-set blacklist src -j TAR
# Allow established connections
# Note: after the blacklist so newly blacklisted threats are immediately ignored
# Yes, that will cause the server to hold the state open until it times out.
# Would you rather have a malicious host continuing its attack?
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Allow the services we want
# Note: These create new state table entries/use up memory
# Note: We do not account for synflood prevention in this example
iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -m tcp --syn -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
# Send everything else to tarpit chain
iptables -A INPUT -j TAR
# This is the tarpit chain
# Tarpit up to 10 unique connections a second, any more, and pass to next rule
# Note: 10/s limit is arbitrary, adjust to your preference (experiment)
iptables -A TAR -p tcp -m limit --limit 10/sec -j TARPIT --tarpit
# Drop everything else that makes it this far
# You can also set to REJECT which will immediately tell all connections to buzz off
iptables -A TAR -j DROP
$ sudo tcpdump -npi eth0 'src YOUR.HOST.IP and (tcp[14] = 0 && tcp[15] = 0)'
Раньше я думал, что это хорошая идея. Но теперь я знаю, к сожалению, это очень плохая идея.
Вы когда-нибудь запускали приложение для тестирования http, например, apache bench. На одном компьютере вы можете настроить его для создания сотен подключений в секунду к целевому серверу. Запустите несколько из этих клиентов и подключитесь к вашему серверу с включенной функцией задержки ответа, и я думаю, вы столкнетесь с проблемой.
Подумайте о том, как создание тысяч подключений к вашему серверу в секунду повлияет на сервер, если каждое подключение будет заблокировано тентом.
Ваш сервер быстро потребит все доступные ресурсы (или дескрипторы файлов), так что больше никаких подключений не будет. Это хуже, чем просто закрыть соединение. Лучше на время бросить обидчика, чем пытаться связать его ресурсы. Этого и достигают сценарии вроде fail2ban.
Кроме того, вы никогда не хотите, чтобы ваши обычные пользователи застревали в брезенте. По крайней мере, для интерактивных занятий. Как вы решаете, кому разрешено, а кому нет? Для некоторых протоколов это невозможно. Например, HTTP-трафик. Вы должны предполагать, что с клиентом все в порядке, пока вы не получите от него действий, говорящих вам об обратном. Тогда вы можете принять решение относиться к нему как к плохому, и в следующий раз он попадется в брезент. Казалось бы, это нормально, за исключением того, что многие из этих атак могут исходить от пользователей динамической рекламы и т. Д., Которые случайно получили последний вирус-червь.
Учитывая, что многие атаки происходят на ПК с помощью вируса-червя, когда пользователь даже не знает и не использует динамические адреса, вы можете создать легко устаревший черный список tarpit. Вы начинаете видеть какие-то проблемы?