Comment surveiller la sécurité de votre système avec osquery sur Ubuntu 16.04

introduction

osquery est un outil de sécurité open source qui prend un système d’exploitation et le transforme en une base de données géante, avec des tables que vous pouvez interroger à l’aide d’instructions de type SQL. Avec ces requêtes, vous pouvez surveiller l’intégrité des fichiers, vérifier l’état et la configuration du pare-feu, effectuer des audits de sécurité du serveur cible, etc.

Il s’agit d’une application multiplate-forme prenant en charge les versions récentes de macOS, Windows 10, CentOS et Ubuntu. Il est officiellement décrit comme un cadre «d’instrumentation, de surveillance et d’analyse de système d’exploitation basé sur SQL» et provient de Facebook.

Avec osquery, vous pouvez exécuter des commandes telles que + select * from log_in_users; + sur votre serveur et obtenir un résultat du type suivant:

Output+-----------+----------+-------+------------------+------------+------+
| type      | user     | tty   | host             | time       | pid  |
+-----------+----------+-------+------------------+------------+------+
| login     | LOGIN    | ttyS0 |                  | 1483580429 | 1546 |
| login     | LOGIN    | tty1  |                  | 1483580429 | 1549 |
| user      | root     | pts/0 | 24.27.68.82      | 1483580584 | 1752 |
| user      | sammy    | pts/1 | 11.11.11.11      | 1483580770 | 4057 |
| boot_time | reboot   | ~     | 4.4.0-57-generic | 1483580419 | 0    |
| runlevel  | runlevel | ~     | 4.4.0-57-generic | 1483580426 | 53   |
+-----------+----------+-------+------------------+------------+------+

Si cela vous intéresse, vous allez adorer utiliser osquery comme outil de surveillance de la sécurité du système et de détection des intrusions sur votre serveur.

L’installation d’osquery vous donne accès aux composants suivants:

  • + osqueryi +: Le shell osquery interactif, pour effectuer des requêtes ad-hoc.

  • + osqueryd +: Un démon pour planifier et exécuter des requêtes en arrière-plan.

  • + osqueryctl +: Un script d’assistance pour tester un déploiement ou une configuration d’osquery. Il peut également être utilisé à la place du gestionnaire de services du système d’exploitation pour démarrer / arrêter / redémarrer + osqueryd +.

+ osqueryi + et + osqueryd + sont des outils indépendants. Ils ne communiquent pas et vous pouvez utiliser l’un sans l’autre. La plupart des indicateurs et options nécessaires à leur exécution sont identiques et vous pouvez lancer + osqueryi + en utilisant le fichier de configuration de + osqueryd + afin de pouvoir personnaliser l’environnement sans utiliser de nombreux commutateurs de ligne de commande.

Dans ce tutoriel, vous allez:

  • Installez osquery.

  • Configurez les aspects du système d’exploitation, tels que Rsyslog, dont osquery a besoin pour fonctionner correctement.

  • Configurez un fichier de configuration pouvant être utilisé à la fois par + osqueryi + et + + osqueryd +.

  • Travaillez avec osquery packs, qui sont des groupes de requêtes prédéfinies que vous pouvez ajouter à une planification.

  • Effectuez des requêtes ad hoc en utilisant + osqueryi + pour rechercher les problèmes de sécurité.

  • Démarrez le démon pour qu’il puisse exécuter des requêtes automatiquement.

Les journaux générés par + osqueryd +, le démon, sont destinés à être expédiés vers des noeuds finaux de journalisation externes nécessitant une expertise supplémentaire pour être configurés et utilisés correctement. Ce tutoriel ne couvrira pas cette configuration, mais vous apprendrez à configurer et à exécuter le démon et à enregistrer les résultats localement.

Conditions préalables

Pour compléter ce didacticiel, vous devez disposer des éléments suivants:

Vous devez également avoir une compréhension de base de SQL et une connaissance de la sécurité des systèmes Linux.

Étape 1 - Installation d’osquery sur le serveur

Vous pouvez installer osquery en le compilant à partir des sources ou en utilisant le gestionnaire de paquets. Comme il n’ya pas de paquet installable dans le référentiel officiel Ubuntu, vous devrez ajouter le référentiel officiel du projet au système.

Tout d’abord, ajoutez la clé publique du référentiel:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1484120AC4E9F8A1A577AEEE97A80C63C9D8B80B

