Глазами "защитника": как мы участвовали в Positive Hack Days CityF "Противостояние".
Часть 6. Нестандартный метод защиты SSH С частью 5 (описание хода сражения) можно ознакомиться постом ранее.
- Почему нам нельзя перенастраивать сетевое оборудование, если мы его защищать должны? Без этого никак.
- А, вы телеком-защитники. Тогда вам можно, но сервисы должны быть доступны и чтобы не терялось управление. Иначе мы подойдем к вам и спросим: "Что за дела?". Если не сможете быстро починить - вернем к настройкам до начала соревнований, а вам выставим штрафные баллы. Поэтому с изменением сетевых настроек будьте аккуратны.
- Это не проблема. А если для обеспечения безопасности нам нужно будет развернуть трафик по-другому, завязать узлом, но при этом все будет работать?
- Тогда мы придем к вам с бумажкой - записать, что и как вы делали, интересно ведь.
- А зачем ты на Positive Hack Days решил Balabit использовать? Чем он там поможет?
- Будем админов мониторить. Они обещали периодически на серверах взводить дырявые сервисы.
- Ну, как знаешь.
Это два реальных разговора при подготовке к PHDays. До определенного момента я сам не думал, что они будут настолько плотно взаимосвязаны. Естественно, после разговора с организаторами я подумывал, что надо бы и удивить, раз грозился. По ходу соревнований вектор настроения потихоньку сдвинулся от первоначального желания в сторону "забетонироваться". Но чудесным образом получилось так, что в итоге они слились. И об этом пойдет рассказ.
Как я уже писал в части 5, и говорил на сцене PHDays, довольно интересное и нестандартное у нас получилось решение по защите уязвимых серверов Unix, управляемых по SSH.
Напомню, сама по себе архитектура упрощенно выглядела следующим образом:
Но, как упоминалось в части 4 и части 5, использовать ACL на firewall с правилом default deny нам не разрешили организаторы. Поэтому изначально из псевдоинтернета трафик шел к серверам DMZ по всем протоколам и портам. Но в этой статье речь пойдет о SSH.
Сервера, которые нам поставили в DMZ, практически все были уязвимы к CVE-2015-5600, что означало отсутствие защиты от перебора паролей и перегруза CPU. Совмещаем эти 2 условия - и получаем идеальную для хакеров ситуацию: "Не подберу - так хоть завалю". При этом, начиная с вечера первого дня, сервера появлялись, как тараканы в общаге. SSH был дырявый везде. Обновления, содержащие фикс к указанной уязвимости, были далеко не во всех репозитариях. То есть, зайти единоразово на все линукса разных версий и втоптать пару команд, чтобы дальше оно само - не вариант. Только сырцы, только хардкор. Лень - двигатель прогресса. Возможно, человек, плотнее в повседневной жизни работающий с Open Source решениями и Unix, пошел бы в сторону реализации своего репозитария либо еще как, но во мне в 3 часа ночи проснулся архитектор.
Я вспомнил об одиноко стоящем Balabit SCB, который, несмотря на игнор первого дня, исправно крутился и жрал некоторые ресурсы вычислительной инфраструктуры организаторов. Поскольку я настраивал еще самую первую инсталляцию Balabit в СНГ, не считая остальных в течение нескольких лет, мысль попробовать пустить через него SSH смотрится вполне закономерно.
Настроив пару проксирующих правил на Balabit, я его просканировал. Модуль проброса SSH zorp-ssh оказался неуязвимым к CVE-2015-5600, равно как и к другим, известным на тот день сканеру MaxPatrol, уязвимостям. Теперь осталось придумать, как разделить трафик таким образом, чтобы SSH к серверам в DMZ балабитизировался, а остальные протоколы шли своим обычным путем.
Рассмотрим на примере SSH, но таким же образом можно поступить и с RDP, и с Telnet, и с VNC, и с ICA (правда, чуть попотеть).
По задумке, реализованной в схеме сети, к серверам из DMZ хакеры попадали по всем протоколам и портам, проходя через пограничный firewall.
Чтобы не запутать в сетевых терминологиях и реализации NAT двух разных производителей, опишу вендорнезависимую концепцию, применимую на оборудовании любых производителей, поддерживающих такую технологию.
Для заворота трафика SSH на Balabit можно пойти такими путями:
1. Выделенные порты для серверов.
- Выделить диапазон портов на Balabit.
- Реализовать динамический NAT many-to-one на пограничном CheckPoint таким образом, чтобы пакеты, прилетающие из псевдоинтернета в направлении серверов DMZ на порт SSH, транслировались в пакет, где src ip подменяется на IP CheckPoint, dst ip - на IP Balabit, dst port - на выделенный для этого сервера порт на Balabit.
Packet: | SRC IP | DST IP | PROTO/PORT |
Original | ANY | DMZ_srv1 | TCP/22 |
Translated | CheckPoint_ip | Balabit_ip | TCP/port1 |
Original | ANY | DMZ_srv2 | TCP/22 |
Translated | CheckPoint_ip | Balabit_ip | TCP/port2 |
Original | ANY | DMZ_srv3 | TCP/22 |
Translated | CheckPoint_ip | Balabit_ip | TCP/port3 |
Original | ANY | DMZ_srv4 | TCP/22 |
Translated | CheckPoint_ip | Balabit_ip | TCP/port4 |
- Открыть доступ для этих TCP-сессий на вход в Firewall ЦОД:
Packet: | SRC IP | DST IP | PROTO/PORT |
To_Balabit | CheckPoint_ip | Balabit_ip | TCP/port1-port4 |
- Настроить правила проксирования на Balabit с возвратом на нужный сервер, порт 22 (SSH):
Packet: | SRC IP | DST IP | PROTO/PORT |
Original | CheckPoint_ip | Balabit_ip | TCP/port1 |
Translated(proxied) | Balabit_ip | DMZ_srv1 | TCP/22 |
Original | CheckPoint_ip | Balabit_ip | TCP/port2 |
Translated(proxied) | Balabit_ip | DMZ_srv2 | TCP/22 |
Original | CheckPoint_ip | Balabit_ip | TCP/port3 |
Translated(proxied) | Balabit_ip | DMZ_srv3 | TCP/22 |
Original | CheckPoint_ip | Balabit_ip | TCP/port4 |
Translated(proxied) | Balabit_ip | DMZ_srv4 | TCP/22 |
- Разрешить выход таких пакетов с Balabit в сторону DMZ на обоих firewall:
Packet: | SRC IP | DST IP | PROTO/PORT |
From_Balabit | Balabit_ip | DMZ_subnet | TCP/22 |
Готово. SSH-сессия функционально не нарушена, другой трафик не задет, условия игры соблюдены.
2. Выделенный пул адресов.
- Выделить в ЦОД подсеть той же размерности, что и DMZ.
- Поместить в нее интерфейс Balabit, принимающий трафик.
- Настроить маршрутизацию.
- Сконфигурировать Balabit с IP-адресами той же подсети.
- Реализовать статический NAT one-to-one на пограничном firewall:
Packet: | SRC IP | DST IP | PROTO/PORT |
Original | ANY | DMZ_subnet | TCP/22 |
Translated | CheckPoint_ip | Balabit_subnet | TCP/22 |
Можно, конечно, и не прятать SRC IP за адрес CheckPoint, но тогда необходимо, чтобы DMZ строился на серых адресах. На «противостоянии» DMZ строили на "белых"…
- Разрешить входящий трафик на Firewall ЦОД:
Packet: | SRC IP | DST IP | PROTO/PORT |
To_Balabit | CheckPoint_ip | Balabit_subnet | TCP/22 |
- Настроить правила проксирования на Balabit:
Packet: | SRC IP | DST IP | PROTO/PORT |
Original | CheckPoint_ip | Balabit_ip1 | TCP/22 |
Translated(proxied) | Balabit_ip0 | DMZ_srv1 | TCP/22 |
Original | CheckPoint_ip | Balabit_ip2 | TCP/22 |
Translated(proxied) | Balabit_ip0 | DMZ_srv2 | TCP/22 |
Original | CheckPoint_ip | Balabit_ip3 | TCP/22 |
Translated(proxied) | Balabit_ip0 | DMZ_srv3 | TCP/22 |
Original | CheckPoint_ip | Balabit_ip2 | TCP/22 |
Translated(proxied) | Balabit_ip0 | DMZ_srv2 | TCP/22 |
- и разрешение на обоих firewall:
Packet: | SRC IP | DST IP | PROTO/PORT |
From_Balabit | Balabit_ip0 | DMZ_subnet | TCP/22 |
где Balabit_ip0 - адрес Balabit, сконфигурированный на интерфейсе как основной, а не IP alias (Balabit_ip1...4). Можно, конечно, настроить так, чтобы src ip был Balabit_ip1...4, но в ситуации на PHDays это было лишним.
===
В обоих случаях, чтобы иметь возможность пускать определенные подсети на сервера DMZ мимо Balabit, необходимо на пограничном firewall перед описанными правилами поставить такое:
Packet: | SRC IP | DST IP | PROTO/PORT |
Original | TRUSTED_NET | DMZ_subnet | IP/ANY |
Translated | TRUSTED_NET | DMZ_subnet | IP/ANY |
Видно, что подобное решение немного напрягает при масштабировании его на большое количество серверов. Нельзя сделать "настроил и забыл" для всей подсети одной строкой. Дополнительные затраты времени вызывает необходимость:
В случае 1 - добавления правила для каждого нового сервера DMZ и на Balabit, и на firewall.
В случае 2 - разработка сетевого дизайна и настройка сети (единоразово), а также добавление нового правила на Balabit для каждого сервера DMZ.
То есть, в обоих случаях - настраивать Balabit для каждого сервера. Задача, по сути, не громоздкая, занимает 5-10 минут, и при статичности жизни сервера вполне терпима, но если все часто течет и меняется...
Оба этих ограничения связаны с тем, что сеть с точки зрения L3 была плоской, с одной таблицей маршрутизации. Есть решение, которое помогло бы прозрачно балабитизировать всю подсеть одним махом, а там хоть каждую секунду добавляйте-удаляйте сервера в подсети. Но для этого потребуется единоразово настроить MPLS L3VPN либо vrf lite на активном сетевом оборудовании (если поддерживает) и аккуратно соединить с его помощью Balabit и пограничный firewall.
Но это уже тема для совсем отдельной статьи...
Вижу немой вопрос в глазах читателей: а как же ты настроил на PHDays?
Ответ: по варианту №1 – выделенные порты.
