Статьи ⇒ Общее ⇒ Безопасность виртуального хостинга

Безопасность виртуального хостинга

Опубликовано: 12 ноя 2011 в 19:30
Автор: freeeeez  

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

Доступ к файлам для владельцев систем

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

Просматривать, а тем более изменять файлы вне своего каталога на FTP-сервере пользователь не может. В качестве корневого каталога очень часто выбирается каталог, являющийся подкаталогом домашнего каталога пользователя. Это позволяет вам иметь файлы, которые не будут доступны для чтения или изменения по протоколу HTTP (например, .htaccess).

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

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

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

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

Если злоумышленник все-таки прочитает содержимое некоторых файлов, это может нести за собой следующие последствия:

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

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

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

В случае с конфигом для доступа к БД, раскрытие пароля может привести к самым критичным последствиям. Не редко админы используют одинаковые пароли доступа ко всем сервисам хостинга (FTP, SSH, Telnet). Это грозит полной потерей управления сайтом и ваша информация может быть скомпрометирована.

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

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

Тэги:  •  •  •  •  •  • 
Нет комментариев
5 152 просмотра


Оставить комментарий:

Имя:
Email:
Сайт:
Комментарий:

Допустимые теги: <em> • <strong> • <u> • <sub> • <sup> • <blockquote>

Проверочный код:

Введите проверочный код, для подтверждения, что вы не робот.
P.S. Если вы робот, то, к сожалению, вы
не сможете прочитать символы с картинки.