Mon serveur est-il suffisamment sécurisé maintenant?

Ok, mon serveur a été piraté la semaine dernière. Le pirate a attaqué un éditeur tiers obsolète (en php) et a implanté un script de porte dérobée en PHP et a gravement endommagé mes sites. J’ai passé un week-end entier à nettoyer les scripts de porte dérobée et les codes malveillants qu’il avait laissés sur mon serveur. Et pour éviter d’être piraté à nouveau, j’ai fait ce qui suit sur mon serveur:

  1. Désactiver file_upload en PHP. Depuis que le piratage a téléchargé la porte dérobée via PHP, j’ai désactivé la fonction dans php.ini. Donc maintenant je ne peux que télécharger via ftp.

  2. désactiver create_function dans php. Aucun de mes logiciels n’utilise cette fonction. Le pirate a utilisé cette fonction de la même manière que eval () pour exécuter des commandes sous forme de chaînes.

  3. désactiver popen, exec, system, passthru, proc_open, shell_exec, show_source, phpinfo dans php.ini. Ces fonctions sont principalement utilisées par le script de porte dérobée pour modifier mes fichiers et répertoires.

  4. Installez suhosin. Trouvez les fonctions légales appelées dans eval (), placez-les dans suhosin.executor.eval.whitelist. Hacker a mis des codes malveillants dans mon programme et l’a obscurci avec base64_encode, puis les a exécutés dans eval (). Donc, je n’autorise que quelques fonctions légales appelées dans eval ().

  5. Activez suhosin.executor.disable_emodifier. Le pirate a mis un autre code obsolète dans mon programme et a utilisé le modificateur e_prêge_replace () pour exécuter les commandes php qu’il a mises sur son navigateur. Ainsi, il pourrait télécharger ou modifier des fichiers sur le serveur via son navigateur. (Depuis que j’ai désactivé file_upload, il ne pouvait plus télécharger, mais il pouvait toujours modifier et supprimer les fichiers comme il le souhaitait).

En désactivant la fonction create_function, le modificateur preg_replace () et la limitation eval (), même si des codes malveillants restnt non nettoyés sur mon serveur, le pirate ne peut rien faire. Ce sont les 3 fonctions les plus dangereuses de PHP.

  1. Ajoutez .htaccess à chaque dossier, à l’exception du répertoire racine, et interdisez à PHP d’être exécuté directement depuis le navigateur:

Ordre Refuser, Autoriser le refus de tous

Je mets un autre * après Php parce que j’ai trouvé un fichier de porte dérobée nommé missing.php.DISABLED et qui peut encore être exécuté si je ne mets pas * après php

  1. Définissez le répertoire racine (le seul endroit permettant d’exécuter .php) en lecture seule. Définissez tous les fichiers de ce dossier en lecture seule. Le pirate ne peut donc pas télécharger de nouveau script de porte dérobée dans le seul répertoire où le php peut être exécuté. Il ne pouvait pas non plus modifier les fichiers dans ce répertoire.

  2. Pour le login wordpress, j’ai ajouté

Ordre Refuser, Autoriser le refus de tous

autoriser de xxx.xxx.xxx.xxx

au .htaccess dans le répertoire racine, où xxx.xxx.xxx.xxx est mon adresse IP.

  1. Définissez tous les .htaccess en lecture seule.

Eh bien, c’est ce que je peux faire pour renforcer la sécurité de mon serveur. Ai-je manqué quelque chose?

Merci pour votre conseil.

À moins de réimager la machine à partir de supports d’installation connus, vous ne pouvez pas savoir qu’il n’ya pas de rootkit en attente.