So richten Sie osquery ein, um Sicherheitsbedrohungen auf Ubuntu zu überwachen

OSQUERY ist ein von Facebook entwickeltes Open-Source-Tool zum Abfragen verschiedener Informationen zum Zustand Ihrer Maschinen, wie z Überwachung effizient und intuitiv. OSQUERY macht ein Betriebssystem als leistungsstarke virtuelle relationale Datenbank verfügbar, mit der Sie SQL-Abfragen schreiben können, um Betriebssystemdaten zu untersuchen und die Endpunkte (Windows, OS X, Linux und FreeBSD) abzufragen, um verschiedene Arten von Bedrohungen zu identifizieren, zu untersuchen und zu beseitigen . OSQUERY unterscheidet sich von traditionellem HIDS/IPS. Hier müssen Sie herausfinden, welche Daten in der Tabelle für Abfragen vorhanden sind, und Abfragen basierend auf diesen Daten entwerfen. Außerdem verfügt es über integrierte Funktionen zur Überwachung der Dateiintegrität, zur Prüfung von Netzwerkverbindungen und -prozessen und sogar zur Protokollierung von Änderungen an Hardwaregeräten in Echtzeit. In diesem Artikel werden wir OSQUERY in Ubuntu 16 installieren und seine Verwendung durch osqueryi und osqueryd überprüfen.

1. Installieren Sie OSQUERY

Fügen Sie OSQUERY-Repository-Informationen zur apt-Datenbank hinzu und aktualisieren Sie das System.

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

Um add-apt-repository zu verwenden, müssen Sie Python-Softwareeigenschaften installieren.

 # sudo apt-get install software-properties-common python-software-properties

Repository-Daten zu apt-database hinzufügen

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

Aktualisieren Sie das System und installieren Sie OSQUERY

 # sudo apt-get update
 # sudo apt-get install osquery

Sie können OSQUERY entweder über die interaktive Shell oder als Daemon-Modus ausführen. Lassen Sie uns zuerst untersuchen, wie es über die OSQUERY-Shell-Schnittstelle verwendet wird, und danach werden wir den Daemon-Modus überprüfen. Um die Osquery-Shell zu erhalten, geben Sie osqueryi in das Terminal ein, um die standardmäßig verfügbaren Osquery-Tabellen abzufragen.

 # osqueryi
 osquery>

Führen Sie die folgende Abfrage aus, um alle angemeldeten Benutzer im System aufzulisten.

 osquery> select * from logged_in_users ;

Finden Sie alle für die Abfrage verfügbaren Tabellen.

 osquery> .tables

Um das Schema einer Tabelle zu beschreiben, führen Sie den folgenden Befehl aus.

 osquery> .schema table-name

Beenden Sie die Shell

 osquery> .exit

Sie können OSQUERY auch ausführen, indem Sie Befehlszeilen-Flags übergeben. zB

 # osqueryi --disable_events=false --worker_threads=2  --logger_plugin=filesystem --pidfile=/var/osquery/osquery.pidfile

Um mehr Befehlszeilen-Flags zu erfahren, die für die interaktive OSQUERY-Shell verfügbar sind, führen Sie den folgenden Befehl vom Terminal aus.

 # osqueryi --help

Wir werden weitere Abfragen in einem separaten Abschnitt untersuchen, aber lassen Sie uns jetzt OSQUERY konfigurieren.

2. OSQUERY konfigurieren

Es ist einfacher, OSQUERY mit einer Konfigurationsdatei auszuführen. Anstatt viele Befehlszeilenparameter zum Ausführen der interaktiven osquery-Shell zu übergeben, können diese Parameter in die osquery-Konfigurationsdatei geschrieben werden. Die interaktive OSQUERY-Shell (osqueryi) liest diese Parameter, wenn Sie osqueryi ausführen. OSQUERY enthält keine Konfigurationsdatei. Stattdessen gibt es eine Beispielkonfigurationsdatei ( /usr/share/osquery/osquery.example.conf ), die Sie kopieren können. Es sucht nach der Konfigurationsdatei in /etc/osquery/osquery.conf . Wenn die Konfigurationsdatei nicht vorhanden ist, wird osqueryi mit Standardoptionen ausgeführt. Außerdem ist die Konfigurationsdatei für den OSQUERY-Daemon verfügbar.

Die OSQUERY-Konfigurationsdatei enthält die folgenden drei Abschnitte.

