Bsdmag 01 2012 rus by plok

РУССКАЯ ВЕРСИЯ

FREEBSD: СОДЕРЖИМ СИСТЕМУ В АКТУАЛЬНОМ СОСТОЯНИИ В НОМЕРЕ: ЧТО НОВОГО ВО FREEBSD 9.0 - DRU LAVIGNE PUPPET НА FREEBSD СИСТЕМА ОБНАРУЖЕНИЯ ВТОРЖЕНИЙ И SNORT INLINE РАСПРЕДЕЛИТЕЛЬ ПАМЯТИ ЯДРА MALLOC(9) ПОДДЕРЖИВАЕМ FREEBSD И ПАКЕТЫ В АКТУАЛЬНОМ СОСТОЯНИИ АНАТОМИЯ КОМПРОМЕТАЦИИ FREEBSD (ЧАСТЬ 2-Я) ДОМАШНИЙ CAPTIVE PORTAL НА БАЗЕ OPENBSD

ВЫПУСК 01/2012 (2)

В НОМЕРЕ

Дорогие читатели,

Мы продолжаем тот почин, что задали в начале года и выпускаем следующий номер журнала. Выход которого, почти совпадает с началом года дракона по китайскому календарю. Надеемся, что он нас всех не подведет.

Редактор английской версии: Patrycja Przybyłowicz patrycja.przybylowicz@software.com.pl

На электронную почту мы получили много писем, посвященных тематике журнала, вашим пожеланиям и предложениям по улучшению. Спасибо! Постараемся не подвести и довести процесс до ума. Все буквы в алфавит со временем вернем, особенно „ё” - не сомневайтесь.

Авторы: Dru Lavigne, Toby Richards, Robert Sommerville, Michael Shirk, Edward Tan, Slawomir Vojtczak, Paul MacMath, Luca Ferrari

Номер открывает дайджест от Dru Lavigne, где вы ознакомитесь с теми нововведениями, что появились во FreeBSD 9.0. В секции HowTo расскажем о таком инструменте, как Puppet, и как его можно применять в серверной среде. Материал от Michael Shirk посвящен системе обнаружения вторжений (IPS) и взаимодействии со Snort Inline. Toby Richards расскажет, как создать домашний Captive Portal.

Русская редакция: editor@bsdmag.su

Системным администраторам будет интересно ознакомиться со статьей от Paul MacMath и посвященной malloc(9) - распределителю памяти ядра общего назначения. В рубрике „Советы и рекомендации” читайте текст об обновлении базовой системы FreeBSD, а также установленных пакетах. Раздел „Безопасность” содержит вторую часть „Анатомии компрометации FreeBSD” от Robert Sommerville. В этот раз автор расскажет об общих техниках получения контроля и как минимизировать риски.

Исполнительный директор: Ewa Dudzic ewa.dudzic@software.com.pl

Корректоры: corrector@bsdmag.su Издатель : Software Press Sp. z o.o. SK ul. Bokserska 1, 02-682 Warszawa Poland worldwide publishing tel: 1 917 338 36 31 www.bsdmag.org Все торговые марки, задействованные в журнале, использованы для информационных целей. Права на них принадлежат соответствующим компаниям.

В секции „Поговорим” расскажем об PostgreSQL и мероприятии PGDay, проведенном в Прато (Италия). Надеемся, вы найдете что-либо рациональное и для себя. P.S. Мы выпускаем журнал на основе ежемесячных лицензионных отчислений польскому издателю. Если хотите продолжать читать журнал на русском языке - спонсоры и читатели, поддержите нас! Команда русской редакции

01/2012

В НОМЕРЕ

Уголок разработчика

Советы и рекомендации

во FreeBSD 9.0 04 Новое Dru Lavigne

FreeBSD и 34 Поддерживаем установленные пакеты в актуальном

How-To

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

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

на основе OpenBSD 10 Создаем домашний Captive Portal Toby Richards

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

на FreeBSD 14 Puppet Edward Tan

Целью этой статьи служит задание направления для старта системному администратору так, чтобы он мог использовать Puppet в нужном формате, а именно - грамотно управлять конфигурацией серверов, в частности, на базе FreeBSD

обнаружения вторжений 22 Система во FreeBSD на основе Snort Inline

состоянии

Slawomir Wojtczak

Безопасность компрометации FreeBSD 46 Анатомия (часть 2-я) Rob Sommerville

Продолжаем серию статей, в которых мы рассматриваем случаи, когда “плохие парни” хотят получить доступ к системе, и что мы можем сделать для снижения рисков.

Поговорим в Прато 52 Слоны Luca Ferrari

Группа поддержки проекта PostgreSQL провела 25 ноября в Прато (Италия) пятую ежегодную конференцию PostgreSQL Day (PGDay).

Michael Shirk

По классической конфигурации Snort в режиме обнаружения вторжений на разных системах семейства BSD существует множество статей. Однако, у Snort есть возможность интеграции с пакетным фильтром ipfw. Это особенность позволяет организовать на FreeBSD встроенную систему предотвращения атак. В этой статье рассматривается базовая конфигурация Snort в режиме IPS на сервере FreeBSD.

Администрирование памяти ядра общего 28 Распределитель назначения - malloc(9) Paul MacMath

В 1988 году в 4.3.BSD был представлен новый механизм распределения памяти, который, как и предполагалось, будет достаточно универсальным для эффективного удовлетворения задач различных подсистем ядра, которым в свою очередь, требовалось динамически размещать участки памяти.

www.bsdmag.su

УГОЛОК РАЗРАБОТЧИКА

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

версии FreeBSD 9.0-RELEASE было предоставлено множество нововведений, которые понравятся пользователям FreeBSD, разработчикам приложений, а также компаниям, использующим FreeBSD либо разрабатывающим свои продукты на базе этой операционной системы. В этой статье приведен обзор некоторых из этих новшеств, включая ссылки на дополнительную информацию. Все новые функции с статье не приводятся, т.к. они детально описаны в документе “FreeBSD 9.0 Detailed Release Notes” (доступном на freebsd.org), с описанием всех изменений версии 9.0. В статье обсуждаются функции, относящиеся к следующим категориям: безопасность, компиляторы и фреймворки тестирования, файловые системы и системы хранения данных, сетевое взаимодействие и многое другое.

Безопасность Фреймворк Capsicum

Capsicum – это легковесный фреймворк, который расширяет возможности ядра UNIX в соответствии со стандартом POSIX, чтобы обеспечить новые возможности безопасности, а также добавляет специальный API для программ пользовательского уровня. Он был разработан совместно University of Cambridge Computer Laboratory и Google. Спонсировался также за счет гранта от компании Google. Операционная система FreeBSD выступала в проекте как платформа-прототип, а Chromium – как приложение-прототип. В ядре FreeBSD 9.0 заявлена поддержка фреймворка в качестве экспериментальной опции, поэтому исследователи и интересующиеся могут уже его опробовать. Поддержка на уровне приложений будет в следующем выпуске системы. Также есть планы выпустить во FreeBSD 9.1 некоторые приложения с поддержкой Capsicum. Традиционные фреймворки по контролю доступа спроектированы таким образом, чтобы пользователи были бы защищены друг от друга за

счет использования битов разрешений, а также за счет политик по мандатному доступу. Однако, такие механизмы не могут защитить пользователя когда приложение, такое как веб-браузер, обрабатывает несколько потенциально опасных потоков данных – HTML, скриптовые языки, небезопасные графические файлы. Capsicum дает разработчикам приложений хорошо отточенный инструмент по контролю за файлами и сетевыми сокетами, так что можно за счёт минимального внесения изменений в код достичь разделения привилегий внутри самого приложения. Другими словами, фреймворк дает приложению возможность создать несколько «песочниц», в которых приложение будет выполнять несколько разных частей программы. В качестве примера может выступать браузер Chromium, в котором каждая открытая вкладка работает в своей «песочнице», точно также в отдельную «песочницу» можно поместить обработку каждого графического файла. Создание таких “песочниц” с помощью Capsicum не требует наличия привилегий, что обычно являлось ключевой проблемой в аналогичных решениях на платформе UNIX. Яркий пример – добавив всего лишь 10 строк кода, такое небезопасное приложение как tcpdump, может быть размещено в “песочнице” Capsicum. Для веб-браузера Chromium потребуется всего 100 новых строк. Посмотрите справку capsicum(4), чтобы получить представление о доступных системных вызовах. Для получения всей информации по проекту, включая ссылки на технические публикации, смотрите сайт Capsicum: http://www.cl.cam.ac.uk/research/security/capsicum/.

Разграничения по ресурсам В систему было добавлено решение rctl(8), которое позволяет пользователю просмотреть текущие ограничения на ресурсы, а также определить те действия, что будут совершены когда процесс превысит эти ограничения. Правила могут быть

01/2012

Новое во FreeBSD 9.0

назначены процессам, пользователям, классам, имеющим право входить в систему, или наложены на jails. Специальное API, под названием racct, собирает информацию по ресурсам, потребляемым процессом, пользователем и т.д. Информацию по ресурсным ограничениям и утилите rctl можно найти по адресу: http://wiki.freebsd.org/Hierarchical_Resource_Limits.

Компиляторы и фреймворки тестирования Инфраструктура компилятора LLVM LLVM – это набор компилирующих утилит, который выпускается под лицензией BSD и обладает схожими чертами, что и коллекция GCC (идущая под лицензией GPL3). Clang – это фронтенд к LLVM для языков: C, C++, Objective C и Objective C++, обеспечивающий альтернативное программное решение для разработчиков и компаний, которые предпочитают использовать утилиты с BSD-лицензией. Кроме того, что Clang выпускается под BSDлицензией, он может предложить разработчикам улучшенные возможности по повышению производительности своей работы, за счет проработанных сообщений об ошибках, анализатору статического кода и т.д. Компилятор может быть настроен для поддержки исследований в области новых инструкций языка или же измерения выполнения программного кода. Начиная с версии FreeBSD 9.0, как само ядро, так и инфраструктура FreeBSD могут быть собраны Clangкомпилятором на большинстве поддерживаемых архитектур. В процессе также находится работа по переводу системы портов на новую схему компиляции. Информация об архитектурной поддержке, оптимизациях линковщиков, генерации автотестов, а также дополнительные ресурсы можно найти на странице: http://wiki.freebsd.org/BuildingFreeBSDWithClang. Информация о Clang находится здесь – http:// clang.llvm.org/, а о самом проекте LLVM – http://www. llvm.org/. Видео от Brooks Davis, в котором рассказывается как проект FreeBSD активно работает по внедрению LLVMинструментария в базовую систему, размещено на YouTube: http://www.youtube.com/watch?v=yVaNAm8jR_U. Вы также можете следить за статусом перевода системы портов на Clang на странице – http://wiki.freebsd.org/PortsAndClang

www.bsdmag.su

DTrace на пользовательском уровне DTrace – это легковесный фреймворк общего назначения, с помощью которого администраторы, разработчики и пользователи могут исследовать причины системных отказов и ошибок, а также искать места, в которых теряется производительность. Поддержка DTrace на уровне ядра появилась во FreeBSD 8.0. Добавление же поддержки DTrace на пользовательском уровне в версии 9.0 позволяет проводить анализ программ пользовательского уровня и смотреть корреляцию полученных данных с данными ядра, что позволяет получить гораздо более полную картину происходящего. На http://wiki.freebsd.org/DTrace можно обнаружить примеры использования DTrace на FreeBSD как на уровне ядра, так и для пользовательских приложений. Там же Вы найдете ссылки на другие ресурсы по теме.

Файловые системы и хранилища Хранилище с высокой доступностью (HAST) Фреймворк HAST (Highly Available Storage) предоставляет механизм синхронной репликации на уровне блоков любых хранилищ данных на физически разнесенных серверах, подключённых к TCP/IP-сети. HAST следует воспринимать как сетевое зеркало, схожее с DRBD в Linux. Будучи совместно использованным с carp(4), HAST позволяет создать высокодоступный кластер хранения данных, устойчивый к аппаратным проблемам. Фреймворк не привязан к какой-либо файловой системе или приложению и может быть совмещен с любым GEOM-классом (см. “В сети - Что такое GEOM-класс”). В случае, если первичный узел становится неисправным, то кластер автоматически переключается на второй узел, проверяет и монтирует файловую систему UFS, либо же импортирует ZFS-пул и продолжает работу без потери и бита информации. В настольной книге FreeBSD Handbook описывается, как можно настроить HAST: http://www.freebsd.org/doc/handbook/disks-hast.html SU+J UFS с журналируемыми softupdates на данный момент является файловой системой по умолчанию. Как следует из названия, в ней была добавлена легковесная версия журнала, в соответствии с http://www.mckusick.com/BSDCan/bsdcan2010.pdf. За счет этого было значительно сокращено время

УГОЛОК РАЗРАБОТЧИКА

загрузки после неправильного выключения системы, т.к. фоновую проверку диска требуется запускать только если произошло разрушение лога журнала. ZFSv28 FreeBSD 9.0 комплектуется с ZFSv28. В этой версии ZFS были добавлены следующие возможности: •

•

• •

•

• •

дедупликация: процесс устранения дублированных копий данных. Когда эта функция применяется к набору данных с дублирующейся информацией (например, виртуальные образы или jails), то экономится место и увеличивается производительность диска за счет меньшего объема записываемых и хранимых данных. тройная четность RAIDZ: RAIDZ3 работает с тремя дисками четности и может продолжать функционирование в режиме деградации, если не более чем у 3 дисков начались проблемы, причем не важно, на каких дисках они возникли zfs diff: команда, которая описывает какие изменения на уровне файловой системы произошли между 2 снапшотами zpool split: позволяет администратору извлекать содержимое диска из зеркалированного устройства vdev и создавать новый пул данных с точной копией диска. Этот новый пул затем может быть импортирован на любой машине удержание снапшотов: позволяет пользователям или приложениям размещать блокировки на снапшотах, с целью предотвращения их удаления zpool import -F: позволяет администратору “перемотать” испорченный пул к более ранней транзакции возможность импортировать zpool в режиме только для чтения.

Фреймворк общего назначения для GEOM I/O планировщиков С помощью этого фреймворка достигается планирование дисковых I/O-запросов к устройству независимым способом, так, чтобы можно было использовать несколько I/O-планировщиков для различных I/O провайдеров. Фреймворк предоставляет пару простых алгоритмов, которые реализуют две формы предупреждающего планирования. За счет наличия двух разных планировщиков, пользователи могут сами выбрать наилучший для их

задач механизм. При некоторых нагрузках (например, где чередуются операции по последовательному и случайный вводу/выводу) можно достичь большей отзывчивости дисковой подсистемы. Примеры, как можно задействовать эти планировщики, представлены на: http://svnweb.freebsd.org/base/ head/sys/geom/sched/README?view=markup&pathr ev=206497. Изменения в CAM и AHCI SATA Новый драйвер ATA/SATA обеспечивает поддержку AHCI-совместимого оборудования, порт-умножителей, а также функции NCQ (tagged queueing) для повышения производительности современных SATA-дисков. Дисковая производительность была значительно увеличена, теперь поддерживаются режимы передачи больших блоков. Поддержка горячего подключения так же была улучшена. Диски ATA/SATA теперь могут нумероваться и ими можно управлять через camcontrol(8), по аналогии со SCSI-дисками. Подсистему cam(4) разбили на несколько модулей (см. “В сети - Подсистема CAM“), а с разработкой и включением отдельных ATA/SATA-модулей в подсистему теперь можно начинать вести речь о том, что она превращается в полноценный фреймворк, где может использоваться произвольный транспорт и протоколы. Она же позволит писать драйверы для поддержки какого-либо отдельного аппаратного решения, не подвергая угрозе стабильность работы не связанной с этим драйвером аппаратуры.

Изменения в инфраструктуре таймеров событий Инфраструктура с новыми таймерами событий представляет унифицированный API для написания драйверов этих таймеров, а также для выбора наилучших драйверов из машинно-независимого кода. Поддержка обеспечивается как для событий каждого CPU, так и для событий всей системы, как для повторяющихся, так и для одноразовых, для архитектур i386 и amd64 Для улучшения производительности в виртуальных машинах, а также эффективного использования энергии в ноутбуках, по умолчанию будет выбран режим динамического цикла, заменяя периодические аппаратные прерывания таймера единственным циклом изменяемого периода. Это экономит время CPU, которое в противном случае тратилось бы на обработку прерываний таймера, не привязанных к выполнению какоголибо действия. Привычный режим может быть

01/2012

Новое во FreeBSD 9.0

включён установкой значения kern.eventtimer.periodic в 1 с помощью sysctl. Технические подробности о динамическом цикле могут быть найдены на http://permalink.gmane.org/gmane.os.freebsd.architechture/13276 Сетевое взаимодействие Пять новых TCP-алгоритмов контроля потока Центр для изучения интернет-архитектур Технологического Университета имени Суинбурна, при поддержке фонда исследовательских программ из Cisco University (в Кремниевой долине) и FreeBSD Foundation, внёс улучшения в TCP-стек FreeBSD для поддержки новых алгоритмов контроля потока. Эти улучшения включают в себя модульный фреймворк, который будет использоваться для добавления будущих алгоритмов, а также для существующих реализаций алгоритмов: H-TCP, CUBIC, Vegas, HD и CHD. Все разработанные алгоритмы выполнены в качестве подгружаемых модулей ядра. Они могут быть выбраны исходя из сетевых/программных характеристик и в зависимости от требований данной конкретной хост-машины. Модульный каркас обеспечивает разработчикам гибкость при создании новых алгоритмов, выводя TCP-стек FreeBSD на передний край разработок в этой области, при сохранении зарекомендовавшей себя стабильности сетевого стека. Ссылки на технические публикации работ по фреймворку и алгоритмам могут быть найдены: http:// caia.swin.edu.au/freebsd/5cc/.

“IPv6-Only” Операционная система FreeBSD находится на переднем крае развития IPv6, начиная с момента выпуска FreeBSD 4.0 в 2000 году, когда была реализована референтная поддержка проекта KAME для сетей IPv4/IPv6. Более того, проект FreeBSD размещает файлы релизов операционной системы на своих IPv6-серверах уже более 8 лет, а вся инфраструктура для разработчиков, списки рассылок, веб-сайтов работает в режиме IPv6 уже с 2007. Начиная с выпуска FreeBSD 9.0 появились и не-IPv4снапшоты. За счет полностью разделенной поддержки функционала IPv6 и IPv4, сами разработчики могут определить, на самом ли деле их “IPv6” приложения готовы к работе в сетях IPv6, или же они имеют свои ещё не выявленные баги из-за того, что их функционирование велось поверх IPv4. Дав

www.bsdmag.su

