Comment auditer le trafic réseau sur un serveur LAMP avec sysdig sur CentOS 7

introduction

sysdig est un tout nouvel outil d’exploration et de dépannage au niveau système qui combine les avantages d’utilitaires bien connus tels que strace, tcpdump et lsof en une seule application. Et comme si cela ne suffisait pas, sysdig fournit également les fonctionnalités permettant d’enregistrer l’activité du système pour tracer les fichiers en vue d’une analyse ultérieure.

En outre, une riche bibliothèque de scripts (appelée chisels) est fournie avec l’installation afin de vous aider à résoudre les problèmes courants ou à répondre aux besoins en matière de surveillance, de l’affichage des opérations d’E / S sur disque défaillantes à la recherche des fichiers où un processus donné a passé le plus le temps et tout le reste. Vous pouvez également écrire vos propres scripts pour améliorer encore plus sysdig en fonction de vos besoins.

Dans cet article, nous allons d’abord présenter l’utilisation de base de sysdig, puis explorer l’analyse de réseau avec sysdig, y compris un exemple d’audit du trafic réseau sur un serveur CentOS 7 LAMP. Veuillez noter que le système VPS utilisé dans les exemples n’a pas été soumis à une charge importante, mais il suffit pour montrer les bases des tâches d’audit actuelles.

Conditions préalables

Avant de commencer, veuillez vous assurer que vous avez ces conditions préalables.

CentOS 7 Droplet
Configurez un serveur LAMP sur votre CentOS 7 VPS. Veuillez consulter his article pour les instructions.
De plus, vous devriez avoir un compte utilisateur non root avec sudo. accès qui sera utilisé pour exécuter sysdig

Installer sysdig

Connectez-vous à votre serveur et suivez ces étapes:

Étape 1 - Faites confiance à la clé Draios GPG

Draios est la firme derrière sysdig.

Avant de procéder à l’installation proprement dite, yum utilisera cette clé pour vérifier l’authenticité du package que vous êtes sur le point de télécharger.

Pour ajouter manuellement la clé Draios à votre trousseau de clés RPM, utilisez l’outil + rpm + avec l’indicateur + - import +:

sudo rpm --import https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public

Ensuite, téléchargez le référentiel Draios et configurez yum pour l’utiliser:

sudo curl -s -o /etc/yum.repos.d/draios.repo http://download.draios.com/stable/rpm/draios.repo

Étape 2 - Activer le référentiel EPEL

EPEL (Extra Packages for Enterprise Linux) est un référentiel de logiciels gratuits et à code source ouvert de haute qualité gérés par le projet Fedora. Il est compatible à 100% avec ses dérivés, tels que Red Hat Enterprise Linux et CentOS. Ce référentiel est nécessaire pour télécharger le package DKMS (Dynamic Kernel Module Support), requis par sysdig, et pour télécharger d’autres dépendances.

sudo yum -y install epel-release

Étape 3 - Installer les en-têtes du noyau

Cela est nécessaire car sysdig devra créer un module de noyau personnalisé (nommé + sysdig-probe +) et l’utiliser pour fonctionner.

sudo yum -y install kernel-devel-$(uname -r)

Étape 4 - Installez le paquet sysdig

Maintenant nous pouvons installer sysdig.

sudo yum -y install sysdig

Étape 5 - Exécuter sysdig en tant qu’utilisateur non root

Pour des raisons de sécurité, il est préférable de faire appel à un utilisateur non root pour exécuter sysdig. Créez un groupe personnalisé pour sysdig:

sudo groupadd sysdig

Ajoutez un ou plusieurs utilisateurs au groupe. Dans notre exemple, nous ajouterons l’utilisateur * sammy *.

sudo usermod -aG sysdig

Localisez le fichier binaire pour sysdig:

which sysdig

Vous pourriez recevoir une réponse comme

Donner à tous les membres du groupe * sysdig * les privilèges nécessaires pour exécuter le fichier exécutable + sysdig + (et ce binaire uniquement). Éditez + / etc / sudoers + avec:

sudo visudo

Ajoutez les lignes suivantes pour le groupe * sysdig * dans la section des groupes. L’ajout de nouvelles lignes après la section +% wheel + convient. Remplacez le chemin par l’emplacement de sysdig sur votre système:

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

## sysdig
%sysdig ALL=

Si vous avez besoin de précisions sur la modification du fichier + / etc / sudoers +, il est recommandé de consulter https://www.digitalocean.com/community/tutorials/how-to-add-and-delete- utilisateurs-sur-centos-7-serveur [cet article].

Exécuter sysdig

Vous pouvez exécuter sysdig de deux manières.

