Предисловие

Задание

АННОТАЦИЯ

ВВЕДЕНИЕ

1. Описание О.С “Solaris”

1.1 Быстродействие системы

1.2 SMF: Средства обслуживания сервисов

1.3 Надежность ПО

1.4 Зоны и Контейнеры (Solaris Containers)

1.5 Управление правами процессов

1.6 Ролевой доступ

1.7 Защита от атак, использующих переполнение буфера

2. Установка и настройка О.С. “Solaris”

2.1 Необходимые параметры Установки О.С. “Solaris”

2.2 Установка прикладного Soft’a

2.2.1 GCC компилятор

2.2.2 Файловый менеджер MC

2.3 Настройка О.С. “Solaris” после установки или выгребаем все не нужное

2.3.1 Огненная Стена

2.4 Оптимизация сетевого стека TCP/IP

3 почтовый сервер.

3.1 Выбор почтового сервера

3.2 Выбор дополнительного программного обеспечения

3.2.1 Выбора сервера баз данных

3.2.2 Выбор антивирусной защиты

3.2.3 Библиотека авторизация Cyrus SASL 2.x

3.2.4 POP3 Сервер

3.2.5 Ведение квот

3.3 Установка Серверов

3.4 Описание почтового сервера Postfix

3.4.1 Архитектура Работы Postfix

3.4.2 Описание процессов работы сервера Postfix

3.5 Защита сервера Postfix встроенными средствами

3.5.1 Защита от атак из вне

3.5.2 Защита от DOS, DDOS, СПАМА

3.7 Итог проделанной работы

3.8 Тестирование сервера Postfix

4. ВИРТУАЛИЗАЦИЯ Зон и Контейнеров (Solaris Containers)

4.1 Описание технологии:

4.2 Технолошия зон

4.2.1 Конфигурирования не глобальной зоны

4.2.2 Сборка зоны

4.2.3 Запуск зоны

4.3 Тестирование почтового сервера Postfix в не глобальной зоне z_postfix.

Global + z_postfix

4.4 Технология Контейнеров (Ресурс Менеджер).

4.5 Управление ресурсами CPU

4.5.1 Метод Fair Share Scheduler (FSS)

4.5.2 Настройка метода FAIR SHARE SCHEDULER (FSS).

4.6 Разделение ресурсов оперативной памяти

4.6.1 Установка ограничений на использования оперативной памяти

4.7 Тестирование почтового сервера Postfix в не глобальной зоне z_postfix с разграничением ресурсов.

5. Взлом системы

Предисловие

Немного истории. В декабре 2004 года я заканчивал 4 курс института транспорта и связи факультет программирования время неумолимо котилось к защите, и передо мной встал не лёгкий выбор темы дипломной работы. К этому времени я уже проработал системным администратором в двух крупнейших компаниях Латвии около 3х лет.За это время я заинтересовался Unix О.С. Долгое время проработал с FreeBSD, а так же с некоторыми дистрибутивами Linux’a.Ну и соответственно тему диплома хотел взять из этой области, что ни будь связанное с защитой сетевых сервисов от атак. При настройки серверов, к примеру apache, sendmail, mysql и.т.д. я всегда ставил их в родную chroot оболочку О.С.

грубо говоря псевдо виртуализация. Для темы диплома я хотел взять намного больше, чем просто FreeBSD+sendmail+chroot, мне требовалась виртуализация без слова “псевдо”. На тот момент было несколько вариантов:

1. виртуальная машина XeN только для Linux или NetBSD

2. Virtual Linux Server для Linux и сейчас портирован на FreeBSD

3. Virtuozzo для большинства Unix

Я не буду попросту разводить канитель, что лучше Linux или *BSD, но лично мне линукс не очень нравился по этой причине я сразу отбросил 2 вариант. Ставить NetBSD и изучать XeN машину тоже не очень хотелось. По поводу viruozzo это мощная вещь, но только комерчиское использование делало не возможным нахождение бесплатной версии.

Ну и тут я наткнулся на статью, в которой описывались будущие возможности О.С. Solaris 10. В ряду с которыми была заметка о 1N grid Containers виртуализация. Я сразу заинтересовался этим вопросом, в конце концов, было решено тема диплома будет связана именно с Solaris 10 и технологией Containers.Тут встала другая задача как и чем тестировать данную технологию? Вариантов было масса, но я сразу решил что из той кучи преподов, что будет на защите дай боже чтоб вообще 2 человека поняли о чем будет работа (в конечном итоге понял только 1ч.), по этой причине было решено выдрать гланды через жопу, то есть сделать с нуля велосипед.

Так все же о чем эта работа позже переписанная в статью. О мощном почтовом сервере с массой вкусностей и прелестей и с должной защитой, так как паранойя правит настоящим админом. С разу хочу оговориться я не претендую на премию лучшая публикация года, но завистливой и бездарной критики я не потерплю, лишь справедливой и дополняющей. Статья рассчитана на людей, которые уже имеют неплохой опыт работы с юниксом и хотели бы познакомится с Solaris 10, а так же я многие моменты рассматривать не буду ввиду их тривиальности с моей точки зрения.

Поехали....

Задание

Цель работы заключается в следующем:

• разработка почтового сервера с перечисленными возможностями:

1. С высокой производительностью более 1000000 писем в сутки

2. Интегрированным с базами данных для хранения информации

   • пользовательские данные: пароли доступа, имя доступа;

   • информации о почтовых ящиках: размер почтового ящика, время создания;

   • информация о доменах;

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

3. С активной защитой от вирусов, с пассивной защитой от спама.

4. С защитой от атак на почтовый сервер средствами самого сервера, с защитой от DOS, DDOS атак.

5. Возможностью пересылки почты только авторизовавшимся пользователям.

• Создание многоуровневой системы защиты от атак из вне на основе изолированных виртуальных машин в операционной системе “Solaris 10”. Анализ целесообразности затрат ресурсов системы при работе почтового сервера в изолированной виртуальной среде.

АННОТАЦИЯ

“Создание безопасного высоко производительного почтового сервера с использованием технологии виртуализации для защиты сервера”

Скорость обработки сообщений почтовым сервером, затраты ресурсов системы при большой нагрузке почтового сервера, Настройка ИЗОЛИРОВАННОЙ виртуальной машины для работы почтового сервера, Анализ ЭФФЕКТИВНОСТИ работы почтового сервера как в ИЗОЛИРОВАННОЙ виртуальной машины так и без неё.

В данной работе создается высоко производительный почтовый сервер с интегрированной системой хранения информации в базе данных, проверкой на вирусы и с защитой от спама, а также создается многоуровневая система защиты сервера от атак из вне средствами самого почтового сервера и операционной системы. Проводится исследования ресурса ёмкости систем безопасности, производительности почтового сервера и операционной системы. С помощью новой технологии “1N Grid Containers” разрабатывается и создается виртуальная зона, в которой будет работать почтовый сервер с антивирусной защитой. Проводится тестирования почтового сервера при работе в оболочке виртуальной машины и при работе без виртуальных машин, анализируется затраты ресурсов на виртуальную машину. Производится анализ исходных показателей, и на основе выявленных результатов теста делается вывод об эффективности и защите сервера с помощью виртуальных машин.

ВВЕДЕНИЕ

В современном мире вопросы информационной, компьютерной или сетевой безопасности стоят, чуть ли не на первом месте в рейтинге основных проблем не только в высоко развитых странах, но и у большинства людей связанных с информационными технологиями. В связи с этим моя работа будет просвещена теме исследования технологии безопасности изолированных виртуальных машин на примере высоко производительного почтового сервера, а так же разработан и хорошо продуман сам почтовый сервер. В мире такой большой выбор операционных систем, что порой выбирать приходится не из положительных качеств О.С., а исходя из соображений дешевизны, доступности, тех. поддержки. По этому далеко не каждый себе может позволить оперировать 3 и более операционными системами. По этому я решил выбрать для своей дипломной работы О.С. “Solaris 10”. В этой О.С. были реализованы такие новаторские вещи как виртуализация Новый высокопроизводительный сетевой стек, Система управления сервисами и многое другое. В данной работе пошагово будет создан почтовый сервер, используя безопасность на основе изолированных виртуальных машин (технология “1N Grid Containers”). В первой части работы кратко рассмотрены некоторые новые возможности, а так же установка и конфигурирование О.С. “Solaris 10”.В этой же части рассматривается архитектура работы выбранного почтового сервера, после чего будет по создан почтовый сервер с описанными функциями, и проведены необходимые тесты производительности и затрат ресурсов почтового сервера и дополнительно используемого программного обеспечения при работе в общей среде О.С. Solaris. Все показатели будут зафиксированы в таблице и усреднены.

Во второй части работы рассматривается технология изолированных виртуальных машин (1N Grid Containers) их создание и конфигурирование. После чего в изолированной виртуальной машине будет запущен тот же почтовый сервер с некоторым набором дополнительного программного обеспечения, и проведены необходимые тесты производительности и затрат ресурсов почтового сервера и дополнительно используемого программного обеспечения при работе в разных изолированных средах О.С. Solaris. В конечном итоге будет сделан вывод о целесообразности использования технологии виртуальных машин для безопасности сервисов в О.С. Solaris.

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

1. Описание О.С “Solaris”

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

Solaris 10 работает не только на архитектуре SPARC, но и на x86 и AMD64. Корпорация Sun Microsystems готова предложить своему заказчику широкий спектр возможностей - на любой платформе. При создании этой версии Solaris уделялось особое внимание безопасности ПО, быстродействию системы и снижению стоимости эксплуатации.

Solaris 10 - это единственная ОС, оптимизированная для работы на нескольких основных платформах:SPARC, x86, AMD64. Это позволяет защитить инвестиции, сделанные заказчиком в свою инфраструктуру.

В Solaris 10 обеспечивается совместимость на уровне исходных кодов для Solaris SPARC и Solaris x86, а так же совместимость на уровне исполняемых кодов для Linux x86 и Solaris x86.

1.1 Быстродействие системы

Динамическая трассировка задач (Dynamic Tracing, DTrace) - это мощный инструмент для диагностики узких мест в режиме реального времени. Эта система позволяет отслеживать узкие места в производительности приложений, анализ проводить тюнинг, и диагностику системы. Динамическая трассировка может значительно повысить производительность отдельных приложений и упростить задачу настройки производительности разработчикам. Использование динамической трассировки задач позволяет повысить скорость выполнения приложений до 30 раз.

Операционная система Solaris 10, установившая на сегодняшний день 14 мировых рекордов производительности, обеспечивает отличное соотношение цена/производительность для всех индустрий - от финансов до телекоммуникаций. Технические усовершенствования, такие как усовершенствование сетевых стеков и оптимизация для различных процессорных архитектур, позволяют Solaris 10 обеспечивать рекордную скорость работы бизнес приложений на серверах Sun Fire и рабочих станциях Sun Java.

1.2 SMF: Средства обслуживания сервисов

Вкратце, SMF - это механизм отношений между сервисами посредством (взаимных) зависимостей. Это также инфраструктура для автоматического запуска и перезапуска сервисов. И, наконец, это репозиторий, где хранится конфигурация и правила для запуска сервисов.

1.3 Надежность ПО

Превентивная самодиагностика (Predictive Self Healing) - это новое слово в определении и автоматическом восстановлении. Solaris 10 автоматически перезапускает приложения и сервисы, в которых были обнаружены нарушения работы, причем весь процесс обнаружения и диагностики занимает миллисекунды, а не часы.

1.4 Зоны и Контейнеры (Solaris Containers)

Solaris 10 позволяет системному администратору организовывать виртуальные системные разделы, называемые зонами. Внутри каждой зоны существует собственное пространство имен и пространство процессов. Каждая зона является самостоятельной системой, со своим набором пользователей, своими каталогами, своими сетевыми адресами, своими процессами. Зоны изолированы друг от друга, так что процессы и пользователи, работающие в одной зоне, не имеют доступа к процессам и ресурсам другой. Важно отметить, что даже суперпользователь “root” зоны не имеет возможности увидеть, что делается в другой зоне. В случае “взлома” отдельной зоны злоумышленник не получает доступа ко всей системе, а остается в рамках этой зоны.

Технология контейнеров предназначена для распределения системных ресурсов между отдельными процессами, группами процессов, пользователями или зонами. Так, администратор имеет возможность выделить 40 частей (shares) процессорных ресурсов серверу баз данных, 30 частей - серверу приложений и 5 раз по 10 частей пяти веб-серверам, работающим в режиме горизонтального масштабирования.

Сочетание технологий зон и контейнеров, называемое Solaris Containers, дает администратору уникальную возможность создания "виртуальных серверов", не пересекающихся друг с другом ни по пользователям, ни по процессам. Каждый из этих виртуальных серверов можно независимо перезагружать, запускать и останавливать сервисы в них, давать пользователям доступ, не опасаясь, что это затронет другие виртуальные серверы, работающие на этой машине.

