Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
Записи с темой: freebsd (список заголовков)
09:45 

О граблях, вестимо.

"Третьего дня"(ТМ) решил я обновить систему на недавно вышедшую 8.1 - на виртуальной машинке все вроде как ОК, можно и на личном букваре поэксперементировать, ага. Правим sup-файл для дерева сырцов, обновляем дерево, make buildworld-kernel-installworld-kernel, НЕ ЗАБЫВАЕМ (Оттож!) обновить gptzfsboot в первой партиции, ребутимся... авотхрен!
error 1 lba 48
error 1 lba 1
No ZFS pools located, can't boot
Хм. Странно. Впрочем... в 8.1 ZFS 14 версии, а в 8-ке - 13, может по тому и не находит? Надо бы версию пула обновить, ага. А пока - установим старый gptzfsboot + копирнем скомпиленый с ZFS'ом loader от 8-ки. Работает. За десять минут до конца рабочего дня - zpool upgrade -a, gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad4, ребут.
error 1 lba 48
error 1 lba 1
No ZFS pools located, can't boot
Хм. По проторенной дорожке - старый лоадер... авотхрен! Версия should be 13, ага. Приплыли. Смотрим, куда именно. Google ничего сильно вразумительного не говорит (Большая часть камрадов тупо забыла проинсталлить gptzfsboot "куда надо", меньшая - ловит кайф с current-веткой и сообщает, что уж в RELEASE'е-то все ОК) - тындекс и спрашивать бесполезно, придется ручками.
ls /usr/src/sys/boot/i386/gptzfsboot - никаких сырцов, один Makefile, в котором прописана статическая линковка gptboot + zfsboot + btx + еще какая-то хрень. Ага. fgrep'ом смотрим, где именно сидят сообщения об ошибках - сидят они в zfsboot.c, вот только к этому самому .c прилагается еще и .S, написанный на ассемблере. Мать-мать-мать. Начинаем смотреть - main вызывает probe_drive(), probe_drive() вызывает drvread(), там инициализируются несколько регистров, вызывается "ассемблерная вставка" - и выдается сообщение об ошибке. Два разА, ага. Дело ясное, что дело темное.
Лезем на svn, начинаем читать комментарии - что и зачем джамшутили в этом самом zfsboot.c - создается впечатление, что проблема вызвана включением 64х битной LBA вместо старой 48-ми битной, но как с этим бороться... версия ДО этого самого включения без сильномогучего бубна не собирается, что и как "править ручками" - хрен знает... трабла, в общем.
Неразрешимая? А вот и нет ). "Совершенно случайно" у меня в букваре обнаружилась SD-карта на 1 гиг, с которой комп вроде как даже соглашается грузиться - форматим ее под UFS2, копируем туда /boot, gpart'ом же ставим MBR, меняем /etc/fstab, ребутимся, меняем boot sequence, ребутимся... и работаем.
А вот что делать с "боевыми" серверами в которых карт-ридеров с "совершенно ненужными" SD'шками нет - Б-г весть. Экспериментировать как-то того... желания нет.

@темы: Работа, FreeBSD

11:17 

Для себя...

... чтобы не забыть:

Чтобы смонтировать ISO-image во фрюхе надо не '-o loop' в mount воткнуть, как в этих ваших linux'ах, а:
Создать виртуальную девайсину с приаттаченным файлом:
mdconfig -a -t vnode -f /
А потом уже смонтировать получившийся девайс штатными средствами:
mount_cd9660 /dev/mdX /mnt
И, да - после не забыть задропать лишнее:
mdconfig -d -u <номер девайса>.

Для рулежки удаленным сервером с, например, koi8-r из X'ового терминала с той же UTF8 вовсе не обязательно перенастраивать кодировку - проще и удобней воспользоваться командой luit - например, так:
luit -encoding 'koi8-r' ssh -i / user@server.

Забавные грабли - два DC, один на 2003R2, другой на 2008 сервере, меняем в krb5.conf'е kdc с 2003 на 2008 сервак и по kinit'у получаем "kinit: krb5_get_init_creds: Response too big for UDP, retry with TCP" - сюрпрайз, сюрпрайз! Ну, TCP так TCP - пишем в krb5.conf'e kdc = tcp/DC и едем дальше, но все же странно усе это...

@темы: FreeBSD, Жизнь

16:15 

Пулеметное...

