Как настроить безопасный доступ

Безопасный и комфортный доступ в интернет или как защитить свою сеть от интернет угроз без неудобств

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

Практика полного разделения локальной сети и доступа в интернет достаточно правильная и, по мнению многих ИТ специалистов, является единственным 100% способом защиты корпоративных данных. Однако, данный способ, помимо больших затрат на его реализацию, имеет еще один весьма существенный недостаток, а именно неудобство использования интернета. Отсутствие комфортного доступа к интернету влечет за собой не только прямые потери в виде снижения эффективности работы сотрудников, но и косвенные, такие как снижение лояльности сотрудников и престижа работы, что является прямой причиной роста затрат компании.

Типичная схема подобной сети выглядит так:

Данная схема полностью отделяет рабочие места от сети интернет и даже в случае попадания трояна на компьютер сотрудника он не сможет передать украденную информацию в интернет. Также сеть, построенная по такой схеме, предотвращает несанкционированное распространение конфиденциальной информации сотрудником компании через интернет.

И все же, при всей безопасности данная схема имеет существенный недостаток – это отсутствие гибкости и комфортной работы, так как возможны только два состояния: у сотрудника или совсем нет доступа в интернет, или он есть на отдельной машине.

Чтобы решить эти проблемы и позволить сотруднику полноценно работать, есть интересное решение в виде виртуализации приложений, у Microsoft данная технология называется App-V.

Microsoft Application Virtualization (App-V) технлогия позволяющая сделать программы доступными для пользовательских компьютеров без необходимости устанавливать их непосредственно на эти компьютеры. Благодаря процессу, называемому виртуализацией приложений, который позволяет каждому приложению работать в собственной автономной виртуальной среде на клиентском компьютере. Виртуализированные приложения изолированы друг от друга. Это позволяет избежать конфликтов между приложениями, но они по-прежнему могут взаимодействовать с клиентским компьютером.

Осуществляется это следующим образом: в DMZ устанавливаем терминальный сервер, на который разрешаем интернет-трафик, настраиваем интернет-браузер как виртуальное приложение, запрещаем использование буфера и использование локальных ресурсов через RDP. Также в DMZ настраиваем Remote Desktop Gateway и разрешаем доступ к нему по https из сети компании.

Итак, что мы имеем в итоге:

Пользователи компании, изолированные внутренней сетью от интернета, заходят на внутреннюю веб-страницу сервиса RDG, на которой опубликован интернет–браузер или запускают RDP файл.

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

Источник

Как организовать удаленный доступ и не пострадать от хакеров

Когда руководство компании экстренно требует перевести всех сотрудников на удаленный доступ, вопросы безопасности зачастую отходят на второй план. Как результат – злоумышленники получают отличное поле для деятельности.

Безопасная публикация ресурсов

Публикуйте веб-ресурсы через Web Application Firewall (в простонародье – WAF). Для быстрого развертывания и базовой защиты достаточно будет использовать стандартные профили защиты по OWASP Top 10. В первое время придется много подкручивать гайки в части отлова false positive событий. Если прямо сейчас у вас нет WAF – не отчаивайтесь! Если у вас стоит на тестировании какая-то триальная версия WAF, попробуйте задействовать ее для решения этой задачи, либо установите open-source решение Nginx + ModSecurity.

Если воспользоваться WAF не удалось, то спешно (по возможности) переводите приклад на HTTPS, проверяйте все пароли (пользовательские, админские) для публикуемого приложения на соответствие установленной в компании парольной политике. Не забудьте проверить операционные системы и CMS на свежесть, а также присутствие всех необходимых патчей, словом – санитизируйте все участки будущего общедоступного сервиса. Разверните Kali Linux и воспользуйтесь встроенным набором утилит для сканирования уязвимостей, если времени на это нет – воспользуйтесь одним из публичных сканеров уязвимостей (Detectify, ImmuniWeb и др.).

Чего делать не надо? Не стоит выставлять на показ в Интернет ваш замечательный самописный приклад на HTTP, в котором могут быть тысячи уязвимостей. Не надо выставлять и доступ по SSH к серверу или сетевому оборудованию, если не хотите, чтобы на вас полился брутфорс, а также не нужно напрямую публиковать RDP до целевых станций (привет, esteemaudit). Если есть сомнения в конкретном приложении, до которого нужно обеспечить доступ, разместите его за VPN.

