REJECT vs DROP при использовании iptables

Ответы:

79

Как правило, используйте REJECT, если вы хотите, чтобы другой конец знал, что порт недоступен, - используйте DROP для соединений с хостами, которые вы не хотите, чтобы люди видели.

Обычно все правила для подключений внутри вашей локальной сети должны использовать REJECT. Для Интернета, за исключением идентификатора на некоторых серверах, соединения из Интернета обычно отбрасываются.

При использовании DROP соединение выглядит как незанятый IP-адрес. Сканеры могут отказаться от сканирования адресов, которые кажутся незанятыми. Учитывая, что NAT можно использовать для перенаправления соединения на брандмауэре, наличие хорошо известной службы не обязательно указывает на наличие сервера по адресу.

Идентификатор должен быть передан или отклонен по любому адресу, предоставляющему SMTP-сервис. Однако использование поиска идентификаторов SMTP-серверами перестало использоваться. Существуют протоколы чата, которые также зависят от работающей службы идентификации.

РЕДАКТИРОВАТЬ: При использовании правил DROP: - UDP-пакеты будут отброшены, и поведение будет таким же, как при подключении к не транслируемому порту без службы. - TCP-пакеты будут возвращать ACK / RST, который является тем же откликом, на который будет отвечать открытый порт без службы. Некоторые маршрутизаторы будут отвечать и ACK / RST от имени отключенных серверов.

При использовании правил REJECT отправляется ICMP-пакет, указывающий, что порт недоступен.

BillThor
источник
5
Это неправда. Даже когда правило говорит «DROP», система все равно ответит на входящий пакет с помощью TCP SYN / ACK, как если бы он был открыт. Чтобы действительно отбросить пакет, система должна ответить TCP RST / ACK - для которого нет правила брандмауэра. Таким образом, лучшая настройка брандмауэра - это когда перенаправляются только выбранные порты. Ваше правило DROP будет рекламировать ваш брандмауэр, а сканеры портов будут знать, что вы что-то брандмауэр, и продолжаете бить вас в надежде сломать ваш брандмауэр.
Dagelf
2
Моя точка зрения заключается в том, что извне можно определить, защищаете ли вы что-то брандмауэром или нет, просто потому, что ваш стек TCP ведет себя по-разному, когда вы DROP, чем когда у вас нет службы, работающей в первую очередь!
Dagelf
2
Это не меняет того факта, что ботнеты извлекают выгоду из разницы и, как следствие, отслеживают ваши порты.
Dagelf
1
что бы вы ни делали, будьте последовательны. если злоумышленник выберет неиспользуемый номер порта и попытается подключиться, он должен получить такой же ответ, как если бы он выбрал тот, который вы намеренно блокируете. другой ответ говорит ему, что там что-то есть. например, он может использовать purtnumber, который дает другой ответ, чтобы определить, какой сервер базы данных вы используете, он может адаптировать SQL-инъекцию к этому серверу ...
user313114
5
@Dagelf откуда вы получаете информацию, что DROP отправляет ответ? Это большая новость, которая противоречит всему, что я наблюдал и рассказывал. У вас есть ссылка на документацию, которая описывает это поведение?
Score_Under
27

Разница в том, что цель REJECT отправляет ответ об отклонении источнику, а цель DROP ничего не отправляет.

Это может быть полезно, например, для службы идентификации. Если вы используете REJECT, клиентам не нужно ждать тайм-аута.

Подробнее об этом: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html

Zizzencs
источник
2
Цель DROP ничего не отправляет. Проверьте мой комментарий к принятому ответу и изучите тему самостоятельно, если вас интересуют детали!
Dagelf
8

Обычно вы хотите игнорировать пробы от злоумышленников на определенные порты, что означает, что вы не хотите отправлять обратно «отказано в соединении». «Отказ в соединении» означает: «здесь есть сервер», и, возможно, выдает больше информации, в то время как удаление пакета не дает подсказки о версиях программного обеспечения, возможных уязвимостях или даже о том, что сервер прослушивает ваш IP.

Вышесказанное является одной из основных причин использовать DROP вместо REJECT.

wzzrd
источник
6
Без правил iptables закрытый порт по умолчанию равен REJECT. Если вы отбрасываете все порты, это хорошая альтернатива (ваш хост отключается), но если вы отбрасываете только определенные порты, вы фактически предоставляете им больше информации, чем REJECT. Если кто-то использует общий зонд, такой как nmap, определенные порты, которые отбрасывают пакеты, будут выглядеть как «фильтрованные», что означает, что они знают, что у вас есть служба, которую вы скрываете.
Raptor007
7

Я вижу много противоречивых ответов здесь, и, учитывая, что это первая статья в Google с правильными ключевыми словами; Вот правильное объяснение.
Все просто:

DROP ничего не делает с пакетом. Он не пересылается на хост, ему не отвечают. В man-странице IPtables говорится, что он сбрасывает пакет с пола, то есть он ничего не делает с пакетом.

REJECT отличается от DROP тем, что отправляет пакет обратно, но ответ таков, что сервер находится на IP-адресе, но порт не находится в состоянии прослушивания. IPtables будет отправлять RST / ACK в случае TCP или с UDP недоступный порт назначения ICMP.

