REJECT vs DROP при використанні iptables

Чи є якась причина, чому я хотів би це мати

iptables -A INPUT -j REJECT

замість

iptables -A INPUT -j DROP

Як правило, використовуйте REJECT, коли ви хочете, щоб інший кінець знав, що порт недоступний ', використовуйте DROP для з'єднань з хостами, які ви не хочете, щоб люди бачили.

Зазвичай у всіх правилах з'єднань у вашій локальній мережі слід використовувати REJECT. Для Інтернету, За винятком ідентифікатора на певних серверах, з'єднання з Інтернету зазвичай перериваються.

Використання DROP робить з'єднання з незайнятою IP-адресою. Сканери можуть вирішити не продовжувати сканування адреси, які видаються незайнятими. Зважаючи на те, що NAT може використовуватися для переадресації з'єднання на брандмауері, наявність добре відомої служби не обов'язково вказує на наявність сервера на адресу.

Ідентифікатор повинен бути переданий або відхилений на будь-яку адресу, що надає послугу SMTP. Однак використання пошукових ідентифікаторів Ident за допомогою сервісів SMTP вийшло з ужитку. Існують протоколи чату, які також покладаються на робочу службу ідентифікації.

EDIT: При використанні правил DROP: - Пакети UDP будуть скинуті, а поведінка буде такою ж, як підключення до непроведеного порту без обслуговування. - TCP-пакети повернуть ACK / RST, що відповідає тій самій відповіді, на яку буде відповідати відкритий порт без жодної служби. Деякі маршрутизатори відповідатимуть і ACK / RST від імені серверів, які не працюють.

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

Різниця полягає в тому, що ціль REJECT надсилає відповідь відхилення до джерела, тоді як ціль DROP нічого не посилає.

Це може бути корисно, наприклад, для послуги ident. Якщо ви використовуєте REJECT, клієнтам не потрібно чекати очікування.

Більше про це: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html

Зазвичай, ви хочете ігнорувати зонди від зловмисників до певних портів, під якими я маю на увазі, що ви не хочете надсилати назад "відмовлено в з’єднанні". "Відмовлено в з’єднанні" означає: "тут є сервер", і, можливо, надає більше інформації, тоді як випадання пакету не дає підказки про версії програмного забезпечення, можливі вразливості або навіть те, що сервер слухає вас IP.

Сказане є однією з головних причин використовувати DROP замість REJECT.

Я бачу тут багато суперечливих відповідей, і з огляду на це перша стаття в Google з правильними ключовими словами; ось правильне пояснення.
Це просто:

DROP взагалі нічого не робить з пакетом. Він не передається хосту, він не отримує відповіді. Сторінка 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 безглуздо. Використовуйте REJECT.

Навіть коли правило каже "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

Таким чином, єдине "невидиме" налаштування брандмауера - це те, де виділений пристрій сидить між вашими пристроями і лише вибірково пересилає порти.

Якщо ви дійсно хочете повозитися з основними сканерами, ви можете TARPIT tcp-з'єднання, яке встановлює вікно TCP 0, так що жодні дані не можуть бути передані після відкриття з'єднання, ігноруючи запити на закриття з'єднання, тобто сканер повинен чекати щоб відбувся час очікування з'єднання, якщо він хоче бути впевненим. Але для нападника банально виявити це і зробити його тайм-аут дуже коротким.

Зважаючи на все, вам, мабуть, найкраще просто використовувати REJECT - або встановити спеціальний пристрій для переадресації портів між вашим сервером та Інтернетом.

Або просто запустити сервіси на своїх Інтернет-машинах, які не потребують брандмауера.

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