возможность использовать ядро с поддержкой только IPv6, проект FreeBSD предлагает разработчикам программного обеспечения условия для проверки и исправления подобных ошибок, поощряя их готовить по настоящему “IPv6”-готовые приложения. Подробная информация о версиях FreeBSD без IPv4 расположена на странице: http://www.freebsd.org/ipv6/ Для поддержки режима “только IPv6” были переделаны rtadvd(8) и rtsold(8) – теперь они соответствуют стандарту RFC6106. Причем rtsold теперь может обновлять /etc/resolv.conf с помощью фреймворка управления информацией DNS openresolv (http://roy.marples.name/projects/openresolv). Доступен опциональный модуль ядра для обеспечения протокола SeND (Secure Neighbor Discovery protocol); его описание ищите в RFC3971. В продолжение более ранней тенденции развития стало возможным задавать больше глобальных опций для единичного сетевого интерфейса. Например, теперь можно принимать объявления со стороны роутера на одном интерфейсе, при этом находясь в форвард-режиме. Такая возможность нужна в ситуациях, когда нужно использовать FreeBSD в качестве IPv6 CPE-устройства (Customer Premises Equipment). Всего лишь одна строчка “ipv6_cpe_wanif” в конфигурации /etc/rc.conf правильно настроит все вызовы sysctl и интерфейсные опции, что позволит создавать устройства формата CPE проще, чем когдалибо!

Высокопроизводительный SSH (HPN-SSH) Сетевая производительность OpenSSH ограничена за счет статически определённых внутренних буферов потока. Они зачастую исчерпываются и создают узкое место для SCP-потока, особенно на широкополосных и протяженных линиях. HPN-SSH добавляет поддержку динамически изменяемых размеров буферов, так, чтобы можно было задействовать целиком толстые и протяжённые каналы, такие как 100Mbps и более быстрые трансатлантические и трансконтинентальные линии. Задержки передачи на широкополосных каналах вплоть до 64Mb также допустимы. Данная реализация включает в себя мультипоточное шифрование, что обеспечивает эффективную обработку данных процессором для такой широкой полосы пропускания. По умолчанию, код HPN включен в реализации sshd для FreeBSD 9.0, а также добавлены некоторые специфичные опции для HPN в файл конфигурации /etc/ssh/sshd_config. Эти опции, а также советы по

УГОЛОК РАЗРАБОТЧИКА

В сети

•

RAID-Z по-русски: http://blogs.oracle.com/bonwick/ru/entry/raid_z_russian

•

Что такое GEOM и классы: http://bu7cher.blogspot.com/2010/12/geom-1.html

Подсистема CAM: http://net-admins.org/forum/showthread.php?t=2589

повышению эффективности, описаны в документе http://svnweb.freebsd.org/base/head/crypto/openssh/README.hpn?revision=224638&view=markup. Разное Стоит также отметить ряд других особенностей: • масштабируемая поддержка SMP-систем с более чем 32 процессорами. В прежних релизах, в структурах ядра не было соответствующих механизмов, которые бы учитывали такое количество процессоров. Yahoo! предоставило системы для тестирования внесенных изменений. • улучшенная поддержка USB3.0 • NFS клиент и nfsd(8) теперь по умолчанию поддерживают NFSv4. Обратная совместимость с более старыми клиентами обеспечивается через тип монтирования “oldnfs”. • был добавлен в ядро новый менеджер NFS-блокировок, который улучшил производительность и поведение при блокировочных ситуациях. Новая команда clear_locks(8) позвовляет очистить блокировки, удерживаемые NFS-клиентом. • установщик sysinstall был заменен на bsdinstall. Его функции описаны на странице http://wiki.freebsd.org/BSDInstall, а документацию по использованию можно найти в FreeBSD Handbook: http://www.freebsd.org/doc/en_ US.ISO8859-1/books/handbook/bsdinstall.html • ядро теперь поддерживает новый формат дампов – textdump(4). В нем содержится информация высокого уровня, механически сгенерированная/ вытащенная из вывода сообщений об ошибках, в отличие от простого дампа памяти. Такая особенность может быть использована при создании отчетов о состоянии ядра, содержащих богатую отладочную информацию. Отчеты, при этом, не зависят от таблиц символов ядра, или же наличия синхронизированного дерева исходных текстов.

FreeBSD 9.0 может быть установлена на Sony Playstation 3 – воспользуйтесь инструкциями с сайта http://people.freebsd.org/~nwhitehorn/ps3/README. в ipfw(8) были добавлены действия для правил: call и return – смотрите http://svnweb.freebsd.org/ base?view=revision&revision=223666

Вывод С выходом FreeBSD 9.0, проект FreeBSD продолжает инновационные работы в области обеспечения безопасности, разработок в области компиляции, файловых систем и сетевого обеспечения. Узнать больше о проекте FreeBSD, а также загрузить FreeBSD 9.0, вы можете на сайте freebsd.org

ОБ АВТОРЕ

Dru Lavigne — автор книг BSD Hacks, The Best of FreeBSD Basics и The Definitive Guide to PCBSD. В качестве директора по развитию в проекте PC-BSD, она руководит работой команды по документированию, помогает новым пользователям, оказывает содействие в поиске и исправлении ошибок, работает с сообществом для выяснения потребностей. Она бывший редактор журнала Open Source Business Resource — бесплатного ежемесячного издания посвященного open source и коммерциализации продуктов на его основе. Она также является основателем и председателем совета BSD Certification Group Inc., некоммерческой организации, миссия которой — создание единого стандарта для сертификации системных администраторов BSD систем. Кроме этого, Dru Lavigne является членом совета FreeBSD Foundation.

01/2012

<<TOP>>

Редакция русской версии журнала открыта для сотрудничества!

Пишите нам: editor@bsdmag.su

www.bsdmag.su

HOWTO

Создаем на основе OpenBSD домашний Captive Portal

Вы когда-нибудь подключались к беспроводной WiFi-сети, где используется страница с предупреждением, и прежде чем выйти в интернет, вам нужно было согласиться с некоторыми опубликованными условиями на этой странице?

та технология называется Captive Portal, и сегодня мы займемся построением такого на базе пакетного фильтра (pf), что присутствует в OpenBSD. Во FreeBSD тоже есть пакетный фильтр, поэтому эти инструкции применимы и к этой операционной систме, хотя я такую конфигурацию и не пробовал. Существует несколько реализаций Captiveпорталов для FreeBSD. Их количество для OpenBSD значительно ниже, поэтому приходится заниматься созданием “домашнего” решения. При построении данного проекта я использовал в качестве captive-сети частную подсеть 172.16.0.0/24. Также есть другая подсеть 192.168.0.0/24, которая подключена к DSL модему/роутеру по адресу 192.168.0.254. У сервера две сетевые карты: xl0 (192.168.0.1) и em0 (172.16.0.1). Смотрите иллюстрацию на Рис. 1. Как вы знаете у меня работает OpenBSD в паре с nginx. По умолчанию, сервер Apache в OpenBSD находится в jail-окружении. Та техника, о которой я буду рассказывать, не сработает если веб-сервер находится в таком изолированном окружении, потому что для обработки результата выполнения команды /sbin/pfctl будет вызываться интерпретатор PHP. Мы должны разрешить возможность его вызова. Для этой цели я завел пользователя “_php”, который будет выполнять PHP в режиме FastCGI из веб-сервера nginx. Если же вы используете Apache с модулем mod_ php, то замените пользователя, от имени которого выполняется процесс httpd. Для этого запускайте команду visudo и в файл sudoers добавляйте следующую строку:

_php ALL=(ALL) NOPASSWD: /sbin/pfctl Нам потребуется запустить DHCP-службу на нашем сервере для captive-подсети (помните, что для нее работает em0-интерфес). # echo ‘dhcpd_flags=”em0”’ >>/etc/rc.conf.local # touch /var/db/dhcpd.leases Отредактируем файл /etc/dhcpd.conf. выглядит моя конфигурация:

Вот

как

option domain-name-servers 8.8.8.8; subnet 172.16.0.0 netmask 255.255.255.0 { option routers 172.16.0.1; range 172.16.0.100 172.16.0.199; } Запустим DHCP демон: # dhcpd em0 Нам потребуется организовать форвардинг IP-пакетов, поэтому в файле /etc/sysctl.conf раскомментируйте следующую строку (я не использую IPv6, но если у вас уже работает такая сеть, то вы знаете как сделать такую же операцию): net.inet.ip.forwarding=1 Чтобы включить IP-форвардинг без перезагрузки, запустите команду sysctl следующим образом: # sysctl net.inet.ip.forwarding=1

01/2012

Создаем на основе OpenBSD домашний Captive Portal

Самое время отредактировать /etc/pf.conf. Я буду использовать таблицу под названием eula, чтобы отслеживать IP-адреса тех пользователей, что нажмут на кнопку и соглашаясь с условиями использования сети. Строка, где используется UDP:53, означает, что пользователям разрешено производить трансляцию DNS-адресов. Таким образом, пользователи освобождаются от лишних проблем при начальном прохождении стартовой страницы и прежде, чем они нажмут на кнопку (см. Листинг 1). Не забудьте перезагрузить правила в файрволе: # pfctl -f /etc/pf.conf В последней строке этого файла и содержится чародейство. Каждый, у которого его IP-адрес не хранится в таблице eula, будет перенаправлен на вебсервер, работающий на нашей BSD-машине. Как уже отмечалось в самом начале статьи, предполагается, что у нас работает веб-сервер в нормальном (а не jail) окружении, с поддержкой PHP. Когда пользователь начинает запрашивать адрес http://somesite.com, то с помощью пакетного фильтра, он будет перенаправлен по адресу http://172.16.0.1, где его будет ожидать страница с баннером. Для

случая, когда пользователь попытается открыть страницу вида http://somesite.com/somepage, он будет отправлен по адресу http://172.16.0.1/somepage и в итоге увидит ошибку 404. Не знаю, как избавиться от такого эффекта в Apache, но для nginx есть решение – добавьте в секцию “location/” файла /etc/nginx/nginx. conf одну единственную строчку: try_files $uri $uri/ /index.php; Теперь перейдем к шаманству с PHP. Мои примеры достаточо просты, и скорее всего вам захочется навести собственный блеск, в соответствии с вашими требованиями по эстетике, и безопасности. В данном примере, в качестве единственной меры безопасности будет служить хеш клиентского IP-адреса. Смотрим на файл index.php (Листинг 2). Следующий шаг, это составление файла auth.php (см. Листинг 3) И, напоследок, последний штрих. Скорее всего, нам захочется добавить тайм-аут, по которому авторизация будет запрашиваться заново. Восемь часов – неплохой период времени. В секундах это время будет 28800.

Рис. 1 - Конфигурация сети www.bsdmag.su

HOWTO

Листинг 1 – pf.conf set skip on lo

pass # to keep state

pass out quick on xl0 proto udp from any to any port 53 nat-to xl0 pass in quick on em0 from <eula> to any

pass out quick on xl0 from <eula> to any nat-to xl0

pass in on em0 proto tcp from any to any port 80 rdr-to 172.16.0.1 port 80

Листинг 2 – index.php <html><body> <?php

$salt=”somesalt”;

$clientip=$_SERVER[‘REMOTE_ADDR’];

$clienthash=hash(‘sha256’, $salt . $clientip); ?>

Это мой captive-портал. Нажмите на кнопку для принятия условий сети. <br>

Листинг 3 – auth.php <html><body> <?php

$salt=”somesalt”;

$clientip=$_SERVER[‘REMOTE_ADDR’];

$goodhash=hash(‘sha256’, $salt . $clientip); $myip=$_POST[‘myip’];

$myhash=$_POST[‘myhash’];

if ($myhash != $goodhash) { die(); }

exec (“sudo pfctl -t eula -T add “ . $clientip); ?>

Теперь вы можете выходить в Интернет. </body></html>

Добавим нужную строчку в файл /var/cron/tabs/root: * * * * * /sbin/pfctl -t eula -T expire 28800 > /dev/null Каждую минуту cron будет проверять и удалять из таблицы eula IP-адреса, срок хранения которых там уже более 8 часов. Поздравляю, вы создали свой собственный captiveпортал. Теперь можете смело открывать кофейную лавку с интернет-доступом!

ОБ АВТОРЕ

Toby Richards работает сетевым администратором с 1997 года. Toby рекомендует bsdvm.com в качестве вашей возможной хостинговой площадки, т.к. ресурс предоставляет полный консольный доступ к вашей виртуальной машине.

01/2012

HOWTO

Puppet на FreeBSD Цель этой статьи – дать направление для старта системному администратору по использованию Puppet (инструменту по управлению конфигурацией) и показать, как управлять конфигурацией серверов, в частности, на базе FreeBSD Вы узнаете… О чем вы должны знать… • что такое Puppet • Базовые навыки настройки сети в FreeBSD • как разворачивать серверы используя Puppet • Базовое знание системы портов FreeBSD • различные сценарии при разворачивании серверов

рименяя Puppet для управления конфигурациями можно добиться следующего:

• • •

автоматизировать процесс установки сервера глобального применения изменений на серверах поддержания целостного состояния серверов

Puppet может быть использован для автоматизации процесса установки программного обеспечения и конфигурирования при разворачивании серверов. Такой инструмент, в частности, полезен, когда приходится устанавливать много серверов с похожей конфигурацией (например, файлы sudo, SSH-службы, веб-серверы и прочее). Puppet также может быть полезен в ситуациях, когда нужно какой-либо скрипт или программу распространить на группу серверов. После этапа начального распространения, изменения в дальнейшем могут быть взяты с мастер-узла Puppet и применены к группам серверов с минимальными усилиями. Частью работы системного администратора является проверка состояния сервера, в нужной ли он форме – как пример, SSH-сервис должен всегда спрашивать про публичные ключи, а парольная аутентификация должна быть отключена. Системному администратору придется персонализировать конфигурационные файлы на всех серверах и , при этом для соответствующих сервисов (например, SSH, NTP, named ...) должна быть обеспечена возможность их непрерывной работы, а также рестарта, в случае, если у них меняется конфигурация.

Puppet написан на Ruby и лицензируется под лицензией Apache (начиная с версии 2.7.6, до этого была лицензия GPL). Утилита является форком от cfEngine, еще одного мощного инструмента по управлению конфигурацией. Разобраться с Puppet и начать использовать его достаточно просто вследствие его декларативного языка. Вместо чтения объемных руководств посвященных Puppet, эта статья предлагает вам пройтись по тем простым примерам, как установить серверную и клиентскую части Puppet. После этого мы разберем типовые сценарии, чтобы понять, как на самом деле работает программа. Общая картина Серверы FreeBSD, участвующие в клиент-серверной модели Puppet должны быть настроены и выглядеть следующим образом: •

•

Puppet правильно установлен и сконфигурирован на “мастере” и “агенте”, в основном речь идет об их взаимодействии по каналу, подписанному SSL-сертификатом система портов настроена корректно – она потребуется для разворачивания конфигураций sudo и SSH-сервиса для использования в агенте Puppet, после этого будет возможным автоматическая настройка и конфигурация вебсервера Apache

Чтобы выполнить озвученные задачи, мы разобъем установку на логические части:

01/2012

Puppet на FreeBSD

