Лучше ли устанавливать -j REJECT или -j DROP в iptables?

Пример правил iptables для вики-файлов archlinux:

# Generated by iptables-save v1.4.18 on Sun Mar 17 14:21:12 2013 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :TCP - [0:0] :UDP - [0:0] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable COMMIT # Completed on Sun Mar 17 14:21:12 2013 

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

Итак, у меня есть два вопроса:

  1. Что делают три правила?

  2. Разве это имеет значение, когда я кладу туда DROP на место REJECT --reject-with ? Если да, какая разница?

One Solution collect form web for “Лучше ли устанавливать -j REJECT или -j DROP в iptables?”

Что делают три правила?

Эти 3 правила кажутся довольно понятными:

  1. Отклонить входящие UDP-пакеты с сообщением ICMP «Недоступный порт»
  2. Отклонить входящие TCP-пакеты с «tcp reset»
  3. Отклонить входящие пакеты (любого другого протокола) с сообщением ICMP «протокол недоступен»

Если вы ищете более подробную информацию (о UDP / TCP-пакетах, ICMP), вам нужно вникнуть в сетевые документы и, возможно, и man iptables .

Разве это имеет значение, когда я кладу туда DROP на место REJECT –reject-with? Если да, может кто-то объяснить мне разницу, я буду очень благодарен.

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

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

Общей причиной использования DROP, а не REJECT, является отказ от предоставления информации о том, какие порты открыты, однако отбрасывание пакетов дает точно столько же информации, сколько и отказ.

С помощью REJECT вы выполняете сканирование и классифицируете результаты в «установлено соединение» и «отклонено соединение».

С помощью DROP вы классифицируете результаты в «установленное соединение» и «время ожидания соединения».

Самый тривиальный сканер будет использовать вызов «connect» операционной системы и будет ждать завершения одной попытки подключения до начала следующего. Этот тип сканера значительно замедлится, если вы упадете пакеты. Однако, если атака устанавливает тайм-аут в 5 секунд на попытку подключения, можно сканировать каждый зарезервированный порт (1..1023) на машине всего за 1,5 часа. Сканирование всегда автоматизировано, и злоумышленнику все равно, что результат не будет немедленным.

Более сложный сканер будет отправлять пакеты сам, а не полагаться на реализацию TCP операционной системы. Такие сканеры быстры, эффективны и безразличны к выбору REJECT или DROP.

ВЫВОД

DROP не предлагает эффективного барьера для враждебных сил, но может значительно замедлить работу приложений, выполняемых законными пользователями. Обычно DROP не используется.

  • UDP, отправляющий две строки в дейтаграмме
  • Запуск nmap через Tor
  • Почему мой трассировочный маршрут (mtr) связывает порт UDP при его запуске?
  • Многоадресный UDP не работает
  • UDP NAT Punching
  • Буферы TCP продолжают заполняться (Recv-Q full): он называется unresponsive
  • Команда для поиска открытых портов
  • Как работает многоадресная рассылка UDP в Unix?
  • Создайте UDP для TCP-моста с помощью socat / netcat для управления командами управления для медиаплеера vlc
  • Не удается увидеть сервер EC2 VPN из другого экземпляра EC2
  • Как найти скорость передачи?
  • Linux и Unix - лучшая ОС в мире.