Vous pouvez afficher en direct le flux d’activité du serveur en temps réel ou vous pouvez enregistrer des enregistrements des opérations du système dans un fichier pour une analyse ultérieure hors ligne.

Comme vous voudrez probablement utiliser la deuxième option, c’est ce que nous aborderons ici. Notez que lors de l’enregistrement de l’activité du système dans un fichier, sysdig prend un instantané complet du système d’exploitation, de sorte que tout ce qui se passe sur votre serveur pendant cet intervalle de temps soit disponible pour une analyse hors ligne.

_ * Remarque: * Lorsque vous exécutez les commandes sysdig, assurez-vous que chaque option est précédée d’un seul tiret. Le copier-coller peut causer un problème lorsqu’un tiret unique est collé en tant que tiret long et n’est donc pas reconnu par le programme. _

Exécutons une commande sysdig de base pour capturer 1 000 lignes d’activité du serveur.

Pour capturer l’activité du système dans un fichier nommé + act1.scap + et limiter la sortie à 1 000 événements, exécutez la commande suivante (omettez la partie + -n 1000 + si vous souhaitez exécuter sysdig pendant une période non spécifiée. ). Le commutateur + -z + permet d’activer la compression du fichier de trace.

sudo sysdig -w act1.scap.gz -n 1000 -z

_ * Remarque: * Si vous avez omis le commutateur à la dernière étape, vous pouvez interrompre l’exécution de sysdig en appuyant sur la combinaison de touches CTRL + C. _

Chisels - Présentation des scripts sysdig

Chisels sont des scripts sysdig. Pour afficher une liste des burins disponibles, nous devons exécuter la commande suivante:

sudo sysdig -cl

Pour auditer le trafic réseau sur notre serveur CentOS 7 LAMP à l’aide du fichier de trace créé par sysdig, nous utiliserons les burins disponibles dans la catégorie Net:

Category: Net
-------------
iobytes_net         Show total network I/O bytes
spy_ip              Show the data exchanged with the given IP address
spy_port            Show the data exchanged using the given IP port number
topconns            top network connections by total bytes
topports_server     Top TCP/UDP server ports by R+W bytes
topprocs_net        Top processes by network I/O

Une description plus détaillée d’un burin spécifique, ainsi que des instructions pour son utilisation, peut être consultée avec:

sudo sysdig -i

Par exemple:

sudo sysdig -i spy_ip

Cela génère:

Category: Net
-------------
spy_ip              Show the data exchanged with the given IP address
shows the network payloads exchanged with an IP endpoint. You can combine this chisel with the -x, -X or -A sysdig command line switches to customize the screen output
Args:
[ipv4] host_ip - the remote host IP address
[string] disable_color - Set to 'disable_colors' if you want to disable color output

La section + Args + indique si vous devez ou non passer un argument au ciseau. Dans le cas de + spy_ip +, vous devez transmettre une adresse IP en tant qu’argument au ciseau.

Audit du trafic réseau (exemple pratique)

Passons en exemple pratique sur l’utilisation de sysdig pour analyser l’utilisation de la bande passante et afficher des informations détaillées sur le trafic réseau.

Pour obtenir les meilleurs résultats de ce test, vous devez configurer un formulaire Web factice sur votre serveur afin de générer le trafic approprié. S’il s’agit d’un serveur avec une nouvelle installation de LAMP, vous pouvez créer ce formulaire à partir de + / var / www / html / index.php +.

<body>
<form id="loginForm" name="loginForm" method="post" action="login.php">
 <table width="300" border="0" align="center" cellpadding="2" cellspacing="0">
   <tr>
     <td width="112"><b>Username:</b></td>
     <td width="188"><input name="login" type="text" class="textfield" id="login" /></td>
   </tr>
   <tr>
     <td><b>Password:</b></td>
     <td><input name="pass" type="password" class="textfield" id="pass" /></td>
   </tr>
   <tr>
     <td>&nbsp;</td>
     <td><br />
     <input type="submit" name="Submit" value="Login" /></td></tr>
 </table>
</form>
</body>

Ce n’est pas nécessaire, mais pour tout arranger, vous pouvez aussi créer la page + / var / www / html / login.php +:

<body>
   <p>Form submitted.</p>
</body>

_ * Attention: * Veuillez supprimer ce formulaire lorsque vous avez terminé les tests! _

Étape 1 - Enregistrement de données en direct pour une analyse hors ligne

Nous allons commencer à capturer notre collecte de journaux de données en émettant la commande suivante:

sudo sysdig -w act1.scap.gz -z -s 4096

