Распространенные проблемы безопасности, с которыми вы сталкиваетесь как поставщик услуг Linux (веб)хостинга

Question

Вопрос к пользователям, имеющим собственный веб-хостинг (физические серверы или являющимся реселлерами):

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

Answer 1

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

Вот список того, что я делаю для большинства серверов (общих и нет), в произвольном порядке:

• Я почти никогда не использую ядро, поставляемое дистрибутивом. Я сохраняю наше собственное дерево ядра, которое идет в ногу с основной веткой Linux... насколько это позволяет grsecurity. Это не просто мера безопасности, это также мера оптимизации. Вы не найдете в наших ядрах таких вещей, как поддержка параллельного интерфейса / USB / аудио (так как веб-серверам они не нужны). Ядра созданы для использования только того, что есть на плате, что нам нужно.
• 9/10 плохих вещей пропускаются через глючные пользовательские скрипты. Многие клиенты знают PHP достаточно, чтобы быть опасными. mod_security — один из моих лучших друзей, я плачу за подписку на укрепленные наборы правил и обновляю их почти еженедельно.
• Аудит имеет решающее значение, я также рекомендую использовать OSSEC или что-то подобное.
• Все мои серверы подключены к обслуживаемой локальной сети, к которой я могу получить доступ независимо от публичной сети. Когда/если что-то пойдет не так и вы обнаружите, что ваш сервер так занят отправкой мусорных пакетов по всему Интернету, вы оцените наличие другого пути. У меня также установлены IP KVM на всех серверах или IPMI в зависимости от оборудования.
• В последнее время я использую Xen в качестве уровня управления для общих серверов. Я создаю одного гостя, который имеет 99% памяти системы. Это позволяет мне делать такие вещи, как восстановление файловой системы / снимки и т. д. довольно безболезненно. Это может действительно помочь в восстановлении, если что-то пойдет не так (и удобно, чтобы скрыть локальную сеть от общего сервера).
• Я использую очень строгий брандмауэр на основе iptables, который особенно строг, когда дело касается исходящего трафика.
• Я очень внимательно отношусь к тому, кто может получить доступ к системному компилятору и инструментам компоновки.
• Я регулярно обновляю системное программное обеспечение.
• Я провожу периодические сканирования, чтобы убедиться, что пользователи не используют по неосторожности старые и уязвимые версии популярных приложений, таких как Wordpress, PHPBB и т. д.
• Я предлагаю бесплатную установку вещей, которые клиенты «находят в Интернете». Это действительно помогает мне проверять то, что размещается, и в то же время предлагать клиентам дополнительную ценность. Это также помогает гарантировать, что все установлено безопасно и правильно.
• Всегда, всегда, всегда укрепляйте PHP, убедитесь, что вы используете suexec для PHP. Нет ничего хуже, чем найти бота в /tmp, принадлежащего 'nobody' :)

И наконец, последнее, но не менее важное:

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

Answer 2

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

Заблокируйте его для определенных IP, отключите его для учетных записей, которым он не нужен. Даже отключите службу, если она не запрошена.

Мне приходилось иметь дело с десятками взломов после загрузки вредоносного кода на веб-сайты, либо спамящих по всему миру, либо перенаправляющих посетителей с помощью инъекций iframe. Редко когда они получают root или доступ к оболочке, вместо этого они просто вызывают тонну ручной работы по уборке серверов из черного списка и ручного поиска кода.

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

Answer 3

Я некоторое время работал в компании веб-хостинга, и это кошмар — обеспечить безопасность всех пользователей. Особенно в общей среде. Частные серверы гораздо проще отслеживать, поскольку проблемы безопасности изолированы только для этой системы.

Вот что следует учитывать при использовании общего хостинга:

• Ошибка на одном сайте может повлиять на все остальные. Поэтому постарайтесь ограничить то, что может делать каждый пользователь, и ограничьте разрешения. Сюда входят ulimit, ограничения php и т. д.
• Мониторинг системы и отдельных сайтов. Такой инструмент, как OSSEC, может быть очень удобен для работы со всей информацией.
• Ядро Linux не имеет хорошей репутации в отношении локальных эксплойтов. Поэтому убедитесь, что оно всегда обновлено, и используйте расширения безопасности ядра (grsecurity, SELinux и т. д.).

Что касается частных серверов, то вы оставляете безопасность на усмотрение пользователей, но не забудьте установить в своей сети надлежащие инструменты QOS, NIDS и anti-DOS.