1.5 Управление правами процессов

Одно важнейших нововведений в Solaris 10 - возможность ограничения прав процессов только самыми необходимыми потребностями. Прежде, если процессу нужно было обеспечить доступ к системному файлу или привилегированному сетевому порту, единственным выходом было присвоение этому процессу статуса суперпользовательского (root), что давало ему широчайший доступ ко всем системным ресурсам. В результате, если злоумышленник получал доступ к этому процессу, он получал доступ ко всей системе. В Solaris 10 администратор имеет возможность ограничить права доступа для конкретного процесса или группы процессов только теми привилегиями, которые ему реально необходимы. Таким образом, даже если процесс будет захвачен злоумышленником, он не сможет получить права суперпользователя.

1.6 Ролевой доступ

Система ролевого доступа (RBAC - Role Based Access Control) предназначена для решения "проблемы суперпользователя" - ситуации, когда один пользователь имеет доступ ко всем ресурсам системы. Такой подход нельзя назвать безопасным, поэтому в Solaris введена возможность разделения прав суперпользователя между несколькими пользователями. Одному пользователю может быть предоставлено только право чтения системных журналов (например, для аудита), другому - право добавления новых пользователей, третьему - право подключения и конфигурирования внешних устройств. Рекомендации экспертов по безопасности говорят о том, что в идеале в системе вообще не должно быть суперпользователя, а все его права должны быть разделены между различными ролями.

1.7 Защита от атак, использующих переполнение буфера

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

2. Установка и настройка О.С. “Solaris”

Установка Операционной системы Solaris 10 может производится в 3 режимах:

1. В Интерактивном консольном режиме – когда пользователь в консольном режиме отвечает на вопросы системы установки, и заводит необходимые для работы О.С параметры, используя при этом только клавиатуру как устройство ввода информации.

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

3. В ручном режиме – когда пользователь работает минимизированном режиме запуска О.С Solaris. Это требует определенных знаний от пользователя, команд О.С Solaris используя при этом только клавиатуру как устройство ввода информации.

2.1 Необходимые параметры Установки О.С. “Solaris”

Во всех трех режимах установки необходимо установить 3 параметра:

1. Произвести разметку диска или другого устройства хранения информации, на который будет установлены О.С. “Solaris”, указать тип файловой системы каждого раздела диска. Для разметки по умолчанию в О.С. Solaris использует UFS (unix file system), но можно также дополнительно создавать и другие разделы с другой файловой системой (FAT32, NTFS, EXT2, EXT3,...) как дополнительные. Указать точки монтирования для каждого раздела диска.

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

3. Установка сетевых настроек требует наличие сетевого адаптера (Ethernet, WAN,...). В операционной системе “Solaris” по умолчанию используется протокол TCP/IP. Основные параметры протокола TCP/IP:

   • IP адрес;

   • IP адрес шлюза по умолчанию;

   • Система идентификации доменных имен: DNS, LDAP, NIS, NIS+;

   • Хост имя системы с доменом;

2.2 Установка прикладного Soft’a

2.2.1 GCC компилятор

Настройка системы после окончания установки и загрузки полной рабочей версии О.С. Solaris, является компиляция и сборка GCC коллекции компиляторов, так как большинство сервисов, таких как MySQL, Postfix, Clamav и многие другие, рассчитаны на компиляцию именно пакетом GCC коллекции компиляторов, по умолчанию установленный пакет GCC собран на другой машине, возможно с другой процессорной архитектурой. По этому я просто удалил из системы GCC имевшийся по умолчанию скачал с http://www.sunfreeware.com компилятор gcc-2.95.3-sol8-intel-local.gz, не смотрите на то что это компилятор для Solaris 8 он нам просто послужит временным компилятором для одной установки и всё. Потом распаковываем “gzip –d gcc-2.95.3-sol8-intel-local.gz”

И устанавливаем в систему “pkgadd –d gcc-2.95.3-sol8-intel-local.gz”. Потом лезем на http://gcc.gnu.org/ и уже от туда забираем свежий GCC и с помощью временного GCC устанавливаем в систему только не забудьте удалить остатки временного компилятора. К стати не каких опций я не ставил при компиляции свежего GCC.

По чему вы спросите меня нужно было удалять старый компилятор ставить временный от Solaris 8, а дело вот в чем просто по умолчанию в Solaris 10 установлен компилятор GCC 3 которым в принципе сложно что либо скомпилировать к примеру MySQL, GCC постоянно на что то жалуется и даже если вы попробуете скомпилировать им свежий GCC с http://gcc.gnu.org то он не по-русски ругнётся и остановит процесс компиляции. Не знаю может в свежих ISO образах Solaris 10 этой проблемы уже нету, но когда я в феврале месяца работал с Solaris 10 то проблема была. Да к стати один из спецов по Солярке мне сказал что у Sun Microsystem есть свой Си компилятор который в ходит в пакет SDK который платный и возможно по этой причине GCC компилятор так криво установлен в Solaris’e (не знаю не проверял).К стати такая же проблема существует и с Perl модулями для того чтоб установить допустим Spamassasin с требуемым набором модулей необходимо стереть к черту существующий Perl скачать и скомпилить заново свежий Perl и только тогда вы сможете зафигачить необходимый набор модулей.

2.2.2 Файловый менеджер MC

Для более удобной и быстрой работы нам потребуется midnight commander. MC и дополнительные библиотеки необходимые для его работы забираем с http://www.sunfreeware.com так же как и gcc устанавливаем “gzip –d mc.gz” и “pkgadd –d mc”.Я не настаиваю на том что именно MC если кому нравится то и командная строка хороша.

2.3 Настройка О.С. “Solaris” после установки или выгребаем все не нужное

Отключение не нужных процессов и программ. Большинство сервисов, демонов, процессов в ранних версиях О.С. Solaris загружались при загрузки системы из загрузочных скриптов находящихся в директории /etc/rc2.d и /etc/rc3.d в зависимости от многопользовательского режима. Но в Solaris 10 была разработана система “SMF” это инфраструктура для автоматического запуска и перезапуска сервисов. По этой причине большая часть скриптов загружавшихся в /etc/rc2.d и /etc/rc3.d были перенесены в систему SMF. Для просмотра всех загружаемых через SMF программ можно воспользоваться командой “svcs –a”. Команда “svcs -a” показывает состояние сервиса, время запуска, и инстант сервиса – идентификатор по которому идёт управление сервисом из системы “SMF”. Для отключения сервиса используется команда вида “svcadm disable < инстант сервиса > ”.

Короче я приведу свой пример того что я оставил включоным в системе SMF (команда svcs -a):

Состояние Инстант сервиса

online Aug_04 svc:/system/svc/restarter:default

online Aug_04 svc:/milestone/name-services:default

online Aug_04 svc:/network/pfil:default

online Aug_04 svc:/network/loopback:default

online Aug_04 svc:/network/physical:default

online Aug_04 svc:/milestone/network:default

online Aug_04 svc:/system/identity:node

online Aug_04 svc:/system/metainit:default

online Aug_04 svc:/system/filesystem/root:default

online Aug_04 svc:/network/mysqld:default

online Aug_04 svc:/system/filesystem/usr:default

online Aug_04 svc:/system/device/local:default

online Aug_04 svc:/milestone/devices:default

online Aug_04 svc:/system/keymap:default

online Aug_04 svc:/system/filesystem/minimal:default

online Aug_04 svc:/system/coreadm:default

online Aug_04 svc:/system/identity:domain

online Aug_04 svc:/system/mdmonitor:default

online Aug_04 svc:/system/power:default

online Aug_04 svc:/system/sar:default

online Aug_04 svc:/system/rmtmpfiles:default

online Aug_04 svc:/system/sysevent:default

online Aug_04 svc:/network/ipfilter:default

online Aug_04 svc:/system/picl:default

online Aug_04 svc:/system/device/fc-fabric:default

online Aug_04 svc:/system/cryptosvc:default

online Aug_04 svc:/network/initial:default

online Aug_04 svc:/network/service:default

online Aug_04 svc:/system/manifest-import:default

online Aug_04 svc:/milestone/single-user:default

online Aug_04 svc:/system/filesystem/local:default

online Aug_04 svc:/system/sysidtool:net

online Aug_04 svc:/system/sysidtool:system

online Aug_04 svc:/milestone/sysconfig:default

online Aug_04 svc:/system/sac:default

online Aug_04 svc:/system/utmp:default

online Aug_04 svc:/system/cron:default

online Aug_04 svc:/system/console-login:default

online Aug_04 svc:/system/system-log:default

online Aug_04 svc:/network/rarp:default

online Aug_04 svc:/system/dumpadm:default

online Aug_04 svc:/system/fmd:default

online Aug_04 svc:/network/ssh:default

online Aug_04 svc:/milestone/multi-user:default

online Aug_04 svc:/milestone/multi-user-server:default

online Aug_04 svc:/system/zones:default

Вкратце. Если состояние сервиса показывается, как legacy_run это означает что, сервис загружен с помощью rc скриптов. Если состояние сервиса maintenance это означает что произошла ошибка запуска сервиса. Сразу для пытливых умов хочу оговорить, что SMF это не просто иной способ запуска сервисов. Это система управления сервисами. К стати отключение одного из сервисов может повлечь за собой maintenance состояние другого сервиса. То есть сервисы в системе SMF имеют взаимные связи между друг другом командой “svcs –d <инстант>” можно посмотреть от каких инстантов зависит данный сервис. К стати командой “svcs –D <инстант>“ можно посмотреть что зависит от данного истанта, то есть если мы вырубим данный инстант, то какие другие инстанты войдут в состояние maintenance.Да и еще если вы захотите убить сервис, который рулится из SMF, командой “kill” то он сразу же будет запущен заного. Более подробную инфу ищите на сайте http://docs.sun.com/app/docs/prod/solaris.10#hic. Да для самых пытливых умов, каким я сам не являюсь: наверно многие из вас сразу же спросят себя “а как создать свой собственный инстант?”

1.Вариант

Создать строчку для запуска сервиса из inetd.conf и через команду “inetconv” преобразовать строчку запуска в файл формата xml для SMF. Да да все инстанты SMF описываются именно xml файлами и хранятся они в директории /var/svc/manifest. С разу хочу сказать, что я не очень люблю inetd по этому этот вариант отпадает.

2.Вариант

Я думаю, что вы уже догадались взять и вручную или создать или изменить существующий из файлов xml под необходимы сервис, и потом просто через команду “svccfg import <путь к файлу xml>” про импортировать этот файл в систему SMF.Мне этот вариант больше всего понравился.

3.Вариант

Не скажу.

2.3.1 Огненная Стена

Далеко ли уедет сервер, если на нем не будет файрвола не думаю.

Если сервер будет находиться в сети без пакетного фильтра (FIREWALL) то необходимо на самом сервере реализовать пакетную фильтрацию средствами О.С. “Solaris”. В О.С. “Solaris” доступны 2 пакетных фильтра:

1. IP-FILTER – бесплатный, распространенный в UNIX мире пакетный фильтр.

2. SUN SCREEN – платный, используется только в О.С. Solaris.

О великий ip-filter как же ты мне близок по духу.

. Для того чтоб работал пакетный фильтр необходимо выполнить следующие команды:

1. svcadm enable svc:/network/pfil:default

2. svcadm enable svc:/network/ipfilter:default

Это запустит два сервиса pfil, ipfilter. После этого необходимо в директории /etc/ipf/pfil.ap указать сетевой интерфейс, на котором будет осуществляться фильтрация пакетов. Подробнее о настройки пакетного фильтра в разделе настройка пакетного фильтра.

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

2.4 Оптимизация сетевого стека TCP/IP

Сразу хочу сказать я не когда в своей жизни не видел еще такого быстрого сетевого стека.

Я запускал ftp сервер на Солярке и ftp выдавал мне по 11 мегабайт в секунду да да 11 мегабайт в секунду с устойчивой связью по Fast Ethernet.На FreeBSD я на максимум разгонял до 9,3 мегабайт в секунду.

Так как сервер рассчитывается на значительную сетевую нагрузку, необходимо изменить некоторые настройки TCP/IP протокола, так как по умолчанию в О.С. Solaris сетевой стек настроен для рабочей станции, но даже в этой ситуации сетевой стек имеет отличную производительность. Мы оптимизируем сетевой стек О.С. Solaris под предъявляемые требования к серверу.

Параметры настройки сетевого стека:

1. ndd –set /dev/tcp tcp_xmit_hiwat 65535

2. ndd –set /dev/tcp tcp_recv_hiwat 65535

3. ndd –set /dev/tcp tcp_conn_req_max_q 1024

4. ndd –set /dev/tcp tcp_conn_req_max_q0 4096

5. ndd –set /dev/tcp tcp_time_wait_interval 5000

6. ndd –set /dev/tcp tcp_max_buf 8388608

7. ndd –set /dev/tcp tcp_cwnd_max 8388608

