Новости :

Защищаем Apache 2. Шаг за шагом

Защищаем Apache 2. Шаг за шагом

Артур Май
При выборе Web сервера, Apache очень часто побеждает своих конкурентов из-за стабильности, высокой производительности, открытого исходного кода и множеством других преимуществ. Сейчас Apache существует в виде двух версий - устойчивая версия 1.3, используемая миллионами пользователей и, с другой стороны, усовершенствованная и перепроектированная версия 2.0.

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

Продолжая серию предыдущих статей (Apache, PHP, MySQL), в этой статье мы расскажем о пошаговой установке и конфигурировании Apache 2.0, чтобы снизить риск неавторизованного доступа или успешного взлома в случае применения новой уязвимости, обнаруженной в Apache Web сервере. В результате, можно будет пользоваться новыми особенностями Apache Web сервера 2.0, не слишком волнуясь о новых ошибках защиты, которые могут представлять серьезную угрозу

Функциональные требования

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

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

Поэтому, перед установкой Apache 2, очень важно знать, какие функциональные возможности мы действительно ожидаем от Web сервера. Это позволит нам подготовить список модулей, которые мы оставим включенными, а остальные будут отключены в процессе установки.

Согласно этому правилу, мы предполагаем, что будут использоваться только следующие основные особенности Apache 2:

  1. Обрабатываться будут только статические HMTL страницы.
  2. Сервер должен поддерживать механизм виртуального хостинга.
  3. Доступ к некоторым Web страницам может быть ограничен по IP адресам или пользователям (basic authentication).
  4. Сервер должен регистрировать все Web запросы (включая информацию о web браузере).
