Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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

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

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

О некоторых вещах, которые следует помнить о виртуальном хостинге:

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

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