Linux auf Sicherheiitslücken testen

[MarkT]

Hallo,

ab und zu lese ich von bekannten Sicherheitslücken unter Linux (z.B. hier) (https://www.pcwelt.de/a/schwere-sicherheitsluecke-bedroht-linux-systeme,3447228) und würde dann gerne testen, ob diese auf meinen Systemen bestehen oder schon gepatcht sind.

Gibt es ein Tool/Programm, mit dem man unterschiedliche Linux-Distributionen auf Probleme testen kann?

Konkret:
Ich benutze derzeit Mint Xfce in einer VM und Debian 7 mit Openmediavault auf einem BananaPi als NAS.
Wie kann ich testen, ob o.g. Sicherheitslücke in den Systemen vorliegt, oder nicht? Wie könnte ich herausfinden, welche Version von systemd auf den Systemen läuft?

[corresponder]

hi,
oftmals gibt es anleitungen, wie du überprüfen kannst, ob dein system "sicher" ist.
das ist von der jeweiligen lücke abhängig, da es welche gibt, wo der angreifer direkten zugriff auf das system nutzt oder
mehrere bugs von der ferne aus dazu führen ein system zu komprimitieren.

die frage ist, wie hängen deine geräte am internet, wenn sie daran hängen,
was erlaubst du an kommunikation (raus/rein) - etc. pp.

wichtig ist vor allem, dein system immer auf dem aktuellen stand zu halten.
per apt-get upgrade, z.b.

gruss

c.

[florian0285]

Es gibt Tools wie z. B. OpenVAS oder Nessus, aber auch teils Nmap (NSE - Script Engine) kann das. Stichwort Vulnerability-Scanner und dann danach googeln.

Die Ergebnisse dieser Tools sind aber nie 100%ig.

Zusätzlich bekommt so gut wie jede Lücke eine Art ID. In deinem Beispiel CVE-2017-9445 und im Artikel wird auch entsprechend verlinkt:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9445

Dort findest du allgemeine Informationen zur Lücke und weiterführende Informationen.
Eigentlich immer die Links zu den Entdeckern mit der technischen Beschreibung und meistens auch noch nen Link zu z. B. securityfocus.com o. ä.

http://www.securityfocus.com/bid/99302/info

Dort findest du gleich unter "Info" die betroffenen Versionen



systemd systemd 233
systemd systemd 229
systemd systemd 228
systemd systemd 214
systemd systemd 213
systemd systemd 209
systemd systemd 208
systemd systemd 207


Dann machst du je nach System ne überprüfung ob du entsprechende Version installiert hast und kannst das dann bei deiner Distribution oder über deinen Package-Manager und den Relase-Notes abgleichen ob die CVE-xy mit dem Update gestopft wurde.



rpm -qa | grep systemd
systemd-231-17.fc25.x86_64


Für dieses Paket findest du bei Fedora z. B. die Info



A fix for an out-of-bounds write in systemd-resolved after a crafted DNS packet (CVE-2017-9445).

No need to reboot or log out.


https://bodhi.fedoraproject.org/updates/FEDORA-2017-72f0c1ea9c

Also die entsprechende CVE wurde hier gestopft.

Das darfst du theoretisch mit jedem betroffenen Paket machen.

[MarkT]

Erstmal vielen Dank für die ausführlichen Antworten.
Wenn ich das richtig sehe, dann ist eine Überprüfung nicht "mal eben" erledigt und erfordert zumindest ein paar Kenntnisse des Betriebssystems.

Ich habe es gerade mit "rpm -qa | grep systemd" unter Mint Xfce und Debian 7 probiert, erhalte aber nur Fehlermeldungen.

Debian7:

-bash: rpm: Kommando nicht gefunden.
root@BaPi:~#

Mint:

tester-VBox ~ $ rpm -qa | grep systemd
Die Anwendung »rpm« ist momentan nicht installiert. Sie können sie durch folgende Eingabe installieren:
sudo apt install rpm


Eine kurze Internetrecherche ergibt, dass rpm parallel zu dpkg nicht empfohlen wird. Besonders auf dem BananaPi (NAS) würde ich gerne möglichst wenig Kram installieren. Könnt ihr mir einen Tipp geben, wie ich die Versionsnummer von systemd mit Standardmitteln herausbekomme?


@corresponder
Ich habe beide Systeme bzgl. der Internetzugriffsberechtigungen nicht besonders konfiguriert. Nachdem ich den lokalen Proxyserver bekanntgegeben hatte, konnten beide auf das Internet zugreifen. Beim NAS habe ich noch SSH und Samba freigegeben. Ob ein Zugriff aus dem Internet auf die Geräte möglich wäre, weiß ich leider nicht. Mir fehlt die Zeit mich damit mal intensiver zu beschäftigen.
apt-get update, apt-get upgrade und apt-get dist-upgrade lasse ich eigentlich immer durchlaufen, wenn ich auf ein System zugreife, also mind. einmal pro Woche. Allerdings habe ich kein Gefühl dafür, wie gut der Support für Debian7, speziell für Openmediavault ist, weshalb ich zumindest in der Anfangszeit bei bekannten Lücken gerne nachsehen würde, ob, und wie schnell die Lücken dort geschlossen werden.




EDIT:
Ich bin auf "journalctl" gestoßen und habe in Mint18 folgende Ausgabe erhalten:


fcetester-VBox xfcetester # journalctl | grep systemd
Jul 02 14:57:57 xfcetester-VBox systemd-journald[272]: Runtime journal (/run/log/journal/) is 632.0K, max 4.9M, 4.3M free.
Jul 02 14:57:57 xfcetester-VBox kernel: random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
Jul 02 14:57:57 xfcetester-VBox kernel: random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
Jul 02 14:57:57 xfcetester-VBox kernel: random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
Jul 02 14:57:57 xfcetester-VBox systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
...

Sehe ich das richtig, dass hier die Version 229 von systemd läuft und mein Linux damit noch von der aktuellen Lücke betroffen ist?


Auf dem NAS mit Debian 7 funktioniert journalctl nicht. Dafür MUSS :) es doch eine gängige Alternative geben.

