Sécurité excessive du serveur Web?

J'ai fait des recherches "approfondies" sur la sécurisation d'un serveur Web Linux. En plus de ce qui est considéré comme les «bases» (suppression des services inutilisés, renforcement de ssh, iptables, etc.), est-il sage d'inclure des anti-rootkits (Tripwire) et un anti-virus (ClamAV)? Est-ce que c'est trop pour un serveur Web? Je sais que c'est une question très vague, mais je suis curieux de connaître les autres opinions.

Mon futur environnement: - ubuntu 10.04 - fail2ban - nginx 0.8.x - php 5.3.x (suhosin, apc, memcached) - mongodb 1.6.x

Applications possibles: - services Web - applications Web avec téléchargements d'utilisateurs (images, fichiers PDF, etc.) - sites Web typiques (formulaires, etc.)

Si vous avez d'autres conseils, n'hésitez pas à en ajouter!

Merci

Pour un serveur public, je dirais que l'installation de quelque chose comme tripwire n'est pas exagérée.

ClamAV est une autre affaire. J'envisagerais de le configurer pour que vos visiteurs partagent des fichiers en téléchargeant sur votre site Web et en téléchargeant à partir de celui-ci. Les fichiers PDF peuvent contenir des exploits.

Sur les serveurs publics, SSH n'autorise pas l'authentification par mot de passe, uniquement l'authentification par clé publique. Si SSH n'est possible qu'à partir d'un LAN interne, vous pouvez l'assouplir.

Dans la mesure du possible, je placerais le serveur sur une zone démilitarisée afin qu'il ne puisse pas établir de connexions vers d'autres ordinateurs sur vos réseaux locaux internes.

Non, tu n'es pas allé assez loin.

1) Vous avez besoin d' un pare-feu d'application Web comme mod_security et assurez-vous qu'il est configuré pour bloquer les attaques, pas seulement pour les enregistrer.

2) Verrouillez php avec phpsecinfo .

3) Verrouillez le compte MySQL de votre application Web, assurez-vous que votre application ne dispose pas de FILEprivilèges, c'est de loin le plus dangereux de MySQL.

4) Pare-feu sur tous les UDP et tous les TCP dont vous n'avez pas besoin. Pensez à utiliser le port knocking pour ssh. Échouer à interdire n'est pas aussi bon que zéro tentative.

Vous pouvez probablement installer AIDE en toute sécurité sur un serveur Web - l'ajout et la suppression de clients ne modifient pas trop de fichiers de configuration, et vous pouvez probablement filtrer le bavardage normal assez facilement.

Mais quelque chose que beaucoup de guides de sécurité du serveur Web ne mentionnent pas est que vous devez activer noexec sur votre partition / tmp dans / etc / fstab. Si vous offrez un hébergement au public, beaucoup de gens installeront des applications Web non sécurisées à votre insu (et n'auront pas les connaissances nécessaires pour maintenir leurs applications à jour), et vous poursuivez essentiellement ces bogues pour toujours. Si vous vous assurez que le seul endroit où un attaquant peut enregistrer un logiciel est le répertoire personnel du client et le répertoire / tmp, l'attaquant court le risque de vous montrer où il s'introduit s'il ne peut pas utiliser le répertoire / tmp. Ils n'aiment pas faire ça.

Cela a résolu la grande majorité des problèmes de sécurité sur notre serveur d'hébergement Web.

"Bienvenue à bord! À bord de notre nouvel avion de ligne, vous pourrez profiter du restaurant, du cinéma, de la salle de sport, du sauna et de la piscine. Maintenant, attachez vos ceintures de sécurité, notre capitaine va essayer de faire voler toute cette merde."

1. mod_security est une douleur à la fois pour vous et pour le serveur. Ses ressources sont gourmandes et ses règles doivent être sérieusement maintenues et ce sera une tâche sans fin. Et non, cela ne fonctionne pas de manière autonome ou avec Nginx. Si vous sentez que vous en avez vraiment besoin, configurez un serveur proxy distinct (Apache, mod_proxy, mod_security). Cela fonctionne également comme DMZ, vos vrais serveurs peuvent être complètement fermés au monde extérieur, et si le proxy est violé, il n'y a rien de toute façon.

2. ClamAV est également très lourd s'il est exécuté en tant que démon. Il est préférable d'exécuter clamscan périodiquement pendant les heures non actives à partir de Cron.

3. Tripwire est exagéré, à mon humble avis. Mais quelque chose capable de traquer les rootkits serait utile, il y a plein de scripts (rkhunter, chkrootkit).

4. Je crois qu'au moins 90% des rootkits, etc. arrivent sur les serveurs via des téléchargements à partir de machines Windows devs. Il n'y a pas vraiment de bon moyen d'empêcher cela, sauf peut-être forcer les développeurs à ne jamais utiliser Windows. La plupart des chevaux de Troie recherchent des informations d'identification FTP, alors n'utilisez jamais FTP.

L'utilisation de la protection des formulaires captcha dans les moteurs CMS populaires (Wordpress, Jomlaa, Drupal) est-elle considérée comme des pratiques de sécurité? Si oui, alors vous pouvez les utiliser:

• Mollom
• Aksimet
• Defensio