Одминский блог

Повышение безопасности VPN сообщества

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

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

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

Крайне желательно, чтобы пользователи не имели вообще никакого доступа к сети, кроме терминального соединения со своей машиной, на которую бы они входили зная свою учетную запись, и IP адрес компьютера, с тем чтобы левому человеку было бы сложно отсканить сетку. В этой связи необходимо создавать базу пользователей и соответствия логинов (и как следствие сертификатов) и IP адресов машин, и поскольку мы заранее знаем какой IP получит сотрудник, то и на фаерволе на виртуальном интерфейсе разрешать прохождение не все ко всем, а определенный IP удаленного клиента, на определенный IP компьютера внутри сети. И только по RDP. Никаких 135, 137 и т.д портов. Ну или же, если у вас в сети есть терминальный сервер, то всех пользователей – на терминальный сервер.

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

Естественно, что для удаленного использования, оптимально было бы задействовать двухфакторную аутентификацию, основанную не только на шифровании на основе сертификата, но и на вводе пароля. Ибо если пользователь профуфыкает сертификат, то между логином и доступом в защищенное пространство сети, остается прокладочка в виде пароля. Для этого, для генерации сертификата пользователя, следует использовать команду:
# ./build-key-pass vpn-client
естественно не забывая проделывать все необходимые для генерации процедуры. Но тут мы можем упереться в пользователей не желающих вводить два пароля подряд- их конечно понять можно, но тут уже зависит от вашей настойчивости. Мне, если честно, мои нервы, в этом плане, всегда были дороже.

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

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

Рубрика: IT безопасность | Ваш отзыв »

Настройка VPN-сообщества под FreeBSD и OpenVPN

Возникла тут необходимость дать видеоинженерам клиента удаленный доступ в локалку. Видеоинженеры же народ ленивый- хочет монтировать передачи и ролики, не отрывая задницу от домашнего дивана, так что этим они несколько похожи на одминов. Поскольку клиент оказался нераскручивываем на приобретение CheckPoint UTM-1, а фаервол я ему уже как то поднимал под FreeBSD, то пришлось мутиться с настройкой VPN сервера под фряхой 8.2. Хотя я и хотел поставить Untangle, про который уже как то рассказывал, но по итогам решил, что проще будет поднять все на одной машине, но под управлением хорошо зарекомендовавшего себя пакета OpenVPN, который помимо того что поддерживает все вариации подключений, так еще и идет со своим клиентом. Поднимать все это богатство я решил на сертификатах открытых ключей Х.509 под управлением RSA Key Management. Лить воду на жернов копирайта по поводу выбора сертификации мне неохота, так как меня от этой темы трясет еще с экзаменов CCSA, так что сразу перейду к настройке решения. Ставить будем на нашу любимскую FreeBSD, предварительно заточив её по всем правилам науки.

(more…)

Рубрика: FreeBSD, IT безопасность | Ваш отзыв »

Забавный глюк работы связки named и ssh

Столкнулся тут с довольно забавным глюком связки ssh + named, в процессе прикручивания сервера доменных имен на работающем фаерволе. Брандмауэр был настроен уже какое то время назад, практически по мануалу который я напостил недавно, и вот на днях возникла необходимость сделать его еще и сервером доменных имен.

Хотя это конечно не безопасно, особенно исходя из концепции параноидальности на сетевом экране, тем более что не далее как в этом феврале была найдена уязвимость BIND 9 ветки, приводившая к DoS севера имен, при трансфере зоны или динамическом обновлении, но тем не менее пропатчив BIND и открыв его только вовнутрь сетки, решил что пользовать можно.

И вот в процессе настройки, когда вроде бы named резолвился для localhost но почему то не хотел стартовать на внутреннем интерфейсе, я решил раскомментировать строку в named.conf содержащую следующее выражение:
query-source address * port 53;

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

Изначально я полагал, что допустил в синтаксисе правил какую то ошибку, из-за которой правила не догружались до конца, но оказалось что таблица правил фаервола была загружена полностью. Да и ssh висел на порту, а вот named почему то отсутствовал. Попытка его стартануть не увенчалась успехом, так что я полез в логи, где обнаружил что прописал в named.conf фалы для зоны “.” дважды, точнее я то прописал один раз, не заметив, что они уже были обозначены. Что и приводило к падению демона named. Но что еще более поразительно- это же и приводило к нестабильной работе сервера ssh, отрубавшего логин к серверу.

Судя по всему, в случае падения демона named, резолвить имена подключений не получалось, так как в /etc/resolv.conf стоял только 127.0.0.1, и по этой самой причине соединение и рубилось на корню.

Так что на всякий случай добавил в /etc/ssh/sshd_config строчку отрубающую резолв имен: UseDNS no , хотя, в принципе, можно было бы и добавить дополнительных DNS серверов в resolv.conf

Рубрика: Сети | Ваш отзыв »

Терминальный сервер под управлением Windows 7

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

(more…)

Рубрика: Windows | Отзывов: 5 »

Настройка маршрутизации в MS Windows

Скажу откровенно- вопрос маршрутизации в Windows Server я для себя закрыл еще в далеком 200X году, когда некие умельцы в том филиале Ростелекома, где я работал на тот момент, пытались поднять программный маршрутизатор на платформе Server 2003 и скажу откровенно это выглядело уныло, так как у них постоянно падали сетки, отваливались маршруты, пакеты переставали ходить и прочее. Учитывая, что как раз в то же время я совокупил порядка 6 сеток за счет бездисковой станции, которая грузилась с дискетки Coyot Linux и шуршала только в путь, то в дальнейшем я использовал исключительно маршрутизацию на базе FreeBSD. Но тем не менее эпизодически возникает необходимость организации маршрутизации на базе Windows Server, с наиболее упертыми клиентами которые сами ничего делать не хотят, но и лезут с советами.