Ajoutez ensuite le référentiel:

sudo add-apt-repository "deb [arch=amd64] https://osquery-packages.s3.amazonaws.com/xenial xenial main"

Mettre à jour la base de données de paquets:

sudo apt-get update

Enfin, installez osquery:

sudo apt-get install osquery

Hors de la boîte, osquery n’est pas incroyablement utile; ce n’est pas une application plug-and-play. Que vous souhaitiez utiliser le shell interactif ou le démon, vous devez transmettre des indicateurs et des options, à partir de la ligne de commande ou via un fichier de configuration. Pour afficher les indicateurs et les options disponibles pour le démon, tapez:

osqueryd --help

La sortie comprendra des dizaines d’indicateurs de ligne de commande et d’options de configuration. Vous trouverez ci-dessous une sortie partielle du serveur de test utilisé pour cet article.

Outputosquery 2.1.2, your OS as a high-performance relational database
Usage: osqueryd [OPTION]...

osquery command line flags:

   --flagfile PATH                           Line-delimited file of additional flags
   --config_check                            Check the format of an osquery config and exit
   --config_dump                             Dump the contents of the configuration
   --config_path VALUE                       Path to JSON config file
   --config_plugin VALUE                     Config plugin name
   --config_tls_endpoint VALUE               TLS/HTTPS endpoint for config retrieval
   --config_tls_max_attempts VALUE           Number of attempts to retry a TLS config/enroll request
   --config_tls_refresh VALUE                Optional interval in seconds to re-read configuration
   --daemonize                               Run as daemon (osqueryd only)

...

...

osquery configuration options (set by config or CLI flags):

   --audit_allow_config                      Allow the audit publisher to change auditing configuration
   --audit_allow_sockets                     Allow the audit publisher to install socket-related rules
   --audit_persist                           Attempt to retain control of audit
   --aws_access_key_id VALUE                 AWS access key ID
   --aws_firehose_period VALUE               Seconds between flushing logs to Firehose (default 10)
   --aws_firehose_stream VALUE               Name of Firehose stream for logging
   --aws_kinesis_period VALUE                Seconds between flushing logs to Kinesis (default 10)
   --aws_kinesis_random_partition_key        Enable random kinesis partition keys
   --aws_kinesis_stream VALUE                Name of Kinesis stream for logging
   --aws_profile_name VALUE                  AWS profile for authentication and region configuration
   --aws_region VALUE                        AWS region

Pour afficher des indicateurs de ligne de commande supplémentaires uniquement disponibles pour le shell interactif, tapez:

osqueryi --help

Exécuter + osqueryi + est la méthode la plus simple pour lister et interroger les tables osquery disponibles prêtes à l’emploi. Par exemple, lancez-le en utilisant la commande suivante:

osqueryi --verbose

Cela vous placera dans un shell interactif et vous obtiendrez une sortie semblable à celle-ci:

OutputI0105 01:52:54.987584  4761 init.cpp:364] osquery initialized [version=2.1.2]
I0105 01:52:54.987808  4761 extensions.cpp:351] Could not autoload extensions: Failed reading: /etc/osquery/extensions.load
I0105 01:52:54.987944  4761 extensions.cpp:364] Could not autoload modules: Failed reading: /etc/osquery/modules.load
I0105 01:52:54.988209  4761 init.cpp:606] Error reading config: config file does not exist: /etc/osquery/osquery.conf
I0105 01:52:54.988334  4761 events.cpp:886] Error registering subscriber: socket_events: Subscriber disabled via configuration
I0105 01:52:54.993973  4763 interface.cpp:307] Extension manager service starting: /home/sammy/.osquery/shell.em
Using a virtual database. Need help, type '.help'
osquery>

En raison des messages d’erreur et d’information dans la sortie, il est évident que toutes les parties d’osquery ne fonctionnent pas correctement. Certaines requêtes, comme + select * de yara; + ne renverront rien, montrant que la table n’a pas été renseignée avec des données.

D’autres requêtes, telles que + select heure, gravité, message de syslog; + renverront un message du type suivant, indiquant que nous avons encore du travail à faire:

OutputW1202 15:44:48.600539  1720 virtual_table.cpp:492] Table syslog is event-based but events are disabled
W1202 15:44:48.600587  1720 virtual_table.cpp:499] Please see the table documentation: https://osquery.io/docs/#syslog