1. tcp_xmit_hiwat - параметр, определяющий размер буфера посылки. По умолчанию равен 8192 (8K). Увеличив это значение до 65535 (65КB) в соответствие с стандартом Fast Ethernet 100Mbit/sec.

2. tcp_recv_hiwat - размер буфера при приеме, то есть размер который используется под информацию при ее приеме. По умолчанию равен 8192 (8K). Увеличим его до 65535 (65КB). в соответствие с стандартом Fast Ethernet 100Mbit/sec.

3. tcp_conn_req_max_q - Этот параметр определяет максимальное значение очереди запросов на каждое соединение.

4. tcp_conn_req_max_q0 - определяет при каком количестве полуоткрытых соединений, поступающие запросы не будут отклонены системой

5. tcp_time_wait_interval – устанавливает время в миллисекундах, в котором TCP соединение остается в состояние TIME-WAIT

6. tcp_max_buf – максимальный размер буфера в байтах, которое может использоваться.

7. tcp_cwnd_max - Максимальное значение окна переполнения. По умолчанию 32768.

Лучше все эти опции засунуть в исполняемый файл и закинуть в /etc/rc скрипты чтоб при каждой загрузке автоматом происходило изменения параметров.

3 почтовый сервер.

3.1 Выбор почтового сервера

Так как система ориентирована на свободно распространяемые программные продукты. С этой целью производился выбор из 4 самых популярных в мире Unix почтовых систем: sendmail, postfix, exim, qmail. Сразу необходимо рассмотреть достоинства и недостатки каждого из них, чтоб сделать объективный выбор будущей почтовой системы.

1. Sendmail является самым старым MTA доступным практически на всех Unix подобных О.С. Несмотря на впечатляющий и мощный функционал он не подходит. В первую очередь из-за того, что программа представляет из себя один монолитный блок. По этой же причине за “Sendmail” тянется огромный шлейф уязвимостей и проблем с быстродействием. Вторым немаловажным недостатком является одна из самых сложных процедур конфигурирования. Перспективы программы для создании простейшей конфигурации, по моему мнению выглядят весьма грустно так как необходимо владеть компилятором m4 . Хотя сам Sendmail все еще не остаётся самым распространенным MTA в мире (до 60% всей отправляемой почты работа Sendmail по всему миру), по причине многочисленности своих приверженцев. Да и в дополнение sendmail не может быть интегрирован с базами данных, таких как MySQL для хранения пользовательских бюджетов.

2. qmail является самым безопасным почтовым сервером. К сожалению, его недостаток заключается в том что qmail обладает слишком жесткой иерархией запуска служебных программ. Для выполнения каждого класса своих задач он порождает дочерние процессы специальных программ. После выполнения задачи процесс дочерней программы уничтожается. С одной стороны это обеспечивает безопасность и запас прочности программы, но с другой создает некоторые накладные расходы на постоянное создание дочерних процессов и межпроцессорное взаимодействие. К тому развитие проекта qmail двигается слишком медленно.

3. Exim первый недостаток заключается в процессе установки. Процесс установки отличается от классической схемы установки программ в Unix, и не особенно подходит для начинающих пользователей мира Unix. Для включения тех или иных возможностей приходится редактировать Makеfile. Да и сам процесс последующей настройки показал необходимость обладать хорошими познаниями в программировании в командных интерпретаторах. Если не обращать внимания на описанные только что недостатки, то мощный функциональный потенциал, заложенный в эту программу, может сгладить все существующие недостатки.

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

По этой причине я выбираю Postfix так как, на мой взгляд, это самое лучшее решение для данной задачи.

3.2 Выбор дополнительного программного обеспечения

3.2.1 Выбора сервера баз данных

Сервера баз данных будет MySQL так как на сегодняшний день эта один из самых распостраненых серверов баз данных.

3.2.2 Выбор антивирусной защиты

В качестве антивирусной защиты был выбран ClamAV антивирус и Avcheck в качестве связующего звена почтового сервера “Postfix” и антивируса ClamAV.

Avcheck в качестве mail checker’a сразу хочу оговорится я перепробовал целую кучу mail checker но не один не смог откомпилится по Solaris 10(Perl не всчет) и потом я наткнулся на проапгрейдную версию Avcheck c возможностью ClamAV. Написал Avcheck Michael Tokarev.

3.2.3 Библиотека авторизация Cyrus SASL 2.x

Так как по умолчанию в протоколе SMTP отсутствует методы авторизации пользователей то есть через сервер может слать почту любой желающий можно ограничить пересылку по IP адресу, но это не удобно так как если на сервере будет 1000 или более пользователей то слежение за IP-адресами и мобильность пользователей будет не возможно.К стати для Cyrus SASL я нашёл патч который даёт возможность хранения зашифрованных паролей в базе MySQL, я не знаю но по моему сейчас этот патч стал одним целым с Cyrus SASL.

Имя патча cyrus-patch-all.c.patch

3.2.4 POP3 Сервер

Courier-IMAP работает pop3 и imap сервером. Там, где сможет, проверяет пользователя сам, где не может – через SASL и отдает пользователю почту, полученную postfix'ом.

Главными плюсами Courier-IMAP является:

• Возможность использовать пароли в зашифрованном виде в SQL базах данных

• Возможность ведение квот на размер почтового ящика пользователя и совместимость с Postfix’ом

Главным минусом данного продукта является то, что Courier Imap может только работает с привилегиями суперпользователя (root).

3.2.5 Ведение квот

http://web.onda.com.br/nadal/ находится файл postfix-vda.patch, который дает возможность Postfix’u вести учет размера почтового ящика. Кстати этот патч на квоты в упор не хотел накладываться на postfix на Солярке. Я взял переписал sources postfix’a и данного патча на Linux (по-моему это был ШнэкWarezz), потом наложил патч на postfix и обратно переписал на Солярку.

3.3 Установка Серверов

1. Для начало надо установить MySQL так как все будет плясать от него. Я думаю что с установкой MySQL сервера не возникнет не у кого не каких проблем.

2. После установки и настройки MySQL нам требуется установить Cyrus SASL. Я просто приведу опции установки для моей систему конечно у каждого пути будут разные

./configure --prefix=/usr/local --sysconfdir=/usr/local/lib/sasl2 --enable-ntlm –with-devrandom=/dev/random --with-openssl=/usr/local --enable-login --enable-plain --with-saslauthd=/usr/local/sbin --with-authdaemond=/usr/local/var/authdaemon --with-pwcheck=/usr/local/var/authdaemon --enable-sql --with-mysql=/usr/local/mysql

--with-rc4 --enable-digest --disable-otp -disable-cram --disable-gssapi --disable-anon --disable-pam --disable-java --without-javabase --without-dbpath --without-dblib --without-bdb-libdir --without-bdb-incdir --without-gdbm --without-ldap

--without-pgsql --without-sqlite --without-des CPPFLAGS="-I/usr/local/mysql/include/mysql"

LDFLAGS="-L/usr/local/mysql/lib/mysql -R/usr/local/mysql/lib/mysql -lmysqlclient -lcrypt"

Make

Make install

Настройка Cyrus SASL заключается в том что надо создать файл в /usr/local/lib/sasl2/smtpd.conf который будет читать сам постфикс.

Содержание файла:

pwcheck_method: auxprop

password_format: crypt

auxprop_plugin: sql

mech_list: DIGEST-MD5 CRAM-MD5 PLAIN LOGIN

auto_transition: yes

sql_engine: mysql

sql_user: mysql_user

sql_passwd: Mysql_pass

sql_hostnames: 127.0.0.1

sql_database: postfixdb

sql_select: SELECT password FROM mailbox WHERE username = '%u@%r'

sql_verbose: yes

log_level: 9

Подробно рассматривать каждую опцию я не буду, вы можете и так их найти в описании SASL.

4.Установка Courier IMAP

Сразу хочу сказать мне не нравится Courier IMAP как сервер POP3 протокола, так как уже не раз находили в нём дырки. Да и сам сервер к сожалению можно запустить только от root’a, Но у меня не было времени да и желания изучать Дакота. Да установку и настройку Courier IMAP я рассматривать не буду.

3.Установка самого Postfix’a

Так как я уже говорил раньше для введения квот в постфиксе необходимо пропатчить систему на линуксе а потом переписать её на солярку.

Ниже приводится маленький скрипт для компиляции Postfix’a, да кстати в процессе инсталляции будут заданы вопросы о том какой “prefix” дать Postfix’у я выбрал префикс /usr/local, и следующие пути к примеру путь очереди уже будет автоматически добовлятся

/usr/local.Так что будьте внимательны какие пути и куда вы ставите так как потом могут возникнуть проблемы.Да конечно надо не забыть добавить в систему пользователей postfix,postdrop и соответствующую группу.

#!/bin/sh

#make tidy

#make clean

set PATH=/usr:/usr/local:/usr/lib:/usr/include:/usr/libexec:/usr/local:/usr/local/lib:/usr/local/include:/usr/local/lib/sasl2:/usr/local/mysql/lib/mysql:/bin:/sbin:/usr/bin:/usr/sbin

export PATH

make -f Makefile.init makefiles 'CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include/mysql -DUSE_SASL_AUTH -I/usr/local/include/sasl -DUSE_SSL -I/usr/local/include/openssl' 'AUXLIBS=-L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lm -L/usr/local/lib -lsasl2 -lssl -lcrypto'

Предворительно перед последней операцией, скопируйте все библиотеки(libsasl2.*) из директории /usr/local/lib в /usr/lib

Так же скопируйте все файлы из директории /usr/local/mysql/lib/mysql в /usr/lib

И потом последнее действие

#make install

Настройка Postfix’a

Я не буду объяснять каждую опцию конфига постфикса так как вы можете это найти на http://www.postfix.org

Файл Main.cf:

queue_directory = /usr/local/var/spool/postfix

command_directory = /usr/local/sbin/postfix

daemon_directory = /usr/local/libexec/postfix

sample_directory = /usr/local/etc/postfix

# opredeljaet uchotnuju zapisj kotoroja javljaetsja vladeljcem pochtovoj ocheredi

mail_owner = postfix

unknown_local_recipient_reject_code = 450

setgid_group = postdrop

html_directory = no

manpage_directory = /usr/local/man

smtpd_helo_required = yes

default_privs = mailnull

alias_database = mysql:/usr/local/etc/postfix/sql/alias.mysql

alias_maps = $alias_database

local_command_shell = /usr/lib/smrsh -c

# Vsegda slatj Ehlo pri nachale smtp sessiji

smtp_always_send_ehlo = yes

# Zapreshenije vrfy

disable_vrfy_command = yes

# Vikljuchaem zaderzhku na otvet v sluchae oshibki clienta

smtpd_error_sleep_time = 0

# Kogda kolichestvo oshibok previshaet eto kolichestvo to postfix rvet soedinenije

#smtpd_hard_error_limit = 8

# kolichestvo processov zapuskaemih postfixom (klientskih i servernih) naprjamuju svjazana s kazhdoj strochkoj iz master.cf (maxproc)

default_process_limit = 2000

# kolichestvo soedinenij s klientami ono dolzhno bitj rovno polovine default_process_limit

smtpd_client_connection_count_limit = 500

smtpd_proxy_timeout = 10s

# Ogranichivaet razmer pisjma pri oshibke

bounce_size_limit = 2000

# Chastota s kotoroj deffered mails pitajutsja zaitji v active queue uvilichenije etogo prarmetra

# videt k povisheniju proizvoditeljnosti tak kak rezhe process dlja peresilki pochti budet zapuskatsja

minimal_backoff_time = 1000s

maximal_backoff_time = 2000s

#Kak chasto manager ocheredi skaniruet ocheredj na "defered mail"

#queue_run_delay = 50s

#qmgr_message_recepient_limit = 9000

# Timeout dlja prinjatija ot klienta kakih ti bi ne bilo zaprosov po istecheniju etogo vremeni svjazj rvetsja

smtpd_timeout = 20s

#vremja dlja poluchenija helo/ehlo kommand dlja neotvechajushego udaljonogo SMTP servera

smtp_helo_timeout = 10s

smtp_mail_timeout = 10s

smtp_rcpt_timeout = 10s

virtual_alias_maps = mysql:/usr/local/etc/postfix/sql/alias.mysql

virtual_mailbox_base = /usr/local/var/spool/postfix/vmail

virtual_gid_maps = static:5001

virtual_minimum_uid = 5001

virtual_transport = virtual

virtual_uid_maps = static:5001

virtual_mailbox_domains = mysql:/usr/local/etc/postfix/sql/domains.mysql

virtual_mailbox_maps = mysql:/usr/local/etc/postfix/sql/mailbox.mysql

virtual_create_maildirsize = yes

virtual_mailbox_extended = yes

virtual_mailbox_limit_maps = mysql:/usr/local/etc/postfix/sql/quota.mysql

virtual_mailbox_limit_override = yes

virtual_maildir_limit_messages = Sorry, the user's maildir has overdrawn his diskspace quota, please try again later.