... продолжение. Сошелся с самим собой на варианте "хост-система + все нужное для работы (Разновсяческие nmap'ы, rsync'и, openvpn'ы, безгуевый virtualbox и прочая-разная шелупонь), голые X-ы - и, в общем-то, все. А всякие фурифоксы с опенопицами (Свят-свят-свят! Как подумаю - в дрожь бросает!) выкинуты в отдельные JAIL'ы в отдельной подсети, ко всему этому прикручены ipfw+nat - и, в общем-то, все. В хост-системе нет лишних пакетов, зависимостей, монструЁзных framework'ов, а на JAIL'ы мне по большому счету плевать - ZFS'ные snapshut'ы сняты, весь софт собирается в package'ы в отедльном JAIL'е - переставить все это "туда-обратно", случись желание дело ну... не пяти минут, но пары часов уж точно.
В процессе пришлось лечить кучу мелкого геморроя (Ну там в первый раз в жизни с xauth'ом столкнулся, для "консолидации" шрифтов пришлось xfontserver, по всем jail'ам ssh-ключи раскидывать ну и так далее) - но когда без того обходилось? Кооллеги, она, втроем qip 2010 побороть не могут ))
В общем и целом, система в рабочем состоянии и "концептуально" состояние это меня более чем вполне устраивает - осталось только утрясти некоторые "частности" - ну там какой WM прописать на ПМЖ, каким IM-клиентом пользоваться (Чегой-то Pidgin меня ну капитально "не вставляет" - без gstreamer'а он под фрюхой таперя не собирается - патч вроде бы есть, но в дерево портов еще не попал + под мою конфигу его ручками рихтовать пришлось; за ним тянется glib-20, который, опять же, не собирается как следует - в последней примерно, тысяче, строк кто-то пропустил "fi" ))) ну и прочая-разная), что со "смотрелками" делать (Монструозные Okular\Evince опять же...) - в общем, на пару недель возни еще хватит - а там еще чего-нибудь придумаю... :shuffle:

@темы: Жизнь, Вендекапец!, FreeBSD

16:33 

Как ни собирай систему...

... один хрен, пулемет получится. Т.е. или половина гнома, или половина KDE встанет обязательно. Вот скажите мне на милость, какого мужского полового органа в чистых иксах делает dbus, hal и прочая разная? Вот и я не знаю. Живет и все тут. xorg.conf править, видимо, не комильфо, даешь "все сразу и автоматом", ога. С конфигом в виде xml-файла. Повбывал бы только за это. Нет, оно, в принципе, выпиливается, но... сцуко, куда они freetype дели? Ах, в сами иксы вкомпилили? Ога, ога ма-лад-цы! Вот только с чего оно после этого работать перестало, а? Ах, fontconfig смотреть? С fonts.conf xml'ным же? Ну спа-аасиба, ребят. Обрадовали. Один хрен, не работает. А товаристча, который дефолтовое поведение Xorg'а на "черный экран" изменил я бы лично м-мммм... приголубил. Старая сетка с курсором, тапереча, с помощью -retro показывается, о чем, кстати, в манах ни полслова нет. Молодые якодзуны, видимо, по "черному экрану" понимают, что иксы настроены. А, да! Они же их не нестраивают, у них dbus есть!
То, что firefox на gtk+ написано - и хрен бы с ним, но скажите мне, каког (см. выше) для долбанного djvu-плагина нужен полный QT, а? Два, блин, гига! 150+ метров сырцов! Нет, оно кнечно крася-ааава нарисовано, собственный просмотрщик, все дела, но для _браузерного плагина_-то нахрена??? Не-по-ни-ма-ю. А в FBReader'е оно ЗАЧЕМ? Эт же ж блин, xml зипованный! Его смотреть - Python + TK - ну заглаза! Нееет, даешь свистоперделки тоннами!
Кондовый afterstep и тот, ёлкала-палкала для сборки полгнома вытянул. Ей-ктулху, проще этот самый гном поставить, чем без него обойтись. Один хрен, так или иначе а в системе это унылое гумно всплывет.

@темы: FreeBSD, Вендекапец!

16:21 

Итак, ZFS-root + GPT...

.... на FreeBSD 8.0 таки заработал, хоть и сильно не "from the box" :). В общем-то, все просто - сносим разметку с помощью gpart delete -i [geom] && gpart destroy [geom], создаем GPT-разметку gpart create -s GPT [geom]. Записываем PMBR в целях обратной совместимости (И не только - у меня, например, не EFI, а обычный BIOS) - gpart bootcode -b /путь-к-pmbr (/boot/pmbr в установленной системе, а так - куда положишь, там и будет). Создаем раздельчик для gptzfsboot - gpart add -s 64 -t freebsd-boot [geom] && gpart bootcode -p /путь-к-gptzfsboot (Там же). Создаем раздел для ZFS - gpart add -t freebsd-zfs -l [метка] [geom] (Создавать отдельный 4х гиговый swap для kernel dump'ов, имхо, жирно будет). На этом с GPT закончено.
Дальше - ZFS: Грузим модули ядра kldload /mnt2/boot/kernel/opensolaris.ko && kldload /mnt2/boot/kernel/zfs.ko (/mnt2 -это по тому, что я с fixit'а все это делаю, а так - куда захочешь, туда и клади, а вот порядок загрузки - важен. zfs.ko без opensolaris'a не грузится с ну оооочень "понятным" объяснением "Exec fromat error"). mkdir /boot/zfs (Чтобы потом export-import'ом кэш не создавать) && zpool create [как вы яхту назовете] /dev/gpt/метка (Использование label'ов, имхо, очень, очень и очень хорошая привычка - а то создал бы я zpool на ad4, а ядро у меня - сюрприз, сюрприз! БЕЗ ATA_STATIC_NUMBERING'а - и что?) && zpool set bootfs=[имя] [имя]. zfs create /(usr|home|var|что-душа-просит) - и можно ставить систему (Вот тут-то я и облажался по полной - систему поставил с дистрибутивного диска (install.sh по каталогам из /dist/8.0-RELEASE), а сорцы воткнул обновленные, с бэкапа - дети, НЕ ДЕЛАЙТЕ так!). Закидываем в loader.conf новоустановленной системы zfs_enable="YES" vfs.root.mountfrom="zfs:[имя пула]", а в rc.conf - zfs_enable="YES". chroot'имся в пул, задаем пароль для root'а и собираем загрузчик с поддержкой zfs. ТеореХтически это можно сделать там же - echo 'LOADER_ZFS_SUPPORT=YES' > /etc/make.conf && export DESTDIR=""; cd /usr/src/sys/boot && make obj && make depend && make && cd ./i386/loader && make install, но на практике загрузчик у меня не собрался от слова "совсем". Есть ощущение, что из-за обновленных сырцов (make tools, ага ), но может и что другое постаралось. Рабочей системы под рукой не нашлось, так что пришлось сносить все вышесделанное и ставить freebsd в минимальной конфигурации. (Тут я сделал вторую ошибку - решил, что достаточно будет сделать make buid|install kernel и скопировать /boot в куда надо. Авотфиг! В результате "все сносить" пришлось еще раз ). Но - долго ли, коротко, а загрузчик я собрал.
Осталось всего-ничего: воткнуть забытый swap ;) и прописать mountpoint'ы:
zfs create -V [сколько надо] [пул]/[имя] && zfs set org.freebsd:swap=on [пул]/[фс] && zfs set checksum=off [пул]/[фс]
zfs set mountpoint=legacy [пул]
zfs set mountpoint [пул]/[имя] - для всех созданных FS.
Ну и, в общем-то, все. Ребутимся, неспеша пишем fstab (TMPFS для /tmp, NULLFS для jail'ов, флешки-сд-карты и пр), копируем нужное из бэкапа - в общем, работаем!

@темы: FreeBSD, Вендекапец!, Жизнь

17:13 

Наступил на целую кучу грабель...

... с ZFS boot'ом (Кто бы мог подумать, что порядок загрузки модулей opensolaris.ko и zfs.ko играет роль, а? При том, что в "loader prompt'е" zfs.ko вполне себе грузился...). Добила меня необходимость собирать loader из chroot'а (Ну, да, ну да - вумные прошареные люди сделали это СИЛЬНО до, честь им и хвала), одно радует - скилл растет.

@темы: FreeBSD, Вендекапец!, Жизнь, Работа

15:48 

И еще одни шикарные...

... грабли. Дано: samba в роли PDC. Трэба - закинуть на этот сервер всякое-разное в количестве. Ясен пень, хочется "разложить" все это не абы как, а по разным jail'ам, ибо. Вот только - сюрприз-сюрпри-иииз! Сволочной nmbd привязывается к *.137/8 и штатного способа изменить это поведение у нас нет (Параметры "interffaces", "bind interfaces only" и "socket address" на nmbd не влияют, о чем в man'е и сказано).
Ок, сделаем, как умные люди говорят - перекинем "проблемный" сервис в jail, и пущай там привязывается к чему ему угодно, хе-хе! Сказано - сделано, но, увы! Кто бы мог подумать? )))) Вышеописанное поведение злобного демона, оказывается, имеет под собой Глубокий Смысл - запущенная таким образом samba на отрез отказывается получать broadcast'ы (Что, собственно, в высшей степени логично - хрен тебе, а не доступ к "сырому" интерфейсу изнутри jail'а!). "Штатного" способа собрать samba'у с поддержкой jail'а в портах не обнаружилось.
Тупик? Авотхрен! Запихиваем в соседний jail связку DNS+DHCP (Вроде как даже описывал когда-то), кидаем в smb.conf "wins support = yes" и "dns proxy = yes", пишем в resolv.conf'е адрес соседнего jail'а и раздаем через тот же DHCP samba'у в качестве еще и WINS сервера. Работает!
Для пущего счастья еще бы и службу "computer browser" на всех клиентах посносить, ибо нефиг где попало broadcast'ами мусорить, но, в общем-то, и так сойдет, наверное.