С публикацией ресурсов разобрались, перейдем к сервисам, доступ до которых опубликовать не удалось. Для этого нам понадобится организовать VPN.

Что следует учесть при организации VPN?

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

Если, например, в вашей сети стоит межсетевой экран Fortinet или Check Point с любым бандлом (NGFW/NGTP/NGTX), поздравляю, поддержка функционала IPsec VPN идет «из коробки», и ничего дополнительного покупать и устанавливать вам не нужно. Останется только поставить клиенты на рабочие места и настроить межсетевой экран.

Если прямо сейчас у вас нет VPN-шлюза или межсетевого экрана, посмотрите в сторону open-source решений (OpenVPN, SoftEther VPN и т.п.), которые можно довольно быстро развернуть на любом сервере, благо, step-by-step гайдов в Интернете предостаточно.

Кроме того, желательно, чтобы ваш VPN-шлюз интегрировался с AD/RADIUS для централизованного управления учетными записями. Также не забудьте проверить парольную политику и настройте защиту от брутфорса.

Если вы решили идти по пути установки клиента удаленного доступа на рабочие места пользователей, нужно будет определиться, какой режим VPN использовать: Full Tunnel или Split Tunnel. Если доступ для отдельной группы пользователей предполагает работу с конфиденциальной или высококритичной информацией, то я бы порекомендовал использовать Full Tunnel режим. Таким образом весь трафик будет заруливаться в туннель, выход в Интернет для пользователей можно будет организовать через прокси, при желании трафик можно будет слушать еще и через DLP. В иных случаях можно ограничиться обычным Split Tunnel режимом, при котором трафик заруливается в туннель только до внутренних сетей компании.

После успешной аутентификации пользователей вам следует определиться с авторизацией: куда давать пользователям доступ, как и где это делать. Есть несколько вариантов.

1. Прямой доступ. Пользователь получил IP-адрес из своего VPN-пула и может идти напрямую к необходимым ресурсам (читай – через межсетевой экран). Здесь следует отметить, что если у вас стоит простой L4 межсетевой экран, на котором уже были настроены политики доступа (и их много!), то быстро адаптировать их к новым пулам IP-адресов может не получиться. Даже если у вас стоит NGFW с политиками по пользователям или группам пользователей, лог-оны в AD не будут зафиксированы (если только у вас не стоит специальный клиент на каждом рабочем месте), и политики тоже не будут работать. В таком случае политики придется создавать непосредственно на VPN-шлюзе либо использовать RADIUS при аутентификации и интегрировать его с клиентом межсетевого экрана для трекинга лог-онов пользователей.
2. Терминальный доступ. Если у вас есть NGFW с политиками по пользователям и терминальный сервер, то можно сделать так. При реализации терминального доступа (например, с помощью MS RDS) пользователь, получивший удаленный доступ, логинится на терминальный сервер. Поставьте на него специальный агент от производителя межсетевых экранов (например, FSSO TS). Этот агент будет сообщать межсетевому экрану IP-адрес залогинившегося пользователя, в результате чего написанные политики безопасности по пользователям или группам пользователей останутся без изменений, и не придется спешно менять политики на NGFW.

Рабочие места пользователей – защищены?

Перейдем к безопасности рабочих мест.

Оцените безопасность рабочих мест удаленных пользователей: вы даете им рабочие станции с установленным золотым образом со всеми необходимыми фичами безопасности (antivirus, host-based IPS/Sandbox и т.п.), или они сидят со своих домашних ноутбуков с неизвестно каким софтом? Если ответ на этот вопрос – домашние устройства, то лучше бы после предоставления удаленного доступа зарулить трафик на NGFW с IDS/IPS, а в идеале еще и на сетевую «песочницу».

Одним из хороших вариантов также будет публикация на VDI конкретного приложения для работы (браузера, почтового клиента и т.п.). Это позволит разрешить доступ только к конкретным используемым приложениям.

Если у вас в компании запрещено подключение съемных носителей, то в случае удаленного доступа об этом также не стоит забывать, ограничив такую возможность для свежевыданных корпоративных ноутбуков.

Как обычно, убедитесь, что отключены небезопасные протоколы и службы, нелишним будет включить шифрование диска (вдруг ваш пользователь пойдет поработать в коворкинг, и его корпоративный ноутбук украдут?), не забудьте отобрать права привилегированного доступа (если ноутбук корпоративный).

