Pour mon serveur perso, afin d’augmenter la sécurité j’utilise Fail2ban, pour ceux qui ne connaissent pas, il scan différents fichiers de logs (ssh, apache, …) et au bon de X tentatives de connexion foirées pour la même IP, il ban cette IP avec iptables pour 10 minutes.
Ça marche très bien et tous les jours j’ai entre 1 et 3 bans. Mais je me dis et si un jour un mec arrive quand même à passer, je n’en serais rien et je me demande si il n’existe pas un logiciel du même type (scan de log) qui me préviendrai en cas d’utilisation douteuse comme une connexion SSH autorisée depuis une IP chinoise par exemple. Ou un système qui m’envoie par mail tous les jours/semaines des statistiques d’utilisation, les logs bash pour checker que rien ne se passe d’anormale.
Bref, quels solutions avez-vous mis en place pour vos serveurs afin d’éviter que les Jean Kevin d’Orlando (3 essais hier à 10h, 13h et 15h) viennent squatter chez vous.
_Interdiction du log root direct (faut passer par un user standard pour passer en root via su)
_Des vrais mot de passe, aussi bien pour les (TOUS) users que pour le root
_fail2ban réglé sur 2 ou 3h voir 24h histoire de faire en sorte qu’ils aillent voir ailleurs
et d’une manière générale:
_faire les mises a jour régulièrement de tout le système (s’inscrire sur la ML sécurité de la distrib ou sur le RSS est une bonne idée)
_Interdire les connexion a des ports non utilisés.
_Est ce que les autres services sont indispensables? (typiquement si t’as mis apache, est ce que tu t’en sers vraiment?)
Franchement, si t’as bien coché toutes les cases (et que tu recoches toutes ces cases toutes les semaines), bah tu risques pas grand chose et quand bien même quelqu’un serait rentré malgré tout, ben t’aurais rien pu faire: il serait rentré no matter what.
Après tu peux partir dans la parano et mettre en place un IDS mais pfff… c’est très très difficile a configurer pour éviter d’avoir des faux positifs, je préfère me concentrer sur la secu de base qui marche dans 95% des cas: monter a 96-97% prendra beaucoup de temps pour très peu de gain.
Bouge pas
Alors perso :
Logging avec clef pgp obligatoire.
Fail 2 ban aussi
Ensuite mise ajour reguliere des serveurs.
Surveillance des sites de sécurités sur les failles connues. http://korben.info/nsa-doc-linux-securisation.html la doc nsa pour securiser un serveur.
Y compris également pour les bases de données; mysql et autres sont bien trop souvent négligés de ce point de vue (non, root c’est pas un mdp valable pour l’utilisateur root).
Pour mon serveur perso hébergé derrière une Freebox, j’utilise le port 440 qui redirige vers le port 22, ça évite les scans bêtes et méchants. Le serveur me prévient des mises à jour en attente grâce à apticron, ça évite d’oublier les mises à jour ou de se connecter quand il n’y a pas de mise à jour à faire. Je reçois un rapport quotidien des connexions, de l’espace disque et d’autres trucs (c’est paramétrable) grâce à logwatch. fail2ban est installé, par contre au début il ne filtrait pas, je n’avais pas touché à la configuration car je pensais qu’il surveillait d’office les accès SSH …
Tiens question d’ailleurs, je devie un peu le thread pour une question rapidos, je me fais un peu ddos a la maison, sur la freebox, et ca nuit carrement a mon ping, obligé de reboot la box tout les soirs. Une idée de comment resoudre ca ?
chez free l’adresse est definitive, c’est con tu changais et tu etais peinard
la freeboite est pas top niveau secu, tu peux dejà désactivé la reponse au ping dans ton interface de gestion, option de base, mais qui te mets a l’abri des script kiddyes qui scannent au petit bonheur la chance.
Apres la meilleure option ,est peut être de foutre la freeboite en bridge et d’utiliser un routeur qui possédent des options plus péchues, voire unp tit serv.
entre nous, c’est quand même pasd e bol de faire parti des 0.000009% de particuliers qui se font ddoser
Virer la réponse au ping est une bonne idée (cf wack), arrêter les soft de P2P 30min avant d’avoir besoin d’un bon ping aide aussi, emule étant assez con quand la connexion se coupe: il continue de faire des tentatives de connexion sur l’ip meme quand le soft est arrêté.
Ouais alors pour moi ca, c’est la fausse bonne idée.
_Ca crée un faux sentiment de sécurité (bonjour a tous les gens que j’ai croisé qui m’ont dit « ouais, j’ai mis ssh sur un autre port, pas besoin de mettre un gros mot de passe, c’est pratique »)
_Ca ne regle en rien les ports scan, bien au contraire: Si le pseudo pirate voit 22 et 80 ouvert, il va tenter des trucs dessus et se faire bouler assez vite par fail2ban. Il a vu 22 bien présent et live (et qui vient de lui faire un doigt), donc il y a de grande chance qu’il fasse pas son reloud avec un full scan de tous les ports de la machine. Et surtout, on montre au pirate qu’on se cache pas et qu’on sait configurer un serveur « state of the art »
Alors que si vous mettez ssh sur un port a la con (genre 2222, ce que font 98% des gens… sic) (le mettre sur 440 est clairement une erreur a mon sens, car les 1024 premiers port sont à usage réservé, mais bon), le port 22 est fermé, ce qui veut dire qu’il n’y a pas de serveur ssh ou qu’il est mis ailleurs: d’ou le full scan qui va suivre.
Bref. Port 22, fail2ban a 2-24h, connexion en root direct interdite et full mot de passe bien costaud (Note: changer de mot de passe régulièrement est une erreur: vaut mieux en avoir un costaud des le départ et eventuellement le changer tous les ans ou 2 ans)
Perso changer ses ports avec une bonne sécurité derriere, j’ai un fail2ban.
Mais je suis pour changer les ports par defaut parce que ca evite les logiciels et les scripts kidies.
Apres voila c’est aussi mon autre point de vue, parce que quand tu dl un soft les options les plus simples c’est scan sur les ports par defauts.
Je persiste pour dire que c’est un mauvais calcul.
Bussiere, je t’invite a lire ça: Security through obscurity - Wikipedia et notamment la partie que tout admin reseau devrait utiliser tous les jours:
LoneWolf
System security should not depend on the secrecy of the implementation or its components.
Je dit juste que voila des que tu commences a script kiddie, tout les softs et toutes les librairies utilisent le port par défaut.
Changer le port demande un tout petit de boulot que tres peu fournissent.
Tu rajoutes derriere un fail2ban et voila bretelle ceinture.
Changer les ports par défauts dans des scripts ou des logiciels de script kiddie demande un tout petit peu de boulot.
Or ce sont des momes et des amateurs, ils ne le feront pas.
Le type qui déja tente un log et essaie les autres ports tu peux monitorer son ip et le gerter.
Juste que voila a peine je met un serveur sur le net dans les 20 minutes qui suivent j’ai un rush d’attaque dessus.
Et changer les ports perso me met un peu a l’abris.
Voila
Surtout que je bosse dans un domaine ou on se dit ils n’oseront jamais porter plainte, ou aussi les gens se croient permis de nous attaquer comme ca.
Sinon vous desactivez l’auth par password et vous utilisez des certificats : un peu galere a mettre en place quand on se connecte de pleins d’endroits differents mais ya pas plus secure
Attention, le ban de plus de 10 minutes m’a déjà pourri quand c’est moi qui m’étais trompé. Attention à la surenchère.
Sinon, ban direct sur tentative avec root/admin/sa/administrator…
Le certificat/keypair, c’est génial quand il faut créer 10/100 ou plus de comptes, pas de mot de passe à initialiser. Par contre c’est une vrai gestion à côté (CA / CRL)
Très interessant vos retours d’expérience, par commaudité j’accepte l’authentification par mot de passe au cas où je devrais accèder à mon serveur depuis un PC autre que les miens, comme c’est de l’Ubuntu, pas d’accès root direct et le mot de passe de mon user est assez costaud, ca devrait suffir.
Faut que je regarde si l’on peux bannir différement en fonction de l’utilisateur, genre ban direct 24h en cas de tentative de connexion avec root.
[quote=“LoneWolf, post:12, topic: 54246”]Je persiste pour dire que c’est un mauvais calcul.
Bussiere, je t’invite a lire ça: http://en.wikipedia…rough_obscurity[/quote]Je suis revenu sur le port 22 par curiosité, je me fais attaquer comme jamais, depuis une petite dizaine d’IPs qui ont essayé de se connecter au compte root. Ton lien est intéressant sauf que pour moi changer de port c’est pas une question de sécurité, ça m’évite juste les connexions des bots.
Pour la connexion par certificat, je connaissais pas et je viens de mettre ça en place en local. Votre clé est protégée par un mot de passe (passphrase) ? Et du coup il faut quand même rentrer un mot de passe ? Quel est l’intérêt dans ce cas ? Parce que si je ne rentre pas de mot de passe, je peux être connecté automatiquement au serveur, mais n’importe quelle personne ayant un accès physique à mon ordinateur pourrait aussi le faire. Autant chez moi ça ne poserait pas de problème, autant ça serait gênant si je laissais ma session au boulot ouverte par inadvertance.
