Je pense que les règles que tu proposes sont un bon début pour sécuriser la production. Avec un peu de chance, ça devrait suffire pour écarter bon nombre de script-kiddies en bouchant la(les) faille(s) qui a(ont) fait que ton serveur s'est retrouvé compromis.
Cependant, tu pourrais travailler sur un autre axe - l'analyse post mortem. J'en parle ici car je suis à la recherche d'idées ou de "bonnes manières" sur le sujet.
En ce moment, je réfléchis à une petite infrastructure pour externaliser un maximum d'informations décrivant le fonctionnement d'un serveur, dans le but de faire une analyse post-attaque. Globalement, cela consiste à :
-Envoyer une copie des logs sur un autre serveur avec les tentatives d'auth sur le ssh, le ftp, etc... (syslog en réseau)
-Activer le process accounting (paquet acct sous Debian et dérivés) qui donne beaucoup d'informations sur ce qui se passe et répliquer ces informations en dehors du serveur
-...
En sachant ce qui s'est passé pour que le serveur tombe, on peut en apprendre beaucoup sur l'attaque, et donc boucher les trous plus efficacement. Par contre, à part les deux sources d'infos que j'ai cité, je manque d'idées. Vous en avez d'autres ?
Au passage, changer le port par défaut de ssh est une TRES bonne idée si votre serveur est en public sur internet. La preuve : en 1 an, j'ai eu environ 1.500.000(!) tentatives de connection sur ssh, avec des login / pass très variés, la plupart du temps des bots qui déroulaient des listes. Depuis que ssh n'écoute plus sur le port 22 mais sur un port à 5 chiffres, je n'ai plus aucune tentative.
(Bon évidemment si on peut faire de l'authentif par clé, c'est mieux, mais vos clients n'aimeront peut-être pas toujours...)
# Investigation ?
Posté par leoboy . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
Je pense que les règles que tu proposes sont un bon début pour sécuriser la production. Avec un peu de chance, ça devrait suffire pour écarter bon nombre de script-kiddies en bouchant la(les) faille(s) qui a(ont) fait que ton serveur s'est retrouvé compromis.
Cependant, tu pourrais travailler sur un autre axe - l'analyse post mortem. J'en parle ici car je suis à la recherche d'idées ou de "bonnes manières" sur le sujet.
En ce moment, je réfléchis à une petite infrastructure pour externaliser un maximum d'informations décrivant le fonctionnement d'un serveur, dans le but de faire une analyse post-attaque. Globalement, cela consiste à :
-Envoyer une copie des logs sur un autre serveur avec les tentatives d'auth sur le ssh, le ftp, etc... (syslog en réseau)
-Activer le process accounting (paquet acct sous Debian et dérivés) qui donne beaucoup d'informations sur ce qui se passe et répliquer ces informations en dehors du serveur
-...
En sachant ce qui s'est passé pour que le serveur tombe, on peut en apprendre beaucoup sur l'attaque, et donc boucher les trous plus efficacement. Par contre, à part les deux sources d'infos que j'ai cité, je manque d'idées. Vous en avez d'autres ?
Au passage, changer le port par défaut de ssh est une TRES bonne idée si votre serveur est en public sur internet. La preuve : en 1 an, j'ai eu environ 1.500.000(!) tentatives de connection sur ssh, avec des login / pass très variés, la plupart du temps des bots qui déroulaient des listes. Depuis que ssh n'écoute plus sur le port 22 mais sur un port à 5 chiffres, je n'ai plus aucune tentative.
(Bon évidemment si on peut faire de l'authentif par clé, c'est mieux, mais vos clients n'aimeront peut-être pas toujours...)