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

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

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

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

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

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

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

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

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

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

Рубрика: 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 | Отзывов: 15 »

Настройка маршрутизации в 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, Сети | Отзывов: 11 »

Как скачать ftp на русском или поддержка unicode ftp-клиентами

Столкнулся в самом начале своей работы в инет агентстве с тем, что пришлось переносить один через-жопу-сделанный-сайт™ (далее ЧЖСС), который еще до моего прихода в контору, ваяли некие омские умельцы, о которых я уже упоминал как то, и видимо еще буду неоднократно их вспоминать. Собственно при переносе всплыла некая особенность реализации, что люди не удосужились озадачиться юзерфрендли алгоритмом переименовывания русскоязычных картинок, при загрузке на сайт, в англоязычные. Поэтому они грузились на сайт в таком же виде что и были на компе, с той лишь разницей- поскольку все это проходило через Drupal, что русские названия сохранялись в кодировке utf-8.

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

А оказалось что проблема в том, что кодировку utf-8 поддерживает весьма небольшое количество ftp-клиентов, так что следующим этапом стал поиск удобоваримого клиента, в резьтате чего сформировался следующий список:

SmartFTP
FileZilla (вроде как в варианте патченной версии)
плагин к FireFox- Fireftp
Lftp
FTPRush

Из них я попробовал несколько штук, и остановился на SmartFTP- правда к сожалению данный клиент является коммерческим, что подразумевает что за него надо бы платить денег. Так как с FileZilla у меня возникли таки траблы с переносом файлов, Fireftp эпизодически задумывалось о судьбах рунета, в вот SmartFTP работал отлично, так что в данный момент я использую исключительно его, в том числе и для работы с файлами по ftp на русском, поскольку решать проблему русскоязычных файлов никто не захотел. SmartFTP оказался отличным ftp-клиентом, который помимо возможности скачать ftp на русском позволяет выполнять все необходимые для ftp-клиента функции: качать, переносить директории и файлы без трансфера на удаленную машину, редактировать удаленные файлы, менять права и многое-многое другое. Единственный вскрывшийся глюк оказался в том, что при редактировании файла на локальной машине- следует убирать выделение с файла, так как он, при попытке сохранения изменений, будет удален.

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