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

De Get Docs
Aller à :navigation, rechercher

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 multiplateforme prenant en charge les versions récentes de macOS, Windows 10, CentOS et Ubuntu. Il est officiellement décrit comme un framework « d'instrumentation, de surveillance et d'analyse de système d'exploitation alimenté par SQL », et provient de Facebook.

Avec osquery, vous pouvez exécuter des commandes telles que select * from logged_in_users ; sur votre serveur et obtenir un résultat comme celui-ci :

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 adorerez utiliser osquery comme outil de surveillance de la sécurité du système et de détection des intrusions pour 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 drapeaux et des options nécessaires pour exécuter chacun sont les mêmes, et vous pouvez lancer osqueryi en utilisant le fichier de configuration de osqueryd afin de personnaliser l'environnement sans utiliser de nombreux commutateurs de ligne de commande.

Dans ce didacticiel, vous allez :

  • Installez osquery.
  • Configurez les aspects du système d'exploitation, comme Rsyslog, dont osquery a besoin pour fonctionner correctement.
  • Configurez un fichier de configuration qui peut ê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 à l'aide de osqueryi pour rechercher des problèmes de sécurité.
  • Démarrez le démon afin 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 terminaux de journalisation externes qui nécessitent une expertise supplémentaire pour être configurés et utilisés correctement. Ce didacticiel 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 terminer ce didacticiel, vous devez disposer des éléments suivants :

Vous devez également avoir une compréhension de base de SQL et une connaissance fondamentale de la sécurité du système 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 packages. Puisqu'il n'y a pas de package installable dans le référentiel officiel Ubuntu, vous devrez ajouter le référentiel Ubuntu officiel du projet au système.

Commencez par ajouter la clé publique du dépôt :

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

Ajoutez ensuite le dépôt :

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

Mettez à jour la base de données des packages :

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 ayez l'intention d'utiliser le shell interactif ou le démon, vous devez passer certains drapeaux et options, soit depuis la ligne de commande, soit via un fichier de configuration. Pour afficher les drapeaux 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 voir les indicateurs de ligne de commande supplémentaires uniquement disponibles pour le shell interactif, tapez :

osqueryi --help

L'exécution de osqueryi est la méthode la plus simple pour répertorier et interroger les tables osquery disponibles prêtes à l'emploi. Par exemple, lancez-le à l'aide de la commande suivante :

osqueryi --verbose

Cela vous placera dans un shell interactif et vous verrez une sortie similaire à ceci :

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 * from yara ; ne renverront rien, indiquant que la table n'a pas été remplie de données.

D'autres requêtes, comme select time, severity, message from syslog ; renverront un message comme celui-ci, 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 apporterons quelques modifications à la configuration de notre serveur pour résoudre ce problème.

Quittez la console en tapant :

.exit

Dans la section suivante, nous modifierons les 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 que vous devez apporter est d'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 qui indiquent à Rsyslog dans quel canal écrire et quels paramètres syslog écrire dans ce canal. Par défaut, le tuyau est /var/osquery/syslog_pipe. osquery remplit ensuite sa table syslog à partir des informations écrites dans ce tube.

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 de 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 packs. Les packs sont des fichiers situés dans le répertoire /usr/share/osquery/packs.

osquery n'est pas fourni avec un fichier de configuration, mais il existe un exemple de fichier de configuration que vous pouvez copier sur /etc/osquery et modifier. Cependant, ce fichier n'a pas toutes les options dont vous avez besoin pour l'exécuter sur une distribution Linux comme Ubuntu, nous allons donc créer le nôtre.

Il y a trois sections dans le fichier de configuration :

  • Une liste d'options de démon et de paramètres de fonctionnalités. Ceux-ci peuvent également être lus par osqueryi.
  • Une liste des requêtes planifiées à exécuter et quand elles doivent être exécutées.
  • Une liste de packs à utiliser pour effectuer des requêtes planifiées plus spécifiques.