→ Eine Liste von Optionen und Einstellungen, die sowohl von osqueryi als auch von osquery daemon ( osqueryd ) gelesen werden
→ Abfragezeitplan:Der Satz von SQL-Abfragen und -Intervallen.
→ Eine Liste von Paketen, die spezifischere/zielgerichtetere Abfragen enthalten. B. File Change Monitoring Pack:Kategorien und Pfade der überwachten Dateien und Verzeichnisse

2.1 Optionen und Einstellungen

Die vollständige Liste der Optionen und Einstellungen finden Sie in diesem Wiki. Die Optionen und Einstellungen, die für diesen Artikel verwendet werden, werden unten beschrieben.

config_plugin: Name des Konfigurations-Plugins. Die Art des Konfigurationsabrufs, das standardmäßige Dateisystem-Plug-in liest eine Konfigurations-JSON von der Festplatte.

logger_plugin: Logger-Plugin-Name. Der Standard-Logger ist filesystem. Dadurch werden die verschiedenen Protokolltypen als JSON in bestimmte Dateipfade geschrieben. Mehrere Logger-Plugins können gleichzeitig verwendet werden, wodurch Protokolle effektiv auf jede Schnittstelle kopiert werden. Trennen Sie Plugin-Namen mit einem Komma, wenn Sie die Konfiguration angeben (--logger_plugin=filesystem,syslog).

logger_path: Verzeichnispfad für ERROR/WARN/INFO und Ergebnisprotokollierung.

disable_logging: Deaktivieren Sie ERROR/WARNING/INFO (als Statusprotokolle bezeichnet) und die Protokollierung von Abfrageergebnissen.

schedule_splay_percent: Prozent zu spreizen Konfigurationszeiten. Der Abfragezeitplan enthält häufig mehrere Abfragen mit demselben Intervall. Es ist oft nicht die Absicht des Zeitplanautors, diese Abfragen in diesem Intervall zusammen auszuführen. Stattdessen sollte jede Abfrage ungefähr in diesem Intervall ausgeführt werden. Beim Laden der Konfiguration wird auf jede Abfrage eine standardmäßige Zeitplanspreizung von 10 % angewendet.

PID-Datei: Pfad zum Daemon-PIDfile-Mutex. Die Datei wird verwendet, um zu verhindern, dass mehrere osqueryd-Prozesse gestartet werden.

events_expiry: Zeitüberschreitung zum Ablaufen von Ereignisveröffentlichungs-Abonnementergebnissen aus dem Sicherungsspeicher. Dieser Ablauf wird nur angewendet, wenn Ergebnisse abgefragt werden. Wenn beispielsweise --events_expiry=1 ist, dann existieren praktisch nur Ereignisse für eine einzelne Auswahl des Abonnenten. Wenn keine Auswahl erfolgt, werden die Ereignisse auf unbestimmte Zeit im Sicherungsspeicher gespeichert.

Datenbankpfad: Wenn Sie einen plattenbasierten Sicherungsspeicher verwenden, geben Sie einen Pfad an. osquery behält den Status unter Verwendung eines "Sicherungsspeichers" standardmäßig bei, der RocksDB verwendet. Dieser Zustand enthält Ereignisinformationen, so dass sie später gemäß einem Zeitplan abgefragt werden können. Es enthält die Ergebnisse der letzten Abfrage für jede Abfrage innerhalb des Zeitplans. Dieses zuletzt abgefragte Ergebnis ermöglicht eine differenzielle Abfrageprotokollierung.

ausführlich: Ausführliche Informationsmeldungen aktivieren.

worker_threads: Anzahl der Arbeitsdispatch-Threads, die zum Verarbeiten von Abfragen verwendet werden.

enable_monitor: Wird verwendet, um die Zeitplanüberwachung zu aktivieren oder zu deaktivieren.

disable_events: Deaktivieren Sie osquery-Betriebssystemereignis-Veröffentlichungs-Abonnement-APIs. Dadurch werden implizit mehrere Tabellen deaktiviert, die Berichte basierend auf protokollierten Ereignissen erstellen.

disable_audit: Wird verwendet, um den Empfang von Ereignissen vom Audit-Subsystem des Betriebssystems zu deaktivieren.

audit_allow_config: Erlauben Sie dem Audit-Publisher, die Auditing-Konfiguration zu ändern

host_identifier: Feld zur Identifizierung des Hosts, auf dem Osquery ausgeführt wird:Hostname, UUID, flüchtig, Instanz.

