Отже, продовжуємо розумітися на ACL. На цей раз, у нас розширені ACL. Топологію візьмемо від попередньої статті, сподіваюся, ви її вивчили досконало. Якщо це не так, то дуже рекомендую прочитати, щоб матеріали цієї статті були зрозумілішими.

Насамперед почну з того, що таке розширені ACL. Розширені ACL дозволяють, крім адреси джерела, вказати протокол, адресу призначення та порти. А також спеціальні параметри певного протоколу. Найкраще вчитися на прикладах, тому сформуємо нове завдання, ускладнивши попереднє. До речі, комусь може цікаво буде зайнятися питаннями розподілу трафіку за пріоритетами, раджу ось QoS Classification and Marking хорошу статтю, правда англійською. Ну а поки що, повернемося до нашого завдання:

Завдання.

1. Дозволити echo-запити із вузлів мережі 192.168.0.0/24 на сервер.
2. Із сервера – заборонити echo-запити у внутрішню мережу.
3. Дозволити WEB-доступ на сервер із вузла 192.168.0.11.
4. Дозволити FTP доступ із вузла 192.168.0.13 на сервер.

Комплексне завдання. Вирішуватимемо її теж комплексно. Насамперед розберу синтаксис застосування розширеного ACL.

Параметри розширеного ACL

<номер от 100 до 199> <действие permit, deny> <протокол> <источник> <порт> <назначение> <порт> <опции>

Номери портів вказуються лише у протоколів TCP/UDP, зрозуміло. Також можу мати місце приставочки eq(Номер порту рівний зазначеному), gt/lt(номер порту більше/менше зазначеного), neq(Номер порту не дорівнює вказаному), range(Діапазон портів).

Названі ACL

До речі, списки доступу можна не тільки нумерувати, а й іменувати! Можливо, цей спосіб здасться вам зручнішим. На цей раз зробимо саме так. Ці команди виконуються в контексті глобального конфігурування, і синтаксис виглядає так:

Router(config)#ip access-list extended<имя>

Отже, починаємо формувати правила.

1. Дозволяємо пінги з мережі 192.168.0.0/24 на сервер. Отже, echo-запити – це протокол ICMP, як адреса джерела виберемо нашу підмережу, адресою призначення – адресу сервера, тип повідомлення – на вхідному інтерфейсі echo, на виході - echo-reply. Router (config) # ip access-list extended INT_IN Router (config-ext-nacl) # Так, це фішка ACL. Так звана WildCard-Маска. Обчислюється як обернена маска від звичної. Тобто. 255.255.255.255 - маска підмережі. У нашому випадку підсіти 255.255.255.0 , після віднімання залишається якраз 0.0.0.255 . Думаю, це правило пояснення не потребує? Протокол icmp, адреса джерела – підмережа 192.168.0.0/24 , адреса призначення – host 10.0.0.100, тип повідомлення - echo(Запит). До речі, неважко помітити, що host 10.0.0.100еквівалентно 10.0.0.100 0.0.0.0 .Застосовуємо це правило на інтерфейс. Router(config)#int fa0/0
   Router(config-if)#ip access-group INT_IN in Ну якось так. Тепер, якщо перевірити пінги - легко помітити, що все добре працює. Тут, щоправда, нас чекає один сюрприз, який спливе трохи пізніше. Поки не розкриватиму. Хто здогадався – молодець!
