Рубрика «FreeBSD»

Установка ftp-сервера с хранением пользователей в БД

Thursday, 05 Jul 2012

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

Хранение пользователей в базе данных крайне удобно, так как позволяет использовать ftp не заводя в системе штатные аккаунты, пусть и с ограниченными правами (по этой же причине мне нравится связка dbmail + mysql). Также эти базы можно удобно резервировать, тем более что все пути и чируты прописываются именно в них. Также при желании можно подключить проверку загружаемых файлов через clamav путем патча пакета pfoFTPD, но думаю что это отнесу к какой нить другой статье.

(more…)

VN:F [1.9.21_1169]
Rating: 5.5/10 (2 votes cast)
VN:F [1.9.21_1169]
Rating: -1 (from 1 vote)

Удаляем историю командной строки shell

Friday, 08 Jun 2012

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

Для этого надо обнулить историю шелла, или по крайней мере выкинуть из нее какие то фрагменты. Делается это крайне просто, ибо она хранится в файле .bash_history, который находится в домашней директории пользователя, и в случае всяких настроек- root. Естественно что там она хранится в случае использования bash, а не /sbin/nologin

Так что вариантов два, либо обнулить этот файл
# cat /dev/null > ~/.bash_history

либо открыть его на редактирование и постирать ненужные строки ручками.

В обоих случаях надо будет перелогиниться, чтобы shell очистился, так как данные из него подгружаются при загрузке профайла.

VN:F [1.9.21_1169]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)

FTP для маленькой такой компании

Friday, 11 Nov 2011

Сегодня пришлось поехать к клиенту как раз по поводу многострадального шарика с видяхами, и пока суть да дело- нарисовался планчик для локального ftp-сервера, который необходимо поставить в конторе. Рисовать не охота, да и Visio я себе так и не поставил, поэтому опишу на пальцах куда рыть.

Собственно принципиальная схема работы следующая: FTP-сервер работающий под ProFTPd с хранением учеток в базе MySQL. К нему есессно подрублен контроль файлов и clamav. Сам сервак находится в DMZ за фаерволом, где на него подключены собственно порты 20, 21 и все выше 1024, для отработки пассива. Также ставим apache и открываем 80 порт на фаерволе, так как некоторым тупым бургам понадобится скачивать из локалок, а по своему опыту работы я неоднократно сталкивался с ситуацией когда у таких “васяток” банально нет чела который им мог бы объяснить как переключить ftp-клиента в пассивный режим, а факи которые им шлешь на почту, почему то не вспомогают. Вот для таких граждан необходимо также иметь web-сервер на котором завести некоторое количество папочек, запароленных на основе .htaccess.

Остальные пакеты это samba сервер, через который внутренние клиенты раскидывают файлы по папкам, с аутентификацией на уровне пользователей. Тут собственно можно сделать два варианта: либо разрешить прохождение smb пакетов из сетки через фаервол, либо засунуть сервак вторым интерфейсом в локалку, но это не особо хорошая идея, ибо хотя шансов что нам сломают ftp крайне мало, но все равно это получается лишний вход. В принципе можно его вывести вторым шнутом во внутренний DMZ, куда уже фильтровать пакетики от внутренних сетей. Такой ход более гиморный, но зато и наиболее спокойный.

Каждому юзверю, или отделу создается папка- желательно конечно с квотированием, иначе ftp-сервер превращается в неконтролируемую файлопойку похуже файл-сервера. В этой связи есть смысл подрубить еженедельную отправку на почту статистики вывода:
df -ah
du -ch -d 1 /ftphome

Теперь по защите всего это хозяйства, как я и сказал: на фаерволе делаем маппинг по портам, или же безусловную трансляцию, закрывая все порты ниже 1024 порта, кроме 20, 21 и 80 вовне, а внутрь от сервера пропускаем все или же только smb протоколы.

После чего все это дело настраиваем и радуемся жизни.

VN:F [1.9.21_1169]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)

Баг прохождения пакетов 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.21_1169]
Rating: 10.0/10 (2 votes cast)
VN:F [1.9.21_1169]
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.21_1169]
Rating: 8.8/10 (4 votes cast)
VN:F [1.9.21_1169]
Rating: +4 (from 4 votes)

Настройка кеширующего DNS сервера на базе BIND

Friday, 19 Aug 2011

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

С помощью стандартного сервера доменных имен BIND, настроить такой сервер, на базе любой *nix системы, можно за считанные минуты, но при этом необходимо выполнить некоторое количество телодвижений, которые я и перечислю ниже.

(more…)

VN:F [1.9.21_1169]
Rating: 10.0/10 (4 votes cast)
VN:F [1.9.21_1169]
Rating: +3 (from 3 votes)

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

Wednesday, 03 Aug 2011

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

VN:F [1.9.21_1169]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)