Аутентификация

Используйте централизованное управление учетными записями при удаленном доступе (AD/RADIUS), а также не забудьте продумать сценарии, при которых ваш Identity Store будет недоступен (например, создайте дополнительно локальные учетные записи).

Хорошей практикой будет использование клиентских сертификатов, самоподписные сертификаты можно выпустить и на Microsoft CA.

Предположим, что в связи с непредвиденными обстоятельствами у ваших удаленных пользователей все-таки увели учетные данные. Двухфакторная аутентификация поможет справиться и с этой напастью (OTP-пуши на мобильных устройствах, SMS). А вот двухфакторную аутентификацию через корпоративный email я бы не рекомендовал (зачастую для аутентификации при удаленном доступе используются такие же учетные записи, как и в электронной почте, и, стало быть, ваш второй фактор легко будет вытащить). Если нужно быстро организовать двухфакторную аутентификацию, можно посмотреть в сторону публичных сервисов – например, Google Authenticator.

Эксплуатация

Продумайте, как ваш ИТ-департамент будет эксплуатировать удаленные рабочие места и помогать пользователям в решении повседневных проблем. Явно потребуется удаленный доступ сотрудников техподдержки к удаленным рабочим местам пользователей.

Желательно, чтобы рабочие станции «разливались» из золотого образа, и вам не пришлось пытаться восстанавливать работоспособность домашних компьютеров сотрудников из-за того, что они поставили что-то не то, или, чего доброго, поймали какой-то ransomware. Лучше выдайте корпоративные ноутбуки с заранее известными мощностями и составом установленного ПО, чтобы не получить головную боль с домашними ПК сотрудников, ведь ими могут пользоваться дети, на них может дико тормозить система или может не быть необходимых средств защиты.

Нелишним будет напомнить пользователям перед переходом на удаленную работу существующие в компании политики безопасности: мало ли как захочется рядовому пользователю расслабиться в обеденный перерыв дома.

Источник

Как организовать защищённый доступ при помощи VPN

Кому нужен VPN?

На март 2017 г. доля вакансий о работе с удаленным доступом, размещенных на hh.ru составляла 1,5% или 13 339 вакансий. За год их число удвоилось. В 2014 г. численность удаленных сотрудников оценивалась в 600 тыс. чел или 1% от экономически-активного населения (15–69 лет). J’son & Partners Consulting прогнозирует, что к 2018 г. около 20% всех занятых россиян будут работать удаленно. Например, до конца 2017 г. Билайн планирует перевести на удаленное сотрудничество от 50% до 70% персонала.

Зачем компании переводят сотрудников на удаленку:

• Сокращение затрат компании на аренду и содержание рабочих мест.
• Отсутствие привязки к одной локации дает возможность собирать команду
  проекта, которую никогда нельзя было бы собрать в пределах одного города. Дополнительный плюс – возможность использования более дешевой рабочей силы.
• Удовлетворение потребности сотрудников в связи с их семейными обстоятельствами.

Мы для себя открыли потребность в VPN более 10 лет назад. Для нас мотиватором предоставления VPN доступа сотрудникам была возможность оперативного доступа в корпоративную сеть из любой точки мира и в любое время дня и ночи.

Путь выбора идеального VPN решения

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

VPN в роутерах

Так называемых “китайских решений” на рынке много. Практически любой роутер имеет функциональность встроенного VPN сервера. Обычно это простое вкл/выкл функционала и добавление логинов паролей для пользователей, иногда интеграция с Radius сервером. Почему мы не стали рассматривать подобное решение? Мы прежде всего думаем о своей безопасности и непрерывности работе сервиса. Подобные же железки не могут похвастаться ни надежной защитой (прошивки выходят обычно очень редко, или не выходят в принципе), да и надежность работы оставляет желать лучшего.

VPN Enterprise класса

Если посмотреть на квадрат Гартнера то на VPN рынке уже давно лидирующие позиции занимают компании, которые производят сетевое оборудование. Juniper, Cisco, Check Point: все они имеют комплексные решения решения, в составе которых есть и VPN сервис.

Минусов у подобных решений, пожалуй, два. Первый и главный — высокая стоимость. Второй — скорость закрытия уязвимостей оставляет желать лучшего, а если не платить ежегодные взносы за поддержку, то обновлений безопасности ждать не стоит. Не так давно появился и третий момент — закладки, встроенные в ПО крупных сетевых вендоров.

