Je viens de jeter un coup d’oeil pour la première fois aux logs de mon serveur qui tourne maintenant depuis 3 ans et ce que je vois m’effraie, je crois que j’aurais dû le faire bien avant !
En effet j’ai des milliers de tentatives de connexions par jour sur mon port SSH, principalement en provenance de Chine, qui tentent de se connecter en root mais qui essaient également tout un tas de logins plus ou moins courants.
Donc j’ai cherché une solution pour bloquer automatiquement les IP après X essais. Le paquet qui permet de faire ça s’appelle “fail2ban” et est très facilement configurable en 2 min. Voici un tuto concis et très bien fait si besoin :
C’est sûrement de l’archi connu pour bon nombre d’entre vous mais on ne se rend pas toujours compte à quel point les systèmes sont exposés à tous les pirates du monde entier et une piqûre de rappel ne peut pas faire de mal !
Je vous invite très fortement à surveiller régulièrement le fichier qui enregistre les tentatives de connexions sur vos systèmes :
Connu, efficace et très utilisé ici.
Si tu veux encore plus de sécurité, connexions SSH interdite sous root, bien sûr mais aussi interdite avec mot de passe.
Seulement autorisées avec jeu de clefs et passphrase.
là, tu n’as même plus à regarder les logs, seulement à vider de temps en temps pour faire de la place.
Déjà passphrase est lié à la liaison avec jeu de clefs.
Ensuite, une simple phrase de 5 mots est mille fois plus compliquée à craquer qu’un MDP de 30 signes.
Si tu veux, je te passe des liens qui t’en diront plus.
Ce n’est vrai que si ta passphrase est plus longue que ton mot de passe. Il n’y a aucune différence entre une phrase de 30 caractères et un mot de passe de 30 caractères pour un ordinateur. La force brute aura la même difficulté à le cracker (ou facilité, ça dépend comment on voit les choses ).
Ca c’est très intéressant et je veux bien des liens dont tu disposes sur ce sujet !
D’avance, merci.
Alors voici un lien
des plus intéressant concernant les passphrases et plus particulièrement ce “morceau choisi” :
[quote]« Mais on m’a toujours dit que des vrais mots Saymal™ ! », me hurlez-vous avec consternation, le sourcil vengeur.
Oui, sauf dans des jolies passphrases. Pourquoi donc ? Parce que le niveau de complexité augmente de façon plus qu’exponentielle au fil des caractères, en particulier quand on commence à découper en mots. En cryptographie, on considère qu’un mot de passe, ou une passphrase, peuvent appartenir à plusieurs niveaux de sécurité, qui correspondent à la difficulté qu’on rencontre pour les casser. La recherche sur le sujet abonde et se met à jour chaque année, notamment au sein de conférences spécialisées comme la célèbre DEFCON.
Je suis assez fan de cet excellent article de Thomas Baekdal, qui illustre bien le sujet. Imaginons une passphrase qu’il faudrait des centaines d’années, voire des millénaires, dans l’état actuel de la technologie la plus avancée, pour casser par un moyen technologique. On qualifie une telle passphrase de « sécurisée à vie » (secure for life). Eh bien, pour obtenir une telle passphrase, il suffit de combiner au moins 3 mots, pas nécessairement sans rapport, pour un total d’au moins une dizaine de caractères. Voici quelques exemples de telles passphrases :
this is fun (sérieux ! Il faudrait au moins 25 siècles…)
j’aime les noix de cajou (le système solaire aura déjà implosé d’ici qu’on casse ça…)
des filles à la vanille
san pellegrino enterre badoit
i love to boogie
tu fais du vb dommage eliane
entre git et svn j’ai choisi
plutot crever qu’installer vista[/quote]
Je ne garantie pas ce que l’auteur prétend, je ne fais que lire et rapporter. Article de sept. 2010, donc pas trop vieux.
la différence est de taille, le passphrase concerne la clé privée qui se trouve sur la machine client, le mot de passe celui sur le serveur ssh donc du user, à la rigueur, même sans passphrase, l’ authentification par clés sera toujours plus sécurisé qu’ avec mot de passe, dans la mesure que la clé privée chez le client n’ est pas usurpée (utilité du passphrase)
fai2ban bonne solution, j’ ai une méthode encore plus radicale: définir dans iptables une seule ip (voir 2 ou 3) autorisée à l’ accés au port ssh, (plus aucune tentative, ni rien dans les logs)
et j’ accéderais toujours puisque l’ ip en question est celle d’ un serveur vpn accessible depuis tous les endroits de la planète.
la différence est de taille, le passphrase concerne la clé privée qui se trouve sur la machine client, le mot de passe celui sur le serveur ssh donc du user, à la rigueur, même sans passphrase, l’ authentification par clés sera toujours plus sécurisé qu’ avec mot de passe, dans la mesure que la clé privée chez le client n’ est pas usurpée (utilité du passphrase)
fai2ban bonne solution, j’ ai une méthode encore plus radicale: définir dans iptables une seule ip (voir 2 ou 3) autorisée à l’ accés au port ssh, (plus aucune tentative, ni rien dans les logs)
et j’ accéderais toujours puisque l’ ip en question est celle d’ un serveur vpn accessible depuis tous les endroits de la planète.[/quote]
Dans le genre parano, j’ai un peu le même principe : SSH possible seulement en LAN, bloqué en WAN.
Et quand je suis en dehors de chez moi, me direz-vous ?
Un script qui m’ouvre la porte et la referme sitôt besoin assouvi
Merci Syam, le Roi des paranos
Tout ça a un défaut, dans mon logwatch journalier, je n’ai pratiquement plus rien à lire
Sinon si vous êtes encore ‘full IPV4’ knockd est un petit démon vous permettant de paramétrer une séquence afin de fermer un port ou de l’ouvrir.
Vous pouvez par exemple fermer un port sensible (ie : un port dédié à phpmyadmin, ssh, etc)
Je vous laisse fouiller le net une multitude de tutoriel et de FAQ explique différente façon de procéder selon les besoins.
Pour exemple, dès que j’installe un nouveau serveur je commence en générale par mettre ne place un knockd qui me permettra d’ouvrir les ports sur lesquels je travaille au besoin, tout le restant étant fermer.
Couplé à un ‘portsentry’ ce type d’astuce permet de facilement sécurisé (hors zéro day ou faille non corrigé) une machine le temps de finir sa sécurisation.
[quote=“ricardo”]Dans le genre parano, j’ai un peu le même principe : SSH possible seulement en LAN, bloqué en WAN.
Et quand je suis en dehors de chez moi, me direz-vous ?
Un script qui m’ouvre la porte et la referme sitôt besoin assouvi[/quote]
Et il se lance comment, ce script ? Port knocking ?
Je connais bien ce principe mais ça ne change rien du tout face à une attaque en force brute si le nombre de caractères est le même. Il y aura toujours le même nombre de combinaisons à tester. Il y a X combinaisons maximales et qu’on y mette des lettres, des mots, des chiffres ou n’importe quels caractères, la force brute ne fera aucune différence et testera toutes les combinaisons possibles.
C’est juste qu’une passphrase permet de retenir plus facilement un mot de passe long et de le modifier bien plus simplement. Mais fondamentalement, si on ne tient pas compte de l’association qu’il est fait d’une passphrase avec une clé privée, ce n’est rien d’autre qu’un long mot de passe.
Ce que tu évoques n’est vrai que dans le cas d’attaques par dictionnaires car dans ce cas le dictionnaire à utiliser est beaucoup plus gros et donc ça prend beaucoup plus de temps.
De ce que je comprends la passphrase n’est techniquement qu’un mot de passe très long et facile à retenir. Mais elle n’est en aucun cas mathématiquement dépendante de la clé privée. Elle sert à la protéger, mais qu’on utilise des mots ou des caractères classiques, ça revient toujours à avoir un mot de passe de 30 caractères pour protéger une clé privée.
Donc en définitive, une passphrase est moins sécurisée qu’un mot de passe à nombre de caractères égal car il sera toujours plus facile d’attaquer avec un gros dictionnaire qu’avec une force brute pour un nombre de caractères donné.
Je ne sais pas qui a écrit ça mais c’est assez stupide. Ce qui prenait plusieurs millions d’années à cracker il y a 30 ans ne prend plus que quelques secondes aujourd’hui. Et 30 ans à l’échelle d’une vie c’est assez court, donc dire qu’un mot de passe est sécurisé à vie ce n’est vrai que si l’on considère que la technologie reste figée et que les puissances de calculs n’évoluent plus, ce qui n’est bien évidemment pas le cas. D’ailleurs la puissance de calcul évolue exponentiellement, c’est pour ça qu’on considère qu’à partir du moment où on a réussit à cracker une fois un algorithme de chiffrement en un temps raisonnable en force brute, on le considère comme obsolète car s’il a été possible de le faire aujourd’hui il sera exponentiellement plus facile de le faire demain.
La sécurité d’un algorithme de chiffrement ne tient qu’au temps qu’on considère que les données doivent rester protégées, car un jour ou l’autre il devient possible de casser le chiffrement.
Le seul algorithme de chiffrement qui fasse exception est le “one-time pad”, le chiffrement par clé aléatoire unique. Le principe est simple : pour chaque caractère que l’on souhaite transmettre, on le chiffre à l’aide d’un autre caractère que l’on choisit aléatoirement, qui ne répond à aucun algorithme, qui ne repose sur aucune logique préétablie. Et si demain on veut retransmettre le même message, on rechiffre le message de la même façon : pour chaque caractère, on le chiffre avec un caractère aléatoire.
Ainsi le message chiffré ne repose sur aucun algorithme mathématique en tant que tel. Le seul moyen de le déchiffrer est d’avoir l’intégralité de la clé unique, qui est donc aussi longue que le message à transmettre.
Problème : comment envoyer la clé unique au destinataire de façon sécurisée ? Car si vous trouvez un moyen 100% sûr de transmettre cette clé sans qu’on l’intercepte, alors autant transmettre directement les données en clair sur ce canal de communication…
Il faut donc échanger au préalable des clé uniques aléatoires qui ne serviront qu’une seule fois pour les chiffrements/déchiffrements, et localement, pas via des canaux de communications pour éviter toute interception des clés au moment de l’échange.
Vient alors le problème du stockage : comment être sûr que mes très chères clés ne seront pas volées en attendant d’être utilisées ?
Le chiffrement à clé aléatoire unique est le seul moyen mathématiquement sûr à 100% d’empêcher tout déchiffrement par un tiers, car le déchiffrement ne repose pas sur un calcul mais sur une information. Si vous n’avez pas l’information, vous n’avez strictement aucun moyen de la retrouver car elle n’est pas générée par un calcul, elle ne découle pas d’une logique, d’où la notion d’aléa qui est fondamentale. Et elle doit être unique pour éviter de pouvoir déduire la clé au fur et à mesure que l’on voit passer les messages chiffrés (le crackage du WEP repose sur ce principe).
[quote=“PascalHambourg”][quote=“ricardo”]Dans le genre parano, j’ai un peu le même principe : SSH possible seulement en LAN, bloqué en WAN.
Et quand je suis en dehors de chez moi, me direz-vous ?
Un script qui m’ouvre la porte et la referme sitôt besoin assouvi[/quote]
Et il se lance comment, ce script ? Port knocking ?[/quote]
Je sens une certaine ironie dans ta question, me trompe-je ?
En gros, car je ne me souviens plus bien de ce que j’ai fait donc schématiquement :
création d’une nouvelle chaine iptables "machin"
ouvrir SSH sur le WAN, script 1 :
iptables -F machin
iptables -A machin -j ACCEPT
restart parefeu
ouvrir SSH sur le LAN, script 2 :
idem dessus sauf
iptables -A machin -s IP locale/24 -j ACCEPT
Salut,
J’utilise un truc simple pour protéger mon ssh:
SSS n’est pas sur le port 22
Portsentry écoute sur le port 22
La moindre tentative ou le moindre scan et l’IP est blacklistée…
Fail2ban surveille le port ssh, mais finalement il ne sert à rien, pas une tentative (faudrait connaitre le port…) en deux ans…
Par contre sur Postfix, sasl et le ftp c’est la grande orgie des tentatives…
Ça je ne sais pas faire justement mais j’avoue que je ne suis pas concerné souvent, étant presque toujours à la maison.
Donc, quand je m’absente (2 ou 3 fois/an pendant 4 à 5 jours maxi), “j’ouvre” le WAN (on pourrait dire la vanne) avant de partir, pour avoir une possibilité d’intervention en SSH sur mon serveur. Toutefois, je reste quand même protégé par :
–fail2ban qui est TRÈS restrictif (une seule tentative et durée de ban très longue),
–interdiction de connexion sous root
–interdiction de connexion avec MDP
Seule connexion possible via jeu de clefs, avec passphrase, dont la privée est sur mon portable.
[quote=“lol”]…
Par contre sur Postfix, sasl et le ftp c’est la grande orgie des tentatives… [/quote] Sftp avec les précautions citées dans le précédent message, plus aucune tentative car systématiquement vouées à l’échec.
).
