SSL VPN сервер Hypersocket
Monday, 17 Jul 2017Три дня и три ночи я долбался с SSL VPN ища программные безклиентные варианты. И даже нашел какой то прекрасный вариант Hypersocket, позиционирующий себя ровней SSL-Explorer.
Блог о технологиях, технократии и методиках борьбы с граблями
Три дня и три ночи я долбался с SSL VPN ища программные безклиентные варианты. И даже нашел какой то прекрасный вариант Hypersocket, позиционирующий себя ровней SSL-Explorer.
Возникла тут необходимость дать видеоинженерам клиента удаленный доступ в локалку. Видеоинженеры же народ ленивый- хочет монтировать передачи и ролики, не отрывая задницу от домашнего дивана, так что этим они несколько похожи на одминов. Поскольку клиент оказался нераскручивываем на приобретение CheckPoint UTM-1, а фаервол я ему уже как то поднимал под FreeBSD, то пришлось мутиться с настройкой VPN сервера под фряхой 8.2. Хотя я и хотел поставить Untangle, про который уже как то рассказывал, но по итогам решил, что проще будет поднять все на одной машине, но под управлением хорошо зарекомендовавшего себя пакета OpenVPN, который помимо того что поддерживает все вариации подключений, так еще и идет со своим клиентом. Поднимать все это богатство я решил на сертификатах открытых ключей Х.509 под управлением RSA Key Management. Лить воду на жернов копирайта по поводу выбора сертификации мне неохота, так как меня от этой темы трясет еще с экзаменов CCSA, так что сразу перейду к настройке решения. Ставить будем на нашу любимскую FreeBSD, предварительно заточив её по всем правилам науки.
У человека, при попытке подключиться к VPN сообществу, через клиента OpenVPN, вылетела ошибка сертификата
error:0906D06C:PEM routines:PEM_read_bio:no start line:
error:140AD009:SSL routines:SSL_CTX_use_certificate_file:PEM lib
Ошибка говорит о том, что с сертификатом какие то траблы, для чего ищем файлик C:\Program Files\OpenVPN\config\Ваше_имя.crt проверяем его размер и если он отличен от нуля, то открываем его в текстовом редакторе и проверяем наличие текста, содержащего мусорный на первый взгляд набор символов, по окончании которого находятся строки:
—–BEGIN CERTIFICATE—–
бла-бла кодированные данные
—–END CERTIFICATE—–
Теоретически если его размер отличен от нуля и данные строки присутствуют, то это проблема с путем до файла сертификата, поэтому проверяем в настройках конфига C:\Program Files\OpenVPN\config\openvpn.ovpn поле
cert Ваше_имя.crt
Если все вроде правильно, а связь тем не менее не устанавливается, то скачиваем сертификаты снова с VPN сервера, ну либо пересоздаем заново. Но как мне кажется все должно ограничиться первыми двумя пунктами.
Вскрылся интересный момент работы 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-сообщества, без погружения в пучину админской паранойи.
Сижу работаю. Приходит коллега и жалуется админу что не может со своего iPhone достучаться до офисного VPN который крутится под Cisco ASA. У меня уши естественно насторожились, поскольку до такой степени задротства, чтобы стучаться в офисную сеть со своего iPhone я еще не дошел. Человек ушел, начал ковыряться в телефоне и смотреть. Вообщем по порядку.