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

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

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

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

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

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

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

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

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

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

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

Критическая уязвимость сервера Apache

В наиболее популярном веб-сервере Apache, на этой неделе, обнаружена критическая уязвимость, которой подвержены многочисленные версии сервера, включающие как ветки 1.3.x, так и ветки 2.0.x b 2.2.x. , использование которой приводит к DoS сервера, вызванном переполнением памяти сервера, с уходом в бесконечный своппинг. Самое веселое во всем этом, что в инете уже имеется готовый эксплоит этой уязвимости, носящий название killapache.pl, который запуская в 40-50 потоков простой запрос:
HEAD / HTTP/1.1
Host: www.example.com
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,<…>,5-1299,5-1300
Accept-Encoding: gzip
Connection: close

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

Сразу надо отметить, что данной уязвимости не подвержены сервера на которых php собран без поддержки gzip. Также по идее можно выставить лимиты на использование памяти, и подключений с одного IP адреса. Тем не менее, даже не смотря на это, по заверениям спецов Apache, по интернету последние несколько дней прокатилась волна DoS атак на сервера под управлением Apache. Для Apache 2.2.x в самое ближайшее время обещают выпустить патч, устраняющий данную уязвимость, а вот пользователям 1.3.х придется довольствоваться закрытием данной уязвимости на своих серверах, посредством некоторого количества уловок, так как ветка 1.3.х уже не поддерживается.

Закрывается данная уязвимость с помощью:
1. блокировки длинных последовательностей Range через mod_rewrite (для обеих веток):
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* – [F]
2. с помощью mod_header, выставлением RequestHeader unset Range
3. с помощью SetEnvIf для Apache 2.Х:
# Удаляем заголовок Range, если в нем более 5 диапазонов
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# помещаем в лог попытки атаки
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
4. использования лимита для максимального размера поля LimitRequestFieldSize 200, где 200 – размер параметров в байтах
5. также данная уязвимость может быть локализована за счет использования проксирования сервером ngix, путем запреты проксирования опасных заголовков:
proxy_set_header Range “”;

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

LF анонимный прокси сервер под SEO-софт

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

SOCKS сервера я откинул сразу, ибо при всей многофункциональности, они в плане работоспособности и быстродействия, значительно уступают HTTP прокси серверам. Для начала я воспользовался имевшимся у меня в наличии сборщиком прокси серверов, и напарсил себе с инета базу в районе 10к проксей. После этого, прогнав через пару чекалок, оставил около полутора штук, но после проверки на анонимность, выяснилось, что использовать можно от силы штук 300. На самом деле, относительно анонимности, я проверял только на счет полной перезаписи пакета, ведь не секрет что прокси сервер, в зависимости от своего типа, либо дописывает к заголовку свою инфу, и тогда отправитель выпаливается, словно он работает без прокси; или же заголовок сетевого пакета переписывается полностью, и тогда для целевого хоста, отправителем будет являться прокси сервер. Но помимо этого, если уж мы говорим про анонимность в интернете, то также надо интересоваться логированием на прокси сервере, ибо через него проходит много различной инфы. Собственно то, что называется элитные прокси, как раз и является сервером полной анонимности- с полной перезаписью пакета, по так называемому level 1 проксирования.

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

С ними, по сути, получилась такая же тема, как и со спарсенными проксями, то есть как тока прокси сервер появлялся в списке, с ним некоторое время возможно было работать, после чего на него, по видимому, приходила вся толпа юзверей, в результате чего прокси либо начинал дико тормозить, либо уходил в бан. И так же как и со спарсенными списками, больше времени уходило на поддержку актуальных и работающих списков, чем на работу с ними. Так что вариант оставался только один – купить прокси сервер. Но поскольку покупка анонимного прокси сервера вещь муторная, то пришлось порыться в инете, пока я не нашел обьяву на одном из вебмастерских форумов, в которой предлагали купить пачками анонимный прокси сервер в США и Европе. Списавшись с ТС, я довольно быстро прикупил пару проксей на тест. Со слов продавца- это безлимитные прокси сервера, на которых живет максимум 3 человека. Потестив, я получил со стримовской сетки время отклика: от европейских прокси порядка 230ms, а от прокси в Америке порядка 340ms.

Приколол конечно ответ продавца, когда я двинул тему на счет того, что будет, если я например решу использовать данные прокси для брута (чисто гипотетически) на что получил ответ, что в принципе продавцу по большому счету все равно в каких целях я планирую использовать купленные прокси сервера, но он надеется на мою добропорядочность. Так что в итоге я прикупил пачку из 10 прокси серверов из Америки и Европы, всего за 20$, которые и пользую в данный момент. Скорость действительно прилично возросла, так что позволяет теперь одновременно парсить поисковые системы, чекать результаты постинга и одновременно постить из двух копий. Единственный момент, что прокси серверы эпизодически попадают в бан у поисковых систем, но он спадает где то в течении получаса. Однако все таки, уже подумываю о том чтобы еще купить прокси серверов хотя бы штук 10, тем более что и хрумак все таки надо брать в ближайшее время.

Ну и поскольку продавец проксей обещал выдать в следующий раз небольшую скидку  на покупку анонимных прокси в Америке, то даю линк по которому  можно купить прокси сервер в США и Европе.

Рубрика: IT безопасность, Интернет | Отзывов: 4 »

Повышаем безопасность веб-сервера с помощью cPanel

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

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

(more…)

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

Оптимизация работы ipf и ipnat

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

После внесения изменений в правила фаервола, данные правила можно применить без перезагрузки фаервола, просто перечитав файл правил, причем это может быть как дефолтовый файл, так и рандомный:
# ipf -Fa -f /etc/ipf.rules
где,
-Fa сброс всех правил фаервола.
-f указывает фаайлец с новыми правилами фаервола (так что не ошибитесь, ибо как вы помните фаервол мы собираели с блоком по умолчанию)

