PHDays CTF: "Противостояние" глазами "защитника". Часть 6. Нестандартный метод защиты SSH

Глазами "защитника": как мы участвовали в 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.

Поскольку как пограничный firewall использовался не ACL на роутере, а CheckPoint, стандартные для firewall фичи типа NAT можно было настраивать во всю мощь. Как firewall, защищающий сервера "ЦОД" - Cisco ASAv.
Чтобы не запутать в сетевых терминологиях и реализации 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 это было лишним.

Готово. SSH-сессия функционально не нарушена, другой трафик не задет, условия игры соблюдены. 
===

В обоих случаях, чтобы иметь возможность пускать определенные подсети на сервера 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 – выделенные порты.