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

Баг прохождения пакетов keep state через фаервол IPF

Столкнулся с древним косяком работы Ipfilter, который был замечен в версии FreeBSD 6.1/6.2, но у меня вылез на 8.2. Причем совершенно не понятным образом, так как фаервол у людей работал уже порядка полугода, и тут отвалился VoIP. То есть в один прекрасный день, как водится в понедельник, перестали коннектится телефоны к удаленному VoIP серверу. Сначала думал что траблы в телефоне, но потом оказалось что не работают все.

Стал ковыряться и обнаружил в логах ipmon интересные записи:
Date em1 @0:38 b LAN_IP,port -> VoIP_server,port PR tcp len 20 60 -S OUT OOW
Date em1 @0:58 b VoIP_server,port -> LAN_IP,port  PR tcp len 20 81 -AP IN OOW NAT
Date em1 @0:58 b VoIP_server,port -> GW_LAN_IP,port  PR tcp len 20 81 -AP IN OOW NAT

Собственно самое интересно в этом флаг OOW, который переводится как out of window, и является багом фильтарции пакетов для которых правило идет со статусом keep state, то есть в момент установленного уже соединения, которое фаервол должен пропускать, он вдруг решает, что это неожиданный пакет и банит его именно по причине OOW. В моем случае- все эти прохождения пакетов были разрешены, и все блокировки были именно по флагу OOW.
Бороться с этим можно двумя способами: либо пропатчив фаервол, либо исключая из правила флаг keep state. Я предпочел последний, тем более что у меня баг срабатывает только на VOIP трафик, тогда как остальной продолжает ходить с флагом keep state.

Самое унылое во всем этом, что судя по инетам данная проблема была пофиксена еще на версии 1.3b5, тогда как у меня в данный момент используется:
# ipf -V
ipf: IP Filter: v4.1.28 (400)
Kernel: IP Filter: v4.1.28
так что видимо с оказией надо будет подумать об обновлении на текущую версию 5.1.0

Кстати просмотреть пакеты дропающиеся по out of window можно с помощью команды:
# ipmon -oI
Тогда как увидеть список загруженных правил можно с помощью команды:
# ipfstat -nio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(more…)

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

Как определить версию Unix системы

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

Для начала понимаем что это вообще за класс операционки, путем вывода универсальной для всех Unix-систем команды:
$ uname -a
которая нам выведет что то типо такого:
Linux hostname.com 2.6.18-194.17.4.el5PAE #1 SMP Mon Oct 25 16:35:27 EDT 2010 i686 i686 i386 GNU/Linux
или
FreeBSD hostname.com 5.5-STABLE FreeBSD 5.5-STABLE #0: Wed Dec  5 20:00:38 MSK 2007  email@hostname.com:/usr/obj/usr/src/sys/GENERIC  i386
или
AIX svcas07 3 4 000145364C00
OS Name Release Version Machine ID
из чего нам либо станет понятно кто это, либо перейдем к более подробному изучению линуха, для того чтобы уже конкретно определить версию линукса:
$ cat /proc/version
Linux version 2.6.18-194.17.4.el5PAE (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Mon Oct 25 16:35:27 EDT 2010
то есть нам понятно семейство линуха и версия ядра, тем более что у семейства шапки есть более подробная команда, для того чтобы узнать версию linux:
$ cat /etc/redhat-release
CentOS release 5.6 (Final)
По хорошему это исчерпывающий ответ, но в шапке также имеется дополнительная утилита ставящаяся в полном комплекте, которая выведет более подробную информацию про версию linux:
$ lsb_release -a
LSB Version:    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description:    CentOS release 5.5 (Final)
Release:        5.5
Codename:       Final

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

Пространные рассуждения про VoIP трафик

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

Начну с того что я остановился сразу на платформе Asterisc, во первых потому что это наиболее популярный open-sourse, во-вторых потому что по данной платформе огромное количество полезной информации в интернете.
(more…)

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