так же можно перечитать и правила ipnat, используя команду
# ipnat -CF -f /etc/ipnat.rules

Полную статистику работы фаервола с момента загрузки системы  можно просмотреть командой
# ipfstat
При этом ключ -ih выдаст количество входящих пакетов, со статистикой прохождения или блокировок с попаданием в правила,
ключ -oh выдаст туже статистику для исходящих пакетов. Это отличное подспорье в оптимизации работы фаервола, путем помещения наиболее часто используемых правил фаервола наверх таблицы.
Обнулить эту статистику можно командой
# ipf -Z
Просмотреть проходящие пакеты в режиме реального времени, можно командой
# ipmon
собственно её вывод и пишется в логфайл.

При использовании ключа  -n адреса и порты будут преобразованы в хостнеймы и сервисы, что довольно удобно для мониторинга того- кто где сидит в данный момент,
а при использовании ключа -x данные проводящих пакетов будут выводиться в hex-коде, что тоже может доставить много интересных минут сисадмину.
Используя команду ipnat можно просматривать таблицу состояния адрес трансляций:
# ipnat -l выведет все открытые на данный момент трансляции адресов
# ipnat -s выводит статистику работы адрес трансляции
# ipnat -F обнуляет все активные соединения из актуальной таблицы адрес трансляций

У ipnat есть, по умолчанию вшитое, количество возможных открытых сессий, и проверить его можно командой:
# ipf -T list | grep nattable
и вероятнее всего вы получите ответ что максимальное число открытых сессий 30к, что для большой сети не так уж и много, так что увеличить это число можно добавив в файл rc.conf следующую строчку:
ipfilter_flags=”-D -T ipf_nattable_sz=10009,ipf_nattable_max=200000 -E”
и перегрузив ipfilter, тем самым увеличив число сессий до 200к.
Также если ваш ipnat.rules предполагает более 127 правил, которые установлены по умолчанию, вам необходимо  также добавить в переменную ipfilter_flags файла rc.conf ключики ipf_natrules_sz=1023,ipf_rdrrules_sz=1023
Еще один момент касаемый уменьшения таймаута TCP сессии, что также позволит оптимизировать работу NAT, так как многие сессии сохраняются в таблице не смотря на то что соединение уже давно закончилось. Для этого добавляем во флаги, также ключи fr_tcptimeout=180,fr_tcpclosewait=60,\
fr_tcphalfclosed=7200,fr_tcpidletimeout=172800
В итоге на выходе в rc.conf имеем следующее выражение:
ipfilter_flags=”-D -T ipf_nattable_sz=10009,ipf_nattable_max=200000,fr_tcptimeout=180,\
fr_tcpclosewait=60,fr_tcphalfclosed=7200,fr_tcpidletimeout=172800,\
ipf_natrules_sz=1023,ipf_rdrrules_sz=1023 -E”

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

Настройка программного фаервола на базе FreeBSD

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

Переведем данное мероприятие сразу же в плоскость экономической выгоды для сисадмина, ибо на мой взгляд, настройка программного брандмауэра находится на втором месте, после лечения компьютера от вирусов, и перед восстановлением данных- по соотношению заработанных средств к затраченному времени. Поскольку на настройку программного фаервола на базе FreeBSD тратится от 6 до 10 часов, с момента как вы включили пустую машину, до момента когда вы можете уже включать данный сервер в разрез сети. Естественно, что поднять сам фаервол займет от силы полтора-два часа на создание и обкатку правил: большую часть времени занимает пересборка и апгрейд системы.

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

Итак- настраиваем программный фаервол на базе FreeBSD.

(more…)

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

Pirate Pay – профанация или очередной развод

В инете нашел инфу о неких пермских парнях разработавших какую то фантастическую, судя по радостным всхлипам журналистов, панацею, которая поставит жирный крест на пиратском распространении всяких материалов, защищенных авторскими правами, через пиринговые сети по протоколу BitTorrent. Именуется эта гроза пиратов Pirate Pay.
Ну понятно, что журналисты пишут про адовые технологии, которые не раскрываются, тоже самое написано и на офф. сайте приблуды, так что пришлось несколько погуглить на предмет инфы, так что в конце концов набрел на интервью Дмитрия Шуваева- директора по развитию грозного проекта Pirate Pay, из которого следует что данная приблудина ставится в сеть провайдера и контролирует bittorrent-трафик на предмет соответствия  запрашиваемого контента с базой данных запрещенного, который составляется на основе обращений правообладателей. В случае если контент запрещен к распространению, то пользователь не получает отклика от трекера с актуальным списком пиров. Причем правообладатель своими силами изыскивает материалы, нарушающие его права и доступные для скачивания через сети BitTorrent.

Более того, компании уже выделили грант от мелкомягких в районе 100к зелени, и на момент интервью чуваки искали лобби в госдуме, для того чтобы обязать всех провайдеров устанавливать в своих сетях их чудо кирогазы Pirate Pay. Но по новым публикациям они обязуются порвать всех к 1 сентября, так что надо полагать что лобби они себе нашли и видимо за не плохой процентик, ибо опубликованные цены радуют: от 30к до 300к в неделю за противодействие, либо же порядка 15% от доли прибыли. С другой стороны может и не так, так как в новых публикациях говорится о том, что они собираются работать на основе DHT спама, то есть обмена хэш-кодами между клиентами для нахождения пиров минуя трекер. То есть их продукт Pirate Pay создает шторм объяв по DHT среди которых теряются родные пиры.

(more…)

Рубрика: IT безопасность, Интернет | Отзывов: 9 »