@темы: FreeBSD, Работа

15:12 

Мелочь...

... а приятно! Вместо стандартного ntpd (С документацией на 9, кажется, страницах) можно использовать OpenBSD'шный OpenNTPD, в котором всего-то требуется указать слушаемый интерфейс и адреса ntp-серверов для синхронизации. И он РАБОТАЕТ!

@темы: FreeBSD

16:04 

Новый экспириенс...

... установка FreeBSD на IBM'овский сервер.
Со SCSI-винтами, числом 2 шт по 8Gb каждый.
128 метров памяти.
P3-500.
В серверной типа "кладовка" (+40 "в тени", ага).
Без стула.
При помощи клавиатуры _без английской раскладки_.
За жестко ограниченное время.

Ничего так, работает. Интернет интернетит, нат натит, ДНС-днсит ). Ядро, правда, все еще пересобирается - ну-да мы не поспешаем, да.
Правда идея взгромоздить на ЭТО еще и почтовый сервер м-ммм... не кажется мне вполне удачной, но где наша не пропадала?

@темы: FreeBSD, Работа

16:17 

Очередная задачка:

Есть Cron. Есть пара "однострочных" задач. Есть IMAP-сервер с настроенными фильтрами (Все сообщения с такой-то темой слать ТУДЫ!). Казалось бы, все хорошо - но как задать Subject: в письме от Cron'а? В конфигах ничего подобного нет. В man'ах, что удивительно, тоже ).
Можно, конечно, подправить IMAP'ный фильтр, но - мы легких путей не ищем! Лезем в man'ы. Думаем. Отключаем отправку писем Cron'ом при помощи установки переменной MAILTO="". Закидываем в конец выполняемой Cron'ом команды конвейер | mail -s ''... и обламываемся, ибо в качестве системы отсылки почты используется не родной sendmail, а самоустановленный ssmtp, который, судя по тем же man'ам знать не знает ни о каких Subject'ах!
Иппон-матрен. Вместо одной строчки в Cron'е пришлось рожать цельный скриптЪ, собирающий искомое письмо из шаблона заголовка и stdout'а собственно программы с удалением получившегося темпака.
Чиооорт, как бы научиться выбирать _самый простой_ путь решения проблемы, а?!!!