Voici une liste des options que nous utiliserons pour notre fichier de configuration, ce qu'elles signifient et les valeurs que nous allons leur attribuer. 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 qu'osquery lise ses configurations. Par défaut, ils sont lus à partir d'un fichier sur le disque, donc la valeur pour ceci est filesystem.
  • logger_plugin : spécifie où osquery doit écrire les résultats des requêtes planifiées. Encore une fois, nous utiliserons filesystem.
  • logger_path : il s'agit du chemin d'accès au répertoire des journaux où vous trouverez les fichiers contenant les informations, les avertissements, les erreurs et les résultats des 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 ce paramètre sur true, chaque ligne des journaux de résultats représentera un changement d'état.
  • schedule_splay_percent : cela indique à osquery que lorsqu'un grand nombre de requêtes sont planifiées au même intervalle, il faut les exécuter étalées 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, durée de conservation des résultats de l'abonné dans le magasin de sauvegarde osquery. Par défaut, il est réglé sur 3600.
  • database_path : le chemin d'accès à la base de données d'osquery. Nous utiliserons la valeur par défaut, qui est /var/osquery/osquery.db.
  • verbose : lorsque la journalisation est activée, cette option est utilisée pour activer ou désactiver les messages d'information détaillés. Nous allons le régler sur false.
  • worker_threads : nombre de threads de répartition du travail utilisés pour traiter les requêtes. Ceci est défini sur 2 par défaut, 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 que cela soit activé, donc la valeur ici sera false.
  • disable_audit : utilisé pour désactiver la réception d'événements du sous-système d'audit du système d'exploitation. Nous avons besoin qu'il soit activé, donc la valeur utilisée ici sera false.
  • audit_allow_config : autorise l'éditeur d'audit à modifier la configuration d'audit. La valeur par défaut est true.
  • audit_allow_sockets : cela permet à l'éditeur d'audit d'installer des règles liées 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, cela permet de déterminer facilement de quel serveur provient une entrée de journal particulière. La valeur est soit hostname ou uuid. Par défaut, il est défini sur hostname, nous utiliserons donc cette valeur.
  • enable_syslog : pour qu'osquery consomme les informations syslog, il doit être défini sur true.
  • schedule_default_interval : lorsque l'intervalle d'une requête planifié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. Gardez simplement le bon format. Si vous ne le faites pas, le fichier échouera à la validation. Par exemple, pour ajouter quelques requêtes supplémentaires, ajoutez ces lignes :

/etc/osquery/osquery.conf

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

Après les requêtes planifiées, vous pouvez ajouter des requêtes spéciales appelées décorateurs, 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 pointer osquery vers une liste de packs contenant des requêtes plus spécifiques. Chaque installation d'osquery est livrée avec un ensemble de packs par défaut situés dans le répertoire /usr/share/osquery/packs. L'un des packs est pour macOS, tandis que les autres sont pour les 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 ouvrante sur la première ligne du fichier. Votre fichier de configuration terminé 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

La sortie 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 corriger.

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 de l'intégrité des fichiers osquery

Garder un œil vigilant sur l'intégrité des fichiers sur votre serveur est un aspect essentiel de la surveillance de la sécurité de son système. À cette fin, osquery offre une solution prête.

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 fichiers dans les répertoires /home, /etc et /tmp toutes les 300 secondes. La configuration complète du fichier 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 rendre le nouveau fichier et ses règles 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

Modifiez ensuite la section packs pour inclure le nouveau fichier :

/etc/osquery/osquery.conf
...

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

Enregistrez et fermez le fichier. Et juste pour être sûr que vous ne vous êtes pas trompé dans le fichier, validez-le à nouveau :

sudo osqueryctl config-check

Commençons maintenant à utiliser osqueryi pour interroger le système.

Étape 5 - Utilisation d'osqueryi pour effectuer des vérifications de sécurité ad hoc

Il existe de nombreux endroits où l'osquerie est utile. Dans cette section, vous allez effectuer divers contrôles 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 en utilisant osqueryi même si le démon n'est pas actif, tout en utilisant le fichier de configuration que nous avons construit pour configurer l'environnement.

Pour lancer osquery avec un fichier de configuration, tapez :

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

Remarque : Transmettre osqueryi et osqueryd l'option verbose est une bonne pratique car elle vous permet de voir les erreurs ou les avertissements qui pourraient indiquer des problèmes avec osquery . Et normalement, osqueryi peut être exécuté sans privilèges root, mais si vous l'appelez en spécifiant le fichier de configuration du démon, vous devez l'exécuter en tant que root.


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

select * from logged_in_users ;