2. З сервера – забороняємо всі запити echo у внутрішню мережу (192.168.0.0/24). Визначаємо новий іменований перелік, INT_OUT і вішаємо його на інтерфейс, найближчий до сервера.
   Router(config)#ip access-list extended INT_OUT
   Router(config-ext-nacl)#deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo
   Router(config-ext-nacl)#exit
   Router(config)#int fa0/1
   Router(config-if)#ip access-group INT_OUT in
   Пояснюю, що ми зробили. Створили розширений список доступу з ім'ям INT_OUT, заборонили протокол. icmpз типом echoз хоста 10.0.0.100 на підмережу 192.168.0.0/24 та застосували на вхід інтерфейсу fa0/1, тобто. найближчий до сервера. Пробуємо надіслати pingіз сервера.
   SERVER>ping 192.168.0.11
   Pinging 192.168.0.11 with 32 bytes of data:
   
   Reply from 10.0.0.1: Destination host unreachable.
   Reply from 10.0.0.1: Destination host unreachable.
   Reply from 10.0.0.1: Destination host unreachable.
   Ping statistics for 192.168.0.11:
   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
   Ну, начебто спрацювало як слід. Для тих, хто не знає, як посилати пінги - кликаємо на вузлі, що цікавить нас, наприклад сервері. Переходимо на вкладку Desktop (Робочий стіл), там Command Prompt (Командний рядок). А тепер обіцяний прикол. Спробуйте надіслати ping з хоста, як у першому пункті. PC>ping 10.0.0.100
   Pinging 10.0.0.100 with 32 bytes of data:
   Request timed out.
   Request timed out.
   Request timed out.
   Request timed out.

   Ось тобі раз. Щойно все працювало! Чому перестало? Це обіцяний сюрприз. Пояснюю, у чому проблема. Так, перше правило нікуди не поділося. Воно дійсно дозволяє відправлення запиту echo на вузол сервера. Але де дозвіл на проходження echo-відповідей? Його нема! Запит посилаємо, а відповіді прийняти не можемо! Чому все працювало раніше? Тоді у нас не було ACL на інтерфейсі fa0/1. А якщо немає ACL, то все дозволено. Прийде створювати правило на дозвіл прийому icmp-відповідей.

   До списку INT_OUT додамо

   Те саме додамо і до списку INT_IN.

   Router(config-ext-nacl)#permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply

   Ось тепер не причепитися. Все проходить чудово!

3. Дозволяємо WEB-доступ на сервер із вузла *.11.Поступаємо аналогічно! Тут, щоправда, треба трохи знати, як відбуваються звернення протоколами 4-го рівня (TCP, UDP). Клієнтський порт вибирається довільним > 1024, а серверний – відповідний службі. Для WEB - це 80 порт (протокол http). А що з приводу WEB-сервера? За промовчанням, на сервері вже встановлена ​​WEB-служба, можна переглянути в налаштуваннях вузла. Зверніть увагу, щоб стояла галочка. А підключитися до сервера можна, вибравши ярлик "Веб браузер" на "Робочому столі" будь-якого вузла. Звичайно ж, зараз доступу не буде. Оскільки у нас на інтерфейсах маршрутизатора висять ACL-и, і в них немає правил для доступу. Що ж, давайте створимо. У список доступу INT_IN (який на інтерфейсі fa0/0) додамо правило: Router(config-ext-nacl)#permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq 80 Тобто ми дозволяємо протокол TCP з нашого вузла (порт довільний, > 1024) на адресу сервера.

   І, зрозуміло, зворотне правило, до списку INT_OUT (який на інтерфейсі fa0/1):

   Router(config-ext-nacl)#permit tcp host 10.0.0.100 eq 80 host 192.168.0.11 established

   Тобто дозволяємо TCPз порту 80 сервера на хост *.11 , і з'єднання вже має бути встановлене! Можна замість establishedвказати так само gt 1024працювати буде так само добре. Але сенс трохи інший.

   У коментах дайте відповідь, що буде безпечнішим?

4. Дозволяємо FTP-доступ з вузла *.13 на сервер. Теж абсолютно нічого складного! Розбираємо, як відбувається взаємодія протоколу FTP. У майбутньому я планую присвятити цілий цикл статей роботі різних протоколів, оскільки це дуже корисно при створенні точних (снайперських) правил ACL. Ну а поки що: Дії сервера та клієнта:+ Клієнт намагається встановити зв'язок і надсилає пакет (в якому знаходиться вказівка, що буде вестися робота в пасивному режимі) на 21 порт сервера зі свого порту X (X > 1024, вільний порт)+ Сервер посилає відповідь і повідомляє номер свого порту для утворення каналу даних Y (Y > 1024) на порт клієнта X, вилученого із заголовка TCP-пакета. Якось так. Трохи складно звучить, але потрібно лише розібратися! До списку INT_IN додаємо правила:

   permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 eq 21
   permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 gt 1024

   А до списку INT_OUT додаємо правила:

   permit tcp host 10.0.0.100 eq ftp host 192.168.0.13 gt 1024
   permit tcp host 10.0.0.100 gt 1024 host 192.168.0.13 gt 1024

   Перевіряємо з командного рядка, командою ftp 10.0.0.100, де авторизуємося за обліковими даними cisco:cisco(взято з налаштувань сервера), там вводимо команду dirі побачимо, що дані як і команди передаються успішно.