@темы: Работа, FreeBSD

16:16 

Матерное, рабочее.

16:02 

... делу венец?

Определившись со списком доступных служб хакер переходит к следующему, последнему перед собственно "атакой" этапу - попытке определения версий ОС и установленного ПО.
С версией конкретных программ все может быть как очень просто так и очень сложно - большинство сетевых служб при установлении соединения выдают т.н. информационный баннер с указанием поддерживаемых возможностей, номера версии (Хорошо если только самой программы, а то ведь и ОС спалить могут )) - этого, собственно, достаточно.
Что с этим можно сделать? Прежде всего, посмотреть настройки службы, очень может быть, что там есть что-либо, определяющее формат "приветствия" (VersionAddendum в SSH, Version в named.conf BIND'а и пр.), иногда этого достаточно - чаще нет. Бывает, что информация о версии жестко зашивается при компиляции программы, стоит ли затевать возню с пересборкой - решать вам.
Дополнительно можно соорудить "хитрую ловушку для слонопотамов" - открыть на файрволле несколько портов, принадлежащих каким-нибудь заведомо небезопасным службам и подвесить на них "Банник"(ТМ). Соорудить оный можно самостоятельно при помощи, например, inetd+TCPWrappers+IPFW, или воспользоваться уже готовым - например, portsentry из ./ports/security. Кстати, готовые "сторожки" вполне могут помочь и в случае -sS сканирования (См. выше), но злоупотреблять ими не стоит (Ибо какие-то ресурсы они все-таки жрут сами по себе, да и организовать с их помощью DOS-атаку вполне реально.), и полностью полагаться на них нельзя (Возможностей по смене IP даже у "среднезавалящего" хакера более, чем достаточно).
Определение версии ОС - штука куда более интересная. Обратимся, опять же к документации nmap нам доступны следующие методы:
- TCP Sequence generation (SEQ, OPS, WIN, and T1)
- ICMP echo
- TCP explicit congestion notification (ECN)
- TCP tests (T2–T7)
Проще всего опять же с ICMP echo - он у нас уже забанен ;).
С Т2-Т7 все тоже не слишком сложно: 3,5,6,7 тесты требуют доступных закрытых портов, которых у нас, опять же, уже нет, 2й - повторяет уже "зарубленное" TCP NULL-сканирование, 4ый надежно отсекается statefull правилами.
Остаются Sequence generation и ECN. В 8ке вроде как имеется sysctl, ответственный за это самое "congestion notification", но скажу честно - не проверял.
T1 - пожалуй самая большая проблема. Опять же, "рубить" SYN-пакеты мы не имеем права, ничего "особо криминального" они не содержат, а методов "анализа последовательности" у ipfw нет. Тупик? М-мммм... не вполне. Помешать проведению теста мы, может и не сможем, но "спутать" его результаты - вполне. Для этого устанавливаем net.inet.ip.random_id в единицу и наблюдаем результаты (Мою 7_3 nmap радостно определил как то ли OpenBSD, то ли Free в диапазоне с 6й по 8ю) - не идеально, но приемлемо.

