1. Wir bauen eine Burg
Viele Tutorials zum Thema »Linux Hardening« sind nach spätestens einem Jahr wieder veraltet. In den letzten Wochen habe ich mir daher Gedanken gemacht, wie sich die Aktualität auch über einen längeren Zeitraum bewahren lässt. Noch dazu wollte ich keine Linux-Distribution bevorzugen, sondern einen möglichst generischen / allgemeinen Ansatz aufzeigen.
Wie wichtig ein gehärtetes System und das Bewusstsein für Sicherheit geworden ist, zeigen die News-Meldungen der letzten Wochen. Eine Ransomware jagt die nächste und richtet sowohl in der Wirtschaft, als auch im Privatumfeld erheblichen Schaden an. Noch immer liegt der Fokus der Angreifer auf der Windows-Plattform. Das bedeutet jedoch nicht, dass sich Linux-Nutzer jetzt in Sicherheit wiegen sollten.
Im ersten Beitrag der Artikelserie »Linux härten« hatte ich bereits aufgezeigt, weshalb ein »sicheres« System nur mit einem quelloffenen Betriebssystem auf Basis von Linux bzw. Unix möglich ist. An dieser Stelle möchte ich nun anknüpfen und im vorliegenden Beitrag die Basis Systemhärtung eines Linux Systems beschreiben.
- Sicheres Desktop System – Linux härten Teil1
- Linux Systemhärtung Basis – Linux härten Teil2
- AppArmor – Linux härten Teil3
- Firejail – Linux härten Teil4
2. IT-Sicherheit
Joachim Ringelnatz hat einmal über Sicherheit gesagt:
Sicher ist, dass nichts sicher ist. Selbst das nicht.
Dem ist im Grunde genommen nichts hinzuzufügen und lässt sich nach meiner Auffassung eins zu eins auf die Informatik anwenden. Allerdings möchte ich den Satz noch um meine Perspektive für Sicherheit in der IT ergänzen – abseits irgendwelcher Definitionen die jeder bei Wikipedia nachlesen kann.
Hilf mit die Spendenziele zu erreichen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Das fehlende Verständnis für IT-Sicherheit
Obwohl wir bereits im Jahre 2016 leben, glauben noch immer viele Entscheider im Unternehmensumfeld, dass hochgerüstete Firewalls (UTM-Appliances) und der flächendeckende Einsatz von Virenscannern ausreichend Schutz bieten. Diese altbewährten Maßnahmen sind heute sicherlich nicht verkehrt (Virenscanner vielleicht ausgenommen), greifen allerdings viel zu kurz und berücksichtigen nicht annähernd das aktuelle und sich stetig wandelnde Gefahrenpotenzial.
Durch die voranschreitende Vernetzung müssen alle sicherheitsrelevanten Bereiche berücksichtigt werden. Anhand einer »Sicherheitskette« lässt sich das anschaulich verdeutlichen:
Es gilt: »Eine Kette ist immer nur so stark wie ihr schwächstes Glied«. Angriffe bzw. Schwachstellen zielen daher meist auf das schwächste Glied der Kette. Erst eine gesamtheitliche Betrachtung aller sicherheitsrelevanter Bereiche (Glieder) kann zu einem angemessenen Sicherheitsniveau führen. Eine sture Fokussierung auf nur einen oder zwei der Bausteine führt zwangsläufig zu einem IT-Sicherheitsvorfall.
2.2 Level up!
Zunächst sollte sich jeder bewusst machen: IT-Sicherheit ist heute nicht optional, sondern zwingend notwendig. Wer das einmal begriffen hat, wird über Maßnahmen nachdenken, wie er das Risiko für sich und seine Daten in der digitalen Welt minimieren kann. Wer dann auch noch begreift, dass Sicherheit kein statischer Zustand ist, sondern ein ständiger Prozess, der kann sich die Prinzessin schnappen und das nächste Level erkunden.
Habt ihr das erste Level absolviert, seid ihr im Dschungel der IT-Sicherheitsmaßnahmen angekommen. Es bedarf mittlerweile einem Leitfaden, um sich darin überhaupt noch zurecht zu finden. Zu allem Überfluss tummeln sich hier allerlei IT-Dienstleister, die beim Buzzword-Bingo jeden Preis gewinnen würden, aber von nachhaltiger IT-Sicherheit leider keine Ahnung haben. Um dieses Level zu bestehen müsst ihr euch frei machen von Marketing-Plattitüden und die Dinge wieder kritisch hinterfragen. Wie schwer das in der Realität sein kann, zeigt bspw. der Markt für Antiviren-Software.
Nach diesem Ausflug in die Welt der IT-Sicherheit, möchte ich an dieser Stelle den Fokus allerdings wieder auf die Artikelserie lenken. Es wäre an dieser Stelle müßig alle erdenklichen IT-Sicherheitsmaßnahmen zu beleuchten oder weiterhin auf die Scharlatane der IT-Sicherheitsbranche zu schimpfen.
3. Linux Systemhärtung
Mir ist bewusst, dass sich der Schutz der eigenen Daten heute nicht mehr auf den heimischen Rechner beschränkt, sondern aufgrund der Vernetzung und ständigen Herausgabe von Informationen -ob bewusst oder unbewusst- längst auch andere Personen für die Sicherheit der Daten mindestens genauso verantwortlich sind. Im Grunde genommen müssen wir daher an den unterschiedlichsten Stellen tätig werden. Hier zeigt sich auch wieder relativ deutlich: IT-Sicherheit und Datenschutz sind heute untrennbar miteinander verwoben.
Bevor wir jetzt also einsteigen, noch der Hinweis zu ein paar vergangenen Projekten, die nicht minder zum Schutz der persönlichen Daten beitragen:
3.1 IT-Sicherheitskonzepte
Im Prinzip weiß niemand auf der Welt wie man ein Rechnersystem sicher bekommt. Es gibt schlichtweg kein sicheres System. Wir können durch verschiedene Maßnahmen lediglich dafür sorgen, die Wahrscheinlichkeit für einen erfolgreichen Angriff möglichst gering zu halten. In der IT-Sicherheit existieren unterschiedliche Konzepte, um es einem Angreifer möglichst schwierig zu machen. Zwei dieser Konzepte möchte ich kurz anreißen.
- Defense in Depth: Das Konzept ist uralt und wurde praktisch schon im Mittelalter angewendet. Man stelle sich eine Burg vor, die auf einem Hügel steht und die umgeben ist von einem Burggraben mit Wasser. Auf den hohen Mauern stehen die Bogenschützen bereit, während die Zugbrücke von Soldaten bewacht wird. Im Inneren der Burg sind weitere Mauern mit Verteidigungslinien errichtet. Überwinden die Angreifer den Pfeilhagel und anschließend die Burgmauern, so sind sie noch immer nicht am Ziel. Dieses Defense in Depth Konzept lässt sich auf den Schutz eines Rechners oder Netzwerkes übertragen. Mit mehreren Schichten von Abwehrmaßnahmen und einer Diversifikation der Strategien (zwei Firewalls hintereinandergeschaltet macht wenig Sinn) wird das Leben eines Angreifers erschwert.
- Keep it Simple Stupid (KISS): Das KISS-Prinzip lässt sich in den unterschiedlichsten Bereichen anwenden – auch in der IT-Sicherheit. Sicherheitsmechanismen sollten so einfach wie möglich sein – nur weil sie »einfach« sind, bedeutet das im Umkehrschluss nicht, dass sie für einen Angreifer auch einfach zu überwinden sind. Das bedeutet vor allem: Setzt keine Tools oder Maßnahmen ein, die ihr nicht versteht. Es sollte alles nachvollziehbar und überschaubar sein. Denn dann vermeidet ihr Fehler bei der Konfiguration, Bedienung und vereinfacht damit insgesamt die Wartung und Überprüfbarkeit. Und eines möchte ich euch noch mit auf den Weg geben: Finger weg von aufgeblasenen Security-Tools, deren Funktionsbeschreibung bzw. -umfang ganze Bücher füllen. Jede zusätzliche Sicherheitsfunktion in solch einem Tool bedeutet meist eine zusätzliche Schnittstelle, die einem Angreifer als Angriffsvektor dient.
3.2 Grundlegende Tipps
Mit den nachfolgenden Tipps könnt ihr mit relativ wenig Aufwand bereits ein »sicheres« Grundsystem aufbauen. Ihr solltet nämlich wissen: Schon mit einfachen Maßnahmen kann man ein relativ gutes Sicherheitsniveau erreichen – jedenfalls im Vergleich mit den Millionen Desktop-Rechnern weltweit. Luft nach oben ist immer. Dabei ist allerdings auch zu bedenken: Je höher das Sicherheitsniveau von eurem Rechner ist, umso mehr Aufwand müsst ihr reinstecken, um einen kleinen Sicherheitsgewinn zu erzielen.
Leider gibt es keinen Standard, der allgemeingültig beschreiben würde, welche Schritte beim Härten nötig sind. Die folgenden gehören fast immer dazu, auch wenn sie noch so abgedroschen klingen mögen:
- Sicherheit beginnt bereits bei der Installation: Nahezu jede Linux-Distribution bietet euch bei der Installation die Möglichkeit ein minimales Setup zu wählen. Das bedeutet: Es werden nur jene Pakete installiert, die für den Betrieb notwendig sind. Nach der Installation solltet ihr euch im Idealfall im Terminal wiederfinden, von wo ihr dann weitere Pakete nachinstalliert. Insbesondere für Anfänger mag dies eine Hürde darstellen – nehmt sie, denn je weniger Pakete und Abhängigkeiten euer System aufweist, umso geringer fällt die Angriffsfläche aus. Gerade in Bezug auf die IT-Sicherheit gilt: Weniger ist oftmals mehr.
- Verschlüsselung: Ein weiterer Schritt den ihr während der Installation durchführen solltet, ist die Verschlüsselung eurer gesamten Festplatte mit LUKS über LVM.
- Installation weiterer Pakete: Installiert nur jene Software, die ihr für den täglichen Gebrauch auf eurem Desktop-Rechner tatsächlich benötigt. Zum Ausprobieren neuer Software gibt es virtuelle Maschinen.
- Paket-Abhängigkeiten: Vermeidet Software die zu viele Abhängigkeiten zu anderer Software bzw. Bibliotheken aufweist. Je nach Distribution habt ihr Einfluss auf die zusätzlichen Pakete, die von einer Software mitinstalliert wird. Wer unter Debian bspw. die »Recommendations« und »Suggestions« nicht mitinstallieren möchte, der kann bei der Installation folgenden Befehl anhängen:
--no-install-recommends --no-install-suggests
- Updates einspielen: Das regelmäßige Einspielen von Updates ist eine Binsenweisheit, die leider noch immer allzu gerne vernachlässigt wird. Ihr solltet mindestens einmal pro Tag nach neuen Updates Ausschau halten und diese zeitnah einspielen.
- Überflüssige Dienste deaktivieren: Trotz der sorgfältigen Auswahl von Software-Paketen werden hin und wieder Abhängigkeiten installiert, die (Netzwerk-)Dienste bzw. Ports auf dem Rechner öffnen. Begebt euch ins Terminal und prüft mit netstat ab und zu (oder nach der Installation mehrerer Softwarepakete) welche Dienste der Rechner anbietet.
sudo netstat -tulpen
- Sichere Konfiguration von Diensten: Übliche Dienste auf einem Desktop-System sind wohl cups (Drucker) und ntp (Zeitabfrage). Beide Dienste könnt ihr so konfigurieren, damit sie nur auf dem localhost bzw. der IP-Adresse 127.0.0.1 lauschen und für andere Rechner im gleichen Netzwerk somit nicht erreichbar sind. Einige von euch werden vermutlich auch oft mit einer Secure Shell arbeiten – hierfür existiert eine ausführliche Hardening-Anleitung.
- Überflüssige Benutzerkonten deaktivieren: Die lokalen Benutzeraccounts mit Shell-Zugang solltet ihr auf ein Minimum reduzieren. Üblicherweise verfügt euer System über einen Account mit »normalen« Rechten und einen Administrator-Account (root).
- Mit eingeschränkten Rechten arbeiten: Hierbei handelt es sich weniger um eine Hardening-Maßnahme, sondern vielmehr um eine Grundregel bei der Arbeit mit Rechnern. Der Administrator-Account bzw. das Root-Konto ist ausschließlich für besondere Verwaltungsaufgaben (bspw. Installation neuer Software) konzipiert. Ansonsten gilt immer: Arbeiten, surfen, gamen, etc. werden mit dem »normalen« User-Account durchgeführt.
- Firewall konfigurieren: In der Linux-Welt ist eine Desktop-Firewall oftmals verpönt. Insbesondere bei Nutzern, die mit dem Defense in Depth Konzept nicht vertraut sind. Dabei ist eine Firewall eine zusätzliche Schicht bzw. Sicherheitsmaßnahme, die ihr nicht unterschätzen solltet. Hat eine Software bspw. einen zusätzlichen Dienst installiert, der zu allem Überfluss auch noch für andere Rechner im Netzwerk erreichbar ist, bietet ihr einem Angreifer eine unnötigen Angriffsvektor. Mit ein paar Konfigurationszeilen für die Firewall könnt ihr dies schnell und einfach vermeiden und eingehende Verbindungen nur dann zulassen, nachdem zuvor von eurem Rechner eine Verbindung initiiert wurde. Weitere Konfigurationsbeispiele für iptables findet ihr unter anderem im Privacy-Handbuch. Und auch nicht zu vergessen: Wer Google, Facebook und Co. nicht mag, der kann den gesamten IP-Adressbereich »blacklisten« – sozusagen Datenschutz von »innen«.
#!/bin/sh # iptables Firewall Skript echo "Loading Firewall ..." ################## # iptables ################## IPTABLES="/sbin/iptables" ################## # Purge/Flush ################## # Alle Regeln löschen $IPTABLES -F $IPTABLES -t nat -F $IPTABLES -t mangle -F # Alle Regelketten löschen $IPTABLES -X $IPTABLES -t nat -X $IPTABLES -t mangle -X ################## # Regeln ################## # IPv4 Default $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPT # Loopback-Schnittstelle Verkehr erlauben $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT # ICMP-Antwortpakete erlauben $IPTABLES -A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT $IPTABLES -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT $IPTABLES -A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT # Alle Pakete zu einer bestehenden TCP-Verbindung akzeptieren $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Alle Pakete ordentlich zurückweisen $IPTABLES -A INPUT -p tcp -j REJECT --reject-with tcp-reset $IPTABLES -A INPUT -j REJECT --reject-with icmp-port-unreachable echo "................ done!"
- Log Files prüfen: In den meisten Fällen ist dies eine äußert unbeliebte Aufgabe und doch halte ich sie für notwendig. Die zwei bekannten Tools logwatch und logcheck benötigen leider einen installierten E-Mail Dienst zum Versenden der Meldungen und Berichte. Zwangsläufig bedeutet das die Installation unnötiger Software, was ich gerne vermeide. Angesichts der Unmengen als Log-Einträgen sind solche Tools allerdings unverzichtbare Helfer.
4. Lynis
Neben den vorgestellten Basis-Tipps, die sich praktisch auf jedes Linux-System anwenden lassen, gibt es für fast jede Linux-Distribution individuelle Absicherungsmaßnahmen. Da ich hier allerdings einen allgemeinen Ansatz verfolge, der keine Distribution bevorzugt und dessen Aktualität länger als wenige Monate sein sollte, musste ich mir etwas einfallen lassen. Letztendlich habe ich einen praktikablen Ansatz gefunden, der diesem Anspruch gerecht wird. Das Open-Source Tool Lynis unterstützt uns bei der Analyse und Verbesserung der Systemsicherheit. Dazu ermittelt es Informationen zum System, den installierten Paketen und bestehenden Konfigurationen.
Besorgt euch das Tool von der offiziellen Webseite oder kompiliert es selbst aus den GitHub-Quellen. Nach dem Download solltet ihr die SHA256 Checksumme prüfen.
4.1 Anwendung
Die Durchführung eines »Audits« ist denkbar einfach:
lynis audit system --quick
Nach dem Durchlauf werdet ihr mit einem Gesamtergebnis, dem sogenannten »Hardening index«, konfrontiert. Scrollt ihr im Terminal dann etwas weiter nach oben findet ihr vermutlich eine Menge an »Warnings« und »Suggestions«, wie sich euer System absichern lässt.
In den häufigsten Fällen ist unter jeder Meldung ein Link angegeben, wo ihr weitere Informationen finden könnt. Die Interpretation der Ergebnisse ist insbesondere für Neulinge nicht einfach – oftmals ist es schwierig abzuschätzen, wie hoch der tatsächliche Sicherheitsgewinn ist, wenn eine Maßnahme umgesetzt wurde. Mein Vorschlag an euch lautet daher: Zunächst solltet ihr euch den »Warnings« widmen und diese beseitigen. Anschließend begutachtet ihr die »Suggestions«, folgt den Links und schätzt dann für euch selbst ein, ob ihr das jeweils Umsetzen wollt / könnt. Und auch hier gilt: Was ihr nicht versteht, dass lasst ihr bitte so lange unangetastet, bis ihr die notwendigen Informationen beisammen habt.
Hinweis: Lynis muss für eine vollständige Prüfung als root ausgeführt werden.
5. Fazit
Wenn ihr die grundlegenden Tipps befolgt und der Hardening-Index in Lynis an der 80% Grenze anklopft, ist euer Desktop-System »gehärtet«. Mit weiteren Maßnahmen wie Mandatory Access Control oder den Kernel-Modifikationen grsecurity / PaX lässt sich die Sicherheit weiter verbessern. Allerdings kommen wir dann schon in einen Bereich, wo ihr für ein höheres Sicherheitsniveau eures Rechners auch mehr Aufwand reinstecken müsst.
Im kommenden Teil der Serie befassen wir uns dann entweder mit Firejail oder AppArmor. Bis dahin habt ihr sicherlich eine Menge zu tun. ;-)
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
AFWall+: Wie ich persönlich die Android-Firewall nutze
AFWall+: Digitaler Türvorsteher – Take back control! Teil4
F-Droid und AFWall+ – Android ohne Google?! Teil4
Sicheres Desktop System – Linux härten Teil1
ASN-Skript: Datensammler haben ausgeschnüffelt – IPFire Teil3
37 Ergänzungen zu “Linux Systemhärtung Basis – Linux härten Teil2”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Tolle Arbeit Mike! Dieser Artikel ist in Zeiten der hohen Internetkriminalität sowohl für Privatanwender als auch für Unterehmen interessant.
Viele dieser Tipps scheinen auch für andere Plattformen nützlich zu sein.
Kann man einige dieserTipps auch auf Android übertragen?
Kann man sicherlich. Nur möchte ich in diesem Beitrag nicht auf Android eingehen. Dazu gibt es schon genügend Beiträge auf dem Blog. Start wäre hier: Your phone Your data – Android ohne Google?! Teil1
Hallo Mike!
erstmal danke für den Artikel. Hätte bezüglich Lynis noch eine Frage.
Bei den Scan Results in der Fraktion „Kernel Hardening“ habe ich bei manchen sysctl keypairs das Ergebnis „DIFFERENT“, jedoch werden hier bzw in den Suggestions keine weiteren Informationen diesbezüglich gegeben.
Es handelt sich um folgende key pairs:
– kernel.core_uses_pid (exp: 1)
– kernel.kptr_restrict (exp: 1)
– kernel.sysrq (exp: 0)
– net.ipv4.conf.default.log_martians (exp: 1)
Was hat das konkret zu bedeuten. Hoffe du kannst mir diesbezüglich ein paar Tipps bzw Infos geben.
# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid
kernel.kptr_restrict: Erklärung und Umgehung (auf Android)
Das kannst du auf 1 setzen – auch wenn der Sicherheitsgewinn verschwindend gering sein sollte.
# Controls the System Request debugging functionality of the kernel
kernel.sysrq
# Log packets with impossible addresses to kernel log?
net.ipv4.conf.default.log_martians
Wirklich sehr gut gelungen!!
Das Firewallscript speichert man wie im privacy-handbuch beschrieben in „/etc/network/if-up.d“ ab. Wie kontrolliert man denn ob es läuft?
Wo das Firewallscript abgelegt wird, hängt von deiner Distribution ab. Mit dem Befehl
iptables -Lkannst du prüfen, ob die Regeln angewendet wurden.Danke. Bei mir ist if-up.d in „/etc/sysconfig/network/if-up.d“ in dem auch die SuSEfirewall2 liegt(OpenSuse)
Hier steht das man die Datei unter /etc/sysconfig/SuSEfirewall2 bearbeiten soll um zB. einen Port zu öffnen:
https://blog.remibergsma.com/2013/02/12/automating-persistent-iptables-rules-on-red-hat-suse-and-debian/
Kommen die Regeln dort rein, oder sollte es schon ein seperates Script sein?
In einem Kommentar auf der Seite steht, dass man für die Standard iptablesRegeln, die SUSEfirewall ausschalten muss.
Hallo Mike und vielen Dank für den Artikel!
Eine Frage ich habe noch: du hast das Ziel einen aktuellen Artikel zu schreiben, der systemübergreifend (Linux) funktioniert. Für die Server-Wartung meines Debian-Familien-Servers würde ich mich für ein paar Tools / Tipps freuen. Ich denke, dass Debian sehr verbreitet sein sollte!
Die dargestellten Tipps sind für ein Linux Desktop-System. Lassen sich aber ebenso auf ein Server-System anwenden. Bei Server-Systemen sind noch ein paar Zusätze zu beachten, auf die ich im Zusammenhang mit der Artikelserie aber nicht weiter eingehen werde. Der Fokus der Reihe sind Desktop-Systeme.
Vielleicht interessant: OSSEC • Schutz von Linux Servern
Gehört zu der Sicherheitskette nicht auch die Hardware (zB. BIOS)?
Zur oben dargestellten Sicherheitskette nicht, aber zum Defense in Depth-Prinzip schon. Die Hardware hatte ich aber bereits im ersten Beitrag gestreift und werde darauf auch nicht weiter eingehen.
Als Tipps kann ich aber noch anregen:
– BIOS-Passwort setzen
– UEFI nach Möglichkeit deaktivieren
– Unnötige Funktionen abschalten (Wake On Lan, etc.)
– I/O Ports wie Bluetooth oder die integrierte Kamera bereits im BIOS deaktvieren
– In der Boot-Reihenfolge USB oder externe Laufwerke ausschließen
– […]
Hallo Mike
warum sollte man das UEFI deaktivieren?
Bei einem herkömmlichen BIOS kontrollierst du den Rechner, UEFI hingegen kontrolliert dich. »UEFI-Features« wie Secure Boot erschweren zu allem Überfluss auch noch die Installation eines freien Systems wie Linux. Einige der Ansätze in UEFI sind sicherlich gut und richtig, aber ein Rechner-BIOS sollte Open-Source sein und nicht so einen Quatsch wie das UEFI-Codesigning forcieren. Sollte es eure Hardware unterstützen solltet ihr auf coreboot wechseln. Auf einigen neuen Systemen verhindert der Intel Boot Guard allerdings den Austausch des Hersteller-BIOS – solche Hardware bitte direkt boykottieren.
Für eine »substanzvollere Antwort« sei dir die Kritik zu UEFI auf Wikipedia empfohlen.
Hallo Mike!
Danke für die Antwort. Leider gibt es keine halbwegs aktuellen Mainboards die Coreboot unterstützen. Sowohl mein Notebook als auch das Mainboard meines Desktop PCs sind nicht in der leider sehr sehr kurzen Kompatibilitätsliste.
Die Lage bezüglich Open Source Hardware scheint ziemlich aussichtslos. Selbst die Entwicklering von Qubes hat bei ihrem Talk am CCC Kongress bedauernd verkündet, dass ihre Bemühungen bezüglich Qubes quasi aufgrund der Intel Management Engine umsonst waren.
Ist mir bekannt. Daher habe ich bereits im ersten Teil der Serie die Hardwareproblematik angerissen.
Der Artikel ist mir natürlich bekannt ;-)
Wie handhabst du das Ganze persönlich?
Setzt du nur auf alte Thinkpads und alte Mainboards (und somit in Folge auch auf alte CPUs) um Coreboot einsetzen zu können?
Dieser sehr allgemeine Tipp sollte aufgrund seiner großen Bedeutung in der IT-Sicherheit trotzdem betont werden:
Passwörter sollten möglichst lang und kompliziert sein.
Bezüglich eines Brute-Force Angriffs sollte man ein Passwort mit mindestens 8 (oder besser mehr) Zeichen wählen. Bei schlechten Passwörtern würde selbst die beste Verschlüsselung nicht nützen. Generell gilt: Je länger, desto besser.
Ich finde auch als Nicht-Profi diesen Artikel sehr interessant, jedoch stellen sich mir als Laien zwei Fragen.
Die erste, wieso wird in dem Artikel häufig solch ein quasi Sidekick Richtung Antivirensoftware gegeben? Sind diese allgemein „überflüssig“ oder bezieht sich das nur auf Linux?
Meine zweite Frage bezieht sich auf die Konfiguration der Firewall und das gezeigte Beispiel. Wo, wie und in welcher Datei wird dieses gespeichert? Laut Privacy-Handbuch als Script unter „/etc/network/if-up.d“. Ist das hier gezeigte beispiel dann ein zusätzliches script oder als Erweiterung zu sehen?
Sorry für die LAien-Fragen, aber wenn ich mich nciht damit beschäftige, bin ich wohl eins der schwächeren Glieder. :)
1. Sowohl auf Linux, als auch für Android (Antivirus-Apps für Android – Sinnvoll oder nutzlos?) bzw. generell Smartphone-Plattformen halte ich einen Antivirensoftware für verzichtbar. Generell vermitteln Antivirensoftware ein trügerisches Sicherheitsgefühl.
2. Je nach Linux-Distribution ist das anders geregelt. Daher immer noch meine Empfehlung: Direkt für eure Linux-Distribution nachschauen – eine Suchmaschine hilft euch sicherlich dabei. ;-)
Hier ein paar bekannte Distris:
– iptables unter Debian
– iptables unter Arch
– iptables unter Ubuntu
– […]
Wenn man die Platte verschlüsselt, muss man beim Starten des Pc´s/Laptop´s das Passwort eingeben.
Dann ist diese ja nicht mehr verschlüsselt.
Soll das nur vor Angriffen währendes Bootens schützen?
Wenn dein rechner über einen exploit komprimittiert wird, hilft dir die Verschlüsselung auf dem Bootdevice natürlich nichts, jedoch hilft die Verschlüsselung bei physischem Zugriff.
Mit einer Live-CD könnte ohne Verschlüsselung jemand alle deine Daten kopieren und auch Files gegen backdoored Files austauschen.
Es bleibt jedoch eine ünverschlüsselte Boot-Partition über die noch immer eine Evil-maid (Infos hier: https://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html ) durchgeführt werden kann.
Trotzdem ein Sicherheitsgewinn mit kaum Nachteilen.
Vielen Dank für die Erklärung.
Also ist das mehr ein Schutz, vor Einbrechern die physischen Zugriff haben.
Dann sollte man die wichtigen Daten auf eine Externe verschlüsselte Festplatte legen?
Ich habe eine Installationsanleitung fü openSUSE mit minimalen Setup gefunden:
https://l3net.wordpress.com/2013/04/24/lightweight-opensuse-lxde-desktop-from-scratch/comment-page-1/#comment-8224
Ist aber nicht für die neuste suseVersion.
Entweder auf einer externen Platte, die dann natürlich nicht permanent entschlüsselt gemountet werden sollte, oder wichtige Dateien ganz einfach zusätzlich mit einem Dateiverschlüsselungstool wie zB ecryptfs ein weiteres mal verschlüsseln
Meinen sie etwa die Festplattenvollverschlüsselung?
Also z.B. LUKS über LMV?
Hallo,
bei mir funktionieren die parameter „–install-recommends –install-suggests“ unter apt-get nicht richtig. Anstelle weniger pakete zu installieren eskaliert das ganze zB bei der Installation von conky, wo er mit den parametern plötzlich 1600 pakete installieren möchte.
Ich verwende anstelle dessen folgendes in der /etc/apt/apt.conf
APT::Install-Recommends „0“;
APT::Install-Suggests „0“;
Hallo,
zu Test-Zwecken hab ich einmal lynis in subgraph, im non root mode durchlaufen lassen, Ergebnis nur 63%.(Hardening index:63 // Testsperformed:176)
Das gleich dann auf meiner arch installation – auch 63% (non root) Die einzigen „mods“ die ich in arch habe sind eine gui firewall + XFCE als Desktop
Subgraph hat ja einige Härtungen build in im system! Das script erkennt ja auch die gresec patches, nur auf das Endergebnis hat es anscheinend keinen großen Einfluss.
Vielleicht nutze ich ja auch lynis falsch und man muss es immer als root user ausführen um klare Ergebnise zu bekommen.
grüße Masterofdisaster
Lynis muss für eine vollständige Prüfung als root ausgeführt werden.
Hallo Mike!
ich denke die Parameter in apt-get sollten lauten: –no-install-recommends –no-install-suggests
Scheinbar ein Typo von dir. Mit den oben genannten Befehlen forced man das installieren der zusätzlichen Pakete
Jop danke! Ist korrigiert.
Hallo,
möchte jetzt nicht vorgreifen, aber es hat mich schon gereizt → habe mich schon aufs Kernel builden fokussiert, jedoch bin ich ein wenig verunsichert. Den grsecurity-3.1-4.5.4-201605112030.patch gibt es nur in einer Test-Version, weil es anscheinend viele Benutzer kommerziell genutzt haben, nun wird die stabel Version nur mehr für zahlende Kunden zu Verfügung gestellt!
Hab mir das building aber trotzdem angetan, das builden hat ohne Probleme funktioniert, hab zu Test Zwecken einen alten Laptop genutzt(ARCH). Die 64bit Funktion aus dem Kernel herausgenommen und die gresec Erweiterung aktiviert + App armor Support sonst alles auf default gelassen.
Der Patch ist ohne Probleme durchgelaufen, hab dann den Kernel eingerichtet.
Infos dazu Linux-4.5.4 stabel + grsecurity-3.1-4.5.4-201605112030 (TEST)
Wenn ich davon booten will, bekomme ich nach 1,9 Sekunden eine Kernel Panik :(
Liegt es an der hdd Verschlüsselung? Ist einen Standard LVM encryption, also nix besonders.
Muss man mehrere Parameter beim Kernel building abändern ?
grüße Masterofdesaster
Hallo Mike,
toller Beitrag, gut zu lesen und informativ.
Ein Vorschlag bzgl der Updates, der insbesondere Anfängern das Leben erleichtert: Konfiguration der Sicherheits-Updates als “automatisch installieren“, Prüfung täglich. Eignet sich sogar für Omas ebay- Rechner.
Gruß und frohes Schaffen,
Michael
Ich bin begeistert!
Ich bin weiterhin und immer wieder von dem Nutzen dieses Blogs beeindruckt! Lese seit rund einem Jahr jeden Artikel und entdecke immer wieder neue Facetten der Datensicherheit. Mittlerweile habe ich – weil mich diverse Einträge hier zum Nachdenken brachten – mein Handy von Google und anderen Datenkraken befreit und letztlich mein Windows gegen Linux getauscht.
Ich freue mich auf weitere informative Gedanken und (was mir noch wichtiger ist) reale Anwendungsbeispiele(-vorschläge)
Top!
Hallo Mike!
Macht ein IDS wie tripwire oder aide deiner Meinung nach am Desktop Sinn?
Ein IDS nicht, ein HIDS kann hingegen schon Sinn machen. Wobei ich das eher auf Server-Systemen sehe. Habe selbst OSSEC im Einsatz.
Schöne Beiträge für Linux Nutzer!
Die Entwickler von subgraph OS haben auf github den Quellcode von ihrer Firewall veröffentlicht:
https://github.com/subgraph/fw-daemon
Weiß jemand, wie man sich daraus ein Programm zusammenbastelt und auf anderen Linux Distributionen installiert?
Die fw sieht aus und arbeitet wie Little Snitch auf MacOS. Dort leistet die Software sehr gute Dienste.
So wurde ein Hack des Internet „Sicherheits“ Anbieters palantir dadurch aufgedeckt:
https://www.buzzfeednews.com/article/williamalden/how-hired-hackers-got-complete-control-of-palantir
Hallo Mike!
Welche umask settings verwendest du am Desktop? Reicht 022 oder bringt 027 am Desktop einen nennenswerten Sicherheitsvorteil?
Auf Servern ist ja 027 die gängigere Variante.
Noch eine Frage bezüglich Lynis:
Das Tool performed bei mir auf 2 verschiedenen Debian Jessie Rechnern trotz gleicher custom.prf config (machine-role=destop, test-scan-mode=full, rest stock) jeweils eine unterschiedliche Anzahl von Tests. Hast du eine Idee woran das liegen könnte?
Bei 027 bekommen neu angelegte Dateien und Ordner eines Users die Zugriffsberechtigung »750«. Das entspricht u(User)=rwx, g(Group)=rx ,o(Others)=.
Ich verwende 027 am Desktop.
Zu Lynis: Keine Ahnung. Vielleicht ein unterschiedlicher Patch-Level der Systeme.