virtual_overquota_bounce = yes

# Imja danogo kompa s postfixom vkljuchajushaja domenuju chastj (FQDN)

myhostname = mail.myserver.lv

# Domen dannogo kompjutera

mydomain = myserver.lv

# eti setki postfix schitaet lokaljnimi i komp iz etoj setki budet imetj vozmozhnostj mail relaya

mynetworks = 127.0.0.0/8 195.195.195.1/24

myorigin = $mydomain

# eta derektiva zadaet shto postfix dolzhen prinjatj pochtu dlja poljzovatelej dannogo domena

mydestination = $myhostname, localhost.$mydomain, localhost

debug_peer_level = 9

#========== CLAMAV VIRUS CHECK

content_filter = scan:127.0.0.1:10025

receive_override_options = no_address_mappings

empty_address_recipient = notrelay@myserver.lv

#==========Access

broken_sasl_auth_clients = yes

smtpd_sasl_auth_enable = yes

smtpd_sasl_security_options = noanonymous

smtpd_sasl_password_maps = mysql:/usr/local/etc/postfix/sql/sasl.mysql

smtpd_banner = ESMTP READY !!! ALL CONNECTION LOGGED IN WINDOWS STATION :( !!!

smtpd_delay_reject = no

# Proverka poljzovatelej

local_recipient_maps = $alias_maps, $virtual_mailbox_maps

#esli stoit to ljubije ogranichenija delajutsja posle vvoda commandi RCPT TO

smtpd_delay_reject = no

#Obichno eto ogranichenije srazu posle "HELO/EHLO" vvoda komandi

#Esli danije peresilajutsja ot clienta k e-mail(serveru) to client budet govoritj

#ustonovleniju u nego v hostname imja sootvetstvenno server ne smozhet ne chego opredelitj po etomu imenji

#NO esli potom e-mail(server)kogda poluchit e-mail ot klienta budet ego peresilatj daljshe to togda

#na zapros helo/ehlo on otvetit svoim imenem

#smtpd_helo_restrictions = reject_unknown_hostname

#smtpd_delay_reject = yes -esli stoit to ogranichenija delajutsja posle commandi RCPT TO

#proverka na etpe kogda poluchenajem "MAIL FROM" commandu

#reject_unknown_sender_domain reject when sender mail adress has no DNS A or MX record

smtpd_sender_restrictions = reject_unknown_sender_domain

# proverka na etpe poluchenija pisem

# Skoljko adressov e-mail'a mozhet soderzhatsja v odnom e-maile na dostavku (chislo CC v odnom pisjme)

smtpd_recipient_limit = 10000

# proverka na etape kogda polucheam commandu "RCPT TO:"

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

readme_directory = no

Файл master.cf:

#

# Postfix master process configuration file. For details on the format

# of the file, see the Postfix master(5) manual page.

#

# ==========================================================================

# service type private unpriv chroot wakeup maxproc command + args

# (yes) (yes) (yes) (never) (100)

# ==========================================================================

smtp inet n y y - 500 smtpd -o content_filter=scan

127.0.0.1:1025 inet n y y - 500 smtpd -o content_filter=

pickup fifo n y y 60 1 pickup

cleanup unix n y y - 0 cleanup

qmgr fifo n y y 300 1 qmgr

rewrite unix - y y - 500 trivial-rewrite

bounce unix - y y - 0 bounce

defer unix - y y - 0 bounce

trace unix - y y - 0 bounce

flush unix n y y 1000? 0 flush

proxymap unix - y y - 500 proxymap

smtp unix - y y - 500 smtp

error unix - y y - 500 error

discard unix - y y - 500 discard

local unix - n y - 500 local

virtual unix - n n - 500 virtual

lmtp unix - y y - 500 lmtp

anvil unix - y y - 1 anvil

scache unix - y y - 1 scache

scan unix - n n - 500 pipe flags=q user=clamav:clamav argv=/usr/local/bin/avcheck -S 127.0.0.1:1025 -d /var/clamav/tmp -s clamav:127.0.0.1:3310 -f ${sender} -- ${recipient}

maildrop unix - n n - 500 pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}

Как видно из файла master.cf я по самые помидоры затянул фичи безопастности да кстати путь к avcheck нужно указать правильный.

Теперь необходимо создать в директории с конфигами и директорию “sql” в которой будет хранится файлы обращения к базе MySQL.Кстати конфигурацию SQL части я взял из описания “Postfix Admin 2.1” так как управление будет иметь WEB Interface

Все ниже перечисленые файлы должны хранится в директории sql.

Файл alias.mysql:

user = mysql_user

password = Mysql_pass

hosts = 127.0.0.1

dbname = postfixdb

table = alias

select_field = goto

where_field = address

Файл domains.mysql:

user = mysql_user

password = Mysql_pass

hosts = 127.0.0.1

dbname = postfixdb

table = domain

select_field = description

where_field = domain

#additional_conditions = and backupmx = '0' and active = '1'

Файл mailbox.mysql:

user = mysql_user

password = Mysql_pass

hosts = 127.0.0.1

dbname = postfixdb

table = mailbox

select_field = maildir

where_field = username

additional_conditions = and active = '1'

Файл quota.mysql:

user = mysql_user

password = Mysql_pass

hosts = 127.0.0.1

dbname = postfixdb

table = mailbox

select_field = quota

where_field = username

additional_conditions = and active = '1'

Файл relay.mysql:

user = mysql_user

password = Mysql_pass

hosts = 127.0.0.1

dbname = postfixdb

table = domain

select_field = domain

where_field = domain

additional_conditions = and backupmx = '1'

Файл sasl.mysql

user = mysql_user

password = Mysql_pass

hosts = 127.0.0.1

dbname = postfixdb

table = mailbox

select_field = password

where_field = username

файл transport:

myserver.lv

Установка ClamAV

На установке и настройки ClamAV я не буду останавливатся скажу только одно

В файле конфигурации clamd.conf необходимо установить две опции:

TCPSocket 3310

TCPAddr 127.0.0.1

Так как Postfix будет работать с ClamAV через AvCheck который в свою очередь работает с ClamAV через TCP порт даную схему мы расмотрим позже.

Установка AvCheck

Заключается в том чтобы в файле avcheck.c закоментировать или наоборот от коментировать несколько DEFINE. И после компиляции надо скопировать полученый бинарник “avcheck” в директорию /usr/local/bin можно конечно и в другую но тогда в файле master.cf надо изменить путь к avcheck.

MySQL запросы на создание базы данных для сервера Postfix

Postfixdb – база данных сервера Postfix должна содержать таблицы:

1. Alias table - таблица пользовательских псевдонимов.

2. Domain table - таблица доменных имен для виртуального сервера.

3. Mailbox table - таблица пользовательских бюджетов.

4. Domain admins table - таблица администраторов доменов.

5. Admin table - таблица бюджетов администраторов доменов.

6. Log table – таблица ведения логов web системы управления.

Необходимо создать доступ к базе данных postfixdb для адресов 127.0.0.1 и localhost, так как сервер Postfix будет связываться с базой через адрес 127.0.0.1 виртуального сетевого локального адаптера lo0.

GRANT SELECT ON postfixdb.* TO mysql_user@"127.0.0.1" IDENTIFIED BY 'Mysql_pass’ WITH GRANT OPTION;

GRANT SELECT ON postfixdb.* TO mysql_user@"localhost" IDENTIFIED BY 'Mysql_pass’ WITH GRANT OPTION;

Нижний запрос требуется для того чтоб когда postfix и mysql будут работать в разных зонах они имели связь между собой.

GRANT SELECT ON postfixdb.* TO mysql_user@"195.195.195.20 " IDENTIFIED BY 'Mysql_pass’ WITH GRANT OPTION;

FLUSH PRIVILEGES;

Создание Таблиц Базы данных Postfixsb

1) CREATE TABLE alias (

address varchar(255) NOT NULL default '',

goto text NOT NULL,

domain varchar(255) NOT NULL default '',

created datetime NOT NULL default '0000-00-00 00:00:00',

modified datetime NOT NULL default '0000-00-00 00:00:00',

active tinyint(1) NOT NULL default '1',

PRIMARY KEY (address),

KEY address (address)

) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Aliases';

2) CREATE TABLE domain (

domain varchar(255) NOT NULL default '',

description varchar(255) NOT NULL default '',

aliases int(10) NOT NULL default '0',

mailboxes int(10) NOT NULL default '0',

maxquota int(10) NOT NULL default '0',

transport varchar(255) default NULL,

backupmx tinyint(1) NOT NULL default '0',

created datetime NOT NULL default '0000-00-00 00:00:00',

modified datetime NOT NULL default '0000-00-00 00:00:00',

active tinyint(1) NOT NULL default '1',

PRIMARY KEY (domain),

KEY domain (domain)

) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Domains';

3) CREATE TABLE mailbox (

username varchar(255) NOT NULL default '',

password varchar(255) NOT NULL default '',

name varchar(255) NOT NULL default '',

maildir varchar(255) NOT NULL default '',

quota int(10) NOT NULL default '0',

domain varchar(255) NOT NULL default '',

created datetime NOT NULL default '0000-00-00 00:00:00',

modified datetime NOT NULL default '0000-00-00 00:00:00',

active tinyint(1) NOT NULL default '1',

PRIMARY KEY (username),

KEY username (username)

) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Mailboxes';

4) CREATE TABLE domain_admins (

username varchar(255) NOT NULL default '',

domain varchar(255) NOT NULL default '',

created datetime NOT NULL default '0000-00-00 00:00:00',

active tinyint(1) NOT NULL default '1',

KEY username (username)

) TYPE=MyISAM COMMENT='Postfix Admin - Domain Admins';

5) # Table structure for table admin

CREATE TABLE admin (

username varchar(255) NOT NULL default '',

password varchar(255) NOT NULL default '',

created datetime NOT NULL default '0000-00-00 00:00:00',

modified datetime NOT NULL default '0000-00-00 00:00:00',

active tinyint(1) NOT NULL default '1',

PRIMARY KEY (username),

KEY username (username)

) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Admins';

6) CREATE TABLE log (

timestamp datetime NOT NULL default '0000-00-00 00:00:00',

username varchar(255) NOT NULL default '',

domain varchar(255) NOT NULL default '',

action varchar(255) NOT NULL default '',

data varchar(255) NOT NULL default '',

KEY timestamp (timestamp)

) TYPE=MyISAM COMMENT='Postfix Admin - Log';

Описание сети:

2 сервера под управлением операционных систем “Solaris” и “Linux” находятся в одном сегменте сети Fast Ethernet и висят на одном Свитче. Сервер с О.С. “Solaris” будет главным объектам для исследования. Сервер с О.С “Linux” будет содержать программу тестирования “Postal” и Web систему управления пользовательскими бюджетами. Почтовый сервер будет тестироваться на прием почты, по этой причине необходим еще один сервер в том же сегменте локальной сети.

3.4 Описание почтового сервера Postfix

postfix – это один из самых популярный MTA (Mail Transfer Agent), позволяющий эффективно передавать письма адресатам. MTA это программа, которая лежит в основе передачи электронной почты. Когда посылается письмо с адресом user@mail.com, то делается это как правило посредством SMTP-клиента (например, Outlook, The Bat!, mutt), который передает письмо MTA. SMTP-клиент может делать это по протоколу SMTP или еще каким-нибудь способом, в любом случае он не выполняет доставку письма самостоятельно. MTA получает письмо и проверяет по своей конфигурации, что он должен с ним сделать: послать адресату напрямую (то есть, послать письмо MTA, который установлен на хосте, куда указывает MX-запись соответствующего домена). MTA должен уметь делать следующие действия:

* Обрабатывать входные соединения для приема почты по протоколу SMTP.

* Сохранять почту на диске в очереди.

* Отправлять почту адресату из очереди (это может быть локальный почтовый ящик, другой MTA или еще какой-то иной способ доставки почты).

* Гарантировать доставку почты получателю или нотификацию отправителю о невозможности доставки.

Этот список – только самое необходимое. Хороший MTA должен, кроме того, быть надежным, высокопроизводительным, гибок в настройках, поддерживать интеграцию с фильтрами (например, для борьбы со спамом) и т.д.

Долгое время фактически единственным MTA для операционных систем типа Unix был sendmail, отличающийся крайне сложным форматом конфигурации и, неудобством использования. Сейчас ситуация иная – есть еще несколько свободных почтовых систем, таких как QMail и postfix, которые обладают целым рядом преимуществ по сравнению с sendmail. Впрочем, sendmail все равно есть и, наверное, останется самым популярным MTA, так как традиционно входит в состав огромного количества дистрибутивов Unix. Кроме того, опять же, интерфейс с установленным MTA, все равно закрепился как вызов программ из установки sendmail и все остальные MTA поддерживают его. Общая организация postfix: модульность, управляющий процесс master.

