ICMP - яблуко розбрату
Багато мережних адміністратори вважають, що протокол міжмережевих керуючих повідомлень (Internet Control Message Protocol (ICMP) являє собою загрозу безпеці і тому повинен завжди блокуватися на брандмауері. Це правда, що протокол має деякі пов'язані з цим проблеми безпеки, і що частина запитів повинна бути заблокована . Але це не привід блокувати весь ICMP-трафік!
ICMP-трафік має багато важливих функцій; якісь з них корисні для усунення неполадок, інші ж необхідні для належного функціонування мережі. Нижче наведено відомості про деякі важливих складових ICMP протоколу, про які ви повинні знати. Слід подумати над тим, як оптимальним чином пропускати їх через вашу мережу.
Echo запит і and Echo відповідь
IPv4 - Echo запит (Type8, Code0) і Echo відповідь (Type0, Code0)
IPv6 - Echo запит (Type128, Code0) and Echo відповідь (Type129, Code0)
Ми всі добре знаємо, що ping. - один з перших інструментів для пошуку і усунення неполадок. Так, якщо ви дозволите на своєму обладнання обробку ICMP-пакетів, то це означає, що ваш хост тепер доступний для виявлення, але хіба ваш веб-сервер вже не слухає порт 80, і не відправляє відповіді на клієнтські запити? Звичайно, заблокуйте ще й ці запити, якщо ви дійсно хочете, щоб на кордоні мережі була ваша DMZ. Але блокуючи ICMP трафік усередині вашої мережі, що не підсилите захист, навпаки отримаєте систему з надмірно складним процесом пошуку та усунення неполадок ( «Перевірте будь ласка відгукується чи шлюз на мережеві запити?», «Ні, але це мене анітрохи не засмучує, тому що мені це нічого не скаже! »).
Пам'ятайте, також можете дозволити проходження запитів в певному напрямку; наприклад, налаштувати обладнання так, щоб Echo запити з вашої мережі проходили в мережу Інтернет і Echo відповіді з Інтернету в вашу мережу, але не навпаки.
Необхідна фрагментація пакета (IPv4) / Пакет занадто великий (IPv6)
IPv4 - (Type3, Code4)
IPv6 - (Type2, Code0)
Do not Fragment - ICMP не пройде!
Передача IPv4-пакетів з встановленим бітом Do not 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 - дуже корисний інструмент для усунення неполадок в мережевих з'єднаннях між двома хостами, детально описує кожен крок шляху.
NDP and 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)
Ці п'ять типів ICMP повідомлень не повинні блокуватися всередині вашої мережі (не враховуємо зовнішній периметр), щоб протокол передачі даних IP функціонував правильно.
Пара слів про обмеження швидкості
Хоча ICMP-повідомлення, подібні до тих, які описані в статті, можуть бути дуже корисними, пам'ятайте, що генерація всіх цих повідомлень займає процесорний час на ваших маршрутизаторах і генерує трафік. Ви дійсно очікуєте, що ви отримуєте 1000 пінгів в секунду через брандмауер в звичайній ситуації? Чи буде це вважатися нормальним трафіком? Ймовірно, немає. Обмежуйте пропускну здатність мережі для цих типів ICMP трафіку, як ви вважаєте за потрібне; цей крок може допомогти вам у захисті вашої мережі.
Читати, досліджувати і розуміти
З огляду на, що обговорення теми «блокувати або не блокувати» ICMP-пакетів, завжди призводить до плутанини, суперечок і розбіжностей, пропоную продовжити вивчати цю тему самостійно. На цій сторінці привів багато посилань, вважаю для більш повного розуміння проблематики слід витратити час на їх читання. І зробити усвідомлений вибір того, що найкраще підходить для вашої мережі.
Ось уже понад 10 років допомагаю компаніям, знайомим і друзям будувати комп'ютерні мережі і налаштовувати системи і додатки для швидкого і якісного взамодействия.
Читайте також
