Puisque notre prévention est envisagée du point de vue de l’intrus, nous devons d’abord savoir comment l’intrus envahit. À l'heure actuelle, les méthodes d'intrusion Web les plus populaires consistent d'abord à obtenir le shell Web du site Web en recherchant les vulnérabilités du programme, puis à trouver les méthodes exploitables correspondantes pour élever les privilèges en fonction de la configuration du serveur, puis à obtenir les autorisations du serveur. Par conséquent, il s’agit d’une méthode efficace pour coopérer avec le serveur afin de mettre en place une prévention contre WebShell.
1. Empêcher le téléchargement illégal de la base de données
Il faut dire que les administrateurs disposant d'un peu de sécurité réseau modifieront le chemin de base de données par défaut des programmes de sites Web téléchargés depuis Internet. Bien sûr, certains administrateurs sont très négligents. Ils récupèrent le programme et l'installent directement sur leur propre serveur, sans même supprimer le fichier de description, et encore moins changer le chemin de la base de données. De cette façon, les pirates peuvent télécharger directement le programme source du site Web à partir du site de code source, puis le tester localement pour trouver la base de données par défaut, puis télécharger la base de données pour lire les informations utilisateur et les données qu'elle contient (généralement cryptées MD5) pour trouver la gestion. entrez et connectez-vous pour obtenir le webshell. Une autre situation est que le chemin d'accès à la base de données du site Web est exposé en raison d'une erreur de programme. Alors, comment éviter que cela ne se produise ? Nous pouvons ajouter le mappage étendu de mdb. Comme indiqué ci-dessous :
Ouvrez IIS et ajoutez un mappage MDB, afin que mdb puisse être analysé dans d'autres fichiers qui ne peuvent pas être téléchargés : "Propriétés IIS" - "Répertoire personnel" - "Configuration" - "Mappage" - "Extension d'application" et ajoutez le fichier .mdb pour appliquer l'analyse Vous pouvez choisir vous-même le fichier utilisé pour l'analyser, tant que le fichier de base de données est inaccessible.
Les avantages sont les suivants : 1. Les fichiers de base de données au format de suffixe mdb ne seront certainement pas téléchargés ; 2. Cela fonctionne pour tous les fichiers mdb du serveur, ce qui est très utile pour les administrateurs d'hôtes virtuels.
2. Empêcher le téléchargement
Pour la configuration ci-dessus, si vous utilisez une base de données MSSQL, tant qu'il existe un point d'injection, vous pouvez toujours utiliser l'outil d'injection pour deviner la base de données. S'il n'y a aucune authentification lors du téléchargement de fichiers, nous pouvons directement télécharger un cheval de Troie asp pour obtenir le webshell du serveur.
Concernant le téléchargement, nous pouvons le résumer comme suit : les répertoires qui peuvent être téléchargés ne reçoivent pas d'autorisations d'exécution, et les répertoires qui peuvent être exécutés ne reçoivent pas d'autorisations de téléchargement. Le programme Web est exécuté par l'utilisateur IIS. Il suffit de donner à l'utilisateur IIS l'autorisation d'écriture sur un répertoire de téléchargement spécifique, puis de supprimer l'autorisation d'exécution de script de ce répertoire pour empêcher les intrus d'obtenir le webshell via le téléchargement. Méthode de configuration : tout d'abord, dans le répertoire Web IIS, ouvrez l'onglet Autorisations et accordez uniquement aux utilisateurs IIS les autorisations de lecture et de liste des répertoires, puis entrez le répertoire dans lequel les fichiers téléchargés sont enregistrés et la base de données est stockée, ajoutez des autorisations d'écriture aux utilisateurs IIS, et enfin Remplacez simplement "Pure Script" par "Aucun" dans l'option "Propriétés" - "Autorisation d'exécution" de ces deux répertoires. Voir photo ci-dessous :
Un dernier rappel, lorsque vous définissez les autorisations ci-dessus, vous devez faire attention à la définition de l'héritage du répertoire parent. Évitez de vous installer en vain.
[Page coupée]
3.Injection MSSQL
Pour la défense de la base de données MSSQL, nous disons qu'il faut d'abord commencer par le compte de connexion à la base de données. N'utilisez pas le compte SA pour la base de données. Utiliser le compte SA pour se connecter à la base de données est un désastre pour le serveur. De manière générale, vous pouvez utiliser le compte d'autorisation DB_OWNER pour vous connecter à la base de données. Si elle peut fonctionner normalement, il est plus sûr d'utiliser l'utilisateur public. Après avoir défini l'autorisation dbo pour se connecter à la base de données, l'intrus ne peut obtenir le webshell qu'en devinant le nom d'utilisateur et le mot de passe ou une sauvegarde différentielle. Pour le premier, nous pouvons le défendre en cryptant et en modifiant l'adresse de connexion par défaut de l'arrière-plan de gestion. . Pour la sauvegarde différentielle, on sait que sa condition est d'avoir les autorisations de sauvegarde et de connaître le répertoire du web. La recherche de répertoires Web s'effectue généralement en parcourant le répertoire pour effectuer une recherche ou en lisant directement le registre. Chacune de ces deux méthodes utilise les deux procédures stockées étendues xp_regread et xp_dirtree. Il suffit de supprimer ces deux magasins étendus. Bien entendu, nous pouvons également supprimer les fichiers dll correspondants ensemble.
Mais si le répertoire Web est exposé en raison d’une erreur de programme, vous ne pouvez rien faire. Nous devons donc également réduire les autorisations du compte et ne pas pouvoir terminer l'opération de sauvegarde. Les opérations spécifiques sont les suivantes : Dans les propriétés de ce compte - options d'accès à la base de données, il vous suffit de sélectionner la base de données correspondante et de lui accorder les autorisations DBO. Ne pas exploiter d'autres bases de données. Accédez ensuite aux autorisations des propriétés de la base de données pour supprimer les autorisations de sauvegarde et de journal de sauvegarde de l'utilisateur, afin que les intrus ne puissent pas obtenir le webshell via une sauvegarde différentielle.
3.Injection MSSQL
Pour la défense de la base de données MSSQL, nous disons qu'il faut d'abord commencer par le compte de connexion à la base de données. N'utilisez pas le compte SA pour la base de données. Utiliser le compte SA pour se connecter à la base de données est un désastre pour le serveur. De manière générale, vous pouvez utiliser le compte d'autorisation DB_OWNER pour vous connecter à la base de données. Si elle peut fonctionner normalement, il est plus sûr d'utiliser l'utilisateur public. Après avoir défini l'autorisation dbo pour se connecter à la base de données, l'intrus ne peut obtenir le webshell qu'en devinant le nom d'utilisateur et le mot de passe ou une sauvegarde différentielle. Pour le premier, nous pouvons le défendre en cryptant et en modifiant l'adresse de connexion par défaut de l'arrière-plan de gestion. . Pour la sauvegarde différentielle, on sait que sa condition est d'avoir les autorisations de sauvegarde et de connaître le répertoire du web. La recherche de répertoires Web s'effectue généralement en parcourant le répertoire pour effectuer une recherche ou en lisant directement le registre. Chacune de ces deux méthodes utilise les deux procédures stockées étendues xp_regread et xp_dirtree. Il suffit de supprimer ces deux magasins étendus. Bien entendu, nous pouvons également supprimer les fichiers dll correspondants ensemble.
Mais si le répertoire Web est exposé en raison d’une erreur de programme, vous ne pouvez rien faire. Nous devons donc également réduire les autorisations du compte et ne pas pouvoir terminer l'opération de sauvegarde. Les opérations spécifiques sont les suivantes : Dans les propriétés de ce compte - options d'accès à la base de données, il vous suffit de sélectionner la base de données correspondante et de lui accorder les autorisations DBO. Ne pas exploiter d'autres bases de données. Accédez ensuite aux autorisations des propriétés de la base de données pour supprimer les autorisations de sauvegarde et de journal de sauvegarde de l'utilisateur, afin que les intrus ne puissent pas obtenir le webshell via une sauvegarde différentielle.