enable_syslog: Aktivieren Sie den Herausgeber des Syslog-Erfassungsereignisses. Dies ist eine 'explizite' Aktivierung, weil es eine externe Konfiguration von rsyslog oder syslog-ng erfordert.

audit_allow_sockets: Dadurch kann der Prüfherausgeber Socket-bezogene Regeln installieren.

schedule_default_interval: Legen Sie optional den Standardintervallwert fest. Dies wird verwendet, wenn Sie eine Abfrage planen, die kein Intervall definiert.

# 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 Abfrageplan

Der Zeitplanabschnitt enthält Abfragen, die durch einen eindeutigen Schlüssel gekennzeichnet sind, gefolgt von dem Intervall, das die Abfragehäufigkeit in Sekunden angibt. Die Konfiguration für den Zeitplanabschnitt, den wir verwenden werden, sieht wie folgt aus-

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

Die erste Abfrage schaut alle 300 Sekunden in die Crontab-Tabelle und die zweite Abfrage schnüffelt geladene Kernel-Erweiterungen alle 10 Sekunden. Die Ergebnisse der Abfrage werden mithilfe von RocksDB auf der Festplatte zwischengespeichert. Beim ersten Abfragelauf werden alle Ergebnisse in RocksDB gespeichert. Bei nachfolgenden Läufen werden nur Ergebnissatzunterschiede (Änderungen) in RocksDB protokolliert.

Weitere spezielle Abfragen, sogenannte Decorators, werden verwendet, um Daten anderen geplanten Abfragen voranzustellen. Die folgenden Decorators stellen die UUID des Hosts, auf dem osquery läuft, und den Benutzernamen des Benutzers jeder geplanten Abfrage voran.

..........
..........
"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 Abfragepakete

Die Konfiguration unterstützt Sätze, sogenannte Packs, von Abfragen, mit denen Sie Ihren Zeitplan definieren können. Packungen werden mit Osquery verteilt und basierend auf breiten Kategorien von Informationen und Sichtbarkeit gekennzeichnet. Beispielsweise enthält ein "Compliance"-Paket Abfragen, die nach Änderungen in gesperrten Betriebssystemfunktionen und Benutzereinstellungen suchen. Ein "Vulnerability Management"-Paket kann allgemeine Asset-Management-Abfragen ausführen, die Ereignisprotokolle um Paket- und Softwareinstallationsänderungen erstellen. Der Standardsatz von Paketen im Ordner /usr/share/osquery/packs. Fügen Sie diese Pakete der Konfigurationsdatei hinzu.

..........
..........
"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 Erstellen Sie ein benutzerdefiniertes Paket zur Überwachung der Dateiintegrität

Die Packs, die wir im vorherigen Abschnitt hinzugefügt haben, werden sofort versandt. Jetzt wollen wir unser eigenes Paket hinzufügen, dessen Aufgabe es ist, die Dateiintegrität für die über file_paths konfigurierten Ordner zu überwachen. Erstellen Sie eine Datei mit dem Namen fims.conf in /usr/share/osquery/packs/ und fügen Sie den folgenden Abschnitt hinzu.

# 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/%%"
    ]
  }
}

Die file_events-Abfrage ist so geplant, dass sie alle FIM-Ereignisse erfasst, die für beliebige Dateien innerhalb der durch file_paths angegebenen Pfade in einem Fünf-Minuten-Intervall aufgetreten sind. Auf hoher Ebene bedeutet dies, dass Ereignisse innerhalb von osquery gepuffert und alle fünf Minuten an den konfigurierten Logger gesendet werden.

Ändern Sie den Abschnitt packs in osquery.conf, um die obige Datei einzuschließen.

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

Die endgültige OSQUERY-Konfigurationsdatei sieht folgendermaßen aus:

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

Überprüfen Sie die Gültigkeit der Konfigurationsdatei.

# sudo osqueryctl config-check

Führen Sie die interaktive OSQUERY-Shell im ausführlichen Modus aus.

# osqueryi --verbose

3. OSQUERY konfigurieren, um Syslog-ng-Protokolle zu verwenden

In diesem Schritt werden wir OSQUERY so konfigurieren, dass Syslogs verwendet werden. Ubuntu hat eine standardmäßige rsyslog-Anwendung, die Syslogs generiert, aber in diesem Artikel werden wir herausfinden, wie man syslog-ng so konfiguriert, dass die von ihm generierten Protokolle von OSQUERY verwendet werden. Die Syslog-Tabelle von OSQUERY fragt Protokolle ab, die über eine benannte Pipe von einem ordnungsgemäß konfigurierten syslog-ng-Daemon weitergeleitet werden. Wenn Syslog in Osquery aufgenommen wird, wird es in den Sicherungsspeicher (RocksDB) geschrieben und für Abfragen verfügbar gemacht. Daher erstellt die syslog-ng-Konfiguration eine benannte Pipe, durch die OSQUERY die Protokolle verarbeitet.

