1. З чого все почалося?
2. «DoS attack protection» із застереженням ...
3. Переходимо до практики
4. На закінчення
5. Відеокурс «Налаштування обладнання MikroTik» (аналог MTCNA)

У процесі підвищення навичок роботи з Mikrotik і RouterOS зокрема, дуже важливо мати в своєму розпорядженні додатковий пристрій RouterBOARD для можливості проведення різноманітних експериментів. Чому це так важливо?
Операційна система RouterOS кардинально відрізняється від програмного забезпечення, що використовується в домашніх і SOHO-маршрутизаторах. Функціональні можливості ROS вже з коробки перевершує можливості таких систем як OpenWRT, DD-WRT і NDMS 2 (використовується в пристроях Zyxel Keenetic).
Функцій RouterOS настільки багато, що середньостатистичний адміністратор просто не володіє достатніми знаннями і досвідом для роботи з усіма функціями пристрою.
Для повного розуміння, просто погляньте на перелік сертифікатів, які видаються авторизованим фахівцям.

Всього у Mikrotik є 3 рівня. На першому рівні знаходиться єдиний сертифікат - MTCNA (MikroTik Certified Network Associate), це базовий сертифікат, що підтверджує базові навички настройки RouterOS, чого буде достатньо більшості фахівців і адміністраторів.
Другий рівень умовно можна назвати «Engineer», по суті це інженерна підготовка. На другому рівні налічується вже 5 сертифікатів (програм підготовки):

• MTCWE (MikroTik Certified Wireless Engineer) - розширений поглиблений курс по налаштуванню бездротових мереж;
• MTCRE (MikroTik Certified Routing Engineer) - розширений поглиблений курс по статичної та динамічної маршрутизації;
• MTCTCE (MikroTik Certified Traffic Control Engineer) - розширений поглиблений курс з управління трафіком і QoS;
• MTCUME (MikroTik Certified User Management Engineer) - розширений поглиблений курс з управління користувачами і авторизацією (VPN, HotSpot, IPsec і т.д.);
• MTCIPv6E (MikroTik Certified IPv6 Engineer) - розширений поглиблений курс по роботі з IPv6;

Для отримання сертифіката другого рівня обов'язково потрібна наявність сертифікату MTCNA. На третьому рівні є всього 1 сертифікат - MTCINE (MikroTik Certified Inter-networking Engineer).
Для того, щоб отримати сертифікат MTCINE, обов'язково потрібно мати сертифікати MTCNA і MTCRE. Курси MTCINE націлені на мережевих інженерів, що працюють на рівні провайдера. Серед тем, які вивчаються в рамках даних курсів - використання BGP і MPLS.
Як бачите, у Mikrotik є окремі курси за різними напрямками. Базовим сертифікатом є MTCNA, який гарантує наявність базових знань по роботі з RouterOS.
В реальних умовах далеко не кожен фахівець, який працює з Mikrotik, має навіть базовий сертифікат. Чого вже говорити про домашніх користувачів і співробітників малого і навіть середнього бізнесу. Особисто у мене сертифіката MTCNA немає, бажання правда є, а от зайві гроші і час відсутні.
До чого все це і чому я зробив таку велику ліричний вступ?
про наслідки неправильної настройки Mikrotik я вже писав, причому на реальних прикладах. Незважаючи на моє повідомлення, один з провайдерів до цього дня не закрив уразливості в своїй мережі, і таких прикладів знайдуться тисячі.
Саме тому при роботі з Mikrotik для просунутих користувачів важливо зберігати логи і мати додатковий пристрій, на якому можна тестувати різні конфігурації.
На відміну від звичайних маршрутизаторів, в Mikrotik досить легко наробити помилок в налаштуваннях Firewall, якщо налаштовувати систему з нуля по чужим інструкцій або ж бездумно додавати / змінювати правила.

З чого все почалося?

На домашньому тестовому маршрутизаторе RB951Ui-2HnD у мене вже є гостьова мережа, Queues, HotSpot, WebProxy, Policy Based Routing, IPsec і інші надбудови. Буквально на днях я вирішив протестувати додаткові настройки Firewall з реалізацією базової захисту від DDoS.
Само собою зрозуміло, повноцінний захист від DDoS вимагає:

• жирний інтернет-канал, від 10 Гбіт і вище
• наявність резервного каналу
• високопродуктивне обладнання