Laissez sysdig en marche pendant un laps de temps raisonnable. Votre invite de commande se bloquera pendant l’exécution de sysdig.

À présent, visitez le domaine ou l’adresse IP de votre serveur dans votre navigateur Web. Vous pouvez visiter des pages existantes et non existantes pour générer du trafic. Si vous souhaitez que cet exemple spécifique fonctionne, vous devez visiter la page d’accueil, compléter les informations de connexion avec tout ce que vous voulez et * soumettre le formulaire de connexion plusieurs fois *. De plus, n’hésitez pas à lancer des requêtes sur votre base de données MySQL / MariaDB.

Une fois que vous avez généré du trafic, appuyez sur CTRL + C pour arrêter sysdig. Ensuite, vous serez prêt à exécuter les requêtes d’analyse dont nous parlerons plus loin dans ce tutoriel.

Dans un environnement de production, vous pouvez démarrer la collecte de données sysdig pendant une période occupée sur votre serveur.

Comprendre les filtres: classes et champs

Avant de commencer à trier les données sysdig, expliquons quelques éléments de base de la commande sysdig.

Sysdig fournit des classes et des champs en tant que filtres. Vous pouvez considérer les classes comme des objets et les champs comme des propriétés, selon une analogie basée sur la théorie de la programmation orientée objet.

Vous pouvez afficher la liste complète des classes et des champs avec:

sudo sysdig -l

Nous allons utiliser des classes et des champs pour filtrer la sortie lors de l’analyse d’un fichier de trace.

Étape 2 - Effectuer une analyse hors ligne à l’aide de fichiers de trace

Puisque nous voulons auditer le trafic réseau depuis et vers notre serveur LAMP, nous allons charger le fichier de trace + act1.scap.gz + et effectuer les tests suivants avec sysdig:

Affichage de la liste des principaux processus utilisant la bande passante réseau

sudo sysdig -r act1.scap.gz -c topprocs_net

Vous devriez voir la sortie un peu comme ceci:

Bytes     Process
------------------------------
331.68KB  httpd
24.14KB   sshd
4.48KB    mysqld

Vous pouvez voir ici qu’Apache utilise la plus grande bande passante (le processus + httpd +).

Sur la base de cette sortie, vous pouvez émettre un avis motivé et éclairé pour décider si vous devez augmenter votre bande passante disponible afin de répondre à vos demandes estimées actuelles et futures. Sinon, vous pouvez imposer des restrictions appropriées sur le débit maximal de bande passante déjà disponible pouvant être utilisé par un processus.

Affichage de l’utilisation du réseau par processus

Nous voudrons peut-être aussi savoir quelles adresses IP utilisent la bande passante réseau consommée par + httpd +, comme indiqué dans l’exemple précédent.