Обратите внимание, что вышеупомянутые функциональные возможности не поддерживают CGI сценарии, SSL протокол или другие полезные особенности Apache сервера. Это сделано так, потому что главная цель статьи состоит в том, чтобы представить общий метод защиты Apache 2.0, не сосредотачиваясь на специфическом выполнении. Если есть потребность в дополнительных функциональных возможностях, читатели
  • могут использовать представленное решение как отправную точку, и расширить его, включая дополнительные модули, например mod_ssl, mod_cgi и тд.

    Предположения защиты

    Чтобы обеспечить наиболее возможный уровень защиты, и в то же самое время сделать это решение переносимым среди различных Linux/BSD систем, мы будем использовать следующие уровни защиты:

    Операционная система

    • операционная система должна быть укреплена в максимально возможной степени; все ненужные компоненты должны быть удалены из системы.
    • Операционная система не должна позволять выполнять программы на стеке (если поддерживается).
    • Все ненужные сетевые службы должны быть заблокированы.
    • Число SUID/SGID файлов должно быть минимизировано.

    Apache web server

    • Включены быть только абсолютно необходимые модули Apache; остальное должно быть заблокировано в процессе компиляции
    • Должны быть выключены все диагностические web-страницы и автоматическая служба индексации каталога.
    • Cервер должен раскрыть наименьшее количество количества информации о себе насколько возможно - политика запутывания. Хотя это - не реальный уровень защиты, его применение делает возможные проникновения трудно осуществимыми.
    • Web сервер должен выполнятся под выделенным UID/GID, который не используется другими системными процессами.
    • Apache процесс должен иметь ограниченный доступ к файловой системе (chrooting).
    • В Apache chrooted среде не должно присутствовать никаких программных оболочек (/bin/sh, /bin/csh и т.п.) - это позволяет намного усложнить процесс выполнения вредоносного кода.
    Установка операционной системы Прежде всего, мы должны выбрать операционную систему, на которой будет выполняться Web сервер. Основная часть этой статьи описывает защиту Apache на FreeBSD (5.1), однако читатели могут свободно использовать их любимую Unix, BSD, Linux или Linux-подобную операционную систему.

    Относительно наших предположений защиты, после установки операционной системы она должна быть защищена против удаленных и локальных нападений. Независимо от выбора UNIX/Linux/BSD дистрибутива, очень важно установить только основную операционную систему и удалить любые избыточные пакеты и применять на современном уровне исправления к ядру и всему установленному программному обеспечению.

    Также рекомендуют периодически синхронизировать локальное время с доверенным сервером времен, используя часы с сервера времени, которому доверяют, используя Network Time Protocol (NTP), и посылать журналы регистрации удаленному, выделенному регистрационному серверу.

    После того, как система подготовлена, мы можем начать устанавливать Apache 2.0. Первым шагом мы должены добавить новую группу и правильного пользовател,я названного Apache. Пример для FreeBSD показан ниже:

    pw groupadd apache
    pw useradd apache -c "Apache Server" -d /dev/null -g apache -s /sbin/nologin
    
    Дочерние Apache процессы должны выполнятся с привилегиями группы и пользователя apache. вышеупомянутая учетная запись будет выделена Apache Web серверу, это поможет обеспечить разделение привилегий и избежать потенциальных проблем защиты, когда несколько различных процессов выполняются под той же самой учетной записью, например под пользователем nobody.

    Загрузка программного обеспечения

    Далее, нам необходимо загрузить последнюю версию Apache Web сервера из Web сайта Apache. Так как мы хотим отключить ненужные модули в процессе компиляции, очень важно загрузить исходный код Apache. Также важно проверить загруженное программное обеспечение против PGP сигнатуры, чтобы удостовериться, что загруженная версия немодифицирована.
    lynx http://httpd.apache.org/download.cgi
        
    gpg --import KEYS
    gpg httpd-2.0.49.tar.gz.asc
        gpg: Good signature from "Sander Striker "
    tar zxvf httpd-2.0.49.tar.gz
    cd ./httpd-2.0.49/
    

    Выбор Apache модулей

    После того, как распакован исходный код Apache, мы должны выбрать, какие модули останутся, и какие должны быть удалены. Краткое описание всех модулей, доступных в Apache 2.0, могут быть найдены в http://httpd.apache.org/docs-2.0/mod/. Выполняя функциональные возможности и требования защиты, принятые в начале этой статьи, мы компилируем только следующие модули:

    Имя модуля

    Описания

    core

    Основное ядро Apache, необходимое для инсталляции.

    http_core

    Основное HTTP ядро, необходимое для Apache 2.0 инсталляции.

    prefork

    Модуль мультизадачного режима (MPM), для обеспечения многозадачной работы.

    mod_access

    Обеспечивает управление доступом, основанным на имени хоста клиента, IP-адресе и других характеристиках запроса клиента. Поскольку этот модуль необходим, чтобы использовать директивы "order", "allow" и "deny", он должен оставаться доступным.

    mod_auth

    Требуется для осуществления пользовательской идентификации (базовая HTTP идентификация).

    mod_dir

    Требуется, для поиска и обслуживания каталога с индексными файлами: "index.html", "default.htm", и т.д.

    mod_log_config

    Требуется для регистрации запросов, сделанных на сервер.

    mod_mime

    Требуется для установки набора символов, content encoding, обработчика, content-language, и документов MIME типа.

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

    Компилирование и установка программного обеспечения

    В этом шаге мы конфигурируем, компилируем, и устанавливаем Apache Web сервер следующим образом:
    ./configure  
    --prefix=/usr/local/apache2  
    --with-mpm=prefork  
    --disable-charset-lite  
    --disable-include  
    --disable-env  
    --disable-setenvif  
    --disable-status  
    --disable-autoindex  
    --disable-asis  
    --disable-cgi  
    --disable-negotiation  
    --disable-imap  
    --disable-actions  
    --disable-userdir  
    --disable-alias  
    --disable-so 
    make 
    su 
    umask 022 
    make install 
    chown -R root:sys /usr/local/apache2
    
    
    После того, как Apache установлен, мы должны удостовериться, что используются только следующие модули:
     /usr/local/apache2/bin/httpd -l 
    Compiled in modules: 
      core.c 
      mod_access.c 
      mod_auth.c 
      mod_log_config.c 
      prefork.c 
      http_core.c 
      mod_mime.c 
      mod_dir.c
     
    

    Конфигурирование Apache

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

    Таким образом, мы должны удалить/usr/local/apache2/conf/httpd.conf файл и создать новый httpd.conf в его месте, со следующим содержанием:

    # =================================================
    # Basic settings
    # =================================================
    Listen 0.0.0.0:80
    User apache
    Group apache
    ServerAdmin webmaster@www.ebank.lab    
    UseCanonicalName Off
    ServerSignature Off
    HostnameLookups Off
    ServerTokens Prod
    ServerRoot "/usr/local/apache2"
    DocumentRoot "/www"
    PidFile /usr/local/apache2/logs/httpd.pid
    ScoreBoardFile /usr/local/apache2/logs/httpd.scoreboard
    
        DirectoryIndex index.html
    
    
    # =================================================
    # HTTP and performance settings
    # =================================================
    Timeout 300
    KeepAlive On
    MaxKeepAliveRequests 100
    KeepAliveTimeout 15
    
    
        MinSpareServers 5
        MaxSpareServers 10
        StartServers 5
        MaxClients 150
        MaxRequestsPerChild 0
    
    
    # =================================================
    # Access control
    # =================================================
    
        Options None
        AllowOverride None
        Order deny,allow
        Deny from all
    
    
        Order allow,deny
        Allow from all
    
    
    
        Order allow,deny
        Allow from all
    
    
    # =================================================
    # MIME encoding
    # =================================================
    
        TypesConfig /usr/local/apache2/conf/mime.types
    
    DefaultType text/plain
    
    
        AddEncoding x-compress .Z
        AddEncoding x-gzip .gz .tgz
        AddType application/x-compress .Z
        AddType application/x-gzip .gz .tgz
        AddType application/x-tar .tgz
    
    
    # =================================================
    # Logs
    # =================================================
    LogLevel warn
    LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
    LogFormat "%h %l %u %t "%r" %>s %b" common
    LogFormat "%{Referer}i -> %U" referer
    LogFormat "%{User-agent}i" agent
    ErrorLog /usr/local/apache2/logs/error_log
    CustomLog /usr/local/apache2/logs/access_log combined
    
    # =================================================
    # Virtual hosts
    # =================================================
    NameVirtualHost *
    
           DocumentRoot "/www/www.ebank.lab"
           ServerName "www.ebank.lab"
           ServerAlias "www.e-bank.lab"
           ErrorLog logs/www.ebank.lab/error_log
           CustomLog logs/www.ebank.lab/access_log combined
    
    
    
           DocumentRoot "/www/www.test.lab"
           ServerName "www.test.lab"
           ErrorLog logs/www.test.lab/error_log
           CustomLog logs/www.test.lab/access_log combined
    
    
    По сравнению с заданным по умолчанию файлом конфигурации, были сделаны следующие важные изменения:
    • Уменьшено до минимума число допускаемых модулей
    • Процессы Apache (кроме rootпроцесса) установлены, чтобы выполнятся с уникальными привилегиями пользователя/группы.
    • Apache раскрывает наименьшее количество информации о себе насколько это возможно.
    • Установлены более ограниченные права доступа к содержанию сайта.
    Согласно нашим требованиям, вышеупомянутая конфигурация предполагает, что есть два виртуальных хоста, поддержавшие Apache:
    • www.ebank.lab(псевдоним:www.e-bank.lab)
    • www.test.lab
    Содержание вышеупомянутых виртуальных хостов физически хранятся под /www каталогом, поэтому перед запуском Apache, мы также должны создать соответствующие каталоги с типовыми web-страницами:
    mkdir -p /www/www.ebank.lab
    mkdir -p /www/www.test.lab
    echo "eBank.labeBank.lab 
         works!" > /www/www.ebank.lab/index.html
    echo "test.labTest.lab 
         works!" > /www/www.test.lab/index.html
    chmod -R 755 /www 
    chown -R root:sys /www
    
    
    Мы должны также подготовить каталоги для хранения журналов регистраций:
    mkdir -p /usr/local/apache2/logs/www.ebank.lab 
    mkdir -p /usr/local/apache2/logs/www.test.lab 
    chmod -R 755 /usr/local/apache2/logs 
    chown -R root:sys /usr/local/apache2/logs 
    
    Наконец, мы можем попробовать выполнить Apache, и проверить, что все работает должным образом:
    /usr/local/apache2/bin/apachectl start
    
    Если доступен сайт www.ebank.lab через web-браузер, мы можем завершение Apache:
    /usr/local/apache2/bin/apachectl stop 
    
    И затем перейдем к chroot сервера. Если возникли проблемы, должны быть проанализированы журналы регистрации или команда truss (для BSD и Solaris пользователей) следующим образом:
    truss /usr/local/apache2/bin/httpd
    
    Обратите внимание, что для Linux пользователей, эквивалентная команда - strace. Анализ данных, представленных командами truss (или strace), могут помочь в решении возникших проблем.

    Chrooting сервера

    Далее, ограничим доступ Apache процесса к файловой системе. Техника chrooting подробно описана в предыдущей статье, поэтому в этом пункте мы просто создадим структуру директорий для нашего нового Apache:
     
    mkdir -p /chroot/httpd/dev 
    mkdir -p /chroot/httpd/etc 
    mkdir -p /chroot/httpd/var/run 
    mkdir -p /chroot/httpd/usr/lib 
    mkdir -p /chroot/httpd/usr/libexec 
    mkdir -p /chroot/httpd/usr/local/apache2/bin 
    mkdir -p /chroot/httpd/usr/local/apache2/lib 
    mkdir -p /chroot/httpd/usr/local/apache2/logs/www.ebank.lab 
    mkdir -p /chroot/httpd/usr/local/apache2/logs/www.test.lab 
    mkdir -p /chroot/httpd/usr/local/apache2/conf 
    mkdir -p /chroot/httpd/usr/local/lib 
    mkdir -p /chroot/httpd/www
    
    Владелец весь выше каталогов должен быть root, и права доступа не должны позволить обычным пользователям выполнять любые изменения в этих каталогах:
    chown -R root:sys /chroot/httpd 
    chmod -R 0755 /chroot/httpd
    
    Затем, мы создадим специальный файл устройства,/dev/null:
    ls -al /dev/null 
      crw-rw-rw- 1 root wheel 2, 2 Mar 14 12:53 /dev/null 
    mknod /chroot/httpd/dev/null c 2 2 
    chown root:sys /chroot/httpd/dev/null 
    chmod 666 /chroot/httpd/dev/null
    
    
    Мы также должны создать /chroot/httpd/dev/log устройство, которое необходимо для нормальной работы сервера. В случае нашей FreeBSD системы, нужно добавить следующую строкe к /etc/rc.conf: syslogd_flags="-l /chroot/httpd/dev/log"

    Для того, чтобы вступили в силу наши изменения, мы также должны перезапустить syslogd демон с новым параметром:

    kill `cat /var/run/syslog.pid` 
    /usr/sbin/syslogd -ss -l /chroot/httpd/dev/log 
    
    Далее скопируем все необходимые программы, библиотеки и файлы конфигурации в новое дерево каталогов. В случае FreeBSD 5.1 список требуемых файлов следующий:
    cp /usr/local/apache2/bin/httpd /chroot/httpd/usr/local/apache2/bin/ 
    cp /usr/local/apache2/lib/libaprutil-0.so.9 /chroot/httpd/usr/local/apache2/lib/ 
    cp /usr/local/apache2/lib/libapr-0.so.9 /chroot/httpd/usr/local/apache2/lib/ 
    cp /usr/local/apache2/conf/mime.types /chroot/httpd/usr/local/apache2/conf/ 
    cp /usr/local/apache2/conf/httpd.conf /chroot/httpd/usr/local/apache2/conf/ 
    cp /usr/local/lib/libexpat.so.4 /chroot/httpd/usr/local/lib/ 
    cp /usr/lib/libc.so.5 /chroot/httpd/usr/lib/ 
    cp /usr/lib/libcrypt.so.2 /chroot/httpd/usr/lib/ 
    cp /usr/lib/libm.so.2 /chroot/httpd/usr/lib/ 
    cp /usr/libexec/ld-elf.so.1 /chroot/httpd/usr/libexec/ 
    cp /var/run/ld-elf.so.hints /chroot/httpd/var/run/ 
    cp /etc/hosts /chroot/httpd/etc/ 
    cp /etc/nsswitch.conf /chroot/httpd/etc/ 
    cp /etc/resolv.conf /chroot/httpd/etc/ 
    cp /etc/group /chroot/httpd/etc/ 
    cp /etc/master.passwd /chroot/httpd/etc/passwords
    
    В случае других Unix, BSD, Linux и Linux-подобных систем, список требуемых файлов может быть определен, используя команды типа ldd, strace, , truss или strings, как было описанр в предыдущей статье. После того, как сделаны вышеупомянутые шаги, мы должны подготовить базу данных пароля, которая должна присутствовать в chrooted файловой системе. Таким образом, от /chroot/httpd/etc/passwords и/chroot/httpd/etc/group мы должны удалить все строки кроме apache. Затем, мы должны формировать базу данных пароля следующим образом:
    cd /chroot/httpd/etc 
    pwd_mkdb -d /chroot/httpd/etc passwords 
    rm -rf /chroot/httpd/etc/master.passwd
    
    Вышеупомянутые команды должны быть выполнены при использовании FreeBSD. В других системах может быть достаточно редактировать /chroot/httpd/etc/passwd и /chroot/httpd/etc/shadow файлы. Наконец, мы можем копировать типовое содержание сайта к chrooted среде:
    cp -R /www/* /chroot/httpd/www/ 
    
    И проверить корректную работу Apache Web сервера:
    chroot /chroot/httpd /usr/local/apache2/bin/httpd
    

    Заключительные шаги

    Если теперь ваш Apache работает должным образом, нам осталось создать сценарий, который запустит Apache во время начальной загрузки системы. Для этого может использоваться следующий сценарий: #!/bin/sh CHROOT=/chroot/httpd HTTPD=/usr/local/apache2/bin/httpd PIDFILE=/usr/local/apache2/logs/httpd.pid echo -n " apache" case "" in start) /usr/sbin/chroot $CHROOT $HTTPD ;; stop) kill `cat ${CHROOT}/${PIDFILE}` ;; *) echo "" echo "Usage: `basename {PAGE_ROW_TEXT}` {start|stop}" >&2 exit 64 ;; esac exit 0 Вышеупомянутый сценарий должен быть скопирован в каталог, где находятся по умолчанию сценарии запуска. В случае с FreeBSD это - /usr/local/etc/rc.d каталог. Права доступа к тому файлу должны быть установлены следующим образом:
    chown root:sys/usr/local/etc/rc.d/apache.sh 
    chmod 711/usr/local/etc/rc.d/apache.sh 
    
    

    Выводы

    Главная цель этой статьи состояла в том, чтобы представить метод защиты Apache 2.0, который позволяет читателям смягчать риск успешного взлома, даже если используется новая уязвимость. Было показано, как установить Apache с минимальным номером модулей, как установить более ограничительную конфигурацию, и как осуществить защиту против большого количества эксплоитов, выполняя Web сервер в chrooted среде, без использования любых программ оболочки. И хотя никакой метод не может предоставить 100% защиты, применяя вышеупомянутые рекомендации, будет намного труднее выполнить нападение против Apache 2.0 по сравнению с заданной по умолчанию инсталляцией.

Статья взята с сайта OpenNet

Комментарии: (0) | Безопасность | 2006-06-07

Создание безопасного высоко производительного почтового сервера на базе Solaris и Postfix

Создание безопасного высоко производительного почтового сервера на базе Solaris и Postfix

Автор:Zedis

Предисловие

Задание

АННОТАЦИЯ

ВВЕДЕНИЕ

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, а так же с некоторыми дистрибутивами Linuxa.Ну и соответственно тему диплома хотел взять из этой области, что ни будь связанное с защитой сетевых сервисов от атак. При настройки серверов, к примеру 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-sol 8-intel-local .gz, не смотрите на то что это компилятор для Solaris 8 он нам просто послужит временным компилятором для одной установки и всё. Потом распаковываем “gzip –d gcc-2.95.3-sol 8-intel-local .gz

И устанавливаем в систему “pkgadd –d gcc-2.95.3-sol 8-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 checkera сразу хочу оговорится я перепробовал целую кучу 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 протокола, так как уже не раз находили в нём дырки. Да и сам сервер к сожалению можно запустить только от roota, Но у меня не было времени да и желания изучать Дакота. Да установку и настройку Courier IMAP я рассматривать не буду.


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

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


Ниже приводится маленький скрипт для компиляции Postfixa, да кстати в процессе инсталляции будут заданы вопросы о том какой “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 демону, который в свою очередь передаёт письмо дальше по схеме.

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

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

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

  4. 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 одновременно.

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

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

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

  4. 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 для удобства.

Перед запуском Postfixa надо изменить 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


Если сравнить таблицу 4.3.1 и таблицу 4.7.1, то можно заметить что 2%-3% снизилась нагрузка на процессор в таблице 5 по сравнению с таблицей 4, связано это с тем, что метод разделения и управления ресурсами процессора FSS более совершенный, чем метод TS используемый по умолчанию в системе при том улучшение связаны с антивирусом ClamAV. Если сравнивать таблицу 3.8.1 и таблицу 4.7.1, то улучшения показателей процессора отсутствует при сравнительно этих же нагрузках. Если брать Оперативную Память и сравнивать таблицу 3.8.1 и таблицу 4.7.1, видно, что нагрузка на память в таблице 4.7.1 выше от 3%-8%. Остальные показатели остаются приблизительно одинаковыми.


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


Как видно из решения в Интернете будут доступны два порта 25 почтовый сервер Postfix и 110 pop3 сервер Courier imap. Так как я рассматриваю только почтовый сервер Postfix, то я беру за главную цель взлома только почтовый сервер Postfix. Я хочу рассмотреть два вида атак самых популярных на сегодняшний день:

      1. Проникновение в систему с целью выполнения произвольной команды или же подготовка плацдарма с целью дальнейшего использования системы.

      2. DOS, DDOS атаки с целью вывода сервера из строя и недостижимости его в дальнейшем


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

Допустим ситуацию, что в одном из модулей Postfix’a допустим в модуле smtpd (так как этот модуль работает на TCP порту 25, соответственно он достижим из Интернета) найдена уязвимость, позволяющая выполнить произвольный код. Первая ступень обороны эта chroot оболочка самого сервера Postfix:

  • взломщик попадет в директорию /usr/local/var/spool/postfix, которая будет считаться для него корнем файловой системы “”/”. Соответственно, там не будет находится стандартных программ операционной системы Solaris, которые могли бы дать взломщику выполнять команды (например команды passwd root для смены пароля суперпользователя root) взломщик сможет только использовать права доступа модуля smtpd. Модуль smtpd имеет права доступа “postfix”. Главная проблема на этом уровне защиты для взломщика заключается в том, чтобы перенести в chroot оболочку необходимые файлы для дальнейших действий и выполнять их с правами суперпользователя. В эту директорию можно записывать файлы, так как сюда складывается сообщения модулем qmgr, но они имеют формат Mime соответственно, если взломщик пришлёт нужный ему файл, он будет в формате Mime, и не будет выполняем. Как видно даже на 1 рубеже защиты уже становится понятно, что данный вид атаки не приведет к большим последствиям.

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

  • Если первых два уровня защиты будут пройдены, то взломщик получит доступ суперпользователя “root” в системе он будет изолирован областью не глобальной зоны z_postfix. В этом случае он не сможет получить доступ к глобальной зоне операционной системы Solaris, в которой работают такие сервисы как MySQL, SSH соответственно и получить доступ к этим сервисам будет не возможно. То есть взломщик будет изолирован от главной области операционной системы. Так же все события из не глобальной зоны z_postfix будут регистрироваться в syslogd демоне, который через сеть будет выводить регистрацию событий из не глобальной зоны z_postfix в глобальную зону, то есть любое проникновение в систему не останется не замеченным и не будет возможным вычистить журнал событий.

Как видно из фактов, проникновение и выполнение на стороне сервера команд является практически не выполнимой операцией.


2. DOS, DDOS атаки с целью вывода сервера из строя и недостижимости его в дальнейшем.

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

 

Выводы


В конечном результате мне удалось решить требуемые задачи:

  1. Удалось достигнуть более лучших результатов, чем 1000000 писем в сутки со среднем размером письма 50 килобайт.

  2. Удалось добиться гибкости системы для администрирования и интегрировать почтовый сервер с MySQL базой данных.

  3. Создать активную систему защиты от вирусов на базе бесплатного программного продукта ClamAV, который не уступает своим коммерческим аналогам.

  4. Сделать пассивную систему защиты от спама и пересылки спам писем через почтовый сервер.

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

  6. Проанализировать эффективность работы виртуальной машины для укрепления защиты сервера.

  7. Создать полнофункциональный рабочий сервер с многоуровневой системой защиты от большинства существующих атак.

  8. Создать хорошую базу для дальнейшего использования данной модели почтового сервера для решения большого круга проблем.

В ходе проделанной работы я доказал, что операционная система Solaris может служить не только как платформа для высоко производительных баз данных, но и высоко производительный почтовый сервер с многоуровневой системой безопасности по технологии виртуальных машин. Считаю, что создать данное решение на аналогичных платформах (Linux, FreeBSD, HP-UX) было бы на много сложнее или даже невозможно.

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

Список использованной литературы и других информационных источников


Дж.Уинзор, SOLARIS. Руководство системного администратора. 3-е издание – Москва: Издание ПИТЕР,2003 – 443 стр.


Технология виртуализации Solaris Containers – Resource Management and Solaris Zones //http://docs.sun.com/app/docs/doc/817-1592, (5.10.2005)

Internet Protocol Suite Tunable Parameters

http://docs.sun.com/app/docs/doc/817-0404/6mg74vsad?a=view, (5.15.2005)


System Administration Guide: Devices and File Systems

// http://docs.sun.com/app/docs/doc/817-5093 , (5.15.2005)


System Administration Guide: Basic Administration

//http://docs.sun.com/app/docs/doc/817-1985, (5.15.2005)


System Administration Guide: Advanced Administration

//http://docs.sun.com/app/docs/doc/817-0403, (5.15.2005)


Postfix Documentation //http://www.postfix.org/documentation.html (5.15.2005)


MySQL Documentation //http://dev.mysql.com/doc/ (5.15.2005)


ClamAV Documentation //http://www.clamav.net/doc/0.85 (5.15.2005)


Simple Authentication and Security Layer (SASL) //http://asg.web.cmu.edu/sasl/sasl-ietf-docs.html (5.15.2005)


Комментарии: (0) | Безопасность | 2006-06-02

Философия и архитектура NT против UNIX с точки зрения безопасности

Философия и архитектура NT против UNIX с точки зрения безопасности


[1] Во избежание многословия под "NT" если только явно не оговорено обратное здесь и далее будет подразумеваться все NT-подобные системы: сама Windows NT, Windows 2000 и Windows XP.


Существует мнение, что распространение электронно-вычислительных машин привнесло больше проблем, чем их решило. Человечество в своей массе ни морально, ни этически, ни психологически ко всему этому оказалось просто не готово и компьютерная техника попала в руки к людям, чей интеллект направлен лишь на разрушение. И, если до появления Интернета, вирусная угроза в основном сводилась к проблеме "грязных рук" и беспорядочного копирования ПО, то сейчас ситуация существенно изменилась…

Введение

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

Представляется логичным протестировать несколько популярных систем, отобрать из них наиболее защищенную и… Тут-то и выясняется, что:

а) такого тестирования еще никто не проводил, во всяком случае, материал найденный по этой теме в Сети, носит субъективный и поверхностный характер, сильно завязанный на непринципиальных недостатках конкретных реализаций ОС, большая часть из которых давным-давно исправлена очередной заплатой;

б) если семейство NT представлено всего тремя операционными системами: самой NT, Windows 2000 и Windows XP с практически идентичными архитектурами, то пестрота UNIX-подобных систем вообще не поддается описанию;

в) очень трудно выбрать адекватные критерии защищенности: количество зафиксированных взломов данной ОС – это не совсем тот показатель, который нам нужен: во-первых, точной статистики у нас нет и не может быть в принципе (по настоящему успешные взломы как правило не регистрируются), а, во-вторых, статистика такого рода отражает не защищенность, а распространенность тех или иных систем и в значительной степени искажена преобладающим интересом хакеров (попросту говоря модой); количество обнаруженных дыр  – само по себе еще ни о чем не говорит (уже хотя бы по указанным выше причинам).

Поэтому мы решили абстрагироваться от особенностей конкретных реализаций, и сравнить потенциальную концептуальную уязвимость операционных систем семейств NT и UNIX. Что такое "потенциальная уязвимость"? Это такое свойство архитекторы системы, которое при определенных обстоятельствах с той или иной вероятностью может привести к снижению степени ее защищенности. В частности, сложность считается одной из потенциальных концептуальных уязвимостей и при прочих равных условиях менее сложная система объявляется более защищенной и, соответственно, наоборот. Кончено, помимо сложности (кстати, уровень сложности измеряется не объемом программного кода, а количеством взаимосвязей между отдельными компонентами программы), большую роль играет профессионализм разработчиков, качество тестирования и т. д. Однако, поскольку все эти факторы практически не поддаются объективному учету (только не надо пожалуйста говорить, что LINUX тестируют миллионы людей по всему миру, – знаем-знаем мы как они ее тестируют), лучше их вообще учитывать, чем учитывать неправильно.

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

Философские концепции


Open Source vs дизассемблер

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

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

Действительно, защитный механизм, принцип действия которого неизвестен, может быть взломан только грубой силой, то есть имеет вполне предсказуемую степень защищенности. Поэтому, любая мало-мальски серьезная акция начинается с изучения атакуемого объекта (целенаправленный взлом). Отсюда: при прочих равных условиях степень защищенности системы обратно пропорционально легкости анализа ее кода. А легкость самого анализа в первую очередь определяется доступностью исходных текстов защитного механизма!

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

Как следствие: количество дыр, обнаруженных в NT за все время ее существования, можно свободно пересчитать по пальцам одной руки (причем, большая часть из них была обнаружена практически случайно). В UNIX же, напротив, дыры обнаруживаются постоянно. С другой стороны….

Каждому хакеру – по системе!

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

В результате, могущество хакера, нашедшего дыру в UNIX, оказывается много ниже, чем если бы дыра аналогичных размеров была обнаружена в NT (в силу не многочисленности своих разновидностей, каждая, отдельно взятая версия NT, установлена на значительно большем количестве машин, нежели UNIX). Именно поэтому NT все-таки ломают или во всяком случае пытаются это сделать. Соблазн в самом деле настолько велик, что хакеров не останавливают ни отсутствие исходных текстов, ни трудоемкость анализа. К тому же, ядро NT не переписывается каждый день и практически все дыры, обнаруженные в NT 4.0 остаются актуальными и в Windows 2000, а то и в Windows XP. (Подробнее об этом рассказывается в книге Криса Касперски "Техника сетевых атак").

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

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

Неплохая идея: на передний план обороны водрузить какой-нибудь "редкоземельный" клон UNIX, а на второй – NT. Большинство хакеров, как показывает практика, в основном специализируются на одной операционной системе, и лишь в исключительных случаях – на двух сразу.

UNIX – это просто!

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

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

Между тем, ошибки крайне неоднородны по своей природе: одни лежат, что называется на поверхности, и обнаруживаются даже автоматизированными средствами контроля качества кода; другие же, напротив, зарыты так глубоко, что найти их можно только случайно. Фундаментальная проблема отладки заключается в том, что любая, даже самая незначительная модификация программного кода, чревата появлением каскада ошибок, возникающих в самых неожиданных местах. И потому, внесение каких бы то ни было изменений во внутренности операционной системы и/или сопутствующих ей приложений должно сопровождаться полным циклом повторного тестирования. Но ведь полное тестирование, как уже было показало выше, выполнить просто невозможно!

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

Большинство UNIX'ов напротив, довольно компактны и содержат минимум необходимых для функционирования системы компонентов (или, во всяком случае, позволяют урезать себя до такого состояния). К тому же их медленное, эволюционное (а не революционное как у NT) развитие отнюдь не способствует появлению грубых, легко обнаруживаемых ошибок, которыми так славится NT.

Удаленный доступ: оружие пролетариата?

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

Никто не спорит – удаленно управлять сервером очень удобно, но давайте задумаемся – насколько это безопасно? Увы, никакое удобство не проходит даром! Что комфортно администрировать, то комфортно и атаковать! Этому, кстати, будут способность и продвинутые командные интерпретаторы, поддерживающие полноценные языки программирования, разительно отличающие от того уродства, что переваривает примитивная оболочка NT. Вообще же, в NT удаленным доступом очень мало что можно сделать (правда, начиная с Windows 2000 в ней все-таки появилось более или менее совершенные механизмы удаленного управления).

Тем не менее не стоит впадать в крайности и полностью отказываться от возможности удаленного администрирования. Конечно, полностью запретив удаленный доступ вы в значительной степени усилите защищенность своего сервера, но… при этом будете вынуждены постоянно находится непосредственно рядом с сервером. Спрашиваете: зачем? А кто хакеров будет гонять?! Ведь проникнуть на атакуемую машину можно через любой, установленный на ней сервис (скажем, WEB) и потому крайне нежелательно лишать себя всех средств дистанционного мониторинга и управления сервером.

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

Комплектность штатной поставки

Комплект штатной поставки подавляющего большинства UNIX включает в себя огромное количество разнообразных программ от игрушек до компиляторов и интерпретаторов. А чем больше приложений установлено на машине, тем выше вероятность образования "дыр" в системе безопасности! К тому же, наличие компиляторов (интерпретаторов) на атакуемой машине значительно упрощает взлом, поскольку, во-первых, усиливает переносимость эксплоитов, во-вторых, позволяет автоматизировать атаку, и, в-третьих, предоставляет доступ к функциям и сервисам недоступным из командной оболочки.

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

Архитектурные концепции


Механизмы аутентификации

Механизмы аутентификации пользователей (то есть, попросту говоря алгоритмы проверки правильности пароля) и в UNIX, и в NT построены на практически идентичных принципах. А именно: эталонный пароль вообще нигде не хранится, – вместо этого используется его хэш (грубо говоря: контрольная сумма). Пользователь вводит пароль, операционная система хэширует его по тому или иному алгоритму и сравнивает полученный результат с хэш-суммой эталонного пароля, хранящейся в специальной базе паролей. Если они совпадают, то все ОК и, соответственно, наоборот. Такая схема (при отсутствии ошибок реализации, конечно) гарантирует, что даже если злоумышленник и получит доступ к базе паролей, он все равно не сможет проникнуть в систему иначе, чем методом перебора. Впрочем, если спуститься с небес идеализированных математических концепций на грешную землю, можно обнаружить, что "нормальные герои всегда идут в обход". В частности, в большинстве UNIX'ов вводимый пароль открытым текстом передается по сети и при наличии хотя бы одного уязвимого узла в цепочке передачи, может быть перехвачен хакером. В NT же открытый пароль никогда не передается (ну, разве что администратор не настроит ее соответствующим образом) и используемая в ней схема аутентификации устойчива к перехвату трафика.

С другой стороны, NT крайне небрежно относится к охране парольной базы от посягательств хакеров. На первый взгляд кажется, что никакой проблемы вообще нет, т. к. доступ к базе имеется лишь у системы, администраторов и ограниченного количества специально назначенных администратором пользователей (например, операторов архива, периодически сохраняющих базу на резервных носителях). А вот в некоторых, правда, довольно немногочисленных UNIX'ах файл паролей свободно доступен всем пользователям системы и зачастую даже "виден" по сети! Ну и что с того? – спросите вы. – Ведь паролей в парольном файле все равно нет, а "обращение" хеша методом перебора занимает слишком много времени, пускай хакер перебирает, если ему это занятие так нравится… Хорошо, тогда такой вопрос: возможно ли в одном единственном переборе взломать все машины в сети? Не спешите отвечать "нет", ибо правильный ответ: "да"! Объем жестких дисков сегодня возрос настолько, что хакер может сохранить хеши всех перебираемых паролей. Неважно сколько это займет времени: месяц или даже несколько лет, – ведь теперь у взломщика появится возможность практически мгновенно восстановить пароль по его хешу – была бы только парольная база в руках! Мало того, что в NT резервные копии парольной базы по умолчанию хранятся в общедоступных каталогах, так алгоритм аутентификации не использует привязки (salt), в результате чего хеши одинаковых паролей в NT всегда будет совпадать, значительно упрощая тем самым взлом! Впрочем, от атак данного типа привязка все равно не спасает, разве что немного продляет "мучения" системы.

Повышение своих привилегий

Модель привилегий пользователей и механизмы контроля прав доступа, – ключевое и вместе с тем наиболее уязвимое (по статистике) звено подсистемы безопасности любой многопользовательской ОС. В общем случае к ней предъявляются следующие требования:

а) модель пользователей должна быть достаточно гибкой, удобной и интуитивно понятной, в противном же случае ошибки администрирования – неизбежны;

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

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

Анализ показывает, что перечисленные выше требования не выполняются ни в одной ОС массового назначения, а потому все они в той или иной степени заведомо уязвимы. Между тем, степень защищенности UNIX и NT различна.

Модель привилегий пользователей, применяемая в большинстве UNIX, является одноуровневой и допускает существование только двух типов пользователей: обычные пользователи и суперпользователь (он же root или администратор). В NT же, напротив, используется иерархическая схема, причем, помимо root'а в ней имеется еще один суперпользователь, – система. Что это означает? А то, что в NT, в отличии от UNIX, каждый пользователь получает минимум необходимых ему прав и никогда не повышает уровень своих привилегий без особой необходимости. Широко распространенное заблуждение гласит, что правильное администрирование UNIX позволяет добиться такого же точно распределения прав доступа, как и в NT, пускай и ценой большего времени и усилий. На самом же деле это не так.

Отсутствие системного пользователя в UNIX приводит к невозможности выполнения целого ряда действий иначе, чем временным повышением привилегий запущенной программы до root'a. Взять хотя бы классическую задачу смены пароля. Пользователи могут (и должны!) периодически менять свои пароли. Но ведь в UNIX (как впрочем и в NT) пароли всех пользователей хранятся в одном файле, причем, используемая модель привилегий не позволяет назначать различным частям файла различные права доступа. Но ведь должен пользователь как-то изменять свой пароль, верно? В UNIX эта задача решается так: утилите, ответственной за смену пароля, присваивается специальный атрибут, позволяющий ей при необходимости получать права root'а, что она, собственно, и делает. Если бы этот механизм использовался только при операциях с паролями большой беды и не было бы. На самом же деле, такой атрибут необходим очень большому количеству приложений, в частности WEB и e-mail серверам. Задумайтесь, что произойдет, если в одной из программ, исполняющихся с наивысшими привилегиями, обнаружится ошибка, так или иначе приводящая к возможности передачи управления хакерскому коду? А ведь такие ошибки сыплются из UNIX'ых программ как из рога изобилия!

Совершенно иная ситуация складывается в среде NT. Непривилегированные пользователи только в исключительных случаях вынуждены повышать свои права до уровня администратора, а все остальное время они пользуются API-функциями операционной системы, выполняющими потенциально опасные действия "руками" самой ОС. Даже если в одном из таких приложений будет допущена ошибка и хакер захватит управление, – он унаследует минимум прав и причинит система минимум вреда.

Таким образом, NT устойчива к программистским ошибкам, а UNIX чрезвычайно чувствительна к ним.

Угроза переполнения буфера

Переполнение буфера – наиболее "популярная" и в то же время наиболее коварная ошибка, которой не избежало практически ни одно сколь ни будь сложное приложение. Коротко объясним ее суть: если размера выделенного программистом буфера вдруг окажется недостаточно для вмещения всех, копируемых в него данных, то содержимое памяти за концом буфера окажется разрушено (а точнее – замещено) не вместившимися в буфер данными. В зависимости от ситуации за концом буфера могут находится:

а) другие буфера и переменные программы;

б) служебные данные – в частности, адрес возврата из функции;

в) исполняемый код;

г) незанятая или д) отсутствующая страница памяти.

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

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

Все системы: и UNIX, и NT потенциально допускают существование пунктов а), б), г) и д), исключая лишь единственный из них – пункт в). Следовательно, они в равной мере подвержены угрозе переполнения буфера. Кроме того, и UNIX, и NT имеют исполняемый стек (то есть разрешают выполнение кода в стеке) и запрещают его выполнение в сегменте данных. А это значит, что переполнение буферов, содержащихся в автоматических (т.е. стековых) переменных несет в себе угрозу полного захвата управления над уязвимой программой. Правда, для некоторых UNIX существуют заплаты, отнимающие у стека право выполнения, но сфера их применения весьма ограничена (исполняемый стек необходим множеству вполне легальных программ, в частности, компиляторов).

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

Доступ к чужому адресному пространству

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

Полноценной защиты от предумышленного доступа в чужое адресное пространство ни в UNIX, ни в NT на самом деле нет. Собственно, UNIX вообще не представляет никаких средств такого взаимодействия, кроме разве что разделяемых (т. е. совместно используемых) областей памяти, но это совсем не то. NT же обеспечивает весьма гибкий контроль доступа адресному пространству процессоров, но все-таки значительно проигрывает UNIX в отношении безопасности. И вот почему:

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

б) в UNIX для отладки процессов необходимо, чтобы отлаживаемый процесс не только дал согласие на свою отладку, но и выполнил некоторые действия, причем, отладка уже запущенных процессов запрещена! NT же беспрепятственно позволяет отлаживать активные процессы и инициировать отладку новых, естественно, с наследованием всех привидений процесса-отладчика (то есть в общем случае, отладка более привилегированных процессов из менее привилегированных невозможна).

Короче говоря, – NT предоставляет весьма вольготные условия для существования Stealth-вирусов, клавиатурных и паролей шпионов и всех прочих тварей, нарушающих покой системы.

Межпроцессорные коммуникации

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

а) самостоятельно решать с кем ему взаимодействовать, а с кем нет;

б) уметь определять подлинность процессов отправителей и процессов получателей;

в) контролировать целостность передаваемых/принимаемый данных;

г) создавать защищенный канал связи, устойчивый к перехвату трафика.

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

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

Именованные каналы доступны всем процессам в системе, а в NT и процессам, исполняющимся на остальных узлах сети. Естественно, для открытия именованного канала необходимо иметь соответствующие привилегии, но вот для создания нового именованного канала такие привилегии необязательны, причем под NT не существует легальных способов определения "авторства" создателя того или иного канала! Учитывая, что именованные каналы активно используются системой для передачи зашифрованных паролей и удаленного управления реестром, угроза внедрения подложных каналов уже не покажется незначительной. Частично эта проблема решается установкой соответствующего пакета обновления (в частности для Windows 2000 это ServicePack 2), который предотвращает создание подложного экземпляра уже существующего именованного канала, между тем возможность создать подложный канал "с нуля" по прежнему остается, а механизмов идентификации создателей канала в win32 API как не было, так до сих пор и нет. Локальность именованных каналов в UNIX оказывается одновременно и сильной, и слабой ее стороной. Тем не менее, отсутствие удаленного доступа к каналам еще не дает повода расслабляться, – ведь создать подложный канал может даже гостевой пользователь, что в ряде случаев позволяет ему успешно атаковать более привилегированные процессы.

Именованные каналы имеют еще один серьезный недостаток: обработка каждого нового подключения требует какого-то количества системных ресурсов, а максимальное количество создаваемых экземпляров канала обычно не ограничено. Создавая все новые и новые экземпляры злоумышленник "сожрет" все ресурсы и система рано или поздно "встанет". Даже если максимальное количество экземпляров было заранее ограничено, получим те же самые яйца, только в профиль. Захватив все свободные каналы, злоумышленник нарушит нормальную работу всех остальных легальных процессов. Система, правда, не рухнет но пользы от этого будет немного… Решение проблемы состоит в введении квот с клиентской (а не серверной!) стороны, но во-первых, не совсем ясно как такое реализовать в сетевой среде, а, во-вторых, клиентскую защиту всегда легко обойти.

Сокеты, использующиеся в основном в межузловых межпроцессорных взаимодействиях (хотя в UNIX они широко применяются и для локального обмена данными), так же катастрофически незащищены перед попыткой захвата всех свободных ресурсов и огромное количество постоянно совершающихся flooding-атак – лучшее тому подтверждение. Кстати, наличие "сырых" (RAW) сокетов в UNIX делает ее платформой номер один для любой мало-мальски серьезной TCP/IP-атаки. Системы семейства NT долгое время вообще не позволяли "вручную" формировать сетевые пакеты и потому атаки типа Land, Teardrop и Bonk осуществить с их помощью было невозможно (правда, это еще не означает, что NT устойчива к таким атакам). Не этим ли обстоятельством вызвана патологическая любовь большинства хакеров к UNIX? Правда, сегодня только ленивый не найдет NDIS-драйвер к NT, позволяющий работать с TCP/IP пакетами на низком уровне, так что репутация UNIX как чисто хакерской платформы в скором будущем обещает пошатнуться.

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

Нашумевшая дыра, связанная с передачей shell-кода в строку редактирования привилегированного процесса с последующей установкой таймера, выполняющего этот код в адресном пространстве и с привилегиями атакуемого процесса, в настоящее время по заверениям Microsoft уже устранена. Подробности рецепта "лечения" в момент написания этих строк еще не известны, но по всей видимости они сводятся к проверке адреса таймерной процедуры – она не должна находится в буфера какого бы то ни было окна. Ну, еще быть может, запретили передавать сообщение WM_TIMER более привилегированным процессам. Полностью же запретить (или защитить) межпроцессорную рассылку сообщений невозможно, поскольку она является частью философии оконной подсистемы Windows и любые попытки внесения каких бы то ни было ограничений не замедлят столкнуться с проблемами совместимости и приведут к неработоспособности большого количества прикладных программ.

Оконная подсистема UNIX хороша тем, что, не является неотъемлемой частью системы и при желании от нее можно отказаться, ограничившись надежным и безопасным текстовым режимом. К тому же, обмен сообщениями в графических оболочках UNIX обычно осуществляется по протоколам TCP/IP, которые защищают окна и элементы управления одного процесса от посягательств всех остальных (если, конечно, сам процесс-владелец этого не захочет).

Итак: межпроцессорный обмен в и UNIX, и в NT выполнен очень плохо и потому не безопасен, причем, адекватных средств защиты от рассмотренных выше атак, ни в близком, ни в отдаленном будущем по видимому не появится, т. к. "собака зарыта" на уровне базовых концепций и философии той и другой системы. А философию очередной заплатой не поменяешь.

Сводная таблица

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

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

характеристика NT UNIX

качество и полнота документирования

документирована поверхностно

документирована весьма обстоятельно

доступность исходных текстов

исходные тексты недоступны

исходные тексты доступны

сложность анализа

высокая

умеренная

распространенность

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

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

сложность кода

код излишне сложен

код предельно прост

поддержка удаленного администрирования

частично поддерживает

поддерживает

комплектность штатной поставки

содержит минимум необходимых приложений

содержит огромное количество приложений, в том числе и не протестированных

механизмы аутентификации

устойчив к перехвату паролей

передает открытый пароль

использование привязки

не использует

использует

выполнение привилегированных операций

выполняется операционной системой

выполняется самим приложением со временным повышением привилегий

модель пользователей

иерархическая

одноуровневая

защита от переполнения буфера

отсутствует, причем сама ОС написана на языке провоцирующим такие ошибки

отсутствует, причем сама ОС написана на языке провоцирующим такие ошибки

возможность доступа в адресное пространство чужого процесса

имеется, разрешена по умолчанию

отсутствует

возможность отладки процессов

имеется, разрешена по умолчанию

имеется, но связана с рядом ограничений

возможность отладки активных процессов

имеется, но требует наличия соответствующих привилегий

отсутствует

удаленный доступ к именованным каналам

есть

нет

создание подложных именованных каналов

есть, можно создать и канал, и даже подложный экземпляр уже открытого канала

есть, можно создать лишь подложный канал

защита именованных каналов от нежелательных подключений

отсутствует

отсутствует

защита сокетов от нежелательных подключений

отсутствует

отсутствует

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

имеется

отсутствует

Таблица 1 Сравнение основных характеристик UNIX и NT прямо или косвенно относящихся к безопасности. Неудачные характеристики залиты серым цветом

Заключение

Не правда ли, забавно, – NT защищена намного слабее (приведенная выше таблица неопровержима доказывает это), но ломают чаще всего все-таки UNIX, а не NT. Парадокс? Или все-таки отсутствие исходных текстов дает о себе знать? Во всяком случае, других причин мы просто не видим… Единственное, что можно предположить: NT ломают, но в силу успешности взлома (и уязвимости самой системы) эти взломы просто не удается зафиксировать. В общем, здесь есть пища для размышлений!

  [C] Крис Касперски

Источник: [W A S M . R U]

Комментарии: (0) | Безопасность | 2006-06-07