Тогда приходится влезать в это болото, которое называется маршрутизация средствами Windows платформ. Для начала посмотрим что  у нас прописано в таблице маршрутизации на сервере. Входим в терминальную консоль cmd и даем команду:
> route PRINT
которая нам высветит список имеющихся в системе интерфейсов, таблицу маршрутизации и постоянные маршруты. Кстати точно эту же картинку можно получить и командой:
> netstat -rn
Теперь собственно мы можем добавить статический маршрут, средствами командной строки. Предположим что нам надо срутить пакеты в сеть 172.16.0.0/24 через внутренний маршрутизатор 192.168.10.250, для чего задаем следующую команду:
> route add 172.16.0.0 mask 255.255.255.0 192.168.10.250 if 1
на самом деле можно со спокойной совестью опустить, маршрут подцепится и без этого, просто пакеты будут рутиться через внутренний интерфейс 127.0.0.1. Для того чтобы удалить данный маршрут достаточно сказать:
> route delete 172.16.0.0
При добавлении машртура мы можем получить загадошное сервисное сообщение “Запрошенная операция требует повышения”, для чего правой клавишей шелкаем в иконку командной строки и говорим “запуск от имени администратора”.
Но вся беда с том, что такие маршруты живут до следующей перезагрузки, поэтому нам необходимо сказать чтобы маршруты сохранялись на потсоянной основе, для чего задаем ключик -p:
> route -p add 172.16.0.0 mask 255.255.255.0 192.168.10.250

Собственно для меня это наиболее удобный вариант, так как не требует ковыряния с системе, да и подходит как для Windows Server, так и для простых рабочих станций под управлением виндусни; но особо беспокойные умы могут  воспользоваться на MS Server службой Network Policy and Access Services, для чего идем в Диспетчер сервера -> Роли -> Добавить роли -> Службы политики сети и доступа -> Маршрутизация (автоматом добавится Служба удаленного доступа) после чего уже в оснастке управления маршрутизации через правый клик на имени сервера включаем машрутизацию и, зайдя в раздел Статические маршруты прописываем необходимые нам маршруты. Там же можно настроить и политики прохождения пакетов (вкладка Основное, свойства интерфейсов), а также динамическую маршрутизацию, путем добавления RIP или IGMP протоколов.

Рубрика: Windows, Сети | Отзывов: 2 »

Ночное отключение сервиса icq

Не успело еще интернет сообщество оклематься от двух, прошедших практически подряд, эпикфелов сервиса voip телефонии skype, накернившихся сразу после приобретения сервиса мега-корпорацией Microsoft, как сегодня в ночь, повсеместно вырубился сервис интернет-пейджера icq. Причем на сайте icq на момент падения сервиса, и его подъема, не было никаких объяснений случившегося, кроме инфы о плановых технических работах, но при этом также был недоступен и официальный веб сайт. При этом отключились все клиенты использовавшие протокол icq. В отличии, например, от джабберовской сетки qip infium которая исправно работала на протяжении нескольких часов, что были недоступны сервисы icq.

Возникает стойкое ощущение того, что Microsoft прикупил и этот сервис также, но посмотрим как пойдет дальше. Хотя помимо мелкомягких мы знаем еще одну компанию СУП, чьи админы также любят проводить  технические работы на живом железе.

Рубрика: Дела Одминские | Ваш отзыв »

Как настроить машрутизатор средствами FreeBSD

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

Так что не боясь предстать капитаном очевидность в этот раз я распишу как организовать программный маршрутизатор средствами FreeBSD. И хотя писалось все это еще под 4.2, но тем не менее и под 7.4 все эти же рецепты применимы, разве только с той разницей, что все пакеты отличаются версиями с большую сторону. Сказать откровенно, я предпочитаю программные маршрутизаторы за их дешевизну, простоту и быстроту в настройке, поскольку для программного маршрутизатора сгодится любая древняя машинка, главное чтобы в ней была возможность поставить дополнительные сетевухи. При этом программный маршрутизатор отличается от аппаратных аналогов тем, что произведя один раз настройку маршрутизатора вы следующий настроите уже за полчаса, а не будите копаться в мануалах нового для вас агрегата, купленного клиентом с оказией, не понимая почему це фича вдруг оказалась багой. К тому же вменяемый аппаратный маршрутизатор стоит не малых денег и вполне сопоставим по стоимости с хорошим компом, который помимо того что будет с сотни раз мощнее, также при этом сможет, естественно при желании, стать принт-сервером, фаерволом, проксей, поточным антивирем и еще чем угодно, и что самое основное- это решение маштабируемое, то есть добавление нового интерфейса сопряжено с гораздо меньшими затратами, нежели при попытке расширения аппаратного маршрутизатора, главное подобрать материнку с 2-3 слотами под сетевуху, ибо найти две интегрированные не проблема. И естественно формула скорость работы/цена для программного маршрутизатора будет на порядки ниже аппаратного, так как стоимость гигабитного маршрутизатора уже будет сопоставима с покупкой мощного сервера для офиса. Ну это просто вода относительно того за что я люблю программные рутеры, а теперь собственно перейдем к самой настройке маршрутизатора.

(more…)

Рубрика: FreeBSD, Сети | Отзывов: 2 »