Мнение, высказанное в этой статье, является личным мнением автора. Он подчёркивает, что оно может не совпадать с мнением его работодателя, начальства и отдела безопасности.
Одна из самых крутых штук в нашей компании в плане инфраструктуры — это то, как мы реализуем удалённый доступ. Это просто супер-мега-защищённая магия. Я поговорил со многими моими коллегами-безопасниками и аудиторами, и, похоже, мы случайно изобрели совершенно новую историю, смешав коммерческие решения и свой софт. И вот, я подумал, будет интересно глубоко погрузиться в технические детали того как в индустрии работают с устаревшими решениями удалённого доступа и как это реализуем мы.
Начну с сильного заявления: все VPN — хлам.
VPN, как и другие цифровые технологии, можно настроить так, чтобы если его и взломают, то не настал конец света. Впрочем, никто так не делает… но теоретически-то могут!
В 99.95% случаев, VPN настроен на:
Это не очень хорошая идея. Представьте если на вашем ноутбуке поселился вирус и вы подключаетесь через VPN к сети боевых серверов? Та-дам! У вируса теперь есть доступ на уровне локальной сети к вашему продакшену. Что на выхлопе? Грусть. Много грусти.
Окей, допустим случай с вирусом надуманный. А как насчёт того, что хакер может проникнуть в сам VPN, скажем с помощью уязвимости внутри устройства или софта, на котором работает VPN? Таким образом, беспрепятственно пробравшись прямиком в целевую сеть? Вот это уже серьёзное дело, и далёкое от теоретизирования. Подробнее можно прочесть в статье о том, как Heartbleed использовали для захвата VPN, используя вектор атаки, о котором я предупреждал прям в своём же блоге.
Не так давно по миру пронеслась волна уязвимостей в VPN, которые тут же использовались киберпреступниками для получения доступа к целевым сетям. Но ведь это не удивительно, правда? Эти системы “смотрят” напрямую в Сеть, без всяких иных защитных механизмов перед ними. Фиксы и патчи обычно не применяются автоматически, и задействуют проприетарные механизмы, управляемые проприетарным софтом, работающем на проприетарных же ОС. Ну, удачи вам там.
Трудно ли найти эти VPN-устройства? До написания этой статьи я никогда не пытался, так что точно не знал. Около получаса в Shodan.io и пожалуйста — несколько крупных результатов из выдачи:
Что ж, это, наверное, не очень хорошо. Если эти вещи так легко найти, кажется не идеальным решением выставлять их в интернет. Есть ли у нас другой выбор?
Zero Trust [буквально: “ноль доверия”] — по сути означает, что вы авторизуете каждое подключение, а не предполагаете, что некоторые из них заслуживают доверия потому что уже находятся внутри вашей сети. Если хотите лучше понимать этот термин и переосмыслить свой подход к делу, прочитайте эту статью на Network World (простите за очередной беспардонный самопиар).
Мы купили решение Okta Advanced Server Access (OASA), чтобы ввести Zero-Trust авторизацию на боевых серверах.
OASA крут по трём причинам:
Под капотом платформа OASA — это хорошо управляемое развёртывание OpenSSH (та самая команда ssh в вашей консоли). А OpenSSH — это крайне хорошо протестированное и защищённое решение для удалённого администрирования. Между прочим, с 2003 года в OpenSSH не было ни одной уязвимости, которая бы приводила к несанкционированному удалённому доступу в стандартной конфигурации.
Точки входа в этой схеме — обычные EC2 инстансы Amazon Linux 2. Таким образом, площадь для атаки крайне мала. Помните: одна из главных проблем с использованием VPN — это проприетарный софт / конфигурации ОС, которые препятствуют автоматическим патчам. Возможность обновлять наши точки входа в сеть вместе с остальной инфраструктурой — большая победа.
Как я упоминал выше, большинство VPN настроены на создание сетевого моста между сетевым устройством, например ноутбуком, и сетью серверов в интернете. Одно из моих самых больных мест в VPN — то, что они перехватывают весь ваш сетевой трафик. Можно, конечно, перенастроить на другое поведение, но наши клиенты и протоколы безопасности NIST 800-53 SC-7(7) обычно требуют именно этого.
Это хороший пример того, как некоторые меры безопасности сильно отстают от развития индустрии. В олдскульном мире VPN мог быть единственной прослойкой для шифрования трафика. Аудиторы временами считают, что без защиты VPN вы будете отправлять ваши данные через незашифрованные каналы.
К счастью, есть способ получше. В модели OASA соединение устанавливается индивидуально между вами и сервером. Например, в ответ на просьбу “Я хочу зайти на EC2 инстанс i-028d62efa6f0b36b5”, ваша система подключается к входной точке сети, а затем к целевому серверу. OASA также защищает эти подключения выпуская десятиминутные клиентские сертификаты после первой проверки ваших данных через SSO, а затем проверяя, что вы на предусмотренном (и подтверждённом) доверенном устройстве.
Остаётся мало свободы бродить по сети. Администратор может войти в сетевую точку входа и пробросить порты на другое место назначения, но эта возможность отключена по умолчанию и должна быть явно запрошена при установке подключения. А лучше всего то, что никто не требует от меня проводить весь трафик через боевые Virtual Private Cloud, потому что это не называется «VPN».
Эти входные точки в сеть развёртываются для каждого Virtual Private Cloud отдельно (например, одна для prod, одна для staging, одна для dev и т.д.). Кроме того, каждая из них пристально отслеживается нашим защитным решением, которое логирует всю активность и фильтрует трафик. Если взломщик окажется внутри одной из точек входа, что-то сделать тоже не особо получится. В любой ситуации, наша схема безопасности не разрешает доступ к защищённым ресурсам просто потому что вы уже находитесь внутри Virtual Private Cloud.
Один из моих любимых защитных механизмов обнаружился совершенно случайно. Когда мы только начали настраивать входные точки, каждая была настроена на статический IP адрес от AWS. Довольно быстро мы обнаружили, что эти IP адреса иногда не привязывались к EC2 инстансам на нужное время, что могло привести к неправильной самоконфигурации OASA. Испытав прелести дюжины разных фиксов в продакшене, я не выдержал и просто удалил всю историю про статические IP – и всё заработало.
Для OASA просто нужен выходящий в интернет IP, он не должен быть заранее известен. Когда клиент готов установить соединение, происходит запрос уникального GUID, с помощью которого выясняется IP:
Это значит, что каждый экземпляр нашей инфраструктуры входных точек (отдельный пост о ней к вашему вниманию) поставляется с совершенно новым набором IP адресов. Таким образом, случайные хакеры должны будут искать один нужный IP среди десятков миллионов, и их количество растёт с каждым днём. К несчастью для них, эти поиски совершенно напрасны, благодаря…
Port knocking [дословно: стук в порты] — это штука, которой в принципе никто не пользуется в реальном мире, но которую очень весело настраивать. Говоря кратко, port knocking это последовательность «ударов» в разные закрытые сетевые порты, и если последовательность повторена верно, «настоящий» порт открывается вашему IP. Изящно, но непрактично в настоящих крупных проектах.
Я вдохновился идеей и задумался как бы усовершенствовать замысел. Так родилось решение, которое я называю Enterprise Port Knocking.
Я хотел создать механизм, который бы гарантировал закрытость наших входных точек для интернета, пока кому-то не удалось получить к ним доступ. Этот механизм должен был быть простым в использовании, надёжным, и аутентифицироваться существующим способом.
Я набросал архитектуру механизма и пошёл с ней к нашей невероятно талантливой команде инженеров. Через пару недель мы запустились.
Сервис довольно простой и разворачивается как AWS Lambda функция, с доступом к ней через AWS API Gateway (радости serverless архитектуры!) для лёгкого и надёжного использования. Механизм работает так:
Благодаря этой ситуации, мы теперь хвастаемся решением для удалённого доступа, которое полностью закрыто для Интернета и требует двухфакторную аутентификацию через нашу базу пользователей ещё до открытия порта в файрволе.
Я ещё не коснулся того, насколько эти механизмы просты в эксплуатации. Я знаю, что составляющих много, но все вместе они создают очень даже простую авторизацию:
Вся эта система — большая победа для нашей инфраструктуры, для соблюдения нами всех соглашений по безопасности и для безопасности наших клиентов. Пользователям очень нравится, насколько легко подключиться к нашим серверам, ведь не надо проходить дополнительную аутентификацию или запоминать какой VPN использовать. А мне очень нравится мой спокойный сон. От новой модели выиграли все!
Ну, кроме хакеров, конечно.
Одна из самых крутых штук в нашей компании в плане инфраструктуры — это то, как мы реализуем удалённый доступ. Это просто супер-мега-защищённая магия. Я поговорил со многими моими коллегами-безопасниками и аудиторами, и, похоже, мы случайно изобрели совершенно новую историю, смешав коммерческие решения и свой софт. И вот, я подумал, будет интересно глубоко погрузиться в технические детали того как в индустрии работают с устаревшими решениями удалённого доступа и как это реализуем мы.
Хороший человек VPN не посоветует
Начну с сильного заявления: все VPN — хлам.
VPN, как и другие цифровые технологии, можно настроить так, чтобы если его и взломают, то не настал конец света. Впрочем, никто так не делает… но теоретически-то могут!
В 99.95% случаев, VPN настроен на:
- Создание сетевого моста между устройством (ноутбуком или другим сервером)
- … и большей сетью серверов (например, в облаке или для on-prem)
- … и интернетом, защищённого дополнительным слоем шифрования
Это не очень хорошая идея. Представьте если на вашем ноутбуке поселился вирус и вы подключаетесь через VPN к сети боевых серверов? Та-дам! У вируса теперь есть доступ на уровне локальной сети к вашему продакшену. Что на выхлопе? Грусть. Много грусти.
Окей, допустим случай с вирусом надуманный. А как насчёт того, что хакер может проникнуть в сам VPN, скажем с помощью уязвимости внутри устройства или софта, на котором работает VPN? Таким образом, беспрепятственно пробравшись прямиком в целевую сеть? Вот это уже серьёзное дело, и далёкое от теоретизирования. Подробнее можно прочесть в статье о том, как Heartbleed использовали для захвата VPN, используя вектор атаки, о котором я предупреждал прям в своём же блоге.
Не так давно по миру пронеслась волна уязвимостей в VPN, которые тут же использовались киберпреступниками для получения доступа к целевым сетям. Но ведь это не удивительно, правда? Эти системы “смотрят” напрямую в Сеть, без всяких иных защитных механизмов перед ними. Фиксы и патчи обычно не применяются автоматически, и задействуют проприетарные механизмы, управляемые проприетарным софтом, работающем на проприетарных же ОС. Ну, удачи вам там.
Трудно ли найти эти VPN-устройства? До написания этой статьи я никогда не пытался, так что точно не знал. Около получаса в Shodan.io и пожалуйста — несколько крупных результатов из выдачи:
- Thomson Reuters — компания стоимостью в 41 млрд. долларов с 26 000 сотрудников, половину прибыли которой составляют финансовые услуги.
- SAP Concur – сервис управления путешествиями, взлом которого дал бы кучу персональных и платёжных данных всех сортов.
- Progressive Insurance — персональные данные и личная медицинская информация, вкупе с кое-какими платёжными данными.
- Chevron Phillips Chemical — название говорит само за себя.
Что ж, это, наверное, не очень хорошо. Если эти вещи так легко найти, кажется не идеальным решением выставлять их в интернет. Есть ли у нас другой выбор?
Zero Trust
Zero Trust [буквально: “ноль доверия”] — по сути означает, что вы авторизуете каждое подключение, а не предполагаете, что некоторые из них заслуживают доверия потому что уже находятся внутри вашей сети. Если хотите лучше понимать этот термин и переосмыслить свой подход к делу, прочитайте эту статью на Network World (простите за очередной беспардонный самопиар).
Мы купили решение Okta Advanced Server Access (OASA), чтобы ввести Zero-Trust авторизацию на боевых серверах.
OASA крут по трём причинам:
1. Это просто обёртка вокруг конфигурации OpenSSH на стероидах
Под капотом платформа OASA — это хорошо управляемое развёртывание OpenSSH (та самая команда ssh в вашей консоли). А OpenSSH — это крайне хорошо протестированное и защищённое решение для удалённого администрирования. Между прочим, с 2003 года в OpenSSH не было ни одной уязвимости, которая бы приводила к несанкционированному удалённому доступу в стандартной конфигурации.
Точки входа в этой схеме — обычные EC2 инстансы Amazon Linux 2. Таким образом, площадь для атаки крайне мала. Помните: одна из главных проблем с использованием VPN — это проприетарный софт / конфигурации ОС, которые препятствуют автоматическим патчам. Возможность обновлять наши точки входа в сеть вместе с остальной инфраструктурой — большая победа.
2. Нет сетевых мостов
Как я упоминал выше, большинство VPN настроены на создание сетевого моста между сетевым устройством, например ноутбуком, и сетью серверов в интернете. Одно из моих самых больных мест в VPN — то, что они перехватывают весь ваш сетевой трафик. Можно, конечно, перенастроить на другое поведение, но наши клиенты и протоколы безопасности NIST 800-53 SC-7(7) обычно требуют именно этого.
Это хороший пример того, как некоторые меры безопасности сильно отстают от развития индустрии. В олдскульном мире VPN мог быть единственной прослойкой для шифрования трафика. Аудиторы временами считают, что без защиты VPN вы будете отправлять ваши данные через незашифрованные каналы.
К счастью, есть способ получше. В модели OASA соединение устанавливается индивидуально между вами и сервером. Например, в ответ на просьбу “Я хочу зайти на EC2 инстанс i-028d62efa6f0b36b5”, ваша система подключается к входной точке сети, а затем к целевому серверу. OASA также защищает эти подключения выпуская десятиминутные клиентские сертификаты после первой проверки ваших данных через SSO, а затем проверяя, что вы на предусмотренном (и подтверждённом) доверенном устройстве.
Остаётся мало свободы бродить по сети. Администратор может войти в сетевую точку входа и пробросить порты на другое место назначения, но эта возможность отключена по умолчанию и должна быть явно запрошена при установке подключения. А лучше всего то, что никто не требует от меня проводить весь трафик через боевые Virtual Private Cloud, потому что это не называется «VPN».
3. Выделенный сетевой доступ и случайные IP
Эти входные точки в сеть развёртываются для каждого Virtual Private Cloud отдельно (например, одна для prod, одна для staging, одна для dev и т.д.). Кроме того, каждая из них пристально отслеживается нашим защитным решением, которое логирует всю активность и фильтрует трафик. Если взломщик окажется внутри одной из точек входа, что-то сделать тоже не особо получится. В любой ситуации, наша схема безопасности не разрешает доступ к защищённым ресурсам просто потому что вы уже находитесь внутри Virtual Private Cloud.
Один из моих любимых защитных механизмов обнаружился совершенно случайно. Когда мы только начали настраивать входные точки, каждая была настроена на статический IP адрес от AWS. Довольно быстро мы обнаружили, что эти IP адреса иногда не привязывались к EC2 инстансам на нужное время, что могло привести к неправильной самоконфигурации OASA. Испытав прелести дюжины разных фиксов в продакшене, я не выдержал и просто удалил всю историю про статические IP – и всё заработало.
Для OASA просто нужен выходящий в интернет IP, он не должен быть заранее известен. Когда клиент готов установить соединение, происходит запрос уникального GUID, с помощью которого выясняется IP:
- Пользователь: Я хочу войти, чтобы подключиться к vpc-99f2acff
- Клиентское приложение OASA: Я определил vpc-99f2acff как известный сервер с GUID 25af5d4f-e657-4583-b0bd-beb1ca4f0c1f
- Сервер OASA: К 25af5d4f-e657-4583-b0bd-beb1ca4f0c1f можно получить доступ по адресу 3.22.198.24, вот сертификаты
- Клиентское приложение OASA: Сертификаты установлены, подключаюсь к 3.22.198.24 по SSH…
Это значит, что каждый экземпляр нашей инфраструктуры входных точек (отдельный пост о ней к вашему вниманию) поставляется с совершенно новым набором IP адресов. Таким образом, случайные хакеры должны будут искать один нужный IP среди десятков миллионов, и их количество растёт с каждым днём. К несчастью для них, эти поиски совершенно напрасны, благодаря…
Enterprise Port Knocking
Port knocking [дословно: стук в порты] — это штука, которой в принципе никто не пользуется в реальном мире, но которую очень весело настраивать. Говоря кратко, port knocking это последовательность «ударов» в разные закрытые сетевые порты, и если последовательность повторена верно, «настоящий» порт открывается вашему IP. Изящно, но непрактично в настоящих крупных проектах.
Я вдохновился идеей и задумался как бы усовершенствовать замысел. Так родилось решение, которое я называю Enterprise Port Knocking.
Я хотел создать механизм, который бы гарантировал закрытость наших входных точек для интернета, пока кому-то не удалось получить к ним доступ. Этот механизм должен был быть простым в использовании, надёжным, и аутентифицироваться существующим способом.
Я набросал архитектуру механизма и пошёл с ней к нашей невероятно талантливой команде инженеров. Через пару недель мы запустились.
Сервис довольно простой и разворачивается как AWS Lambda функция, с доступом к ней через AWS API Gateway (радости serverless архитектуры!) для лёгкого и надёжного использования. Механизм работает так:
- Пользователь успешно аутентифицируется через SSO.
- Приложение обходит настроенные аккаунты AWS в поисках специально отмеченной Группы Безопасности (концепция AWS для правил файрвола)
- Приложение обновляет Группу Безопасности, разрешая доступ IP адресу запрашивающего. Правило в Группе Безопасности также хранит временную метку добавления.
- Cron-задача каждый заданный промежуток времени очищает список разрешённых IP.
Благодаря этой ситуации, мы теперь хвастаемся решением для удалённого доступа, которое полностью закрыто для Интернета и требует двухфакторную аутентификацию через нашу базу пользователей ещё до открытия порта в файрволе.
А ещё это просто!
Я ещё не коснулся того, насколько эти механизмы просты в эксплуатации. Я знаю, что составляющих много, но все вместе они создают очень даже простую авторизацию:
- Войти через SSO.
- Нажать на запуск Enterprise Port Knocking в портале SSO.
- В терминале, используя команду SSH указать пункт назначения в виде ID целевого EC2 инстанса. Система OASA достаточно умна, чтобы понять, какую точку входа использовать и всё остальное происходит полностью автоматически!
Вся эта система — большая победа для нашей инфраструктуры, для соблюдения нами всех соглашений по безопасности и для безопасности наших клиентов. Пользователям очень нравится, насколько легко подключиться к нашим серверам, ведь не надо проходить дополнительную аутентификацию или запоминать какой VPN использовать. А мне очень нравится мой спокойный сон. От новой модели выиграли все!
Ну, кроме хакеров, конечно.