Взагалі, більш правильно перед Mikrotik поставити додатковий Firewall на базі того ж FreeBSD або зовсім перенести Frontend в хмарний сервіс.
Але зараз не про це. У ряді випадків і конфігурацій, укласти «мікротік» на лопатки дуже просто. Банально, багато власників даних пристроїв страждають від зовнішніх запитів на їхній DNS ззовні, що призводить до непотрібної навантаженні на CPU. Як закрити доступ до DNS, описувалося раніше, хто пропустив - зверніть увагу на пункт 3 .
Зараз, знову ж таки, трохи не про це. На офіційному Wiki Mikrotik є інструкція під назвою « DoS attack protection », Саме цю публікацію багато хто бере за основу, багато її адаптували під себе, деякі ресурси і зовсім просто перепубліковалі. У будь-якому випадку, в результатах пошукової видачі це один з перших варіантів.
І тут спрацьовує людський фактор, адже реалізація описана на офіційному Wiki, що в ній може бути не так?

«DoS attack protection» із застереженням ...

Існують такі терміни як DoS і DDoS, відразу обмовлюся, перший термін не варто плутати з MS-DOS, це абсолютно різні речі.
DoS є скороченням від англійського «Denial of Service», іншими словами відмова в обслуговуванні. DoS виникає тоді, коли ресурси CPU завантажені на 100%, внаслідок чого маршрутизатор може стати недоступним (unreachable).
Відповідно термін DDoS є скороченням від Distributed Denial of Service, тобто розподілених атак. Такі атаки здійснюються з різних IP і навіть цілих підмереж, здатних генерувати величезні обсяги трафіку. Для прикладу, не так давно сервіс GitHub був атакований ботнетом з сумарною пропускною спроможністю 1.35 терабіт / сек, після чого сервіс просто «впав» на 10 хвилин. Власнику ресурсу вдалося відновити повну працездатність вже через 8 хвилин, але для цього потрібні були величезні обчислювальні ресурси Цодов. Ваш домашній або корпоративний маршрутизатор, в разі наявності зовнішнього білого IP також може піддатися найрізноманітнішим атакам.
У RouterOS ресурси процесора задіють багато операцій по пакетній обробці, зокрема це робота Firewall (Filter, NAT, Mangle), логирование подій, черги (Queues) - в разі великої кількості вступників пакетів, все це може призвести до перевантаження маршрутизатора.
На даний момент не існує ідеального рішення для протидії DoS-атакам. Запам'ятайте, абсолютно будь-який сервіс може бути перевантажений надмірно великою кількістю запитів.
Проте, існують методи для мінімізації впливу невеликих атак подібного типу. Звичайно, якщо у вас підключення 100 Мбіт, від атаки 1 Гбіт це вас не захистить. А ось якщо атака менше, але використовує особливості і / або уразливості конфігурації, погодьтеся, мати завантаження CPU в 30-60% куди краще, ніж 100% і повна відмова.
Одним з найбільш ефективних методів атаки є SYN-флуд . Суть атаки полягає у відправці великої кількості SYN-запитів на установку TCP-з'єднання, на які маршрутизатор повинен давати відповідь SYN + ACK. Все це забирає у маршрутизатора ресурси, в той час як атакуючий може ігнорувати відповіді, що в свою чергу привід до великої кількості напів-відкритих з'єднань (half-open connection) без великого завантаження атакуючої сторони. Такі сполуки «висять» деякий час «в повітрі», після чого маршрутизатор закриває їх з таймаут. Проблема полягає в тому, що пакети обробляються в порядку черговості і при наявності достатньої кількості «сміття», маршрутизатор просто перестане обробляти запити від звичайних клієнтів.
Для перегляду поточних з'єднань в Terminal можна вдатися до команди / ip firewall connection print
А також / tool torch
Якщо ж ви захочете подивитися статистику за окремим інтерфейсу, використовуйте наступний синтаксис: / interface monitor-traffic [названіе_інтерфейса]
Для перегляду ресурсів, використовуйте команду: / system resource monitor
Власне, весь цей функціонал продубльований в Winbox, я лише дублюю інформацію з публікації на Wiki.
Як боротися з великим числом з'єднань?
Для цього нам пропонують скористатися командою: / ip firewall filter add chain = input protocol = tcp connection-limit = LIMIT, 32 \ action = add-src-to-address-list address-list = blacklist-ddos address-list-timeout = 1d
Де LIMIT необхідно замінити на число від 100 і вище. Суть правила в тому, що при перевищенні зазначеного числа з'єднань, віддалений IP-адреса буде внесений до чорного списку (blacklist-ddos) на 1 годину. Назва списку і таймаут можете поміняти на свій розсуд, головне в наступних командах використовувати правильний address-list.
Далі для IP з чорного списку необхідно провести обробку пакетів. Однак, замість стандартного покидька пакетів «action = drop», нам пропонують виконувати «action = tarpit».
Дія «tarpit» призводить до «захоплення» і утриманню TCP-з'єднань, сам маршрутизатор при цьому дає відповідь SYN / ACK на вхідний TCP SYN. На потужних маршрутизаторах це буде призводити до уповільнення атакуючого (в теорії). / Ip firewall filter add chain = input protocol = tcp src-address-list = blacklist-ddos \ connection-limit = 3,32 action = tarpit
Також можна використовувати звичайний action = drop, щоб відкидати пакети навіть не відповідаючи на них. Пробуйте експериментувати з різними настройками. Ні в якому разі не використовуйте reject, тому що він передбачає наявність відповіді, який буде віднімати ресурси.
Далі запропонований наступний механізм виявлення і обробки SYN-флуда / ip firewall filter add chain = forward protocol = tcp tcp-flags = syn connection-state = new \ action = jump jump-target = SYN-Protect comment = "SYN Flood protect" disabled = yes / ip firewall filter add chain = SYN-Protect protocol = tcp tcp-flags = syn limit = 400,5 connection-state = new \ action = accept comment = "" disabled = no / ip firewall filter add chain = SYN- Protect protocol = tcp tcp-flags = syn connection-state = new \ action = drop comment = "" disabled = no
Зверніть увагу, всі перераховані вище правила необхідно переносити в самий верх Firewall, інакше вони просто не будуть працювати.
У першого правила присутній атрибут disabled = yes, іншими словами правило відключено. Автори коду пропонують встановити бажаний limit і включити правило в ланцюжок forward для перегляду кількості відкинутих пакетів.
Власне на цьому подальші дії не описані, і багато читачів просто беруть і додають правила як є. Але до цього моменту ми ще повернемося.
Остання рекомендація полягає у використанні SYN cookies . / Ip settings set tcp-syncookies = yes
Що таке SYN cookies і як це працює? При використанні SYN cookie, в разі переповнення черги, маршрутизатор буде уникати скидання нових з'єднань, замість цього клієнту буде відправляти коректний SYN + ACK зі спеціальними номерами послідовності.
При цьому маршрутизатор не триматиме з'єднання відкритим. У разі отримання коректного ACK і номерів послідовності від клієнта, маршрутизатор відновить сесію. У той же час, маршрутизатор забракує сесію і не буде відновлювати з'єднання в разі, коли номер послідовності невірний, чим забезпечується захист від підміни ACK.
Таким чином, потенційний зловмисник не може обійти міжмережеві екрани з SYN cookie, шляхом простої відправки ACK-пакетів з довільним номером послідовності.