Installieren Sie syslog-ng

 # sudo apt-get install syslog-ng

Ändern Sie die Gruppe der von syslog-ng erstellten Dateien in syslog. Bearbeiten Sie die Hauptkonfigurationsdatei von syslog-ng und ändern Sie die Gruppe in 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); }; ......................... .........................

Erstellen Sie als Nächstes die syslog-ng-Konfiguration für OSQUERY. Der folgende Abschnitt zeigt, wie Sie syslog-ng für Systemprotokolle konfigurieren und diese Protokolle im CSV-Format umschreiben. Dann wird eine Vorlage verwendet, um die Nachricht/das Protokoll so zu formatieren, dass die Protokollfelder mit der Syslog-Tabelle von OSQUERY übereinstimmen. Schließlich werden die Protokolle an die benannte Pipe geschoben, damit OSQUERY sie verarbeiten kann. Berechtigungen für die Pipe müssen mindestens syslog-ng zum Lesen/Schreiben und osquery zum Lesen erlauben.

 # 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);
 };

Die osquery-Konfigurationsdatei ( /etc/osquery/osquery.conf ), die wir zuvor erstellt haben, benötigt eine kleine Anpassung für syslog-ng. Ändern Sie logger_plugin in syslog vom Dateisystem oder behalten Sie beide bei.

 "logger_plugin": "syslog" or  "logger_plugin": "filesystem,syslog"

Die folgenden Optionen werden auch für die Aufnahme von Syslog benötigt.

 .................
 .................
 "enable_syslog": "true",
 "syslog_pipe_path": "/var/osquery/syslog_pipe",
 "disable_events": "false",
 .................
 .................

Daher müssen wir nur die logger_plugin-Optionen in der /etc/osquery/osquery.conf bearbeiten, die wir zuvor erstellt haben, und die restlichen drei Optionen sind bereits in der Konfigurationsdatei vorhanden.

Starten Sie nun syslog-ng neu und überprüfen Sie, ob die Pipe mit den richtigen Berechtigungen erstellt wurde.

# sudo systemctl start syslog-ng

# ls -l /var/osquery/syslog_pipe
prw-r----- 1 root adm 0 Apr 27 14:29 /var/osquery/syslog_pipe

Prüfen Sie die Holzscheite, die durch das Rohr fließen

 # 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"
 ...................................
 ...................................

Starten Sie die interaktive OSQUERY-Shell.

# 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>

Fragen Sie nun die Syslog-Tabelle ab.

osqueryi> select * from syslog;

Die obige Abfrage zeigt die von osquery verbrauchten Syslogs über die benannte Pipe /var/osquery/syslog_pipe

an

4. Bedrohungserkennung und DFIR durch OSQUERYi

In diesem Abschnitt werden wir einige grundlegende Sicherheitsprüfungen durch die interaktive osquery-Shell untersuchen.

a) Führen Sie die folgende Abfrage aus, um herauszufinden, wer die angemeldeten Benutzer im System sind.

osquery> select * from logged_in_users ;

b) Finden Sie alle vorherigen Anmeldungen

osquery> select * from last ;

c) Um die Firewall-Regeln zu finden, führen Sie die folgende Abfrage aus. Wenn die folgende Abfrage keine Ausgabe liefert, ist die Firewall nicht konfiguriert.

osquery> select * from iptables ;

d) Führen Sie die folgende Abfrage aus, um alle von crontab geplanten Jobs zu finden. Mit dieser Abfrage können Sie feststellen, ob Malware vorhanden ist, die in bestimmten Intervallen ausgeführt werden soll.

osquery> select command, path from crontab ;

e) Finden Sie die Dateien, die setuid-fähig sind. Standardmäßig sind in Ubuntu 16 nur wenige Dateien setuid-fähig, aber abgesehen davon, welche anderen Dateien sind setuid-fähig. Dies hilft bei der Erkennung von Backdoor-Binärdateien.

osquery> select * from suid_bin ;

f) Finden Sie die Liste der geladenen Kernel-Module.

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