Первое, на что стоит обратить внимание: postfix не является монолитной программой. Он весь состоит из модулей, которые передают почтовые сообщения или иную информацию между собой.

Интересно, что модули постфикса, или сервисы, устроены в виде отдельных программ, каждая из которых запускается из управляющего сервиса master (порождается от master). Почему выбрана такая модель (то есть, множество однопоточных процессов) а не, к примеру, популярные потоки?

Многопоточные сервисы вполне могут существовать и создаваться, это мы все рассмотрим чуть позднее. Но все сервисы постфикса основаны либо на select, либо на pre-fork моделях. Связано это, с отлаженностью этих механизмов на различных операционных системах. Постфикс компилируется и успешно работает практически на всех более-менее популярных операционных системах типа Unix, это было бы попросту невозможно в том случае, если бы использовались потоки, так как на разных О.С. типа Unix потоки имеют разную реализацию. А pre-fork модель или select вполне отлажена в течение десятилетий использования. Для функционирования всей системы в целом необходимо запустить только процесс master. Он читает конфигурационный файл следующего вида:

Таблица 3.4.1.

Настройки демонов сервера Postfix

=================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) =================================================================== smtp inet n y y - 500 smtpd -o content_filter=scan 127.0.0.1:1025 inet n y y - 500 smtpd -o content_filter= pickup fifo n y y 60 1 pickup cleanup unix n y y - 0 cleanup qmgr fifo n y y 300 1 qmgr rewrite unix - y y - 500 trivial-rewrite bounce unix - y y - 0 bounce defer unix - y y - 0 bounce trace unix - y y - 0 bounce flush unix n y y 1000? 0 flush smtp unix - y y - 500 smtp error unix - y y - 500 error discard unix - y y - 500 discard local unix - n y - 500 local virtual unix - n n - 500 virtual lmtp unix - y y - 500 lmtp anvil unix - y y - 1 anvil scache unix - y y - 1 scache scan unix - n n - 500 pipe flags=q user=clamav:clamav argv=/usr/local/bin/avcheck -S 127.0.0.1:1025 -d /var/clamav/tmp -s clamav:127.0.0.1:3310 -f ${sender} -- ${recipient}

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

• service – название сервиса в случае использования сокетов unix-domain и прочих средств IPC (interprocess communication), порт и интерфейс в случае использования интернет-сокетов (smtp, аналог TCP порта 25).

• type – тип сокета, который слушается сервисом.

• private – признак того, что сервис может быть доступен снаружи MTA. Все сервисы с типом inet не могут быть private по понятным причинам – никак нельзя ограничить доступ процессов к интернет-сокету. В зависимости от этого флага отличается каталог и права доступа на файл, который связан с создаваемым сокетом. Доступные снаружи сервисы нужны по разным причинам, например сервис showq нужен для получения содержимого очереди сообщений для команды mailq.

• unpriv – признак того, что сервис запускается от пользователя ограниченными привилегиями postfix, а не от супер-пользователя (root). Надо сказать, что смена пользователя целиком и полностью лежит на самом сервисе, а не управляющем сервисе master (единственное, чем отличается запуск непривилегированного процесса от запуска привилегированного – так это наличием ключа -u). Это можно объяснить тем, что сервисы (а это программы в каталоге /usr/local/libexec/postfix) просто так не появляются и они должны поддерживать такой интерфейс. Этот флаг нужен для того, чтобы обезопасить сервер от сбоев в работе. Допустим, в сервере Postfix найдена критическая ошибка в каком-либо из сервисов, позволяющая злоумышленнику выполнить любой код на вашем сервере; если бы сервисы работали от root'а то этот человек получил бы полный доступ к компьютеру, а если они работают от пользователя postfix, который даже не имеет возможности логина, то под ударом только ваша почта. Естественно, что основной процесс, master, работает с правами суперпользователя root, это значит, что master должен быть максимально простым для того, чтобы гарантировать отсутствие в нем грубых ошибок.

• chroot – аналогично unpriv, флаг заставляет сервисы выполнить вызов chroot на /usr/local/var/spool/postfix. Тем самым для сервисов меняется положение каталога '/' и они не могут получить доступ к другим файлам, кроме очереди сообщений. Необходимость этого флага обусловлена теми же причинами, что и для unpriv.

• wakeup – нотификация сервиса каждые n секунд. Это позволяет заставить сервисы, допустим, перечитать очередь. На самом деле, нотификация об изменениях в очереди может быть доставлена от других сервисов, но это все равно полезно: вдруг где-то что-то сломалось, или постфикс перезапустился, все равно очередь должна быть проверена.

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

• command – это просто название программы и аргументы, которые должны быть ей переданы. Здесь никаких тонкостей нет.

Значения по умолчанию (например, maxproc) настраиваются через другой конфигурационный файл – main.cf. master: запуск сервисов, интерфейс с уже запущенными сервисами.

Теперь необходимо рассмотреть, как появляются новые процессы, выполняющие работу сервисов.

При запуске главного сервиса master считывает файл конфигурации master.cf, по которому он определяет, какие сервисы понадобятся. Он создает все указанные сокеты, и готовиться их "слушать", инициализирует внутри себя структуры, описывающие состояние каждого из сервисов (количество запущенных процессов и т.п.), после чего master заносит все дескрипторы сокетов в select и ждет какого-нибудь из событий на каждый из них. Теперь, допустим, на наш сервер должна прийти почта. Когда приходит почта, это значит, что некий почтовый релей установил соединение на 25-й порт нашего сервера. В этом случае, дескриптор в master'е, который связан с этим портом, будет готов к чтению и, тем самым, select завершится. Главный сервис master не умеет обрабатывать smtp-сессию, зато это умеет делать сервис smtpd, который и будет запущен при помощи fork. Естественно, что перед запуском производится некоторое количество действий, которые пока что не особенно интересны, важно то, что сразу же после запуска smtpd выполняет accept на этом дескрипторе и приступает к обработке smtp-сессии и пересылке письма дальше по сервисам до менеджера очереди.

Перед запуском master увеличивает счетчик процессов сервиса smtpd и запоминает его pid. Этот счетчик будет уменьшен тогда, когда master получит сигнал SIGCHLD, то есть smtpd завершится. Тем самым, master может контролировать количество запущенных процессов.

Теперь интересно как smtp-сессия обрабатывается, master может опять реагировать на изменения состояния дескриптора, связанного с 25-м портом, а что делать, когда эта сессия закончится? Глупо завершать smtpd сразу же после обработки одного письма если через секунду, возможно, придет еще одно письмо: тогда будет слишком много затрат связанных с fork. Тем самым, сервисы должны уметь обрабатывать новые соединения и при этом им не должен вмешаться master. Кроме того, master все равно должен следить за сервисами и если кто-то из них прекратил работу и умер, то это не должно сказаться на работоспобности MTA в целом.

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

Обычно, каждый свободный экземпляр сервера (то есть, отдельный процесс) выполняет accept (или сначала select, а потом accept) на нужный дескриптор. При этом реально accept будет выполнен только у одного экземпляра сервера (заранее неизвестно какого именно), остальные получат ошибку и могут опять запустить accept или select. Сейчас же, master должен уметь отличать ситуации, когда свободных экземпляров сервиса нет (тогда он должен слушать сокет сам и выполнить fork, когда придет новое соединение) и когда кто-то свободен (и тогда ему не надо запускать select на этот сокет, поскольку этот "кто-то" сам следит за своим сокетом). Естественно, что это делается опять же через IPC: между потомком (то есть, экземпляром сервиса) и master'ом есть канал, через который потомок уведомляет master о своей занятости или свободности. Когда потомок изменяет свое состояние, он передает master'у два значения: свой pid и флаг "занят" или "свободен".

Реализация многопроцессного однопотокового сервиса в этом случае простая: сервис все время делает accept, по успеху последнего он оповещает master о занятости, затем начинает обрабатывать соединение, после чего сообщает master'у о своей свободности и опять делает accept. Если в какой-то момент он решит закончить свое выполнение, он может это сделать без оповещений –– master получит сигнал от операционной системы и выполнит все необходимые действия.

Теперь небольшая ремарка о необходимости завершения работы процесса. Это общепринятая практика, когда сервер после выполнения определенного числа операций или простоя, прекращает свое выполнение. Такая логика очень полезно, потому что уменьшает зависимость от ошибок с неудалением выделенной ранее памяти (попросту, "разбухания" процесса), поэтому обычно любые сервера имеют какое-то ограничение на количество обработанных запросов и время простоя. В postfix каждый сервис имеет подобные ограничения, кроме, разумеется, master, так как последний некому перезапустить.

Когда некий сервис требует для своей работы другой сервис (например, для того чтобы передать почтовое сообщение от smtpd в cleanup), он всего-навсего обращается по нужному сетевому адресу (в сети Интернет или файловой системе), все остальное за него будет сделано master'ом или работающим целевым сервисом.

3.4.1 Архитектура Работы Postfix

3.4.2 Описание процессов работы сервера Postfix

1. smtpd – демон SMTPD принимает соединение из сети и выполняет 0 или более транзакций на соединение, а также, если включены фильтры, проверяет доступ поступившего письма. Допустимо ли письмо и не попадает ли это письмо под запрещенные в директиве ACCESS и фильтр спама базы RBL. После проверок демон Smtpd передает письмо сервису scan, который запускает утилиту avcheck.

2. Avcheck – утилита, предназначенная для связующего звена между smtpd демоном и ClamAV антивирусом. При поступлении письма avcheck передает копию письма по адресу 127.0.0.1 на порт 3310, на котором работает Clamav антивирус.

• В случае, если в письме был найден вирус, то Clamav возвращает код ошибки и имя вируса, найденного в письме. Avcheck уничтожает письмо и передается уведомление о найденном вирусе и адресате пославшего его в master демон для занесения этой информации в логи.

• В случае, если в письме Clamav не нашёл вирусов, тогда avcheck возвращается положительный код и avcheck возвращает письмо обратно через адрес 127.0.0.1 на порт 1025 smtpd демону, который в свою очередь передаёт письмо дальше по схеме.

3. cleanup - проводит первоначальные проверки на правильность оформления и формат входящего сообщения, позволяя защитить остальную систему от многих атак, рассчитанных на переполнение буфера. В случае необходимости добавляет в письмо недостающие служебные заголовки и с помощью процесса по имени trivial-rewrite приводит адреса к виду: пользователь@поддомен.домен. В postfix пока нет полноценного языка, позволяющего гибко управлять процессом переписывания адресов, поэтому вместо него используются служебные таблицы canonical и virtual для хранения правил, управляющих перезаписью. После такой обработки письмо сохраняется на диск в формате файла почтовой очереди и кладется в директорию, где хранится очередь incoming, обычно это директория /usr/local/var/spool/postfix/incoming/. Эта очередь используется только для обработки входящих сообщений. Затем процесс cleanup уведомляет процесс queue manager (qmgr), управляющий всеми очередями о прибытии новой почты.

4. Pickup – демон для доставки почты, отправленной локально из самой операционной системы. Во многих UNIX-системах в качестве почтовой программы и по сей день традиционно используется sendmail. Соответственно большинство скриптов, написанных ранее и используемых сейчас, используют именно sendmail, считает, что в системе установлена именно эта разновидность почтового сервера. Чтобы не разрушить совместимость с огромным количеством программного обеспечения при переходе к использованию Postfix, в систему вместе с прочими файлами устанавливается программа, заменяющая sendmail. Таким образом, получается, что команда mail передает письмо программе sendmail, установленной Postfix, а та в свою очередь вызывает привилегированную программу postdrop. Ну а последняя уже кладет файлы с письмами в служебную директорию maildrop, которая обычно находится в /var/spool/postfix/maildrop/. Затем письмо подхватывает процесс pickup и аналогично SMTP-демону проверяет соответствие послания установленным форматам, в результате чего письмо попадает в лапы свободному на данный момент процессу cleanup. В случае, если письмо не поддается коррекции, то оно немедленно уничтожается. Стоит отметить, что отправитель не получит никаких извещений о данном факте. Если же ничего аномального не было найдено, то сообщение беспрепятственно попадет в очередь incoming, а queue manager, как обычно, получит сигнал о появлении новых писем.

5. Bounce, Defer. Демоны для извещения об ошибке доставки почты. Новая почта также может появиться в случае, если письмо невозможно доставить адресату и настройки системы диктуют в данном случае отправлять оповещения отправителю. При таком повороте событий процесс bounce или defer генерирует письмо с извещением о проблеме. Адресовано оно, конечно же, отправителю первоначального сообщения. Другим источником возникновения писем может быть настройка Postfix, заставляющая его отправлять администратору уведомления в случае проблем c SMTP или нарушения тех или иных политик, которые продиктованы настройками почтовой системы. Соответственно, в обоих случаях, чтобы доставить письмо адресату, приходится, как обычно, отдать его процессу cleanup и затем отправить в очередь incoming.