La sortie 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      | root     | pts/0 | 11.11.11.11      | 1483580584 | 1752 |
| user      | sammy    | pts/1 | 11.11.11.11      | 1483580770 | 4057 |
+-----------+----------+-------+------------------+------------+------+

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

La requête précédente vous indique qui est connecté maintenant, mais qu'en est-il des connexions précédentes ? Vous pouvez le savoir en interrogeant la table last, comme ceci :

select * from last ;

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

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 |                  |
| root     | pts/0 | 1752 | 7    | 1483580584 | 11.11.11.11      |
| sammy    | pts/1 | 4057 | 7    | 1483580770 | 11.11.11.11      |
+----------+-------+------+------+------------+------------------+

Le pare-feu est-il configuré et activé ? Le pare-feu fonctionne-t-il toujours ? En cas de doute, exécutez cette requête pour savoir :

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 accessible sur Internet, ce n'est pas une bonne chose, il vaut donc mieux configurer le pare-feu.

Vous pouvez exécuter la commande précédente, modifiée pour filtrer sur 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 ? Les avez-vous programmés ? Cette requête vous aidera à trouver des logiciels malveillants qui ont été programmés pour s'exécuter à des intervalles spécifiques :

select command, path from crontab ;

Et la sortie devrait prendre cette forme. Toute commande qui semble 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 |
+----------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+

Y a-t-il des fichiers sur le système qui sont activés par setuid ? Il y en a plusieurs sur n'importe quel serveur Ubuntu 16.04, mais lesquels sont-ils, et y en a-t-il qui ne sont pas censés être sur le système ? Les réponses à ces questions vous aideront à détecter les binaires dérobés. Exécutez cette requête périodiquement et comparez ses résultats aux résultats plus anciens afin de pouvoir garder un œil sur tout ajout. 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 la liste des modules de noyau chargés, exécutez cette requête :

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

Il s'agit d'une autre requête que vous voudrez exécuter périodiquement et comparer sa sortie avec des résultats plus anciens pour voir si quelque chose a changé.

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

select * from listening_ports ;

Sur un nouveau serveur avec uniquement SSH exécuté 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 n'inclut que les ports sur lesquels vous savez que le serveur doit être à l'écoute, il n'y a rien à craindre. Mais s'il y avait d'autres ports ouverts, vous voudrez rechercher ce que sont ces ports.

Pour examiner l'activité des fichiers sur le serveur, exécutez cette requête :

select target_path, action, uid from file_events ;

La sortie montre toute l'activité récente des fichiers sur le serveur, ainsi que l'ID 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 comme celles que vous pouvez exécuter sur votre serveur pour avoir une idée des problèmes de sécurité possibles.

Si vous n'êtes pas sûr du schéma d'une table, utilisez la commande suivante pour le savoir :

.schema name-of-table

Et vous pouvez lister les tables disponibles avec :

.tables

Il existe de nombreux autres exemples dans les packs livrés avec osquery, 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 - Exécution d'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 que nous avons spécifiés à cette étape et celles du pack FIM que nous avons configuré à l'étape 5. Si vous ne les avez pas encore étudiés, c'est le bon moment pour jeter un coup d'œil au contenu de /usr/share/osquery/packs.

Les résultats générés par osqueryd sont écrits dans un fichier appelé osqueryd.results.log dans le répertoire /var/log/osquery. Hors de la boîte, ce fichier n'existe pas. Il n'est créé que lorsque le démon est démarré et commence à générer des résultats.

Vous pouvez démarrer osqueryd en utilisant 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 continuera à fonctionner sans fichier de configuration, bien qu'il ne fasse rien d'utile.

Mais puisque vous avez déjà configuré un fichier de configuration, il ne vous reste plus qu'à démarrer 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 cela se produire 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 ne dispose pas d'une fonction d'alerte comme 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 CTRL+C pour arrêter de suivre la grume.

À plus long terme, vous souhaiterez 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 ElasticSearch.

Conclusion

osquery est un outil puissant, utile pour exécuter des requêtes ponctuelles et planifiées à l'aide d'une syntaxe SQL familière. osqueryi est le composant osquery pour l'écriture de requêtes ponctuelles, tandis que osqueryd est pour la planification des requêtes. Pour donner un sens aux résultats des requêtes planifiées, vous devez les expédier à une plate-forme d'analyse de journaux externe. Vous pouvez trouver plus d'informations sur osquery sur https://osquery.io/.