Nous allons apporter quelques modifications à la configuration de notre serveur pour résoudre ce problème.

Quittez la console en tapant:

.exit

Dans la section suivante, nous allons modifier certains aspects du système d’exploitation dont OSquery a besoin pour fonctionner correctement.

Étape 2 - Autoriser osquery à accéder au journal système

Dans cette étape, nous allons modifier l’application syslog du système d’exploitation pour permettre à osquery de consommer et d’interroger le journal système. Sur Ubuntu 16.04, cela signifie modifier le fichier de configuration Rsyslog. Et la seule modification à apporter consiste à ajouter quelques lignes de code au fichier de configuration.

Pour commencer, ouvrez le fichier + / etc / rsyslog.conf +:

sudo nano /etc/rsyslog.conf

Nous devons ajouter quelques lignes de configuration indiquant à Rsyslog sur quel canal écrire et quels paramètres syslog écrire sur ce canal. Par défaut, le tube est + / var / osquery / syslog_pipe +. osquery remplit ensuite sa table + syslog + à partir d’informations écrites dans ce canal.

Ajoutez les lignes suivantes au fichier:

/etc/rsyslog.conftemplate(
 name="OsqueryCsvFormat"
 type="string"
 string="%timestamp:::date-rfc3339,csv%,%hostname:::csv%,%syslogseverity:::csv%,%syslogfacility-text:::csv%,%syslogtag:::csv%,%msg:::csv%\n"
)
*.* action(type="ompipe" Pipe="/var/osquery/syslog_pipe" template="OsqueryCsvFormat")

Enregistrez et fermez le fichier. Pour appliquer les modifications, redémarrez le démon syslog:

sudo systemctl restart rsyslog

Créons maintenant un fichier de configuration qui définit certaines options par défaut et planifie certaines requêtes.

Étape 3 - Création d’un fichier de configuration osquery

La création d’un fichier de configuration facilite l’exécution de + osqueryi +. Au lieu de devoir passer de nombreuses options en ligne de commande, + osqueryi + peut lire ces options à partir d’un fichier de configuration situé dans + / etc / osquery / osquery.conf +. Et, bien sûr, le fichier de configuration sera également disponible pour le démon.

Le fichier de configuration contient également des requêtes qui doivent être exécutées dans les délais. Cependant, la plupart des requêtes que vous pouvez exécuter dans les délais sont expédiées sous la forme de paquets. Les packs sont des fichiers situés dans le répertoire + / usr / share / osquery / packs +.

osquery ne vient pas avec un fichier de configuration, mais il existe un exemple de fichier de configuration que vous pouvez copier sur + / etc / osquery + et modifier. Toutefois, ce fichier ne dispose pas de toutes les options nécessaires pour l’exécuter sur une distribution Linux telle que Ubuntu. Nous allons donc créer le nôtre.

Le fichier de configuration comprend trois sections:

  • Une liste des options du démon et des paramètres de fonctionnalité. Ceux-ci peuvent également être lus par + osqueryi +.

  • Liste des requêtes planifiées à exécuter et à quel moment.

  • Une liste de packs à utiliser pour mener des requêtes planifiées plus spécifiques.