Ось приблизно і все, що стосується розширеного списку доступу.

Отже, подивимося наші правила:

Router#sh access
Розширений IP access list INT_IN
permit icmp 192.168.0.0 0.0.0.255 host 10.0.0.100 echo (17 match(es))
permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply
permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq www (36 match(es))
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 eq ftp (40 match(es))
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 gt 1024 (4 match(es))
Розширений IP access list INT_OUT
deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo (4 match(es))
permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply (4 match(es))
permit tcp host 10.0.0.100 eq www host 192.168.0.11 established (3 match(es))
permit tcp host 10.0.0.100 eq ftp host 192.168.0.13 gt 1024 (16 match(es))
permit tcp host 10.0.0.100 gt 1024 host 192.168.0.13 gt 1024 (3 match(es))

Навчитися налаштування MikroTikможна на онлайн курсіз обладнання цього виробника. Автор курсу є сертифікованим тренером MikroTik. Детальніше Ви можете прочитати наприкінці статті.

Стаття відповідає питанням наскільки небезпечно блокувати ICMP трафік.

ICMP - яблуко розбрату

Багато мережеві адміністраторивважають, що протокол міжмережевих керуючих повідомлень (Internet Control Message Protocol (ICMP) є загрозою безпеці і тому повинен завжди блокуватися на . Це правда, що протокол має деякі пов'язані з цим проблеми безпеки, і що частина запитів повинна бути заблокована. Але це не привід блокувати весь ICMP-трафік!

ICMP-трафік має багато важливих функцій; якісь з них корисні для усунення несправностей, інші необхідні для правильної роботи мережі. Нижче наведено відомості про деякі важливі складові протоколу ICMP, про які ви повинні знати. Слід подумати над тим, як оптимально пропускати їх через вашу мережу.

Echo запит та and Echo відповідь

IPv4 – Echo запит (Type8, Code0) та Echo відповідь (Type0, Code0)
IPv6 – Echo запит (Type128, Code0) та Echo відповідь (Type129, Code0)

Ми всі добре знаємо, що ping - один з перших інструментів для пошуку та усунення несправностей. Так, якщо ви увімкнете на своєму обладнання обробку ICMP-пакетів, то це означає, що ваш хост тепер доступний для виявлення, але хіба ваш уже не слухає порт 80, і не надсилає відповіді на запити клієнта? Звичайно, заблокуйте ще й ці запити, якщо ви дійсно хочете, щоб на межі мережі була ваша DMZ. Але блокуючи ICMP трафік усередині вашої мережі, не посиліть захист, навпаки отримаєте систему із надмірно складним процесом пошуку та усунення несправностей («Перевірте будь ласка, чи відгукується шлюз на мережеві запити?», «Ні, але це мене анітрохи не засмучує, тому що мені це нічого не скаже!»).

Пам'ятайте, також можете дозволити проходження запитів у певному напрямку; наприклад, налаштувати обладнання так, щоб Echo запити з вашої мережі проходили до мережі Інтернет та Echo відповіді з Інтернету у вашу мережу, але не навпаки.

Необхідна фрагментація пакета (IPv4) / Пакет занадто великий (IPv6)

IPv4 - (Type3, Code4)
IPv6 - (Type2, Code0)

Дані компоненти протоколу ICMP дуже важливі, оскільки є важливим компонентом Path MTU Discovery (PMTUD), який є невід'ємною частиною протоколу TCP. Дозволяє двом хостам коригувати значення максимального розміру сегмента TCP (MSS) до значення, яке відповідатиме найменшому MTU шляхом зв'язків між двома адресатами. Якщо на шляху проходження пакетів буде вузол з меншим Maximum Transmission Unit, ніж у відправника або одержувача, і у них не буде засобів для виявлення даної колізії, то трафік буде непомітно відкидається. І ви не будете розуміти, що відбувається з каналом зв'язку; Іншими словами, «для вас настануть веселі дні».

Don't Fragment - ICMP не пройде!

Передача IPv4-пакетів із встановленим бітом Don't Fragment (більшість з них!) або IPv6-пакетів (пам'ятаємо, що в IPv6 немає фрагментації маршрутизаторами), які надто великі для передачі через інтерфейс, призведе до того, що маршрутизатор відкине пакет і сформує відповідь джерелу передачі з наступними помилками ICMP: Потрібна Фрагментація ( Fragmentation Required), або Пакет занадто великий ( Packet Too Big). Якщо відповіді з цими помилками не зможуть повернутися до відправника, він інтерпретуватиме відсутність підтверджуючих відповідей про доставку пакетів ACK ( Acknowledge) від одержувача як перевантаження / втрати та джерелом для повторної передачі пакетів, які також будуть відкидатися.

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