Часть I – установка мастер-узла Puppet и агента 1. установим Puppet и другие утилиты 2. выполним работу по редактирированию конфигурационных файлов: • /usr/local/etc/puppet/puppet.conf • /usr/local/etc/puppet/fileserver.conf • /usr/local/etc/puppet/manifests/site.pp • /usr/local/etc/puppet/manifests/classes/*.pp • /usr/local/etc/puppet/auth.conf • /etc/rc.conf 3. подпишем сертификатом мастер-узел Puppet и агент Часть II – различные сценарии развертывания 1. задействуем Puppet для конфигурации sudo на агенте 2. установим и сконфигурируем SSH-службу 3. установим и сконфигурируем веб-сервер Apache 2.2 Следующие серверы будут выполнять роли: • puppet-master.example.com – этот сервер будет мастер-узлом/мастер-сервером Puppet. Он ответственен за распространение конфигураций на узлы-агенты. • puppet-agent.example.com – собственно, сам агент. Он получает инструкции от мастер-узла и действует в соответствии с ними. В данном случае, разворачивает конфигурации для sudo, SSH-службы и веб-сервера. Вы уже заметили, что для работы сервера требуется FQDN-имя. Мастер и агент будут называться, соответственно, как puppet-master.example.com” и “puppet-agent.example.com”. Внимание: конфигурационные файлы, показанные в этой статье, являются необходимым минимумом чтобы заработала связка мастер-агент, а также контролируемые сервисы. Примеры могут быть не предназначены для промышленного применения. Используйте их на свой страх и риск! Как работает Puppet Puppet полагается на связь “мастер-агент” для контроля клиентских машин со стороны сервера. На мастер-узле готовится какой-либо сценарий и отсылается агенту, который, в свою очередь, выполняет присланный сценарий. Эти действия называются “ресурсы” (“resources”). Они могут быть сгруппированы в “классы” (“classes”) для формирования более общих “функций” (“func-

www.bsdmag.su

tions”). “Ресурсы” затем выполняются на узлах, то есть агентах. Как себя ведет Puppet: •

Использует SSL для обеспечения безопасной связи между мастером и агентом. • Мастер-узел хранит разрешения на ресурсы в файле /usr/local/etc/puppet/auth.conf • Мастер-узел хранит собственную конфигурацию в файле /usr/local/etc/puppet/puppet.conf • На агентах не требуется присутствие файла /usr/ local/etc/puppet/puppet.conf • Сообщения об ошибках Puppet хранятся в /var/ log/messages Древовидная структура ниже показывает какие именно файлы и директории необходимы для мастера-узла Puppet: /usr/local/etc/puppet ├── auth.conf ├── files │

├── httpd.conf

│

└── sudoers

│

├── sshd_config

├── fileserver.conf ├── manifests │

├── classes

│

│ │

│

├── resource_group.pp └── something.pp

└── site.pp

└── puppet.conf

Часть I: устанавливаем мастер-узел Puppet и агент

Листинг 1.1 – Установка Puppet # cd /usr/ports/sysutils/puppet # make install clean

Подготовка puppet-master.example.com: См. Листинг 1.1 Установка и конфигурирование: См. Листинг 1.2 Конфигурируем мастер-узел Puppet: См. Листинг 1.3 Изменим следующие параметры /usr/local/etc/puppet/puppet.conf:

файле

HOWTO

Листинг 1.2 – Создание пустых файлов-скелетов # mkdir -p /usr/local/etc/puppet/manifests/classes # mkdir -p /usr/local/etc/puppet/files

# touch /usr/local/etc/puppet/files/sudoers

# touch /usr/local/etc/puppet/files/sshd_config # touch /usr/local/etc/puppet/files/httpd.conf

В Листинге 1.5 задаются некоторые имена для агентов и определяется какие ресурсы нужно им передавать. В приведенном выше примере, еще ничего не указано. Мы вернемся к этой конфигурации снова, когда займемся сценариями. Подготовка puppet-agent.example.com:

# touch /usr/local/etc/puppet/manifests/classes/ resource_group.pp

# touch /usr/local/etc/puppet/fileserver.conf

Листинг 1.6 – Запускаем мастер-узел

# touch /usr/local/etc/puppet/manifests/classes/

# /usr/local/etc/rc.d/puppetmaster start

# touch /usr/local/etc/puppet/manifests/site.pp

# echo ‘puppetmaster_enable=”YES”’ >> /etc/rc.conf

resource_group.pp

Листинг 1.3 – конфигурация мастер-узла # puppet master --genconfig > /usr/local/etc/puppet/

Листинг 1.7 – установка агента и некоторых зависимых пакетов

# cp /usr/local/etc/puppet/auth.conf-dist /usr/local/

# make install clean

• •

puppet.conf

# cd /usr/ports/sysutils/puppet

etc/puppet/auth.conf

# cd /usr/ports/ports-mgmt/portupgrade # make install clean

factsource = puppet://puppet-master.example.com/ facts/ pluginsource = puppet://puppet-master.example. com/plugins

Листинг 1.8 – установка и конфигурация агента # hostname puppet-agent.example.com

# cp /usr/local/etc/puppet/auth.conf-dist /usr/local/ etc/puppet/auth.conf

Создадим следующие файлы с содержимым:

Листинг 1.9 – /usr/local/etc/puppet/auth.conf Листинг 1.4 – /usr/local/etc/puppet/fileserver.conf

path /run

[files]

allow puppet-master.example.com

method save

path /usr/local/etc/puppet/files allow *.example.com

Листинг 1.5 – /usr/local/etc/puppet/manifests/site.pp import “classes/*.pp”

filebucket { main: server => ‘puppet-master.example. com’ }

File { backup => main }

Exec { path => “/usr/bin:/usr/sbin/:/bin:/sbin” } node ‘puppet-agent.example.com’ { }

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

Начнем сессию подписи сертификата от Puppet агента на Puppet мастер-сервере: # puppet agent -v --server puppet-master.example.com --waitforcert 60 --test

При удачном соединении, подписываем сертификат на мастер-узле Как только сертификат подписан, сессия на агенте должна завершиться. Дождитесь, пока сам агент ее не завершит. Запустите агента на puppet-agent.example. com добавив следующее в /etc/rc.conf:

01/2012

Puppet на FreeBSD

Листинг 1.10 – Подписывается сертификат на мастер-узле # puppet cert --list --all

# puppet cert --sign puppet-agent.example.com

Листинг 1.11 – /etc/rc.conf puppet_enable=”YES”

puppet_flags=”-v --listen --server puppet-master. example.com”

Запустим агент, чтобы он мог забрать инструкции с мастера-узла: # /usr/local/etc/rc.d/puppet start

Когда мастер-узел и агент Puppet более-менее инициализирован, проверьте отсутствие сообщений об ошибках в /var/log/messages. Часть II: различные сценарии развертывания Сценарий 1 – используем Puppet для настройки конфигурации sudo на агенте На машине puppet-master.example.com создайте требуемый файл sudoers, который будет передан и развернут на Puppet агенте:

В Листинге 2.1.2 тип ресурса “файл” включен в класс под названием “sudoers”. Если какому-либо узлу требуется использовать данный ресурс, то мы можем с помощью синтаксической конструкции “include” добавить класс “sudoers” в нужный узел. Этот же ресурс может многократно использоваться и на других узлах. Так же ключевое слово “source” определяет место нахождения файла в /usr/local/etc/sudoers. Путь к файлу должен совпадать со значением параметра “[files]” из Листинга 1.4 Для получения более полной информации по типам ресурсов обратитесь к документации http://docs.puppetlabs.com/references/stable/type.html

Листинг 2.1.1 – /usr/local/etc/puppet/files/sudoers root bob joe

ALL=(ALL) NOPASSWD: ALL

Листинг 2.1.2 – /usr/local/etc/puppet/manifests/ classes/resource_group.pp class sudoers { file { “/usr/local/etc/sudoers”: ensure

=> file,

group

=> wheel,

owner

Создайте класс, который объединяет “ресурсы”: Включите “ресурс” (в классе) в “узел” (нужный Puppetагент) так, чтобы мастер-узел мог бы отправить его на агент:

ALL=(ALL) ALL

ALL=(ALL) NOPASSWD: ALL

mode

}

source

=> root, => 440,

=> “puppet:///files/sudoers”,

Активируем проведенное изменение путем “толкания” агента. Который затем самостоятельно скачает каталог изменений и совершит необходимые действия на машине.

Листинг 2.1.3 – /usr/local/etc/puppet/manifests/site.pp

# puppet kick puppet-agent.example.com

}

Как только агент получит извещение об измененных конфигурациях, он загрузит файл sudoers к себе. Проверьте /usr/local/etc/sudoers и убедитесь, совпадает ли он с тем вариантом, что мы редактировали на мастер-узле puppet-master. example.com. Этот сценарий приведен для того, чтобы показать, что Puppet действительно умеет синхронизировать конфигурации со своей главной машины с подчиненными агентами.

www.bsdmag.su

node ‘puppet-agent.example.com’ { include sudoers

Сценарий 2: Настройка и конфигурирование службы SSH Точно так же с Puppet мастер-узла можно управлять как службами, так и конфигурационными файлами. Посмотрим, как развернуть SSH-службу с её конфигурационным файлом на машине-агенте. После получения файлов, агент должен будет перезапустить службу, чтобы изменения вошли в силу.

HOWTO

Листинг 2.2.1 – /usr/local/etc/puppet/files/sshd_config PermitRootLogin no StrictModes yes PubkeyAuthentication yes PermitEmptyPasswords no Листинг 2.2.2 – /usr/local/etc/puppet/manifests/ classes/resource_group.pp class sshd { file { “/etc/ssh/sshd_config”: owner => root, group => wheel, mode => 0644, source => “puppet:///files/sshd_config”, } service { ‘sshd_services’: ensure => running, name => “sshd”, enable => true, hasrestart => true, hasstatus => true, subscribe => File[‘/etc/ssh/sshd_config’], } } Листинг 2.2.3 – /usr/local/etc/puppet/manifests/site.pp node ‘puppet-agent.example.com’ { include sudoers include sshd } На мастер-узле puppet-master.example.com создайте нужный конфигурационный файл для SSH. Обновите файл с классами, чтобы мы могли использовать новый ресурс: Аналогичным образом включаем этот ресурс и в определение узла, чтобы Puppet знал куда именно передавать конфигурацию: “Толкаем” агента Puppet, чтобы он синхронизировал информацию: # /usr/local/etc/rc.d/puppet restart

После того, как агент получил изменения, конфигурационный файл для SSH-службы должен

быть загружен на puppet-agent.example.com , а сам SSH-демон перезапуститься. Обратите внимание на параметр “ensure” в классе “sshd” ресурсного типа “service”. Он предназначен для проверки, что служба SSH работает. Параметр “subscribe” предназначен для слежения за изменением файла “/etc/ssh/sshd_config”, чтобы в случае такового Puppet на агенте перезапустил службу. Информация о других доступных параметрах приведена на сайте Puppet: http://docs.puppetlabs.com/references/2.7.6/metaparameter.html Список поддерживаемых сервисов под FreeBSD приведен на: http://docs.puppetlabs.com/references/2.7.6/type. html#service Сценарий 3: настройка и конфигурация веб-сервера Apache 2.2 В этом примере мастер-узел Puppet будет управлять агентом таким образом, чтобы последний установил Apache 2.2 и подгрузил с мастер-узла нужную конфигурацию. Затем веб-сервер на агенте будет перезапущен, для применения изменений. Создаем нужную конфигурацию для Apache на мастер-узле puppet-master.example.com Еще разок создадим нужный ресурс в классе: Как и всегда добавляем ресурс в нужный агент, чтобы мастер-узел знал куда передавать изменения: “Толкаем” агент Puppet: # /usr/local/etc/rc.d/puppet restart После обновления информации на агенте, на нем должна начаться инсталляция Apache 2.2. вместе с получением конфигурационного файла для вебсервера на узле puppet-agent.example.com, после чего будет перезапущена служба “apache22”. На эту процедуру уйдет некоторое время, т.к. операционная система FreeBSD на агенте должна будет загрузить нужный исходник через систему портов и пройти через фазу инсталляции. В этом сценарии мы встретили два новых параметра

01/2012

Puppet на FreeBSD

Листинг 2.3.1 – /usr/local/etc/puppet/files/httpd. conf ServerRoot “/usr/local”

Листинг 2.3.2 – /usr/local/etc/puppet/manifests/classes/resource_ group.pp

LoadModule authz_host_module libexec/apache22/mod_

class apache22 {

Listen 80

authz_host.so

package { ‘www/apache22’:

LoadModule include_module libexec/apache22/mod_

ensure

include.so

LoadModule log_config_module libexec/apache22/mod_log_

}

config.so

LoadModule mime_module libexec/apache22/mod_mime.so

file { “/usr/local/etc/apache22/httpd.conf”:

LoadModule dir_module libexec/apache22/mod_dir.so

Group www }

ServerName example.com:80

AllowOverride None

DirectoryIndex index.php index.htm index.html

}

LogLevel warn

DefaultType text/plain <IfModule mime_module>

TypesConfig etc/apache22/mime.types AddType application/x-compress .Z

AddType application/x-gzip .gz .tgz

AddType application/x-httpd-php .php .aspx

AddType application/x-httpd-php-source .phps

</IfModule>

Include etc/apache22/extra/httpd-default.conf Include etc/apache22/Includes/*.conf

www.bsdmag.su

enable

=> true,

=> “apache22”,

}

httpd.conf’],

Листинг 2.3.3 – /usr/local/etc/puppet/manifests/site.pp node ‘puppet-agent.example.com’ { include apache22

</IfModule>

ErrorLog “/var/log/httpd-error.log”

=> running,

subscribe => File[‘/usr/local/etc/apache22/

</Directory>

ensure

hasstatus => true,

Deny from all

Allow from all

=> “puppet:///files/httpd.conf”,

require => Package[‘www/apache22’],

hasrestart => true,

Order deny,allow

</Directory>

=> 0640,

=> wheel,

name

Order allow,deny

mode

service { ‘apache22_service’:

DocumentRoot “/usr/local/www/apache22/data”

AllowOverride None

=> root,

source

ServerAdmin webmaster@example.com

Options Indexes FollowSymLinks

owner group

User www

=> installed,

provider => ports,

include sudoers }

include sshd

для ресурсов – “provider” и “require”. Первый информирует Puppet, что он должен использовать для инсталляции программ порты (т.е. компиляцию из исходных текстов) вместо бинарных пакетов (pkg). Второй же параметр – “require” – предназначен для указания, что сначала должен быть установлен Apache22, а потом применены действия в отношении файла /usr/local/etc/apache22/httpd.conf. И только после этого, веб-служба “apache22” может быть перезапущена. Рассмотрев установку и три сценария, мы продемонстрировали, что Puppet применим для

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

В сети

Документация от Puppet Labs: http://docs.puppetlabs.com/ Изучаем Puppet: http://docs.puppetlabs.com/learning/

ОБ АВТОРЕ Edward Tan занимается администрированием пары серверов на базе FreeBSD. В свободное время пишет на разные технические темы в блоге http://psybermonkey.net, изучает Perl и раздумывает о путях развития сообщества FreeBSD.

<<TOP>>

Вы предоставляете услуги хостинга и работаете на *BSD? Разместите рекламу у нас!

www.bsdmag.su

HOWTO

Система обнаружения вторжений во FreeBSD на основе Snort Inline

Написано уже много статей по классической конфигурации Snort в режиме обнаружения вторжений (IDS, Intrusion Detection System) на разных системах семейства BSD. Однако обычно забывают упомянуть такую особенность Snort, как возможность интеграции с ipfw, что позволило бы организовать на FreeBSD встроенную систему предотвращения атак (IPS, Intrusion Prevention System). В этой статье рассматривается базовая конфигурация Snort в режиме IPS на сервере FreeBSD. Вы узнаете… • Как конфигурировать Snort в режиме IPS на сервере FreeBSD • Как установить правила в Snort для блокировки нежелательного трафика

бычно к Snort Inline относятся как к инструменту, разработанному сугубо для Linux и для интеграции с пакетом iptables. Однако, используя divert-socket можно заворачивать трафик и от ipfw, перенаправляя его для анализа на процесс, который слушает на заворачиваемом порту. Snort, а именно он будет слушать порт, будет обрабатыват пакеты в соответствии с настроенными сигнатурами. В зависимости от совпадения, Snort либо разрешит прохождение трафика, либо молча сбросит соединение или же закроет соединение с помощью TCP reset. Действие по блокировке устанавливается в каждой сигнатуре. В нашем примере рассматриваются две машины с FreeBSD 8.2, работающие в одной локальной сети.

О чем вы должны знать… • Как компилировать код из исходных текстов и устанавливать порты во FreeBSD • Базовое знание по инструментам сетевой безопасности, особенно IDS/IPS • Знакомство с ipfw

Обе работают внутри VirtualBox, одна как IPS, а другая как атакующая система (см. Рис. 1). Обе виртуальные машины должны содержать минимальный набор пакетов для i386, включая дерево портов (см. FREEBSD-INSTALL для инструкций по такой установке). Стандартное ядро FreeBSD 8.2 имеет поддержку divert-sockets, однако этот модуль должен быть явно разрешен. В Листинге 1 приводится пример, Листинг 1 Необходимая настройка в файле /boot/loader. conf для включения divert sockets echo ‚ipdivert_load=”YES”’ >> /boot/loader.conf

01/2012

Система обнаружения вторжений во FreeBSD на основе Snort Inline

Листинг 2 Установите нужные порты и загрузите Snort с поддержкой DAQ. Это позволит вам собрать программу с функцией заворачивания пакетов от ipfw. В описываемых шагах используется ключ компиляции -DBATCH и подразумеваются стандартные настройки для каждого порта. cd /usr/ports/ftp/wget

make -DBATCH install clean rehash

cd /usr/ports/textproc/flex make -DBATCH install clean cd /usr/ports/devel/pcre

make -DBATCH install clean cd /usr/ports/net/libdnet/ make -DBATCH install clean

mkdir /usr/src/snort && cd /usr/src/snort

wget http://www.snort.org/dl/snort-current/daq-0.6.2.tar.gz -O daq-0.6.2.tar.gz tar xzf daq-0.6.2.tar.gz cd daq-0.6.2 ./configure make

make install

wget http://www.snort.org/dl/snort-current/snort-2.9.2.tar.gz -O snort-2.9.2.tar.gz cd snort-2.9.2

./configure --enable-ipv6 --enable-gre --enable-mpls --enable-targetbased --enable-decoder-prepocessor-rules \

--enable-ppm --enable-perfprofiling --enable-zlib --enable-active-response --enable-normalizer --enable-reload \ --enable-react --enable-flexresp3 make

make install

mkdir -p /usr/local/etc/snort

cp /usr/src/snort/snort-2.9.2/etc/*.conf* /usr/local/etc/snort/ cp /usr/src/snort/snort-2.9.2/etc/*.map /usr/local/etc/snort/ mkdir -p /usr/local/lib/snort_dynamicrules/ mkdir -p /usr/local/etc/snort

mkdir -p /usr/local/etc/snort/rules

mkdir -p /usr/local/etc/snort/so_rules

mkdir -p /usr/local/etc/snort/preproc_rules mkdir -p /var/log/snort

mkdir -p /var/log/barnyard2

touch /usr/local/etc/snort/rules/local.rules

sed -i ‘’ “s/ipvar HOME_NET any/ipvar HOME_NET \[192.168.1.21\/32\]/” /usr/local/etc/snort/snort.conf

sed -i ‘’ ‘s/ipvar EXTERNAL_NET any/ipvar EXTERNAL_NET \[!\$HOME_NET\]/’ /usr/local/etc/snort/snort.conf sed -i ‘’ ‘s/var RULE_PATH \.\.\/rules/var RULE_PATH rules/’ /usr/local/etc/snort/snort.conf

sed -i ‘’ ‘s/var SO_RULE_PATH \.\.\/so_rules/var SO_RULE_PATH so_rules/’ /usr/local/etc/snort/snort.conf

sed -i ‘’ ‘s/var PREPROC_RULE_PATH \.\.\/preproc_rules/var PREPROC_RULE_PATH preproc_rules/’ /usr/local/etc/snort/ snort.conf

sed -i ‘’ ‘/^include \$RULE_PATH\/.*.rules$/d’ /usr/local/etc/snort/snort.conf

echo “output alert_syslog: LOG_DAEMON LOG_ALERT” >> /usr/local/etc/snort/snort.conf echo ‘include $RULE_PATH/local.rules’ >> /usr/local/etc/snort/snort.conf

www.bsdmag.su

HOWTO

make -DBATCH install clean

Чтобы показать, как Snort блокирует атаки, нам потребуется установить Apache для эмуляции сетевого сервиса, который будут атаковать. В Листинге 3 приводится фрагмент по установке Apache со стандартными настройками.

Листинг 4 - Создаем файл /etc/rc.firewall-ips (Обратите внимание, что для пропускания трафика вставлены правила для ICMP, TCP/80 и UDP/53, если же сам трафик, конечно, не заблокирован Snort)

В Листинге 5 создается нужный исполняемый скрипт для Snort, который помещается в /usr/local/etc/rc.d. Таким образом, используя настройки из /etc/rc.conf.local, Snort и apache22 будут автоматически запускаться при каждом старте.

cat << EOF > /etc/rc.firewall-ips;

В Листинге 6 приводятся необходимые строки, которые нужно добавить в файл /etc/rc.conf – именно этим механизмом будут загружаться правила для файрвола во время загрузки виртуальной машины с FreeBSD-IPS. Нужно иметь ввиду одну важную деталь при использовании divert sockets совместно с ipfw файрволом. Если Snort не будет запущен и, соответственно, некому будет обрабатывать входящие пакеты, то весь трафик будет пропущен, т.к. на divert-порт информация приходит, но ничего не перенаправляется на следующее правило в очереди ipfw.

Листинг 3 - Устанавливаем apache22 из дерева портов. cd /usr/ports/www/apache22/

ipfw -q flush

ipfw -q add 01100 divert 8000 ip4 from any to any

ipfw -q add 01200 allow tcp from any to me 22 in via em0

ipfw -q add 01300 allow tcp from any to me 80 in via em0

ipfw -q add 01400 allow udp from any to me 53 in via em0

ipfw -q add 01500 allow icmp from any to any ipfw -q add 01600 allow ip4 from any to any EOF

как включить нужную строчку в конфигурационный файл /boot/loader.conf для организации заворачивания пакетов на машине FreeBSD-IPS. В Листинге 2 приводятся необходимые шаги для построения Snort, включая небольшие изменения в стандартную конфигурацию. Плагин вывода alert_syslog используется для демонстрации способностей IPS. В реальной системе вместо него должен использоваться плагин barnyard2 для обработки вывода unified2, что генерируется самим Snort.

В нормальных условиях, в Snort-сигнатуре присутствует параметр “alert”, с помощью которого генерируется сигнал, но действия по предотвращению не производятся. Чтобы заблокировать пакет, нужно использовать параметр “block” или “drop”. В Листинге 7 приводится пример создания сигнатуры HTTP, при нахождении которой в сетевом трафике, он будет заблокирован. Перезагрузив виртуальный контейнер с FreeBSD-IPS, мы получим автостарт Apache, Snort и работающий совместно со Snort файрвол ipfw.

Рис. 1 - Сетевая архитектура вместе с Snort Inline 24

01/2012

Система обнаружения вторжений во FreeBSD на основе Snort Inline

Листинг 5 - Создаем исполняемый скрипт snort и добавляем необходимую информацию об apache22 и Snort в файл /etc/rc.conf.local.

Листинг 6 - Добавляем нужные настройки в файл /etc/rc.conf, и обеспечиваем таким образом автоматический старт ipfw.

cat << EOF > /usr/local/etc/rc.d/snort;

echo ‘firewall_enable=”YES”’ >> /etc/rc.conf

#!/bin/sh

echo ‘firewall_script=”/etc/rc.firewall-ips”’ >> /etc/ rc.conf

# \$FreeBSD\$ #

Listing 7 - Создаем сигнатуру для блокировки запроса на получение файла /etc/passwd

# REQUIRE: LOGIN

cat << EOF >> /usr/local/etc/snort/rules/local.rules;

# This signature looks for an attempt to retrieve the

# PROVIDE: snort # KEYWORD: shutdown # Add the following lines to /etc/rc.conf.local or /etc/ rc.conf

# to enable this service: #

# snort_enable (bool): #

Set it to YES to enable snort.

# snort_config (path): # #

Set to NO by default.

Set to /usr/local/etc/snort/

# /etc/passwd file with a web request.

# По этой сигнатуре проверяется весь веб-трафик на наличие запроса

# доступа к /etc/passwd

block tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_ PORTS (msg:”HTTP FreeBSD-

snort.conf

ATTACKER /etc/passwd attempt”;

by default.

flow:established,to_server;

content:”/etc/passwd”; http_uri;

nocase; classtype:attempted-admin;

. /etc/rc.subr

EOF

name=”snort”

rcvar=\${name}_enable command=/usr/local/bin/\${name} load_rc_config \$name : \${snort_enable=”NO”}

sid:2200001; rev:1;)

Листинг 8 - В командной строке приводится поведение атакующей системы FreeBSD-Attacker FreeBSD-Attacker# printf “GET / HTTP/1.1\r\nHost:

192.168.1.21\r\nUser-Agent: Netcat\r\ nContent-type: text/html\r\n\r\n” | nc -vvnn 192.168.1.21 80

: \${snort_config=”/usr/local/etc/snort/snort.conf”}

Connection to 192.168.1.21 80 port [tcp/*] succeeded!

command_args=”--pid-path /var/run --create-pidfile

Date: Sat, 17 Dec 2011 06:20:26 GMT

--daq=ipfw -Q -D -k none -c \$snort_ config”

run_rc_command “\$1” EOF chmod 555 /usr/local/etc/rc.d/snort; echo ‘accf_http_load=”YES”’ >> /boot/loader.conf

echo ‘apache22_enable=”YES”’ >> /etc/rc.conf.local echo ‘snort_enable=”YES”’ >> /etc/rc.conf.local

HTTP/1.1 200 OK

Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8q DAV/2

Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT ETag: “ba199-2c-3e9564c23b600” Accept-Ranges: bytes Content-Length: 44

Content-Type: text/html

<html><body><h1>It works!</h1></body></html>FreeBSDAttacker#

FreeBSD-Attacker# printf “GET /etc/passwd HTTP/1.1\r\

nHost: 192.168.1.21\r\nUser-Agent:

Netcat\r\nContent-type: text/html\r\ n\r\n” | nc -vvnn 192.168.1.21 80

Connection to 192.168.1.21 80 port [tcp/*] succeeded!

www.bsdmag.su

HOWTO

Листинг 9 - Сообщение о блокированной атаке от системы Snort и сохраненной в /var/log/messages Dec 17 01:20:49 FreeBSD-IPS snort[838]: [1:2200001:1] HTTP FreeBSD-ATTACKER /etc/passwd attempt [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 192.168.1.22:17123 -> 192.168.1.21:80

Теперь атакующая система FreeBSD-Attacker может попробовать запустить ping-пакеты на IPS-сенсор. Чтобы продемонстрировать работу IPS, на атакующей машине мы будем выводить сообщения с помощью команд printf и netcat, которые и сформируют HTTPзапрос для посылки на сервер Apache. В Листинге 8 приведен правильный HTTP-запрос, за которым следует попытка получить нужный файл. Первый запрос был отправлен веб-серверу Apache и от него был получен ответ HTTP 200 OK. Во втором запросе в адресное поле включена строка /etc/passwd. Этот запрос Snort заблокировал, но пропустил на обработку серверу Apache. В Листинге 9 приводится сообщение из /var/log/messages, т.к. Snort был настроен на использование syslog для сохранения лог-данных.

В сети • • • • • •

FREEBSD-INSTALL: http://www.freebsd.org/doc/handbook/install-start.html FreeBSD Snort Inline: http://freebsd.rogness.net/snort_ inline/ FreeBSD IPFW: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html FreeBSD Inline Forum Post: https://forums.snort.org/forums/support/topics/snort-inline-on-freebsd-ipfw Snort: http://www.snort.org Emerging Threats Rules: http://www.emergingthreats.net

В этой статье представлены только основы по организации совместного встроенного решения на базе Snort и FreeBSD. Сложные конфигурации могут учитывать частные сети, располагающиеся за экраном FreeBSD-IPS, защищающим таким образом эти сетевые сегменты от атак. В сегодняшнем примере мы использовали только одну сигнатуру, чтобы продемонстрировать функционал по блокировке атаки. Можно найти свободно-распространяемые в сети образцы правил, такие как Emerging Threats, а также зарегистрированные правила с сайт Sourcefire, которые вы можете задействовать для защиты собственной системы или сети от вредоносных атак.

ОБ АВТОРЕ Michael Shirk - фанатик BSD, который работает с OpenBSD и FreeBSD более 6 лет. Он работает в сообществе безопасности и занимается поддержкой открытых продуктов по безопасности, которые работают на операционных системах семейства BSD. Автор благодарит J. J. Cummings за помощь в проведении тестирования этой статьи.

01/2012

<<TOP>>

Ваш продукт основан на FreeBSD? Расскажите о нем на страницах нашего журнала! editor@bsdmag.su

www.bsdmag.su

АДМИНИСТРИРОВАНИЕ

malloc(9)

Распределитель памяти ядра общего назначения

С появлением в 1988 году версии 4.3.BSD был представлен новый механизм распределения памяти, который, как и предполагалось, будет достаточно универсальным для эффективного удовлетворения задач различных подсистем ядра, которым в свою очередь требовалось динамически размещать участки памяти. Вы узнаете… • как происходит динамическое размещение памяти ядра • что означают данные статистики ядра от команды vmstat

еред выпуском 4.3BSD в ядре уже были различные механизмы для обработки запросов на динамическое выделение памяти, но каждый специализировался на свой определенный тип размещения. Разработка новых механизмов для каждого сервиса ядра приводила к тому, что система усложнялась, а эффективность снижалась. Новый распределитель памяти – malloc(9) – пришел на смену всем другим механизмам. Его архитектура, основанная на статистике использования памяти (она же модель определенностей), оказалась эффективной как с точки зрения времени исполнения запроса, так и по размеру программного кода. Был создан один простой для использования интерфейс, схожий с функциями malloc(3) и free(3), которые присутствуют в широкоизвестной C-библиотеке. FreeBSD, NetBSD и OpenBSD всё еще используют интерфейс от malloc(9) для распределения динамической памяти ядра, хотя сейчас его использование перестало быть универсальным, как было когда-то. В настоящее время он больше используется для управления запросами на

О чем вы должны знать… • Что такое страница памяти – фиксированная часть памяти (обычно в 4Кб), используемая в системе управления памяти

выделение памяти произвольного размера. Частое выделение памяти фиксированного размера обычно контролируется пулами ядра или slabраспределителями. В этой статье приведен обзор malloc(9) и соответствующей ему функции free(9), а также объясняется как в ядре происходит динамическое управление памятью. Хотя многие высокоуровневые механизмы одни и те же в различных BSDдистрибутивах, их низкоуровневые реализации могут достаточно сильно различаться. Детальный обзор возможных реализаций для всего семейства BSD выходит за рамки статьи, поэтому будем считать, что по умолчанию говорится об системе OpenBSD, если иное не указано явно. Статистика по использованию памяти ядра доступна программам на пользовательском уровне через вызовы sysctl(3,8). Утилита vmstat вызывает sysctl для сбора нужной информации, которую потом показывает пользователю. На OpenBSD утилита systat(1) , которая также может выводить эту информацию, имеет расширенный функционал – она умеет показывать данные в динамике, по аналогии с известной утилитой

01/2012

malloc(9) - Распределитель памяти ядра общего назначения

top(1). Конкретные варианты вывода (‘views’), которые обсуждаются в ходе статьи – это ‘malloc’ и ‘buckets’ (“наборы”).

4096

Немного о том, как организована память ядра Суммарная память, доступная на какойлибо системе, разделяется на 2 части: память, предназначенная для программ в пользовательской области и память, используемая самим ядром. Последняя предназначена только для ядра и программы на пользовательском уровне доступа к ней не имеют.

Команда pagesize (1) опрашивает службу sysctl(3), для получения аппаратного размера страницы в байтах. Затем программа sysctl(1), работающая на пользовательском уровне, запрашивает количество страниц из пула malloc (vm.nkmempages). На данной системе этот пул равен 4096 * 32768 байтов (128 Мб), что, между прочим, совпадает с верхней границей. Если размер по умолчанию не годится, то он может быть статически задан при комипляции собственного ядра. Смотрите страницы помощи options(4), в частности, переменную NKMEMPAGES. Подсистемы, использующие память из mallocпула, работают в различных частях ядра – сетевое взаимодействие, файловые системы, обслуживание устройств, криптография, а также управление самим ядром. Для каждой подсистемы, что вызывает malloc(9), существует структура памяти kmemstats, которая нужна для ведения статистики и для выставления лимитов на использование памяти этой подистемой. Есть верхний предел потребления, а также счетчик, который при определенных условиях отслеживает как часто достигается этот верхний предел. Другие счетчики подсчитывают частоту вызовов malloc(9) и как много блоков памяти занято.

Та память, что доступна ядру, хранит также непрерывные разделы, которые предназначены для специфических целей. Такие разделы называются подкарты (submaps). Они используются изолированно, в отличие от остальной памяти. У них есть свой собственный механизм управления, который обеспечивает доступ к этой памяти и который может группировать различные, но сходные распределения памяти в один запрос, не смешивая их с другими, не имеющими отношения к текущему объекту. Размер таких подкарт, измеренный в страницах, всегда постоянен, поээтому может быть использован для наложения некоторых ограничений, свыше которых ядро не сможет запросить память. Подкарта kmem_map существует исключительно для динамических размещений памяти. Функции malloc(9) и free(9) являются интерфейсом к этому региону памяти и, в купе с другими низкоуровневыми инструментами, предоставляют механизм для управления им. Наиболее употребительным названием для карты kmem_map является “malloc-пул ядра”. Он создается в ходе загрузочного процесса, когда ядро инициализирует структуры, которые потребуются в процессе управления памятью. Размер этого пула зависит от машины. Также во внимание принимается размер страниц памяти, а также доступный объем памяти. На системах OpenBSD и NetBSD верхние и нижние границы по умолчанию задаются в файле /usr/ include/machine/param.h (соответственно, как NKMEMPAGES_MAX и NKMEMPAGE_MIN). На работающей машине размер может определен исходя из системного размера страницы ориентируясь затем по количеству страниц в malloc-пуле, например, как:

prompt#> sysctl vm.kmempages vm.nkmempages=32768

Реализация Единственные две функции, которые занимаются распределением и высвобождением динамически размещенной памяти – это malloc(9) и free(9). Они есть в NetBSD, FreeBSD и OpenBSD. Первая функция – malloc(9) – имеет три аргумента: размер запрашиваемой памяти, подсистема, которая запрашивает память и массив из 4 возможных флагов, три из которых обозначают, что должно произойти, если malloc(9) не удастся выделить память сразу. Рассмотрим рядовой случай, когда подсистема, делающая запрос, уже использует разрешенный для нее максимальный размер памяти. Если флаг M_WAIT установлен, то malloc(9) будет ждать, пока подсистема не вернет достаточно памяти, так, чтобы суммарное ее количество ушло ниже максимально-разрешенного предела. После чего malloc(9) проснется, и вернет требуемую память. Наоборот, с помощью флага M_ NOWAIT можно указать malloc(9) не ждать события, а сразу, сообщив об ошибке возвращая NULL.

prompt#> pagesize

www.bsdmag.su

АДМИНИСТРИРОВАНИЕ

Третий флаг – M_CANFAIL – показывает, как malloc должен сообщить об ошибке, если выставлен флаг M_WAIT, однако определенные и достаточно редкие условия мешают ему в возвратить требуемую память. Такое может произойти если в malloc-пуле нет нужного количества памяти. В этом случае malloc(9), при установленном флаге M_CANFAIL, вернет значение NULL, чтобы сигнализировать об ошибке. В противном случае, в системе произойдет паника, а также будет выведено сообщение об ошибке - “malloc: out of space in kmem_map”. Такое же сообщение может появится при запросе памяти размером больше предела ( 65535 * PAGE_SIZE ). Функция free(9) используется подсистемой для возврата памяти, которая больше не требуется. У нее есть только два аргумента: адрес возвращаемой памяти и идентификатор подсистемы, что возвращает блок памяти. Память ядра, выделяемая из распределяемой области, организована как наборы списков адресов, обычно называемых просто «наборы» (buckets). Каждый набор представляет из себя список (называемый «список свободной памяти» (free-list)) блоков памяти одинакового размера, при этом размер каждого набора кратен степени двойки, начиная с минимального размера в 16 байт и заканчивая

максимальным в 524288. Функция malloc(9) принимает в качестве аргумента размер выделяемой памяти, округляет его до ближайшей степени двойки, и выделяет блок памяти из набора (т.е. списка). Например, запрос на выделение 23 байт памяти приведет к выделению памяти из набора с размером 32 байта. Когда подсистемой вызывается функция free(), память заносится обратно в список свободной памяти соответствующего набора, чтобы ее можно было использовать вновь. Когда система инициализирует malloc-пул, то свободные списки во всех наборах обнулены. Первый вызов malloc(9) приведет к выделению памяти. Для тех наборов, что хранят указатели на объекты, размер которых меньше страницы, будет выделена из памяти и “порезана” на нужные размеры одна страница. Такое распределение памяти эффективно, в силу того, что единственный запрос на блок памяти позволяет создать несколько объектов, которые и будут мгновенно готовы к использованию. Те же buckets, где фигурируют объекты с размерами превышающими объем страницы пользы от такой оптимизации не получат. Наоброт, запрашиваемая память будет отдана подсистеме, которая инициировала запрос. Однако, при освобождении памяти, она будет помещена в свободный список соответствующего bucket, и где она будет храниться до следующего запроса. Вообще-то, страницы памяти, выделенные для каждого набора, остаются постоянно с ним связанными. Существуют специальные счетчики, которые отслеживают количество свободной памяти в наборе, но каких-либо действий по удалению страниц из набора и перемещению их в malloc-пул не предпринимается. Однако существует специальное правило для наборов, в которых фигурируют объекты размером больше, чем 2 * PAGE_SIZE. Такие объекты никогда не попадают в свободный список после вызова функции free. Наоборот, они почти сразу возвращаются в malloc-пул, откуда они могут распределены по другим наборам. Таким образом, размер свободного списка для этих наборов всегда нулевой.

Рис. 1 - Статистика, отсортированная по размеру наборов 30

При создании malloc-пула также происходит инициализация нескольких структур для управления памятью. В число таких структур входит и kmembuckets. Каждый набор имеет свою собственную структуру kmembucket, которая используется при работе со статистикой занятости памяти. Статистика по набору, которую отображает vmstat, берется непосредственно

01/2012

malloc(9) - Распределитель памяти ядра общего назначения

из этой структуры. На рисунке 1 представлена часть вывода от команды ‘vmstat -m’. Верхняя часть таблицы выводит статистику по памяти в зависимости от размера набора. SIZE - размер объектов в наборе INUSE - количество объектов из набора, которые активно используются подистемой ядра FREE - количество объектов в свободном списке REQUESTS – количество запросов из набора этого размера с начала работы HIWAT - уровень для оценки количества объектов в наборе COULDFREE – количество объектов превышающих HIWAT и которые могут быть высвобождены (для OpenBSD статистика выше получена с помощью ‘systat buckets’)

может

быть

Колонка SIZE показывает в возрастающем порядке размеры наборов. Общий объем памяти, который может быть выделен определенному набору, равняется SIZE * (FREE + INUSE). Значение для HIWAT – это количество объектов, которые могут быть размещены на одной странице, умноженное на 5 (например, на системе, где страница памяти равна 4Кб и в наборе содержатся объекты в 64 байта, значение для HIWAT будет 4096 / 64 * 5 = 320). Обратите внимание, что свободные списки в наборах для объектов размерами больше, чем 2 * PAGE_SIZE (16Кб), всегда будут (и есть) нулевые. Когда функция malloc(9) впервые была реализована в 4.3BSD, во внимание брался только факт, как

незанятая память в свободных списках может быть возвращена, при условии, что в malloc-пуле существует нехватка памяти. Собственно, для этих целей и были предложены параметры HIWAT и COULDFREE. Значение COULDFREE увеличивается каждый раз, когда объект возвращается в набор и: (1) количество объектов в свободном списке больше или равно общему количеству объектов, которые могут уместиться на одной странице; (2) количество объектов в свободном списке больше значения HIWAT. По существу, это означает, что перед вызовом функции free() должна существовать по крайней мере одна странице памяти в наборе, которая не используется и не нужна в данный момент. В оригинальной работе McKusick/Karels была изложена проблема, когда свободные списки могут стать очень большими и, следовательно, сделают память недоступной для других запросов. Однако на практике такого не случилось и ее решение отодвинули в долгий ящик. Провести анализ по всем системам, что основаны на коде 4.3BSD, не удалось, однако автор проверил исходные файлы последующих релизов BSD, а также их вариации и не нашел там кода, который бы решал эту проблему, т.е. возврат свободных, неиспользуемых страниц набора. Из-за этого значение COULDFREE никогда не уменьшается и соответствующих действий не производится. Аналогичным образом, значение для HIWAT также не используется ни для каких целей, кроме упомянутых выше. Вторая таблица вывода статистики показывает организацию памяти в зависимости от размера набора. ‘Size’ – это список наборов, а ‘Types(s)’ – различные подсистемы ядра, которые пользовались участками памяти, зарезервированными за данным набором. На рисунке 2 частично приведен вывод команды ‘vmstat -m’, которая отображает статистику по использованию памятью отсортированную по типу (т.е. подсистемам ядра) на системе, где используется страница памяти в 4Кб.

Рис. 2 - Статистика памяти, отсортированная по типу www.bsdmag.su

TYPE – тип malloc(9) в ядре или подсистемы ядра INUSE – количество наборов, используемых конкретной системой MEMUSE – общее количество памяти используемой подсистемой HIGHUSE – максимальный размер памяти, одновременно выделенной подсистеме с момента

АДМИНИСТРИРОВАНИЕ

загрузки LIMIT - максимальный размер памяти данного типа, который разрешается выделить REQUESTS – общее количество удачных запросов к malloc(9) TYPE LIMIT – количество раз, когда malloc(9) был заблокирован из-за того, что размер MEMUSE был больше константы LIMIT KERNEL LIMIT – количество заблокированных попыток, произошедших из-за того, что не осталось памяти в пуле malloc SIZES – список из размеров buckets, которые были запрошены по крайней мере один раз (на OpenBSD системах вышеприведенная статистика может быть получена с помощью команды ‘systat malloc’. В таком случае значения для MEMUSE, HIGHUSE и LIMIT будут даны в байтах). Детальная информация по используемым типам может быть найдена в макросах исходных текстов sys/ malloc. Если какая-либо подсистема не используется, либо malloc(9) не вызывается, то информация о ней в выводе не появится. Параметр LIMIT выставляется при инициализации malloc-пула. Он одинаков для всех типов, а значение зависит от размера пула. Рассчитывается как (nkmempages * PAGE_SIZE * 6 / 10). Если величина MEMUSE уже равна (или превышает) TYPE LIMIT при вызове malloc(9), то выделение памяти завершится либо ошибкой и возвращением NULL, либо же, если вызывающая подсистема может подождать, функция malloc(9) увеличит TYPE LIMIT и будет ожидать, пока какая-либо подсистема не вернет в пул достаточное количество памяти так, чтобы значение MEMUSE стало ниже LIMIT. SIZES – это просто список наборов, из которых конкретная подсистема запрашивает память. Отображаются не только текущие выделения памяти, а все, т.к. подсистема совершает свой первый вызов malloc. На OpenBSD вывод от команды vmstat отличается от такового команды systat. В последней используются вертикальные черточки (|) и точки (.) для обозначения наборов, которые отсортированы по размеру. Если вертикальная черта есть, то набор используется. В то время как точка означает, что из набора ничего пока что не было распределено. Например, “|.||..||..||....” означает, что из первого набора (16Кб) была выделена память, также как из третьего и четвертого (64Кб, 128Кб). В то время как память

свободна во втором блоке, в пятом, шестом и т.д. Параметр KERNEL LIMIT был впервые предложен в 4.3BSD. Его значение каждый раз увеличивалось, когда malloc(9) не мог добавить больше памяти в bucket, т.к. в malloc-пуле ядра больше не оставалось памяти. Следующие релизы BSD от Computer Systems Research Group ушли от практики увеличения этого параметра. В настоящий момент эта переменная всё еще есть в структуре kmemstat, но в коде NetBSD/OpenBSD больше не используется, кроме тех программ, что получают значения переменных из kmemstat (sysctl, vmstat, systat). Таким образом, она всегда равна нулю. Вывод: malloc(9) раньше и сейчас Когда malloc(9) впервые появился в 4.3BSD, предполагалось, что он заменит все другие механизмы по динамеческому распределению памяти ядра, существовавшие на тот момент. При проектировании malloc были приняты во внимание известные шаблоны использования памяти. В последующие два десятилетия с начала выхода 4.3BSD появились другие, более эффективные методы по распределению памяти: в частности, пулы памяти в ядре, slab-распределители. Системы NetBSD и FreeBSD расширили функционал, имеющийся в malloc(9), добавив некоторые функции в malloc(3). Последняя используется на уровне пользователя и основана на базе C-библиотеки. Во FreeBSD, сила двух таких стратегий используется при выделении памяти меньшего, либо равного размеру страницы. Более крупные объекты памяти округляются до следюущей страницы. Также во FreeBSD реализована работа с buckets на базе slabраспределителя. И хотя malloc(9) всё еще может использоваться в ядре NetBSD, его можно считать устаревшим и при проектировании новых сервисов ядра рекомендуется переходить на альтернативные решения по динамическому управлению памятью. Что, впрочем, увеличивает сложность.

ОБ АВТОРЕ

Paul McMath проработал в качестве Unix администратора более 10 лет в Европе и США. Он использует тот или иной BSD-вариант в качестве любимой системы с 2002 года.

01/2012

<<TOP>>

Неравнодушны к UNIX и системам на базе BSD? Поделитесь с остальными! editor@bsdmag.su

www.bsdmag.su

СОВЕТЫ И РЕКОМЕНДАЦИИ

Поддерживаем FreeBSD

и установленные пакеты в актуальном состояниии Сегодня я бы хотел коснуться такой неблагодарной темы, как поддержание в актуальном состоянии FreeBSD и установленных пакетов. Вы узнаете… О чем вы должны знать… • Как поддерживать базовую систему FreeBSD и • Как производить обновление и апгрейд её порты в актуальном состоянии базовой системы FreeBSD (смотрите главу http://freebsd.org/handbook/updating-upgrading.html из FreeBSD Handbook) • Как добавлять и удалять пакеты (смотрите man pkg_info / man pkg_add / man pkg_delete) • Как построена система портов и общие моменты их использования (см. главу http:// freebsd.org/handbook/ports.html из FreeBSD Handbook)

осле того, как я начал использовать FreeBSD во времена выхода версии 5.4 (а это 2005 год), я опробовал различные варианты обновления моих установок FreeBSD до актуального состояния. Многие из них просто не сработали, но некоторые из свежих разработок, похоже, делают свою работу на отлично, как и задумывалось. Еще некоторое время назад я думал: так, нужно зафиксироваться на версии RELEASE, и не компилировать новые версии пакетов, так как они есть на FTP в бинарном виде. Но у такого подхода существуют огромные проблемы. Во-первых, раз RELEASE уже выпущен, то в последующем выпускаются только обновления безопасности, а исправления в саму ветку RELEASE уже не вносятся. Еще хуже дела обстоят с пакетами для RELEASE,

потому что, будучи один раз выпущенными, они в последующем вообще не обновляются. Даже если в них найдены проблемы, связанные с безопасность, не говоря уже об обычных багах. Определенно, это не самый правильный путь. Решением может стать использование ветки STABLE базовой системы вместе с пакетной базой ветки STABLE, пакеты в которой пересобираются каждые 2 недели и их перекомпиляция происходит только в случае, если найдены ошибки безопасности. Правда, пройдет около, скажем, 10 дней, прежде чем бинарные версии окажутся на FTP в ветке STABLE. Чуть ниже я покажу, как организовать процесс обновления FreeBSD в самом простейшем варианте. В первой части будет идти речь о базовой системе,

01/2012

Поддерживаем FreeBSD и установленные пакеты в актуальном состоянии

а во второй – об организации обновлений пакетной базы. Важная информация о поддержке Вашей системы этим способом. Вы не будете пересобирать базовую систему каждый день, и даже каждую неделю; это делают только когда это действительно необходимо. Что означает “когда необходимо”? Например, когда найдена проблема безопасности, Вам нужно выполнить инструкции из SA (security advisory, извещение безопасности), при этом не нужно пересобирать весь мир. Единственными причинами для пересборки системы могут стать найденные в ветке STABLE баги, наблюдаемые в Вашей системе, либо же нужный Вам функционал, который был добавлен в ветку STABLE (например, из ветки CURRENT) – допустим, поддержка новой версии ZFS или что-то в этом роде. Что касается новых инсталляций, то вы можете произвести установку версии RELEASE, а затем обновиться до версии STABLE. Или же установить ежедневную STABLE-сборку, чтобы не пришлось самостоятельно пересобирать систему из исходного кода. Ежедневные ISO-образы можно найти на сервере http://pub.allbsd.org/FreeBSD-snapshots/

Часть I. Поддерживаем в актуальном состоянии базовую систему FreeBSD Некоторые сведения о базовой системе FreeBSD

RELEASE производится именно в STABLE). Если мы хотим собрать текущую версию STABLE дерева базовой системы FreeBSD, то нам потребуется получить копию дерева исходных текстов или провести обновление наших исходных тектов до актуального состояния. Удобно для этого воспользоваться воспользоваться утилитой из пакета sysutils/fastest_cvsup. Она найдет ближайший и самый быстрый сервер с исходными текстами – внимание на Листинг I.1. Для моего местоположения им оказался сервер cvsup.pl.freebsd.org, вполне понятно, что в Вашем случае будет немного по-другому. Не забывайте в следующих шагах использовать адрес ближайшего к Вам сервера. Создайте простейший файл supfile, который будет использваться утилитой csup(1) – она обновляет исходные тексты системы до нужного состояния (Листинг I.2). В директории /usr/share/examples/cvsup/ содержатся полезные примеры на тот случай, если Вы захотите углубиться в тему. Теперь давайте скачаем/обновим наши исходные тексты до текущего состояния (Листинг I.3). Имейте ввиду, что список отредактированных/проверенных файлов на вашей системе будет несколько иным, т.к. у меня уже была достаточно свежая копия исходников. Более того, на такую процедуру может Листинг I.1 – Поиск ближайшего csup (1) сервера с помощью утилиты fastest_cvsup(7)

• • • •

•

после того, как RELEASE выпущен, будут появляться только обновления безопасности, никаких исправлений ошибок ошибки исправляются в ветке STABLE обновления безопасности также производятся и в STABLE-ветке в версии RELEASE можно использовать утилиту freebsd-update для получения бинарных обновлений с исправлениями ошибок безопасности в версии STABLE для обновления потребуется перекомпилировать базовую систему FreeBSD

(Прим. перев. - Иногда в RELEASE исправляют критичные баги, например http://www.freebsd. org/security/notices.html . Следует иметь ввиду, что исправление всех остальных, возможно, не критичных, но крайне неприятных ошибок ветки

www.bsdmag.su

Speed Daemons:

- 1st: cvsup.pl.freebsd.org

- 2nd: cvsup11.ua.freebsd.org - 3rd: cvsup5.de.freebsd.org

Листинг I.2 – Создание конфигурационного файла csup (1) для обновления исходных текстов до 9-STABLE. # cat > /root/stable-supfile << EOF *default host=cvsup.pl.freebsd.org *default base=/var/db *default prefix=/usr

*default release=cvs tag=RELENG_9 *default delete use-rel-suffix *default compress src-all EOF

СОВЕТЫ И РЕКОМЕНДАЦИИ

уйти продолжительное время, особенно если у вас нет на диске установленных исходных кодов. В качестве альтернативного способа, Вы можете получить исходные тексты через SVN, но в таком случае придется установить пакет devel/subversion16. В целом, обновления исходников из svn будет быстрее и проще, нежели при использовании csup, правда, csup входит в состав базовой системы, поэтому доступен сразу, тогда как для того, чтобы воспользоваться SVN, сначала его нужно поставить из пакета – иногда это может быть хлопотным. Правда, с некоторых пор само дерево исходных текстов FreeBSD хранится в SVN-репозитории, поэтому вполне возможно, что со временем эта утилита войдет в базовую поставку FreeBSD. (Прим. перев. - В оригинальной статье, видимо, допущена ошибка - для целей работы с исходниками базовой системы FreeBSD нужно использовать порт devel/subversion-freebsd, потому что subversion из «обычного» порта, например, не раскрывает теги репозитория FreeBSD). Также следует отметить, что исходные тексты, полученные из SVN, не совместимы с теми же текстами, скачанными csup. Поэтому, если Вы решили использовать какой-то метод – используйте его до конца. Иначе придется загружать всё дерево исходных текстов FreeBSD заново. Ниже (см. Листинг I.4) приводится пример, как через SVN обновить дерево до последней версии в ветке 9-STABLE. При этом не имеет значения, загрузили ли вы дерево полностью или вчера произвели его обновление. Если svn жалуется на что-либо, то просто удалите /usr/src и запустите команду заново. Теперь, когда у нас есть исходные тексты, мы можем приступить к сборке базовой системы FreeBSD (см. Листинг I.5). Что касается редактирования конфигурации ядра, то вы можете даже не задумываться о нем, а просто использовать конфигурацию GENERIC – эта статья посвящена поддержке системы в актуальном состоянии, а не оптимизации базовой системы и компонентов ядра. Без сомнения, если вы хотите, то можете работать со своей оптимизированной конфигурацией – на задачи, изложенные в статье, это не повлияет. Также Вы можете перед строкой make buildworld…вставить

Листинг I.3. Обновляем дерево исходников FreeBSD с помощью csup(1) из базового комплекта системы # csup /root/stable-supfile

Connected to 188.125.237.138

Updating collection src-all/cvs Edit src/bin/ed/buf.c

Edit src/sbin/fsck_ffs/main.c

Edit src/sbin/mdconfig/mdconfig.8 Edit src/sbin/mdconfig/mdconfig.c Edit src/share/man/man4/ath.4

Edit src/share/man/man4/ath_hal.4

Edit src/sys/cddl/contrib/opensolaris/uts/common/fs/ zfs/zfs_vnops.c

Edit src/sys/cddl/contrib/opensolaris/uts/common/fs/ zfs/zfs_znode.c

Edit src/sys/dev/ahci/ahci.c

Edit src/sys/fs/msdosfs/msdosfs_vnops.c Edit src/sys/fs/nfsclient/nfs_clbio.c

Edit src/sys/fs/nfsserver/nfs_nfsdserv.c Edit src/sys/fs/nwfs/nwfs_io.c

Edit src/sys/fs/smbfs/smbfs_io.c

Edit src/sys/fs/tmpfs/tmpfs_vnops.c

Edit src/sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c Edit src/sys/kern/uipc_usrreq.c Edit src/sys/kern/vfs_vnops.c

Edit src/sys/nfsclient/nfs_bio.c Edit src/sys/sparc64/sbus/sbus.c Edit src/sys/sys/vnode.h

Edit src/sys/ufs/ffs/ffs_inode.c Edit src/sys/ufs/ffs/ffs_vnops.c

Finished successfully

префикс nice -n 20, что понизит приоритет выполнения пересборки и система будет более отзывчивой во время процесса. После завершения процедур, ваша система перезагрузится. Мы переходим ко второй фазе процесса обновления (см. Листинг I.6). После нормальной загрузки (однопользовательский режим не требуется и определенно не рекомендован во время удаленного обновления), остановите все ненужные сервисы (помните про необходимость оставить SSH, если работаете по сети). Если ваша система нормально загрузилась, то вы можете сделать ваше новое тестовое ядро используемым по-умолчанию. По крайней мере, если вы использовали GENERIC конфигурацию ядра, проблем возникнуть не должно ;)

01/2012

Поддерживаем FreeBSD и установленные пакеты в актуальном состоянии

Список запущенных процессов (см. Листинг I.7) может выглядеть приблизительно так, включая (или не включая) sshd(8) для работы по сети. Теперь мы можем продолжить (см. Листинг I.8) чтобы завершить обновление. Команда mergemaster (8) спросит Вас о том, что нужно сделать с различиями в скриптах запуска и конфигурационных файлах, если Вы их изменяли. Нажмите ‘I’ для установки новой/ стандартной конфигурации, либо нажимайте ‘D’, чтобы Листинг I.4. Обновляем дерево исходных текстов FreeBSD с помощью svn (1) из пакета devel/subversion16 # svn checkout svn://svn.freebsd.org/base/stable/9 / usr/src

/usr/src/usr.bin/grep/util.c

/usr/src/share/man/man5/rc.conf.5

U U

U U U

U U

/usr/src/usr.bin/grep

/usr/src/share/man/man5

/usr/src/share/man/man9/driver.9 /usr/src/share/man/man9

/usr/src/usr.sbin/mergemaster/mergemaster.sh /usr/src/usr.sbin/mergemaster /usr/src/lib/libc/stdtime

U U

# cd /usr/src

/usr/src/lib/libpam

# make buildworld kernel KODIR=/boot/testing

/usr/src/lib/libpam/modules/pam_ssh/pam_ssh.c /usr/src/etc/network.subr /usr/src/etc/devd.conf /usr/src/etc

/usr/src/sys/sparc64/pci/schizo.c

# rm -r -f /usr/obj

# nextboot -k testing # shutdown -r now

/usr/src/sys/kern/sys_generic.c

Листинг I.6. Делаем новое ядро используемым по-умолчнию и останавливаем ненужные сервисы

/usr/src/sys/netinet6/nd6.c

# cd /boot

/usr/src/sys/contrib/pf

# mv kernel OLD

/usr/src/sys/contrib/pf/net/pf.c /usr/src/sys/amd64/include/segments.h /usr/src/sys/amd64/include/xen

/usr/src/sys/amd64/include/trap.h /usr/src/sys/amd64/amd64/trap.c

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

/usr/src/lib/librt

/usr/src/lib/librt/timer.c

/usr/src/sys/netinet/tcp_reass.c

(Прим. перев. - Внезапно, автор говорит это после того, как предполагает, что у Вас что-то пошло не так, возможно, вы угробили свою систему. Всегда дочитывайте статьи до конца, прежде чем начать).

Листинг I.5. Собираем базовую систему FreeBSD

/usr/src/sys/kern/vfs_syscalls.c

После этой второй перезагрузки у Вас должно быть STABLE-дерево базовой системы FreeBSD. Я написал “должно быть” из-за того, что иногда некоторые вещи идут совсем не так, как мы планировали, особенно, если вы делаете это в первый раз. Как поется у Aerosmith – “Я знаю, это общий грех, Вам нужно проиграть, чтобы узнать как побеждать”. Хорошей идеей будет потренироваться в VirtualBox или QEMU, выполняя сегодняшние задания в виртуальной копии FreeBSD.

/usr/src/lib/libc

/usr/src/sys/kern/kern_ctf.c

оставить ту версию, что уже у Вас работает. Запомните, что вы можете сделать эти замены позднее. Также не желательно устанавливать настройки по-умолчанию для файрвола или OpenSSH при обновлении по сети.

/usr/src/sys/sys/bus.h /usr/src/sys

Checked out revision 228452.

www.bsdmag.su

# rm -r -f OLD

# mv testing kernel

# killall dhclient moused # /etc/rc.d/cron stop # /etc/rc.d/devd stop # /etc/rc.d/sshd stop

# /etc/rc.d/powerd stop

# /etc/rc.d/syslogd stop

СОВЕТЫ И РЕКОМЕНДАЦИИ

PACKAGESITE, чтобы она указывала на http://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/ Latest/, по крайней мере для систем FreeBSD 9.x. (Прим. перев. - Обратите внимание, что это основное зеркало FreeBSD, ветка 9-STABLE для 64-битных систем. Вы должны выбрать свое FTPзеркало, версию и разрядность).

Часть II. Поддерживаем в актуальном состоянии пакетную базу FreeBSD Держать пакеты в актуальном состоянии немного сложнее, и нам также потребуется для работы с пакетами ветка STABLE, т.к. в RELEASE они не обновляются. Давайте предположим, что вы установили FreeBSD STABLE из снапшота месяц назад, а заодно

Листинг I.7. Ограничьте необходимым минимумом количество процессов во время обновления # top -b

last pid: 64835;

load averages:

0.00,

119 processes: 2 running, 117 sleeping

0.00,

0.00

up 0+03:11:51

10:24:37

Mem: 960M Active, 355M Inact, 4014M Wired, 6096K Cache, 8368K Buf, 2527M Free Swap:

PID USERNAME

2178 root

THR PRI NICE

SIZE

RES STATE

0 10304K

2748K ppwait

6912K

1284K ttyin

6912K

2174 root

1 1

2177 root 2176 root 2175 root

1 1

114 root

45 76 76 76

0 21696K 0 0

6912K 2764K

1992K wait

1284K ttyin 1284K ttyin 1056K pause

TIME

0:00

0 0 1 0 0

WCPU COMMAND

0:00

0.00% csh

0:00

0.00% getty

0:00 0:00 0:00

0.00% login 0.00% getty 0.00% getty

0.00% adjkerntz

Листинг I.8. Устанавливаем свежесобранную базовую систему # cd /usr/src

# mergemaster -p

# make installworld # mergemaster -iU # make delete-old # shutdown -r now

Листинг II.1. Функция ports-check function ports-check {

# Загрузить последний снимок дерева портов sudo portsnap fetch update

# Проверить, для каких пакетов достыпны новые версии

sudo portmaster -L --index-only | awk ‘/ [Nn]ew / {print substr($0,9,9999)}’ # Загрузить новую базу и проверить установленные пакеты на наличие уязвимостей sudo portaudit -Fda

# Проверить /usr/ports/UPDATING }

pkg_updating -d $( ls -ltr -D ‘%Y%m%d’ /var/db/pkg | awk ‘END{print $6}’ )

01/2012

Поддерживаем FreeBSD и установленные пакеты в актуальном состоянии

Листинг II.2. Функция ports-update

Extracting new files:

/usr/ports/chinese/c2t/

function ports-update {

# Обновить все пакеты либо только один, используя STABLE case ${#} in

ветку на FTP

/usr/ports/polish/hunspell/

ports|/var/db)” ;;

/usr/ports/textproc/es-mythes/

(*) sudo pkg_upgrade -C $@ 2>&1 | grep --color=none

/usr/ports/textproc/nl-mythes/

--line-buffered -E “^(=+>|/usr/

/usr/ports/textproc/sk-mythes/

ports|/var/db)” ;;

/usr/ports/textproc/sl-mythes/

Building new INDEX files... done. New version available: arc-5.21p

# Исправить зависимости при необходимости

New version available: ca_root_nss-3.12.11_1

sudo portmaster --check-depends

New version available: expat-2.0.1_2 New version available: tinyxml-2.6.2 New version available: bash-4.1.11

Листинг II.3. Функция ports-build

New version available: gstreamer-plugins-0.10.35_1,3 New version available: gtk-2.24.6

function ports-build {

New version available: gtk-update-icon-cache-2.24.6

# Пересобрать один, группу или все порты

New version available: libsamplerate-0.1.8_1

case ${#} in

(0) sudo portmaster -y --no-confirm -m ‘BATCH=yes’ -d -a ;;

(*) sudo portmaster -y --no-confirm -m ‘BATCH=yes’ -d esac

$@ ;;

New version available: nas-1.9.3

New version available: nettle-2.4

New version available: p5-Date-Manip-6.25

New version available: p5-Mail-IMAPClient-3.29 New version available: p5-XML-Parser-2.41 New version available: xterm-273

New version available: filezilla-3.5.1

# Исправить зависимости при необходимости }

/usr/ports/devel/p5-System-Command/ /usr/ports/math/p5-Statistics-R/

--line-buffered -E “^(=+>|/usr/

}

/usr/ports/devel/Makefile

/usr/ports/german/mythes/

(0) sudo pkg_upgrade -C -a 2>&1 | grep --color=none

esac

/usr/ports/chinese/hc/

New version available: firefox-6.0.1,1

sudo portmaster --check-depends

New version available: gtk-oxygen-engine-1.1.2 New version available: nginx-1.0.6,1

New version available: qemu-0.11.1_10

Пример II.1. Примерный вывод о доступности новых/обновленных пакетах и их версиях

20 have new versions available New database installed.

Database created: Thu Sep

% ports-check

1 21:20:00 CEST 2011

0 problem(s) in your installed packages found.

Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found.

Fetching snapshot tag from portsnap5.freebsd.org... done. Fetching snapshot metadata... done. Updating from Mon Sep

5 07:11:28 CEST 2011 to Mon Sep

08:51:01 CEST 2011.

Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 10 patches.....10 done. Applying patches... done.

Fetching 1 new ports or files... done.

Removing old files and directories... done.

www.bsdmag.su

СОВЕТЫ И РЕКОМЕНДАЦИИ

Пример II.2. Отчет, в котором также отображены проблемы с безопасностью

New version available: nas-1.9.3

New version available: nettle-2.4

New version available: p5-Date-Manip-6.25

% ports-check

Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found.

Fetching snapshot tag from portsnap1.freebsd.org... done.

Fetching snapshot metadata... done. Updating from Mon Sep

5 10:28:51 CEST 2011 to Mon Sep

5 12:07:23 CEST 2011.

Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 0 metadata files... done.

New version available: p5-Mail-IMAPClient-3.29 New version available: p5-XML-Parser-2.41 New version available: xterm-273

New version available: filezilla-3.5.1 New version available: firefox-6.0.1,1

New version available: gtk-oxygen-engine-1.1.2 New version available: nginx-1.0.6,1

New version available: qemu-0.11.1_10 20 have new versions available auditfile.tbz

69 kB

54 kBps

Fetching 20 patches.....10....20 done.

New database installed.

Fetching 1 new ports or files... done.

Affected package: ca_root_nss-3.12.9

Applying patches... done.

Removing old files and directories... done. Extracting new files: /usr/ports/MOVED

/usr/ports/Mk/bsd.sites.mk /usr/ports/cad/Makefile

/usr/ports/devel/Makefile

/usr/ports/devel/p5-Bread-Board-Declare/ /usr/ports/devel/p5-Curses-UI/ /usr/ports/devel/p5-Data-Peek/

/usr/ports/devel/p5-Scope-Upper/ /usr/ports/dns/pear-Net_DNS2/

Database created: Mon Sep

100% of

5 12:35:01 CEST 2011

Type of problem: ca_root_nss -- Extraction of unsafe certificates into trust bundle..

Reference: http://portaudit.FreeBSD.org/1b27af46-d6f611e0-89a6-080027ef73ec.html

Affected package: ca_root_nss-3.12.9

Type of problem: nss/ca_root_nss -- Fraudulent

Certificates issued by DigiNotar.nl.

Reference: http://portaudit.FreeBSD.org/aa5bc971-d63511e0-b3cf-080027ef73ec.html

/usr/ports/lang/p5-Try-Tiny/

2 problem(s) in your installed packages found.

/usr/ports/math/p5-Math-BigInt/

You are advised to update or deinstall the affected

/usr/ports/mail/p5-Email-Valid/ /usr/ports/math/p5-Statistics-Descriptive/ /usr/ports/net/pear-Net_SMTP/

package(s) immediately.

/usr/ports/ports-mgmt/portaudit-db/ /usr/ports/sysutils/py-supervisor/ /usr/ports/sysutils/zfsnap/ /usr/ports/www/nginx-devel/ /usr/ports/www/nginx/

/usr/ports/www/rubygem-passenger/ /usr/ports/x11/Makefile

Building new INDEX files... done. New version available: arc-5.21p

New version available: ca_root_nss-3.12.11_1 New version available: expat-2.0.1_2 New version available: tinyxml-2.6.2 New version available: bash-4.1.11

New version available: gstreamer-plugins-0.10.35_1,3 New version available: gtk-2.24.6

New version available: gtk-update-icon-cache-2.24.6 New version available: libsamplerate-0.1.8_1

01/2012

Поддерживаем FreeBSD и установленные пакеты в актуальном состоянии

Пример II.3. Решаем проблемы с безопасностью путем пересборки нужного пакета % ports-build ca_root_nss ===>>> Currently installed version: ca_root_nss-3.12.9 ===>>> Port directory: /usr/ports/security/ca_root_nss (...)

===>>> Updating dependency entry for ca_root_nss-3.12.11_1 in each dependent port ===>>> Upgrade of ca_root_nss-3.12.9 to ca_root_nss-3.12.11_1 complete % ports-check

Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found. Fetching snapshot tag from portsnap2.freebsd.org... done. Fetching snapshot metadata... done. Updating from Mon Sep

5 12:07:23 CEST 2011 to Mon Sep

Fetching 3 metadata patches.. done.

5 12:25:09 CEST 2011.

Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 2 patches.. done. Applying patches... done.

Fetching 0 new ports or files... done.

Removing old files and directories... done. Extracting new files:

/usr/ports/devel/p5-File-NFSLock/

/usr/ports/devel/p5-MooseX-Aliases/ Building new INDEX files... done. New version available: arc-5.21p

New version available: expat-2.0.1_2 New version available: tinyxml-2.6.2 New version available: bash-4.1.11

New version available: gstreamer-plugins-0.10.35_1,3 New version available: gtk-2.24.6

New version available: gtk-update-icon-cache-2.24.6 New version available: libsamplerate-0.1.8_1 New version available: nas-1.9.3

New version available: nettle-2.4

New version available: p5-Date-Manip-6.25

New version available: p5-Mail-IMAPClient-3.29 New version available: p5-XML-Parser-2.41 New version available: xterm-273

New version available: filezilla-3.5.1 New version available: firefox-6.0.1,1

New version available: gtk-oxygen-engine-1.1.2 New version available: nginx-1.0.6,1

New version available: qemu-0.11.1_10 19 have new versions available auditfile.tbz

New database installed.

Database created: Mon Sep

100% of

69 kB

54 kBps

5 12:40:01 CEST 2011

0 problem(s) in your installed packages found.

www.bsdmag.su

СОВЕТЫ И РЕКОМЕНДАЦИИ

Пример II.4. Обновляем установленные пакеты с помощью STABLE-ветки

===> Update <nettle-2.2> to <nettle-2.4> (security/ nettle)

=> Update <nas-1.9.2> to <nas-1.9.3> (audio/nas)

% ports-update

/var/db/uma/FTPINDEX

100% of

/usr/ports/packages/All/nettle-2.4.tbz

100% of

/usr/ports/packages/All/gtk-2.24.6.tbz

100% of

21 MB 1139 kBps 00m00s 1082 kB

332 kBps

9822 kB

253 kBps 00m00s

4091 kB

942 kBps

succeeded

===> Update <libsamplerate-0.1.7_1> to

<libsamplerate-0.1.8_1> (audio/ libsamplerate)

=> Update <libsamplerate-0.1.7_1> to

<libsamplerate-0.1.8_1> (audio/ libsamplerate) succeeded

/usr/ports/packages/All/gstreamer-plugins-0.10100% of

===> Update <expat-2.0.1_1> to <expat-2.0.1_2>

/usr/ports/packages/All/gtk-oxygen-engine-1.1.100% of

=> Update <expat-2.0.1_1> to <expat-2.0.1_2> (textproc/

/usr/ports/packages/All/filezilla-3.5.1.tbz

===> Update <xterm-271> to <xterm-273> (x11/xterm)

509 kB

339 kBps

3301 kB

232 kBps 00m00s

100% of

/usr/ports/packages/All/nas-1.9.3.tbz

100% of

/usr/ports/packages/All/expat-2.0.1_2.tbz

100% of

/usr/ports/packages/All/xterm-273.tbz

100% of

487 kB

494 kBps

130 kB

129 kBps

262 kB

104 kBps

184 kB

381 kBps

225 kB

206 kBps

/usr/ports/packages/All/p5-XML-Parser-2.41.tbz100% of /usr/ports/packages/All/nginx-1.0.6,1.tbz

100% of

/usr/ports/packages/All/qemu-0.11.1_10.tbz

100% of

/usr/ports/packages/All/tinyxml-2.6.2.tbz

100% of

12 MB

170 kB

359 kBps 00m00s 121 kBps

/usr/ports/packages/All/p5-Date-Manip-6.25.tbz100% of 1301 kB

681 kBps

===> Update <tinyxml-2.6.1_1> to <tinyxml-2.6.2>

expat2) succeeded

=> Update <xterm-271> to <xterm-273> (x11/xterm) succeeded

===> Update <qemu-0.11.1_9> to <qemu-0.11.1_10> (emulators/qemu)

=> Update <qemu-0.11.1_9> to <qemu-0.11.1_10>

(emulators/qemu) succeeded

===> Update <p5-XML-Parser-2.40> to <p5-XML-Parser-2.41> (textproc/p5-XML-Parser)

=> Update <p5-XML-Parser-2.40> to <p5-XML-Parser-2.41> (textproc/p5-XML-Parser) succeeded

===> Update <gtk-update-icon-cache-2.24.5> to <gtk-

update-icon-cache-2.24.6> (graphics/ gtk-update-icon-cache)

=> Update <gtk-update-icon-cache-2.24.5> to <gtk-updateicon-cache-2.24.6> (graphics/gtkupdate-icon-cache) succeeded

===> Update <gtk-2.24.5_1> to <gtk-2.24.6> (x11toolkits/gtk20)

(textproc/tinyxml)

=> Update <gtk-2.24.5_1> to <gtk-2.24.6> (x11-toolkits/

(textproc/tinyxml) succeeded

===> Update <gtk-oxygen-engine-1.1.1> to <gtk-oxygen-

=> Update <tinyxml-2.6.1_1> to <tinyxml-2.6.2>

===> Update <p5-Mail-IMAPClient-3.28> to <p5-Mail-

IMAPClient-3.29> (mail/p5-MailIMAPClient)

=> Update <p5-Mail-IMAPClient-3.28> to <p5-Mail-

IMAPClient-3.29> (mail/p5-MailIMAPClient) succeeded

===> Update <p5-Date-Manip-6.24> to <p5-Date-Manip-6.25> (devel/p5-Date-Manip)

=> Update <p5-Date-Manip-6.24> to <p5-Date-Manip-6.25> (devel/p5-Date-Manip) succeeded

===> Update <nginx-1.0.5,1> to <nginx-1.0.6,1> (www/

gtk20) succeeded

engine-1.1.2> (x11-themes/gtk-oxygenengine)

=> Update <gtk-oxygen-engine-1.1.1> to <gtk-oxygen-

engine-1.1.2> (x11-themes/gtk-oxygenengine) succeeded

===> Update <gstreamer-plugins-0.10.35,3> to <gstreamerplugins-0.10.35_1,3> (multimedia/ gstreamer-plugins)

=> Update <gstreamer-plugins-0.10.35,3> to <gstreamerplugins-0.10.35_1,3> (multimedia/ gstreamer-plugins) succeeded

nginx)

===>>> Checking 2bsd-vi-050325_1

succeeded

(...)

=> Update <nginx-1.0.5,1> to <nginx-1.0.6,1> (www/nginx)

(textproc/expat2)

01/2012

Поддерживаем FreeBSD и установленные пакеты в актуальном состоянии

тогда же собрали и пакеты. Теперь у многих пакетов появились новые версии, что в целом неважно, но для некоторых могут (и возможно есть) исправления, связанные с безопасностью. И вот эти пакеты следует обновить. Конечно, вы можете скомпилировать их из портов с помощью portmaster (8), но зачем тратить время на компиляцию, когда вы можете взять готовые бинарные сборки, что появляются каждые 2 недели в ветке STABLE?[5] Скрипт под названием pkg_upgrade (1) из пакета sysutils/bsdadminscripts может хорошо послужить в таком бинарном обновлении. Он загрузит самые последние версии пакетов со STABLE FTP, и есть большие шансы в том, что в этих новыз версиях ошибки с безопасностью уже решены. Если же они не решены, то тогда конечно применяйте portmaster (8). В любом случае, намного быстрее и лучше скомпилировать только 1-2 пакета вместо 30 и даже более. (Прим. перев. - Указанное верно, если вы ранее установили программы из пакетов, либо собирали порты с опциями по-умолчанию. Если порт был собран с переопределением опций, его придется пересобрать, либо отказаться от переопределенных в порте опций. См. “Недостатки” в конце статьи). Что касается обновлений пакетов, я обычно проверяю их ежедневно, в основном по причинам, связанным с безопасностью, узнать о которых можно с помощью утилиты portaudit (1) (из пакета ports-mgmt/portaudit). Информация о новых версиях приходит часто, иногда даже в очень большом объеме, но пока 0 problem(s) in your installed packages found суетиться не стоит. Время от времени, я запускаю pkg_upgrade -a -C для получения с FTP свежих пакетов ветки STABLE. Некоторые из вас могут спросить - зачем использовать pkg_upgrade (1) вместо обновления с помощью portmaster(8)? Что я могу сказать – представьте, что у Вас в системе установлен пакет z-1.0, самый свежий пакет, доступный на FTP – это z-1.1 и z-1.2, поэтому portmaster (8) пропустит версию z-1.1 вне зависимости является он более новым или нет. И будет компилировать z-1.2 из дерева портов. Коротко об обновлении пакетов FreeBSD • используйте пакеты из ветки STABLE, которые пересобираются каждые 2 недели • используйте утилиту pkg_upgrade (1) для

www.bsdmag.su

•

обновления пакетов используйте утилиту portmaster пересборки пакетов, у которых проблемы в безопасности

(8) для найдены

Несколько фактов об обновлении пакетов FreeBSD •

•

пакеты собираются для каждого нового выпуска в ветке RELEASE, и в этой ветке они не обновляются (даже если в новой версии пакета устранена проблема безопасности) пакеты в ветке STABLE пересобираются каждые 2 недели

Во-первых, мы должны установить инструментарий, которым мы будем обновлять пакеты. # pkg_add -r bsdadminscripts portmaster portaudit

По желанию, мы можем разрешить пользователям группы wheel выполнять задачи по обновлению, используя утилиту sudo (8) из пакета sysutils/sudo, которую можно установить, выполнив pkg_add –r sudo. Так как этим пользователям уже разрешено поднимать привелегии до уровня суперпользователя (root), то мы, конечно же, можем создать еще и отдельную группу (например, maintainers), состоящим в которой разрешается проводить обновление. Для этого Вам потребуется добавить следующую строку в конец файла /usr/local/etc/sudoers %wheel ALL=NOPASSWD: /usr/sbin/portsnap, /usr/local/sbin/pkg_upgrade, /usr/local/sbin/portmaster, /usr/local/sbin/portaudit [7] (Прим. перев. - Указанное разрешает выполнение portsnap, etc пользователям в группе wheel через выполнение sudo portsnap… без ввода рутового пароля, а совсем не то, что у автора описано!) Здесь начинается самая важная часть – команды сгруппированы в функции таким образом, чтобы позволить нам в простой форме проверить наличие новых версий пакетов, выявить проблемы безопасности и в конце-концов обновить их до новой или исправленной версии. Функция ports-check загружает последний снимок дерева портов, затем показывает, для каких установленных в системе пакетов доступны новые версии. После чего пакеты проверяются на наличие проблем с безопасностью, с помощью portaudit(8) и, наконец, проверяется файл /usr/ports/UPDAT-

СОВЕТЫ И РЕКОМЕНДАЦИИ

ING на наличие различных сообщений, которые могут быть нам интересны. Функция ports-check (см. Листинг II.1) не перестраивает и не обновляет пакеты, а, как понятно из названия, только проверяет. (Прим. перев. - Команда sudo portsnap fetch update загрузит последний снимок дерева портов и применит различия к имеющемуся в системе дереву, так что собрать порт предыдущей версии будет не так просто. Помимо этого, если вы не выполнили рекомендацию из прим. 7 и/или пользователь, запускающий скрипт, не состоит в группе wheel, может потребоваться один или несколько раз ввести пароль root). Вторая функция – ports-update – предназначена для обновления пакетов (см. Листинг II.2) из ветки STABLE. В функции используется утилита pkg_upgrade (1) из пакета sysutils/bsdadminscripts. Компиляция из портов производиться не будет. Вы можете использовать эту функцию в двух вариантах – вызванная без аргументов она обновит все пакеты, которые будут найдены в STABLE FTP. Но, как показано в Примере II.5, она может быть также использована для пересборки только конкретных пакетов, которые требуется обновить. Например, ports-update openbox nautilus xterm. Последняя функция (см. Листинг II.3), названная ports-build, пересобирает определенный пакет или все из них, если вы не задали имена пакетов явно. (Прим.

перев.

этом

варианте

функция

Пример II.5. Обновляем одиночный пакет % ports-update openbox

===> Update <openbox-3.5.0> to <openbox-3.5.0> (x11wm/openbox)

=> Update <openbox-3.5.0> to <openbox-3.5.0> (x11-wm/ openbox) succeeded

... и в целом, это всё, что я хотел рассказать. Некоторые примеры использования этих функций приведены к конце статьи. Чтобы можно было вызвать эти функции, внесите их в свои шеллпрофили – для sh(1) и bash(1) это будет файл / etc/profile, для zsh (1) - /etc/zshrc. Для C-образных шеллов, например, csh(1) они работать не будут, т.к. они не поддерживают функции и являются устаревшими оболочками по нескольким аспектам: http://www.grymoire.com/Unix/CshTop10.txt Недостатки Применяя такой подход по актуализации пакетов, вы должны имеет ввиду две вещи. Нетиповые пакеты. Если Вы собрали некий пакет с нестандартными опциями, используемыми при компиляции, то после обновления пакет “вернется” к стандартным значениям. Поэтому Вам придется перекомпилировать его снова так, как нужно именно Вам. Модули ядра. Любой пакет, содержащий модули ядра, и который теоретически (и скорее всего) на практике может “развалиться” из-за того, что ветка STABLE – это всё время развивающийся проект, логически приводит нас к выводу, что сначала нужно обновить базовую систему, а после обновить пакеты. Наиболее часто используемые пакеты, в которых присутствуют модули ядра – emulators/virtualbox-ose (VirtualBox), sysutils/fuse-kmod (реализация FUSE) и самый примечательный – x11/nvidia-driver (бинарные графические драйвера для Nvidia-карт). Вот и всё! ;)

(...)

ОБ АВТОРЕ

===>>> Checking nss-3.12.11

===>>> Checking open-motif-2.3.3 ===>>> Checking openbox-3.5.0

===>>> No installed ports depend on openbox-3.5.0

===>>> Emptying +REQUIRED_BY file. portmaster -s

пересобирает все указанные пакеты, без проверки на security problems. Кроме того, пакеты пересобираются с портов, а не как указано выше no compilation. portmaster --packages)

Try

Slawomir Wojtczak (vermaden) просто еще один системный администратор, который интересуется UNIX- и BSD-системами (в основном, FreeBSD), но которому часто приходится работать и с Linux. Приверженец принципа KISS (Keep-it-simple-Stupid, Делай короче и проще). Активно троллит на многих форумах, посвященным BSD, UNIX и Linux.

01/2012

БЕЗОПАСНОСТЬ

Анатомия компрометации FreeBSD (часть 2) Продолжаем серию статей, в которых мы рассматриваем случаи, когда “плохие парни” хотят получить доступ к системе, и что мы можем сделать для снижения рисков. Вы узнаете… • Как планировать стратегию безопасности

предыдущей статье мы осветили некоторые причины, по которым серверы и системы сами по себе не могут быть защищенными от атак, а также почему невозможно гарантировать 100% защиту для любой системы. В этой части мы проверим несколько общеизвестных техник для получения контроля на системой, а также противодействующие им механизмы. Векторы атак Что же такое вектор атаки? Проще говоря – это метод, с помощью которого хакер получает доступ к ресурсам или данным, хранимым на сервере, ПЭВМ или же путешествующим по сети. Стандартное определение подразумевает лишь атаки, основанные на различных технологиях, например Cross Site Scripting (XSS), вредоносное ПО, фишинг и т.п., но это лишь одна сторона проблем информационной безопасности. Хотя и очевидно, что если вы обнаружили на компьютере червей, значит вы подверглись атаке, тем не менее в стандартном определении не учитывается множество других обстоятельств. Например, если атакующий получил физический доступ к компьютеру, когда тот не был заблокирован, скопировал важный документ на USB-флешку и при этом оригинальный документ остался без изменений, то в таком случае можно считать, что атака произошла. Именно поэтому я бы для определения атаки предпочел использовать более широкое определение, в которое входят физический доступ, социальный инжиниринг и воровство/подделка средств идентификации

О чем вы должны знать… • Навыки администрирования BSD

личности. В отличие от классического “технического” определения, где мы зажаты рамками битов и байтов, мир все-таки немного разнообразнее. Если вы посмотрите на мир IT безопасности, то вы откроете, что множество инцидентов может быть отнесено к группе – “Почему же я не смог увидеть этого раньше?”. По этой причине мы должны уважительно, хотя и с неохотой, относиться к взламывающим. Зачастую, метод доступа к информации является просто нестандартным решением, ловкостью рук или же прыжком через ограничения системы, в которых она находится – она же выполняет только те инструкции, которые в нее заложены, не глядя на этическую сторону проблемы. Будучи разработчиком, системным администратором и т.п., вы должны добавить моральный аспект к ее действиям, так как у компьютеров пока еще нет сознания! Некоторые сценарии взлома Для иллюстрации главных принципов, предлагаю рассмотреть следующие гипотетические атаки. Если они будут производиться опытным хакером или экспертом по безопасности (учитывая, что у них достаточно ресурсов), то ваши данные будут скомпрометированы во всех этих сценариях. Сможете выяснить как именно? И хотя многие из них надуманы, но все потенциально возможны. И я надеюсь, что эти примеры помогут читателю взглянуть на это со стороны. Ответы приведены в конце статьи.

01/2012

Анатомия компрометации FreeBSD (часть 2)

Атака 1 ЭВМ на вашем рабочем столе не подключена к сети и вы работаете в типовом офисе, что располагается на 11-м этаже. Вы решаете, что для повышения продуктивности работы и обеспечения безопасности нужно поставить ПО распознавания голоса – тогда не только документы будут создаваться быстрее, но также можно будет организовать защищенный доступ к операционной системе. Все ваши данные зашифрованы, а клавиатуру вы не так уж и часто используете, поэтому кейлоггеры (аппаратные или программные) атакующему вряд ли помогут. Программа распознавания голоса сертифицирована по высшему классу, либо известно, что в ней отсутствуют уязвимости. Всем вашим коллегам вы полностью доверяете и они к безопасности относятся ответственно. Кроме того, они не имеют ни малейшего понятия над чем вы работаете. Офис и окна на ночь закрываются. Однако в прессу попадает крайне секретный документ, над которым работали только вы и у вас была единственная копия. Т.к. вы определенно не подозреваете ваших коллег в таком поступке, то вы должны предоставить начальству объяснение, как атакующий получил доступ. Проверяя логи, вы обнаруживаете, что взламывавший ваш компьютер работал в понедельник, 7 утра. Скопировал файл используя ваши права, причем ошибок при распознавании голоса или попыток подбора кодов не было. Офис регулярно проверяется на “жучки”, а использование мобильных телефонов / записывающих устройств строго запрещено. Как атакующему удалось перехватить ваши парольные данные? Атака 2 Кто-то из старшего руководства звонит и просит сбросить его пароль. Служба IT-поддержки сбрасывает его на стандартный, так, чтобы сам пользователь смог поменять его на нужный при первом вхоже в систему. Чуть позже, в этот же день, после проведения совещания руководство включает ПЭВМ и выясняет, что все файлы были удалены с жесткого диска. Что произошло? Атака 3 Все персоналки работников подключены к корпоративной сети. Директор рассылает всем электронное письмо, что с сегодняшнего дня зарплата увеличивается на 15%. К сожалению, директор не указал обратный свой адрес. Изучая заголовки письма выясняется, что письмо пришло с компьютера директора, но в тот момент его не было на работе, а его

www.bsdmag.su

пользовательский аккаунт в целости и сохранности. Как такую ситуацию можно смоделировать?

Важность физической безопасности и защиты периметра Многие администраторы воспринимают как должное тот факт, что серверы должны располагаться в безопасном месте, желательно в дата-центре с пожарной защитой, резервным питанием, температурным контролем и с ограничением по доступу. Однако, очень часто, все остальное не принимается во внимание. В частности, автору сильно не нравится как проектируются современные здания, где используются фальш-полы с проложенными там сетевыми кабелями CAT5/6/7, а также кабелями питания. Изначально их использовали как удобную замену монтажу по стене, но автор считает, что в таком виде они предоставляют удобный способ доступа к инфраструктуре. И если в старых системах достаточно было навесить дополнительный замок или прикрепить болты безопасности к роутерам или сетевым коробам, чтобы ограничить несанкционированный доступ, и в таком случае достаточно было лишь визуального контроля отсутствия “лишних” устройств; то размещение сетевых устройств в фальш-полах никак нельзя признать безопасным. Очень часто доступ к этим полам не охраняется для облегчения работы службы эксплуатации, и даже если доступ к фальш-полу под контролем – сами панели достаточно легко снять. Также во многих датацентрах, из-за нехватки места или ради удобства, автор видел монтаж роутеров и других устройств под фальш-полом. Такое размещение можно найти и в офисном пространстве. С помощью специального устройства “вампирчик” (см. Википедиа, “Vampire tap”) можно подключиться к коаксиальному кабелю и пассивно снимать информацию – такое устройство в сети будет не видно. А используя аккумуляторы от мобильного устройства, можно снимать данные в течение нескольких часов. Но это для особо умных взламывателей. Вариант попроще – разрезать CAT5 кабель с помощью инструмента по обрезке кабелей и с помощью нескольких коннекторов, а также пары дополнительных проводов сесть на сетевой кабель. Основная проблема – как уложить ковровое покрытие, чтобы оно не топорщилось и скрывало проникновение в кабельную инфраструктуру. Следующая проблема – это использование CD/USB устройств и кейлоггеров. Раз хакеру удалось получить физический доступ к устройству, то появляются

БЕЗОПАСНОСТЬ

дополнительные возможности по перехвату нешифрованных данных. Пользователи должны быть приучены к хранению данных на сетевом диске, однако очень часто важная информация хранится на локальных жестких дисках, а доступ к ним можно получить с помощью такой утилиты как Trinity, если, конечно, разделы не зашифрованы. Пароль же локального администратора для большинства популярных операционных систем можно сбросить определенной утилитой, загрузившись с CD или же USB-брелка. Преимущество метода загрузки с USB заключается в том, что данные раздела можно переписать на сам брелок, при этом никаких нарушений дисковой структуры не будет. Кроме того отследить такое воровство не представляется возможным, если конечно преступник не будет пойман за руку, или же его действия не будут записаны на видео. Этот же метод по идее может быть использован для кражи личных данных. Несмотря на то, что важная информация пользователя хранится на сетевых ресурсах, браузеры могут сохранять логи и пароли пользователей для доступа к интернет-сайтам и т.д. В зависимости от изобретательности разработчиков веб-браузера, полученные личные данные можно привязать к CPU ID используемого пользователем компьютера (если он на базе процессоров от Intel), но у меня нет сведений, существует ли такая атака. Другая распространенная форма атаки – это кейлоггеры, которые записывают коды нажатых пользователем клавиш. С ростом интернета, количество программных кейлоггеров стало достаточно большим, однако можно найти и аппаратные устройства. Степень угрозы в данном рассматриваемом случае высока, т.к. весь ввод с клавиатуры, а это имена, пароли, документация и тексты писем, находится под угрозой. Программное обеспечение, которое контролирует использование USB (и злоупотребление ими), широкодоступно, но вопрос должен рассматриваться с той точки зрения, нужно ли вообще предоставлять пользователям доступ к ним или нет. К сожалению, достаточно использовать USB-хаб для получения дополнительных портов, кроме того современные компьютеры используют USBклавиатуры и мыши, поэтому отключать USB-кабель от материнской платы (или же заливать разъемы эпоксидной смолой, как было кем-то предложено) не будет хорошей затеей, и единственное, что тут возможно - спрятать системный блок в ящике или корпусе, который ограничивает физический доступ к портам. Далее, существуют видео-захватчики,

которые перехватывают и записывают снимки экрана на специальное устройство. Есть даже видео-кабели, в которые встроена функция видео-захвата, при том что внешне они не отличимы от обычного кабеля. И, наконец, у нас есть варианты с вклиниванием в сетевую инфраструктуру – просто втыкается мини-хаб или свитч между ЭВМ и сетью. Т.к. свичи сейчас достаточно “умные” и могут осуществлять разбиение на разные VLAN и зоны, то получить весь корпоративный трафик не получится, однако на данном конкретном сегменте сети информация может быть скомпрометирована.

Безопасность связанная с культурой Здесь живет социальный инженер – хакер с навыками обращения с людьми. Забудем на время электронную форму социального инжиринга (фишинг, распространение вредоносного кода, поддельный запрос на восстановление пароля и и т.п.), и сфокусируемся на на человеческой стороне атаки. Тут не всегда можно провести чёткие границы и иногда хакеру требуется самая малость, чтобы получить себе преимущество (например, если жертва является фанатом Chicago Bulls, то есть хороший шанс, что пароль у него будет “basketball”). Большая часть атак этого типа возможна из-за отсутствия чувства подозрительности, излишней наивности или же человеческой слабости жертвы (как пример может служить спам-рассылка с предложением финансового “вознаграждения” от третьей стороны, пытающейся “получить” деньги из какой-либо страны), так что жертва не понимает масштаба преступления пока не зашло слишком далеко. В некоторых случаях, жертва может быть просто козлом отпущения на пути к истинной цели атакующего, например, когда стараются заполучить технический пароль с неограниченным доступом, чтобы вытащить данные других пользователей. Иногда в этих атаках участвует и инсайдер (например, для выдачи данных о кредитных картах за пределы компании-эмитента), а так как инсайдер намеренно пытается обмануть компанию, то они вместе будут проводить манипуляции по маскировке, чтобы их действия не были обнаружены и не были запущены процессы по пресечению их деятельности. Чаще всего реальные ошибки допускаются сотрудниками, однако и «чутьё» может служить хорошим критерием в некоторых случаях. Если база данных скомпрометирована, и нет никаких свидетельств, что это результат программной атаки,

01/2012

Анатомия компрометации FreeBSD (часть 2)

небрежности, либо внешнего вмешательства – тогда у сотрудника безопасности возникает проблема. Хотя есть необходимые инструменты, которые помогают отследить и проанализировать данные и доступ к ним, тем не менее очень трудно смириться с фактом, что какой-либо сотрудник может потенциально быть замешан в совершении преступления, и нужно очень тщательно всё проанализировать, чтобы на непричастного не свалилось ложное обвинение или клевета. Вот почему компании и организации пытаются замять внутренние разбирательства: не столько из-за боязни урона репутации, сколько из-за того, что большая часть коллектива не воспримет ту сложность расследования инцидента внутри большой организации. Риск может быть снижен за счет введения принципа доступа к системе по принципу “хочу знать” (см. “В сети”), и регулярно проводимых аудитов. Но даже тогда наличие неудовлетворенных сотрудников, плохая рабочая атмосфера и корпоративный подход “невмешательства” к проблемам безопасности не сделает жизнь проще. Иногда, в случае внутреннего подлога, нарушитель теряет голову и может наделать ошибок, не принимая во внимание такие вещи, как серьёзные финансовые проблемы, проблемы во взаимоотношениях с коллективом или же собственные привычки. В таких обстоятельствах полиция будет вашим лучшим союзником, но не надо также забывать простое правило – расследование должно полагаться на факты, а не на косвенные улики. Когда атака проводится извне, то с коммерческой точки зрения может быть очень трудно быстро изолировать источник проблемы. Т.к. социальный инжиниринг на самом деле является уловкой, а большинство компаний работают на доверии и открытом взаимодействии в ходе рабочего процесса, то лучшим способом уменьшения риска будет обучение. Большая часть пользователей с радостью позволили бы коллегам воспользоваться USBпортом их персоналок, но если порты заблокированы (или физически недоступны), сразу же возникает следующий вопрос – разрешили бы они такое действие внешнему консультанта или “эксперту”, с которым нет дружеских взаимоотношений? Большинство людей склонны доверять авторитетному мнению, и если хакер умудряется произвести должное впечатление, то упомянутое доверие будет получено им автоматически. Kevin Mitnick, исправившийся хакер, о таком отношении говорил предельно ясно – проще заполучить доступ с помощью социального искусства, нежели производить полноценный взлом. Таким

www.bsdmag.su

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

Безопасность в программных продуктах Это и есть классическая интерпретация того, что является вектором атаки. У хакеров есть тысячи различных эксплойтов, которые можно разбить на 4 концептуальные категории. Иногда атакующий рассчитывает использовать несколько уязвимостей, и, кроме случая если система совсем уж не защищена, ему приходится использовать несколько техник для получения доступа. Например, атаковавший мой FreeBSD сервер использовал техники из категорий 2 и 3. Слабая конфигурация системы Вероятно, это самая очевидная дырка в системе, которую просто закрыть; она подразумевает массу упущений, начиная с пренебрежения учетными записями с пустыми паролями и заканчивая ненужными запущенными сервисами на сервере. Наряду с хорошей практикой, устранение этих очевидных дыр уменьшает площадь атаки. Надо учитывать и то, что есть определенные приложения и сервисы (например, telnetd), которые настолько небезопасны, что их вообще не следует запускать. ПО работающее как надо Утверждение может показаться парадоксальным, но почти все DDoS-атаки используют этот принцип. Ваш веб-сервер предназначен для обработки HTML-страниц, поэтому у хакера появляется мысль - “Как я могу взломать сервер нагрузив его сверх меры?” Такая атака может быть отражена с помощью хорошего архитектурного решения, балансировки нагрузки, используя патчи и регулируя количество одновременных запросов. Однако в таких распределенных средах как интернет, если ваш сервер атакуется ботнетом (сетью скомпрометированных машин) бывает чрезвычайно трудно разделить хороший и паразитный трафик, особенно когда сам бот-нет находится в разных частях света. Ботнет Alureon, состоящий из 4.5 миллионов машин, хороший

БЕЗОПАСНОСТЬ

пример для этого. От него не поможет ни хороший канал связи, ни высокопроизводительные сервера при длительной атаке. DDoS – страшное оружие. Вы можете уменьшить риск, но полностью предотвратить его при указанных обстоятельствах у вас вряд ли получится. Самое лучшее, что вы можете сделать – это производить мониторинг трафика на наличие плохих запросов и предпринимать противодействующие меры, когда атака начинается. Плохой дизайн Всегда хорошо заводить с разработчиками беседы на тему – является часть кода “багом” или “фичей”. Такой код может быть в любом месте операционной системы и нет такой программы, которая бы его не содержала. С наилучшими намерениями в голове, разработчик может написать качественный код, но он будет зависеть от внешних библиотек или же самой ОС, написанными, в свою очередь, другими. И таким образом, контроль над ситуацией уходит из под рук самого разработчика. Например, ситуация с C-функцией strcpy, которая не проверят выход за пределы массива, и является общепринятой мишенью для атак по переполнению буфера. Хорошие программисты применяют “защитную тактику” (т.е. пишут код, который обрабатывает такие ситуации, как выход за пределы массива), но иногда в игру вступают некоторые нюансы. Пример тому – форумы с использованием HTML, где пользователям дается возможность вставлять в свои комментарии HTMLкод. Но что будет, если кто-то вставить вредоносный javascript или XSS-код? Как отличить “расширенную функциональность” от “потенциальной угрозы”? Хотя я верю, что такие проблемы могут быть выявлены при адекватном тестировании (например, с помощью ввода произвольных данных, тестирование на проникновение и т.д.), однако по мере развития индустрии, всё больше таких уязвимостей будет

выявляться. Именно в этот момент в игру должны вступать и вступают сами разработчики. Вот почему автор всегда будет опираться на open-source продукты и на *BSD. При детальном рассмотрении оказывается, что открытость в отношении проблем безопасности и желание решить этот вопрос правильно, были движущей силой в сообществе свободного ПО. Отсюда и происходит такое явное стремление по обеспечению качества кода и его безопасности. Производители коммерческих продуктов, с другой стороны, работают полагаясь на принцип “мы вам даем только то, что вам нужно знать”. И часто требуемые заплатки выходят с опозданием, т.к. такая операция не приносит прибыль, либо же может внести в существующую систему слишком значительные разрушения позже. Когда я начинал работать на заводе электроники в конце 1970х, такого инструментария как автоматизированная контрольно-измерительной аппаратура (Automated Test Equipment, ATE) не было и величина брака была высокой. Теперь же использование КИА – нормальная практика, при этом брак незначителен. Если мы посмотрим на безопасность под другой точкой зрения, то ботнет хакеров с его брутфорс попытками можно рассматривать как программный эквивалент КИА – проверять одну технологию другой технологией на надёжность. Вот здесь у свободного ПО явное преимущество перед коммерческими продуктами. У нас есть нужная гибкость и изобретательность, чтобы ответить на угрозу творчески и быть в авангарде. Если кто-то отказывается думать, что безопасность – это проблема, касающаяся всех, то в определенный момент он сам окажется под ударом.

В сети • • • • • • • • • •

Профессиональные лазерные микрофоны: http://www.argoasecurity.com/product_detail.aspx?productID=880 Рабочий концепт для вышеизложенного метода: http://www.ehow.com/how_5969176_make-laser-listening-device.html Ethernet taps: http://www.janitha.com/archives/146 Кейлоггер: http://www.keydemon.com Видео-захват: http://www.keydemon.com/tiny_frame_grabber/ Trinity Rescue CD: http://trinityhome.org Уникальные CPUID номера для процессоров Intel: http://www.intel.com/support/processors/pentiumiii/sb/CS-007579.htm Решения для обеспечения безопасности персональных компьютеров: http://www.pc-safe.co.uk Ботнет Alureon: http://arstechnica.com/security/news/2011/07/4-million-strong-alureon-botnet-practically-indestructable.ars Укрепляем Apache. Хотя и старая статья, но есть ряд здравых мыслей: http://www.techrepublic.com/article/protect-your-apache-server-from-dos-attacks/5058830

01/2012

Анатомия компрометации FreeBSD (часть 2)

Ответы Атака 1 Используя лазерный микрофон, атакующий сканировал окно вашего офиса и записывал внутренние разговоры. Затем всё зависит от методов социальной инженерии, чтобы убедить уборщика помещения разрешить ему войти в помещение. Для большей убедительности, он показывает уборщику, что он может войти в ваш компьютер, в котором используется голосовое распознавание. К сожалению, программа распознавания не смогла уловить его региональный акцент, однако разрешила доступ, т.к. распознала правильные слова и фразы. Используя специальные преломляющие пленки или стекло, можно заблокировать намертво такой тип атаки (что и применяется в некоторых секретных службах и посольствах)

На заметку Информация, содержащаяся в этих статьях предназначена для системных администраторов, чтобы помочь улучшить безопасность системы. Во то время как тестирование и выявление уязвимостей в ваших собственных персональных системах в целях повышения безопасности является совершенно законным в Великобритании, законодательство может отличаться в других частях мира. Работодатели могут принимать дисциплинарные и/или юридические меры против работников, если эти инструменты используются на рабочем месте без разрешения. Иcпользование этих инструментов по отношению к сторонним системам без разрешения считается не только неэтичным, но и является незаконным во многих странах. Автор и BSD Magazine не оправдывает неэтичный или незаконный взлом.

Атака 2 На рабочих местах IT-службы не применяется достаточное количество механизмов по идентификации личности. Атакующий воспользовался рабочим телефоном менеджера, пока его не было на месте, и позвонил в IT с запросом сброса пароля. Так как, поддержка не может определить менеджера, кроме как по номеру телефона, то никто дополнительно не озаботился личностью звонящего. Как только доступ к системе получен, атакующий без проблем удалил файлы на локальном диске. Угроза такой атаки может быть снижена путем выдачи каждому пользователю индивидуального пароля для звонков в IT-службу, и который известен только пользователю и самой ITслужбе. Атака 3 SMTP-сервер не использует аутентификацию. Подделав MAC- и IP-адрес директорского компьютера, атакующий смог зайти на порт 25 почтового сервера и обмануть собеседника в ходе переписки. Такая ситуация вполне типична на многих серверах интернет-провайдеров, а сфабриковать подложные письма в пределах одного домена достаточно тривиально. Решить проблему на внутренних почтовых серверах очень просто, но в пределах внешней сети – затруднительно.

www.bsdmag.su

ОБ АВТОРЕ

Rob Sommerville неравнодушно относился к технологиям с детства. Ярый сторонник открытых систем с середины восьмидесятых, он проработал во многих корпоративных секторах, включая финансовый, автомобильный, авиаиндустрии, правительственный и СМИ. Был во множестве ролей - начиная от технической службы поддержки, системного администратора, разработчика и заканчивая системным интегратором и IT-менеджером. Вышел из мира CP/M и газоразрядных ламп, однако хранит паяльник под рукой, на всякий случай.

ПОГОВОРИМ

Слоны в Прато В прошлом году, 25 ноября, группа поддержки проекта PostgreSQL организовала в Прато пятую ежегодную конференцию PostgreSQL Day (PGDay).

ля организации этого мероприятия итальянской группе пользователей PostgreSQL (ITPUG) потребовалось 6 месяцев. И хотя стаж у конференции достаточно мал (в первый раз она была организована в 2007), тем не менее она уже стала обязательным событием для итальянского сообщества. После 2 лет отсутствия в Прато организаторы решили вернуться в то место, где первоначально был дан старт конференции – исследовательский центр Университета Монаша. Две конференции были проведены в Пизе и Риме, но пятую решено было снова провести именно здесь. Причём вовсе не из-за того, что предыдущие были неудачными, вовсе нет. Просто организаторы чувствовали себя в Прато как дома, более того – большинство активных членов ITPUG живут рядом с этим городом. Краткая характеристика события Мероприятие, по сути, началось вечером накануне с банкета, где угощали шедеврами местной кухни (в частности, хорошо известным флорентийским стейком) и вином. В неформальной атмосфере вы могли пообщаться не только с участниками местного сообщества, но также и с зарубежными делегатами, которые, не смотря на совершенно разные навыки и образование, сидели все вместе за одним столом. Такая организация мероприятия наполняет организаторов гордостью, т.к. назначение конференции не только продвижение PostgreSQL как продукта, но и развитие связей в сообществе. На следующий день началась собственно сама конференция и атмосфера стала более формальной. Каждый участник, после прохождения регистрации,

мог выбрать одну из двух параллельных секций – ориентированную либо на администраторов баз данных, либо же более подходящую для разработчиков. Президент группы ITPUG – Gabriele Bartolini – от лица собравшихся поприветствовал гостей и озвучил цели конференции. Прежде чем передать микрофон в зал, несколько слов были сказаны представителем местной городской администрации, который подчеркнул, насколько важным стало OpenSource движение в Италии и как оно развивается с каждым днем. Основной доклад был сделан президентом PostgreSQL Europe – Magnus Hagander. Он представил все новые функции, появившиеся в новом релизе 9.1, а также некоторые из следующего релиза за номером 9.2. Речь была произнесена в потрясающем зале Grollo, который на всех произвел впечатление своим изяществом. После доклада, был сделан кофебрейк, что позволило гостям немного отдохнуть, переговорить, а также осмотреть сам университет Монаша. И

только

после

этого

началась

настоящая

PGDay в числах Конференцию посетило почти 100 участников – что считается достаточно большой цифрой, учитывая то, что это примерно половина участников конференции PostgreSQL Europe. Было 25 выступлений общей сложностью примерно 15 часов.

01/2012

Слоны в Прато

История проведения PGDay Первая официальная конференция PGDay в Италии была организована компанией волонтеров, включая самого автора, в 2007 году. На тот момент, пользовательской группы ITPUG вообще не существовало. Конференция привлекла внимание нескольких других PostgreSQL сообществ, включая PostgreSQL-группу пользователей из Японии (JPUG), а также, в качестве специальных гостей, нескольких ключевых разработчиков базы данных. Организаторы достаточно быстро поняли, что событие нужно расширять, и делать двухдневную конференцию, вместо однодневной. Воодушевленные успехом от проведенной конференции, организаторы затем решили создать специальную группу итальянских пользователей PostgreSQL – организацию, которая будет распространять сведения об PostgreSQL по всей Италии, обеспечивая поддержку пользователей и предприятий, организовывая различные мероприятия, обеспечивать перевод и развитие инструментария, связанного с PostgreSQL и т. д. Следующая конференция PGDay, организованная уже ITPUG, была двухдневной и работала в качестве как итальянского, так и общеевропейского официального события. Она дала толчок к созданию PGeu – европейской комиссии по аналогии с ITPUG, но работающей на европейском уровне. Все следующие мероприятия был отмечены как строго итальянские, что, впрочем, не означает, что были только посетители из Италии. Фактически, сегодня PGDay-Italy – это хорошо известное и зарекомендовавшее себя событие, которое привлекает каждый год участников международного сообщества, а также членов команды развития проекта. конференция. Докладчики выступали по графику в двух параллельных сессиях: администраторская часть проводилась в Grollo-зале, а разработчики - в Venice-зале. Описание каждого выступления выходит за рамки данной статьи; заинтересовавшиеся могут загрузить презентационный материал с официального сайта

www.bsdmag.su

конференции (см. “В сети”). Для галочки же могу сказать – во время всего дня шли разговоры о будущем PostgreSQL, шли бои сторонников NoSQL против реляционных баз данных (иногда называемых как Yes-SQL), разговоры об инструментах репликации и резервного копирования, обсуждались способы эффективного использования CTE (Common Table Expressions) и способа обращаться к внешним данным изнутри экземпляра объекта PostgreSQL. Было также обсуждение, посвященное безопасности, в частности, как безопасно хранить пароли внутри базы данных. В следующие дни дискуссии велись о том, как подключаться к PostgreSQL с помощью различных языков программирования, и как писать новые модули к самой базе данных, используя эти языки. Последним по порядку, но не по значению, было обсуждение использования PostgreSQL на различных уровнях, начиная с предприятия и вплоть до уровеня местной администрации. Утро закончилось отличным ужином, накрытом в одной из зал университета. Кроме отдыха и наслаждения едой, трапеза также позволила гостям дополнительно пообщаться друг с другом. Организаторам было очень приятно видеть, как люди обмениваются мнениями, обсуждают проблемы и решения, и т.д. Другими словами – обмениваются опытом. Я сильно убежден, что именно такие мероприятия делают OpenSource движение экстраординарным, т.к. привлекают людей к различным проектам. В свою очередь, чем больше людей участвуют в проекте, тем сильнее проект может эволюционировать Блиц-доклад, который прошел после ужина, был действительно интересен с учётом представленных презентаций и краткого описания накопленного опыта. Правило проведения блица простое – на представление аргументированной позиции есть не более пяти минут, а затем вы должны уступить место следующему докладчику. Почти все блиц-доклады были техническими, но было также приятно увидеть и ряд нетехнических. В частности, некоторые нетехнари рассказали о прошедших мероприятиях, а также их опыте, который они приобрели, став членами PostgreSQL сообщества – начиная от составителей документации и вплоть до коммитеров. Мне кажется, такие разговоры должны вестись в большем объеме, т.к. люди зачастую опасаются начинать сотрудничать с проектом из-за опасения плохо сделать задуманное или боясь того, что их будут постоянно оценивать.

ПОГОВОРИМ

В сети Официальный сайт PGDay 2011 – http://www.pgday.it Веб-сайт ITPUG – http://www.itpug.org Официальный сайт PostgreSQL – http://www.postgresql.org Наоборот, как было отмечено в ходе этих блицев, каждый может начать вносить свой вклад почти на любом уровне. И чем больше вы привносите, тем большим экспертом вы становитесь в данной отрасли, и тем больше (надеюсь) будете увлечены проектом! После сессии блиц-докладов, конференция опять разбилась на два потока, которые потом завершились в Grollo-зале. Я имел честь официально объявить о завершении конференции. Обратившись ко всем участникам с краткой речью, я поблагодарил, прежде всего, сотрудников ITPUG и тех добровольцев, которые помогли нам в организации такого замечательного события, а затем и всех тех, кто приехал к нам. Как обычно, я упомянул и о том, как важен для PostgreSQL и, в частности, для ITPUG постоянный приток активных участников, с целью поддержки как проекта, так и итальянского сообщества. И, конечно, я выразил надежду увидеть всех снова в следующем году на новом дне PostgreSQL!

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

По традиции, мое заключительное слово завершило конференцию, но не само мероприятие. Через несколько минут почти все участники и организаторы переместились в паб, где расслабились за классным пивом Гиннес, предоставленным золотым спонсором мероприятия – компанией 2ndQuadrant. Я был приятно удивлен тем, сколько участников конференции осталось на неофициальную часть, что только подтверждает тот факт, насколько важна для пользователей, разработчиков и неравнодушных людей общая команда и возможность общения об их любимой базе данных. В конце конференции организаторы обычно подводят итоги – это, без сомнения, был успех. Что интересно, количество компаний, которые участвуют в конференции, постоянно увеличивается. А этот год показал, что компании больше не смотрят на PostgreSQL как на альтернативное решение, по отношению к закрытым базам данным, а используют его в качестве основного решения. В качестве финальной ноты – если у вас есть возможность, я советую вам не пропустить следующую

ОБ АВТОРЕ Luca Ferrari живет вместе с женой и сыном в Италии. Он является адъюнкт-профессором в Nipissing University (Канада), а также сооснователь и вицепрезидент итальянской группы пользователей PostgreSQL (ITPUG). Ему просто нравится OpenSource культура, поэтому он отказывается работать с не UNIX-системами. Найти его вы можете по адресу http://fluca1978.blogspot.com

01/2012

В следующем выпуске: • Продолжение серии по безопасности • Балансировщики нагрузок • Работа с PostgreSQL • и многое другое!