[karl-heinz-lnx]

Mint bzw. Debian (auch Ubuntu) benutzt als Paketverwaltungstool das Advanced Packaging Tool (APT), siehe auch https://de.wikipedia.org/wiki/Advanced_Packaging_Tool. Fedora benutzt den RPM Package Manager, siehe auch https://de.wikipedia.org/wiki/RPM_Package_Manager.
Florian hat in seinem Post den Befehl für Fedora bzgl. der Paketverwaltung beschrieben.

[corresponder]

natürlich kannst du auch mit werkzeugen wie netstat (netstat -an |grep LISTEN)
schauen, auf welche ports das jeweilige system lauscht und diese dann über die dienste
systemd oder früher xinit ab- bzw. einschalten.

das thema firewall solltest eventuell ein bisschen anschaun,
da kannst du einfach einstellen, was überhaupt von aussen zugreifen darf.

gruss

c.

[florian0285]

Ha ja jedes System hat seine "eigene" Paketverwaltung. Vielleicht kam das unklar rüber.

Dazu hast du ja schon den Link zu apt bekommen und sonst ginge es auch mit dpkg



dpkg --list | grep systemd


Wenn du hinter nem Router hängst dürfte "von Werk" aus kein direkter Zugriff von außen möglich sein.

[marce]

zumindest solange er kein WLAN, Bluetooth, IR und ähnliches aktiviert hat.

Ansonsten - installier einfach brav immer die Updates, die die Distribution Dir zur Verfügung stellt. Wenn Du sehr motiviert bist ließt Du parallel die Changelogs und ReleasNotes der Patches der Distribution. Alles darüber hinaus ist für Otto-Normal-User eh nicht handlebar. Und auch nicht notwendig.

[MarkT]

