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

Есть ли причина, по которой я хотел бы иметь

iptables -A INPUT -j REJECT

вместо

iptables -A INPUT -j DROP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коротко:

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

Да, использовать 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 лучше всего подходит для веб-серверов, поскольку любая служба, пытающаяся получить к ней доступ (возможно, чаще, чем вы), быстро получит ответ, и пользователи или другие службы не будут ждать, задаваясь вопросом, есть ли сбой в сети.