Vous trouverez ci-dessous une liste des options que nous allons utiliser pour notre fichier de configuration, leur signification et les valeurs que nous leur attribuerons. Cette liste d’options est suffisante pour exécuter + osqueryi + et + osqueryd + sur Ubuntu 16.04 et d’autres distributions Linux.

  • * config_plugin *: Où voulez-vous que osquery lise ses configurations? Par défaut, ils sont lus à partir d’un fichier sur le disque. La valeur correspondante est donc + système de fichiers +.

  • * logger_plugin *: Spécifie où osquery doit écrire les résultats des requêtes planifiées. Une fois encore, nous allons utiliser + filesystem +.

  • * logger_path *: il s’agit du chemin du répertoire des journaux dans lequel vous trouverez des fichiers contenant des informations, des avertissements, des erreurs et des résultats de requêtes planifiées. Par défaut, il s’agit de + / var / log / osquery +.

  • * disable_logging *: En définissant la valeur de this sur + false +, nous activons la journalisation.

  • * log_result_events *: en définissant ceci sur + true +, chaque ligne des journaux de résultats représentera un changement d’état.

  • schedule_splay_percent *: Ceci indique à osquery que lorsqu’un grand nombre de requêtes sont planifiées à la même intervalle, il est préférable de les exécuter de manière dispersée afin de limiter tout impact sur les performances du serveur. La valeur par défaut est + 10 +, qui est un pourcentage.

  • * pidfile *: Où écrire l’ID de processus du démon osquery. La valeur par défaut est + / var / osquery / osquery.pidfile +.

  • * events_expiry *: en secondes, le temps de stockage des résultats d’abonné dans le magasin de sauvegarde d’osquery. Hors de la boîte, ceci est réglé sur + 3600 +.

  • * database_path *: chemin de la base de données osquery. Nous allons utiliser la valeur par défaut, qui est + / var / osquery / osquery.db +.

  • * verbose *: avec la journalisation activée, permet d’activer ou de désactiver les messages d’information verbeux. Nous allons définir ceci sur + false.

  • * worker_threads *: nombre de threads de répartition du travail utilisés pour traiter les requêtes. Ceci est réglé par défaut sur + 2 +, nous allons donc en rester là.

  • * enable_monitor *: Utilisé pour activer ou désactiver le moniteur de planification. Nous allons l’activer, donc la valeur sera + true +.

  • * disable_events *: utilisé pour réguler le système de publication / abonnement d’Osquery. Nous avons besoin de cette option, donc la valeur ici sera + false +.

  • * disable_audit *: utilisé pour désactiver la réception des événements du sous-système d’audit du système d’exploitation. Nous avons besoin de l’activer, donc la valeur utilisée ici sera + false +.

  • * audit_allow_config *: Autorise l’éditeur d’audit à modifier la configuration de l’audit. La valeur par défaut est + true +.

  • * audit_allow_sockets *: Ceci permet à l’éditeur d’audit d’installer des règles relatives aux sockets. La valeur sera + true +.

  • * host_identifier *: Ceci est utilisé pour identifier l’hôte exécutant osquery. Lors de l’agrégation des résultats de plusieurs serveurs, il est utile de déterminer facilement à partir de quel serveur provient une entrée de journal particulière. La valeur est soit + hostname + ou + uuid +. Hors de la boîte, il est réglé sur + hostname +, nous allons donc utiliser cette valeur.

  • * enable_syslog *: Pour que osquery consomme des informations syslog, vous devez lui attribuer la valeur + true +.

  • * schedule_default_interval *: lorsque l’intervalle d’une requête programmée n’est pas défini, utilisez cette valeur. C’est en secondes et nous allons le régler sur «+ 3600 +».

Vous avez déjà vu comment afficher tous les indicateurs de ligne de commande et les options de configuration disponibles pour + osqueryi + et + osqueryd +, mais les options ci-dessus seront suffisantes pour exécuter osquery sur ce serveur.

Créez et ouvrez le fichier de configuration à l’aide de la commande suivante:

sudo nano /etc/osquery/osquery.conf

Le fichier de configuration utilise le format JSON. Copiez le contenu suivant dans le fichier:

/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"
 },

La partie suivante du fichier de configuration est la section de planification. Chaque requête est identifiée par une clé ou un nom, qui doit être unique dans le fichier, suivi de la requête à exécuter et de l’intervalle, en secondes, pour exécuter la requête. Nous allons ajouter une requête planifiée qui examine la table + crontab + toutes les 300 secondes.

Ajoutez ces lignes au fichier de configuration:

/etc/osquery/osquery.conf

 "schedule": {
   "crontab": {
     "query": "SELECT * FROM crontab;",
     "interval": 300
   }
 },

Vous pouvez écrire autant de requêtes que vous le souhaitez. Il suffit de garder le bon format. Sinon, la validation du fichier échouera. Par exemple, pour ajouter quelques requêtes supplémentaires, ajoutez ces lignes:

/etc/osquery/osquery.conf

 "schedule": {
   "crontab": {
     "query": "SELECT * FROM crontab;",
     "interval": 300
   }







 },

Après les requêtes planifiées, vous pouvez ajouter des requêtes spéciales appelées * décorators *, qui sont des requêtes qui ajoutent des données à d’autres requêtes planifiées. Les requêtes de décorateur présentées ici ajouteront l’UUID de l’hôte exécutant osquery et le nom d’utilisateur de l’utilisateur à chaque requête planifiée.

Ajoutez ces lignes au fichier:

/etc/osquery/osquery.conf

 "decorators": {
   "load": [
     "SELECT uuid AS host_uuid FROM system_info;",
     "SELECT user AS username FROM logged_in_users ORDER BY time DESC LIMIT 1;"
   ]
 },

Enfin, nous pouvons faire pointer osquery vers une liste de packs contenant des requêtes plus spécifiques. Chaque installation d’osquery est fournie avec un ensemble de packs par défaut situé dans le répertoire + / usr / share / osquery / packs +. L’un des packs est destiné à macOS, tandis que les autres sont destinés aux systèmes Linux. Bien que vous puissiez utiliser les packs à partir de leur emplacement par défaut, vous pouvez également les copier dans le répertoire + / etc / osquery +.

Ajoutez ces lignes au fichier pour compléter le fichier.

/etc/osquery/osquery.conf

 "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"
 }
}

Notez l’accolade fermante à la fin, qui correspond à l’accolade ouverte sur la première ligne du fichier. Votre fichier de configuration complété devrait ressembler à ceci:

/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"
 },
 "schedule": {
   "crontab": {
     "query": "SELECT * FROM crontab;",
     "interval": 300
   },
   "system_profile": {
     "query": "SELECT * FROM osquery_schedule;"
   },
   "system_info": {
     "query": "SELECT hostname, cpu_brand, physical_memory FROM system_info;",
     "interval": 3600
   }
 },
 "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": {
    "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"
 }
}

Enregistrez et fermez le fichier, puis validez-le à l’aide de la commande suivante:

sudo osqueryctl config-check

Le résultat devrait ressembler à ceci:

OutputI0104 11:11:46.022858 24501 rocksdb.cpp:187] Opening RocksDB handle: /var/osquery/osquery.db

S’il y a une erreur, la sortie indiquera l’emplacement de l’erreur afin que vous puissiez la réparer.

Une fois que vous avez un fichier de configuration valide, vous pouvez passer à la configuration du pack osquery requis pour la surveillance de l’intégrité des fichiers.

Étape 4 - Configuration du pack de surveillance d’intégrité de fichiers osquery

Surveiller l’intégrité des fichiers sur votre serveur est un aspect essentiel de la surveillance de la sécurité de son système. Pour cela, osquery offre une solution prête à l’emploi.

Les packs que vous avez ajoutés à la configuration dans la section précédente sont livrés prêts à l’emploi. Dans cette section, nous ajouterons un pack supplémentaire à la liste, qui contiendra la requête et les directives qui seront utilisées pour la surveillance de l’intégrité des fichiers. Pour cet exercice, nous appellerons le fichier + fim.conf +.

Créez ce fichier et ouvrez-le dans votre éditeur:

sudo nano /usr/share/osquery/packs/fim.conf

Nous allons créer un pack qui surveillera les événements de fichier dans les répertoires + / home,` + / etc` et + / tmp toutes les 300 secondes. La configuration complète du fichier de pack est indiquée dans la liste de fichiers suivante. Copiez-le dans le fichier.

/usr/share/osquery/packs/fim.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/%%"
   ]
 }
}

Enregistrez et fermez le fichier.

Pour que le nouveau fichier et ses règles soient disponibles pour osquery, référencez-le dans la liste des packs à la fin de + / etc / osquery / osquery.conf +. Ouvrez le fichier pour le modifier:

sudo nano /etc/osquery/osquery.conf

Puis modifiez la section packs pour inclure le nouveau fichier:

/etc/osquery/osquery.conf
...

"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"
 }

Enregistrez et fermez le fichier. Et pour vous assurer que vous n’avez pas commis d’erreur dans le fichier, validez-le à nouveau:

sudo osqueryctl config-check

Commençons maintenant par + osqueryi + pour interroger le système.

Étape 5 - Utilisation d’osqueryi pour effectuer des contrôles de sécurité ad hoc

Il existe de nombreux endroits où l’osquery est utile. Dans cette section, vous effectuerez diverses vérifications de sécurité sur votre système à l’aide de + osqueryi +, le shell interactif. Gardez à l’esprit qu’à ce stade, nous n’avons toujours pas démarré le démon osquery. Et c’est la beauté d’osquery: vous pouvez exécuter des requêtes avec + osqueryi + même si le démon n’est pas actif, tout en utilisant le fichier de configuration que nous avons créé pour configurer l’environnement.

Pour lancer + osquery + avec un fichier de configuration, tapez:

sudo osqueryi --config_path /etc/osquery/osquery.conf --verbose

Commençons par les contrôles de sécurité de base et remontons à partir de là. Par exemple, qui d’autre que vous est connecté au système maintenant? Découvrez avec cette requête:

select * from logged_in_users ;

Le résultat devrait ressembler à ceci:

Output+-----------+----------+-------+------------------+------------+------+
| type      | user     | tty   | host             | time       | pid  |
+-----------+----------+-------+------------------+------------+------+
| boot_time | reboot   | ~     | 4.4.0-57-generic | 1483580419 | 0    |
| runlevel  | runlevel | ~     | 4.4.0-57-generic | 1483580426 | 53   |
| login     | LOGIN    | ttyS0 |                  | 1483580429 | 1546 |
| login     | LOGIN    | tty1  |                  | 1483580429 | 1549 |
| user      |      | pts/0 |       | 1483580584 | 1752 |
| user      |     | pts/1 |       | 1483580770 | 4057 |
+-----------+----------+-------+------------------+------------+------+

Dans cette sortie, deux comptes d’utilisateurs réels sont connectés à la machine et ils proviennent tous deux de la même adresse IP. Cette adresse IP doit être une adresse IP connue. Si ce n’est pas le cas, vous devez rechercher l’origine de cette connexion.

La requête précédente vous indique qui est actuellement connecté, mais qu’en est-il des connexions précédentes? Vous pouvez le savoir en interrogeant la * dernière * table, comme ceci:

select * from last ;

La sortie n’indiquait rien d’extraordinaire, aucune autre personne ne s’est donc connectée à la machine récemment:

Output+----------+-------+------+------+------------+------------------+
| username | tty   | pid  | type | time       | host             |
+----------+-------+------+------+------------+------------------+
| reboot   | ~     | 0    | 2    | 1483580419 | 4.4.0-57-generic |
| runlevel | ~     | 53   | 1    | 1483580426 | 4.4.0-57-generic |
|          | ttyS0 | 1546 | 5    | 1483580429 |                  |
| LOGIN    | ttyS0 | 1546 | 6    | 1483580429 |                  |
|          | tty1  | 1549 | 5    | 1483580429 |                  |
| LOGIN    | tty1  | 1549 | 6    | 1483580429 |                  |
|      | pts/0 | 1752 | 7    | 1483580584 |       |
|     | pts/1 | 4057 | 7    | 1483580770 |       |
+----------+-------+------+------+------------+------------------+

Le pare-feu est-il configuré et activé? Le pare-feu est-il toujours actif? En cas de doute, lancez cette requête pour découvrir:

select * from iptables ;

S’il n’y a pas de sortie, cela signifie que le pare-feu IPTables n’a pas été configuré. Pour un serveur Internet, ce n’est pas une bonne chose, il est donc préférable de configurer le pare-feu.

Vous pouvez exécuter la commande précédente, modifiée pour filtrer des colonnes particulières, comme ceci:

select chain, policy, src_ip, dst_ip from iptables ;

Cette requête devrait donner une sortie comme celle-ci. Recherchez les adresses IP source et de destination inhabituelles que vous n’avez pas configurées:

Output+---------+--------+---------+-----------+
| chain   | policy | src_ip  | dst_ip    |
+---------+--------+---------+-----------+
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 127.0.0.0 |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| INPUT   | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| FORWARD | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| FORWARD | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| OUTPUT  | ACCEPT | 0.0.0.0 | 0.0.0.0   |
| OUTPUT  | ACCEPT | 0.0.0.0 | 0.0.0.0   |
+---------+--------+---------+-----------+

Quels types de travaux sont planifiés dans crontab? Avez-vous les planifier? Cette requête vous aidera à localiser les logiciels malveillants dont l’exécution a été planifiée à des intervalles spécifiques:

select command, path from crontab ;

Et la sortie devrait prendre cette forme. Toute commande suspecte nécessite une enquête plus approfondie:

