Безопасность веб-сервера

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

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

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

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

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

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

2) Блокировка php с помощью phpsecinfo.

3)Lock down your web application's MySQL account, make sure your application doesn't have FILE privileges, its by far the most dangerous one in MySQL.

4)Firewall off all UDP, and all TCP that you don't need. Consider using port knocking for ssh. Fail to ban isn't nearly as good as getting zero attempts.

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

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

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

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

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

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

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

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

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

• Mollom
• Aksimet
• Defensio