@темы: FreeBSD

16:38 

Продолжим, помолясь

После обнаружения в анализируемой сети активных хостов атакующий переходит к следующему этапу - попытке определить список доступных сетевых служб на целевой машине. Для этого используется т.н. технология "сканирования портов".
Наиболее распространены следующие типы сканирования:
- сканирование "полусоединением", оно же stealth, tcp syn и пр.
- сканирование с нестандартной установкой tcp-флагов
- UDP-сканирование
Для решения специфических задач (Определение правил брандмауэра, обход брандмауэра, сканирование нестандартных систем и пр) могут так же использоваться TCP ACK сканирование, сканирование Мэймона и TCP-window сканирование.
Проще всего справиться со сканированием с нестандартной установкой флагов:
ipfw add deny all from any to any tcpflags syn,fin,ack,psh,urg,rst - NULL-scan
ipfw add deny all from any to any tcpflags !syn,!fin,!ack,!psh,!urg,!rst XMAS-scan
ipfw add deny all from any to any not established tcpflags fin FIN-сканирование.
UDP-сканирование само по себе штука не простая - открытые порты почти всегда (Зависит от службы) не отвечают на запрос, фильтруемые порты не отвечают тем более, а закрытых портов при правильно настроенном файрволле у нас просто нет ).
Увы, самый простой, самый быстрый и самый надежный способ (Используемый nmap'ом по умолчанию) заблокировать практически невозможно: syn-пакет является частью легитимного процесса установления соединения. В процессе подобного сканирования _можно_ обнаружить две аномалии - резкое увеличение пакетов с rst-флагом приходящих с одного адреса и большое количество попыток установления соединения. Теоретически, это можно использовать для попытки обнаружения сканирования, но на практике все не так просто. Используя ipfw можно попытаться ограничить число одновременных попыток соединения, но поможет это мало - даже последовательный перебор всех 65535 портов занимает порядка 20 секунд, пытаться "ускорить" этот процесс - нет особого смысла. Попытка обнаружить аномальное увеличение RST-пакетов с помощью IDS так же не приведет к успеху, т.к. установление соединений с закрытыми портами будет заблокировано межсетевым экраном и собственно увеличения - не произойдет.
Таким образом, можно с уверенностью сказать, что атакующий _получит_ список запущенных на целевой машине сетевых служб, и с этим мало что можно сделать.

@темы: FreeBSD, Работа

16:37 

Продолжаем firewall'льную...

... тему или немного о, собственно, безопасности.
Первое, что делает хакер перед атакой - определяет цель. В сети 4 294 967 296 IPv4 адресов (Плюс-минус лапоть в виде зарезервированных для спец. использования подсетей) и понять, какой из них тебе нужен не так-то просто. В случае, если система оказывает какие-либо услуги внешним клиентам (Web-сервер, SMTP-сервер и пр) "прятаться" в общем-то, не имеет смысла и этот пост можно смело пропустить, а вот если речь идет, например, о корпоративном шлюзе скрыть сам факт его существования - не самая плохая идея.
Каким образом это можно сделать? Открываем раздел документации NMAP, посвященный процессу обнаружения хостов и смотрим, каким образом это самое "обнаружение" может производиться:
- при помощи ICMP-запросов различного типа (-sP -PE -PP -PM)
- при помощи посылки tcp-пакетов с установленными флагами SYN/ACK на некоторые порты
- при помощи посылки udp-пакетов на некоторые порты
- пингование с помощью ARP
- пингование с помощью IP-протокола
По первому пункту все ясно - тупо дропаем icmptypes 8,14,18 (Ай-яй-яй! Нарушаем rfc 1122/792, ну да Кришна с ним.) и не беспокоимся. Вообще, про ICMP еще будет, причем достаточно много.
Второй пункт несколько сложнее - мы _в принципе_ не можем блокировать пакеты с установленным SYN'ом, но - мы можем закрыть наиболее часто употребляющиеся при сканировании порты (-PS22,25,80 -PA21,23,80,3389 - что-то вроде), перенеся соответствующие службы куда-нибудь подальше. Про 25/80 я уже говорил - прятать их обычно нет никакого смысла, 23 - малоактуален, 21 - уже гадательно, 3389 на *nix-машине маловероятен, а вот 22-ssh закинуть куда-нибудь "повыше" (При помощи директивы listenaddress addr:port в sshd_config) - самое оно.
С UDP для атакующего тоже все не просто - явный "отклик" дают только "закрытые" порты, которых в случае правильно настроенного firewall'а у нас просто не должно быть.
ARP-сканирование по большому счету имеет смысл только в локальной сети и защищаться от него долго и уныло в общем-то нет необходимости
А вот с -PO и впрямь могут возникнуть проблемы, хотя задропаный исходящий icmptypes 3 частично помогает, плюс кое-что (IPv6, SCTP и пр.) можно "выпилить" при компиляции ядра.

@темы: FreeBSD

16:36 

Ну и еще немного о...

... firewall'ах (На примере IPFW) - вдруг кому интересно? ))

Основные требования к правилам межсетевого экрана - читаемость и производительность. Если первое более-менее понятно (Кому не понятно - откройте дефолтовый rc.firewall FreeBSD и никогда, никогда, НИКОГДА не повторяйте то, что там увидите!), то со вторым надо разобраться чуть по-подробней.
От чего зависит производительность firewall'а? От количества операций сравнения, которые производит межсетевой экран над полученными в результате анализа пакета данными. Оно, в свою очередь, определяется количеством правил, которое проходит пакет и числом критериев, по которым производится сравнение.
Для примера возьмем несколько достаточно стандартных правил из Handbook'а:
Что мы видим? Любой пакет, направленный "к нам" будет последовательно сравниваться с правилами, предназначенными для "исходящих" пакетов (0-299) и только потом дойдет до правил, предназначенных собственно для обработки пакетов "входящих", кроме того, в каждом правиле предусмотрена проверка "направления движения" пакета и интерфейса, через который он "движется". Не-по-ря-док.
Что тут можно сделать? Например, разделить поток трафика...
... примерно таким образом:
При этом а) входящим пакетам не придется проходить сравнения с правилами предназначенными для пакетов исходящих и б) собственно операции сравнения можно значительно упростить т.к. "направление движения" и "интерфейс" мы проверяем при этом самом "делении". Как только в дело вмешается nat + расположенные на самом сервере службы таким простым делением обойтись уже не удастся - я лично делю трафик на (входящий-исходящий), (внутренний интерфейс-наружный интерфейс), (адресованный серверу - транзитный), в ряде случаев к последней "дележке" добавляются еще broadcast и multicast трафик, но это требуется не слишком часто. Единственное требование, нужное для выполнения этого "фокуса" - _явная_ нумерация всех правил в списке, что определенным образом затрудняет сопровождение скрипта.
Можно еще скомпоновать несколько правил "в одно":
$cmd 00200 allow tcp from any to any 80,443,25,110 setup keep-state
Не следует забывать, что подобная организация правил упрощает сопровождение-управление скрипта и затрудняет тонкую "донастройку" правил, но "группировать" подобным образом "однотипные" протоколы можно и нужно.

