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

Tuesday, 11 Oct 2011

Столкнулся с древним косяком работы 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

VN:F [1.9.13_1145]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

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

Sunday, 02 Oct 2011

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

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

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

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

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

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

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

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

VN:F [1.9.13_1145]
Rating: 10.0/10 (2 votes cast)
VN:F [1.9.13_1145]
Rating: +1 (from 1 vote)

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

Tuesday, 27 Sep 2011

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

(more…)

VN:F [1.9.13_1145]
Rating: 8.3/10 (3 votes cast)
VN:F [1.9.13_1145]
Rating: +3 (from 3 votes)

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

Wednesday, 03 Aug 2011

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

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

Полную статистику работы фаервола с момента загрузки системы  можно просмотреть командой
# 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”

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

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

Tuesday, 02 Aug 2011

настройка фаервола

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

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

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

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

(more…)

VN:F [1.9.13_1145]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.13_1145]
Rating: +1 (from 1 vote)

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

Friday, 10 Jun 2011

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

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

(more…)

VN:F [1.9.13_1145]
Rating: 10.0/10 (2 votes cast)
VN:F [1.9.13_1145]
Rating: +1 (from 1 vote)

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

Friday, 10 Jun 2011

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

Для начала понимаем что это вообще за класс операционки, путем вывода универсальной для всех 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

VN:F [1.9.13_1145]
Rating: 9.8/10 (4 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)