Несмотря на то, что изначально сеть создавалась для обмена файлами, с появлением первого браузера популярность WWW-страниц начала расти не по дням, а по часам. Сейчас уже трудно себе представить не только Интернет, но и интранет без Web-страниц.
Для того чтобы пользователь смог просматривать с вашего узла хотя бы простейшие Web-странички, необходим Web (HTTP)-сервер. Уже долгое время самым распространенным из них является Apache. Трудно точно сказать, какая доля серверов работает на Apache, но можно с уверенностью утверждать, что больше половины. Хотя для Linux существуют и другие Web-серверы (например, TUX), но когда говорят о Web-сервере под Linux, то подразумевают именно Apache.
Apache абсолютно бесплатный сервер, который распространяется но лицензии GNU и доступен не только для Unix-систем, но и для ОС Windows. Официальный сайт разработчиков — www.apache.org. Почему этот сервер стал так популярен? Неужели так повлиял фактор дармовщины? Бесплатность, конечно, соблазнительна, но качество превыше всего. Сервер Apache располагает громадным количеством возможностей и при этом обладает следующими немаловажными особенностями:
□ безопасность — многие профессионалы относят к разряду самых защищенных;
□ надежность — в сочетании с ОС Linux может работать без перезагрузок годами;
□ неприхотливый — работает с минимальной нагрузкой на систему (не требует особых ресурсов);
□ производительность — высокая скорость отклика и обработки запросов пользователей.
На основе Apache строят серверы, которые работают практически без выключения (доступны 99,9%). Многие корпорации вверяют ему свои важные данные, и мне не известны случаи, когда кто-нибудь пожалел о содеянном.
Единственный недостаток, который отмечают пользователи, — это сложность конфигурирования. Приходится редактировать текстовый файл, а т.к. настроечных параметров огромное количество, то это может оказаться утомительным занятием. При этом нет гарантии, что все настройки будут сделаны оптимальными и безопасными, ведь очень легко упустить что-либо.
В данной книге мы не сможем рассмотреть все возможные параметры, потому что их слишком много. Мы коснемся только основных и поговорим о том. что может сказаться на производительности и безопасности сервера.
7.1. Основные настройки
Основные настройки сервера Apache располагаются в файле /etc/httpd/conf/httpd.conf (для некоторых дистрибутивов — в /etc/httpd.conf). Здесь хранятся настройки Web-сервера, его виртуальных серверов и программных модулей. Для Red Hat Linux, а именно он взят за основу в этой книге, все рассматриваемые параметры сервера находятся в этом файле, если явно не указано другое расположение.
Как и для большинства других сервисов, в современных дистрибутивах для настройки Apache есть простая и удобная графическая утилита. Для ее запуска нужно в основном меню системы выбрать System/Apache configuration. На рис. 7.1 показано главное окно программы Apache Configuration, позволяющей быстро и легко настроить Web-сервер.
Рис. 7.1. Главное окно программы Apache Configuration
С помощью визуальной программы очень удобно делать первоначальные настройки, но после этого вы обязательно должны самостоятельно просмотреть конфигурационный файл, а для этого нужно знать его параметры.
Внимание!
Если вы вручную внесли исправления в конфигурационный файл, то после этого использовать графическую утилиту нельзя, потому что она может неправильно интерпретировать ваши правки и поменяет их на свои значения. Чтобы изменения вступили в силу, необходимо перезапустить сервер. Сервис Apache считывает параметры из конфигурационного файла только во время старта.
За счет прямого редактирования файла конфигурации можно добиться максимально безопасной и быстрой работы. Рассмотрим основные параметры Web-сервера:
□ ServerType — тип сервера, может принимать значения inetd или Standalone. Если выбрать inetd, то такие параметры, как порт, игнорируются. а используются значения из конфигурации демона inetd (см. разд. 5.4);
□ ServerRoot — корневая директория, в которой находятся файлы конфигураций и журналы;
□ Timeout — предельное время ожидания в секундах для получения и отправки пакетов;
□ Port — порт, на котором будет работать сервис. По умолчанию и для общедоступных серверов используется значение 80. Но для закрытых серверов, которыми пользуется узкий круг людей, можно изменить значение, например, на 10387. В этом случае в качестве адреса страницы надо использовать URL типа ИмяСервера:10387 (например, www.linux.com:10387/index.htm). Таким образом, не зная порта, злоумышленник не сможет проникнуть в систему, пока не просканирует весь диапазон портов и не выяснит, что 10387 — это порт Web-сервера. Это простейшая, но достаточно эффективная защита от скриптеров, которые обладают минимумом знаний о безопасности и взламывают компьютеры только с помощью сплоитов, написанных другими хакерами;
□ ServerTokens — при обращении к серверу возвращает заголовок с подробной информацией о системе, которая включает версии Apache, ОС Linux и всех имеющихся модулей. Если хакер узнает, что на сервере установлена старая версия интерпретатора PHP (или любой другой программы), то на взлом уйдет намного меньше времени. Болтливые параметры необходимо отключать, а информацию о сервере прятать. ServerTokens может принимать одно из следующих значений:
• Full — отображать полную информацию о сервере и установленных модулях, включая их версии. Самое опасное для сервиса — это использование именно этого параметра;
• Min — показать минимум сведений (только название сервера и установленные модули). Иногда даже такой простой список без версий может сказать хакеру слишком много;
• ProductOnly — только название сервера, в нашем случае Apache вернет свое имя (apache) без указания версий. Вот это как раз то, что нам нужно.
Очень опытные администраторы могут даже подменить имя сервера, но для этого необходимо будет перекомпилировать исходные коды Apache. Заголовок хранится в файле include/ap_releas.h в виде следующих двух строк:
#define SERVER_BASEPRODUCT "Apache"
#define SERVER_BASEVERSION "2.0"
Подставьте имя какого-либо другого сервера. Желательно, чтобы оно было похоже на реальность, иначе профессиональный хакер сразу заметит обман.
В более ранних версиях Apache расположение файла было другим, но мы же договорились, что устанавливать надо все только последнее;
□ HostnameLookup — если установлено значение on, то IP-адрес клиента, запросившего данные с сервера, будет преобразован в доменное имя, иначе будет использоваться IP-адрес;
□ User и Group — группа и имя пользователя, с правами которого будет работать сервис. По умолчанию в Linux для этих параметров используется Apache. Этот пользователь и группа должны обладать минимальными правами в системе, которые только необходимы для работы Web-сервера и его модулей. Ничего лишнего разрешать им нельзя;
□ ErrorLog и CustomLog — определяют местоположение журналов;
□ LogLevel — обусловливает, что будет писаться в журнал. Можно указать одно из следующих значений: emerg, alert, crit, error, warn, notice, info, debug;
□ KeepAlive — разрешение обрабатывать несколько запросов за одно соединение. По умолчанию этот параметр выключен (off), и для получения каждого файла требуется отдельное соединение. Это неэффективно и приводит к расходу лишних ресурсов. Допустим, что пользователь запросил страницу с 10 картинками. В ответ на это браузер клиента страницу с 10 картинками. В ответ на это браузер клиента откроет одиннадцать соединений с Web-сервером (одно для получения документа html и десять — для картинок документа). Если включить этот параметр, то за одно подключение может быть обработано несколько запросов;
□ MaxKeepAliveRequests — максимальное число запросов, которое может быть выполнено в течение одного соединения;
□ KeepAliveTimeout — время ожидания в секундах очередного запроса от одного и того же клиента. Если за указанный период запрос не поступит, то соединение завершается;
□ MaxClients — максимальное количество клиентов, которые могут подключиться одновременно. Если сделать это значение слишком большим, то злоумышленник сможет произвести атаку DoS (отказ от обслуживания), открыв слишком много соединений, с которыми не справится сервер. По умолчанию установлено 150, но этого будет достаточно только для небольшого сервера. Apache способен обработать намного больше даже на слабеньком железе. Вы должны указать такое значение, при котором сервер сможет обрабатывать максимальное число запросов и при этом успешно работать (не зависнуть) с предельной загрузкой;
□ MaxRequestsPerChild — число запросов, которое позволено обрабатывать дочернему процессу до переполнения. Если Apache или используемые им библиотеки допускают некорректную работу с памятью (выделяют, но не освобождают) или другими ресурсами, то во избежание проблем при длительной непрерывной работе сервера дочерний процесс при переполнении будет принудительно завершен. Большинству систем это не требуется, но некоторые (например, Solaris) страдают заметными "утечками" в библиотеках.
7.2. Модули
При настройке сервиса Apache очень важным звеном являются модули. Загрузка их описана в конфигурационном файле /etc/httpd/conf/httpd.conf следующим образом:
LoadModule perl_module modules/libperl.so
В первой строке проверяется параметр HAVE_PERL. Если он установлен, то команда LoadModule загружает модуль modules/libperl.so, необходимый для интерпретации Perl-сценариев.
Следом идет подключение модулей, которое похоже на загрузку, но используется команда AddModule:
AddModule mod_perl.c
По умолчанию загружаются все установленные модули или те, которые включены в дистрибутив. Но ото не оптимально, потому что разработчик не может знать, что нам понадобится. Рассмотрим основные модули поддержки сценариев, которые могут загружаться:
□ perl_module — Perl;
□ php_module — PHP;
□ php3_module — PHP версии 3;
□ php4_module — PHP версии 4:
□ python_module — на языке Python.
Эти модули являются наиболее опасными для Web-сервера, потому что позволяют выполнять сценарии, через которые могут происходить взломы. Например, воспользовавшись ошибкой в сценарии PHP, злоумышленник может выполнять какие-либо команды на сервере. Хорошие сайты используют какой-то один язык Web-программирования: Perl, PHP или Python, и вы должны оставить только тот модуль, который необходим, а остальные лучше отключить.
Я рекомендую взять на вооружение для программирования PHP, потому что он гибок в настройках и может обеспечить большую безопасность. Да и по моему опыту, злоумышленники чаще используют Perl для создания rootkit (набор администратора или программа, которая позволяет выполнять необходимые хакеру действия на удаленной системе) на взломанной системе. Но это мое мнение, которое отнюдь не претендует на истину в последней инстанции. Хороший программист на Perl сможет легко написать программу, которая будет абсолютно безопасной и доставит много хлопот хакеру. На любом языке, даже самом "дырявом", можно написать супер защищенную программу, а на самом проверенном — наделать дыр. Это уже полностью зависит от программиста и его умений.
Неиспользуемые модули необходимо отключить, это значительно сузит возможности злоумышленника. Ничего не напоминает вам такая рекомендация? Да, это снова самое популярное мое правило: лишняя программа — враг администратора и дополнительная дверь для хакера.
Обязательно уделите внимание рассмотрению загружаемых модулей и удалите или закомментируйте то, что ненужно. Сделав это, вы повысите безопасность Web-сервера более чем на 50%. Почему? Если Python хакерами используется редко, то Perl и PHP очень популярны. Получается, что у вас в системе две большие двери. Если закрыть хотя бы одну, то останется ровно половина.
7.3. Права доступа
В данном разделе нам предстоит познакомиться с основными параметрами файла конфигурации /etc/httpd/conf/httpd.conf. Они отвечают за права доступа, относящиеся к директориям, и имеют следующий вид:
Order allow,deny
Allow from all
или, например:
SetHandler server-status
Order deny,allow
Deny from all
Allow from .your-domain.com
Первое объявление задает права доступа к определенной директории на диске (в данном случае /var/www/html), а второе — ограничивает доступ к виртуальной директории (в приведенном примере http://servername/server-status).
Если вы знакомы с HTML (HyperText Markup Language, язык разметки гипертекста) или XML (Extensible Markup Language, расширенный язык разметки), то такое объявление будет вам известно и понятно без дополнительных разъяснений. Для тех, кто не в курсе, я сделаю несколько пояснений на примере директорий. Объявление начинается со следующей строки:
В угловых скобках указывается ключевое слово Directory и путь к каталогу, права доступа к которому нужно изменить. Это начало описания, после которого идут команды, определяющие права. Блок заканчивается строкой:
Параметры доступа к директории могут быть описаны не только в файле /etc/httpd/conf/httpd.conf, но и в файле .htaccess, который может находиться в указанном каталоге. Сам файл требует отдельного рассмотрения (см. разд. 7.5.1), а сейчас вы должны только знать, что разрешения, указанные в конфигурации Web-сервера, могут быть переопределены.
Теперь рассмотрим, как задаются права доступа. Для этого используются следующие директивы:
□ Allow from параметр — определяет, с каких хостов можно получить доступ к указанной директории. В качестве параметр можно использовать одно из следующих значений:
• all — доступ к директории разрешен всем;
• доменное имя — определяет домен, с которого можно получить доступ к директории. Например, можно указать domain.com. В этом случае только пользователи этого домена смогут получить доступ к директории через Web. Если какая-либо папка содержит опасные файлы, с которыми должны работать только вы, то лучше ограничить доступ своим доменом или только локальной машиной, указав allow from localhost;
• IP-адрес — сужает доступ к директории до определенного IP-адреса. Это очень удобно, когда у вашего компьютера есть выделенный адрес, и вы хотите обеспечить доступ к каталогу, содержащему администраторские сценарии, только для себя. Адрес может быть как полным, так и неполным, что позволяет ограничить доступ к директории определенной сетью;
• env=ИмяПеременной — доступ разрешен, если определена указанная переменная окружения. Полный формат директивы: allow from env=ИмяПеременной;
□ Deny from параметр — запрещение доступа к указанной директории. Параметры такие же, как у команды allow from, только в данном случае закрывается доступ для указанных адресов, доменов и т.д.;
□ Order параметр — очередность, в которой применяются директивы allow и deny. Может быть три варианта:
• Order deny, allow — изначально все разрешено, потом первыми применяются запреты, а затем разрешения. Рекомендуется использовать только на общих директориях, в которые пользователи могут самостоятельно закачивать файлы, например, свои изображения;
• Order allow, deny — сначала все запрещено, вслед за этим применяются разрешения, затем запрещения. Рекомендуется применять для всех директорий со сценариями;
• Order mutual-failure — исходно запрещен доступ всем, кроме перечисленных в allow и в то же время отсутствующих в deny. Советую использовать для всех каталогов, где находятся файлы, используемые определенным кругом лиц, например, администраторские сценарии;
□ Require параметр — позволяет задать пользователей, которым разрешен доступ к каталогу. В качестве параметра можно указывать:
• user — имена пользователей (или их ID), которым разрешен доступ к каталогу. Например, Require user robert FlenovM;
• group — названия групп, пользователям которых позволен доступ к каталогу. Директива работает так же, как и user;
• valid-user — доступ к директории разрешен любому пользователю, прошедшему аутентификацию;
□ satisfy параметр — если указать значение any, то для ограничения доступа используется или логин/пароль или IP-адрес. Для идентификации пользователя по двум условиям одновременно надо задать all;
□ AllowOverwrite параметр — определяет, какие директивы из файла .htaccess в указанном каталоге могут перекрывать конфигурацию сервера. В качестве параметр можно указать одно из следующих значений: None, All, AuthConfig, FileInfo, Indexes, Limit и Options;
□ AuthName — домен авторизации, который должен использовать клиент при определении имени и пароля;
□ Options [+ | -] параметр — определяет возможности Web-сервера, которые доступны в данном каталоге. Если у вас есть директория, в которую пользователям разрешено закачивать картинки, то вполне логичным является запрет на выполнение в ней любых сценариев. Не надо надеяться, что вы сумеете программно запретить загрузку любых файлов, кроме изображений. Хакер может найти способ закачать злостный код и выполнить его в системе. С помощью опций можно сделать так, чтобы сценарий не выполнился Web-сервером.
Итак, после ключевого слова можно ставить знаки плюс или минус, что соответствует разрешению или запрещению опции. В качестве параметр указывается одно из следующих значений:
• All — все, кроме MultiView. Если указать строку Option + All, то в данном каталоге будут разрешены любые действия, кроме MultiView, который задается отдельно;
• ExecCGI — разрешено выполнение CGI-сценариев. Чаще всего для этого используется отдельная директория /cgi-bin, но и в ней можно определить отдельные папки, в которых запрещено выполнение;
• FollowSymLinks — позволяет использовать символьные ссылки. Убедитесь, что в директории нет опасных ссылок и их права не избыточны. Мы уже говорили в разд. 3.1.3 о том, что ссылки сами по себе опасны, поэтому с ними нужно обращаться аккуратно, где бы они ни были;
• SymLinksIfOwnerMatch — следовать по символьным ссылкам, только если владельцы целевого файла и ссылки совпадают. При использовании символьных ссылок в данной директории лучше указать этот параметр вместо FollowSymLinks. Если хакер сможет создать ссылку на каталог /etc и проследует по ней из Web-браузера, то это вызовет серьезные проблемы в безопасности;
• Includes — использовать SSI (Server Side Include, подключение на сервере);
• IncludesNoExec — использовать SSI, кроме exec и include. Если вы не используете в сценариях CGI эти команды, то данная опция является предпочтительнее предыдущей;
• Indexes — отобразить список содержимого каталога, если отсутствует файл по умолчанию. Чаще всего, пользователи набирают адреса в укороченном формате, например, www.cydsoft.com. Здесь не указан файл, который нужно загрузить. Полный URL выглядит как www.cydsoft.com/index.htm. В первом варианте сервер сам ищет файл по умолчанию и открывает его. Это могут быть index.htm, index.html, index.asp или index.php, default.htm и т.д. Если один из таких файлов по указанному пути не найден, то при включенной опции Indexes будет выведено дерево каталога, иначе — страница ошибки. Я рекомендую отключать эту опцию, потому что злоумышленник может получить слишком много информации о структуре каталога и его содержимом;
• MultiViews — представление зависит от предпочтений клиента.
Все выше описанные директивы могут использоваться не только в файле /etc/httpd/conf/httpd.conf, но и в файлах .htaccess, которые могут располагаться в отдельных директориях и определять права этой директории.
Права доступа могут назначаться не только на директории, но и на отдельные файлы. Это описание делается между двумя следующими строками:
Это объявление может находиться внутри объявления прав доступа к директории, например:
Order allow,deny
Allow from all
Deny from all
Директивы для файла такие же, как и для директорий. Исходя из этого, в данном примере к подкаталогу /var/www/html разрешен доступ всем пользователям, а к файлу /var/www/html/admin.php из этой директории запрещен доступ абсолютно всем.
Помимо файлов и директорий можно ограничивать и методы HTTP- протокола, такие как GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK. Где тут собака зарыта? Допустим, что у вас есть сценарий, которому пользователь должен передать параметры. Это делается одним из методов POST или GET. Если вы заведомо знаете, что программист использует только GET-метод, то запретите все остальные, чтобы хакер не смог воспользоваться потенциальной уязвимостью в сценарии, изменив метод.
Бывают варианты, когда не всем пользователям должно быть позволено отправлять данные на сервер. Например, сценарии в определенной директории могут быть доступны для исполнения всем, но загружать информацию на сервер могут только администраторы. Эта проблема легко решается с помощью разграничения прав использования методов протокола HTTP.
Права на использование методов описываются следующим образом:
Права
Как видите, этот процесс схож с описанием разрешений на файлы. Даже права доступа используются те же самые, и размещаются внутри определения директорий (
К примеру, так можно запретить любую передачу данных на сервер в директории /home:
Deny from all
Внутри определения прав для директории /home устанавливается запрет на методы GET и POST.
Ваша задача как администратора настроить такие параметры доступа на директории и файлы, при которых они будут минимально достаточными. Пользователь не должен иметь возможности сделать ни одного лишнего шага. Для реализации этого вы должны действовать по правилу "Что не разрешено, то запрещено".
Я всегда сначала закрываю все, что только можно, и только потом постепенно смягчаю права, чтобы все сценарии начали работать верно. Лучше лишний раз прописать явный запрет, чем потом упустить разрешение, которое позволит хакеру уничтожить мой сервер.
7.4. Создание виртуальных Web-серверов
На одном физическом сервере может работать большое количество виртуальных Web-серверов, например, www.your_name.com и www.your_company.com. Это два разных Web-сайта, но они находятся на одном сервере. Такое расположение дает нам следующие преимущества:
□ экономия денег на закупке серверов;
□ эффективное использование каналов связи, если сайты небольшие и нагрузка на сервер невысока;
□ экономия IP-адресов, лимит которых уже давно был бы исчерпан, если бы все сайты находились на выделенных серверах (с внедрением протокола IPv6 эта проблема будет стоять не так остро). Виртуальные Web-серверы могут иметь как отдельные IP-адреса, так и использовать общий адрес, а различаться будут доменными именами;
□ упрощение администрирования и контроля за безопасностью. Конфигурация Web-сервера и его защита — достаточно сложный процесс, поэтому намного легче настроить и обновлять программное обеспечение одного физического сервера, чем сотни серверов, ресурсы которых используются на 10%.
Для создания виртуального сервера используется формат:
Между этими тегами указываются параметры виртуального сервера. Вот пример описания сервера, адрес которого 192.168.1.1 и порт 80:
ServerAdmin admin@your_server.com
DocumentRoot /var/www/your_server
ServerName your_server.com
ErrorLog logs/your_server.com -error_log
CustomLog logs/your_server.com -access_log common
AllowOverride none
Рассмотрим только основные параметры, которые указываются при описании виртуального сервера:
□ ServerAdmin — E-mail администратора, которому будут направляться сообщения об ошибках;
□ DocumentRoot — директория, в которой расположен корневой каталог сайта;
□ ServerName — имя сервера. Если оно не указано, то используется локальный IP-адрес сервера.
Директивы ErrorLog и CustomLog нам уже знакомы. После этого в нашем примере идет указание прав доступа на директорию /var/www/your_server/, которая является корнем для виртуального Web-сервера. Разрешения можно устанавливать как внутри объявления виртуального сервера, так и вне его.
За более подробной информацией обратитесь к документации по Apache.
7.5. Замечания по безопасности
В конфигурационном файле /etc/httpd/conf/httpd.conf есть несколько директив, которые позволяют управлять безопасностью. Эти же команды можно указывать в файле .htaccess. Давайте их рассмотрим:
□ AuthType параметр — тип аутентификации. В качестве параметра можно использовать одно из значений: Basic или Digest;
□ AuthGroupFile параметр — файл, в котором хранится список групп пользователей;
□ AuthUserFile параметр — файл, содержащий имена пользователей и пароли. Этот список лучше формировать утилитой htpasswd;
□ AuthAuthoritative параметр — способ проверки прав. По умолчанию директива включена (on). Если директива выключена (off), а пользователь не указал имя, то его аутентификация осуществляется другими модулями, например по IP-адресу;
□ AuthDBMGroupFile и AuthDBMUserFile — аналогичны AuthGroupFile и AuthUserFile, но в качестве параметра указывается файл в формате базы данных Berkley-DB.
Эти команды помогут вам настроить идентификацию пользователей при обращении к определенным директориям. Например, если у вас есть каталог, работа с которым разрешена только авторизованными пользователями, то можно указать файл паролей, в соответствии с которым доступ к файлам будет запрещен самим сервером.
7.5.1. Файлы .htaccess
Если какая-либо директория Web-сервера должна иметь особые права, то лучше создать в этом каталоге файл .htaccess. Разрешения, описанные в таком файле, действуют на директорию, в которой он находится. Рассмотрим пример содержимого файла .htaccess:
AuthType Basic
AuthName "By Invitation Only"
AuthUserFile /pub/home/flenov/passwd
Require valid-user
В данном файле для текущей директории указывается тип аутентификации Basic. Это значит, что будет использоваться окно для ввода имени и пароля. Текст, указанный в директиве AuthName, отобразится в заголовке окна. На рис. 7.2 приведен пример такого окна.
Рис. 7.2. Окно запроса имени и пароля
Директива AuthUserFile задает файл, в котором находится база имен и паролей пользователей сайта. Последняя команда Require в качестве параметра использует значение valid-user. Это значит, что файлы в текущей директории смогут открыть только те пользователи, которые прошли аутентификацию.
Вот таким простым способом можно запретить неавторизованный доступ к директории, содержащей секретные данные или сценарии администратора.
Как я уже говорил, в файле .htaccess могут находиться и директивы типа allow from, которые мы рассматривали выше (см. разд. 7.3).
Например, если нужно разрешить доступ только с определенного IP-адреса, то в файле может содержаться следующая строка:
allow from 101.12.41.148
Если объединить защиту директивой allow from и требование ввести пароль, то задача хакера по взлому сервера сильно усложнится. Здесь уже недостаточно знания пароля, необходимо иметь конкретный IP-адрес для обращения к содержимому директории, а это требует значительных усилий.
Эти же параметры можно указывать и в файле httpd.conf, например:
AuthType Basic
AuthName "By Invitation Only"
AuthUserFile /pub/home/flenov/passwd
Require valid-user
Чем будете пользоваться вы, зависит от личных предпочтений. Мне больше нравится работать с файлом .htaccess, потому что настройки безопасности будут храниться в той же директории, на которую устанавливаются права. Но это небезопасно, потому что хакер может получить возможность прочитать этот файл, а это лишнее.
Использование централизованного файла httpd.conf дает преимущества, т.к. он находится в директории /etc, которая не входит в корень Web-сервера и должна быть запрещена для просмотра пользователям.
7.5.2. Файлы паролей
Теперь нам предстоит узнать, как создаются файлы паролей и как ими управлять. Директива AuthUserFile для хранения информации об авторизации использует простой текстовый файл, в котором содержатся строки следующего вида:
flenov:{SHA}lZZEBt.Py4/gdHsyztjUEWb0d90E=
В этой записи два параметра, разделенных двоеточием. Сначала указано имя пользователя, а после разделителя — зашифрованный по алгоритму MD5 пароль. Формировать такой файл вручную сложно и не имеет смысла, поэтому для облегчения жизни администраторов есть утилита htpasswd. С помощью этой программы создаются и обновляются имена и пароли для базовой аутентификации Web-сервером HTTP-пользователей.
Удобство программы состоит в том, что она может шифровать пароли и по алгоритму MD5, и с помощью системной функции crypt(). В одном файле могут находиться записи с паролями обоих типов.
Если вы храните имена и пароли в формате базы данных DBM (для указания этого в файле .htaccess используется директива AuthDBMUserFile), то для управления БД нужно применять команду dbmmanage.
Давайте рассмотрим, как пользоваться программой htpasswd. Общий вид вызова команды выглядит следующим образом:
htpasswd параметры файл имя пароль
Пароль и имя файла являются необязательными, и их наличие зависит от указанных опций. Давайте посмотрим основные ключи, которые нам доступны:
□ -c — создать новый файл. Если указанный файл уже существует, то он перезаписывается, и старое содержимое теряется. Пример использования команды:
htpasswd -c .htaccess robert
После выполнения этой директивы перед вами появится приглашение ввести пароль для нового пользователя robert и подтвердить его. В результате будет создан файл .htaccess, в котором будет одна запись для пользователя robert с указанным вами паролем;
□ -m — использовать модифицированный Apache алгоритм MD5 для паролей. Это позволит переносить созданный файл на любую другую платформу (Windows, Unix, BeOS и т.д.), где работает Web-сервер Apache. Такой ключ удобен, если у вас разнородная сеть, и один файл с паролями используется на разных серверах;
□ -d — для шифрования будет применяться системная функция crypt();
□ -s — применить SHA-шифрование (на базе алгоритма хэширования), которое используется на платформе Netscape;
□ -р — не шифровать пароли. Я не рекомендую устанавливать этот флаг, потому что он небезопасен;
□ -n — не вносить никаких изменений, а только вывести результат на экран.
Для добавления нового пользователя можно выполнить команду без указания ключей, а передать в качестве параметров только имена файла и пользователя:
htpasswd .htaccess Flenov
У команды htpasswd есть два ограничения: в имени пользователя не должно быть символа двоеточия, и пароль не может превышать 255 символов. Оба условия достаточно демократичны и с ними можно смириться. Из моих знакомых такой длинный пароль пока еще никто не захотел устанавливать, а задавать имя пользователя с двоеточием редко кому приходит на ум.
7.5.3. Проблемы авторизации
Авторизация — это слишком простой способ обеспечения безопасности. При передаче пароли шифруются простым кодированием Base64. Если хакер сможет перехватить пакет, содержащий имя пользователя и пароль, то он прочитает эту информацию через пять секунд. Для расшифровки Base64 не нужно подбирать пароль, достаточно выполнить одну функцию, которая декодирует практически моментально.
Для создания реально безопасного соединения необходимо сначала зашифровать весь трафик. Для этого может использоваться stunnel или уже готовый протокол HTTPS, который использует SSL. О нем мы еще поговорим в разд. 10.9.
7.5.4. Обработка на сервере
HTML-файлы могут обрабатываться прямо на сервере (так же, как выполняются файлы PHP). С одной стороны, это удобно, потому что код PHP можно будет вставлять в файлы с расширением htm, с другой стороны, HTML-файлы далеко небезопасны, и если хакер сможет их изменять, то сервер окажется под угрозой.
Чтобы разрешить серверу выполнять файлы с определенными расширениями, используется директива AddHandler. В конфигурационном файле httpd.conf можно найти следующие строки с этой командой:
AddHandler cgi-script .cgi
AddHandler server-parsed .shtml
Если у вас не установлен интерпретатор языка Perl, то первую строку следует закомментировать, чтобы она даже не смущала. Вторая строка безобидна, а вот если таким же образом разрешить серверу работать с НТМ- или HTML-файлами, то это уже станет небезопасным. Следующей строки не должно быть в вашем конфигурационном файле:
AddHandler server-parsed .html
Если где-то действительно есть необходимость подключения HTML-документа, то пропишите это в файле .htaccess. В остальных директориях я рекомендую в явном виде запретить обработку HTML-файлов сервером. Для этого добавьте следующую строку в конфигурационный файл httpd.conf или в файл .htaccess каждой директории:
RemoveHandler .html .htm
Таким образом, мы запретим выполнение файла на сервере, но не отменим SSI-инструкции. Например, следующий код в SHTML-файле будет выполнен:
Если вы не используете SSI и, соответственно, SHTML-файлы, то закомментируйте следующую строку (по умолчанию она доступна):
AddHandler server-parsed .shtml
7.6. Проще, удобнее, быстрее
Процесс конфигурирования должен быть максимально удобным. Если все настройки будут нагромождены в одном файле /etc/httpd/conf/httpd.conf, то разобраться в них станет очень сложно. А чем больше параметров, тем выше вероятность, что вы что-либо прозеваете. Чтобы упростить поддержку вашего Web-сервера, могу посоветовать придерживаться следующих рекомендаций:
□ для удобства администрирования все описания прав доступа можно перенести в конфигурационный файл /etc/httpd/conf/access.conf. По умолчанию этот файл пустой, а все используют только /etc/httpd/conf/httpd.conf. Выделение части разрешений в отдельный файл действительно может помочь в управлении, потому что права будут видны, как на ладони;
□ основные настройки сервера, которые редко изменяются, можно перенести в конфигурационный файл /etc/httpd/conf/access.conf;
□ комментируйте все ваши действия. Многие настройки не изменяются годами, и уже через пару месяцев трудно вспомнить, зачем вы установили определенную директиву. Например, вы запретили доступ для всех пользователей к какой-либо директории, которая временно использовалась для тестирования сценариев. Через какое-то время вы можете забыть это и случайно откроете доступ к сценариям, которые отлажены не полностью и могут стать причиной взлома и крушения системы.
Чем удобнее управлять безопасностью сервера, тем меньше ошибок вы совершите, потому что все параметры правильно сгруппированы, и подробные комментарии напоминают вам о назначении сделанных настроек. Такой подход к администрированию также помогает оперативно решать возникающие проблемы. А как известно, в войне администраторов и хакеров побеждает тот, кто больше знает, имеет больше опыта и быстрее реагирует. Последнее очень важно.
Централизованное хранение прав доступа в конфигурационных файлах Web-сервера приемлемо только на небольших сайтах. Когда работает сотня виртуальных серверов, то такие описания становятся слишком громоздкими. Даже если все права выделить в отдельный файл /etc/httpd/conf/access.conf, его размер будет слишком велик, чтобы найти в нем что-то нужное.
Для больших сайтов я рекомендую описывать в конфигурационных файлах сервера только общие правила, которые затрагивают сразу несколько директорий. Это возможно, потому что при указании пути к каталогу можно использовать регулярные выражения. Приведу пример, который определяет правила для всего, что находится в директории /home:
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
Order allow,deny
Allow from all
Order deny,allow
Deny from all
С помощью таких регулярных выражений удобно создавать общие правила для различных каталогов. Например, если указать в качестве директории значение /home/*/public_html, то все каталоги public_html в директории /home будут иметь указанные права, если нет явного переопределения для отдельных папок.
7.7. Безопасность сценариев
Как мы уже говорили, сценарии являются очень опасными для Web-сервера (см. разд. 1.1.2). Через их ошибки происходило очень много громких взломов. Мы уже знаем, что необходимо отключить все интерпретаторы, которые не используются вами, и оставить только то, что нужно. Таким образом мы усложним задачу хакера, но не решим проблему полностью.
Наиболее безопасный сайт — это тот, что использует статичные (HTML) документы и не имеет сценариев, выполняемых на сервере (PHP, ASP, Perl, Python и др.). Если вам нужен какой-то интерпретатор, то необходимо максимально ограничить его возможности.
Допустим, что ваш сайт использует сценарии PHP, и в нем есть функции, которые обращаются к системе, и если вы их неверно используете (например, не проверяются параметры, заданные пользователем), то злоумышленник имеет возможность передать такие значения, которые могут нарушить работу сервера. Мы не будем говорить о том, как правильно писать сценарии и как их делать безопасными, потому что это задача программистов. Но мы не должны надеяться на их профессионализм, потому что все мы — люди, и нам свойственно ошибаться. Мы должны сделать все, чтобы погрешности не стали фатальными.
В интерпретаторе PHP есть возможность описывать правила выполнения каких-либо действий, используя более безопасные настройки и права доступа, — это режим safe_mode. Но вы должны отдавать себе отчет в том, что некоторые скрипты могут отказаться работать в этом режиме. Многие администраторы отключают safe_mode. Это не совсем верно. Я всегда сначала проверяю, можно ли переписать сценарий, и если это нереально, то только тогда выключаю безопасный режим.
При настройке интерпретатора вы опять же должны действовать от запрета. Изначально следует закрыть все, что нужно и ненужно. А потом включать необходимые вашим сценариям опции. Лучше всего, если вы будете заниматься конфигурированием не только рабочего сервера, но и сервера, который используют программисты для разработки и отладки своих сценариев. В этом случае можно будет контролировать все установленные параметры.
Действия администратора должны быть тесно связаны с работой программиста сценариев для Web-сайта. Если разработчику нужны какие-то опции, то именно вы должны их включать на обоих серверах. О любых корректировках скриптов, влекущих за собой уменьшение (увеличение) прав доступа, разработчик должен вам сообщать, и настройки должны быть изменены.
Администратор и разработчик должны находиться в постоянном контакте, чтобы оперативно реагировать на необходимость использования каких-либо дополнительных возможностей. Некоторые администраторы избавляются от настройки интерпретаторов и переводят эти функции на разработчиков. Это не совсем правильно, потому что программист пишет код и не может достаточно хорошо разбираться в вопросах конфигурации серверов, чтобы обеспечить требуемый уровень безопасности.
Все настройки для интерпретатора PHP хранятся в файле /etc/php.ini. Мы этот файл не будем рассматривать, потому что эта тема выходит за рамки книги по Linux.
7.7.1. Основы безопасности
В настоящее время большинство взломов в Интернете совершается с помощью или благодаря ошибкам в сценариях Web-страниц. Давайте попробуем разобраться, почему это происходит.
Большинство владельцев домашних сайтов — это простые пользователи, которые хотят быстро получить собственную страницу с множеством возможностей. А что именно нужно сайту? Конечно же, это гостевая книга, форум, чат, голосование и т.д. Все эти разделы нельзя сделать с помощью языка разметки HTML, и нужны знания программирования, например, на Perl или PHP. Пользователи не хотят (или не могут) вникать в тонкости программирования, поэтому используют в своих проектах уже готовые (платные или бесплатные) движки.
Как я уже говорил, любая разработка содержит ошибки, просто о них до поры до времени не известно. А распространенная программа становится лакомым кусочком для любого хакера, потому что ее взлом позволяет приникнуть в систему, на которой установлена эта программа.
Если администратор сайта устанавливает на свою страничку популярный форум, то он должен понимать, что когда-нибудь в нем найдут уязвимость, и через нее любой злоумышленник проникнет в систему. Чтобы этого не произошло, администратор сайта должен регулярно обновлять используемые Web-программы и Web-сценарии.
Если вы решили написать собственный форум для сайта, то он может оказаться более надежным, если знать хотя бы основные принципы защиты Web-приложений. В этом случае ваша работа будет безопаснее, чем при использовании любой готовой программы и, тем более, программы с открытым кодом.
Ну а если вы не знаете особенностей языка или вообще не знакомы с программированием, то лучше даже не пытаться. В этом случае даже начинающий хакер найдет уязвимость, не зная исходного кода, структуры базы данных и других параметров, упрощающих взлом Web-сценария.
Как видите, сложности есть всегда. Самый безопасный вариант — использовать на Web-сайтах наименее распространенные программы, разработанные профессиональными программистами. Лучше всего, если они будут с закрытым кодом или даже написаны на заказ. Это требует дополнительных затрат, но расходы на восстановление системы после взлома намного больше.
Если вы отвечаете за один Web-сервер, то легко сможете контролировать обновление программ. Хуже всего администраторам хостинговых компаний. На их серверах расположены сотни, а то и тысячи Web-сайтов. Проследить за всеми хозяевами сайтов нереально, поэтому нужно защитить свои владения от недобросовестных или ленивых пользователей. Для этих целей лучше всего подходит программа jail, о которой мы говорили в гл. 4. Для Web-сервиса вы должны создать его собственный виртуальный сервер, в котором он и будет работать. Если злоумышленник взломает систему через Web-программу, то сможет нарушить работу только виртуальной директории.
Во время подготовки материалов для данной книги в одном из популярных форумов была найдена уязвимость, позволяющая выполнять любые команды на удаленной системе. Для этого нужно было директиву специальным образом передать через строку URL. Эту главу я начал писать через месяц после этого страшного открытия, и почему-то вспомнив про ошибку, решил проверить серверы в Интернете. Я запустил поиск всех сайтов, содержащих уязвимый форум. Вы не поверите, но их было сотни.
Меня заинтересовала пара сайтов, расположенных на серверах крупных хостинговых компаний. На обоих я выполнил команду ls -a /etc. Результат не заставил себя ждать. Я увидел всю директорию /etc, и моих прав хватало даже на удаление файлов. Конечно же, делать этого я не стал даже в тестовых целях. Для доказательства прав я переименовал по одному файлу на каждой системе и сообщил об уязвимости администраторам.
Внимание!
Не советую вам повторять подобные действия. Взлом даже с добрыми намерениями не всеми администраторами воспринимается положительно. Некоторые могут сообщить о ваших действиях в правоохранительные органы, и тогда вам не избежать судебных тяжб. Благие побуждения могут быть восприняты неверно. Если я нахожу какую-либо дыру, то всегда сообщаю администраторам, но для этого отправляется анонимное письмо.
Конечно же, переместив Apache в виртуальное пространство, вы обезопасите только свою систему, но все сайты, которые работают в этом пространстве, остаются уязвимыми. Здесь уже нужно искать другие методы защиты, например, через права доступа, запуск нескольких копий Apache (каждый работает в своем пространстве), выделенные серверы для каждого сайта, запрет на выполнение опасных функций в интерпретаторе PHP и т.д.
Выбрать какой-либо определенный метод защиты множества виртуальных серверов достаточно сложно, а иногда просто невозможно. Например, один сайт требует для своей работы интерпретатор Perl, а другой — PHP. Приходится включать обе возможности.
Из собственного опыта могу посоветовать использовать несколько физических серверов для разделения хранимых сайтов в соответствии с их потребностями:
□ используется интерпретатор PHP в защищенном режиме;
□ нужен интерпретатор PHP с полными правами;
□ применяется интерпретатор Perl.
И так далее. Вы должны сгруппировать сайты, исходя из их требований, тогда администрирование станет намного удобнее и проще.
Особо важные сайты должны располагаться на выделенном сервере и находиться под пристальным присмотром. Например, нельзя размещать на одном
физическом сервере сайт электронного магазина и домашние странички, очень часто использующие бесплатные или некачественные модули, в которых бывают ошибки, и при этом пользователи не обновляют эти программы. Когда-нибудь злоумышленник взломает домашнюю страничку через уязвимые сценарии и сможет украсть номера кредитных карт пользователей интернет-магазина. Это поставит крест на вашей карьере администратора.
7.7.2. mod_security
Несмотря на то, что безопасность Web-сервера, в основном, зависит от выполняемых на нем сценариев и программистов, которые пишут эти скрипты, есть возможность защитить сервер вне зависимости от этих факторов. Отличное решение данной проблемы — бесплатный модуль для Apache под названием mod_security.
Принцип действия модуля схож с сетевым экраном, который встроен в ОС, только в данном случае он специально разработан для обеспечения взаимодействия по протоколу HTTP. Модуль на основе правил, которые задает администратор, анализирует запросы пользователей к серверу и выносит свое решение о возможности пропустить пакет к Web-серверу.
Правила определяют, что может быть в запросе, а что нет. Там обычно содержится URL-адрес, с которого необходимо взять документ или файл. Как можно сформулировать правило для модуля с точки зрения безопасности системы? Рассмотрим простейший пример — для сервера опасно незаконное обращение к файлу /etc/passwd, а значит, его не должно быть в строке URL.
Таким образом, сетевой экран проверяет на основе заданных фильтров адрес URL, и если он нарушает правила, то запрос отклоняется.
Итак, модуль mod security находится на сайте http://www.modsecurity.org, После его установки в файле httpd.conf можно будет использовать дополнительные директивы, фильтрации запросов. Рассмотрим наиболее интересные из них:
□ SecFilterEngine On — включить режим фильтрации запросов;
□ SecFilterCheckURLEncoding On — проверять кодировку URL (URL encoding is valid);
□ SecFilterForceByteRange 32 126 — использовать символы только из указанного диапазона. Существует достаточное количество служебных символов (например, перевод каретки, конец строки), коды которых менее 32. Большинство из них невидимы, но требуют обработки нажатия соответствующих клавиш. Но как же тогда хакер может ввести такой символ в URL? Только через их код. Например, чтобы применить символ "конец строки", необходимо указать в URL-адресе "%13". В данном случае коды символов менее 32 и более 126 являются недопустимыми для адреса, поэтому вполне логично такие пакеты не пропускать к Web-сервер;
□ SecAuditLog logs/audit_log — определяет файл журнала, в котором будет сохраняться информация об аудите;
□ SecFilterDefaultAction "deny,log,status:406" — задает действие по умолчанию. В данном случае указан запрет (deny);
□ SecFilter xxx redirect:http://www.webkreator.com — обеспечивает переадресацию. Если правила соблюдены, то пользователя отправляют на сайт http://www.webkreator.com;
□ SecFilter yyy log,exec:/home/apache/report-attack.pl — запускает сценарий. Если фильтр срабатывает, то будет выполнен скрипт /home/apache/report-attack.pl;
□ SecFilter /etc/password — устанавливает запрет на использование в запросе пользователя обращения к файлу /etc/passwd. Таким же образом нужно добавить ограничение на файл /etc/shadow;
□ SecFilter /bin/ls — отказ пользователям в обращении к директивам. В данном случае запрещается команда ls, которая может позволить хакеру увидеть содержимое каталогов, если в сценарии есть ошибка. Необходимо предотвратить обращение к таким командам, как cat, rm, cp, ftp и др.;
□ SecFilter "\.\./" — классическая атака, когда в URL указываются символы точек. Их не должно там быть;
□ SecFilter "delete[[:space:]]+from" — запрет текста delete ... from, который чаще всего используется в SQL-запросах для удаления данных. Такая строка очень часто используется в атаках типа SQL injection. Помимо этого, рекомендуется установить следующие три фильтра:
• SecFilter "insert[[:space:]]+into" — используется в SQL-запросах для добавления данных;
• SecFilter "select.+from" — используется в SQL-запросах для чтения данных из таблицы базы данных;
• SecFilter "<(.|\n)+>" и SecFilter "<[[:space:]]*script" — позволяют защититься от XSS-атак (Cross-Site Scripting, межсайтовое выполнение сценариев).
Мы рассмотрели основные методы, использование которых может повысить безопасность вашего Web-сервера. Таким образом, можно защищать даже сети из серверов. Дополнительную информацию можно получить с сайта разработчиков.
7.7.3. Секреты и советы
Как бы аккуратно программист не писал сценарии, как бы вы их не защищали с помощью специальных модулей, неплохо предпринять дополнительные меры безопасности. Есть еще ряд параметров, которыми можно воспользоваться для этих целей. В данном разделе я собрал небольшие рекомендации, которые вам помогут сделать необходимые настройки.
Ограничение сценариев
Во-первых, ограничьте выполнение сценариев только отдельной директорией. Чаще всего это каталог cgi-bin. Однажды я видел систему, в которой для этих целей администратор указал корневой каталог, что позволяло хранить сценарии, где угодно. Не стоит повторять эту ошибку, потому что в системе могут быть различные программы, написанные на Perl, и они должны быть недоступны для выполнения на Web-сервере.
Резервные копии
Никогда не сохраняйте резервные копии сценариев в каталогах, доступных Web-серверам. Рассмотрим пример. Если на сервере есть PHP-скрипты, то пользователи видят только результат их выполнения. Чтобы посмотреть исходный код, хакеру необходим доступ к серверу, например FTP или Telnet, т.к. сервер Apache не передает таких данных клиенту.
Перед тем как вносить изменения в сценарий, программисты любят создавать на сервере резервные копии, чтобы в случае ошибки можно было восстановить старую, но рабочую версию. Для этого очень часто содержимое файла копируется в тот же каталог, под тем же именем, но с другим расширением, например, old или bak (наиболее часто встречаемые).
Такие программы уже не выполняются сервером, и если хакер запросит файл, то он увидит его исходный код, что поможет быстрее найти ошибки в скриптах.
Когда злоумышленник исследует сценарии на сервере, то никто не мешает проверить наличие резервной копии. Допустим, что у вас есть файл www.servername.com/index.php, хакер попробует загрузить www.servername.com/index.bak или www.servername.com/index.old. На любительских сайтах такие версии встречаются очень часто. Не допускайте подобных промахов.
Любой специалист по безопасности должен запретить пользователям работу с резервными копиями. Сколько бы мы не говорили программистам о том, что нельзя держать на сервере ничего лишнего, они все равно продолжают это делать, потому что им так удобно. Наша задача — сделать хранение этих копий безопасными, т.е. запретить доступ со стороны Web-клиентов.
Это можно сделать, используя следующие директивы:
Order deny, allow
Deny from all
Order deny, allow
Deny from all
7.8. Индексация Web-страниц
За последние 10 лет Интернет разросся до таких размеров, что найти в нем что-либо без хорошей поисковой системы стало невозможным. Первые системы просто индексировали страницы по их содержимому и потом использовали полученную базу данных для поиска, который давал очень приблизительные результаты. Если ввести в качестве контекста слово "лук", то будет отобрано огромное количество сайтов по пищевой промышленности и по стрельбе из лука. В большинстве языков есть слова, которые имеют несколько значений, и по ним поиск затруднителен.
Проблема не только в двусмысленности некоторых слов. Есть множество широко употребляемых выражений, по которым тоже сложно произвести точную выборку. В связи с этим поисковые системы стали развиваться, и теперь можно добавлять в запрос различные параметры. Одной из самых мощных является поисковая система www.google.com. В ней реализовано много возможностей, позволяющих сделать поиск более точным. Жаль, что большинство пользователей не освоили их, а вот взломщики изучили все функции и используют в своих целях.
Один из самых простых способов взлома — найти с помощью поисковой системы закрытую Web-страницу. Некоторые сайты имеют засекреченные области, к которым доступ осуществляется по паролю. Сюда же относятся платные ресурсы, где защита основана на проверке пароля при входе, а не на защите каждой страницы и использовании SSL. В таких случаях Google проиндексирует запрещенные страницы, и их можно будет просмотреть через поиск. Для этого всего лишь надо четко знать, какая информация хранится в файле, и как можно точнее составить строку поиска.
С помощью google.com можно найти достаточно важные данные, которые скрыты от пользователя, но по ошибке администратора стали доступными для индексирующей машины Google. Во время поиска нужно правильно задавать параметры. Например, можно ввести в строку поиска следующую команду:
Годовой отчет filetype:doc
Или
Годовой отчет filetype:xls
И вы найдете все файлы в формате Word и Excel, содержащие слова "Годовой отчет". Возможно, документов будет слишком много, поэтому запрос придется ужесточить, но кто ищет, тот всегда найдет. Существуют реальные примеры из жизни, когда таким простым способом были найдены секретные данные, в том числе действующие номера кредитных карт и финансовые отчеты фирм.
Давайте рассмотрим, как можно запретить индексацию каталогов Web-страниц, которые не должны стать доступными для всеобщего просмотра. Для этого необходимо понимать, что именно индексируют поисковые системы. На этот вопрос ответить легко — все, что попадается под руку: текст, описания, названия картинок, документы поддерживаемых форматов (PDF, XLS, DOC и т.д.).
Наша задача — ограничить настойчивость индексирующих роботов поисковых машин, чтобы они не трогали то, что запрещено. Для этого робот должен получить определенный сигнал. Как это сделать? Было найдено достаточно простое, но элегантное решение — в корень сайта помещается файл с именем robots.txt, который содержит правила для поисковых машин.
Допустим, что у вас есть сайт www.your_name.com. Робот, прежде чем начать свою работу, пробует загрузить файл www.your_name.com/robots.txt. Если он будет найден, то индексация пойдет в соответствии с описанными в файле правилами, иначе процесс затронет все подряд.
Формат файла очень простой и состоит всего лишь из двух директив:
□ User-Agent: параметр — в качестве параметра передается имя поисковой системы, к которой относятся запреты. Таких записей в файле может быть несколько, и каждая будет описывать свою поисковую систему. Если запреты должны действовать на все поисковики, то достаточно указать вначале файла директиву User-Agent с параметром звездочка (*);
□ Disallow: адрес — запрещает индексировать определенный адрес, который указывается относительно URL. Например, если вы хотите отказаться от индексации страниц с URL www.your_name.com/admin, то в качестве параметра нужно указать /admin. Как видите, этот адрес берется именно из URL, а не из вашей реальной файловой системы, потому что поисковая система не может знать истинное положение файлов на диске сервера и оперирует только адресами URL.
Вот пример файла robots.txt, который запрещает индексацию страниц, находящихся по адресам www.your_name.com/admin и www.your_name.com/cgi_bin для любых индексирующих роботов поисковых систем:
User-Agent: *
Disallow: /cgi-bin/
Disallow: /admin/
Данные правила запрещают индексацию с учетом подкаталогов. Например, файлы по адресу www.your_name.com/cgi_bin/forum тоже не будут индексироваться.
Следующий пример запрещает индексацию сайта вовсе:
User-Agent: *
Disallow: /
Если на вашем сайте есть директории с секретными данными, то следует запретить их индексацию. Лучше лишний раз отказать, чем потерять. При этом не стоит слишком увлекаться и закрывать все подряд, потому что если сайт не будет проиндексирован, то его не найдут поисковые машины, и вы потеряете большое количество посетителей. Если поинтересоваться статистикой, то можно увидеть, что на некоторых сайтах количество посетителей, пришедших с поисковых систем, превышает заходы по любым другим ссылкам или входы напрямую.
7.9. Безопасность подключения
В разд. 14.5 мы будем рассматривать различные технологии прослушивания сетевого трафика. В основном они эффективны в локальных сетях, но хакеры больше любят интернет-соединения, потому что здесь можно найти больше интересного и есть лазейка, чтобы удаленно проводить атаку.
Как можно, находясь в Европе, перехватить трафик, который проходит между двумя городами в США? Я думаю, что пакеты будут следовать по каналам США, и в Европе им делать нечего. Но задача хакера сделать свой компьютер посредником в передаче пакетов данных, что-то наподобие прокси-сервера.
Самое сложное — организовать, чтобы клиент подключился не к реальному Web-серверу, а к вашему компьютеру. Чаще всего мы в браузерах набираем символьные имена адресов, но соединение происходит по IP-адресу. Для такого сопоставления используются DNS-серверы. Хакер может обмануть клиента с помощью ложного DNS-ответа или подставного DNS-сервера и тем самым перенаправить трафик на себя.
Затем компьютер злоумышленника будет переадресовывать пакеты реальному Web-серверу и возвращать ответы клиенту (рис. 7.3). Таким образом, весь трафик будет проходить через компьютер хакера.
Рис. 7.3. Перехват трафика
Что опасного может увидеть хакер, когда клиент просматривает страницы на Web-сервере? Мы каждый день вводим на Web-страницах какие-либо данные, пароли, номера кредитных карт, и именно это является основной целью хакера. Но этот метод был хорош несколько лет назад, когда не было HTTPS-протокола и безопасного соединения с помощью SSL-шифрования.
Давайте вспомним, что для подключения по SSL любая программа-клиент (например, браузер) и Web-сервер обмениваются ключами, с помощью которых происходит шифрование. Для HTTPS помимо открытого и закрытого ключей необходимы подтвержденные сертификаты, которые выдаются специализированными компаниями. Программа-клиент проверяет сертификат, и если он достоверен (цифровая подпись принадлежит авторизованной фирме), то подключение разрешается. Сертификаты можно сгенерировать самостоятельно, а вот подпись подделать практически невозможно.
Если компьютер хакера просто будет передавать данные между клиентом и сервером, то трафик останется зашифрованным, и его просмотреть не удастся. Единственным вариантом может быть следующая схема:
1. На компьютере хакера генерируется пара ключей и сертификат.
2. Клиент подключается к компьютеру хакера и обменивается с ним ключами.
3. При передаче информации шифрование происходит с ключом, который сгенерировал хакер, поэтому он без проблем расшифровывает все данные.
4. Компьютер хакера соединяется с Web-сервером и получает его ключ.
5. Между компьютером хакера и Web-сервером устанавливается соединение по ключу Web-сервера.
При такой схеме клиент получает ключ, который сгенерирован хакером и не имеет нужной подписи. Это значит, что у клиента появится сообщение о подключении к сайту без необходимого сертификата. И вот тут происходит самое страшное — большинство пользователей, которые давно работают с Интернетом, устали смотреть на различные предупреждения, поэтому, не читая сообщения, нажимают кнопку OK для продолжения работы.
Решить проблему подложного подключения можно только защитой DNS-сервера, чтобы хакер не смог стать посредником в соединении между клиентом и сервером. Не используйте прокси-сервер, в происхождении которого вы не уверены, ведь он может принадлежать хакеру, и тогда весь ваш Web-трафик оказывается в опасности.
Можно еще попытаться перевоспитать пользователей, чтобы они читали все сообщения, которые отображает браузер. Но это сложно. Для этого необходимо, чтобы Web-браузер графически (иконками) ранжировал информацию по степени критичности. Таким образом, увидев сообщение об опасности, пользователь обязательно его прочтет. Если оповещение о подключении к сайту с неподписанным сертификатом сделать важным, то пользователи испугаются и прервут соединение. А ведь таких сайтов достаточно, и многие из них вполне уважаемые и защищенные. Просто подпись стоит денег, а не каждый хочет вкладывать дополнительные средства. А подписанными являются только коммерческие проекты. Но даже среди таких авторитетных ресурсов бывают проблемы. Сертификат действителен только в течение указанного в нем периода, а если администратор не уследил за датой, то он устареет.
Единственное, что должен помнить пользователь, при неавторизованном соединении нельзя вводить номера кредитных карт. Вот это предупреждение должно появляться большими буквами при подключении к серверу с неподписанным сертификатом.