Назад | Перейти на главную страницу

iptables tables - исправление опечатки в обработке lo

Сегодня я потратил некоторое время на аудит моего скрипта iptables. Я инженер-программист, а не специалист по эксплуатации, но я пытался постичь основы iptables. Я заметил кое-что, что должно быть давно ломалось:

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i lo -d 127.0.0.0/8 -j REJECT

Итак, похоже, это должно быть:

-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

Правильно?

Проблема в том, что на сервере идет живой трафик. Хотя это выглядит безобидным изменением, я отношусь к iptables с должным уважением. Кроме того, это означает, что я принимал трафик от / 8, который поступает с других интерфейсов. Что это означает в реальном мире? Как машина будет получать запросы от 127/8 на другом интерфейсе?

похоже должно быть:

-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

Правильно?

Возможно - да. Суть этого правила заключается в том, чтобы заблокировать все, чей IP-адрес 127.0.0.0/8 не прибыть на lo (loopback) интерфейс.

См. Этот вопрос о правильном расположении ! персонаж: Положение удара Iptables.

Я принимал трафик с / 8, который идет с других интерфейсов. Что это означает в реальном мире?

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

На самом деле, шансы использовать это, по крайней мере, мне кажутся маловероятными. Злоумышленник должен находиться в том же сегменте сети, что и вы, чтобы подделать IP-заголовок, сохраняя при этом заголовок Ethernet (в частности, MAC-адрес назначения). Удаленные узлы не смогут использовать поддельный IP-заголовок, потому что пакет будет отброшен недоставленным, когда он пройдет через маршрутизаторы в сети. Любые службы на машине, явно привязанные к IP-адресу интерфейса обратной связи, должны отвечать только на полученный таким образом трафик, а не на поддельные пакеты, поступающие на другие интерфейсы, поэтому я (лично) не считаю это серьезной проблемой для вас.

Проблема в том, что на сервере идет живой трафик. Хотя это выглядит безобидным изменением, я отношусь к iptables с должным уважением.

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

Изменение этого типа должен быть безвредным, но по-прежнему существует относительно много режимов сбоя: перебор транзакции с клавиатурой, непонимание взаимодействия между этим аспектом вашего iptables конфигурация и некоторые другие записи в брандмауэре и т. д.

Для всех нестандартных изменений брандмауэра, особенно связанных с REJECT правила, вы должны планировать время простоя. Если вы выполняете изменение на машине из удаленного места, убедитесь, что у вас есть другие средства доступа к машине на случай потери доступа - желательно, чтобы они были доступны. в пределах окна обслуживания так что вы можете избежать нарушения любых SLA. OOB-соединение через встроенный контроллер IPMI или последовательную консоль или, альтернативно, возможность физического доступа к машине в центре обработки данных во время at risk период, все бы здесь подошло.