Для того, чтобы все это не превратилось в нечитаемую мешанину из goskipto рекомендуется:
- Нумеровать правила с шагом хотя бы в 10 (Но в 100, как собственно и установлено по дефолту - лучше. Мало ли...).
- Отделять логические блоки правил друг от друга при помощи комментариев, в которых _обязательно_ указывать что это за блок, и в каком числовом диапазоне он расположен ("#######Обрабатываем входящий трафик 0-32500#####:" - примерно так).
- Не экономить на "внутритекстовых" комментариях.

@темы: FreeBSD, Работа

14:58 

Полежал. Прошло.

Поставил вместо isc-dhcpd 3.1.3 (С обновлением от 27 марта, ага) его же версии 3.0.7_5. Запустил с теми же конфигами. Возрадовался, ибо работает. Решил разобраться чуть-глубже, стартанул tcpdump -i lo0 -w ./3.0.7_5, записал дамп происходящего. Снес 3.0.7_5, воткнул обратно 3.1.3, злорадно запустил tcpdump... и обломался! ЭТА СВОЛОЧЬ НАЧАЛА НОРМАЛЬНО ОБНОВЛЯТЬ ОБРАТНУЮ ЗОНУ!!!
Снес-почистил-ребутнул-поставил-запустил... обновляет. Скопировал конфиги на другую виртуальную машину, запустил... работает! Без всякого копирования нарисовал всю схему по новой на свободной ВМке - тоже работает.
Сижу в раздумьях и сомненьях - "то ли лыжи не едут, то ли я ..."(Ц).

