Продовження роботи над помилками від колег, що відповідали за мережу
Червоне – допущені під час змагань помилки
Синє -погані ідеї, або такі що були виконані невчасно
1.Було оновлено RouterOS до крайньої мажорної варсії (тобто до 6.49.10). Це мотивовано наявністю критичних вразливостей які дозволяли зловмиснику віддалене виконання команд.
2. Було відключено scheduler task який вигружає поточну конфігурацію на зовнішній ресурс кожні 15 хв.
3. Було створено нові облікові записи адміністраторів системи. При створенні нових облікових записів було вказано з яких мереж/хостів згадані облікові записи можуть підключатися.
4. Відключено існуючі в системах облікові записи адміністраторів (admin та blue).
5. Було відредаговано group policies, які регламентують права користувачів та груп користувачів (залишено лише ті права, які потрібні для роботи кожні групі).
6. Було проаналізовано DNS сервери, які пристрої використовують. Було виявлено, що пристрої використовують сторонні незадокументовані DNS сервері. Їх було замінено на авторизовані “корпоративні” DNS сервери.
7. Було проаналізовано протоколи, по яких дозволено адмініструвати пристрій. Було відключено всі протоколи за винятком ssh та https (для https було згенеровано self-signed сертифікат на кожному пристрої).
8. поточні налаштування NTP серверів на пристрої проаналізовано не було.
9. Було налаштовано логування системих подій на SecurityOnion (коректна доставка та інтерпритація логів зі сторони SecurityOnion не перевірялась).
10. Було відключено Neighbor Discovery.
11. Було викремлено OSPF в окремий процес між пристроями Mikrotik лише “нашої інфраструктури”.
Це було реалізовано шляхом створення nbma-типу OSPF процесу, де сусідні пристрої, з якими потрібно формувати суміжність, було вказано вручну. Простіше це було зробити реалізацією окремого Process ID. Для OSPFv2 було налаштовано автентифікацію сусідів по протоколу MD5. Крім цього, було створено додаткове правило в ланцюгу INPUT, яке дозволяло вхідні OSPF пакети лише з визначених сусідніх пристроїв. Вище описані дії були реалізховані як для IPv4, так і IPv6 (За виключенням MD5 автентифікації).
12. Було оптимізовано роботу пртоколу BGP – пристрої було налаштовано на отримання лише маршруту по замовчуванню від сусідів (0.0.0.0/0 та ::/0). Це було виконано шляхом фільтрації вхідних маршрутиів від налаштованих BGP peers.
Як вявилось після змагань, описані в п. 10 та 11 дії були неефективними так як червона команда в даних змаганнях не планувала виконувати ін’єкцію маршрутів, а тому оптимізація роботи протоколів маршрутизації виявиась зайвою та ресурсоємкою.
13. В останній день було вимкнено анонсування Connected саршрутів в BGP. Необхідно було виконати це раніше так після змагань виявилось, що хост даної мережі використовувся як Pivot для атаки на мерержі інших команд.
14. Було вимкнено статичний маршрут до дрону. Варто було зробити це раніше на RCC фаєрволі.
Висновок: помилково було обрано стратегію щодо пристроїв Mikrotik – його початково було інтерпритовано як частину інфраструктури, яку потрібно було захищати, хоча потрібно було сприймати його як інструмент безпеки.
Коректною під час участі в змаганнях була б стратегія витратити менше часу на оптимізацію роботи проткоолів динамічної маршрутизації, натомість реалізувати правила міжмережевого екрану для фільтрації трафіку.