Microsoft VPN

10 лет назад мы были компанией, ориентированной прежде всего на Windows. Microsoft предлагает бесплатное решение для тех, у кого вся инфраструктура построена на их базе. В простых случаях настройка не вызывает сложностей даже у начинающего системного администратора. В нашем случае мы хотели выжать из VPN все с точки зрения безопасности, соответственно, использование паролей было исключено. Мы естественно хотели использовать сертификаты вместо паролей и для хранения ключевой пары использовать свой продукт Рутокен ЭЦП. Для реализации проекта нам нужно было: контроллер домена, радиус сервер и правильно поднятая и настроенная инфраструктура PKI. Подробно на настройке я останавливаться не буду, в интернете есть достаточно много информации по данным вопросам, а правильная настройка PKI вообще может потянуть на десяток статей. Первым протоколом, который мы использовали у себя, был протокол PPTP. Долгое время данный вариант VPN нас устраивал, но в конечном итоге нам пришлось отказаться от него по двум причинам: PPTP работал далеко не везде и мы начинали пользоваться не только Windows, но и другими операционными системами. Поэтому мы стали искать альтернативы. Замечу, что поддержка PPTP не так давно была прекращена apple. Для начала мы решили посмотреть, что еще из протоколов может предложить на Microsoft. SSTP/L2TP. SSTP нас устраивал всем, за исключением того, что он работал только на Windows. L2TP данным недостатком не обладал, но его настройка и поддержание его в работе показались нам достаточно затратными и мы решили попробовать альтернативы. Хотелось более простого решения, как для пользователей, так и для администраторов.

OpenVPN

Мы в компании “Актив” искренне любим open source. Выбирая замену Microsoft VPN мы не могли обойти стороной решение OpenVPN. Основным плюсом для нас было то, что решение «из коробки» работает на всех платформах. Поднять сервер в простом случае достаточно просто. Сейчас, используя docker и, к примеру готовый образ, это можно сделать за несколько минут. Но нам хотелось большего. Нам хотелось добавить в проект интеграцию с Microsoft CA, для того, чтобы использовать выданные ранее сертификаты. Нам хотелось добавить поддержку используемых нами токенов. Как настраивать связку OpenVPN и токены описано к примеру вот в этой статье. Сложнее было настроить интеграцию Microsoft CA и OpenVPN, но в целом тоже вполне реализуемо. Получившимся решением мы пользовались около трех лет, но все это время продолжали искать более удобные варианты. Главной возможностью, которую мы получили, перейдя на OpenVPN, был доступ из любой ОС. Но остались еще две претензии: сотрудникам компании нужно пройти 7 кругов ада Microsoft CA для выписывания сертификата, а администраторам по-прежнему приходилось поддерживать достаточно сложную инфраструктуру VPN.

Рутокен VPN

У нас есть знание, как использовать токены в любых операционных системах, у нас есть понимание, как правильно готовить инфраструктуру PKI, мы умеем настраивать разные версии OpenVPN и мы имеем технологии, которые позволяют управлять всем этим удобным для пользователя образом из окна браузера. Так возникла идея нового продукта.

Настройка Рутокен VPN

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

На втором шаге нужно ввести название компании и подождать несколько минут, пока устройство произведет настройку встроенного центра сертификации.

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

Четвертым шагом настройки мы создаем локальных пользователей, или добавляем их из AD

На этом настройку можно считать завершенной, все остальные действия может произвести сам сотрудник (хотя все может сделать и администратор).

Личный кабинет сотрудника

После того, как администратор добавил пользователей, сотрудник может воспользоваться порталом самообслуживания.

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

После установки плагина/расширения нам остается лишь сгенерировать сертификат себе на Рутокен ЭЦП.

И установить клиент под нужную операционную систему:

Как все это работает?

Немного об аппаратной части. Изначально мы долго думали, какую “базу” использовать для нашего решения, так как нужно было соблюдать баланс между стоимостью, удобством, производительностью. После исследований, что предлагается на рынке, мы остановились на двух вариантах реализации и дальнейшего распространения решения:

• x86 (Enterprise) – программное решение, которое предоставляется конечному потребителю в виде образа виртуальной машины, который можно развернуть в рамках своей ит-инфраструктуры.

