Как исправить ошибки детских VPN в корпоративной сети

Детcкий VPN

В шахматах есть понятие "детский мат", когда неопытный игрок проигрывает партию за 3 своих хода.

В корпоративных сетях ситуация сложилась такая же - очень много инсталляций VPN шлюзов сделано так, что любой хакер проникает внутрь сети за один шаг. 

Основные три ошибки детского VPN:

1. Логин и пароль единственное, что нужно знать для проникновения в сеть.
2. Рабочая станция дома никак не защищается и любой хакер попавший на компьютер мгновенно узнает логин и пароль на VPN и следующим шагом попадает в сеть компании с полными правами данного сотрудника.
3. Сетевое подключение внутри сети никак не защищается и любой сотрудник компании может делать все что угодно: забирать файлы, оставлять файлы, копировать информацию компании или уничтожать.

Такой VPN называется тоже детским. Обычно это значит, что автор этой дыры в безопасности просто прочитал документацию к каком-то шлюзу, например, это часто OpenVPN и собственно реализовал этот дырявый VPN для своей компании. Да, решение ставится методом next-next-finish, но дает доступ не только сотрудникам, он и всем-всем-всем.

Взрослый VPN: MFA, HIP, NGFW

Соответственно, исправление ситуации достигается изменением и повышением безопасности всех трех ошибочных пунктов.

1. MFA. Двухфакторная аутентификация 

Кража и подбор логина и пароля является частой атакой и применяется постоянно. Чтобы минимизировать эту угрозу нужно использовать второй фактор. В современных VPN существует компонент, который позволяет добавить проверку сообщения на телефоне, и это рекомендуется делать. Лидером игроками здесь является компания Okta, но я приведу весь квадрат Gartner где показаны другие проекты позволяющие реализовать второй фактор. Есть еще одна частая ошибка - сертификат считают вторым фактором. Однако он хранится на компьютере жертвы и его нельзя считать за второй фактор. Второй фактор должен быть обязательно на стороннем устройстве.

2. HIP и XDR. Comliance проверки.

Рабочая станция дома - это точка наивысшей опасности. То что мы дали сегодня людям возможность подключаться не с рабочих машин, а с домашних компьютеров - в общем уже большая дыра в безопасности. А то что мы еще и не контролируем ничего там - это просто epic fail. Но главное не бояться! Все поправимо

Существуют реально два механизма, которые могут нам помочь дома

• проверка состояния хоста клииентом VPN
• проверка состояния хоста специализированной защитой EDR/XDR

Host Information Profile позволяет шлюзу VPN убедиться, что вы подключаетесь с рабочей станции, на которой выполнены минимальные проверки безопасности. Для вас этот фукнционал может быть неожиданностью, однако это стандартные функции корпоративного VPN, который предоставляют такие лидеры рынка VPN как Palo Alto Networks.

EDR/XDR позволяет постоянно контролировать что происходит на рабочей станции, блокировать угрозы и расследовать инциденты, если требуется.

Если вы будете проверять обоими методиками, то вы создадите серьезные проблемы злоумышленнику. Начните!

3. NGFW

Сам VPN клиент архитектурно может приземлять ваши IPSEC туннели в сеть и сразу давать доступы к нужным ресурсам: серверам, рабочим станциям. Однако это неверно с точки зрения безопасности - архитекторы приземляют VPN сегодня в NGFW. NGFW это многофункциональное устройство и оно не просто дает вам доступ в сеть как VPN шлюз, но и контролирует домашнего пользователя: что он делает, каким приложением, какие файлы забирает, нет ли там вирусов или не производит ли он сканирование сети. Если вы не используете NGFW для контроля действий сотрудников, которые подключены по VPN, то любой человек делает в сети что ему заблагорассудится, а если это хакер, то он вам всемерно благодарен. 

По идее все эти три пункта сделать несложно, но нужно постоянно контролировать изменения, ведь у вас меняются люди, меняется архитектура подключений.

И еще тонкость

И в заключение важно заметить, что удаленный доступ выявил одну проблему: никто никогда не планировал в компаниях доступы сотрудников. Часто все доступно всем. В случае с удаленным доступом из дома это создало катастрофический объем возможностей для злоупотреблений. В случае, когда люди работали из офиса, то это было незаметно, а вот сейчас, когда человек из дома имеет ко всему, причем ненужному ему по работе - это то, что нужно минимизировать. Обсудите этот проект в своей компании и займитесь минимизацией привилегий. И это срочно!

С 1 января 2021 банки должны перевести межсетевые экраны в режим анализа приложений по ГОСТ ЦБ 57580

 

В стандарте Центрального Банка ГОСТ 57580 существует несколько пунктов, где упоминается межсетевое экранирование на прикладном уровне, например, в разделе 7.3. ЦБ говорит, что с 1 января 2021 года эти требования УЖЕ должны быть выполнены для банков России. Но проблема в том, что у многих банков стоят устаревшие межсетевые экраны, в которых включение анализа трафика на уровне приложений просто невозможно - у них не хватает производительности. Продвинутые банки делали весь этот год проекты по замене межсетевых экранов на более производительные. Хитрые банки сделали проще - они просто выключили все функции анализа и с выключенной функциональностью межсетевые экраны тянут нужные скорости. Но с 1 января эти банки так сделать не смогут - нужно будет показывать свои настройки во время аудита и возникнет вопрос как быть - ведь сеть просто упадет при включении любой дополнительной функции: анализ приложений и файлов в них - это очень нагрузочная операция для процессора любого устройства.

Минимизация рисков использования DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)

Защита от DoH и DoT

Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Одной из областей, которой часто не уделяется должного внимания, является DNS. Контролируете ли вы свой DNS трафик?