Ecko
источник
2
+1 от меня, но ответы на самом деле не согласны. Насколько я понимаю, все они согласны, за исключением Дагельфа - кто не прав.
MadHatter
Хорошо, вот вам небольшая хитрость: сделайте "nmap localhost". Теперь выберите любой порт, который не «открыт» ... и добавьте правило, которое «ничего не делает», например: «iptables -I INPUT -p tcp --dport 888 -j DROP». Теперь снова nmap localhost. Что ты видишь? ...
Дагельф
4

Если вы пытаетесь скрыть существование вашей машины полностью, -j DROPэто уместно. Например, вы можете использовать это для реализации черного списка.

Если вы пытаетесь скрыть тот факт, что порт открыт, вы должны имитировать поведение, которое будет иметь место, если порт не был открыт:

  • TCP: -p tcp -j REJECT --reject-with tcp-reset
  • UDP: -p udp -j REJECT --reject-with icmp-port-unreachable

Если сканер портов видит, что несколько портов отбрасывают пакеты, а большинство отклоняет их, он может предположить, что отброшенные пакеты находятся на портах, которые открыты, но скрыты.

Raptor007
источник
Что если вы откроете несколько портов (то есть 22, 25, 53, 80, 443), а затем ОТПРАВИТЕ все остальное? Теперь у меня запущены MySQL, PostgreSQL, SQLite или Cassandra ... сканер не может сказать, верно?
Алексис Вилке
@AlexisWilke В этом случае единственная дополнительная информация, которую вы предоставляете сканеру портов, - это наличие какого-то брандмауэра с политикой DROP по умолчанию.
Raptor007
0

Несмотря на множество правильных ответов, только мои два цента:

Вот краткое изложение PoC FW.IDS-DROP-vs-REJECT на эту тему, касающееся правил для системы запретов (брандмауэр, IDS и т. Д.).

Коротко:

  • DROP может использоваться для рецидивирующих злоумышленников, если запрещены все порты (похоже, сервер не работает на стороне злоумышленника)
  • REJECT --reject-with tcp-reset лучший выбор для многопортового бана, потому что он выглядит как настоящий закрытый порт
  • если некоторые порты отвечают (злоумышленник знает, что хост жив), DROPи REJECT(без tcp-reset) подаст злоумышленнику «сигнал» о наличии чего-то блокирующего (что может стимулировать его к продолжению «атаки» в надежде предоставить необходимые данные). в какой-то момент)
sebres
источник
-5

Да, использовать DROP бессмысленно. Используйте ОТКАЗ.

Даже когда правило говорит «DROP», система все еще отвечает на входящий SYN с TCP RST / ACK - это поведение по умолчанию для портов без запущенных служб. (tcpdump и другие не регистрируют это.)

Если служба работает, SYN встречается с TCP SYN / ACK.

Поскольку DROP обычно не отвечает с помощью TCP SYN / ACK, а вместо этого с помощью RST / ACK, ваше правило DROP будет объявлять ваш брандмауэр, а сканеры портов будут знать, что вы что-то брандмауэру, и, возможно, вас не оправдают. поймать ваш брандмауэр вниз.

Теперь nmap может сообщать «отфильтрованный» вместо «закрытый», например:

$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
1111/tcp filtered lmsocialserver

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -D INPUT 1

Таким образом, единственная «невидимая» настройка брандмауэра - это установка, где выделенное устройство располагается между вашими устройствами и только выборочно перенаправляет порты.

Если вы действительно хотите связываться с базовыми сканерами, вы можете использовать TARP-соединения TARP, которые устанавливают в окне TCP значение 0, чтобы никакие данные не могли быть переданы после открытия соединения, игнорируя запросы на закрытие соединения, что означает, что сканер должен ждать для истечения времени ожидания соединения, если оно хочет быть уверенным. Но злоумышленник может легко обнаружить это и сократить время ожидания.

Учитывая все вышесказанное, вам, вероятно, лучше всего использовать REJECT - или разместить выделенное устройство переадресации портов между вашим сервером и Интернетом.

Или просто запускать сервисы на компьютерах с выходом в Интернет, которые не требуют брандмауэра.

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

оборота Дагельф
источник
5
Этот ответ неверен. С помощью tcpdump легко показать, что правило DROP приведет к тому, что система не будет отправлять ЛЮБОЙ ответ - как и следовало ожидать. И ваше утверждение «Чтобы действительно отбросить пакет, система должна ответить TCP RST / ACK TCP» не имеет смысла, так как ответ на что-либо, очевидно, не означает «действительно отбрасывание пакета». Если вы «действительно отбрасываете» пакет, вы просто не отвечаете, и это, очевидно, является следствием правила DROP.
Джулиана Хольцт
3
Не могли бы вы предоставить источник для обвинения, которое DROPбудет выдавать SYN/ACK? Я никогда не видел это на моих машинах.
motobói
2
@Dagelf В вашей статье написано "DROP (иначе DENY, BLACKHOLE) Запретить передачу пакета. Не отправлять ответ".
JeanT
Он не отправляет нормальный ответ, но отправляет его как объяснено, независимо.
Dagelf
3
В документе, на который вы ссылаетесь, написано " УБРАТЬ ... Не отправлять ответ ", и, насколько я вижу, не поддерживает ваше утверждение, которое DROPвозвращает a SYN/ACK. Я тоже никогда не видел такого поведения при любой версии iptables. Если у вас есть источник, который поддерживает вашу заявку, было бы очень полезно увидеть его; конечно, дампы пакетов, которые я только что сделал, не поддерживают вашу заявку.
MadHatter