Буду утешаться тем, что скилл установки-настройки BIND'а поднялся на пару пунктов. На будущее - копирнул себе стартовые скрипты от 3.1.3 и сорцы от 4.1.1, буду пользоваться ими... :shuffle:

@темы: FreeBSD, Работа

16:44 

Ну и опять о вечном...

... т.е. о граблях(ТМ).
FreeBSD 7_3.
DNS. Зона прямого просмотра. Зона обратного просмотра. Файл с ключом. named-checkconf. named-checkzone. OK
DHCP. update-style interim. Зоны, primary 127.0.0.1; ключ. isc-dhcpd start. ОК.
Проверяем клиента - ipconfig /release - ipconfig /renew. Получаем адрес. nslookup <имя> - получаем IP. nslookup ip - получаем... ничего не получаем.
Лезем в логи - offer/ack, forward проапдейтили, TXT + A создали, TXT удалили, а с revers'ом - таки ой: "dhcpd: unable to add reverse map from <> to <> timed out".
В логах BIND'а чуть интересней:
client 127.0.0.1 updating zone бла-бла-бла ОК
client внешний адрес update 'x.x.x.in-addr.arpa/IN' denied.
Шо за нафиг? Прямую зону обновляем через 127.0.0.1, а обратную - через собственно интерфейс? Резво лезу в dhcpd.conf - нет, и там, и там стоит обращаться к 127.0.0.1. Странно. Запускаю tcpdump -i lo0, делаю release-renew на клиенте - думаю, может, это он, зар-раза за обновлением пополз, на DHCPD наплевав? Не-а!!! Запрос на обновление прямой зоны идет через 127.0.0.1 от, собственно, 127.0.0.1, а запрос на обновление зоны обратного преобразования идет через 127.0.0.1 же, но src-addr там именно что адрес реального интерфейса!
Для проверки меняю у зоны обратного преобразования update-policy на allow-update { адрес интрефейса }, проверяю - пашет. Меняю на 127.0.0.1 - нихтЪ. Ставлю вместо адреса ключ - опять нихтЪ. Запускаю nsupdate -k <ключ>, server = 127.0.0.1, делаю обновление - проходит.
"От такая вот загогулина"(С). Оно, конечно, и без зоны обратного просмотра прожить можно, да и на всю бОшку инсекьюрные апдейты по IP-адресу нормально пашут, но, блин, интересно же! Полдня вокруг железки с бубном плясал, так ничего и не добился. Думаю завтра качнуть с isc.org сорцы 4_1_1 вместо 3х из портов и попробовать скрестить ежа с ужом...
Вся жизнь - борьба!

@темы: Работа, FreeBSD

16:19 

Поймал себя на желании...

... в третий раз переписать основной firewall'ьный скрипт - ибо "читаемость" входит в противоречие с "простотой парсинга".
Медитирую на фразу "совершенство недостижимо", думаю странное ).

