Sandbox, AV und Co.: Damit bin ich nun sicher, oder? (Sicherheits-Sammelthread)

[mezzomix]

Alles was in 90% der Fälle nicht mit dem Computer gemacht werden soll, gehört als Programm in die Tonne.

Das dürfte der wichtigste Tip sein.

Also alle Programme / Services weg, die nicht zum Arbeiten benötigt werden. Bei einer Standarddesktopinstallation läuft > 80% Müll, der nie benötigt wird. In vielen Fällen gehört der Virenscanner übrigens ebenfalls in diese Kategorie. Das meiste davon wird ein Standard-User aber leider auch nicht los. Beim Browser sollte man sich überlegen, ob man wirklich jedes verfügbare Plugin benötigt. Und ganz schnell ist man an dem Punkt, wo man sich entscheiden muss: Bequemlichkeit/Spielzeuge oder Sicherheit.

[sQueeZer]

Browserplugins die zum Standard gehoeren sollten:

Adblock, NoScript, Https everywhere.

Grueße

[oda.krell]

[snip]

Wie schon erwartet: kein Beispiel gefunden.

/thread

[flipperfish]

1) Das OS muss NX-Stack, Stack-Canaries und ASLR unterstützen. Weiter oben erwähnte ich Windows Vista/7 mit EMET. Das ist IMHO schon eine recht brauchbare Kombi. Windows XP ist wegen des fehlenden ASLR im Kernel keine Empfehlung mehr. Falls Linux, dann nur mit diesen Features.

Wie sieht es denn damit derzeit bei den gängigen Linux-Distributionen aus? Als ich das letzte mal Nachforschungen zu diesem Thema angestellt habe, war es eher so, dass man noch zusätzliche Kernel-Patches wie "grsecurity", "execshield", etc. für alles, was über das NX-Bit hinausging, benötigte.

[kneim]

Was sagt eigentlich: "scanelf -e <beliebiges Binary>" bei dir?

Die folgende Ausgabe sollte zurückkommen:

TYPE        STK/REL/PTL    FILE
ET_DYN   RW- R-- RW-      <beliebiges Binary>

Darüberhinaus sollte dich auch mal

cat /proc/sys/kernel/randomize_va_space

interessieren.
Als Rückgabe sollte im Idealfall eine 2 kommen.
0 bedeutet, dass es abgeschaltet ist und sollte so nicht eingesetzt werden. Ach, das hatte ich noch nicht erwähnt. Es geht hierbei um die ASLR in Linux per grsecurity.

Gruss
Bill

Die Ausgabe sieht so aus:
$ scanelf -e /bin/bash
TYPE      STK/REL/PTL    FILE
ET_EXEC   RW- R-- RW-    /bin/bash

Auf den Linux-Kernel angewendet, gab es keine Ausgabe.

randomize_va_space ist bei Debian 7.4 auf 2 gesetzt.

Danke für den Hinweis über KVM. Kannte ich noch nicht, sehe ich mir genauer an.

[bill86]

Hey flipperfish,

1) Das OS muss NX-Stack, Stack-Canaries und ASLR unterstützen. Weiter oben erwähnte ich Windows Vista/7 mit EMET. Das ist IMHO schon eine recht brauchbare Kombi. Windows XP ist wegen des fehlenden ASLR im Kernel keine Empfehlung mehr. Falls Linux, dann nur mit diesen Features.

Wie sieht es denn damit derzeit bei den gängigen Linux-Distributionen aus? Als ich das letzte mal Nachforschungen zu diesem Thema angestellt habe, war es eher so, dass man noch zusätzliche Kernel-Patches wie "grsecurity", "execshield", etc. für alles, was über das NX-Bit hinausging, benötigte.

Das gilt IMHO auch weiterhin für ExecShield. Zumindest habe ich es bisher nicht in der Kernelkonfiguration gesehen. Vermutlich muss es gepatcht werden, wenn man kein RedHat, Fedora oder CentOS hat.
Im Standardkernel ist dafür aber PaX vorhanden. Grsecurity muss ebenfalls nicht mehr durch einen separaten Kernelpatch nachgereicht werden.

Standardmäßig scheinen bisher alle aktuellen Linuxdistros (abgesehen von "Damn Vulnerable Linux") ASLR einzusetzen. Wie es dabei mit den restlichen Schutzmaßnahmen aussieht, kann ich nicht beurteilen. Mir fehlt schlicht die Zeit, um mir selbst ein aktuelles Bild davon zu machen.

Das ist einer der Gründe, warum ich hoffe, in diesem Thread vielleicht etwas dazuzulernen.

Gruss
Bill

[bill86]

Hey kneim,

Die Ausgabe sieht so aus:
$ scanelf -e /bin/bash
TYPE      STK/REL/PTL    FILE
ET_EXEC   RW- R-- RW-    /bin/bash

Auf den Linux-Kernel angewendet, gab es keine Ausgabe.

Dass scanelf beim Kernel keine Ausgabe produziert liegt daran, dass es nur die Infos zu ELF-Binärdateien zurückliefert. Der Kernel hingegen ist kein ELF-Binary. Er schafft erst die Bedingungen für das ELF.

Bei der scanelf-Geschichte hatte ich mich undeutlich ausgedrückt. Dafür bitte ich um Nachsicht.

Es kam mir vor Allem auf das fehlende "X" bei "STK" an. Das ist der Hinweis darauf, dass der Stack nicht ausführbar ist.

"ET_EXEC" (Flag für "ausführbare eigenständige Datei") oder "ET_DYN" (Flag für "Shared Object": Mir fällt gerade keine gute Übersetzung dafür ein) sagen für sich genommen nichts über die Schutzmechanismen eines Programms (vgl. man scanelf).

Als ein Test eignet sich da besser ein ldd <Binärdatei> (zweimal ausgeführt).

Ein Beispiel auf meinem Testsystem:

bill@mahoney ~ $ ldd /bin/bash
        linux-vdso.so.1 (0x00007395c4653000)
        libreadline.so.6 => /lib64/libreadline.so.6 (0x00007395c41e6000)
        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007395c3f8c000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007395c3d88000)
        libc.so.6 => /lib64/libc.so.6 (0x00007395c39dd000)
        /lib64/ld-linux-x86-64.so.2 (0x00007395c4433000)
bill@mahoney ~ $ ldd /bin/bash
        linux-vdso.so.1 (0x0000685972062000)
        libreadline.so.6 => /lib64/libreadline.so.6 (0x0000685971bf5000)
        libncurses.so.5 => /lib64/libncurses.so.5 (0x000068597199b000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000685971797000)
        libc.so.6 => /lib64/libc.so.6 (0x00006859713ec000)
        /lib64/ld-linux-x86-64.so.2 (0x0000685971e42000)

Bitte beachte, wie sich die Adressen der eingebundenen Libraries verändern. Das zeigt, dass ASLR bei der /bin/bash tatsächlich greift.

Danke für den Hinweis über KVM. Kannte ich noch nicht, sehe ich mir genauer an.

KVM ist aber nur der Hypervisor. Du brauchst dann noch irgendwas, was das konfiguriert und aufruft. QEmu, AQEmu und LibVirt habe ich schon damit getestet. Eine Rundum-Sorglos-Lösung war keines davon.

Gruss
Bill

[kneim]

Bei mir gibt das Kommando "ldd /bin/bash" laufend andere Adressen aus, bei mir sieht's also gut aus.