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

Излишняя безопасность веб-сервера?

Я проводил «обширные» исследования по обеспечению безопасности веб-сервера Linux. Помимо того, что считается «основами» (удаление неиспользуемых служб, усиление защиты ssh, iptables и т. Д.), Разумно ли включать антируткиты (Tripwire) и антивирус (ClamAV)? Это просто перебор для веб-сервера? Я знаю, что это очень расплывчатый вопрос, но мне интересно узнать мнение других.

Моя будущая среда: - ubuntu 10.04 - fail2ban - nginx 0.8.x - php 5.3.x (suhosin, apc, memcached) - mongodb 1.6.x

Возможные приложения: - веб-сервисы - веб-приложения с пользовательскими загрузками (изображения, PDF-файлы и т. Д.) - типовые веб-сайты (формы и т. Д.)

Если у вас есть другие советы, не стесняйтесь добавлять!

Спасибо

Для общедоступного сервера я бы сказал, что установка чего-то вроде tripwire не является излишним.

Другое дело ClamAV. Я бы подумал о том, чтобы настроить это, если ваши посетители будут обмен файлы, загружая на свой веб-сайт и скачивая с него. PDF-файлы могут содержать эксплойты.

На публичных серверах у меня SSH не разрешает аутентификацию по паролю, а только аутентификацию с открытым ключом. Если SSH возможен только из внутренней локальной сети, вы можете ослабить это.

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

Нет, ты не зашел достаточно далеко.

1) Вы необходимость брандмауэр веб-приложений, например mod_security и убедитесь, что он настроен для блокирования атак, а не только для их регистрации.

2) Заблокируйте php с помощью phpsecinfo.

3) Заблокируйте учетную запись MySQL своего веб-приложения, убедитесь, что в вашем приложении нет FILE привилегии, безусловно, самый опасный в MySQL.

4) Брандмауэр отключил все UDP и все TCP, которые вам не нужны. Рассмотрите возможность использования стук порта для ssh. Отказ от бан не так хорош, как получение нуль попытки.

«Добро пожаловать на борт! На борту нашего нового авиалайнера вы можете насладиться рестораном, кинотеатром, тренажерным залом, сауной и бассейном. А теперь пристегните ремни безопасности, наш капитан попытается отправить все это дерьмо в воздух».

  1. mod_security - это боль как для вас, так и для сервера. Он требует ресурсов, а его правила требуют серьезной поддержки, и это будет бесконечной задачей. И нет, он не работает отдельно или с Nginx. Если вы чувствуете, что вам это действительно нужно, установите отдельный прокси-сервер (Apache, mod_proxy, mod_security). Он также работает как DMZ, ваши реальные серверы могут быть полностью закрыты для внешнего мира, и если прокси будет взломан, все равно ничего не будет.

  2. ClamAV тоже очень тяжелый, если запускать его как демон. Clamscan лучше запускать периодически в неактивные часы из Cron.

  3. Tripwire - это перебор, ИМХО. Но кое-что, способное выслеживать руткиты, было бы полезно, скриптов предостаточно (rkhunter, chkrootkit).

  4. Я считаю, что по крайней мере 90% руткитов и т. Д. Попадают на серверы через загрузку с Windows-машин разработчиков. Нет действительно хорошего способа предотвратить это, кроме, может быть, принуждения разработчиков никогда не использовать Windows. Большинство троянов ищут учетные данные FTP, поэтому никогда не используйте FTP.

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

Но кое-что, о чем не упоминают многие руководства по безопасности веб-серверов, - это то, что вы должны включить noexec в своем разделе / ​​tmp в / etc / fstab. Если вы предлагаете публичный хостинг, очень многие люди будут устанавливать небезопасные веб-приложения без вашего ведома (и сами не будут знать, чтобы поддерживать свои приложения в актуальном состоянии), и вы в основном преследуете эти ошибки навсегда. Если вы убедитесь, что единственное место, где злоумышленник может сохранить программное обеспечение, - это домашний каталог клиента и каталог / tmp, тогда злоумышленник рискует показать вам, где они взламывают, если он не может использовать каталог / tmp. Им это не нравится.

Это решило подавляющее большинство проблем с безопасностью на нашем сервере веб-хостинга.

Считается ли использование защиты формы капчи в популярном движке CMS (Wordpress, Jomlaa, Drupal) практикой безопасности? Если да, то вы можете использовать это: