OSQUERY est un outil open source développé par Facebook pour interroger diverses informations liées à l'état de vos machines, telles que les processus en cours d'exécution, les modules Kernel chargés, les utilisateurs connectés actifs, les ports d'écoute actifs, etc. Ce cadre d'instrumentation système rend le système d'exploitation de bas niveau analytique et un monitoring à la fois efficace et intuitif. OSQUERY expose un système d'exploitation en tant que base de données relationnelle virtuelle hautes performances qui vous permet d'écrire des requêtes SQL pour explorer les données du système d'exploitation et interroger les terminaux (Windows, OS X, Linux et FreeBSD) pour identifier, sonder et éliminer divers types de menaces. . OSQUERY est différent du HIDS/IPS traditionnel. Ici, vous devez savoir quelles données se trouvent dans la table pour les requêtes de requête et de conception basées sur ces données. En outre, il dispose d'une fonctionnalité intégrée pour surveiller l'intégrité des fichiers, auditer les connexions et les processus réseau, et même enregistrer les changements de périphériques matériels en temps réel. Dans cet article, nous allons installer OSQUERY dans Ubuntu 16 et vérifier ses utilisations via osqueryi et osqueryd.
1. Installer OSQUERY
Ajoutez les informations du référentiel OSQUERY à la base de données apt et mettez à jour le système.
# sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1484120AC4E9F8A1A577AEEE97A80C63C9D8B80BPour utiliser add-apt-repository, vous devez installer les propriétés du logiciel python.
# sudo apt-get install software-properties-common python-software-propertiesAjouter les données du référentiel à apt-database
# sudo add-apt-repository "deb [arch=amd64] https://osquery-packages.s3.amazonaws.com/xenial xenial main"Mettez à jour le système et installez OSQUERY
# sudo apt-get update
# sudo apt-get install osqueryVous pouvez exécuter OSQUERY via le shell interactif ou en mode démon. Dans un premier temps, explorons comment l'utiliser via l'interface shell OSQUERY et ensuite nous vérifierons le mode démon. Pour obtenir le shell osquery, tapez osqueryi dans le terminal pour interroger les tables osquery disponibles par défaut.
# osqueryi
osquery>Pour répertorier tous les utilisateurs connectés au système, exécutez la requête suivante.
osquery> select * from logged_in_users ;Trouvez toutes les tables disponibles pour la requête.
osquery> .tablesPour décrire le schéma d'une table, exécutez la commande suivante.
osquery> .schema table-nameSortir du shell
osquery> .exitVous pouvez également exécuter OSQUERY en passant des indicateurs de ligne de commande. par exemple
# osqueryi --disable_events=false --worker_threads=2 --logger_plugin=filesystem --pidfile=/var/osquery/osquery.pidfilePour en savoir plus sur les indicateurs de ligne de commande disponibles pour le shell interactif OSQUERY, exécutez la commande suivante à partir du terminal.
# osqueryi --helpNous explorerons plus de requêtes dans une section distincte, mais configurons maintenant OSQUERY.
2. Configurer OSQUERY
Il est plus facile d'exécuter OSQUERY avec un fichier de configuration. Plutôt que de transmettre de nombreux paramètres de ligne de commande pour exécuter le shell interactif osquery, ces paramètres peuvent être écrits dans le fichier de configuration osquery. Le shell interactif OSQUERY (osqueryi) lira ces paramètres lorsque vous exécuterez osqueryi. OSQUERY n'est pas livré avec un fichier de configuration. Il existe plutôt un exemple de fichier de configuration ( /usr/share/osquery/osquery.example.conf ) que vous pouvez copier. Il recherche le fichier de configuration dans /etc/osquery/osquery.conf . Si le fichier de configuration n'est pas présent, osqueryi s'exécutera avec les options par défaut. De plus, le fichier de configuration est disponible pour le démon OSQUERY.
Le fichier de configuration OSQUERY contient les trois sections suivantes.
→ Une liste d'options et de paramètres lus par osqueryi et le démon osquery ( osqueryd )
→ Query Schedule :l'ensemble des requêtes SQL et des intervalles.
→ Une liste de packs contenant des requêtes plus spécifiques/ciblées. par exemple, le pack de surveillance des modifications de fichiers :catégories et chemins des fichiers et répertoires surveillés
2.1 Options et paramètres
La liste complète des options et des paramètres se trouve dans ce wiki. Les options et les paramètres qui seront utilisés pour cet article sont décrits ci-dessous.
config_plugin : Nom du plug-in de configuration. Le type de récupération de configuration, le plug-in de système de fichiers par défaut lit un JSON de configuration à partir du disque.
logger_plugin : Nom du plug-in de l'enregistreur. L'enregistreur par défaut est le système de fichiers. Cela écrit les différents types de journaux au format JSON dans des chemins de fichiers spécifiques. Plusieurs plugins de journalisation peuvent être utilisés simultanément, copiant efficacement les journaux sur chaque interface. Séparez les noms des plugins par une virgule lors de la spécification de la configuration (--logger_plugin=filesystem,syslog).
logger_path : Chemin d'accès au répertoire pour ERROR/WARN/INFO et la journalisation des résultats.
disable_logging : Désactivez ERROR/WARNING/INFO (appelés journaux d'état) et la journalisation des résultats de requête.
schedule_splay_percent : Pourcentage pour étaler les temps de configuration. La planification des requêtes comprend souvent plusieurs requêtes avec le même intervalle. L'auteur de la planification n'a souvent pas l'intention d'exécuter ces requêtes ensemble à cet intervalle. Mais plutôt, chaque requête doit s'exécuter à peu près à l'intervalle. Un affichage de planification par défaut de 10 % est appliqué à chaque requête lors du chargement de la configuration.
pidfile : Chemin d'accès au mutex du démon pidfile. Le fichier est utilisé pour empêcher le démarrage de plusieurs processus osqueryd.
events_expiry : Délai d'expiration des résultats de publication d'abonnement d'événements à partir du magasin de sauvegarde. Cette expiration n'est appliquée que lorsque les résultats sont interrogés. Par exemple, si --events_expiry=1 alors les événements n'existeront pratiquement que pour une seule sélection de l'abonné. Si aucune sélection ne se produit, les événements seront enregistrés indéfiniment dans le magasin de sauvegarde.
database_path : Si vous utilisez un magasin de sauvegarde sur disque, spécifiez un chemin. osquery conservera l'état en utilisant un "magasin de sauvegarde" utilisant RocksDB par défaut. Cet état contient des informations d'événement telles qu'elles peuvent être interrogées ultérieurement selon un calendrier. Il contient les résultats de la requête la plus récente pour chaque requête de la planification. Ce dernier résultat interrogé permet la journalisation différentielle des requêtes.
verbeux : Activer les messages informatifs détaillés.
worker_threads : Nombre de threads de répartition du travail utilisés pour traiter les requêtes.
enable_monitor : Utilisé pour activer ou désactiver le moniteur de planification.
disable_events : Désactivez les API de publication d'abonnement du système d'exploitation osquery. Cela désactivera implicitement plusieurs tableaux qui rapportent en fonction des événements enregistrés.
disable_audit : Utilisé pour désactiver la réception d'événements du sous-système d'audit du système d'exploitation.
audit_allow_config : Autoriser l'éditeur d'audit à modifier la configuration d'audit
identifiant_hôte : Champ utilisé pour identifier l'hôte exécutant osquery :nom d'hôte, uuid, éphémère, instance.
enable_syslog : Activez l'éditeur d'événements d'ingestion Syslog. Il s'agit d'une activation "explicite" car elle nécessite une configuration externe de rsyslog ou syslog-ng.
audit_allow_sockets : Cela permet à l'éditeur d'audit d'installer des règles liées aux sockets.
schedule_default_interval : Définissez éventuellement la valeur d'intervalle par défaut. Ceci est utilisé si vous planifiez une requête qui ne définit pas d'intervalle.
# sudo vi /etc/osquery/osquery.conf
"options": {
"config_plugin": "filesystem",
"logger_plugin": "filesystem",
"logger_path": "/var/log/osquery",
"disable_logging": "false",
"log_result_events": "true",
"schedule_splay_percent": "10",
"pidfile": "/var/osquery/osquery.pidfile",
"events_expiry": "3600",
"database_path": "/var/osquery/osquery.db",
"verbose": "false",
"worker_threads": "2",
"enable_monitor": "true",
"disable_events": "false",
"disable_audit": "false",
"audit_allow_config": "true",
"host_identifier": "hostname",
"enable_syslog": "true",
"audit_allow_sockets": "true",
"schedule_default_interval": "3600"
},
...........
...........
...........2.2 Calendrier des requêtes
La section de planification contient des requêtes identifiées par une clé unique suivie de l'intervalle qui spécifie la fréquence des requêtes en secondes. La configuration de la section de planification que nous utiliserons ressemble à ci-dessous-
...........
...........
{
"schedule": {
"crontab": {
"query": "SELECT * FROM crontab;",
"interval": 300
},
"largest_process": {
"query": "select pid, name, uid, resident_size from processes order by resident_size desc limit 10;",
"interval": 60
},
}
...........
...........La première requête regarde la table crontab toutes les 300 secondes et la deuxième requête renifle les extensions de noyau chargées toutes les 10 secondes. Les résultats de la requête sont mis en cache sur le disque à l'aide de RocksDB. Lors de la première exécution de la requête, tous les résultats sont stockés dans RocksDB. Lors des exécutions suivantes, seules les différences d'ensemble de résultats (modifications) sont enregistrées dans RocksDB.
D'autres requêtes spéciales appelées décorateurs sont utilisées pour ajouter des données à d'autres requêtes planifiées. Les décorateurs suivants ajouteront l'UUID de l'hôte exécutant osquery et le nom d'utilisateur de l'utilisateur à chaque requête planifiée.
..........
..........
"decorators": {
"load": [
"SELECT uuid AS host_uuid FROM system_info;",
"SELECT user AS username FROM logged_in_users ORDER BY time DESC LIMIT 1;"
]
},
..........
..........2.3 Packs de requêtes
La configuration prend en charge des ensembles, appelés packs, de requêtes qui aident à définir votre planification. Les packs sont distribués avec osquery et étiquetés en fonction de grandes catégories d'informations et de visibilité. Par exemple, un pack "conformité" comprendra des requêtes qui vérifient les modifications apportées aux fonctionnalités du système d'exploitation verrouillé et aux paramètres utilisateur. Un pack de "gestion des vulnérabilités" peut effectuer des requêtes générales de gestion des actifs qui créent des journaux d'événements autour des modifications d'installation de packages et de logiciels. L'ensemble de packs par défaut situé dans le dossier /usr/share/osquery/packs. Ajoutez ces packs au fichier de configuration.
..........
..........
"packs": {
"osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
"incident-response": "/usr/share/osquery/packs/incident-response.conf",
"it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
"vuln-management": "/usr/share/osquery/packs/vuln-management.conf"
}2.4 Créer un pack personnalisé pour la surveillance de l'intégrité des fichiers
Les packs que nous avons ajoutés dans la section précédente sont livrés prêts à l'emploi. Nous voulons maintenant ajouter notre propre pack dont la tâche est de surveiller l'intégrité des fichiers pour les dossiers configurés via file_paths. Créez un fichier nommé fims.conf dans /usr/share/osquery/packs/ et ajoutez la section suivante.
# vi /usr/share/osquery/packs/fims.conf
{
"queries": {
"file_events": {
"query": "select * from file_events;",
"removed": false,
"interval": 300
}
},
"file_paths": {
"homes": [
"/root/.ssh/%%",
"/home/%/.ssh/%%"
],
"etc": [
"/etc/%%"
],
"home": [
"/home/%%"
],
"tmp": [
"/tmp/%%"
]
}
}La requête file_events est planifiée pour collecter tous les événements FIM qui se sont produits sur tous les fichiers dans les chemins spécifiés par file_paths sur un intervalle de cinq minutes. À un niveau élevé, cela signifie que les événements sont mis en mémoire tampon dans osquery et envoyés à l'enregistreur configuré toutes les cinq minutes.
Modifiez la section packs dans osquery.conf pour inclure le fichier ci-dessus.
# sudo vi /etc/osquery/osquery.conf
.................
"packs": {
"fim": "/usr/share/osquery/packs/fims.conf",
"osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
"incident-response": "/usr/share/osquery/packs/incident-response.conf",
"it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
"vuln-management": "/usr/share/osquery/packs/vuln-management.conf"
}Le fichier de configuration OSQUERY final ressemble à ceci-
{
"options": {
"config_plugin": "filesystem",
"logger_plugin": "filesystem",
"logger_path": "/var/log/osquery",
"disable_logging": "false",
"log_result_events": "true",
"schedule_splay_percent": "10",
"pidfile": "/var/osquery/osquery.pidfile",
"events_expiry": "3600",
"database_path": "/var/osquery/osquery.db",
"verbose": "true",
"worker_threads": "2",
"enable_monitor": "true",
"disable_events": "false",
"disable_audit": "false",
"audit_allow_config": "true",
"host_identifier": "hostname",
"enable_syslog": "true",
"syslog_pipe_path": "/var/osquery/syslog_pipe",
"audit_allow_sockets": "true",
"schedule_default_interval": "3600"
},
"schedule": {
"crontab": {
"query": "SELECT * FROM crontab;",
"interval": 300
},
"largest_process": {
"query": "select pid, name, uid, resident_size from processes order by resident_size desc limit 10;",
"interval": 60
}
},
"decorators": {
"load": [
"SELECT uuid AS host_uuid FROM system_info;",
"SELECT user AS username FROM logged_in_users ORDER BY time DESC LIMIT 1;"
]
},
"packs": {
"fim": "/usr/share/osquery/packs/fims.conf",
"osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf",
"incident-response": "/usr/share/osquery/packs/incident-response.conf",
"it-compliance": "/usr/share/osquery/packs/it-compliance.conf",
"vuln-management": "/usr/share/osquery/packs/vuln-management.conf",
"hardware-monitoring": "/usr/share/osquery/packs/hardware-monitoring.conf"
}
}Vérifiez la validité du fichier de configuration.
# sudo osqueryctl config-checkExécutez le shell interactif OSQUERY en mode détaillé.
# osqueryi --verbose3. Configurez OSQUERY pour consommer les journaux syslog-ng
Dans cette étape, nous allons configurer OSQUERY pour consommer les syslogs. Ubuntu a l'application rsyslog par défaut qui génère des syslogs mais dans cet article, nous allons découvrir comment configurer syslog-ng pour que les journaux générés par celui-ci soient consommés par OSQUERY. La table syslog d'OSQUERY interroge les journaux transmis via un canal nommé à partir d'un démon syslog-ng correctement configuré. Au fur et à mesure que syslog est ingéré dans osquery, il est écrit dans le magasin de sauvegarde (RocksDB) et mis à disposition pour l'interrogation. Par conséquent, la configuration de syslog-ng créera un canal nommé à travers lequel OSQUERY consommera les journaux.
Installer syslog-ng
# sudo apt-get install syslog-ngModifiez le groupe de fichiers créé par syslog-ng en syslog. Modifiez le fichier de configuration principal syslog-ng et changez le groupe en adm.
# vi /etc/syslog-ng/syslog-ng.conf
.........................
.........................
options { chain_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no);
owner("root"); group("adm"); perm(0640); stats_freq(0); bad_hostname("^gconfd$"); threaded(yes); }; ......................... .........................Ensuite, créez la configuration syslog-ng pour OSQUERY. La section suivante montre comment configurer syslog-ng pour les journaux système et réécrit ces journaux au format CSV. Ensuite, un modèle est utilisé pour formater le message/journal afin que les champs du journal se fondent avec la table syslog d'OSQUERY. Enfin, les journaux sont poussés vers le canal nommé pour qu'OSQUERY les consomme. Les autorisations pour le tube doivent au moins permettre à syslog-ng de lire/écrire et à osquery de lire.
# vi /etc/syslog-ng/conf.d/osquery.conf
source s_osquery {
system();
};
rewrite r_csv_message {
set("$MESSAGE", value("CSVMESSAGE") );
subst("\"","\\\"", value("CSVMESSAGE"), flags(global) );
};
template t_csv {
template("\"${ISODATE}\", \"${HOST}\", \"${LEVEL_NUM}\", \"${FACILITY}\", \"${PROGRAM}\", \"${MESSAGE}\"\n");
template_escape(no);
};
destination d_osquery {
pipe("/var/osquery/syslog_pipe" template(t_csv));
};
log {
source(s_osquery);
rewrite(r_csv_message);
destination(d_osquery);
};Le fichier de configuration d'osquery ( /etc/osquery/osquery.conf ) que nous avons créé précédemment a besoin d'un petit ajustement pour syslog-ng. Remplacez logger_plugin par syslog à partir du système de fichiers ou conservez les deux.
"logger_plugin": "syslog" or "logger_plugin": "filesystem,syslog"Les options suivantes sont également nécessaires pour l'ingestion de Syslog.
.................
.................
"enable_syslog": "true",
"syslog_pipe_path": "/var/osquery/syslog_pipe",
"disable_events": "false",
.................
.................Nous devons donc modifier uniquement les options logger_plugin dans le fichier /etc/osquery/osquery.conf que nous avons créé précédemment et le reste des trois options est déjà présent dans le fichier de configuration.
Redémarrez maintenant syslog-ng et vérifiez si le canal a été créé avec les autorisations appropriées.
# sudo systemctl start syslog-ng
# ls -l /var/osquery/syslog_pipe
prw-r----- 1 root adm 0 Apr 27 14:29 /var/osquery/syslog_pipeVérifiez les bûches circulant dans le tuyau
# cat /var/osquery/syslog_pipe
"2017-04-27T14:42:33+00:00", "ubuntu", "6", "auth", "sshd", "Accepted password for root from 117.227.81.214 port 61849 ssh2"
"2017-04-27T14:42:33+00:00", "ubuntu", "6", "authpriv", "sshd", "pam_unix(sshd:session): session opened for user root by (uid=0)"
"2017-04-27T14:42:41+00:00", "ubuntu", "5", "local3", "osqueryi", "severity=0 location=options.cpp:61 message=Verbose logging enabled by config option"
...................................
...................................Démarrez le shell interactif OSQUERY.
# osqueryi
I0427 14:32:07.981422 3730 options.cpp:61] Verbose logging enabled by config option
I0427 14:32:08.085734 3730 syslog.cpp:97] Successfully opened pipe for syslog ingestion: /var/osquery/syslog_pipe
I0427 14:32:08.101172 3730 file_events.cpp:68] Added file event listener to: /etc/**
....................
I0427 14:32:08.101784 3730 audit.cpp:226] Adding audit rule: syscall=59 action=2 filter=''
....................
I0427 14:32:08.278990 3737 events.cpp:749] Starting event publisher run loop: syslog
I0427 14:32:08.279242 3736 events.cpp:749] Starting event publisher run loop: inotify
I0427 14:32:08.279353 3735 events.cpp:749] Starting event publisher run loop: audit
osquery>Interrogez maintenant la table syslog.
osqueryi> select * from syslog;La requête ci-dessus affichera les journaux système consommés par osquery via le canal nommé /var/osquery/syslog_pipe
4. Détection des menaces et DFIR via OSQUERYi
Dans cette section, nous allons explorer quelques contrôles de sécurité de base via le shell interactif osquery.
a) Exécutez la requête suivante pour trouver qui sont les utilisateurs connectés au système actuellement.
osquery> select * from logged_in_users ;b) Retrouver toutes les connexions précédentes
osquery> select * from last ;c) Pour trouver les règles de pare-feu, exécutez la requête suivante. Si la requête suivante ne produit aucune sortie, cela signifie que le pare-feu n'est pas configuré.
osquery> select * from iptables ;d) Pour trouver toutes les tâches planifiées par crontab, exécutez la requête suivante. Avec cette requête, vous pouvez trouver s'il y a des logiciels malveillants qui ont été programmés pour s'exécuter à un intervalle spécifique.
osquery> select command, path from crontab ;e) Trouvez les fichiers qui sont activés par setuid. Par défaut, peu de fichiers sont activés par setuid dans Ubuntu 16, mais à part ceux-ci, quels sont les autres fichiers qui sont activés par setuid. Cela aidera à détecter les fichiers binaires de porte dérobée.
osquery> select * from suid_bin ;f) Trouvez la liste des modules du noyau chargés.
osquery> select name, used_by, status from kernel_modules where status="Live" ;g) Trouvez tous les ports d'écoute pour vérifier s'il existe une porte dérobée vers le système. S'il existe un port ouvert que vous n'avez pas configuré, vous devrez peut-être examiner le processus qui a ouvert ce port.
osquery> select * from listening_ports ;h) Trouvez l'activité du fichier sur le serveur avec l'utilisateur responsable en exécutant la requête suivante.
osquery> select * from file_events ;i) Trouvez les 10 processus les plus volumineux par taille de mémoire résidente.
osquery> select pid, name, uid, resident_size from processes order by resident_size desc limit 10;j) Trouvez tous les processus en cours d'exécution.
osquery> select * from processes;k) Trouvez le nombre de processus, le nom des 10 processus les plus actifs.
osquery> select count(pid) as total, name from processes group by name order by total desc limit 10;l) En règle générale, les logiciels malveillants écoutent les ports et transmettent le shell inversé à l'attaquant. Exécutez la requête suivante et recherchez les différences avec tout état de sécurité connu antérieur de votre système.
osquery> SELECT DISTINCT process.name, listening.port, listening.address, process.pid FROM processes AS process JOIN listening_ports AS listening ON process.pid = listening.pid;m) Souvent, l'attaquant supprimera le fichier binaire malveillant après l'avoir exécuté dans le système. Pour trouver de tels processus, exécutez la requête suivante.
osquery> SELECT name, path, pid FROM processes WHERE on_disk = 0;n) Exécutez la requête suivante pour déterminer s'il existe un shell inverse bash transmis à l'attaquant.
osquery> SELECT * FROM processes WHERE cmdline LIKE '/bin/bash -i >& /dev/tcp/%';5. OSQUERY en mode démon
Comme nous l'avons vu, OSQUERY renverra les résultats de l'état du système d'exploitation en temps réel qui pourront être interrogés ultérieurement. Mais il n'est pas possible d'exécuter une requête tout le temps pour la détection des menaces. En dehors de cela, OSQUERY n'inclut pas non plus de mécanisme d'alerte. La solution consiste à exécuter OSQUERY en tant que démon qui exécutera les requêtes planifiées et les packs inclus dans le fichier de configuration à intervalles réguliers et écrira les résultats dans un fichier. Créez vos propres packs dans /usr/share/osquery/packs et incluez les packs à surveiller dans le fichier de configuration OSQUERY. Les résultats des requêtes et des packs planifiés sont écrits dans le fichier /var/log/osquery/osqueryd.results.log Ce fichier journal sera créé uniquement lorsque OSQUERY a démarré en mode démon et qu'OSQUERYD commence à envoyer les résultats. Le démon OSQUERY lira le même fichier de configuration /etc/osquery/osquery.conf. N'oubliez pas de rétablir la valeur de logger_plugin sur le système de fichiers dans /etc/osquery/osquery.conf si vous l'avez précédemment modifiée en 'syslog'.
Pour démarrer le démon, utilisez l'une des commandes suivantes.
# sudo systemctl start osqueryd
OR
# sudo osqueryctl startLes résultats devraient être disponibles dans un court laps de temps une fois que l'OSQUERYD exécute les requêtes et les packs planifiés. Utilisez la commande tail pour vérifier que les résultats sont écrits dans le fichier /var/log/osquery/osqueryd.results.log
# tail -f /var/log/osquery/osqueryd.results.logVous pouvez désormais transférer les journaux de résultats vers n'importe quelle application externe comme la pile ELK pour l'analyse des journaux et la génération d'alertes.
Conclusion
OSQUERY est un outil génial qui expose les données du système d'exploitation à la base de données relationnelle virtuelle et vous permet d'interroger les données du système avec SQL. osqueryi est utile pour exécuter des requêtes uniques pour trouver des portes dérobées, des logiciels malveillants, des processus zombies ou pour découvrir des utilisateurs connectés, etc. tandis que osqueryd peut être utilisé pour exécuter des requêtes planifiées et des packs personnalisés pour stocker les résultats à long terme et générer des alertes à l'aide de application externe.