Почему я не могу использовать политику REJECT в цепочке OUTPUT iptables?

11

В настоящее время моя цепочка OUTPUT установлена на DROP. Я хотел бы изменить его на REJECT, чтобы у меня была подсказка, что именно мой брандмауэр мешает мне получить что-то, а не проблему с какой-либо службой, к которой я пытаюсь получить доступ (немедленное отклонение вместо истечения времени ожидания). Однако iptables, похоже, не заботится об этом. Если я вручную отредактировал сохраненный файл правил и попытался восстановить его, я получил, iptables-restore v1.4.15: Can't set policy 'REJECT' on 'OUTPUT' line 22: Bad policy nameи он отказался загружать правила. Если я пытаюсь установить это вручную ( iptables -P OUTPUT REJECT), я получаю, iptables: Bad policy name. Run 'dmesg' for more information.но в dmesg нет вывода.

Я подтвердил, что соответствующее правило скомпилировано в ядро, и я перезагрузился, чтобы убедиться, что оно загружено:

# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
***
CONFIG_IP_NF_TARGET_REJECT=y
***
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y

(Звездочки добавлены, чтобы выделить применимое правило)

Все, что я могу найти, говорит о том, что REJECT является допустимой политикой / целью (в целом), но я не могу найти ничего, что говорит о том, что это недопустимо для цепочек INPUT, FORWARD или OUTPUT. Мой гугл-фу не помогает. Я на Gentoo, если это что-то меняет. Кто-нибудь здесь есть какое-то понимание?

networking iptables gentoo

— ND Geek
источник

Можете ли вы показать iptablesправило (ы) в вопросе?

— Багамат

15

REJECTявляется целевым расширением , в то время как цепная политика должна быть целью . Страница руководства говорит это (хотя это не совсем понятно), но кое-что из того, что там написано, совершенно неверно.

Политика может быть только ACCEPTили DROPна встроенных цепочках. Если вы хотите получить эффект отклонения всех пакетов, которые не соответствуют предыдущим правилам, просто убедитесь, что последнее правило соответствует всему, и добавьте правило с REJECTцелевым расширением. Другими словами, после добавления всех соответствующих правил, выполните iptables -t filter -A OUTPUT -j REJECT.

См. Ветку «Каковы возможные политики цепочки» в списке сетевых фильтров для получения более подробной информации.

— Шон Дж. Гофф
источник

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

— ND Geek

1

Читая всю справочную страницу, становится ясно, что REJECT является целевым расширением, но справочная страница очень длинная, поэтому обычно применяется TL; DR. Это также подразумевает, что DROP, ACCEPT и QUEUE являются действительными целями политики; из текущего кода, QUEUE нет!

— StarNamer

4

Я не смог найти его документированным, но ссылка здесь указывает на то, что единственными разрешенными политиками являются ACCEPTor DROP. Это подтверждается, глядя на источник из libiptc(который отвечает за изменение правил) вокруг линии 2429, где код имеет

2429         if (strcmp(policy, LABEL_ACCEPT) == 0)
2430                 c->verdict = -NF_ACCEPT - 1;
2431         else if (strcmp(policy, LABEL_DROP) == 0)
2432                 c->verdict = -NF_DROP - 1;
2433         else {
2434                 errno = EINVAL;
2435                 return 0;
2436         }

Оригинальный поток предлагает лучшее, что нужно сделать, это добавить REJECT в конце цепочки, что должно быть iptables -A OUTPUT -j REJECT.

Обратите внимание, что код перед этим:

2423         if (!iptcc_is_builtin(c)) {
2424                 DEBUGP("cannot set policy of userdefinedchain `%s'\n", chain);
2425                 errno = ENOENT;
2426                 return 0;
2427         }
2428

Таким образом, вы вообще не можете устанавливать политику в пользовательской цепочке.

— StarNamer
источник

Эта команда в потоке неверна; -pдля сопоставления по протоколу; он имел в виду, -Aкак говорит мой ответ.

— Шон Дж. Гофф,

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

— ND Geek

2

REJECTна OUTPUTне имеет смысла; a REJECTвернет ICMP-пакет, который должен был бы пройти через сеть.

Добавьте новое -j LOGкак ваше последнее правило (следовательно, перед DROPполитикой), чтобы увидеть, что заходит так далеко в OUTPUTцепочке.

— Аарон Д. Мараско
источник

1

Не мог REJECTICMP-пакет вернуться на интерфейс lo? Я согласен, что это LOGполезно для устранения неполадок, но я действительно надеялся, что это способ напомнить мне, что «О, да ... это, вероятно, заблокировано моим DROPiptables default» вместо того, чтобы устранять неполадки в течение 5 минут, просит коллегу Сервер Access XYZ понимает, что он, вероятно, локальный , что является моим наиболее распространенным подходом, поскольку мой обычный рабочий день редко затрагивает вещи, для которых я еще не открыл дыру. Конечно, возможно, мне нужно помнить это лучше, но квартира REJECTболее очевидна.

— ND Geek

Я не думаю, что вы хотели бы, чтобы ethXинтерфейс генерировал трафик на loинтерфейсе по многим причинам. Они очень независимы; Вы можете легко сделать цепочки применимы к одному, а не к другому.

— Аарон Д. Мараско