Блог о технологиях, технократии и методиках борьбы с граблями
Благодаря айфоне пришлось в очередной раз повозиться со временем на одном стареньком почтаре, так как он по каким то причинам выставив актуальное время, стал выдавать в почте юзверей время на час позже, но поскольку переставить время на другое было бы не кошерно, то решил пойти классическим методом через правку timezone.
Натолкнулся на забавный глюк работы ifconfig во FreeBSD. Был себе сервачок на котором стоял шлюз и через NAT шел проброс сетки в DMZ. В этой связи на внешнем интерфейсе были подняты алиасы, грузившиеся через /etc/rc.conf
ifconfig_em1=”inet IP1 netmask 255.255.255.248 media 100baseTX mediaopt full-duplex”
ifconfig_em1_alias1=”inet IP2 netmask 255.255.255.248″
ifconfig_em1_alias2=”inet IP3 netmask 255.255.255.248″
Собственно, алиасы позволяют назначить на один интерфейс несколько IP адресов, что позволяет творить всякие интересные штуки как на внешнем интернет-интерфейсе, так и разделять локалку на подсети на внутреннем.
Возникла необходимость поставить ftp сервер, так что в этой связи появился стимул наконец то разродиться статьей по настройке ftp сервера. Для этого я буду использовать сервер ProFTPD, позволяющий хранить аккаунты пользователей в базе данных, а также дающий возможность использования различных удобных фич как в безопасности, так и для подключения дополнительных модулей.
Хранение пользователей в базе данных крайне удобно, так как позволяет использовать ftp не заводя в системе штатные аккаунты, пусть и с ограниченными правами (по этой же причине мне нравится связка dbmail + mysql). Также эти базы можно удобно резервировать, тем более что все пути и чируты прописываются именно в них. Также при желании можно подключить проверку загружаемых файлов через clamav путем патча пакета pfoFTPD, но думаю что это отнесу к какой нить другой статье.
Иногда приключается ситуация, что надо поднять сервак и передать его в руки чужих умельцев, а вы на нем например тестили закрытие трафа в сопряженные сетки, или не хотите палить процедуру настройки сервера.
Для этого надо обнулить историю шелла, или по крайней мере выкинуть из нее какие то фрагменты. Делается это крайне просто, ибо она хранится в файле .bash_history, который находится в домашней директории пользователя, и в случае всяких настроек- root. Естественно что там она хранится в случае использования bash, а не /sbin/nologin
Так что вариантов два, либо обнулить этот файл
# cat /dev/null > ~/.bash_history
либо открыть его на редактирование и постирать ненужные строки ручками.
В обоих случаях надо будет перелогиниться, чтобы shell очистился, так как данные из него подгружаются при загрузке профайла.
Сегодня пришлось поехать к клиенту как раз по поводу многострадального шарика с видяхами, и пока суть да дело- нарисовался планчик для локального 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 протоколы.
После чего все это дело настраиваем и радуемся жизни.
Столкнулся с древним косяком работы 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
Думаю что не надо лишний раз лить воду на жернов копирайта пустословия, относительно того что для жизни сетей и Интернета в частности, сервера доменных имен являются краеугольной тематикой. Ибо без их существования все доменные имена, типо мойкрутойдомен.ком были бы пустыми словами. И для того, чтобы выходить из любой сети в интернет, нам необходимо использовать DNS сервер для разрешения доменных имен в IP адреса. Но в данном случае нам хватит, так называемого кеширующего сервера имен, то есть отвечающего только за разрешение имен и не содержащего описаний доменных зон.
С помощью стандартного сервера доменных имен BIND, настроить такой сервер, на базе любой *nix системы, можно за считанные минуты, но при этом необходимо выполнить некоторое количество телодвижений, которые я и перечислю ниже.