Pour cela, nous utiliserons le ciseau + topconns + (qui indique le nombre total de connexions réseau) et ajouterons un filtre formé avec la classe + proc + et le champ + nom + pour filtrer les résultats uniquement http + `connexions. En d’autres termes, la commande suivante:

sudo sysdig -r act1.scap.gz -c topconns proc.name=httpd

Cela renverra les connexions réseau supérieures sur votre serveur, y compris la source, où le processus servant la demande est + httpd +.

Bytes     Proto     Conn
------------------------------
56.24KB   tcp       111.111.111.111:12574->your_server_ip:80
51.94KB   tcp       111.111.111.111:15249->your_server_ip:80
51.57KB   tcp       111.111.111.111:27832->your_server_ip:80
51.26KB   tcp       111.111.222.222:42487->your_server_ip:80
48.20KB   tcp       111.111.222.222:42483->your_server_ip:80
48.20KB   tcp       111.111.222.222:42493->your_server_ip:80
4.17KB    tcp       111.111.111.111:13879->your_server_ip:80
3.14KB    tcp       111.111.111.111:27873->your_server_ip:80
3.06KB    tcp       111.111.222.222:42484->your_server_ip:80
3.06KB    tcp       111.111.222.222:42494->your_server_ip:80

Notez que les adresses IP d’origine et de destination d’origine ont été masquées pour des raisons de confidentialité.

Ce type de requête peut vous aider à trouver les utilisateurs avec la bande passante maximale qui envoient du trafic sur votre serveur.

Après avoir examiné le résultat ci-dessus, vous pensez peut-être que les nombres situés après les adresses IP source représentent les ports. Cependant, ce n’est pas le cas. Ces chiffres indiquent les numéros d’événements enregistrés par sysdig.

Étape 3 - Analyse des données échangées entre une adresse IP spécifique et Apache

Nous allons maintenant examiner plus en détail les connexions entre une adresse IP spécifique et Apache.

Le ciseau + echo_fds + nous permet d’afficher les données lues et écrites par les processus. Combiné à un nom de processus spécifique et à une adresse IP client (tel que + proc.name = httpd et fd.cip = 111.111.111.111 + dans ce cas), ce ciseau affiche les données échangées entre notre serveur LAMP et cette adresse IP du client.

De plus, l’utilisation des commutateurs suivants nous permet d’afficher les résultats de manière plus conviviale et précise:

+ -s 4096 +: Pour chaque événement, lisez jusqu’à 4096 octets dans son tampon (cet indicateur peut également être utilisé pour spécifier le nombre d’octets de chaque tampon de données à enregistrer sur le disque lors de l’enregistrement de données en direct dans un fichier de trace analyse hors ligne)
+ -A +: N’affiche que la partie texte des tampons de données et indique l’écho en fin de ligne (nous voulons uniquement afficher les données lisibles par l’homme)

Voici la commande. Assurez-vous de remplacer ++ par une adresse IP du client de la sortie précédente.

sudo sysdig -r act1.scap.gz -s 4096 -A -c echo_fds fd.cip= and proc.name=httpd

Vous devriez voir un peu de sortie, en fonction du nombre de connexions établies par cette adresse IP. Voici un exemple montrant une erreur 404:

GET /hi HTTP/1.1
Host: your_server_ip
Connection: keep-alive
Cache-Control: m

------ Write 426B to :39003->your_server_ip:80

HTTP/1.1 404 Not Found
Date: Tue, 02 Dec 2014 19:38:16 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
Content-Length: 200
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /hi was not found on this server.</p>
</body></html>

Ce type de requête peut vous aider à déterminer exactement quels types de connexions ont été établies par une adresse IP utilisant la bande passante maximale. Par exemple, si vous constatez que l’adresse IP atteint une certaine page très fréquemment, vous pouvez réduire au maximum les ressources de cette page afin de réduire l’utilisation de la bande passante. Ou, si le trafic ne semble pas être légitime, vous pouvez créer une nouvelle règle firewall pour bloquer le monopole sur la bande passante. IPs.

Étape 4 - Examen des données échangées avec une adresse IP par mot clé

En fonction de l’activité du serveur au cours de l’intervalle de capture, le fichier de trace peut contenir de nombreux événements et informations. Ainsi, parcourir les résultats de la commande dans la section précédente à la main peut prendre un temps peu pratique. Pour cette raison, nous pouvons rechercher des mots spécifiques dans les tampons d’événements.

Supposons qu’un ensemble d’applications Web s’exécute sur notre serveur Web et que nous souhaitons nous assurer que les informations d’identification de connexion ne sont pas transmises sous forme de texte brut par le biais de formulaires.

Ajoutons quelques indicateurs à la commande utilisée dans l’exemple précédent:

sudo sysdig -r act1.scap.gz -A -c echo_fds fd.ip= and proc.name=httpd and evt.is_io_read=true and evt.buffer contains

Ici, la classe + evt +, ainsi que le champ + is_io_read +, nous permettent d’examiner uniquement les événements lus (du point de vue du serveur). De plus, + evt.buffer + nous permet de rechercher un mot spécifique dans le tampon d’événements (le mot est '++ `dans ce cas). Vous pouvez remplacer le mot clé de recherche par un mot clé pour vos propres applications.

La sortie suivante montre qu’un nom d’utilisateur et un mot de passe sont transmis du client au serveur en texte brut (devenant ainsi lisibles par toute personne possédant une expertise suffisante):

------ Read 551B from :41135->your_server_ip:80

POST /login.php HTTP/1.1
Host: your_server_ip
Connection: keep-alive
Content-Length: 35
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://104.236.40.111
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.122 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://104.236.40.111/
Accept-Encoding: gzip,deflate
Accept-Language: en-US,en;q=0.8

login=&pass=&Submit=Login

Si vous trouvez un trou de sécurité similaire, prévenez immédiatement votre équipe de développeurs.

Conclusion

Ce que vous pouvez accomplir avec sysdig dans l’audit du trafic réseau sur un serveur LAMP est principalement limité par l’imagination et les demandes d’application. Nous avons vu comment rechercher les utilisateurs les plus performants en bande passante, examiner le trafic provenant d’adresses IP spécifiques et trier les connexions par mot-clé en fonction des demandes de vos applications.

Si vous avez d’autres questions sur le présent article ou souhaitez des suggestions sur la manière de travailler avec sysdig dans votre environnement LAMP actuel, n’hésitez pas à envoyer vos commentaires à l’aide du formulaire ci-dessous.

TOC