Михаил Фленов СанктПетербург бхвпетербург 2010 удк 681 06 ббк 32. 973. 26018. 2 Ф69
 Скачать 3.69 Mb.
|
|
www.cydsoft.com. Здесь не указан файл, Глава 7 248 который нужно загрузить Полный 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 , WEB-c ервер 249 PROPFIND , PROPPATCH , MKCOL , COPY , MOVE , LOCK , UNLOCK . Где тут собака зарыта? Допустим , что у вас есть сценарий, которому пользователь должен передать параметры . Это делается одним из методов POST или GET . Если вы заведомо знаете , что программист использует только метод GET , то запретите все ос- тальные , чтобы хакер не смог воспользоваться потенциальной уязвимостью в сценарии, изменив метод. Бывают ситуации, когда не всем пользователям позволено отправлять данные на сервер. Например, сценарии в определенной директории могут быть дос- тупны для исполнения всем, но загружать информацию на сервер могут только администраторы. Эта проблема легко решается с помощью разграни- чения прав использования методов протокола HTTP. Права на использование методов описываются следующим образом: Права Как видите, это похоже на описание разрешений на файлы, даже права дос- тупа используются те же самые. Они размещаются внутри определения директорий ( или ) и влияют только на указанный каталог К примеру, так можно запретить любую передачу данных из директории /home в любом направлении: Deny from all При этом внутри определения прав для директории /home устанавливается запрет на методы GET и POST Ваша задача как администратора — настроить параметры доступа на дирек- тории и файлы, при которых они будут минимально достаточными. Пользо- ватель не должен иметь возможности сделать ни одного лишнего шага. Для реализации этого вы должны действовать по правилу "Что не разрешено, то запрещено ". Я всегда сначала закрываю все, что только можно, и только потом постепен- но смягчаю права, чтобы все сценарии начали работать верно. Лучше лиш- ний раз прописать явный запрет, чем потом упустить разрешение, которое позволит хакеру уничтожить мой сервер. Глава 7 250 7.4. Создание виртуальных WEB- серверов На одном физическом сервере может работать большое количество виртуальных WEB-серверов, например, www.your_name.com и www.your_company.com. Это два разных WEB-сайта, но они находятся на одном сервере. Такое распо- ложение дает нам следующие преимущества: экономия денег на закупке серверов; эффективное использование каналов связи, если сайты небольшие и на- грузка на сервер невысока; экономия IP-адресов, лимит которых уже давно был бы исчерпан, если бы все сайты находились на выделенных серверах (с внедрением протокола IPv6 эта проблема будет стоять не так остро). Виртуальные WEB-серверы могут иметь как отдельные IP-адреса, так и использовать общий адрес, а различаться будут доменными именами; упрощение администрирования и контроля за безопасностью. Конфигура- ция WEB-сервера и его защита — достаточно сложный процесс, поэтому намного легче настроить и обновлять программное обеспечение одного физического сервера, чем сотни серверов, ресурсы каждого из которых используются на 1%. Для создания виртуального сервера используется формат: Между этими тегами указываются параметры виртуального сервера. Вот пример описания сервера, адрес которого 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 WEB-c ервер 251 Рассмотрим только основные параметры, которые указываются при описании виртуального сервера: 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. Эти команды помогут вам настроить идентификацию пользователей при об- ращении к определенным директориям. Например, если у вас есть каталог, работа с которым разрешена только авторизованным пользователям, то можно указать файл паролей и директиву Require valid-user , и при запросе фай- лов из этого каталога сервер предложит авторизоваться, указав имя пользова- теля и пароль. Глава 7 252 7.5.1. Файлы .htaccess Если какая-либо директория WEB-сервера должна иметь особые права, то лучше создать в этом каталоге файл .htaccess. Разрешения, описанные в та- ком файле, действуют на директорию, в которой он находится. Рассмотрим пример содержимого файла .htaccess: AuthType Basic AuthName "By Invitation Only" AuthUserFile /pub/home/flenov/passwd Require valid-user В данном файле для текущей директории указывается тип аутентифика- ции Basic. Это значит, что будет использоваться окно для ввода имени и па- роля . Текст, указанный в директиве AuthName , отобразится в заголовке окна. На рис. 7.1 приведен пример такого окна. Рис . 7.1. Окно запроса имени и пароля Директива AuthUserFile задает файл, в котором находится база имен и паро- лей пользователей сайта. Этот файл можно (и нужно) размещать вне области, доступной через WEB-сервер. Последняя команда Require в качестве пара- метра использует значение valid-user . Это значит, что файлы в текущей ди- ректории смогут открыть только те пользователи, которые прошли аутенти- фикацию Вот таким простым способом можно запретить неавторизованный доступ к директории, содержащей секретные данные или сценарии администратора. WEB-c ервер 253 Как я уже говорил, в файле .htaccess могут находиться и директивы типа Аllow 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}1ZZEBtPy4/gdHsyztjUEWb0d90E= В этой записи два параметра, разделенных двоеточием. Сначала указано имя пользователя , а после разделителя — зашифрованный по алгоритму MD5 па- роль . Формировать такой файл вручную сложно и не имеет смысла, поэтому для облегчения жизни администраторов есть утилита htpasswd. С помощью этой программы создаются и обновляются имена и пароли для базовой аутентификации WEB-сервером HTTP-пользователей. Глава 7 254 Удобство программы в том, что она может шифровать пароли и по алгоритму MD5, и с помощью системной функции crypt() . В одном файле могут нахо- диться записи с обоими типами паролей. Если вы храните имена и пароли в формате базы данных DBM (для ее указа- ния в файле .htaccess используется директива AuthDBMUserFile) , то для управления ею нужно применять команду dbmmanage. Давайте рассмотрим, как пользоваться программой htpasswd. Общий вид вы- зова команды выглядит следующим образом: htpasswd параметры файл имя пароль Пароль и имя файла являются необязательными, и их наличие зависит от ука- занных опций. Давайте рассмотрим ее основные ключи: -c — создать новый файл. Если указанный файл уже существует, то он перезаписывается , и старое содержимое теряется. Например, можно написать : htpasswd –c mypasswd robert После выполнения этой команды перед вами появится приглашение вве- сти пароль для нового пользователя robert и подтвердить его. В результате будет создан файл mypasswd, в котором будет одна запись для пользова- теля robert с указанным вами паролем; -m — использовать модифицированный Apache алгоритм MD5 для паро- лей . Это позволит переносить созданный файл на любую другую плат- форму (Windows, UNIX, BeOS и т. д.), где работает WEB-сервер Apache. Такой ключ удобен, если у вас разнородная сеть, и один файл с паролями используется на разных серверах; -d — применить системную функцию crypt() для шифрования; -s — применить SHA-шифрование (на базе алгоритма хеширования), ко- торое используется на платформе Netscape; -p — не шифровать пароли. Я не рекомендую использовать этот флаг, по- тому что он небезопасен; -n — не вносить никаких изменений, а только вывести результат на экран. Для добавления нового пользователя можно выполнить команду без указания ключей , а передать в качестве параметров только имена файла и пользователя: htpasswd .htaccess Flenov Надо отметить, что хотя пароль можно задавать в командной строке, делать это не следует, так как такая команда небезопасна. Например, команда со- хранится в истории командной оболочки, и незашифрованный пароль может таким (или другим) образом стать известным хакеру. Если пароль не задан, но требуется, то программа запросит его в интерактивном режиме. WEB-c ервер 255 У команды htpasswd есть два ограничения: в имени пользователя не должно быть символа двоеточия, и пароль не может превышать 255 символов. Оба условия достаточно демократичны, и с ними можно смириться. Из моих зна- комых такой длинный пароль пока еще никто не захотел устанавливать, а использовать имя пользователя с двоеточием редко кому приходит на ум. 7.5.3. Проблемы авторизации Авторизация — это слишком простой способ обеспечения безопасности. При передаче пароли шифруются простым кодированием Base64. Если хакер сможет перехватить пакет, содержащий имя пользователя и пароль, то он прочитает эту информацию через пять секунд. Для расшифровки Base64 не нужно подбирать пароль, достаточно выполнить одну функцию, которая декодирует практически моментально. Для создания реально безопасного соединения необходимо сначала зашиф- ровать весь трафик. Для этого может использоваться stunnel или уже гото- вый протокол HTTPS, который использует SSL. О нем мы еще поговорим в разд. 7.9. 7.5.4. Обработка на сервере HTML-файлы могут обрабатываться прямо на сервере (так же, как выполня- ются файлы PHP). С одной стороны, это удобно, потому что код PHP можно будет вставлять в файлы с расширением htm, с другой стороны, HTML- файлы далеко небезопасны, и если хакер сможет их изменять, то сервер ока- жется под угрозой. Чтобы разрешить серверу выполнять файлы с определенными расширениями на сервере, используется директива AddHandler . В конфигурационном файле httpd.conf можно найти следующие строки с этой командой: AddHandler cgi-script .cgi AddHandler server-parsed .shtml Если у вас нет необходимости использовать интерпретатор языка Perl, то первую строку следует закомментировать, чтобы она даже не смущала. Вто- рая строка безобидна, но если таким же образом разрешить серверу работать с HTM- или HTML-файлами, то это уже станет небезопасным. Следующей строки в вашем конфигурационном файле быть не должно: AddHandler server-parsed .html Если где-то действительно есть необходимость выполнять включения в HTML- документах , то пропишите это в файле .htaccess. В остальных директориях я рекомендую в явном виде запретить обработку HTML-файлов сервером. Глава 7 256 Для этого добавьте следующую строку в конфигурационный файл 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/basic.conf — такой файл на- до создать; комментируйте все ваши действия. Многие настройки не изменяются го- дами , и уже через полгода трудно вспомнить, зачем вы установили опре- деленную директиву. Например, вы запретили доступ для всех пользова- телей к какой-либо директории, которая временно использовалась для тестирования сценариев. Через какое-то время вы можете забыть об этом и случайно открыть доступ к сценариям, которые не были полностью от- лажены и могут стать причиной взлома или крушения системы. Если вы последовали первым двум рекомендациям, то нужно включить эти файлы в основной файл при помощи директивы Include , например WEB-c ервер 257 Include /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 и любой ее поддиректории будут иметь указанные права, если они явно не переопределены для отдельных папок. Это значит, что под шаблон попадут такие папки, как /home/robert/public_html, /home/other_user/public_html и т. д. Глава 7 258 7.7. Безопасность сценариев Как мы уже говорили, сценарии являются очень опасными для WEB-сервера. Через их ошибки происходило очень много громких взломов. Мы уже знаем, что необходимо отключить все интерпретаторы, которые не используются, и оставить только то, что нужно. Этим мы усложним задачу хакера, но не решим проблему полностью. Наиболее безопасный сайт — это тот, что использует статичные (HTML) до- кументы и не имеет сценариев, выполняемых на сервере (PHP, ASP, Perl, Py- thon и др.). Если вам нужен какой-то интерпретатор, то необходимо макси- мально ограничить его возможности. Допустим , что ваш сайт использует сценарии PHP, и в этих сценариях есть функции , которые обращаются к системе. Если вы их неверно используете (например, не проверяются параметры, заданные пользователем), то зло- умышленник имеет возможность передать такие значения, которые могут нарушить работу сервера. Мы не будем говорить о том, как правильно писать сценарии и как их делать безопасными, потому что это задача программи- стов . Но не стоит надеяться на их профессионализм, потому что все мы — люди , и нам свойственно ошибаться. Администратор должен сделать все, чтобы погрешности не стали фатальными. В интерпретаторе PHP есть возможность описывать правила выполнения ка- ких -либо действий, используя более безопасные настройки и права досту- па — это режим safe_mode. Но вы должны отдавать себе отчет в том, что некоторые скрипты могут отказаться работать в этом режиме. Многие адми- нистраторы отключают safe_mode . Это не совсем верно. Я всегда сначала проверяю , можно ли переписать сценарий, и выключаю безопасный режим лишь если это нереально. При настройке интерпретатора вы опять же должны действовать от запрета. Изначально следует закрыть все, что нужно и ненужно. А потом включать необходимые вашим сценариям опции. Лучше всего, если вы будете зани- маться конфигурированием не только рабочего сервера, но и сервера, кото- рый используют программисты для разработки и отладки своих сценариев. В этом случае можно будет контролировать все установленные параметры. Действия администратора должны быть тесно связаны с работой программи- ста сценариев для WEB-сайта. Если разработчику нужны какие-то опции, то именно вы должны их включать на обоих серверах. О любых корректировках скриптов , влекущих за собой уменьшение (увеличение) прав доступа, разра- ботчик должен вам сообщать, и настройки должны быть изменены. WEB-c ервер 259 Администратор и разработчик должны находиться в постоянном контакте, чтобы оперативно реагировать на необходимость использования каких-либо дополнительных возможностей. Некоторые администраторы избавляются от настройки интерпретаторов и переводят эти функции на разработчиков. Это не совсем правильно, потому что программист умеет писать код, но чаще всего не может достаточно хорошо разбираться в вопросах конфигурации серверов , чтобы обеспечить требуемый уровень безопасности. Все настройки для интерпретатора PHP хранятся в файле /etc/php.ini. Мы этот файл не будем рассматривать, потому что эта тема выходит за рамки книги про Linux. 7.7.1. Основы безопасности В настоящее время большинство взломов в Интернете совершается с помо- щью или благодаря ошибкам в сценариях WEB-страниц. Давайте попробуем разобраться , почему это происходит. Большинство владельцев домашних сайтов — это простые пользователи, ко- торые хотят быстро получить собственную страницу с множеством возмож- ностей . А что именно нужно сайту? Конечно же, это гостевая книга, форум, чат , голосование и т. д. Все эти разделы нельзя сделать с помощью языка разметки HTML, и нужны знания программирования, например, на Perl или PHP. Пользователи не хотят (или не могут) вникать в тонкости программиро- вания , поэтому используют в своих проектах уже готовые (платные или бес- платные ) движки. Как я уже неоднократно говорил, любая разработка содержит ошибки, про- сто о них до поры до времени никому не известно. А распространенная программа становится лакомым кусочком для любого хакера, потому что ее взлом позволяет приникнуть сразу во множество систем, где она уста- новлена Если администратор сайта устанавливает на свою страничку популярный фо- рум , то он должен понимать, что когда-нибудь в нем найдут уязвимость, и через нее любой злоумышленник проникнет в систему. Чтобы этого не произошло , администратор сайта должен регулярно обновлять используемые WEB-программы и WEB-сценарии. Если вы решили написать собственный форум для сайта, то он может ока- заться более надежным, если вы знаете хотя бы основные принципы защи- ты WEB-приложений. В этом случае ваша работа будет безопаснее, чем при использовании любой готовой программы и, тем более, программы с от- крытым кодом. Глава 7 260 Ну а если вы не знаете особенностей языка или вообще не знакомы с про- граммированием , то лучше даже не пытаться. В этом случае и начинающий хакер найдет уязвимость, даже не зная исходного кода, структуры базы дан- ных и других параметров, упрощающих взлом WEB-сценария. Как видите, сложности есть всегда. Самый безопасный вариант — использо- вать на WEB-сайтах наименее распространенные программы, написанные профессиональными программистами. Лучше всего, если они будут с закры- тым кодом или даже написаны на заказ. Это требует дополнительных затрат, но расходы на восстановление системы после взлома намного больше. Если вы отвечаете за один WEB-сервер, то легко сможете контролировать обновление программ. Хуже всего администраторам хостинговых компаний. На их серверах расположены сотни, а то и тысячи WEB-сайтов. Проследить за всеми хозяевами сайтов нереально, поэтому нужно защитить свои владе- ния от недобросовестных или ленивых пользователей. Для этих целей лучше всего подходит программа jail, о которой мы говорили в главе 4. Для WEB- сервиса вы должны создать его собственный виртуальный сервер, в котором он и будет работать. Если злоумышленник взломает систему через WEB- программу , то сможет нарушить работу только виртуальной директории. Во время подготовки материалов для данной книги в одном из популярных форумов была найдена уязвимость, позволяющая выполнять любые команды на удаленной системе. Для этого нужно было директиву специальным обра- зом передать через строку URL. Эту главу я начал писать через месяц после этого страшного открытия, и почему-то вспомнив про ошибку, решил прове- рить серверы в Интернете. Я запустил поиск всех сайтов, содержащих уязви- мый форум. Вы не поверите, но их были сотни. Меня заинтересовала пара сайтов, расположенных на серверах крупных хостинговых компаний. На обоих я выполнил команду ls -a /etc . Резуль- тат не заставил себя ждать. Я увидел всю директорию /etc, и моих прав хва- тало даже на удаление файлов. Конечно же, делать этого я не стал даже в тестовых целях. Для доказательства серьезности ошибки я переименовал по одному файлу на каждой системе и сообщил об уязвимости админист- раторам В Н И МА Н И Е ! Не советую вам повторять подобные действия Взлом даже с добрыми наме - рениями не всеми администраторами воспринимается положительно Некото - рые могут сообщить о ваших действиях в правоохранительные органы , и тогда вам не избежать судебных тяжб Благие побуждения могут быть восприняты неверно Если я нахожу какую - либо дыру , то всегда сообщаю администрато - рам , но отправляю для этого письмо анонимно WEB-c ервер 261 Конечно же, переместив Apache в виртуальное пространство, вы обезопасите только свою систему, но все сайты, которые работают в этом пространстве, остаются уязвимыми. Здесь уже нужно искать другие методы защиты, на- пример , через права доступа, запуск нескольких копий Apache (каждый рабо- тает в своем пространстве), выделенные серверы для каждого сайта, запрет на выполнение опасных функций в интерпретаторе PHP и т. д. Выбрать какой-либо определенный метод защиты множества виртуальных серверов достаточно сложно, а иногда просто невозможно. Например, один сайт требует для своей работы интерпретатор Perl, а другой — PHP. Прихо- дится включать обе возможности. Из собственного опыта могу посоветовать использовать несколько физиче- ских серверов для разделения сайтов в соответствии с их потребностями: используется интерпретатор PHP в защищенном режиме; нужен интерпретатор PHP с полными правами; применяется интерпретатор Perl. И так далее. Вы должны сгруппировать сайты, исходя из их требований, и тогда администрирование станет намного удобнее и проще. Особо важные сайты должны располагаться на выделенном сервере и на- ходиться под пристальным присмотром. Например, нельзя размещать на одном физическом сервере сайт электронного магазина и домашние стра- нички , очень часто использующие бесплатные или некачественные модули, в которых бывают ошибки, пользователи которых, к тому же, не обновляют эти программы. Когда-нибудь злоумышленник взломает домашнюю стра- ничку через уязвимые сценарии и сможет украсть номера кредитных карт пользователей интернет-магазина. Это поставит крест на вашей карьере администратора 7.7.2. mod_security Несмотря на то, что безопасность WEB-сервера, в основном, зависит от вы- полняемых на нем сценариев и программистов, которые пишут эти скрипты, есть возможность защитить сервер вне зависимости от этих факторов. Отличное решение данной проблемы — бесплатный модуль для Apache под названием mod_security. Принцип действия модуля схож с сетевым экраном, который встроен в ОС, только в данном случае он специально разработан для обеспечения взаимо- действия по протоколу HTTP. Модуль на основе правил, которые задает ад- министратор , анализирует запросы пользователей к серверу и выносит свое решение о возможности пропустить пакет к WEB-серверу. Глава 7 262 Правила определяют, что может быть в запросе, а что нет. Там обычно со- держится URL-адрес, с которого необходимо взять документ или файл. Как можно сформулировать правило для модуля с точки зрения безопасности системы ? Рассмотрим простейший пример — для сервера опасно незаконное обращение к файлу /etc/passwd, а значит, его не должно быть в строке URL. Таким образом, сетевой экран проверяет на основе заданных фильтров адрес URL, и если он нарушает правила, то запрос отклоняется. Итак , модуль mod_security находится на сайте www.modsecurity.org. После его установки в файле httpd.conf можно будет использовать дополнительные директивы фильтрации запросов. Рассмотрим наиболее интересные из них: SecFilterEngine On — включить режим фильтрации запросов; SecFilterCheckURLEncoding On — проверять кодировку URL; 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/passwd — устанавливает запрет на использование в за- просе пользователя подстроки "/etc/passwd". Таким же образом нужно до- бавить ограничение на файл /etc/shadow; SecFilter /bin/ls — отказ пользователям в обращении к директивам. В данном случае запрещается команда ls , которая может позволить хакеру увидеть содержимое каталогов, если в сценарии есть ошибка. Необходимо предотвратить обращения к таким командам, как cat , rm , cp , ftp и др.; WEB-c ервер 263 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 не передает таких данных клиенту. Глава 7 264 Перед тем как вносить изменения в сценарий, программисты любят создавать на сервере резервные копии, чтобы в случае ошибки можно было восстано- вить старую, но рабочую версию. Для этого очень часто содержимое файла копируется в тот же каталог, под тем же именем, но с другим расширением, например , old или bak (наиболее часто встречаемые). Такие программы уже не выполняются сервером, и если хакер запросит та- кой файл, то он увидит его исходный код, что поможет быстрее найти ошиб- ки в скриптах. Когда злоумышленник исследует сценарии на сервере, то никто не мешает ему проверить наличие резервной копии. Увидев, что у вас есть файл www.servername.com/index.php, хакер попробует загрузить www.servername.com/index.bak или www.servername.com/index.old. На непро- фессиональных сайтах такие версии встречаются очень часто. Не допускайте по- добных промахов. Любой специалист по безопасности должен запретить работу с резервными копиями . Сколько бы мы не говорили программистам о том, что нельзя дер- жать на сервере ничего лишнего, они все равно продолжают это делать, по- тому что им так удобно. Наша задача — сделать хранение этих копий безо- пасным , то есть запретить к ним доступ со стороны WEB-клиентов. Чаще всего для резервных копий файлов используются те же имена файлов, но расширение меняется на .bak или .old. Следующий пример запрещает пользователям доступ к таким файлам: Order deny, allow Deny from all Order deny, allow Deny from all 7.8. Индексация WEB- страниц За последние 10 лет Интернет разросся до таких размеров, что найти в нем что -либо без хорошей поисковой системы стало невозможным. Первые такие системы просто индексировали страницы по их содержимому и потом ис- пользовали полученную базу данных для поиска, что давало очень приблизи- тельные результаты. Если ввести в качестве контекста слово "лук", то будет WEB-c ервер 265 отобрано огромное количество сайтов по пищевой промышленности и по стрельбе из лука. В большинстве языков есть слова, которые имеют несколь- ко значений, и поиск по ним затруднителен. Проблема не только в двусмысленности некоторых слов. Есть множество широко употребляемых выражений, по которым тоже сложно произвести точную выборку. В связи с этим поисковые системы стали развиваться, и те- перь можно добавлять в запрос различные параметры. Одной из самых мощ- ных является поисковая система Google (www.google.com). В ней реализова- но много возможностей, позволяющих сделать поиск более точным. Жаль, что большинство пользователей не освоили их, а вот взломщики изучили все функции , и используют в своих целях. Один из самых простых способов взлома — найти с помощью поисковой системы закрытую WEB-страницу. Некоторые сайты имеют засекреченные области , к которым доступ осуществляется по паролю. Сюда же относятся платные ресурсы, где защита основана на проверке пароля при входе, а не на защите каждой страницы и использовании SSL. В таких случаях часто случа- ется , что Google индексирует запрещенные страницы, и их можно просмот- реть через поиск. Для этого всего лишь надо четко знать, какая информация хранится в файле, и как можно точнее составить строку поиска. С помощью Google можно найти достаточно важные данные, которые скры- ты от пользователя, но по ошибке администратора стали доступными для ин- дексирующей машины Google. Во время поиска нужно правильно задавать параметры . Например, можно ввести в строку поиска следующую строку: Годовой отчет filetype:doc Или Годовой отчет filetype:xls И вы найдете все документы в формате Word и Excel, содержащие слова "Го- довой отчет". Возможно, документов будет слишком много, поэтому запрос придется ужесточить, но кто ищет, тот всегда найдет. Существуют реальные примеры из жизни, когда таким простым способом были найдены секретные данные , в том числе действующие номера кредитных карт и финансовые от- четы фирм. Давайте рассмотрим, как можно запретить индексацию каталогов WEB- страниц , которые не должны стать доступными для всеобщего просмотра. Для этого необходимо понимать, что именно индексируют поисковые систе- мы . На этот вопрос ответить легко — все, что попадается под руку: текст, описания , названия картинок, документы поддерживаемых форматов (PDF, XLS, DOC и т. д.). Глава 7 266 Наша задача — ограничить настойчивость индексирующих роботов поиско- вых машин, чтобы они не трогали то, что запрещено. Для этого робот должен получить определенный сигнал. Как это сделать? Было найдено достаточно простое , но элегантное решение — в корень сайта помещается файл с именем 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: / Если на вашем сайте есть директории с секретными данными, то следует за- претить их индексацию. Лучше лишний раз отказать, чем раскрыть секрет. При этом не стоит слишком увлекаться и закрывать все подряд, потому что если сайт не будет проиндексирован, то его не найдут поисковые машины, WEB-c ервер 267 и вы потеряете большое количество посетителей. Если поинтересоваться ста- тистикой , то можно увидеть, что на некоторых сайтах количество посетите- лей , пришедших с поисковых систем, превышает число зашедших по любым другим ссылкам или напрямую. 7.9. Безопасность подключения Различные технологии прослушивания сетевого трафика в основном эффек- тивны в локальных сетях, но хакеры больше любят интернет-соединения, потому что здесь можно найти больше интересного и есть лазейка, чтобы удаленно проводить атаку. Что опасного может увидеть хакер, когда клиент просматривает страницы на WEB-сервере? Мы каждый день вводим на WEB-страницах какие-либо дан- ные , пароли, номера кредитных карт, и именно это является основной целью хакера Как можно, например, находясь в Европе, перехватить трафик, который про- ходит между двумя городами в США? Я думаю, что пакеты будут следовать по каналам США, и в Европе им делать нечего. Но задача хакера сделать свой компьютер посредником в передаче пакетов данных, что-то наподобие прокси -сервера. Самое сложное — организовать, чтобы клиент подключился не к реальному WEB-серверу, а к вашему компьютеру. Чаще всего мы в браузерах набираем символьные имена адресов, но соединение происходит по IP-адресу. Для та- кого сопоставления используются DNS-серверы. Хакер может обмануть кли- ента с помощью ложного DNS-ответа или подставного DNS-сервера и тем самым перенаправить трафик на себя. Затем компьютер злоумышленника будет переадресовывать пакеты реально- му WEB-серверу и возвращать ответы клиенту (рис. 7.2). Таким образом, весь трафик будет проходить через компьютер хакера. Hacker WEB Server Client Рис . 7.2. Перехват трафика Но этот метод был хорош несколько лет назад, когда не было HTTPS- протокола и безопасного соединения с помощью SSL-шифрования. Давайте Глава 7 268 вспомним , что для подключения по SSL программа-клиент и сервер обмени- вается ключами, с помощью которых происходит шифрование. Для HTTPS помимо открытого и закрытого ключей необходимы подтвержденные серти- фикаты , которые выдаются специализированными компаниями и подтвер- ждают подлинность ключа. Программа-клиент проверяет сертификат, и если он достоверен (цифровая подпись принадлежит авторизованной фирме), то подключение разрешается. Сертификаты можно сгенерировать самостоя- тельно , а вот подпись подделать практически невозможно. Если компьютер хакера просто будет передавать данные между клиентом и сервером, то трафик останется зашифрованным, и его просмотреть не уда- стся . Единственным вариантом может быть следующая схема: 1. На компьютере хакера генерируется пара ключей и сертификат. 2. Клиент подключается к компьютеру хакера и обменивается с ним клю- чами 3. При передаче информации шифрование происходит с ключом, который сгенерировал хакер, поэтому он без проблем расшифровывает все данные. 4. Компьютер хакера соединяется с WEB-сервером и получает его ключ. 5. Между компьютером хакера и WEB-сервером устанавливается соедине- ние по ключу WEB-сервера. При такой схеме клиент получает ключ, который сгенерирован хакером и не имеет нужной подписи. Это значит, что у клиента появится сообщение о подключении к сайту без необходимого сертификата. И вот тут происхо- дит самое страшное — большинство пользователей, которые давно работают с Интернетом, устали смотреть на различные предупреждения, поэтому, не читая сообщения, нажимают кнопку OK для продолжения работы. Решить проблему подложного подключения можно только защитой DNS- сервера , чтобы хакер не смог стать посредником в соединении между клиен- том и сервером. Не используйте прокси-серверы, в происхождении которых вы не уверены, ведь они могут принадлежать хакеру, и тогда весь ваш WEB- трафик оказывается в опасности. Можно еще попытаться перевоспитать пользователей, чтобы они читали все сообщения , которые отображает браузер, но это сложно. Для этого необхо- димо , чтобы WEB-браузер графически (иконками) ранжировал информацию по степени критичности. Таким образом, увидев сообщение об опасности, пользователь обязательно его прочтет. Если сообщение о подключении к сайту с неподписанным сертификатом сделать важным, то пользователи испугаются и прервут соединение. WEB-c ервер 269 С другой стороны, таких сайтов достаточно много, и многие из них вполне уважаемы и защищены. Просто за подпись надо платить, а не каждый захо- чет платить за проекты, которые не будут приносить денег. Таким образом, подписанными чаще всего являются коммерческие проекты. Но даже у плат- ных и авторитетных ресурсов бывают проблемы. Сертификат действителен только в течение указанного в нем периода, и если администратор не уследил за датой, то он устареет. Единственное , что должен помнить пользователь: при неавторизованном со- единении нельзя вводить действительно секретной информации, например, номера кредитных карт. Вот это предупреждение должно появляться боль- шими буквами при подключении к серверу с неподписанным сертификатом. |