Output+----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+
| command                                                                                                                                | path                           |
+----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+
| root cd / && run-parts --report /etc/cron.hourly                                                                                       | /etc/crontab                   |
| root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )                                                       | /etc/crontab                   |
| root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )                                                      | /etc/crontab                   |
| root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )                                                     | /etc/crontab                   |
| root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi | /etc/cron.d/mdadm              |
| root test -x /etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-contest --crond                                          | /etc/cron.d/popularity-contest |
+----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+

Existe-t-il des fichiers sur le système qui sont configurés avec setuid? Il y en a assez sur n’importe quel serveur Ubuntu 16.04, mais quels sont-ils, et y en a-t-il qui ne sont pas supposés être sur le système? Les réponses à ces questions vous aideront à détecter les fichiers binaires de porte dérobée. Exécutez cette requête périodiquement et comparez ses résultats avec les résultats antérieurs afin de pouvoir surveiller tous les ajouts. Cette requête est:

select * from suid_bin ;

Une sortie partielle de cette requête pourrait ressembler à ceci:

Output+-------------------------------+----------+-----------+-------------+
| path                          | username | groupname | permissions |
+-------------------------------+----------+-----------+-------------+
| /bin/ping6                    | root     | root      | S           |
| /bin/su                       | root     | root      | S           |
| /bin/mount                    | root     | root      | S           |
| /bin/umount                   | root     | root      | S           |
| /bin/fusermount               | root     | root      | S           |
| /bin/ntfs-3g                  | root     | root      | S           |
| /bin/ping                     | root     | root      | S           |
| /sbin/mount.ntfs-3g           | root     | root      | S           |
| /sbin/mount.ntfs              | root     | root      | S           |
| /sbin/unix_chkpwd             | root     | shadow    | G           |
| /sbin/pam_extrausers_chkpwd   | root     | shadow    | G           |
| /usr/bin/chage                | root     | shadow    | G           |
| /usr/bin/locate               | root     | mlocate   | G           |
| /usr/bin/chfn                 | root     | root      | S           |
| /usr/bin/chsh                 | root     | root      | S           |
| /usr/bin/newuidmap            | root     | root      | S           |
| /usr/bin/write                | root     | tty       | G           |
| /usr/bin/mlocate              | root     | mlocate   | G           |
| /usr/bin/at                   | daemon   | daemon    | SG          |
| /usr/bin/sg                   | root     | root      | S           |

Pour afficher une liste des modules du noyau chargés, exécutez la requête suivante:

select name, used_by, status from kernel_modules where status="Live" ;

C’est une autre requête que vous voudrez exécuter périodiquement et comparer sa sortie à des résultats plus anciens pour voir si quelque chose a changé.

Une autre méthode qui vous aidera à trouver les portes dérobées sur le serveur consiste à exécuter une requête répertoriant tous les ports d’écoute. Pour ce faire, exécutez cette requête:

select * from listening_ports ;

Sur un nouveau serveur avec uniquement SSH fonctionnant sur le port + 22 +, la sortie ressemblerait à ceci:

Output+-------+------+----------+--------+---------+
| pid   | port | protocol | family | address |
+-------+------+----------+--------+---------+
| 1686  | 22   | 6        | 2      | 0.0.0.0 |
| 1686  | 22   | 6        | 10     | ::      |
| 25356 | 0    | 0        | 0      |         |
+-------+------+----------+--------+---------+

Sur votre serveur, si la sortie ne comprend que des ports pour lesquels vous savez que le serveur doit être à l’écoute, vous n’avez aucune inquiétude Mais si d’autres ports sont ouverts, vous voudrez vous renseigner sur leur nature.

Pour examiner l’activité des fichiers sur le serveur, exécutez la requête suivante:

select target_path, action, uid from file_events ;

La sortie affiche toutes les activités de fichier récentes sur le serveur, ainsi que l’identifiant de l’utilisateur responsable de l’activité.