6. Qmgr – Демон доставки почты ждёт пришедшую почту в очередь incoming и договаривается о доставке почты через Postfix delivery process. Получив от cleanup уведомление о поступлении новой почты, демон queue manager, управляющий очередями, перекладывает письмо в очередь active. Кстати, стоит заметить, что эта очередь очень маленького размера. В ней может находиться всего лишь несколько писем, которые в данный момент находятся в процессе доставки. Сделано это по двум причинам. Во-первых, для того чтобы при большой нагрузке менеджер очередей не потреблял слишком много памяти. Вторая причина состоит в том, что в случае, когда принимающая сторона не в состоянии получать письма с той скоростью, с которой Postfix старается их передать, приходится притормозить скорость отправки. С малой очередью это делать гораздо проще. Положив письмо в очередь active, демон queue manager создает запрос к процессу trivial-rewrite, с помощью которого удается определить точку назначения сообщения. В ответ можно будет лишь узнать, локальный ли получатель или на удаленной системе. Добавочную информацию о маршрутизации почты можно получить из файла transport. В зависимости от полученных данных queue manager входит в контакт с одним из следующих агентов доставки:

• Local используется для доставки почты внутри локальной системы. Умеет работать со стандартными для UNIX почтовыми ящиками. В случае, если для данного пользователя не заведено системных псевдонимов, в файле псевдонимов обычно это /usr/local/etc/postfix/aliases и нет файлов локального перенаправления .forward, которые любой пользователь может создать в своей домашней директории, то письмо сразу же попадает в целевой почтовый ящик. В противном случае письмо будет передано туда, куда они указывают. Возможности локального агента доставки на этом не заканчиваются. Одновременно могут работать несколько агентов локальной доставки, но в то же время параллельная доставка нескольких писем в один почтовый ящик обычно не практикуется. Несмотря на то, что агент локальной доставки может самостоятельно справиться со всеми проблемами, по желанию администратор может задействовать механизмы, позволяющие передоверить доставку в почтовый ящик внешним программам. Примером такой программы может служить широко известный многим администраторам procmail.

• Virtual агент виртуальной доставки представляет собой очень урезанную версию агента локальной доставки. Поэтому он может работать только с почтовыми ящиками в формате mailbox. В нем также отсутствует поддержка системной базы псевдонимов и файлов .forward. За счет таких ограничений данный агент доставки считается самым безопасным из всех. Благодаря своей природе он может легко работать с почтой, предназначенной для нескольких виртуальных доменов, располагающихся на одной и той же машине.

• SMTP-клиент, являющийся еще одним агентом, вступает в действие в тот момент, когда нужно доставить письмо пользователю удаленной системы. Обычно queue manager передает ему следующие данные: имя файла очереди, адрес получателя, хост или домен, куда нужно доставить почту, адрес отправителя. Первым делом с помощью DNS-запроса нужно получить список MX-серверов для целевого домена и отсортировать его по приоритету. Следующим шагом мы начинаем пробовать каждый адрес до тех пор, пока не найдем тот, который находится в рабочем состоянии. Обычно доставка идет одновременно сразу для нескольких доменов, поэтому в системах, через которые проходит большой поток почты, можно увидеть несколько SMTP-клиентов, работающих параллельно. Если доставка завершилась удачно, то SMTP-клиент модифицирует файл почтовой очереди так, чтобы было понятно, что он обработан. В противном случае данный клиент уведомляет queue manager либо о фатальной ошибке, либо о временных затруднениях. Проблемы первого типа могут быть вызваны отсутствием нужного пользователя удаленной системы, а вторые, к примеру, неполадками в сети или неработоспособностью принимающего сервера. В первом случае процесс bounce посылает отправителю оповещение о неудаче предпринятого действия и делает запись в протокол работы почтовой системы с помощью syslogd. А во втором письмо помещается в специальную очередь deferred, где оно должно дожидаться следующей попытки доставки.

• LMTP-клиент работает точно так же, как и SMTP-клиент, разве что протокол используется другой. LMTP специально создан для того, чтобы доставлять письмо на локальный или удаленный сервер, выделенный для хранения почтовых ящиков. В таком качестве могут выступать Courier- или Cyrus-сервер. Большим плюсом такого подхода к доставке писем является то, что один сервер Postfix может раздавать письма разным серверам почтовых ящиков. В то же время никто не мешает одному серверу почтовых ящиков получать почту от нескольких серверов postfix одновременно.

7. incoming queue - эта очередь используется только для обработки входящих сообщений. Затем процесс cleanup уведомляет процесс queue manager, управляющий всеми очередями о прибытии новой почты.

8. Deferred queue – эта очередь для не доставленных сообщений. В ней складируются отложенные до лучших времен письма. На файл с письмом ставится временной штамп, находящийся в будущем, соответственно следующая обработка этого файла произойдет именно в тот момент, на который указывает штамп. Периодически менеджер очередей проверяет, не пришло ли время предпринять следующую попытку доставки отложенных сообщений. В случае если есть необходимость выполнить очередную попытку раньше, чем истечет тайм-аут, нужно воспользоваться командой postfix flush.

9. Corrupt queue - Следующим интересным для нас понятием является очередь corrupt. В нее попадают все поврежденные, нечитаемые или неправильно отформатированные файлы почтовых очередей. Такая предосторожность позволяет изолировать подозрительные данные до тех пор, пока администратор системы не решит, что с ними делать. Впрочем, за несколько лет непрерывной работы моего сервера мне так и не удалось увидеть ни одного случая, чтобы сообщение попало в эту очередь.

10. Hold queue - Последняя из существующих в системе очередей называется hold. Здесь хранятся письма, доставка которых приостановлена по тем или иным причинам. Они будут находиться в этой очереди, пока не поступит специальная команда, выводящая их из состояния паузы.

3.5 Защита сервера Postfix встроенными средствами

3.5.1 Защита от атак из вне

Так как постфикс разделён на модули, то к разным модулям предъявляется разного рода уровень защиты. Например, модуль smtpd работает на порту и принимает все входящие соединения и по этой причине к нему предъявляется повышенный уровень защиты. Он работает от прав доступа postfix, а не от root к тому же, чтобы усложнить использование эксплойтов новых уязвимостей в этом модуле мы можем его запустить в chroot оболочке, которая ограничит работу демона в пределах одной директории и не даст доступ к системным командам. Главной модуль master, который управляет системой демонов, должен запускаться с правами root, поэтому этот демон самый уязвимый в системе. Для защиты демона master он содержит минимальное количество строк кода и написан максимально просто.

А также для защиты других модулей применяются следующие меры:

• Использование наименьших привилегий. Postfix может быть легко ограничен с помощью chroot и работать от имени самого бесправного пользователя.

• Ни одна из служебных программ не использует set-uid бит.

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

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

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

• Количество объектов, находящихся в памяти, строго ограничено. Соответственно даже под большой нагрузкой Postfix не будет потреблять слишком много системных ресурсов. Ведь скорость обработки почтовых сообщений вряд ли вырастет от того, что мы, к примеру, вместо десяти будем использовать двадцать буферов для обработки писем. Тут уже ограничителем выступает скорость аппаратных компонентов самой системы, а не количество объектов для обработки почты, хранящейся на диске.

• Также выполнение команд самой операционной системы будет производится в специально созданном для этих целей командном интерпретаторе “smrsh”, в котором можно выполнить только определенные команды не угрожающие безопасности.

3.5.2 Защита от DOS, DDOS, СПАМА

Так как требуется защитить почтовый сервер Postfix от DDOS – атак, DOS – атак, сделать пересылку спама более сложным заданием для этих целей.

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

Пример отправки почты при smtp сессии

1. telnet myserver.lv 25

2. HELO hostname

3. MAIL FROM: email_adress_ot_kogo

4. RCPT TO: email_adress_komu

5. DATA

6. .

7. QUIT

Описание:

1. соединяемся с почтовым сервером myserver.lv;

2. указываем свое hostname имя;

3. от кого будет послано письмо;

4. кому будет послано письмо, если адресатов больше 1, то команда повторяется несколько раз с нужными адресами;

5. команда, после которой идет данные, содержащиеся в письме (тело письма);

6. конец письма. После этого мы можем отослать еще письма. Для этого нам надо проделать все еще раз с пункта 3;

7. команда, говорящая об окончании smtp-сессии.

Теперь можно разработать эффективные методы борьбы с спамом и DOS атаками

1. smtp_always_send_ehlo = yes

2. disable_vrfy_command = yes

3. smtpd_error_sleep_time = 0

4. default_process_limit = 2000

5. smtpd_client_connection_count_limit = 500

6. bounce_size_limit = 2000

7. smtpd_timeout = 20s

8. smtp_helo_timeout = 10s

9. smtp_mail_timeout = 10s

10. smtp_rcpt_timeout = 10s

11. local_recipient_maps = $alias_maps, $virtual_mailbox_maps

12. smtpd_sender_restrictions = reject_unknown_sender_domain

13. smtpd_recipient_limit = 10000

14. smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Описание:

1. всегда слать команду HELO/EHLO с HOST. До сих пор многие программы для спам рассылок не включают в себя набор этих команд;

2. запрещаем использовать команду vrfy для определения пользователя на сервере;

3. отключает задержку при ошибке;

4. ограничивает число процессов, порождаемых сервером Postfix;

5. ограничивает число соединений с сервером должно не превышать в половину default_process_limit;

6. ограничивает размер письма при ошибке;

7. завершение smtp сессии при истечении данного времени;

8. завершение smtp сессии при истечении данного времени на этапе команды “HELO/EHLO”;

9. завершение smtp сессии при истечении данного времени на этапе команды “MAIL FROM”;

10. завершение smtp сессии при истечении данного времени на этапе команды ”RCPT TO”;

11. проверка, существует ли такой адрес в базе почтовых адресов и пользовательских псевдонимов;

12. запрещаем прием сообщения, если в DNS нет записей типа A или MX о посылающем сообщения;

13. максимальное количество адресов, на которые надо отправить сообщение;

14. запрещаем прием сообщения, если в DNS нет записей типа A или MX о посылающем сообщение, разрешаем пересылку почты только авторизовавшимся пользователям.

Данный набор опций в файле настроек main.cf существенно снижает издержки, связанные с некорректной отправкой почты.

3.7 Итог проделанной работы

В результате мы получаем систему, которая защищена от вирусов антивирусом Clamav. Пароли пользователей, зашифрованные по алгоритму MD5, имена пользователей, размер почтового ящика, пользовательские псевдонимы теперь хранятся в базе данных MySQL сервера. За счет того, что мы используем библиотеку SASL 2.x для авторизации пользователей пароли пользователей захешированы по MD5, запрещается пересылка через наш сервер почты не существующих пользователей или не авторизовавшихся, снижает риск рассылки через сервер спама. Ограничено число адресов, кому можно отправить одно письмо размером 1000 адресов, то есть одно письмо может иметь только до 1000 "RCPT TO:”.

Защита от DOS атак путем сокращения времени ожидания сокета: в полуоткрытом состоянии, в открытом состоянии, в состоянии ожидания “Time Out”. Путем сокращения времени smtp сессии после разных команд. Проверки на существования пользовательского почтового ящика и почтового псевдонима в базе MySQL. Проверки на существования домена, от адреса которого отсылается почта. Существенное ограничение и создание изолированной песочницы для демонов сервера Postfix и запуск их под привилегией ограниченного пользователя, исключение составляют local, virtual, master, scan.

3.8 Тестирование сервера Postfix

Оборудование сервера Солярки включает в себя: процессор P4-2.4 GHz, объём оперативной памяти 1024 Mb, скорость памяти 400 MHZ, жёсткий диск SATA 80 Gb. Сетевой адаптер 3Com 905 10/100 Fast Ethernet.

Программа Postal

Postal программа предназначена для тестирования почтовых серверов путем отсылки на них большого числа писем разного объема и сбор статистики.

Основные опции программы Postal:

postal <options> <smtp-server-ip> <user-list-filename>

-m <integer> – максимальный объём в килобайтах тела одного письма, выбирается случайным образом для каждого сообщения от 0 до этого установленного значения.

-с <integer> - максимальное число писем на одно соединение, выбирается случайным образом для каждого соединения от 0 до этого установленного значения.

-r <integer> - максимально количество сообщений, которое посылается за одну минуту.

smtp-server-ip – адрес почтового сервера

user-list-filename – файл с адресами почтовых ящиков пользователя.

Программа Postal, установленной на компьютере с операционной системой Linux, находящемся в одном сегменте локальной сети Fast Ethernet с сервером postfix.

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

Цель опытов увидеть нагрузку на программное обеспечение (загрузку процессора,загрузку памяти в процентах), количество переданных сообщений в минуту, размер сообщений выбирается случайным образом из диапазона от 20 килобайт до 100 килобайт в среднем 50-60 килобайт. Количество подключений за минуту. Одновременно сервер будет обрабатывать до 100 соединений.

3.8.1 Таблица

Производительность сервера Postfix.

