Sécuriser un serveur Web Linux pour un accès public
https://stackoverflow.com/questions/5078
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'aimerais configurer une machine Linux bon marché en tant que serveur Web pour héberger une variété de technologies Web (PHP et Java EE me viennent à l'esprit, mais j'aimerais également expérimenter Ruby ou Python à l'avenir).
Je suis assez habitué à configurer Tomcat pour qu'il fonctionne sous Linux afin de servir des applications Java EE, mais j'aimerais pouvoir ouvrir ce serveur, ne serait-ce que pour pouvoir créer des outils que je peux utiliser pendant que je travaille. le bureau.Toute l'expérience que j'ai eue dans la configuration de sites Java EE concerne des applications intranet pour lesquelles on nous a dit de ne pas nous concentrer sur la sécurisation des pages pour les utilisateurs externes.
Quel conseil donnez-vous pour configurer un serveur Web Linux personnel de manière suffisamment sécurisée pour l'ouvrir au trafic externe ?
La solution
Cet article présente certaines des meilleures façons de verrouiller les choses :
http://www.petefreitag.com/item/505.cfm
Quelques faits marquants :
- Assurez-vous que personne ne peut parcourir les répertoires
- Assurez-vous que seul root a des privilèges d'écriture sur tout et que seul root a des privilèges de lecture sur certains fichiers de configuration.
- Exécutez mod_security
L'article reprend également quelques indications de ce livre :
Sécurité Apache (O'Reilly Press)
En ce qui concerne les distributions, j'ai utilisé Debain et Ubuntu, mais cela dépend simplement de ce que vous voulez faire.J'ai exécuté Debian sans X et je me suis connecté à chaque fois que j'avais besoin de quelque chose.C'est un moyen simple de réduire les frais généraux.Ou Ubuntu a de jolies fonctionnalités d'interface graphique qui facilitent le contrôle d'Apache/MySQL/PHP.
Autres conseils
Il est important de suivre les meilleures pratiques de sécurité dans la mesure du possible, mais vous ne voulez pas vous rendre les choses trop difficiles ou perdre le sommeil en vous souciant de suivre les derniers exploits.D'après mon expérience, il y a deux éléments clés qui peuvent vous aider à maintenir votre serveur personnel suffisamment sécurisé pour vomir sur Internet tout en préservant votre santé mentale :
1) La sécurité par l’obscurité
Inutile de dire que s'appuyer sur cela dans le « monde réel » est une mauvaise idée et ne doit pas être diverti.Mais c'est parce que dans le monde réel, les méchants savent ce qu'il y a là-bas et qu'il y a du butin à gagner.
Sur un serveur personnel, la majorité des « attaques » dont vous serez victime seront simplement des balayages automatisés de machines déjà compromises, à la recherche d'installations par défaut de produits connus pour être vulnérables.Si votre serveur ne propose rien d'attrayant sur les ports par défaut ou dans les emplacements par défaut, l'attaquant automatisé passera à autre chose.Par conséquent, si vous envisagez d'exécuter un serveur ssh, placez-le sur un port non standard (> 1024) et il est probable qu'il ne sera jamais trouvé.Si vous pouvez vous en sortir avec cette technique pour votre serveur Web, alors super, déplacez-le également vers un port obscur.
2) Gestion des colis
Ne compilez pas et n'installez pas Apache ou sshd à partir des sources vous-même, sauf si vous y êtes absolument obligé.Si vous le faites, vous assumez la responsabilité de vous tenir à jour avec les derniers correctifs de sécurité.Laissez les bons responsables de paquets des distributions Linux telles que Debian ou Ubuntu faire le travail à votre place.Installez à partir des packages précompilés de la distribution, et rester à jour devient une question de publication occasionnelle apt-get update && apt-get -u dist-upgrade commande, ou en utilisant n’importe quel outil graphique sophistiqué fourni par Ubuntu.
Une chose à laquelle vous devez vous assurer est de savoir quels ports sont ouverts sur le monde.Personnellement, je viens d'ouvrir le port 22 pour SSH et le port 123 pour ntpd.Mais si vous ouvrez le port 80 (http) ou FTP, assurez-vous d'apprendre au moins à savoir ce que vous servez au monde et qui peut faire quoi avec cela.Je ne connais pas grand-chose au FTP, mais il existe des millions d'excellents didacticiels Apache à portée de recherche sur Google.
@svrist a mentionné EC2.EC2 fournit une API pour ouvrir et fermer les ports à distance.De cette façon, vous pouvez faire fonctionner votre box.Si vous avez besoin de faire une démonstration depuis un café ou le bureau d'un client, vous pouvez récupérer votre adresse IP et l'ajouter à l'ACL.
C'est sûr et sécurisé si vous gardez la voix basse à ce sujet (c'est-à-dire que quelqu'un s'en prendra rarement à votre serveur domestique si vous hébergez simplement une racine Web glorifiée sur une connexion domestique) et si vous restez vigilant à propos de votre configuration (c'est-à-dire, évitez d'utiliser root pour tout, assurez-vous de maintenir votre logiciel à jour).
Sur cette note, même si ce fil risque de devenir simplement flamboyant, ma suggestion pour votre serveur personnel est de s'en tenir à tout ce qui est Ubuntu (obtenez le serveur Ubuntu ici);D'après mon expérience, c'est le moyen le plus rapide d'obtenir des réponses, d'où poser des questions sur les forums (je ne sais pas quoi dire sur l'adoption).
La sécurité de mon serveur domestique BTW profite en quelque sorte (je pense, ou j'aime penser) de ne pas avoir d'adresse IP statique (fonctionne sur DynDNS).
Bonne chance!
/mp
Soyez prudent lorsque vous ouvrez le port SSH à l'état sauvage.Si vous le faites, assurez-vous de désactiver les connexions root (vous pouvez toujours su ou sudo une fois entré) et envisagez des méthodes d'authentification plus agressives dans des limites raisonnables.Un week-end, j'ai vu une énorme attaque par dictionnaire dans les journaux de mon serveur s'en prendre à mon serveur SSH à partir d'un serveur IP domestique DynDNS.
Cela étant dit, c'est vraiment génial de pouvoir rentrer chez soi depuis le travail ou en déplacement...et en ajoutant le fait que vous pouvez utiliser SFTP sur le même port, je ne pourrais pas imaginer la vie sans lui.=)
Vous pourriez envisager un Instance EC2 d'Amazon.De cette façon, vous pouvez facilement tester des « trucs » sans vous soucier de la production.Et ne payez que pour l'espace, le temps et la bande passante que vous utilisez.
Si vous exécutez un serveur Linux depuis chez vous, installez ossec dessus pour un joli IDS léger qui fonctionne très bien.
[MODIFIER]
En remarque, assurez-vous de ne pas enfreindre la politique d'utilisation acceptable de votre FAI. et qu'ils autorisent les connexions entrantes sur les ports standards.Le FAI pour lequel je travaillais avait écrit dans ses conditions que vous pouviez être déconnecté pour exécuter des serveurs sur le port 80/25, à moins que vous n'ayez un compte de classe affaires.Bien que nous n'ayons pas activement bloqué ces ports (nous ne nous en soucions pas, sauf si cela posait un problème), certains FAI n'autorisent aucun trafic sur le port 80 ou 25, vous devrez donc utiliser des ports alternatifs.
Si vous comptez faire cela, dépensez un peu d'argent et achetez au moins un routeur/pare-feu dédié avec un port DMZ séparé.Vous souhaiterez protéger votre réseau interne depuis votre serveur afin que lorsque (pas si !) votre serveur Web est compromis, votre réseau interne ne soit pas également immédiatement vulnérable.
Il existe de nombreuses façons de procéder qui fonctionneront très bien.J'utiliserais généralement un fichier .htaccess.Rapide à mettre en place et sécurisé assez .Ce n'est probablement pas la meilleure option, mais cela fonctionne pour moi.Je ne mettrais pas mes numéros de carte de crédit derrière, mais à part ça, je m'en fiche vraiment.
Wow, vous ouvrez une boîte de Pandore dès que vous commencez à ouvrir quoi que ce soit au trafic externe.Gardez à l’esprit que ce que vous considérez comme un serveur expérimental, presque comme un agneau sacrificiel, est également un choix facile pour les personnes cherchant à faire de mauvaises choses avec votre réseau et vos ressources.
L'ensemble de votre approche concernant un serveur disponible en externe doit être très conservatrice et approfondie.Cela commence par des choses simples comme les politiques de pare-feu, inclut le système d'exploitation sous-jacent (en le gardant patché, en le configurant pour la sécurité, etc.) et implique chaque couche de chaque pile que vous utiliserez.Il n’y a pas de réponse ou de recette simple, j’en ai peur.
Si vous souhaitez expérimenter, vous feriez bien mieux de garder le serveur privé et d'utiliser un VPN si vous devez travailler dessus à distance.