Output+---------------------------+---------+------+
| target_path               | action  | uid  |
+---------------------------+---------+------+
| /home/sammy/..bashrc.swp  | CREATED | 1000 |
| /home/sammy/..bashrc.swp  | UPDATED | 1000 |
| /home/sammy/..bashrc.swp  | UPDATED | 1000 |
| /home/sammy/.bashrc       | UPDATED | 1000 |
| /home/sammy/..bashrc.swp  | DELETED | 1000 |
| /home/sammy/..bashrc.swp  | CREATED | 1000 |
| /home/sammy/..bashrc.swp  | UPDATED | 1000 |
| /home/sammy/..bashrc.swp  | UPDATED | 1000 |
| /home/sammy/.bashrc       | UPDATED | 1000 |
| /home/sammy/.bashrc       | UPDATED | 1000 |
| /home/sammy/.bashrc       | UPDATED | 1000 |
| /home/sammy/..bashrc.swp  | DELETED |      |
| /etc/test_file.txt        | DELETED |      |
| /home/sammy/.bash_history | UPDATED | 1000 |
| /home/sammy/.bash_history | UPDATED | 1000 |
| /etc/secret_file.md       | CREATED | 0    |
| /etc/secret_file.md       | UPDATED | 0    |
| /etc/secret_file.md       | UPDATED | 0    |
+---------------------------+---------+------+

Il existe de nombreuses requêtes telles que celles que vous pouvez exécuter sur votre serveur pour avoir une idée des problèmes de sécurité possibles.

Si vous avez des doutes sur le schéma d’une table, utilisez la commande suivante pour le savoir:

.schema

Et vous pouvez lister les tables disponibles avec:

.tables

Les packs fournis avec osquery contiennent de nombreux autres exemples, et beaucoup sont conçus pour être exécutés périodiquement par + osqueryd +. Dans la section suivante, vous apprendrez à démarrer le démon pour exécuter ces requêtes.

Étape 6 - Lancer osqueryd

+ osqueryd +, le démon, permet à osquery d’exécuter des requêtes à des intervalles définis. Ces requêtes incluent celles que vous avez configurées à l’étape 4, celles des packs spécifiés à cette étape et du pack FIM que nous avons configuré à l’étape 5. Si vous ne les avez pas encore étudiés, c’est le moment de jeter un coup d’œil sur le contenu de + / usr / share / osquery / packs +.

Les résultats générés par + osqueryd + sont écrits dans un fichier nommé + osqueryd.results.log + dans le répertoire + / var / log / osquery +. Hors de la boîte, ce fichier n’existe pas. Il est créé uniquement au démarrage du démon et commence à générer des résultats.

Vous pouvez démarrer + osqueryd + en utilisant soit + systemctl + ou + osqueryctl +. Les deux accomplissent la même chose, donc peu importe celui que vous utilisez. + osqueryd + vérifiera l’existence d’un fichier de configuration au démarrage et vous alertera s’il n’en trouve pas. Il restera en cours d’exécution sans fichier de configuration, même s’il ne sert à rien.

Mais comme vous avez déjà configuré un fichier de configuration, il vous suffit de lancer le démon:

sudo systemctl start osqueryd

Ou vous pouvez taper:

sudo osqueryctl start

Quelques minutes après le démarrage du démon, la taille de + / var / log / osquery / osqueryd.results.log + devrait augmenter. Vous pouvez voir que cela se passe en tapant et en répétant la commande suivante:

ls -lh /var/log/osquery/osqueryd.results.log

La taille croissante du fichier indique que les résultats des requêtes planifiées sont en cours d’écriture sur le disque. Malheureusement, osquery n’a pas de système d’alerte tel que OSSEC, vous ne pouvez donc pas voir les résultats des requêtes planifiées à moins d’afficher le fichier de résultats. Vous pouvez le faire avec la commande + tail +, qui diffusera en continu les 10 dernières lignes de ce fichier sur votre écran:

sudo tail -f /var/log/osquery/osqueryd.results.log

Appuyez sur les touches + CTRL + C + pour arrêter de mettre fin au journal.

À plus long terme, vous voudriez envoyer le journal des résultats de la requête à une plate-forme d’analyse externe avec laquelle vous pouvez travailler. Les options open source viables incluent Doorman, Zentral et https://www.elastic.co/products/ elasticsearch [ElasticSearch].

Conclusion

osquery est un outil puissant, utile pour exécuter des requêtes uniques et planifiées en utilisant une syntaxe SQL bien connue. + osqueryi + est le composant osquery utilisé pour l’écriture de requêtes uniques, tandis que + osqueryd + sert à la planification de requêtes. Pour donner un sens aux résultats des requêtes planifiées, vous devez les expédier vers une plate-forme d’analyse de journaux externe. Pour plus d’informations sur osquery, rendez-vous sur https://osquery.io [https://osquery.io/].