SSL VPN сервер Hypersocket
Monday, 17 Jul 2017Три дня и три ночи я долбался с SSL VPN ища программные безклиентные варианты. И даже нашел какой то прекрасный вариант Hypersocket, позиционирующий себя ровней SSL-Explorer.
Блог о технологиях, технократии и методиках борьбы с граблями
Три дня и три ночи я долбался с SSL VPN ища программные безклиентные варианты. И даже нашел какой то прекрасный вариант Hypersocket, позиционирующий себя ровней SSL-Explorer.
Возникла задача выдать человеку настроенное на Windows 7 L2TP VPN подключение, поскольку он чего то там делал криво, т.ч у него никак не хотело подключаться, а на счет удаленного доступа к его машине – гражданин параноил.
Возникла тут необходимость дать видеоинженерам клиента удаленный доступ в локалку. Видеоинженеры же народ ленивый- хочет монтировать передачи и ролики, не отрывая задницу от домашнего дивана, так что этим они несколько похожи на одминов. Поскольку клиент оказался нераскручивываем на приобретение CheckPoint UTM-1, а фаервол я ему уже как то поднимал под FreeBSD, то пришлось мутиться с настройкой VPN сервера под фряхой 8.2. Хотя я и хотел поставить Untangle, про который уже как то рассказывал, но по итогам решил, что проще будет поднять все на одной машине, но под управлением хорошо зарекомендовавшего себя пакета OpenVPN, который помимо того что поддерживает все вариации подключений, так еще и идет со своим клиентом. Поднимать все это богатство я решил на сертификатах открытых ключей Х.509 под управлением RSA Key Management. Лить воду на жернов копирайта по поводу выбора сертификации мне неохота, так как меня от этой темы трясет еще с экзаменов CCSA, так что сразу перейду к настройке решения. Ставить будем на нашу любимскую FreeBSD, предварительно заточив её по всем правилам науки.
Решил я тут повозиться с SSL VPN, чтобы был свой с бриджем и блудницами. Расписывать по технологии особо не буду, ибо вся инфа гуглится, но основное преимущество SSL VPN перед вcякими IPsec и иже с ними, в том, что для установления соединения через SSL VPN не нужен никакой дополнительный клиент, а достаточно браузера и наличия виртуальной машины Java и выполнения ActiveX, т.е установить соединение с нужным VPN можно с какой угодно машины – хотя в интернет кафе, хоть на вашем ноутбуке. К тому же соединение инкапсулируется в https, т.ч не требуется открытия каких то дополнительных портов, т.ч компьютеру необходимо только доступ в интернет и стандартный порт HTTPS, который частенько открыт даже в самых параноидальных конторах.
Пробовать я решил начать с достаточно древнего пакета SSL Explorer от компании 3sp, версия 1.0.0 RC17 которого была зарелизена аж в 2008 году. На данный момент контора, как я понимаю, ушла под Barracuda Network, которые занимаются разработкой всяческих кирогазов для информационной безопасности, в том числе и SSL VPN appliance, начинающиеся от штуки грина.
В процессе установки SSLExplorer в браузере вылезла ошибка:
HTTP ERROR: 500
Unable to compile class for JSP
Generated servlet error:
/root/sslexplorer-1.0.0_RC17/sslexplorer/tmp/org/apache/jsp/WEB_002dINF/jsp/layouts/layout_jsp.java:7: cannot access java.lang.Object
bad class file: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.1.el7_0.x86_64/jre/lib/rt.jar(java/lang/Object.class)
class file has wrong version 51.0, should be 49.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
public final class layout_jsp extends org.apache.jasper.runtime.HttpJspBase
RequestURI=/selectCertificateSource.do
Вскрылся интересный момент работы OpenVPN на клиентском компьютере под управлением Windows 7. Подняли VPN сообщество, чтобы люди могли из дома работать в офисной сети, ну и на одном из компьютеров, надо отметить Apple (что дало ложный ход мысли), после установки дров на принтер, компьютер перестал подключаться к VPN. Точнее он подключался вроде бы, но канал не поднимался, так как человек не мог достучаться по RDP и HTTP до внутренних ресурсов сети.
Так что клиентский админ поехал выяснять в чем дело. Опытным путем выяснили что при подъеме канала по каким то причинам не поднимался маршрут, то есть пакеты которые должны были идти через VPN канал в офисную сеть, не инкапсулировались, а вместо этого стучались по дефолтному маршруту. Я с таким пару раз сталкивался на Checkpoint VPN если не правильно задавались параметры сообщества, но тут явно проблема была в системе.
В итоге опытным путем выявили, что проблема в правах на запуск клиента OpenVPN, так как в системе Windows 7 настройки сети устанавливаются с правами администратора, поэтому и клиент должен запускаться с правами администратора, но после установки новых драйверов или устройства принтера эти права почему то съехали на не привилегированного пользователя. Возможно це не багу, це фича Apple’вских систем, но починить удалось именно переназначением прав.
В дополнение к статье об установке OpenVPN сервера в инфраструктуру предприятия, хочется разродиться измышлениями о том, каким образом можно повысить безопасность при работе через VPN соединение. Ведь не секрет, что работники бывают разные, как в плане пакостности, так и в плане рассеянности, и наличие соединения которое устанавливается одним кликом- в самое сердце предприятия, не есть здорово.
В этой связи можно произвести некоторые телодвижения, которыми возможно если не обезопасить, то хотя бы минимизировать риски, при работе сотрудников через удаленное соединение.
В первую очередь право раздачи удаленных доступов возложить на руководство отделов, а лучше компании, с тем чтобы избежать последующих воплей- как же ты мог допустить!!! Организации всех доступов только по письму начальника отдела. Никаких за шоколадку, на вечер, дочка болеет и прочей слюнявой шняги, ибо если что, то иметь будут персонально вашу задницу.
Крайне желательно, чтобы пользователи не имели вообще никакого доступа к сети, кроме терминального соединения со своей машиной, на которую бы они входили зная свою учетную запись, и IP адрес компьютера, с тем чтобы левому человеку было бы сложно отсканить сетку. В этой связи необходимо создавать базу пользователей и соответствия логинов (и как следствие сертификатов) и IP адресов машин, и поскольку мы заранее знаем какой IP получит сотрудник, то и на фаерволе на виртуальном интерфейсе разрешать прохождение не все ко всем, а определенный IP удаленного клиента, на определенный IP компьютера внутри сети. И только по RDP. Никаких 135, 137 и т.д портов. Ну или же, если у вас в сети есть терминальный сервер, то всех пользователей – на терминальный сервер.
Как я это не ни люблю, но необходимо вести полное логирование безопасности- входов в домен и выходов, а также действий внутри домена.
Естественно, что для удаленного использования, оптимально было бы задействовать двухфакторную аутентификацию, основанную не только на шифровании на основе сертификата, но и на вводе пароля. Ибо если пользователь профуфыкает сертификат, то между логином и доступом в защищенное пространство сети, остается прокладочка в виде пароля. Для этого, для генерации сертификата пользователя, следует использовать команду:
# ./build-key-pass vpn-client
естественно не забывая проделывать все необходимые для генерации процедуры. Но тут мы можем упереться в пользователей не желающих вводить два пароля подряд- их конечно понять можно, но тут уже зависит от вашей настойчивости. Мне, если честно, мои нервы, в этом плане, всегда были дороже.
Если вы устанавливаете удаленных клиентов на ноутбуки сотрудников, то повторно рекомендую организовать хранение сертификатов на флешках, или, что еще лучше, на шифрованных носителях- крипт-контейнерах. Настройка клиента в этом случае, указана в конце статьи по установке сервера OpenVPN.
Надеюсь, что указанные шаги, помогут вам повысить безопасность вашего VPN-сообщества, без погружения в пучину админской паранойи.