Переходимо до практики

Дану інструкцію я взяв за основу і додав на 2 маршрутизатора. На першому маршрутизаторі в Firewall були додані трохи змінені правила.
У момент правки правил на другому (тестовому) пристрої мене трохи відволікли і я додав правила «як є», чи не внісши всіх змін.
Щоб ви правильно розуміли, перевірку SYN flood необхідно виконувати в першу чергу на ланцюжку input, тому що жертвою зловмисника є саме зовнішній IP. У той час як ланцюжок forward відповідає за транзитний трафік, що проходить через маршрутизатор, наприклад, від клієнта за NAT в інтернет.
Кількома годинами пізніше я грав в WOT і відчув фризи, після чого мене і зовсім викинуло з сервера, а сам тестовий RB951Ui-2HnD пішов в перезавантаження. Власне про перезавантаження роутера я зрозумів по звуку вбудованого біпера, який при запуску у мене додатково програє ноти з «Star Wars - The Imperial March».
Але чим були викликані фризи і автоматичне перезавантаження маршрутизатора? Варіант з перебоями харчування виключаємо відразу, тому що пристрій підключено через ДБЖ.
Відкриваємо логи RouterOS і спостерігаємо таку картину:

Це список усіх запитів, що йдуть через webproxy, записи в логах відображаються з тієї причини, що у мене налаштоване розширене логирование в файл.
Встановлено актуальна RouterOS 6.42.3, нових users не додалося, в files нічого підозрілого.
Заходимо в Gparhing і спостерігаємо таку картину:

