Примерно 5-6 лет назад там был реально крутой админ, который настроил сеть как часы и оснастил современным на тот момент оборудованием экономсегмента. Недостаток бюджета админ компенсировал хорошими конфигами и правильной архитектурой. В общем, видно, что было сделано много работы.
Потом компания разделилась на две, расширилась, в ней всё поменялось пару раз — и за всё это время сеть поддерживали на костылях. Поскольку ИТ не профильный бизнес нашего заказчика, ситуация в целом понятна. Она такая много где, но чтобы большая сеть (территориально распределённая компания, десятки филиалов) продержалась в таком виде 5 лет — я такого ещё не видел.
Собственно, и не продержалась. Нас позвали провести аудит сетевой инфраструктуры после зафиксированного случая взлома, когда их базы данных со всей представляющей коммерческую тайну информацией оказались просто скачаны. Точнее, всплыли не у тех людей.
Обстоятельства, части топологии и другие детали немного изменены, чтобы нельзя было узнать заказчика. Тем не менее пост основан на реальных событиях и максимально приближен к действительности, насколько позволили наши безопасники.
Компания представляет собой основное производство (там же серверный узел) и десятки филиалов по всей стране. В филиалах установлены тонкие клиенты, которые ходят по VPN + RDP до серверного узла, где пользователи и работают. Также в филиалах есть оборудование, которое использует сервисы и базы данных центрального узла. Если в филиале пропадает коннект, то он просто умирает до подключения сети снова.
Сеть — несколько десятков доисторических коммутаторов, покрытые пылью «тупые» маршрутизаторы и MPLS L3 VPN-стык от провайдера для переброски данных между площадками.
Корневой коммутатор в другой компании
Как я говорил, компания разделилась на две независимые и немного конкурирующие несколько лет назад. Так вот, части сети остались общими, потому что тогда их решили не ломать. Странный, но закономерный итог: корневой коммутатор принадлежит конкурентам. Пользователи конкурентов могут посылать задания на сетевые принтеры, админ конкурентов — при некотором усилии смотреть их сетевые шары и так далее. Серверы с архивом видеонаблюдения вообще до сих пор общие. Лабораторный мини-кластер — тоже. Ииии…
Файрволла нет!
Сети не разграничены. Точнее, как: на стыке стоит старинная железка, которая до появления файрволлов нового поколения использовалась в том числе и для защиты. По сути, она работает как простой statefull-файрволл. На ней были обнаружены следы нормального конфига, которые были закомментированы, поскольку, видимо, в какой-то момент помешали развитию сети.
Общие проблемы
Вот выдержки из отчёта:
- При текущих настройках коммутаторов сетевая инфраструктура уязвима как к атакам на само активное сетевое оборудование: DoS/DDoS, неавторизованный доступ, так и к атакам на трафик пользователей и серверное оборудование: DoS/DDoS-атаки, атаки по перехвату трафика путём подмены MAC и IP-адресов, атаки на сервис DHCP.
- Для предотвращения неавторизованного доступа к активному сетевому оборудованию необходимо настроить централизованную аутентификацию и авторизацию, а также ограничить IP-адреса устройств, с которых администраторы могут устанавливать management-подключения к устройствам.
- Для предотвращения неавторизованного доступа в сеть и атак на активное сетевое оборудование и устройства в сети необходимо выключить неиспользуемые интерфейсы и поместить их в неиспользуемую VLAN.
- Для предотвращения атак на сервис DHCP и последующую компрометацию трафика необходимо использовать функционал DHCP Snooping.
- Для предотвращения атак по подмене MAC-адресов и атак на таблицы коммутации коммутаторов с последующей компрометацией трафика необходимо использовать функционал port-security.
- Для предотвращения атак, направленных на перенаправление трафика путём отправки вредоносных ARP-ответов, необходимо использовать функционал Dynamic ARP Inspection.
- Для предотвращения атак на коммутаторы и трафик пользователей необходимо использовать функционал spanning-tree BPDUguard.
- Для предотвращения DoS- и DDoS-атак на сетевую инфраструктуру, а также в связи с вероятностью появления петель коммутации необходимо использовать функционал storm control (unicast, broadcast, multicast).
- На площадке используются устаревшие модели коммутаторов с устаревшими версиями ОС. Рекомендуется обновить версии ОС на коммутаторах, но и после этого данные коммутаторы не смогут предоставить необходимую на сегодняшний день безопасность сети передачи данных на втором уровне модели OSI.
- Связь с другими площадками и выход в Интернет на данной площадке зависят от сетевой инфраструктуры другой компании. Рекомендуется произвести подключения к сервис-провайдерам на локальном корневом коммутаторе.
- В сети есть ряд посторонних устройств, находящихся в гостевой VLAN. При поддержке конечными устройствами функционала dot1x supplicant необходимо настроить для всех этих устройств dot1x-аутентификацию с назначением VLAN и динамических списков контроля доступа, ограничивающих трафик от этих устройств. При отсутствии поддержки данного функционала конечными устройствами рекомендуется на интерфейсах коммутаторов настроить списки контроля доступа и port-security, а также QoS policing для ограничения количества разрешённого трафика.
- В качестве точек доступа используются устройства, которые не поддерживают централизованную аутентификацию администраторов, разрешающие подключения по протоколу HTTP, а также по HTTPS на основании протокола SSL v1.
- SSID объявляются в широковещательном режиме, рекомендуется объявлять их в скрытом.
- WPA2-ключи, используемые для аутентификации, совпадают как для внутренней SSID, так и для гостевой, и представляют из себя 10 букв латинского алфавита (фамилия учредителя).
- В текущих настройках IPsec VPN на маршрутизаторе на фазе 1 и 2 протокола IKE используется протокол 3DES в качестве алгоритма шифрования, MD5 в качестве алгоритма аутентификации и DH 2. Рекомендуется использовать AES-256, SHA-512 и выше и DH 19 и выше. Также необходимо включить функционал PFS с группой DH 19 и выше.
Удалённый доступ OpenVPN (Debian Linux 8). В зависимости от порта подключения, разным клиентам возвращаются разные маршруты в качестве split-tunneling, таким образом, неявно разрешая доступ только к определённым сетям для удалённого подключения. Но клиент может вручную прописать дополнительные маршруты в логический туннель, создаваемый при подключении к OpenVPN-серверу, таким образом, получив возможность маршрутизировать трафик в любые сети компании.
Трафик от пользователей и серверов на всех площадках передаётся в Интернет и из Интернета через маршрутизаторы, не проходя проверку и инспекцию современными межсетевыми экранами и системами предотвращения вторжений. Также данный трафик в большинстве случаев либо не ограничен, либо почти не ограничен. В связи с этим устройства, приложения и данные компании практически не защищены от целого ряда атак, которые могут быть использованы против компании. Это атаки, использующие уязвимость приложений и операционных систем, атаки DoS и DDoS на серверы, приложения и активное сетевое оборудование компании, атаки на данные пользователей компании при помощи вирусов и сетевых червей и т.д. Весь трафик компании, передающийся из или в публичные сети, а также трафик между разными площадками компании и трафик между компанией и её партнёрами должен быть ограничен и проходить проверку межсетевыми экранами и системами предотвращения вторжений последнего поколения. Из-за высокой стоимости таких решений целесообразно использовать централизованную пару устройства (для отказоустойчивости) в центральном офисе и маршрутизировать трафик от всех площадок в Интернет и на другие площадки компании через данные устройства.
Как шёл аудит?
Этап первый. Я выслал заказчику опросные листы и попросил их заполнить до того, как буду проводить работы. Опросные листы были в формате doc-файлов и экселевских табличек, объём информации зависел от объектов. По какому-то оборудованию было много информации, по какому-то — по нулям. Вообще, заполнение таких опросных листов — процедура стандартная, там указываются IP-адреса, количество серверов, где, что и как, ну и так далее.
Не все айтишники, вовлечённые в процесс конфигурации сети, являлись штатными сотрудниками заказчика, была ещё и аутсорс-поддержка. OpenVPN мне настраивал как раз внешний инженер. Я просил, чтобы он мне предоставил удалённый доступ и конфигурационные файлы. Здесь проблем особых не возникло. Информацию я получил в течение недели, после подключился к оборудованию. Если возникали вопросы, решал их с местным админом. Несколько раз встретились некоторые участки конфигураций от линуксоида, и чтобы в них разобраться, мне пришлось подключить своих коллег. Это были следы того самого мифического админа, который всё как часы запустил много лет назад.
На втором этапе я запросил конфигурации прокси-сервера и OpenSSL VPN-сервера, которые впоследствии анализировал. На это ушло ещё около недели.
Этап третий. Залезал на все «железки» и смотрел. Это необязательная процедура в таком аудите. В принципе, всё должно быть в конфигурационном файле. Однако, есть и такие вещи, которые так просто посмотреть нельзя. Часть «железа» была выключена, часть в пересланных документах показывала настройки по умолчанию, а не фактические. Перечень этих настроек никто не вёл, они нигде не указывались. Поэтому лучше было всё проверить вручную. Так и сделал. На каждом интерфейсе оборудования любого вендора ведётся статистика полученного и отправленного трафика. Если статистика по нулям, понятно, что оборудование не используется и его можно выключить. Были и интерфейсы, у которых счётчики были не по нулям, но к оборудованию ничего не было подключено. Я обнулял счётчики трафика и проверял, увеличилось ли количество байт через интерфейс или нет. Если спустя две недели через этот интерфейс ничего не передавалось, то можно сделать предварительный вывод, что он не использовался.
Ещё я смотрел, какие есть протоколы, как настроена аутентификация. Проводил полный аудит по каждой «железке»: протоколы удалённого доступа, настройка протоколов, аутентификация, авторизация, включены/выключены ли интерфейсы, NAT, Wi-Fi — всё. Очень важны access-листы на маршрутизаторах. Либо их не было, либо они были очень базовыми. Это заняло три недели вместе с оформлением отчётов. А, да, я ещё проверял ОС, версии прошивок, можно ли обновиться и получить более современный функционал, есть ли подходящая версия.
Четвёртый этап — сагрегировал информацию и дал рекомендации по каждой «железке».
Как они выжили?
Скорее всего — по принципу Неуловимого Джо. 5 лет везения закончились взломом, про который стало известно. Куда более интересно — как они за эти пять лет не подцепили очередную эпидемию блокировщиков либо не словили майнеров или случайный DDoS, который бы их «положил»?
В целом могу сказать, что маленькие компании (особенно разные производства в далёких регионах) так и живут. Даже частные банки небольшие так иногда работают, коллеги рассказывали такие байки. Но вот чтобы компания такого размера и с таким оборотом — очень странно. Элементарно, все конкуренты должны быть джентльменами, чтобы не положить их инфраструктуру одной левой.
Чем кончилась история
Они сейчас закупают снова современное оборудование корпоративного уровня. Будет пара файрволов, будут новые, более функциональные маршрутизаторы, будут правильные настройки и правила разрешённого трафика. Маршрутизация доступа к Интернету пойдёт через основной серверный узел для всей страны, потому что пара файрволов только там. Уже сейчас они закрыли все неиспользуемые порты и вообще обновили настройки. Обновляют прошивки, где это возможно.
У новых коммутаторов будет централизованная аутентификация, логирование, разграничение прав юзеров по управлению. У поддержки наконец-то появятся разные учётки — сейчас они работают по одной. Если сейчас удалить конфиг и перезагрузить устройство, то никто не узнает, кто это был.
После этого они будут медленно копить на DLP и другие фичи.
Ссылки
- ИБ через микросегментацию
- Как мы строили новую сеть Аэроэкспресса
- Направленные атаки и защита
- Моя почта — ASigachev@croc.ru