@темы: FreeBSD, Жизнь, Работа

15:58 

Две распространенные...

... ошибки (?) при написании firewall'ов:
Первая - исключение из рассмотрения одного из проходов. "Слева у меня диск С и справа у меня диск С, ну я один и удалил"(С), ага. Зачем описывать в правилах два прохода - "замышим" все на выходе в интернет и будем жить, да. В лучшем случае трафик делится на "входящий" и "исходящий" без указания интерфейсов - т.е. дважды проходит _один и тот же_ набор правил, а в худшем - просто ставится что-то вроде ipfw add allow all from any to any via <внутренний интерфейс>.
Пошло все это, как мне кажется с весьма умных людей, которые решали достаточно специфические задачи (Интернет-провайдинг) в достаточно специфических условиях (ОЧЕНЬ большой объем трафика, отсутствие каких-либо "дополнительных" служб на сервере, практически одинаковый уровень безопасности "внутренней" и "наружной" сетей и пр), охотно приводимые ими примеры отлично работали, хорошо читались, охотно комментировались и, как следствие, получили широкое распространение.
"Куда крестьяне, туда и обезьяне", ага. Увы, в "корпоративных" (Малый-средний бизнес, где все еще "в ходу" подобные "самоделки") решениях условия-требования несколько другие: "наружная" и "внутренняя" сеть обладают разными уровнями безопасности, "внутренняя" сеть, кто бы там что не думал, _НЕ_ является "абсолютно безопасной" (Т.е. решение с разрешением _всего_ трафика на внутреннем интерфейсе является категорически неприемлемым), сам брандмауэр может предоставлять внутренним пользователям дополнительные услуги (DNS-сервер, различные proxy и пр) - так что экономить на "головоемкости" не следует, и "мой тоби совет" - контролировать надо _оба_ прохода трафика, причем правила контроля "в общем случае" должны быть _разные_.
Вторая распространенная ошибка - использование nat'а в качестве stateful фильтра. Казалось бы, и там и там мы контролируем src port/addr - dst port/addr, создаем динамические правила с ограниченным сроком жизни - "... What's the difference?"(C). Увы, в большинстве современных реализаций nat'а она все-таки есть. Более-менее контроль состояния обеспечивает т.н. symmetric nat (Навскидку - pf), остальные реализации (Port restricted, addr restricted, full clone nat) допускают те или иные вольности с прохождением трафика (Из любви к истине скажем, что делается это не просто так - наиболее "безопасная" реализация nat'а, равно как и statefull filtering сам по себе, создают значительные проблемы ряду протоколов (Пиринговые сети, STUN и пр)).
Если посмотреть еще чуть-чуть глубже, например, набрав во FreeBSD'шной консоли sysctl net.inet.ip.fw мы увидим:
net.inet.ip.fw.dyn_keepalive: 1
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300
что stateful фильтрация контролирует _все_ стадии "жизни" tcp-соединения, создавая целый _ряд_ динамических правил с разным временем жизни, чем известные мне реализации nat'а (Совершенно справедливо, ибо не барское это дело ;)) не озадачиваются. Ergo - на nat надейся, а "контролем состояния" не пренебрегай, как бы геморройно это ни было в том же ipfw ;). Впрочем, чрезмерно увлекаться подобным контролем тоже не стоит - записи в таблице состояний, записи в таблице nat'а, энное количество правил + два прохода трафика = потенциальная уязвимость к (D)DOS атакам. На мой взгляд, имеет смысл использовать контроль состояния на выходе из firewall'а, а на внутреннем интерфейсе можно применять классическую пакетную фильтрацию образца 80х годов... впрочем, по этому поводу я все еще думаю, ибо "совершенство приходит с опытом" :shuffle:

@темы: FreeBSD, Работа

16:07 

Загадка...

... ну или очередные грабли - это уж кому как ;). Как запрячь в одну упряжку осла и трепетную лань совместить в одном ipfw'шном ruleset'е stateful filtering и kernel nat написано в handbook'e. Чего там _не_ написано (Не удивлюсь, если оный sysctl появился уже _после_ выхода статьи, а "поправить" ни у кого руки не дошли) - sysctl net.inet.ip.fw.one_pass надо ставить в нуль, иначе работать пример не будет. Внимание, вопрос! Можно ли нафантазировать stateful ruleset с one_pass=1 и nat?
Ответ

@темы: FreeBSD, Работа

Танец-с-саблями на граблях

главная