So viele Baustellen und so wenig Zeit...
Ich benutze noch XP als Hauptsystem, würde aber gerne auf Linux umsteigen, weshalb mich eigentlich alles interessiert, was hier erwähnt wurde. Um mich aber nicht zu verzetteln, will ich mich im Moment auf das Wesentliche beschränken:
1. wie teste ich meine Debian-Systeme auf die aktuell bekannte Sicherheitslücke "SambaCry"?
2. Wie prüfe ich grundsätzlich meine Debian-Linuxe auf bekannte Lücken?

"dpkg --list | grep systemd" ist wohl das, was ich aktuell brauche. Das ergibt auf Mint 18 (sorry, nicht 17, wie ich oben schrieb):


xfcetester-VBox xfcetester # dpkg --list | grep systemd
ii libpam-systemd:i386 229-4ubuntu17 i386 system and service manager - PAM module
ii libsystemd-daemon0:i386 204-5ubuntu20.15linuxmint1 i386 systemd utility library
ii libsystemd-login0:i386 204-5ubuntu20.15linuxmint1 i386 systemd login utility library
ii libsystemd0:i386 229-4ubuntu17 i386 systemd utility library
ii systemd 229-4ubuntu17 i386 system and service manager
rc systemd-services 204-5ubuntu20.15linuxmint1 i386 systemd runtime services
ii systemd-shim 9-1bzr4ubuntu1 i386 shim for systemd
ii systemd-sysv 229-4ubuntu17 i386 system and service manager - SysV links


Auf dem BananaPi:


Pi:~# dpkg --list | grep systemd
ii libsystemd-login0:armhf 44-11+deb7u5 armhf systemd login utility library


Mit der Ausgabe auf dem BananaPi kann ich bzgl. meiner Suche nichts anfangen.
Mein Mint scheint die Sicherheitslücke noch zu enthalten, obwohl ich die aktuellsten Updates installiert habe. Damit hätte ich jetzt nicht gerechnet. Ist die Sicherheitslücke weit weniger dramatisch, als sie in einigen Medien dargestellt wird, oder ist es nicht möglich, die Lücke schneller zu schließen, oder ist Mint einfach eine weniger sichere Distribution?

[marce]

wie kommst du darauf, bei Mint wäre die Lücke noch enthaten?

[nopes]

Ich denke mal einen Schritt zurücktreten und mal das hier lesen (auch wenn es eigentlich dein zweites Anliegen war) und vor allem verstehen, warum die was machen/vorschlagen; ist auch gar nicht so schrecklich lang - https://www.debian.org/doc/manuals/securing-debian-howto/index.de.html
Die erste Frage wird hier beantwortet: https://heise.de/-3726053 - dh um das in Linux zu können, musst die dich mit der Anwendung nmap befassen

[Sauerland1]

Hier bei openSUSE:

rpm -qa --changelog samba | grep -iB3 CVE-2017-7494
* Mi Mai 24 2017 nopower@suse.com
- Fix authenticated remote code execution bug;
CVE-2017-7494; (bso#12780); (bsc#1038231).

Sollte mit apt/dpkg doch auch funktionieren.....

[florian0285]

So ergänzend möchte ich auch noch erwähnen, dass die Versionen der betroffenen Systeme auch nicht 100%ig sind sondern das wozu man lust und Zeit hatte zu testen oder was eben bekannt ist.

Wenn du die gleiche Version auf deinem System findest kann dennoch bereits der Patch enthalten sein. Deswegen ändert sich die Versionsnummer nicht zwingend. Deshalb Changelogs lesen.



ap-get changelog systemd


Mit dpkg ist der Befehl etwas "unhandlicher" daher lass ich das mal.

Für Mint/*buntu gebe es noch hübsch den CVE Tracker auf:
http://bugs.launchpad.net/bugs/cve

So etwas ähnliches solltest du als Newsletter, Blog, Mailinglist wie auch immer bei anderen Distributionen vorfinden. Das dürfte für dich die beste Variante sein. Die Liste und einfach fleißig updaten...