g) Suchen Sie alle Listening-Ports, um zu prüfen, ob es eine Hintertür zum System gibt. Wenn es einen offenen Port gibt, den Sie nicht konfiguriert haben, müssen Sie möglicherweise den Prozess untersuchen, der diesen Port geöffnet hat.

osquery> select * from listening_ports ;

h) Suchen Sie die Dateiaktivität auf dem Server zusammen mit dem verantwortlichen Benutzer, indem Sie die folgende Abfrage ausführen.

osquery> select * from  file_events ;

i) Finden Sie die 10 größten Prozesse nach Größe des residenten Speichers.

osquery> select pid, name, uid, resident_size from processes order by resident_size desc limit 10;

j) Finden Sie alle laufenden Prozesse.

osquery> select * from processes;

k) Finden Sie die Prozessanzahl, Namen für die 10 aktivsten Prozesse.

osquery> select count(pid) as total, name from processes group by name order by total desc limit 10;

l) Im Allgemeinen hört Malware die Ports ab und leitet die Reverse-Shell an den Angreifer weiter. Führen Sie die folgende Abfrage aus und finden Sie die Unterschiede zu allen früheren bekannten sicheren Zuständen Ihres Systems.

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) Häufig löschen Angreifer die bösartige Binärdatei, nachdem sie im System ausgeführt wurde. Um solche Prozesse zu finden, führen Sie die folgende Abfrage aus.

osquery>  SELECT name, path, pid FROM processes WHERE on_disk = 0;

n) Führen Sie die folgende Abfrage aus, um herauszufinden, ob es eine Bash-Reverse-Shell gibt, die an den Angreifer weitergeleitet wird.

osquery> SELECT * FROM processes WHERE cmdline LIKE '/bin/bash -i >& /dev/tcp/%';

5. OSQUERY im Daemon-Modus

Wie wir gesehen haben, gibt OSQUERY Ergebnisse des Betriebssystemstatus in Echtzeit zurück, die zu einem späteren Zeitpunkt abgefragt werden können. Es ist jedoch nicht möglich, ständig Abfragen zur Erkennung von Bedrohungen auszuführen. Abgesehen davon enthält OSQUERY auch keinen Alerting-Mechanismus. Die Lösung besteht darin, OSQUERY als Daemon auszuführen, der geplante Abfragen und in der Konfigurationsdatei enthaltene Pakete in regelmäßigen Abständen ausführt und die Ergebnisse in eine Datei schreibt. Erstellen Sie Ihre eigenen Pakete in /usr/share/osquery/packs und fügen Sie die Pakete zur Überwachung in die OSQUERY-Konfigurationsdatei ein. Die Ergebnisse geplanter Abfragen und Packs werden in die Datei /var/log/osquery/osqueryd.results.log geschrieben. Diese Protokolldatei wird nur erstellt, wenn OSQUERY im Daemon-Modus gestartet wurde und OSQUERYD mit dem Senden der Ergebnisse beginnt. Der OSQUERY-Daemon liest dieselbe Konfigurationsdatei /etc/osquery/osquery.conf. Denken Sie daran, den logger_plugin-Wert auf das Dateisystem in /etc/osquery/osquery.conf zurückzusetzen, wenn Sie ihn zuvor in „syslog“ geändert haben.

Um den Daemon zu starten, verwenden Sie einen der folgenden Befehle.

# sudo systemctl start osqueryd
       OR
# sudo osqueryctl start

Die Ergebnisse sollten innerhalb kurzer Zeit verfügbar sein, sobald OSQUERYD die geplanten Abfragen und Pakete ausführt. Verwenden Sie den tail-Befehl, um zu überprüfen, ob die Ergebnisse in die Datei /var/log/osquery/osqueryd.results.log

geschrieben werden

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

Jetzt können Sie die Ergebnisprotokolle an jede externe Anwendung wie den ELK-Stack zur Protokollanalyse und Alarmgenerierung weiterleiten.

Schlussfolgerung

OSQUERY ist ein großartiges Tool, das Betriebssystemdaten für die virtuelle relationale Datenbank verfügbar macht und es Ihnen ermöglicht, die Systemdaten mit SQL abzufragen. osqueryi ist nützlich, um einmalige Abfragen auszuführen, um Backdoors, Malware, Zombie-Prozesse zu finden oder angemeldete Benutzer usw. herauszufinden, während osqueryd zum Ausführen geplanter Abfragen und benutzerdefinierter Pakete zum Speichern von Ergebnissen für die langfristige Speicherung und zur Generierung von Warnungen verwendet werden kann externe Anwendung.