Заборонити icmp трафік до свого vpn. Cisco ACL для сучасних. Розширені списки доступу. Скидати або дозволити трафік з певних MAC адрес
Отже, продовжуємо розумітися на ACL. На цей раз, у нас розширені ACL. Топологію візьмемо від попередньої статті, сподіваюся, ви її вивчили досконало. Якщо це не так, то дуже рекомендую прочитати, щоб матеріали цієї статті були зрозумілішими.
Насамперед почну з того, що таке розширені ACL. Розширені ACL дозволяють, крім адреси джерела, вказати протокол, адресу призначення та порти. А також спеціальні параметри певного протоколу. Найкраще вчитися на прикладах, тому сформуємо нове завдання, ускладнивши попереднє. До речі, комусь може цікаво буде зайнятися питаннями розподілу трафіку за пріоритетами, раджу ось QoS Classification and Marking гарну статтю, правда англійською. Ну а поки що, повернемося до нашого завдання:
Завдання.
- Дозволити echo-запити із вузлів мережі 192.168.0.0/24 на сервер.
- Із сервера – заборонити echo-запити у внутрішню мережу.
- Дозволити WEB-доступ на сервер із вузла 192.168.0.11.
- Дозволити 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<имя>
Отже, починаємо формувати правила.
- Дозволяємо пінги з мережі 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 Ну якось так. Тепер, якщо перевірити пінги - легко помітити, що все добре працює. Тут, щоправда, нас чекає один сюрприз, який спливе трохи пізніше. Поки не розкриватиму. Хто здогадався – молодець! - З сервера – забороняємо всі запити 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
Ось тепер не причепитися. Все проходить чудово!
- Дозволяємо 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працювати буде так само добре. Але сенс трохи інший.
У коментах дайте відповідь, що буде безпечнішим?
- Дозволяємо 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))
Нерідко користувачів дратує повільність у роботі інтернету. Особливо це стосується численної армії любителів мережевих ігор. Можна скоротити час потенційних затримок, вимкнувши функцію ping.
Вам знадобиться
- - ПК із встановленою операційною системою Windows;
- - доступ в Інтернет.
Інструкція
Інструкція
Навчитися налаштування MikroTik можна на онлайн курсі з обладнання цього виробника. Автор курсу є сертифікованим тренером MikroTik. Детальніше Ви можете прочитати наприкінці статті.
Стаття відповідає питанням наскільки небезпечно блокувати ICMP трафік.
ICMP - яблуко розбрату
Багато адміністраторів мережі вважають, що протокол міжмережевих керуючих повідомлень (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)), Щоб знайти максимально можливу величину пакета без його фрагментації на шляху прямування від передавача до приймача. Цей функціонал зменшує залежність від своєчасного отримання відповідей з помилками протоколу міжмережевих керуючих повідомлень (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) містить багато повідомлень, що ідентифікуються полем "тип".
| Тип | Найменування | Специфікація |
|---|---|---|
| 0 | Echo Reply | |
| 1 | Unassigned | |
| 2 | Unassigned | |
| 3 | Destination Unreachable | |
| 4 | Source Quench (Deprecated) | |
| 5 | Redirect | |
| 6 | Alternate Host Address (Deprecated) | |
| 7 | Unassigned | |
| 8 | Echo | |
| 9 | Router Advertisement | |
| 10 | Router Solicitation | |
| 11 | Time Exceeded | |
| 12 | Parameter Problem | |
| 13 | Timestamp | |
| 14 | Timestamp Reply | |
| 15 | Information Request (Deprecated) | |
| 16 | Information Reply (Deprecated) | |
| 17 | Address Mask Request (Deprecated) | |
| 18 | Address Mask Reply (Deprecated) | |
| 19 | Reserved (for Security) | Solo |
| 20-29 | Reserved (for Robustness Experiment) | ZSu |
| 30 | Traceroute (Deprecated) | |
| 31 | Datagram Conversion Error (Deprecated) | |
| 32 | Mobile Host Redirect (Deprecated) | David_Johnson |
| 33 | IPv6 Where-Are-You (Deprecated) | |
| 34 | IPv6 I-Am-Here (Deprecated) | |
| 35 | Mobile Registration Request (Deprecated) | |
| 36 | Mobile Registration Reply (Deprecated) | |
| 37 | Domain Name Request (Deprecated) | |
| 38 | Domain Name Reply (Deprecated) | |
| 39 | SKIP (Deprecated) | |
| 40 | Photuris | |
| 41 | ICMP messages utilized by experimental mobility protocols such as Seamoby | |
| 42 | Extended Echo Request | |
| 43 | Extended Echo Reply | |
| 44-252 | Unassigned | |
| 253 | RFC3692-style Experiment 1 | |
| 254 | RFC3692-style Experiment 2 | |
| 255 | Reserved |
Пара слів про обмеження швидкості
Хоча ICMP-повідомлення, подібні до тих, які описані в статті, можуть бути дуже корисними, пам'ятайте, що генерація всіх цих повідомлень займає процесорний час на ваших маршрутизаторах і генерує трафік. Ви дійсно очікуєте, що ви отримаєте 1000 пінгів на секунду через ваш брандмауер у звичайній ситуації? Чи вважатиметься це нормальним трафіком? Мабуть, ні. Обмежуйте пропускну спроможністьмережі для цих типів ICMP трафіку, як ви вважаєте за потрібне; цей крок може допомогти вам у захисті вашої мережі.
Читати, досліджувати та розуміти
Враховуючи, що обговорення теми «блокувати чи не блокувати» ICMP-пакетів, завжди призводить до плутанини, суперечок та розбіжностей, пропоную продовжити вивчати цю тему самостійно. На цій сторінці навів багато посилань, вважаю для більш повного розуміння проблематики слід витрачати час на їх читання. І зробити усвідомлений вибір того, що найкраще підходить для вашої мережі.
MikroTik: куди натиснути, щоб запрацювало?
За всіх своїх переваг, є у продукції компанії MikroTik один мінус - багато роз'єднаної і далеко не завжди достовірної інформації про її налаштування. Рекомендуємо перевірене джерело російською мовою, де все зібрано, логічно та структуровано – відеокурс « Налаштування обладнання MikroTik». До курсу входить 162 відеоуроки, 45 лабораторних робіт, питання для самоперевірки та конспект. Усі матеріали залишаються у вас безстроково. Початок курсу можна переглянути безкоштовно, залишивши заявку на сторінці курсу. Автор курсу є сертифікованим тренером MikroTik.
Брандмауер - перша лінія захисту будь-якого сервера і від нього правильного налаштуваннязалежить, чи зловмисник зможе просунутися далі у своїх спробах проникнення в систему. Сучасні фаєри пропонують безліч механізмів забезпечення безпеки, використовуючи які ти можеш залишити «не при ділі» 99% атакуючих. І все це без необхідності купівлі дорогого обладнання та комерційного софту.
Головна мета всіх зломщиків – отримання доступу до командного інтерпретатора сервера для використання його можливостей у своїх інтересах. Найчастіше проникнення в «свята святих» здійснюється за допомогою дір у сервісах або через підбір пароля (брутфорс) до одного з них (наприклад, ssh).
Сканування портів
Щоб виявити наявність уразливих сервісів на машині, атакуючий здійснює розвідку за допомогою сканера портів та різних систем виявлення вразливостей. Зазвичай як сканер портів використовується nmap, який здатний здійснювати сканування десятком різних способіві в деяких випадках вміє виявляти версії ОС та сервісів. Ось список особливо популярних прапорів nmap, які зазвичай використовують хакери:
Прапори nmap, які використовуються при скануванні
- -sT - звичайне TCP-сканування за допомогою відкриття з'єднання на вказаний порт та його завершення;
- -sS - SYN/ACK-сканування, зв'язок розривається відразу після відповіді на запит відкриття з'єднання;
- -sU – UDP-сканування;
- -sF - сканування пакетами із встановленим прапором FIN;
- -sX - сканування пакетами із встановленими прапорами FIN, PSH та URG;
- -sN – сканування пакетами без встановлених прапорів.
Метод захисту від сканування простий і відомий будь-якому системному адміністратору. Полягає він у простому закритті всіх сервісів, які повинні бути видно із зовнішньої мережі. Наприклад, якщо на машині працюють сервіси ssh, samba та apache, а із зовнішнього світу має бути видно лише веб-сервер з корпоративною веб-сторінкою, то міжмережевий екран може бути налаштований так:
Початкове налаштування iptables
outif="eth1"
iptables -F
iptables -i $outif -A INPUT \
-m conntrack \
--ctstate ESTABLISHED,RELATED \
-j ACCEPT
iptables -i $outif -A INPUT -p tcp \
--dport 80 -j ACCEPT
iptables -i $outif -P INPUT DROP
iptables -i $outif -P OUTPUT ACCEPT
Початкове налаштування ipfw
outif="rl0"
ipfw add allow ip from any to any \
via lo0
ipfw add allow ip from me to any \
via $outif
ipfw add allow tcp from any to me \
established via $outif
ipfw add allow tcp from any 80 \
to me via $outif
ipfw add deny ip from any to any \
via $outif
Початкове налаштування pf
outif="rl0"
set skip on lo0
block all
pass out on $outif from $outif \
to any keep state
pass in on $outif proto from any \
to $outif port 80
Всі три набори правил роблять те саме - дозволяють проходження будь-якого трафіку по інтерфейсу зворотної петлі (loopback), дозволяють приймати пакети вже встановлених з'єднань (щоб, наприклад, браузер міг отримати відповідь на запит до віддаленому серверу), дозволяють звернення на 80-й порт, блокуючи решту, і дозволяють будь-які коннекти назовні. Зверніть увагу, що якщо в прикладах iptables та ipfw ми явно задали правила для дозволу прийому пакетів вже встановлених з'єднань (established), то у випадку з pf для цього достатньо було вказати «keep state» у рулісеті, що дозволяє будь-які вихідні з'єднання.
Загалом, така схема захисту мережевих сервісів від сканування та проникнення чудово працює, але ми можемо піти далі і налаштувати фаєр так, щоб деякі види сканування взагалі не могли б бути виконані. Технічно ми не можемо зробити це щодо звичайного сканування (прапори nmap "-sT", "-sS" та "-sU") просто тому, що в ньому немає нічого кримінального, проте нестандартні типи сканування, такі як "-sN", "-sF" та "-sX" породжують пакети, які ніяк не могли бути створені легальними додатками.
Тому без тіні сумніву відкидаємо такі сполуки.
Методи боротьби з екзотичними видами сканування
# Заборона FIN-сканування
Linux> iptables -A INPUT -p tcp \
-m tcp \
--tcp-flags FIN,ACK FIN -j DROP
FreeBSD>
не встановлено tcpflags fin
# Заборона X-сканування
Linux>
--tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG \
-j DROP
FreeBSD> ipfw add reject tcp from any to any \
tcpflags fin, syn, rst, psh, ack, urg
# Заборона N-сканування
Linux> iptables -A INPUT -p tcp -m tcp \
–-tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE –j DROP
FreeBSD> ipfw add reject tcp from any to any \
tcpflags !fin, !syn, !rst, !psh, !ack, !urg
У OpenBSD всі ці рядки можна замінити простим записом на початку
/etc/pf.conf:
scrub in all
Директива scrub активує механізм нормалізації пакетів, при якому фрагментовані пакети від'єднуються, а пакети з неприпустимою комбінацією прапорів відкидаються. Крім екзотичних видів сканування scrub дозволяє захиститися від обману систем виявлення вторгнень (посилання сильно фрагментованих пакетів) і деяких видів DoS-атак.
Для захисту від SYN/ACK-сканування, ініційованого за допомогою nmap-прапора "-sS", ми можемо використовувати метод пасивного визначення ОС (OS Fingerprint), доступний у брандмауерах pf та iptables/netfilter (починаючи з версії 1.4.6). Під час проведення звичайного сканування (прапор "-sT") nmap використовує стандартний інтерфейс сокетів операційної системи, тому такий скан майже нічим не відрізняється від потоку звичайних пакетів (нижче ми розглянемо деякі його відмінності), проте при SYN/ACK-скануванні nmap формує пакети самостійно, тому вони мають деякі риси, які видають їхнє джерело. Метод пасивного визначення ОС дозволяє ідентифікувати ці пакети та відкинути їх за допомогою стандартних правил фаєрволу:
OpenBSD> block in quick from any os NMAP
Linux> iptables -I INPUT -p tcp -m osf --genre NMAP \
-j DROP
Модуль osf брандмауера iptables/netfilter використовує базу відбитків, зібрану та оновлювану розробниками OpenBSD (/etc/pf.os), тому обидва ці правила повинні привести до однакових результатів. Цікаво також і те, що вони дозволяють ефективно протидіяти функції визначення ОС утиліти nmap (прапор "-O").
Тепер ми захищені майже від усіх видів сканування, крім стандартного та тупого "-sT". Як бути із ним? Насправді, все просто. Факт сканування портів легко помітити, просто проаналізувавши логи фаєрвола. Якщо за короткий проміжок часу відбувалося безліч коннектів на різні порти – значить нас сканували. Залишилося лише перекласти цю ідею на правила брандмауера. Для iptables є відмінний рецепт, який блокує всіх, хто надто наполегливо стукає у неробочі порти:
Боротьба зі скануванням за допомогою iptables
# Перевірка на стукіт у неробочі порти (10 на годину)
--seconds 3600 --hitcount 10 --rttl -j RETURN
# Друга перевірка на стукіт у неробочі порти (2 за хвилину)
iptables -A INPUT -m recent --rcheck \
--seconds 60 --hitcount 2 --rttl -j RETURN
# Заносимо адреси тих, хто стукає до списку
iptables -A INPUT -m recent --set
# Відкидаємо пакети всіх, хто перевищив ліміт на
кількість підключень
iptables -P INPUT -j DROP
Встановивши пакет xtables-addons, що містить напрацювання проекту patch-omatic, ми отримаємо доступ до модуля PSD (Port Scan Detect), реалізованого за образом і подобою демона scanlogd. Усі попередні рядки можуть бути легко замінені простим правилом:
# iptables -A INPUT -m psd -j DROP
На жаль, у пакетних фільтрах ipfw і pf нічого подібного немає, але це не біда, тому що сканування портів добре протидіє демон PortSentry і той самий scanlogd.
Заборона Icmp-повідомлень
Хорошою практикою є заборона ICMP-повідомлень, які можуть видати додаткову інформаціюпро хост або використовуватися для виконання різних зловмисних дій (наприклад, модифікації таблиці маршрутизації). Нижче наведено таблицю зі списком можливих типів ICMP-повідомлень:
Типи ICMP-повідомлень
- 0 - echo reply (echo-відповідь, пінг)
- 3 - destination unreachable (адресат недосяжний)
- 4 - source quench (придушення джерела, прохання надсилати пакети повільніше)
- 5 - redirect (редирект)
- 8 - echo request (echo-запит, пінг)
- 9 - router advertisement (оголошення маршрутизатора)
- 10 - router solicitation (клопотання маршрутизатора)
- 11 - time-to-live exceeded (закінчення терміну життя пакету)
- 12 - IP header bad (неправильний IP-заголовок пакета)
- 13 - timestamp request (запит значення лічильника часу)
- 14 - timestamp reply (відповідь на запит значення лічильника часу)
- 15 - information request (запит інформації)
- 16 - information reply (відповідь на запит інформації)
- 17 - address mask request (запит маски мережі)
- 18 - address mask reply (відповідь на запит маски мережі)
Як бачиш, відповідь на деякі ICMP-повідомлення може призвести до розголошення деякої інформації про хост, тоді як інші – привести до модифікації таблиці маршрутизації, тому їх необхідно заборонити.
Зазвичай вихід у світ дозволяють ICMP-повідомленням 0, 3, 4, 11 і 12, тоді як на вхід приймають лише 3, 8 і 12.
Заборона небезпечних ICMP-повідомлень
Linux> iptables -A INPUT -p icmp \
-icmp-type 3,8,12 -j ACCEPT
Linux> iptables -A OUTPUT -p icmp \
-icmp-type 0,3,4,11,12 -j ACCEPT
FreeBSD> ipfw add allow icmp \
from any to $outif in \
via $outif icmptype 3,8,12
FreeBSD> ipfw add allow icmp \
from $outif to any out \
via $outif icmptype 0,3,4,11,12
OpenBSD> pass in inet proto icmp \
from any to $outif \
icmp-type ( 3, 8, 12 ) keep state
OpenBSD> pass out inet proto icmp \
від $outif to any \
icmp-type ( 0, 3, 4, 11, 12 ) \
keep state
За бажання ти можеш заборонити весь ICMP трафік, включаючи пінг-запити, але це може вплинути на коректність роботи мережі.
Брутфорс
Розвідавши інформацію про відкритих портахі ОС, зломщик робить спроби проникнення в систему, які можуть бути засновані на експлуатації дірок у сервісах, або на доборі паролів. Запобігти можливості злому сервісів брандмауер нам не допоможе, проте загальмувати процес перебору паролів - легко. Для цього застосовуються можливості обмеження кількості пакетів, що прийшли на машину з однієї IP-адреси. Ось як це можна зробити за допомогою iptables:
Захист від брутфорсу за допомогою iptables
# Ланцюжок для перевірки з'єднань
iptables -N brute_check
# Блокування адреси, якщо за 60
секунд він ініціював більше 2-х з'єднань
--update --seconds 60 \
--hitcount 3 -j DROP
# Якщо ні - дозволяємо з'єднання та
заносимо адресу до списку
iptables -A brute_check -m recent \
--set -j ACCEPT
# Очищаємо ланцюжок INPUT
iptables -F INPUT
# Відправляємо в ланцюжок brute_check
всіх, хто намагається підключитися до
22-му порту
--ctstate NEW -p tcp \
--dport 22 -j brute_check
iptables -P INPUT DROP
Те саме можна зробити і з використанням pf:
Захист від брутфорсу за допомогою pf
# Створюємо таблицю для брутфорсерів
table
# Блокуємо всіх, хто до неї потрапляє
block in quick from
# Поміщаємо в таблицю bruteforcers всіх, хто ініціює більше двох з'єднань на 22-й порт на хвилину
pass in on $ext_if inet proto tcp to $outif \
port 22 flags S/SA keep state \
(max-src-conn-rate 60/2, \ overload
Брандмауер ipfw не має достатньої функціональності для ефективної протидії брутфорсерам, тому його користувачі повинні використовувати інструменти більше високого рівня, такі як спеціальні модулі PAM, системи виявлення вторгнень та програми на зразок sshguard.
Спуфінг
Спуфінг (підміна адреси відправника пакета) може бути використаний для здійснення DoS-атак або обходу брандмауера. У першому випадку спуфінг дає величезну перевагу атакуючому, так як суттєво ускладнює реакцію на атаку (пакети, що приходять з абсолютно різними адресами відправника, не так просто класифікувати та заблокувати) і затягує процес закриття нових з'єднань (зазвичай підроблена адреса недосяжна, тому закриття з'єднання відбувається лише після закінчення таймууту). Спуфінг, що здійснюється для обходу системи захисту, менш небезпечний і в більшості випадків контролюється.
Досить часто, блокуючи зовнішні мережеві сервісихоста, системні адміністраторизалишають їх відкритими для певного діапазону адрес (наприклад, для підключення зі своєї домашньої машини). Обчисливши одну з цих адрес, зломщик може сформувати пакет, вказавши цю адресу як зворотну, і таким чином прослизнути через брандмауер. Далі він може вгадати номери послідовності TCP-пакетів і зробити так, щоб сервіс, що довіряє зворотній адресі, виконав необхідну йому дію. Це дуже важка в реалізації атака, яка може бути виконана грамотним фахівцем, а якщо йдеться про протокол UDP, то це під силу і кулхацкеру.
На щастя, захиститись від подібних атак легко. Достатньо не відкривати порти незахищених сервісів у зовнішній світ, а у разі різкої необхідності використовувати захисні системи самих сервісів (наприклад, сертифікати ssh) або механізм «стукання в порти» (про нього розказано наприкінці статті).
Ситуація стає складнішою, коли справа стосується мережевого мосту, що розділяє внутрішню та зовнішню мережі (або дві локальні мережі). Довірчі відносини всередині локальної мережі- звичайна справа. Сервіси доступні для всіх, ніякої аутентифікації, шифрування і т.д. - просто ласий шматочок для зломщика. Перебуваючи у зовнішній мережі, він може дізнатися мережну маску внутрішньої мережі та сформувати пакети з відповідною зворотною адресою, що призведе до отримання доступу до всіх ресурсів локалки. Це справді небезпечна ситуація, але її легко запобігти за допомогою правильного налаштування брандмауера або ОС.
Для цього достатньо заборонити проходження пакетів, зворотні адреси яких відповідають використовуваним у внутрішній мережі із зовнішнього інтерфейсу:
Linux> iptables -A INPUT -i $outif \
-s 192.168.1.0/24 -j DENY
FreeBSD> ipfw add deny ip from \
192.168.1.0/24 to any via $outif
OpenBSD> block in on $outif from \
192.168.1.0/24 to any
В якості альтернативи або додаткового захисту можна (і навіть потрібно) використовувати спеціальні директиви ipfw і pf і налаштування ядра Linux:
Linux > echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
FreeBSD> ipfw add deny ip з будь-якої ніби antispoof в
OpenBSD> antispoof quick for $ext_if
Ці три команди призводять до однакових результатів. Усі пакети, обернені адреси яких відповідають масці мережі іншого інтерфейсу, відкидаються.
Корисності IPTABLES
Наприкінці статті ми розглянемо кілька цікавих можливостей iptables/netfilter, які можуть бути корисними для захисту сервера від проникнень. Почнемо з механізму віддаленого керуваннябрандмауером, який отримав ім'я «стукіт у порти» (port knoking). Суть його полягає в тому, щоб змусити фаєрвол виконувати певні дії після підключення до заданого порту. Нижче наведено приклад правил, що відкривають порт SSH на 10 секунд після «стуку» в 27520 порт:
iptables та port knocking
# Ланцюжок для перевірки з'єднань на порт, що захищається
iptables -N knock
# Дозволяємо з'єднання, якщо стукіт був протягом останніх
10 секунд
iptables -A knock -m recent --rcheck --seconds 10 \
-j ACCEPT
# Очищаємо INPUT
iptables -F INPUT
# Дозволяємо все, що відноситься до вже встановленим з'єднанням
iptables -A INPUT -m conntrack \
--ctstate ESTABLISHED,RELATED -j ACCEPT
# Усі спроби відкрити з'єднання з 22-м портом відправляємо
на перевірку в ланцюжок knock
-p tcp --dport 22 -j knock
# Заносимо адресу того, хто стукає в 27520-й порт у список
iptables -A INPUT -m conntrack --ctstate NEW \
-p tcp --dport 27520 -m recent --set
# При стуку до сусідніх портів видаляємо адресу зі списку
iptables -A INPUT -m conntrack --ctstate NEW -p tcp \
-m multiport --dport 27519,27521 -m recent --remove
# Забороняємо все
iptables -P INPUT DROP
Третє з кінця правило додає адресу того, хто стукає в список. Якщо та ж машина протягом 10 секунд після стуку звернеться до 22-го порту, з'єднання буде встановлено. Передостаннє правило – захист від «перебору стукоту». Якщо зловмисник спробує стукати послідовно у всі порти з надією, що один з них відкриє 22-й порт, спрацює це правило, і його адреса буде видалена зі списку одразу після потрапляння до нього.
Друга корисність iptables поширюється в пакеті xtables-addons (patch-o-matic) та носить ім'я TARPIT. Це дія (така ж, як ACCEPT або DENY), яка "підвішує" з'єднання, не дозволяючи атакуючій стороні його закрити. З'єднання, пакети якого потрапляють у TARPIT, буде встановлене, однак розмір вікна дорівнюватиме нулю, завдяки чому віддалена машина не зможе відправляти дані, витрачаючи свої ресурси, а з'єднання буде закрито тільки після закінчення таймууту. TARPIT можна використовувати в екстрених випадках для захисту від DoS:
# iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT
Або ж для введення атакуючого в оману та боротьби проти сканерів
портів (тільки звичайне TCP-сканування, "-sT"):
# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
# iptables -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
# iptables -A INPUT -p tcp -m tcp -j TARPIT
Ці правила створюють видимість системи, в якій відкриті всі порти, однак під час спроби підключення до будь-якого з них (крім 80 і 25) з'єднання «підвисатимуть». Того ж результату, але без «провислих» з'єднань, можна досягти за допомогою дії DELUDE, яка правильно відповідає на всі спроби ініціації з'єднання, але посилає RST-пакет у відповідь на решту пакетів. Для ще більшого заплутування атакуючого ти можеш використовувати дію CHAOS, яка випадково активує одну з двох описаних вище дій.
Висновки
Маючи достатню кількість знань і вдумливо читаючи документацію, ти можеш створити дуже міцний бастіон, до якого не так просто просто підібратися. Сучасні брандмауери, особливо pf і iptables, пропонують безліч засобів захисту від непроханих гостей, які ти можеш отримати абсолютно безоплатно.
Links
- sf.net/projects/sentrytools - PortSentry
- www.openwall.com/scanlogd - scanlogd
Боротьба з витіканням ресурсів
При використанні дії TARPIT обов'язково додай у конфіг наступне правило, інакше «провислі» з'єднання з'їдатимуть ресурси при обробці підсистемою conntrack:
# iptables -t raw -I PREROUTING -p tcp --dport 25 -j NOTRACK