• Raspberry Pi – уже достаточно известный микрокомпьютер, который обладает вполне неплохой производительностью при не самой высокой стоимости и который можно начать использовать как VPN-сервер уже через 10 минут после того, как его в прямом смысле вынули из коробки.

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

Но изначально, нам все же нужно осуществить настройку сервисов, которые требуются для корректной работы продукта. Настройка сервисов осуществляется на текущий момент специалистами нашей компании в полуавтоматическом режиме. Это значит, что автоматизирован процесс деплоя программного обеспечения и первичных настроек, но инициализация данного процесса пока остается привилегией человека. Во время первичной настройки устанавливаются системные пакеты, python, django, OpenVPN, supervisor, OpenSSL и пр.

А что же дальше? Далее необходимо настроить всю инфраструктуру, которая собственно и отвечает в целом за безопасность. А именно: CA (центр сертификации), PKI (инфраструктура открытых ключей), выписать необходимые ключи и сертификаты.

Создание PKI и CA, а также формирование файла конфигурации OpenVPN-сервера, генерация ключей и выписывание сертификатов осуществляется уже после передачи продукта клиенту. Но это не значит, что для этого необходимо иметь какие-то специфические знания и прямой доступ к операционной системе. Все реализовано в бизнес-логике бэкенда системы администрирования, доступ к которой предоставляется через Web-интерфейс. От клиента требуется только ввести минимальный набор атрибутов (описано выше), после чего стартует процесс инициализации PKI и создания СА. Описывать конкретные вызовы системных команд смысла особого нет, так как уже давно все описано и разжевано до нас. Главное, что мы сделали — это автоматизировали данный процесс, избавив пользователя от необходимости обладать специфическими знаниями в администрировании.

Для работы с ключами и сертификатами мы решили не изобретать велосипед (хотя очень хотелось и до сих пор вынашиваем мысль его изобрести исходя из наших дальнейших планов развития продукта) и используем easy-rsa.

Самый долгий процесс при настройке инфраструктуры – это генерация файла Diffie-Hellman. Мы долго экспериментировали с параметрами и пришли к балансу “качество-производительность”. Хотя были мысли вообще избавиться от данного шага, нагенерировать таких файлов заранее, используя наши серверные мощности и просто “раздавать” их во время первичной инициализации. Тем более, что данные, содержащиеся в этом файле не являются приватными. Но пока мы оставили эти мысли для дальнейших “изысканий”.

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

Первую задачу мы решили благодаря нашему плагину который реализует функциональность электронной подписи, шифрования и двухфакторной аутентификации для Web- и SaaS-сервисов. Для того, чтобы выписать сертификат и записать его на токен, пользователь должен установить данный плагин, перейти по ссылке чтобы попасть в личный кабинет сервиса RutokenVPN, предварительно подключив токен к компьютеру (подробнее о плагине можно прочитать на нашем ресурсе )

При инициализации процесса выписывания сертификата, осуществляется запрос на токен для генерации ключевой пары а также запрос на выписку сертификата в CA. Приватный ключ записывается на токен, а запрос на выписку сертификата отправляется в СА, который в свою очередь осуществляет его выписывание и возвращает в ответе. После чего сертификат так же записывается на токен.

Почти все готово для установления VPN-соединения. Не хватает клиента, который “знает”, как работать с сервером и нашими токенами.

Наш клиент реализован на Electron. Кто не в курсе, что это за зверь, то если совсем кратко – возможность реализовать десктопное приложение, используя js, css и html. Не вдаваясь в подробности, клиент является неким “враппером” над OpenVPN-клиентом, позволяющим осуществлять его вызовы с нужными параметрами. Почему именно так? На самом деле нам было так удобней, хотя выбранное решение и накладывает определенные ограничения.

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

При запросе на установку VPN-соединения, запрашивается PIN-код ключа, при корректном вводе извлекается сертификат для аутентификации клиента, осуществляется хэндшейк клиента с сервером и устанавливается VPN-соединение. Знающие люди могут возразить, что не все так просто, но целью данного описания не является рассказать все тонкости работы OpenVPN, а только осветить основные моменты нашей реализации.

Немного о наших планах. Основное, над чем сейчас мы работаем — это реализация ГОСТ-шифрования. Уже пройден достаточно большой путь исследований, позволивший нам максимально приблизиться к ее реализации. В ближайшее время сможем удовлетворить интерес потенциальных клиентов в данной функциональности.

Источник