Quelles mesures prenez-vous pour sécuriser un serveur Debian?
J'installe un serveur Debian qui est connecté directement à Internet. Évidemment, je veux le rendre aussi sûr que possible. J'aimerais que vous les gars/filles ajoutiez vos idées pour le sécuriser et quels programmes vous utilisez pour cela.
Je veux qu'une partie de cette question couvre ce que vous utilisez comme pare-feu? Juste iptables configuré manuellement ou utilisez-vous une sorte de logiciel pour vous aider? Quelle est la meilleure façon? Tout bloquer et autoriser uniquement ce qui est nécessaire? Existe-t-il peut-être de bons tutoriels pour les débutants sur ce sujet?
Modifiez-vous votre port SSH? Utilisez-vous des logiciels comme Fail2Ban pour empêcher les attaques par bruteforce?
Obligatoire:
- installation du système en mode expert, uniquement les packages dont j'ai besoin
- pare-feu écrit à la main avec une politique par défaut sur l'entrée iptables: supprimer, autoriser l'accès à SSH, HTTP ou tout autre serveur donné en cours d'exécution
- Fail2Ban pour SSH [et parfois FTP/HTTP/autre - selon le contexte]
- désactiver les connexions root, forcer l'utilisation d'un utilisateur normal et de Sudo
- noyau personnalisé [juste une vieille habitude]
- mise à niveau programmée du système
En fonction du niveau de paranoïa en plus:
- supprimer la politique de sortie, sauf quelques destinations/ports autorisés
integritpour vérifier si certaines parties du système de fichiers ne sont pas modifiées [avec une somme de contrôle conservée en dehors de la machine], par exemple Tripwire- analyse planifiée au moins avec nmap du système de l'extérieur
- vérification automatisée des journaux pour les modèles inconnus [mais c'est principalement pour détecter un dysfonctionnement matériel ou quelques plantages mineurs]
- exécution planifiée de chkrootkit
- attribut immuable pour
/etc/passwdil est donc un peu plus difficile d'ajouter de nouveaux utilisateurs - / tmp monté avec noexec
- heurtoir de port ou autre moyen non standard d'ouvrir les ports SSH [par ex. la visite de la page Web "secrète" sur le serveur Web permet une connexion SSH entrante pendant une période limitée à partir d'une adresse IP qui a consulté la page. Si vous vous connectez,
-m state --satete ESTABLISHEDprend soin d'autoriser le flux de paquets tant que vous utilisez une seule session SSH]
Des choses que je ne fais pas moi-même mais qui ont du sens:
- grsecurity pour le noyau
- syslog distant pour que les journaux ne puissent pas être écrasés lorsque le système est compromis
- alerte sur les connexions SSH
- configurez rkhunter et configurez-le pour qu'il s'exécute de temps en temps
Juste une note sur le pare-feu de votre machine ...
- Utilisez une liste blanche, pas une liste noire - c'est-à-dire tout bloquer, et n'autorisez que ce dont vous avez besoin, refusez tout le reste.
- N'utilisez pas d'interfaces graphiques/ncurses ou tout autre logiciel qui tente de vous écrire votre pare-feu. Si vous le faites, vous autoriserez le logiciel à faire des hypothèses pour vous - vous n'avez pas besoin de prendre ce risque et vous ne devriez pas. Configurez-le vous-même, si vous n'êtes pas sûr, désactivez-le - vous découvrirez assez tôt s'il est nécessaire. S'il s'agit déjà d'un système opérationnel et que vous ne pouvez pas perturber le trafic (en le bloquant accidentellement), exécutez tcpdump (vidage dans un fichier) et prenez des échantillons - étudiez-les plus tard, puis déterminez ce qui est valide et ce qui ne l'est pas.
- Personnellement, je ne vois aucun intérêt à exécuter un service sur un port non standard, les outils ne sont pas si stupides ces jours-ci pour supposer que parce que quelque chose fonctionne sur le port 22 par exemple, il doit être ssh, et pas autrement - pour exemple
amapetnmap's-Aoption. Cela dit, vous pouvez (et probablement le cas échéant) modifier vos services pour vous cacher des regards indiscrets, par exemple, ce qui suit permettrait à l'attaquant de connaître la version exacte deOpenSSHque vous exécutez, ils peut alors rechercher des exploits pour cette version exacte. Si vous cachez de telles choses, vous leur rendriez la tâche plus difficile.
[root @ ud-olis-1 uhtbin] # telnet localhost 22 Essayer 127.0.0.1 ... Connecté à localhost.localdomain (127.0.0.1). Le caractère d'échappement est '^]'. SSH-2.0-OpenSSH_3.9p1
- Gardez tous vos services publics à jour et corrigés avec les derniers correctifs de sécurité.
- Ne stockez pas de DONNÉES sur le serveur de passerelle lui-même, au moins vous gagnerez du temps lorsqu'ils parviendront à pénétrer dans cette machine, et vous perdrez un ou deux services, et un peu de temps, mais pas de données.
En bout de ligne, vous ne réussirez jamais à sécuriser quoi que ce soit à 100% - ce n'est tout simplement pas possible - donc l'objectif est de le rendre aussi sécurisé que possible - si c'est juste trop d'efforts pour casser votre système, c'est assez bon, et la plupart des lamer les script-kiddies passeront au système suivant.
iptablesest la voie à suivre pour tout système Linux - mais configurez-le vous-même.
N'utilisez jamais de "logiciels de sécurité" qui ne sont pas basés sur des normes ouvertes - ils sont voués à être mal écrits et seront piratés (pas une question de "si", mais de "quand"). L'open source et les protocoles ouverts sont ouverts à l'examen du public et convergent pour devenir un produit mature et fiable; Les logiciels à source fermée reposent principalement sur la confiance en soi des auteurs quant à la qualité/sécurité d'un produit ils le pensent - c'est-à-dire un petit nombre d'yeux contre une terre pleine d'yeux.
J'espère que cela pourra aider :)
- désactiver la connexion root
- désactiver la connexion par mot de passe (autoriser uniquement la connexion par clé publique)
- changer le port SSH
utiliser denyhosts (ou similaire)
écrivez votre propre script iptbles (afin que vous contrôliez exactement ce qu'il faut autoriser et que vous puissiez supprimer tout le reste)
forcer l'utilisation de communications sécurisées SSL/TLS et s'assurer d'avoir des certificats valides, non expirés et signés
- activer la vérification stricte des certificats pour tous les services externes (par exemple lors de l'authentification des utilisateurs avec un serveur LDAP sur une autre machine)
Commencer ici:
Comme point de départ général, je suis le référentiel/guides du Center for Internet Security , qui sont des compilations complètes des meilleures pratiques de sécurité. Il ne semble pas que leur benchmark Debian ait été mis à jour depuis un certain temps, mais un aperçu général des étapes est le suivant:
- Appliquer les derniers correctifs/packages du système d'exploitation
- Activez la comptabilité système/noyau/processus.
- Activez MAC (par exemple, SELinux ou AppArmor).
- Activez le pare-feu basé sur l'hôte (iptables).
- Vérifiez APT sources.list (les clés sont correctes, les sources sont fiables).
- Minimisez les services réseau, désactivez tout ce qui n'est pas nécessaire et pare-feu.
- Utilisez TCPWrappers pour restreindre davantage l'accès au système.
- Utilisez uniquement des protocoles réseau cryptés, désactivez les services non cryptés (telnet, ftp, etc.).
- Configurez l'accès à distance à SSH uniquement.
- Désactivez les mots de passe de connexion utilisateur et exigez une authentification par clé.
- Désactivez le partage de système de fichiers (NFS, SMB).
- Activez la journalisation du système à distance/centralisée (et consultez régulièrement les journaux!).
- Définissez un mot de passe au niveau du BIOS/firmware.
- Définissez un mot de passe du chargeur de démarrage.
- Configurez les sauvegardes du système, disposez d'un plan de reprise après sinistre et TESTEZ que les sauvegardes sont valides et que le personnel connaît les procédures de reprise après sinistre!
Il existe de nombreuses ressources sur tous ces différents paramètres, y compris les commandes spécifiques et les fichiers de configuration à implémenter sur le système dans les benchmarks CISecurity.
Je suggérerais de ne pas connecter une machine directement à Internet. Placez une sorte de pare-feu entre la machine et Internet. Cela vous permet de faire de la sécurité et de la surveillance du réseau sans mettre plus de charge sur le serveur. Personnellement, je trouve que la segmentation du réseau et des fonctions simplifie fréquemment le dépannage du réseau, bien qu'à l'occasion, la complexité supplémentaire rend l'analyse plus difficile.
La politique de pare-feu la plus sûre, mais la plus ennuyeuse à gérer, consiste à tout refuser et à autoriser explicitement uniquement le trafic que vous devez autoriser. C'est ennuyeux, car il faut fréquemment mettre à jour la politique de pare-feu à mesure que le réseau change.
Je suggère également d'utiliser une sorte de pare-feu d'interface sur le serveur - la défense en profondeur est la clé. L'utilisation de ports non standard pour les services liés à l'administration ne fait pas de mal. fail2ban est très bien. Poursuivez les questions plus spécifiques sur les applications de sécurité sur Serverfault pour trouver plus d'idées.
La sécurité est comme la blague sur les deux randonneurs et l'ours - même si l'on ne peut jamais atteindre une sécurité parfaite, il est utile d'être une cible plus difficile que les autres gars.
Certaines personnes ont pointé le Securing Debian Manual . Cela devrait convenir parfaitement à tout sauf aux besoins militaires.
Beaucoup de gens pensent qu'être ridiculement paranoïaque est cool ou professionnel ou quelque chose. Ce n'est pas , c'est juste ennuyeux pour les autres administrateurs et carrément répressif pour vos utilisateurs. La plupart des choses que vous verrez recommandées ne sont que de faux travaux pour se sentir utiles pour l'administrateur paranoïaque, mais pas réellement utiles, car la véritable violation de la sécurité est susceptible d'être causée par un système pas suffisamment mis à jour et/ou par une source interne.
Cela dit, je considère comme l'un de mes principes de ne faire confiance à rien sur le réseau local, pas plus qu'à Internet. Par conséquent, je configure tout pour exiger une authentification même sur le réseau local. Je crypte et authentifie tout le trafic entre chacun des ordinateurs utilisant IPsec.
Je suis en train de passer au chiffrement complet du disque pour tous mes serveurs.
J'installe uniquement les services que j'utilise. Je n'ai pas de pare-feu; Je configure les services dont j'ai besoin pour exiger une authentification ou les limite (par la propre configuration du programme ou par des wrappers TCP) à certaines IP. La seule chose que j'ai jamais eu besoin de bloquer en utilisant iptables était memcached, car il n'avait pas de fichier de configuration et n'utilisait pas de wrappers TCP.
J'utilise de bons mots de passe générés aléatoirement pour mes comptes et je fais confiance à mon serveur SSH (et à tous les autres services) pour empêcher l'accès à ceux qui ne connaissent pas le mot de passe. fail2ban est uniquement pour ceux qui ont un espace limité pour les fichiers journaux, IMO. (Vous devez avoir suffisamment de mots de passe pour pouvoir leur faire confiance.)
Parcourez ce guide pratique de Nice sur www.debian.org/doc/manuals/securing-debian-howto/
Personnellement, je change le port ssh et j'utilise fail2ban + denyhosts. Et je bloque tout ce qui n'est pas nécessaire. Plus vous bloquez, moins vous devez vous inquiéter.