На графіках проглядається практично 100% завантаження CPU і високе завантаження RAM прі не такому вже й великому трафіку на WAN-порту. Втім, старенький AR9344 не самий продуктивний процесор.
У підміню Tools - Profile можна побачити більш детальний розподіл ресурсів.

Але як таке можливо, що хтось отримав доступ до webproxy ззовні?
Все дуже просто, на другому маршрутизаторі я не встиг внести правки в правила Firewall. Всьому виною action = accept для syn-пакетів. У випадку з forward це не так страшно, як для input. Дія «Accept» призводить до того, що Firewall схвалює пакет, і далі до них вже не застосовуються інші правила.
Перераховані вище фільтри здійснюють тільки фільтр за кількістю пакетів, не більше, тому всі пакети, які пройшли фільтр необхідно далі обробляти стандартними правилами.
Для цього скористаємося action = return. Дія return здійснюється повернення пакета в попередній chain, для подальшої обробки.
В кінцевому підсумку отримуємо правила такого вигляду: / ip settings set tcp-syncookies = yes / ip firewall filter add action = add-src-to-address-list address-list = ddos-blacklist \ address-list-timeout = 30m chain = input comment = \ "DDoS - Limit incoming connections, add IP to Blacklist" \ connection-limit = 100,32 in-interface = ether1-gateway protocol = tcp add action = tarpit chain = input comment = \ "DDoS - capture and hold connections, try to slow the attacker "\ connection-limit = 3,32 protocol = tcp src-address-list = ddos-blacklist add action = jump chain = forward comment =" DDoS - SYN Flood protect "\ connection-state = new jump-target = SYN-Protect protocol = tcp tcp-flags = syn add action = jump chain = input connection-state = new in-interface = ether1-gateway \ jump-target = SYN-Protect protocol = tcp tcp-flags = syn add action = return chain = SYN-Protect connection-state = new limit = 200,5: packet \ protocol = tcp tcp-flags = syn add action = drop chain = SYN-Protect connection-state = new protocol = tc p \ tcp-flags = syn
В даному прикладі на вході встановлено обмеження в 100 з'єднань на IP, в разі перевищення лімітів, IP вноситься в blacklist з подальшим дропом всіх наступних пакетів.

Базовий захист від SYN-флуда реалізована шляхом перекидання всіх SYN-пакетів в додатковий чейн SYN-Protect з обмеженням в 200 пакетів / сек. Пакети, які не потрапляють під обмеження, повертаються до рідної chain, в разі перевищення лімітів - пакети відкидаються.

Додатково задіяна надбудова tcp-syncookies, що дозволяє не відкидати клієнтів, які перебувають поза чергою.
Власне на цьому все.

На закінчення

На конкретному прикладі показано наскільки важливим є розуміння всіх тих дій, які ви проводите з конфігурацією маршрутизатора. Ніхто не застрахований від чужих помилок, всього 1 помилка може привести до серйозних наслідків і негативно вплинути на безпечність пристрою і мережі в цілому. Після того, як ви переконалися у відсутності помилок, перевірте конфігурацію за собою повторно.
Описана реалізація захисту від DoS-атак і SYN-флуда базова, вона допоможе захистити ваш пристрій і мережу від перевантажень, викликаних примітивними атаками зловмисників. У той же час повторюся, для захисту від повноцінних DDoS-атак цього буде недостатньо.

Відеокурс «Налаштування обладнання MikroTik» (аналог MTCNA)

Вчіться працювати з MikroTik? Рекомендую відеокурс « Налаштування обладнання MikroTik ». В курсі розібрані всі теми з офіційною навчальної програми MTCNA і багато додаткового матеріалу. Курс поєднує теоретичну частину і практику - настройку маршрутизатора за технічним завданням. Консультації за завданнями курсу веде його автор Дмитро скоромні. Підійде і для першого знайомства з обладнанням MikroTik, і для систематизації знань досвідченим фахівцям.