Дослідження шляху доставки пакетів

RFC 4821 був розроблений для того, щоб допомогти учасникам передачі трафіку в мережі обійти цю проблему, використовуючи дослідження шляхів розповсюдження пакетів (Path MTU Discovery (PLPMTUD). Стандарт дозволяє виявити максимальний обсяг даних (Maximum Transmission Unit (MTU), який може бути переданий протоколом за одну ітерацію шляхом поступового збільшення максимального розміру корисного блоку даних (Maximum Segment Size (MSS)), Щоб знайти максимально можливу величину пакета без його фрагментації на шляху прямування від передавача до приймача. Даний функціонал зменшує залежність від своєчасного отримання відповідей з помилками за протоколом міжмережевих керуючих повідомлень (Internet Control Message Protocol (ICMP)) і доступний у більшості мережевих стеків пристроїв та клієнтських операційних систем. На жаль, він не такий ефективний, як безпосереднє отримання даних про максимальний можливий розмір пакетів, що передаються. Будь ласка, дозвольте цим повідомленням протоколу ICMP повертатися до джерела передачі, добре?

Перевищення часу передачі пакетів

IPv4 - (Type11, Code0)
IPv6 - (Type3, Code0)

Traceroute - дуже корисний інструмент для усунення несправностей мережевих з'єднанняхміж двома хостами, що докладно описує кожен крок шляху.

Відправляє пакет із часом життя пакету даних для протоколу IP (Time to live (TTL)рівним 1 , щоб перший маршрутизатор надіслав повідомлення з помилкою (включно з власною IP-адресою) про перевищення часу життя пакета. Потім відправляє пакет з TTL 2 і так далі. Ця процедура необхідна для того, щоб виявити кожен вузол на шляху проходження пакетів.

NDP та SLAAC (IPv6)

Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Neighbour Solicitation (NS) (Type135, Code0)
Neighbour Advertisement (NA) (Type136, Code0)
Redirect (Type137, Code0)

У той час як IPv4 використовував протокол дозволу адрес (ARP) для зіставлення 2 і 3 рівнів мережевої моделі OSI, IPv6 використовує інший підхід як протокол виявлення сусідів (NDP). NDP надає безліч функцій, включаючи виявлення маршрутизатора, виявлення префікса, роздільну здатність адреси та багато іншого. Крім NDP, Автоконфігурація (StateLess Address AutoConfiguration (SLAAC)) дозволяє динамічно налаштовувати хост в мережі, аналогічно концепції протоколу динамічного налаштування вузла (Dynamic Host Configuration Protocol (DHCP) (хоча DHCPv6 призначається для більш тонкого керування).

Ці п'ять типів ICMP повідомлень не повинні блокуватися всередині вашої мережі (не враховуючи зовнішній периметр), щоб протокол передачі даних IP функціонував правильно.

Нумерація типів ICMP

Протокол міжмережевих керуючих повідомлень (ICMP) містить багато повідомлень, що ідентифікуються полем "тип".

Пара слів про обмеження швидкості

Хоча ICMP-повідомлення, подібні до тих, які описані в статті, можуть бути дуже корисними, пам'ятайте, що генерація всіх цих повідомлень займає процесорний час на ваших маршрутизаторах і генерує трафік. Ви дійсно очікуєте, що ви отримаєте 1000 пінгів на секунду через ваш брандмауер у звичайній ситуації? Чи вважатиметься це нормальним трафіком? Мабуть, ні. Обмежуйте пропускну спроможністьмережі для цих типів ICMP трафіку, як ви вважаєте за потрібне; цей крок може допомогти вам у захисті вашої мережі.

Читати, досліджувати та розуміти

Враховуючи, що обговорення теми «блокувати чи не блокувати» ICMP-пакетів, завжди призводить до плутанини, суперечок та розбіжностей, пропоную продовжити вивчати цю тему самостійно. На цій сторінці навів багато посилань, вважаю для більш повного розуміння проблематики слід витрачати час на їх читання. І зробити усвідомлений вибір того, що найкраще підходить для вашої мережі.

MikroTik: куди натиснути, щоб запрацювало?
За всіх своїх переваг, є у продукції компанії MikroTik один мінус - багато роз'єднаної і далеко не завжди достовірної інформації про її налаштування. Рекомендуємо перевірене джерело російською мовою, де все зібрано, логічно та структуровано – відеокурс « Налаштування обладнання MikroTik». До курсу входить 162 відеоуроки, 45 лабораторних робіт, питання для самоперевірки та конспект. Усі матеріали залишаються у вас безстроково. Початок курсу можна переглянути безкоштовно, залишивши заявку на сторінці курсу. Автор курсу є сертифікованим тренером MikroTik.

Як можна конфігурувати комп'ютери під керуванням Windows 2000/XP/2003 блокування Ping пакетів? Windows 2000/XP/2003 має вбудований механізм безпеки IP, званих IPSec (IP Security). IPSec це протокол, розроблений для захисту індивідуальних TCP/IP пакетів при передачі їх через мережу.

Однак ми не будемо вдаватися до подробиць функціонування та пристрою IPsec, оскільки крім шифрування, IPSec може також захищати ваш сервер або робочу станцію механізмом, схожим на фаєрвол.

Блокуємо PING на одиночному комп'ютері

Для блокування всіх PING пакетів з комп'ютера і на нього необхідно створити політику IPSec, яка буде блокувати весь ICMP трафік. Для початку перевірте, чи відповідає ваш комп'ютер на ICMP запити:

Для налаштування одиночного комп'ютера нам необхідно виконати такі кроки:

Конфігуруємосписок IP Filter Lists та Filter Actions

1. Відкрийте вікно MMC (Start > Run > MMC).
2. Додайте оснастку IP Security and Policy Management.

1. Виберіть який комп'ютер керуватиметься цією політикою – у нашому випадку це локальний комп'ютер. Натисніть Close, потім натисніть OK.

1. Правою кнопкою натисніть на IP Security Policies у лівій половині консолі MMC. Виберіть Manage IP Filter Lists and Filter Actions.

1. Вам не потрібно налаштовувати або створювати IP фільтр для ICMP (протокол у якому працює PING), оскільки такий фільтр вже існує за замовчуванням – All ICMP Traffic.

Однак ви можете налаштувати як завгодно складний IP фільтр, наприклад заборонити пінгувати ваш комп'ютер з усіх IP, крім кількох певних. В одній із наступних статей присвячених IPSec ми докладно розглянемо створення IP фільтрів, стежте за оновленнями.

1. У вікні Manage IP Filter Lists and Filter actions перегляньте ваші фільтри і якщо все гаразд натисніть на вкладку Manage Filter Actions. Тепер нам потрібно додати дію для фільтра, який блокуватиме певний трафік, натиснемо Add.

1. У першому вікні привітання натискаємо Next.
2. У полі Filter Action Name вводимо Block та натискаємо Next.

1. У Filter Action General Options вибираємо Block, після чого тиснемо Next.

1. Поверніться у вікно Manage IP Filter Lists and Filter actions і перегляньте ваші фільтри і якщо все гаразд, натисніть Close. Ви можете додати фільтри та дії для фільтрів у будь-який час.

Наступним кроком буде конфігурування політики IPSec та її застосування.

Конфігуруємо політику IPSe

1. У тій же консолі MMC натисніть правою кнопкою по IP Security Policies і виберіть Create IP Security Policy.

1. Пропустіть привітання майстра, натиснувши Next.
2. У полі IP Security Policy Name введіть відповідне ім'я, наприклад “Block PING”. Натисніть Next

1. У вікні Запитів безпечного з'єднання зніміть галочку з чекбоксу Active the Default Response Rule. НатиснітьNext

1. Позначте чекбокс змінити властивості та натисніть Finish.

1. Нам потрібно додати IP фільтри та дії фільтрів до нової політики IPSec. У вікні новий політиці IPSec натисніть Add

1. Натисніть кнопку Next.
2. У вікні Tunnel Endpoint переконайтеся, що вибрано значення за промовчанням і натисніть Next.

Блокування відповідей пінг в ОС може запобігти атакам флуду ICMP пакетів, але більшість систем використовують цю послугуонлайн моніторингу (системного моніторингу). У своїй темі «заблокувати Ping (ICMP) відповідей у ​​Unix/Linux» я розповім як можна його вимкнути.

Блокування PING на сервер є корисним, якщо сервер постійно стикається з якоюсь DoS атакоюза допомогою функції PING. При використанні IPTables ми можемо просто зупинити заборону проходження пакетів ICMP (власне, заборонити PING) на сервер. Перед початком цього необхідно мати уявлення про те, що таке Iptables у Linux. Iptables - це система міжмережевого екрану з набором правил, які контролює вхідні та вихідні пакети. За замовчуванням в Iptables працює без будь-яких правил, ви можете створювати, додавати, редагувати правила.

Відключення Ping використовуючи iptables

Пояснення деяких параметрів в iptables, які необхідні для створення правил управління пакетами ICMP:

A: Додає правила.
-D: Видаляє правило з таблиці.
-p: Опція, щоб вказати протокол (де icmp).
-icmp-type: Опція для вказівки типу.
-J: Перейти до ланцюжка.

Нижче я наведу наочні приклади.

Як заблокувати PING на сервері з виведенням повідомлень про помилку?
Таким чином, ви можете частково блокувати PING з виводом повідомлення про помилку Destination Port Unreachable. Додайте наступні правила Iptables, щоб заблокувати PING з виведенням повідомлення про помилку:

# iptables -A INPUT -p icmp --icmp-type echo-request -j REJECT

Заблокувати PING на серверібез будь-яких повідомлень про помилки.
Для цього використовуємо команду для ІПтейбелс:

# iptables -A OUTPUT -p icmp --icmp-type echo-request -j DROP # iptables -A INPUT -p icmp --icmp-type echo-reply -j DROP

Заблокує всі вхідні та вихідні пакети ICMP на сервері.

Дозволити Ping використовуючи iptables

Якщо ви заблокували ping на сервері і не знаєте як повернути назад. То я зараз розповім, як це зробити. А робиться це, додавши наступне правило в IPtables:

# iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT # iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT

Дані правила дозволять проходження ICMP пакетів із сервера та на нього.

Блокування Ping із параметрами Kernel

Ми можемо також блокувати пінг відповіді безпосередньо параметрами ядра. Можна заблокувати відповіді на пінг тимчасово або постійно, і внизу показано, як це зробити.

Тимчасове блокування Ping
Ви можете заблокувати тимчасово відповіді на пінг, використовуючи наступну команду

# echo "1" >

Щоб розблокувати цю команду, виконайте таке:

# echo 0 >/proc/sys/net/ipv4/icmp_echo_ignore_all

Заборонити Ping взагалі
Ви можете заблокувати пінг відповіді додаючи наступний параметрв конфігураційний файл:

# vim /etc/sysctl.conf

І прописати:

[...] net.ipv4.icmp_echo_ignore_all = 1 [...]

sysctl використовується для зміни параметрів ядра під час виконання, один із цих параметрів може бути «ping daemon» (демон пінгу), якщо ви хочете відключити пінг, то ви просто повинні виконати щось на зразок:

# sysctl -w net.ipv4.icmp_echo_ignore_all=1

Тепер спробуйте пінгувати машину, жодних відповідей на неї немає, чи не так? Для повторного включення пінгу використовуйте:

# sysctl -w net.ipv4.icmp_echo_ignore_all=0

W прапор використовується, якщо потрібно змінити деякі настройки.

Тепер виконайте наступну команду, щоб негайно застосувати налаштування без перезавантаження системи:

# sysctl -p

# sysctl --system

Ось мій повний конфіг:

# cd /usr/local/src && wget http://сайт/wp-content/uploads/files/sysctl_conf.txt

і потім можна виконати:

# cp /usr/local/src/sysctl_conf.txt /etc/sysctl.conf

На цьому у мене все тема «Заблокувати Ping (ICMP) відповідей у ​​Unix/Linux» завершена.