Minutу		1	2	3	4	5
Messages		3141.4	2971.4	2694.6	2374.2	2432
data size (Kbyte)		157789.2	149398	135804.6	119583.4	119018.2
Total Connections		2105	1983.2	1790	1592.2	1582.4
HDD write (Kbyte/Sec.)		6105	5918	5655.6	5432.54	5473
Postfix	CPU %	28.04	26.34	25.72	27.36	26.04
	Memory %	28.6	29.2	29.4	29.6	29.2
ClamAV	CPU %	36.8	38.4	36.6	36.8	36.4
	Memory %	1.96	2.16	2.3	2.36	1.94
GLOBAL	CPU %	65.4	65.6	63.2	64.2	63.2
	Memory %	34.4	35.2	36	36.2	35.6

Postfix CPU % - нагрузка процессора от всех процессов Postfix

Postfix Memmory % - нагрузка памяти от всех процессов Postfix

Clamav CPU % - нагрузка процессора от антивируса ClamAV

Clamav Memmory % - нагрузка памяти от антивируса ClamAV

Global – глобальная зона в данном случае суммарная нагрузка всей системы в целом.

Результат тестов как видно из тестов таблицы 3.8.1, на 1 минуте сервер очень хорошо справляется с потоком присланных писем, на второй минуте производительность обработки присланных писем начинает падать до 4 минуту на пятой ситуация нормализуется. Как видно из результатов, перегрузка ресурсов системы не происходит, так как нагрузка на процессор не превышает 70%, а использованная оперативная память занята не более чем на 40%. Виду этого узким для производительности почтовой системы, но защищенным от атак является qmgr сервис доставки почты. Сервис по умолчанию настроен так, чтобы в очереди active хранилось малое количество почтовых сообщений для уменьшения вероятности лавинного скачка нагрузки как на CPU, так и на оперативную память. Так же нельзя допустить, чтоб у оперативной системы не осталось свободных ресурсов, обязательно необходимо иметь запас ресурсов. Нагрузка на сервер баз данных MySQL остается не изменой на всем этапе тестирования и равна около 2% от памяти и 2% от CPU по этой причине сервер баз данных MySQL не присутствует в таблице тестов. Параметр Global в данном тесте показывает загрузку всей системы в целом

4. ВИРТУАЛИЗАЦИЯ Зон и Контейнеров (Solaris Containers)

4.1 Описание технологии:

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

Технология – Sun Dynamic System Domains, доступная на серверах среднего и высшего уровней, уже много лет как эффективно используется при организации современных высоко-доступных информационных систем. Суть ее заключается в разделении аппаратных ресурсов SPARC-серверов на несколько независимых подсистем, каждая из которых, содержит собственную версию операционной системы.

К сожалению, технология организации аппаратных динамических доменов жестко привязана к линейке серверов Sun Fire midrange- и high-end- уровней и недоступна на серверах начального уровня и системах на платформе х86.

Здесь на «помощь» приходит инновационная технология – Solaris Containers, которая является одной из наиболее значимых возможностей новой версии операционной системы – Solaris 10.

Имея обобщенное название – N1 Grid Containers, данная технология состоит из двух компонентов: контейнеров (Solaris Containers) и зон (Solaris Zones).

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

Использование зон дает возможность создавать на одном сервере до 8192 виртуальных операционных систем - полностью изолированных, со своим пространством памяти, файловой системой и запущенными процессами. Пользователи в разных зонах могут отличаться друг от друга, и суперпользователь root из одной зоны может не иметь привилегий в другой зоне. Фактически это набор независимых виртуальных серверов Solaris 10, запущенных на одном аппаратном сервере.

Причем, важно отметить, данная технология не зависит от используемой аппаратной платформы и может применяться на всей линейке SPARC-серверов, 64-разрядных системах AMD Opteron и на платформе х86.

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

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

4.2 Технолошия зон

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

Во-первых, аппаратные ресурсы теперь тоже представлены в виде неких виртуальных устройств, которые распределяются между существующими зонами, а также, и между самими процессами, разделенными механизмами контейнеров. В качестве примера можно посмотреть информацию об имеющихся в системе процессорах – они «виртуальные»:

# psrinfo -v Status of virtual processor 0 as of: 05/31/2005 19:48:08 on-line since 05/23/2005 03:30:18. The i386 processor operates at 2400 MHz, and has an i387 compatible floating point processor.

Во-вторых, операционная система Solaris теперь разделена на два типа зон: глобальная зона (global zone) и не-глобальные зоны (non-global zone).

Глобальная зона – это именно та копия системы, которую вы устанавливаете непосредственно с дистрибутива на ваш сервер. Эта зона создается автоматически при инсталляции и неизменно присутствует в вашей системе. Фактически она несет на себе две функциональные обязанности:

• Общесистемное администрирование

• Является базовой зоной для создаваемых non-global зон

Только эта зона может быть загружена с аппаратных ресурсов системы, и все вопросы конфигурирования аппаратных устройств (добавление, динамическая реконфигурация и т.д.), настройка таблиц маршрутизации, а также, создание и управление non-global зонами – доступны только с нее.

Глобальная зона всегда имеет идентификатор ID=0 и имя global.

Non-global зоны – являются виртуальными копиями вашей системы. Создаются они только с глобальной зоны и унаследуют от нее ряд параметров и установленных продуктов. Каждая такая зона функционирует самостоятельно со своими сетевыми адресами, пользователями, сервисами и т.д. Все процессы, протекающие в любой из зон, полностью изолированы и от глобальной зоны и от остальных non-global зон. Зоны могут взаимодействовать между собой только через сетевые сервисы.

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

Функциональные возможности non-global зон довольно широки:

• Безопасность. Поскольку зоны полностью изолированы, то в случае «взлома» в одной из зон, злоумышленник не сможет получить доступа ко всем ресурсам системы, ограничившись лишь областью поврежденной им зоны.

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

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

• Универсальность. Используя ресурсы глобальной зоны, максимально упрощаются процедуры администрирования как системы в целом, так и отдельных зон в частности. Установка патчей и других программных продуктов в глобальной зоне, автоматически распространяется на все non-global зоны.

Создание, изменение, удаление и управление зонами осуществляет «глобальный» администратор, а вот администрирование внутри non-global зоны доступны только «локальному» администратору конкретной зоны.

Таблица 4.2.1

Таблица функциональных особенностей зон.

Глобальная зона (global zone)	Не глобальная зона (non-global zone)
ID всегда равен 0	ID назначается системой когда зона загружается
Одна копия Solaris ядра, с которой система загружается и функционирует	Не содержит собственного ядра, использует компоненты ядра глобальной зоны
Содержит полную инсталляцию системы Solaris и других продуктов	Может содержать только необходимую часть системы Solaris, взятую из глобальной зоны Использует установленные в глобальной зоне продукты
Может содержать дополнительные программные продукты	Может содержать дополнительные программные продукты, даже не установленные в глобальной зоне
Содержит конфигурационную информацию для глобальной зоны	Содержит настройки только для данной зоны
Полный контроль над всеми устройствами и файловыми системами	Возможность только пользоваться предоставленными устройствами
Содержит информацию и параметры non-global зон	Не содержит информации о других зонах
Создание, изменение, удаление и управление non-global зонами	Не может создавать, изменять, удалять и управлять зонами, даже собственной

Любая non-global зона может находится в одном из шести функциональных состояний:

• Configured – это состояние означает, что установлены все необходимые параметры для данной зоны.

• Incomplete – это состояние устанавливается до тех пор, пока не будет корректно завершена процедура инсталляции (или удаления) зоны.

• Installed – зона корректно инсталлирована в системе, необходимые продукты установлены в ее корневой путь. Виртуальная система в этом состоянии только установлена – не «запущена».

• Ready – в этом состоянии «запускается» виртуальная система: ядро запускает необходимые процессы, «поднимаются» виртуальные сетевые интерфейсы, монтируются файловые системы и конфигурируются выделенные устройства. На этом этапе зоне назначается уникальный ID. Пользовательские процессы в зоне пока не запущены.

• Running – в это состояние зона переходит, когда в ней запустится первый пользовательский процесс (init)

• Shutting down или Down – состояние остановки функционирования данной зоны

Перевод зоны в перечисленные выше состояния осуществляются «глобальным» администратором с помощью команд администрирования виртуальных зон.

Как было сказано раньше, компонент зон – главная составляющая технологии N1 Grid Containers. Смысл данного компонента заключается в следующем: в изоляции некой виртуальной области операционной системы в отдельную зону с ограниченными правами. В этой области, так же как и в глобальной зоне, работают программы, сервисы и контролируются как из глобальной зоны, так и из самой не глобальной зоны. Ограничения накладываются при создании не глобальной зоны и могут ограничивать такие вещи как:

• ограниченный доступ к аппаратным устройствам сервера;

• ограниченный доступ к файловой системе;

• ограниченный доступ к программам, установленных в операционной системе и доступных только в глобальной зоне;

• ограниченный доступ к ядру операционной системы.

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

• Virtual Private server – операционная система Linux.

• Jail, Chroot - операционная система FreeBSD, OpenBSD, NetBSD, Linux.

4.2.1 Конфигурирования не глобальной зоны

1 Шаг создание не глобальной зоны

1) zonecfg -z z_postfix

2) zonecfg:z_postfix> create

3) zonecfg:z_postfix> set zonepath=/chroot/ZONI/postfix

4) zonecfg:z_postfix> set autoboot=true

5) zonecfg:z_postfix> add fs
zonecfg:z_postfix:fs> set dir=/usr/local/etc/postfix/sql
zonecfg:z_postfix:fs> set special=/usr/local/etc/postfix/sql.non
zonecfg:z_postfix:fs> set type=lofs
zonecfg:z_postfix:fs> end

zonecfg:z_postfix> add fs
zonecfg:z_postfix:fs> set dir=/usr/local/var
zonecfg:z_postfix:fs> set special=/chroot/ZONI/var
zonecfg:z_postfix:fs> set type=lofs
zonecfg:z_postfix:fs> end

6) zonecfg:z_postfix> add net
zonecfg:z_postfix:net> set address=195.195.195.20

zonecfg:z_postfix:net> set physical=elxl0
zonecfg:z_postfix:net> end

7) zonecfg:z_postfix> add device

zonecfg:z_postfix:device> set match=/dev/pts*
zonecfg:z_postfix:device> end

zonecfg:z_postfix> add device

zonecfg:z_postfix:device> set match=/dev/tcp
zonecfg:z_postfix:device> end

zonecfg:z_postfix> add device

zonecfg:z_postfix:device> set match=/dev/ip
zonecfg:z_postfix:device> end

8) zonecfg:z_postfix> add attr
zonecfg:z_postfix:attr> set name=Postfix
zonecfg:z_postfix:attr> set type=string
zonecfg:z_postfix:attr> set value=”test_zone1”
zonecfg:z_postfix:attr> end

9) zonecfg:z_postfix> verify

10) zonecfg:z_postfix> commit

11) zonecfg:z_postfix> exit

Описание:

1) Запускаем команду zonecfg с указанием имени нашей будущей зоны. Поскольку зона еще не существует, рекомендуется ее создать.

2) Создаем зону.

3) Указываем, где будем размещать зону.

4) Зона должна автоматически загружаться, когда загружается глобальная зона.

5) Задаем дополнительно монтируемые в виртуальной зоне файловые системы в режиме запись, чтение. В данном примере указывается, что каталог /usr/local/etc/postfix/sql.non из глобальной зоны будет смонтирован виртуальной зоне z_postfix в каталог /usr/local/etc/postfix/sql. Так как сервисы из не глобальной зоны могут общаться с сервисами в глобальной зоне только через сетевые сервисы, а для работы сервера Postfix необходима связь с сервером баз данных MySQL сервером, тогда в директории /usr/local/etc/postfix/sql.non содержится связь не через 127.0.0.1, как это было раньше, а через 195.195.195.10(IP адрес глобальной зоны). У каждой зоны своя таблица маршрутизации и своя локальная сетевая петля, не доступная между сервисами разных зон (рисунок 3.3.1). Так же монтируется в режиме чтения, запись в рабочую директорию с очередями для сервера Postfix из глобальной зоны /chroot/ZONI/var в не глобальную зону /usr/local/var. Это необходимо потому, что директория из глобальной зоны /usr монтируется в не глобальную зону по умолчанию с правами только чтения. По этой причине необходимо это действие. В дополнение можно отметить, что, так как используется защита модулей сервера Postfix, в chroot это требует наличие копии таких файлов (именно той зоны, в которой он работает) как:

1. /etc/resolv.conf содержащий адреса DNS серверов.

2. /etc/hosts содержащий хост имена и IP-адреса.

3. /etc/services содержащий сервисы соотношения сервиса к сетевому порту.

Если не перемонтировали директорию из глобальной зоны в не глобальную в режиме запись, чтение, то сервер Postfix не смог бы складывать почту в такие директории как incoming, hold, defered, active, а так же не смогли бы работать модули сервера Postfix в режиме chroot, так как в не существовала файлов resolv.conf, hosts.

