Общий хостинг. Это дешевый вариант, не так ли? И для огромного количества населения это все, что им когда-либо потребуется для размещения своего веб-сайта или веб-приложения. И когда все сделано хорошо, виртуальный хостинг является масштабируемым, быстрым и безопасным.
Но что происходит, когда это не сделано хорошо?
Хорошо, вот когда начинают появляться опасные проблемы с безопасностью. Это когда ваш сайт рискует быть испорченным или утечка личных данных, которые вы храните. Но не волнуйтесь. Подавляющее большинство веб-хостов имеют достойные меры безопасности. Вы должны быть осторожны только с ночными хозяевами в подвале.
Мы рекомендуем хостинг InMotion Hosting с SSD-хранилищем .
Мы собираемся исследовать проблемы безопасности, связанные с общим хостингом. Но сначала давайте поговорим о том, что делает платформу общего хостинга безопасной.
Что делает безопасный веб-хостинг
Есть несколько выдающихся соображений безопасности, которые должны быть сделаны в отношении общего хостинга.
- Каждый пользователь на сервере должен быть изолирован от других пользователей и не должен иметь возможности доступа или изменения файлов других пользователей.
- Уязвимость безопасности в логике веб-сайта, размещенного на сервере, не должна влиять на других пользователей.
- Сервер регулярно обновляется, обновляется и отслеживается для решения проблем безопасности архитектуры.
- Каждый пользователь должен иметь собственный доступ к изолированной базе данных, и ему не должно быть разрешено вносить изменения в сохраненные записи или разрешения таблиц других пользователей.
Опять же, большинство веб-хостов отвечают этим требованиям для своих общих предложений. Но если вы хотите разместить несколько веб-сайтов на одном сервере, или вам интересно узнать, как складывается ваша хостинговая компания, или даже подумываете о создании собственной хостинговой компании и хотите решить, как защитить своих пользователей, тогда, пожалуйста, прочитайте на.
Но сначала отказ от ответственности
Прежде чем мы углубимся в рассмотрение общих атак, направленных на виртуальный хостинг, я просто хочу заявить, что этот пост не будет (и не должен восприниматься как) исчерпывающим списком потенциальных проблем безопасности.
Одним словом, безопасность велика. Есть много способов, которыми вы можете скомпрометировать сайт. Это удваивается для общего хостинга. Освещение их в одной статье никогда не было на карточках.
Если вы не уверены в своей безопасности, приобретите VPS или выделенный сервер. Это среды, в которых у вас есть (по большей части) абсолютный контроль над тем, что происходит. Если вы не уверены в различных видах веб-хостинга, ознакомьтесь с этой от моего коллеги Джеймса Брюса.
Я также должен подчеркнуть, что этот пост не следует рассматривать как атаку на виртуальный хостинг. Скорее, это чисто академический взгляд на проблемы безопасности, связанные с этой категорией веб-хостинга.
Обратный путь в каталогах
Давайте начнем с атак через каталоги (часто называемые «обходом пути»). Этот вид атаки позволяет получить доступ к файлам и каталогам, которые хранятся вне веб-корня.
На простом английском? Что ж, давайте представим, что Алиса и Боб используют один и тот же сервер для размещения своих сайтов. Файлы Алисы хранятся в / var / www / alice, а документы Боба можно найти в / var / www / bob. Кроме того, давайте представим, что на сервере есть еще одна папка (/ usr / crappyhosting / myfolder), в которой находится незашифрованный текстовый файл (назовем его pwd.txt), содержащий системные имена пользователей и пароли.
Со мной так далеко? Хорошо. Теперь давайте представим, что веб-сайт Боба обслуживает файлы PDF, которые создаются локально, а локальный файл указан в URL-адресе. Что-то вроде:
http://example.com/file?=report.pdf
Что произойдет, если я заменим файл report.pdf на некоторые параметры UNIX, которые изменят каталог?
http://example.com/file?=../alice/
Если сервер настроен неправильно, это позволит вам увидеть корневой каталог документа Алисы. Интересно, но нас больше интересует этот сочный паспорт. Accio пароли !
http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt
Это действительно так просто. Но как мы справимся с этим? Это легко.
Вы когда-нибудь слышали о малоизвестной утилите Linux под названием chroot ? Вы, наверное, уже догадались, что он делает. Он устанавливает корневой каталог Linux / UNIX в произвольную папку, что делает невозможным его выход для пользователей. По сути, он останавливает атаки обхода каталогов на своем пути.
Трудно сказать, имеет ли это место у вашего хозяина, не нарушая закон. В конце концов, чтобы проверить это, вы будете получать доступ к системам и файлам, к которым у вас нет прав доступа. Имея это в виду, возможно, было бы разумно поговорить с вашим веб-хостингом и узнать, как они изолируют своих пользователей друг от друга.
Вы используете свой собственный хостинг-сервер и не используете chroot для защиты своих пользователей? По общему признанию, привязка к вашей среде может быть трудной. К счастью, есть множество плагинов, которые делают это легко. В частности, обратите внимание на mod_chroot.
Инъекция команд
Вернемся к Алисе и Бобу. Итак, мы знаем, что у веб-приложения Боба есть несколько … Хм … проблем с безопасностью. Одной из них является уязвимость внедрения команд, которая позволяет запускать произвольные системные команды
Веб-сайт Боба позволяет вам выполнить запрос whois на другом веб-сайте, который затем отображается в браузере. Существует стандартное поле ввода HTML, которое принимает имя домена, а затем запускает системную команду whois. Эта команда выполняется путем вызова PHP-команды system ().
Что произойдет, если кто-то введет следующее значение?
example.com && cd ../alice/ && rm index.html
Ну, давай разберемся. Некоторые из них могут быть вам знакомы, если вы прочитали наше «Руководство по началу работы с Linux». электронной книге, которую мы ранее опубликовали в 2010 году, или просмотрели наш шпаргалку по командной строке Linux .
Во-первых, он запустит запрос whois на example.com. Тогда он изменит текущий рабочий каталог на корневой каталог документа Алисы. Затем он удалит файл с именем «index.html», который является страницей индекса для ее веб-сайта. Это не хорошо. Нет, сэр.
Итак, как системные администраторы, как мы можем противостоять этому? Что ж, возвращаясь к предыдущему примеру, мы всегда можем поместить каждого пользователя в отдельную изолированную, очищенную, изолированную среду.
Мы также можем подойти к этому на уровне языка. Возможно (хотя это может сломать вещи) глобальное удаление объявлений функций из языков. То есть можно удалить функциональность с языков, к которым у пользователей есть доступ.
В частности, рассматривая PHP, вы можете удалить функциональность с помощью Runkit — официального инструментария PHP для изменения функциональности языка. Там множество документов. Прочитайте в это.
Вы также можете изменить конфигурационный файл PHP (php.ini), чтобы отключить функции, которые часто используются хакерами. Для этого откройте терминал на вашем сервере и откройте файл php.ini в текстовом редакторе. Мне нравится использовать VIM, но NANO также приемлем.
Найдите строку, которая начинается с disable_functions, и добавьте определения функций, которые вы хотите запретить. В этом случае это будут exec, shell_exec и system, хотя стоит отметить, что существуют другие встроенные функции, которые могут быть использованы хакерами.
disable_functions = EXEC, shell_exec, система
Языковые и интерпретируемые атаки
Итак, давайте посмотрим на PHP. Это язык, который обеспечивает потрясающее количество веб-сайтов. Это также идет со многими особенностями и странными поведениями. Как это.
PHP обычно используется вместе с веб-сервером Apache. По большей части невозможно загрузить несколько версий языка с этой конфигурацией.
Почему это проблема? Что ж, давайте представим, что веб-приложение Боба изначально было создано в 2002 году. Это давно. Это вернулось, когда Мишель Бранч все еще лидировала в чартах, Майкл Джордан все еще играл за Washington Wizards, а PHP был совершенно другим языком.
Но сайт Боба все еще работает! Он использует целую кучу устаревших и устаревших функций PHP, но работает! Использование современной версии PHP будет эффективно разрушать веб-сайт Боба, и почему Боб должен переписать свой веб-сайт, чтобы удовлетворить прихоти своего веб-хостинга?
Это должно дать вам представление о дилемме, с которой сталкиваются некоторые веб-хосты. Они должны сбалансировать поддержание архитектурно надежного и безопасного обслуживания, в то же время поддерживая его в гармонии с удовлетворением клиентов, которые платят.
В результате, нередко можно видеть, как меньшие независимые хосты используют более старые версии интерпретатора PHP (или любого другого языка, если на то пошло).
Нередко независимые хосты меньшего размера используют более старые версии PHP, что потенциально подвергает пользователей угрозам безопасности.
Почему это плохо? Ну, во-первых, это подвергнет пользователей ряду угроз безопасности. Как и большинство основных программных пакетов, PHP постоянно обновляется для устранения множества уязвимостей в области безопасности, которые постоянно обнаруживаются (и раскрываются).
Кроме того, это означает, что пользователи не могут использовать новейшие (и лучшие) языковые функции. Это также означает, что функции, которые были исключены по какой-либо причине, остаются. В случае с языком программирования PHP , это включает в себя ужасные (и недавно устарелые) функции mysql_, которые используются для взаимодействия с системой реляционных баз данных MySQL, и dl (), которая позволяет пользователям импортировать свои собственные языковые расширения.
Как пользователь, вы должны видеть, какая версия интерпретатора работает в вашем сервисе. Если он устарел или содержит ряд уязвимостей, обратитесь к своему хосту.
А как насчет системных администраторов? У вас есть несколько вариантов здесь. Первое (и наиболее перспективное) — использовать Docker для каждого из ваших пользователей. Docker позволяет вам запускать несколько изолированных сред одновременно, как и на виртуальной машине, хотя и без необходимости запуска другой операционной системы. В результате это быстро. Действительно, очень быстро.
На простом английском? Вы можете запустить новейший и самый передовой интерпретатор для большинства своих пользователей, в то время как клиенты, использующие старые приложения, которые используют устаревшие устаревшие интерпретаторы, делают это без ущерба для других пользователей.
Это также имеет то преимущество, что не зависит от языка. PHP, Python, Ruby. Без разницы. Все то же самое.
Не иметь кошмаров.
Этот пост был призван сделать пару вещей. Во-первых, он должен был привлечь ваше внимание к числу проблем безопасности, с которыми приходится сталкиваться веб-хостинговым компаниям для обеспечения безопасности своих клиентов и их данных.
Он также должен был показать вам, как сайты, размещенные на одном сервере, могут влиять друг на друга. Хотите поставить вмятину в этом? Начните соблюдать хорошие, безопасные стандарты кодирования. В частности, начните дезинфекцию ваших входных данных как на входной, так и на серверной части.
Хорошее начало — с новой функциональностью проверки формы HTML5. Мы говорили об этом раньше в нашем руководстве по HTML5. В совокупности мы можем сделать сайты более безопасными, будучи более добросовестными программистами.
Как всегда, я готов услышать ваши мысли. Оставьте мне комментарий ниже.
Фото: всем нужен хакер (Александр Дюлауной) , наклейка на окне такси (Кори Доктороу) , серверная комната (Torkild Retvedt) , книги и журналы Linux (library_mistress) , PHP Elephant (Маркус Такер)