Серьезность проблемы в том, что по данным Palo Alto Networks Unit 42 Threat Research, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.

 

Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например, заплатили 10 миллионов долларов.

 

Презентация Verisign по тому как Ransomware использует DNS.

При правильной настройке NGFW могут запрещать или защищать использование DNS-over-TLS (DoT) и могут использоваться для запрета использования DNS-over-HTTPS (DoH), что позволяет анализировать весь трафик DNS в вашей сети.

Что такое зашифрованный DNS?

Система доменных имен (DNS) преобразует удобочитаемые доменные имена (например, адрес www.paloaltonetworks.com ) в IP-адреса (например, в 34.107.151.202). Когда пользователь вводит доменное имя в веб-браузере, браузер отправляет DNS-запрос на DNS-сервер, запрашивая IP-адрес, связанный с этим доменным именем. В ответ DNS-сервер возвращает IP-адрес, который будет использовать этот браузер.

 

Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или перехвата и перенаправления в нежелательные пункты назначения. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. В частности, зашифрованные протоколы DNS защищают от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом. 

 

За последние несколько лет были внедрены два протокола шифрования DNS:

1. DNS-over-HTTPS (DoH)

2. DNS-over-TLS (DoT)

Эти протоколы имеют одну общую черту: намеренно прячут DNS-запросы от любого перехвата и от безопасников организации в том числе. Протоколы в основном используют протокол TLS (Transport Layer Security) для установления зашифрованного соединения между клиентом, выполняющим запросы, и сервером, разрешающим запросы DNS, через порт, который обычно не используется для трафика DNS.

 

Конфиденциальность запросов DNS является большим плюсом этих протоколов. Однако, они создают проблемы безопасникам, которые должны следить за сетевым трафиком и обнаруживать и блокировать вредоносные соединения. Поскольку протоколы различаются по своей реализации, методы анализа будут отличаться у DoH и DoT.

DNS over HTTPS (DoH)

DNS внутри HTTPS

Этот протокол использует хорошо известный порт 443 для HTTPS, для которого в RFC специально указано, что задача состоит в том, чтобы «смешать трафик DoH с другим трафиком HTTPS в одном и том же соединении», «затруднить анализ трафика DNS» и, таким образом, обойти меры корпоративного контроля ( RFC 8484 DoH, раздел 8.1 ). Протокол DoH использует шифрование TLS и синтаксис запросов, предоставляемый общими стандартами HTTPS и HTTP/2, добавляя запросы и ответы DNS поверх стандартных запросов HTTP.

Риски, связанные с DoH

Если вы не задались целью отличить обычный HTTPS-трафик от запросов DoH, то приложения внутри вашей организации могут обходить локальные настройки DNS, перенаправляя запросы на сторонние сервера отвечающие на запросы DoH, что обходит любой мониторинг, то есть уничтожает возможность контроля за DNS трафиком. В идеале вы должны контролировать DoH используя функции расшифрования HTTPS.

 

И Google, и Mozilla реализовали возможности DoH в последней версии своих браузеров, и обе компании работают над использованием DoH по умолчанию для всех запросов DNS. Microsoft также разрабатывает планы по интеграции DoH в свои операционные системы. Минусом является то, что не только уважаемые компании-разработчики программного обеспечения, но и злоумышленники начали использовать DoH как средство обхода традиционных мер корпоративного межсетевого экрана. ( Например, просмотрите следующие статьи: PsiXBot теперь использует Google DoH, PsiXBot продолжает развиваться с обновленной инфраструктурой DNS и анализ бэкдора Godlua.) В любом случае, как хороший, так и вредоносный трафик DoH останется незамеченным, оставив организацию слепой к злонамеренному использованию DoH в качестве канала для управления вредоносным ПО (C2) и кражи конфиденциальных данных.

 

Обеспечение видимости и контроля трафика DoH

В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https). 

Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласно руководству по лучшим методам расшифровки.

 

Во-вторых, создайте правило для трафика приложения «dns-over-https», как показано ниже:

В качестве промежуточной альтернативы, если ваша организация не полностью реализовала расшифрование HTTPS, NGFW все еще можно настроить для применения действия «запретить» к идентификатору приложения «dns-over-https», но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см.  Applipedia от Palo Alto Networks  и выполните поиск по фразе «dns-over-https») .

 

DNS over TLS (DoT)

DNS внутри TLS

В то время как протокол DoH стремится смешиваться с другим трафиком на том же порту, DoT вместо этого по умолчанию использует порт, зарезервированный для этой единственной цели, даже специально запрещая использование того же порта для традиционного незашифрованного трафика DNS (RFC 7858 , Раздел 3.1).

 

Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 (RFC 7858, раздел 6).  Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.

Риски, связанные с DoT

Google реализовал DoT в своем клиенте Android 9 Pie и более поздних версиях, при этом по умолчанию включена настройка автоматического использования DoT, если он доступен. Если вы оценили риски и готовы к использованию DoT на уровне организации, то нужно, чтобы сетевые администраторы явно разрешали исходящий трафик на порт 853 через свой периметр для этого нового протокола.

 

Обеспечение видимости и контроля трафика DoT

В качестве наилучшей методики контроля за DoT мы рекомендуем любое из вышеперечисленного, исходя из требований вашей организации:

• Настройте NGFW для расшифровки всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подписку Palo Alto Networks DNS Security для контроля DGA доменов или уже имеющийся DNS Sinkholing и anti-spyware.

• В качестве альтернативы можно полностью заблокировать движком App-ID трафик 'dns-over-tls' через порт 853. Обычно он заблокирован по умолчанию, никаких действий не требуется (если вы специально не разрешили приложение 'dns-over-tls' или трафик через порт 853).