6) Устанавливаем сетевые устройства. Указываем для них сетевой адрес и «реальный» сетевой интерфейс, на который будет конструироваться виртуальная не глобальная зона. Для каждой виртуальной не глобальной зоны должен быть свой уникальный адрес. Для зоны z_postfix устанавливаем IP адрес 195.195.195.20.

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

8) Задаем комментарии для данной зоны.

9) Проверяем правильность установленных параметров.

10) Сохраняем внесенные конфигурационные параметры зоны.

11) Выходим из интерактивного режима конфигурирования виртуальной зоны.

Из глобальной зоны по умолчанию при создании не глобальной зоны монтируются следующие каталоги в режиме только чтение /usr,/lib,/platform,/sbin.

И если изобразить графически наша зона будет выглядеть следующим образом (Рисунок 4.2.2).

Рисунок 4.2.2

Топология сети с учётом виртуальной машины

Рисунок 4.2.3

Составная схема глобальной и не глобальной зоны по дереву файловой системы:

Если же рассматривать внутри сервера составную схему глобальной и не глобальной зоны по дереву файловой системы (Рисунок 4.2.3).

Так как не глобальная зона z_postfix достижима из глобальной по этой причине, она входит в состав глобальной зоны, но в свою очередь глобальная зона не входит в состав не глобальной z_postfix. Пунктирными линиями серого цвета соединены директории глобальной зоны, монтируемые в директории не глобальной зоны z_postfix с правами только чтение, зелёной пунктирной линией соединены директории глобальной зоны, монтируемые в не глобальную зону z_postfix с правами чтение, запись.

4.2.2 Сборка зоны

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

# zoneadm -z z_postfix install

Preparing to install zone <z_postfix>.

Creating list of files to copy from the global zone.

Copying <3368> files to the zone.

Initializing zone product registry.

Determining zone package initialization order.

Preparing to initialize <839> packages on the zone.

Initialized <839> packages on zone.

Successfully initialized zone <z_postfix>.

4.2.3 Запуск зоны

Для запуска зоны необходимо вести команду:

# zoneadm - z zone1 boot

Так как при конфигурации зоны мы ввели параметр “set autoboot=true”, что означает, что не глобальная зона z_postfix будет грузится автоматически с загрузкой глобальной зоны, то есть каждый раз при загрузки самой операционной системы Solaris 10 необходимости вводить каждый раз команду для загрузки не глобальной зоны z_postfix нет необходимости.

Теперь необходимо зайти и отконфигурировать не глобальную зону, так же как и глобальную зону в пункте 10. По умолчанию при первой загрузки не глобальной зоны z_postfix будет грузится множество сервисов и программ, которые нам не нужны. Для входа в зону вводим команду:

#zlogin -C -e\@ z_postfix

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

1. Язык и используемую локальную кодировку символов.

2. Тип терминала (VT100,XTERM,DTTERM,....).

3. Хост имя зоны в месте с доменом.

4. Адрес DNS сервера.

Да кстати можно сразу изменить конфиг SSH сервера чтоб root или кто нибудь другой имел доступ по протоколу ssh к зоне z_postfix для удобства.

Перед запуском Postfix’a надо изменить IP адресс обращения к базе MySQL в файлах находящихся в директории “sql” на IP адрес 195.195.195.10 и также открыть дырку в файрволе с IP 195.195.195.20 на 195.195.195.10 порт 3306 если файрвол конечно установлен на этом же компьютере.

Теперь можно запустить сервер Postfix и антивирус ClamAV внутри не глобальной зоны z_postfix.

Для того чтобы сервер Postfix и антивирус ClamAV загружались в месте с загрузкой не глобальной зоны z_postfix, можно воспользоваться системой SMF внутри самой не глобальной зоны z_postfix, она будет абсолютно не зависима от системы SMF в глобальной зоне также, как и любая программа или сервис, запущенный в не глобальной зоне z_postfix.Да кстати вычищать зону z_postfix так же как и глобальную необходимо так как не глобальные зоны наследуют все то что было в первоначальном варианте глобальной зоны то есть в первый за груз Солярки.

4.3 Тестирование почтового сервера Postfix в не глобальной зоне z_postfix.

Задача протестировать сервер Postfix и антивирус ClamAV в не глобальной зоне z_postfix и определить затраты аппаратных ресурсов при работе сервера Postfix и антивируса ClamAV в не глобальной зоне z_postfix. Цель эффективности работы не глобальной зоны. Тест будет проходить по одинаковой также как и в разделе 3.8.

Таблица 4.3.1

Таблица производительности системы.

Minutе		1	2	3	4	5
Messages		3092	2919.5	2753.25	2552.5	2440
data size		156032.5	146663.5	138050.5	128103.5	124461
Total Connections		2081	1946	1839.25	1698	1622
M(write)/sec-M(read)/sec		6056.5	5557.75	5785.25	5655.5	5391.5
Postfix	CPU	31.375	29.925	30.575	31.875	32.5
	Memory	22.625	22.975	23.075	23.2	23.925
ClamAV	CPU	35.75	34	36.25	34.5	32.5
	Memory	2.225	1.875	2.175	2.1	2.25
GLOBAL	CPU	1.775	1.7	1.75	1.725	1.65
	Memory	14	14	14	14	14
z_postfix	CPU	67.5	63.75	67	67.25	65
	Memory	24.75	25.5	25.25	26	26
Global + z_postfix	CPU	69.275	65.45	68.75	68.975	66.65
	Memory	38.75	39.5	39.25	40	40

Если проанализировать таблицу 3.8.1 и таблицу 4.3.1 при работе в глобальной зоне сервер Postfix расходует меньше на 2%-5% процессорного времени, но при этом в глобальной зоне сервер Postfix расходует больше оперативной памяти на 2%-5%. Затраты ресурсов на антивирус ClamAV остается не измененным как для глобальной зоны, так и для не глобальной зоны.

Сравнение затрат ресурсов на работу только глобальной зоны (Таблица 3.8.1) и суммы не глобальной и глобальной зоны (Таблица 4.3.1) показывает, что в случае с двумя работающими зонами затраты на процессорное время выше 3%-4%, затраты оперативной памяти выше на 4%. Также надо учитывать что в не глобальной зоне для удобства, работал такой сервис как SSH который требует 1%-3%, как процессорного времени так и оперативной памяти. Виду выше перечисленного можно сделать вывод что общие затраты на работу дополнительно одной не глобальной зоны с работающими сервисами и программами не превышает 2% как памяти так и процессорного времени.

4.4 Технология Контейнеров (Ресурс Менеджер).

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

Использование технологии управления ресурсами позволяет:

• Распределять аппаратные ресурсы системы между различными задачами

• Контролировать эффективность работы процессов и динамически выделять им необходимые ресурсы

• Вести статистику работы процессов

4.5 Управление ресурсами CPU

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

4.5.1 Метод Fair Share Scheduler (FSS)

При распределении ресурсов процессора, в Sun Solaris, по умолчанию используется механизм временного разделения (TS – timesharing scheduling). Согласно этому механизму, система пытается распределить ресурсы процессора приблизительно равными долями между всеми запущенными процессами. С использованием ряда параметров *.max-cpu-time можно устанавливать время использования процессора для необходимых задач и процессов. Но время использования процессора не позволяет четко задать, в процентном отношении, ресурс его использования.

Если стоит задача гарантированного выделения необходимой части вычислительной мощности процессоров, то в этом случае, применяется технология долевого распределения (FSS – Fair Share Scheduler). С помощью механизмов FSS можно выдавать определенное количество частей (shares) использования процессорных ресурсов системы для необходимых вам проектов.

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

Главным отличием данного методы является то, что, если проект, на который выделено определенная часть ресурсов, не активен в данную минуту, то его ресурсы могут использовать другие проекты нуждающейся в этом, то есть динамическое управление ресурсами. Так как мы провели тесты в прошлом, в котором было видно, что около 70% процессорного времени уходит для не глобальной зоны с этой целью мы будем делать разделение процессорного времени на глобальную зону = 15%, на не глобальную зону z_postfix = 85%.

4.5.2 Настройка метода FAIR SHARE SCHEDULER (FSS).

1) dispadmin –d FSS

2) pooladm –e

init 6

3)pooladm -x

pooladm -s

poolcfg -f create pool work-zpool ( string pool.scheduler = "FSS" )

pooladm -c

4)zoneadm –z z_postfix halt

zonecfg –z z_postfix

set pool=work-zpool

add rctl

set name=zone.cpu-shares

add value (priv=privileged,limit=85,action=none)

end

zoneadm –z z_postfix boot

5)prctl –n zone.cpu-shares –v 15 –r –i zone global

Сразу хочу сказать я забыл команду с помощью корой можно посмотреть сколько кому выделено ресурсов CPU, но вы её можете найти по MAN’у

Описание:

1) Переводим всю систему под метод управления FSS по умолчанию.

2) Активизируем контроль над пулами устройств. Перезапускаем систему для вступления в силу новых изменений.

3) Создаем пул ресурсов для не глобальной зоны и прописываем туда метод по умолчанию FSS, сохраняем изменения в файл /etc/pooladm.conf.

4) Останавливаем работу не глобальной зоны z_postfix для внесения изменений в работу. Входим в режим конфигурирования зоны. Устанавливаем пул устройств, созданных специально для не глобальной зоны z_postfix. Устанавливаем переменную зоны zone.cpu-shares и значение 85, что обозначает 85 долей использования ресурса процессора между проектами. Выходим из режима конфигурации. Загружаем зону.

5) По умолчанию для глобальной зоны выделено всего 1 доля использования. По этой причине мы должны повысить это значение до 15. И желательно занести эту команду в загрузочный скрипт /lib/svc/method/svc-zone для того, чтобы после каждой загрузки системы для глобальной зоны выставлялась это значение.

Если пытливым умам захотелось проверить как это работает на практике то ниже преведёный скрипт загружает CPU по самые возможности. Даный скрипт запускаете в глобальной зоне и не в глобальной зоне и из глобальной зоны запускаете команду

“prstat –Z” она покажет использованое CPU в процентах между зонами.

#!/usr/bin/perl

print "eating the CPUs\n";

foreach $i (1..16) {

$pid = fork();

last if $pid == 0;

print "created PID $pid\n";

}

while (1) {

$x++;

}

4.6 Разделение ресурсов оперативной памяти

Технология разделение используемого объёма оперативной памяти на момент написания данной работы, описывалась только для отдельных запусков приложений, но не для ограничения оперативной памяти, для какой-нибудь не глобальной или глобальной зоны. Соответственно есть существенный недостаток, так как для ограничения работы приложения или сервиса внутри зоны нельзя ограничить использования оперативной памяти для этой зоны и ограничения будут распространятся на приложения, работающие в этой зоне. Ограничения на оперативную память накладываются только при запуске приложения той зоны, в которой данное приложение будет работать.

4.6.1 Установка ограничений на использования оперативной памяти

1) rcapadm –E

2) projadd –K ‘rcap.max-rss=536870912’ workproj1

3) /usr/bin/newtask –p workproj1 /usr/local/bin/postfix/postfix

Описание:

1) Активизация rcap демона отвечающего за разграничения объёма используемой памяти.

2) Создания системного проекта, в переменой которого мы указываем максимальный размер оперативной памяти (512 мегабайт), которой может оперировать приложение или сервис, запущенный в рамках данного проекта.

3) запуск сервера Postfix в рамках проекта ограниченного максимальным объёмом оперативной памяти.

4.7 Тестирование почтового сервера Postfix в не глобальной зоне z_postfix с разграничением ресурсов.

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

Разграничения использования ресурса процессора по 85% на глобальную зону и 15% для не глобальной зоны, а так же что максимальный объём памяти, используемый сервером Postfix.

Таблица 4.7.1

Тест производительности

Minutе		1	2	3	4	5
Messages		3049.6	2911.6	2634.8	2586.4	2265.2
data size		153565.6	151841	132414.6	130113	114217.4
Total Connection		2045.6	2009.6	1764.8	1717.6	1494.4
M(write)/sec-M(read)/sec		5809.2	5720.7	5727.2	5680.98	5195.96
Postfix	CPU	28.98	32.76	31.86	32.36	32.1
	Memory	24.68	25.78	25.2	24.9	25.72
ClamAV	CPU	32.2	30	33.2	29.4	30
	Memory	1.94	1.54	1.94	2.22	2.08
GLOBAL	CPU	1.4	1.32	1.24	1.3	1.22
	Memory	16.8	16.8	16.8	16.8	16.8
z_postfix	CPU	61.6	63.2	65	60.6	62.8
	Memory	26.6	27.6	27.2	26.6	27.4
Global + z_postfix	CPU	63	64.52	66.24	61.9	64.02
	Memory	43.4	44.4	44	43.4	44.2