| |
|
|
| | На сервере есть такой набор правил iptables:
-A INPUT -i lo -j ACCEPT # local interface
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT # http
-A INPUT -p tcp -m tcp --dport 15689 -j ACCEPT # ssh
-A INPUT -p tcp -m tcp --dport 18927 -j ACCEPT # ftp
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT # smtp
-A INPUT -p udp -m udp --dport 123 -j ACCEPT # ntp
-A INPUT -p tcp -m multiport --dports 0:1024 -j TARPIT
-A OUTPUT -o lo -j ACCEPT # local interface
-A OUTPUT -j ACCEPT
|
Используется прекрасный модуль TARPIT, подтверждающий запрос на TCP/IP соединение и устанавливает размер окна равным нулю, что вынуждает атакующую систему прекратить передачу данных. Любые попытки атакующего закрыть соединение игнорируются, таким образом соединение остается открытым, пока не истечет срок тайм аута.
То есть внешне порты выглядят открытыми, а на деле являются ловушками.
В приведённом мной конфиге ловушками являются все tcp порты от 0 до 1024, кроме 80, 15689, 18927 и 25. Проблемы начинаются когда я вешаю TARPIT в цепочку INPUT на ВСЕ порты (опять же, кроме разрешенных).
-A INPUT -p tcp -m tcp -j TARPIT
В итоге перекрываются исходящие соединения.
# curl ya.ru
curl: (7) couldn't connect to host
|
Снимаю, и:
# curl ya.ru
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><....
|
Собственно, почему TARPIT на входящие подключения влияет на исходящие? | |
| |
|
|
| |
|
|
| |
для: Саня
(23.11.2011 в 09:36)
| | | >все tcp порты от 0 до 1024, кроме 80, 15689, 18927 и 25
15689 и 18927 вроде как сильно больше 1024? Т.е. закрыты действительно все порты? | |
| |
|
|
| |
|
|
| |
для: cheops
(23.11.2011 в 10:25)
| | | Правило -A INPUT -p tcp -m tcp -j TARPIT применяется ко всем без исключения tcp подключениям, независимо от номера порта. На 80, 15689, 18927 и 25 висит ACCEPT, поэтому подключения на эти порты не дойдут до этого правила, так как оно в конце цепочки. А вот все остальные уже попадут на TARPIT.
Когда добавляю -A INPUT -p tcp -m tcp -j TARPIT в конец цепочки, начинаются глюки с исходящими подключениями, поэтому в качестве полумеры сейчас блокируются только первые 1024. | |
| |
|
|
| |
|
|
| |
для: Саня
(23.11.2011 в 10:29)
| | | Хм... а локальные соединения тоже закрыты? Дело в том что CURL нужны локальные TCP/IP соединения на порты, отличные от 80 (он там что-то сам себе пересылает). | |
| |
|
|
| |
|
|
| |
для: cheops
(23.11.2011 в 10:49)
| | | Всё верно, curl (а так же wget и все остальные) открывают себе эфемерный порт и общаются через него. Только вот непонятно почему порт открывается наружу (то есть исходящее соединение), а попадает в TARPIT, определённом для входящих соединений.
Ради эксперимена заблокировал все порты, кроме эфемерных для моей системы (49152 — 65535), curl не отвалился.
Локальные соединения на все порты открыты правилом -A INPUT -i lo -j ACCEPT | |
| |
|
|
| |
|
|
| |
для: Саня
(23.11.2011 в 11:05)
| | | Скорее всего iptables порт получателя режет, он как раз где-то в этих диапазонах и должен быть. Все-равно ему откуда данные идут и для чего. | |
| |
|
|
| |
|
|
| |
для: cheops
(23.11.2011 в 11:15)
| | | Всё, разобрался. Правило действует на все пакеты, независимо от состояния соединения. То есть curl устанавливает tcp-соединение и отсылает запрос без каких-либо препятствий со стороны фаервола. Удалённая машина отвечает по этому соединению и получает отлуп от фаервола, из-за чего curl думает что удалённой машины не существует и отваливается.
Нужно было настроить правило на отсечение новых входящих пакетов, а пакеты по установленному соединению пропускать: -A INPUT -p tcp -m conntrack --ctstate NEW -j TARPIT | |
| |
|
|
