CLI-Adventskalender: Security

Security ist anders als viele andere Bereiche der IT. Darum geht es im 22. Beitrag meines CLI-Adventskalenders.

Wenn man mit dem Terminal schon aussieht wie ein Hacker, dann kann ma ja auch gleich lernen einer zu werden, hm?

Security

Viel von Security ist durchsetzt von Aberglauben. Ich kann hier mal eine Suche nach Passwortrichtlinien empfehlen und welche davon die Richtige ist. Sind sechzehn Zeichen mit Zahlen, Sonderzeichen, Klein- und Großbuchstaben ein vernünftiges Passwort? Oder sollte man einfach fünf oder sechs Wörter ohne Zusammenhang nehmen und sie aneinander reihen? Wie oft sollten Passwörter rotiert werden? Sind Passwortsafes sicher? Oder sollte ich besser ein Papiernotizbuch in einen Safe legen?

Passwortrichtlinien sind ein klassisches Beispiel dafür was passiert, wenn verschiedene, eigentlich vertrauenswürdige Quellen selbstbewusst etwas anderes sagen. Noch schlimmer wird es, wenn wir uns in Bereiche bewegen, in denen kommerzielle Interessen bestehen. Macht Antiviren-Software ein System sicherer? Im Verhältnis dazu, wie viel zusätzliche Angriffsfläche sie öffnet?

Ich will hier gar nicht lange rumbashen. Mein Punkt ist: Es ist nicht unmittelbar klar, welche Security-Maßnahmen sinnvoll sind und welche überflüssig oder gar eher schädlich.

Defense in Depth

Wer von euch hat schon mal eine fremde Person in eurem Büro vorbeilaufen sehen und sofort angesprochen? „Lieber Mensch im Handwerker-Blaumann, wer sind Sie denn? Von welcher Firma kommen Sie? Wer hat sie beauftragt? Kann ich Ihnen helfen?“

Gerade in Unternehmen mit strikteren Sicherheitsvorkehrungen (RFID-Badges, Maschendrahtzäune, Anmeldung im Foyer, Überwachungskameras, Aufzüge, die nur autorisierte Stockwerke ansteuern, …) nehmen wir gerne an, dass wer auch immer durch das alles durchgekommen ist schon autorisiert sein wird da zu sein.

Genau so ist es häufig mit Servern. Wer auch immer es schafft eine Shell zu öffnen, der wird schon irgendwie autorisiert sein. Außer natürlich es gibt eine Sicherheitslücke, die irgendeine äußere Sicherheitsvorkehrung umgeht. Selbst die sauber konfigurierten Systeme können sich nicht vor Lücken schützen, die bisher unbekannt sind.

Oder etwa doch?

Genau so wie wir Handwerker im Büro freundlich ansprechen können, können wir auch unsere Maschinen so konfigurieren, dass sie alles was auf ihnen läuft erst einmal kritisch beäugen. Es ist nur Paranoia wenn wir falsch liegen. Andernfalls ist es vorausschauende Vorsicht.

Wenige die im Bereich der Softwareentwicklung arbeiten glauben, dass Bug-freie Systeme möglich sind. Menschliche Fehler sind eine konstante unserer Arbeit. Kompensationen derselbigen und möglichst saubere Arbeit auf allen Ebenen ist deshalb eine gute Idee.

Security ist nicht nur für Admins

Ich beziehe mich hier nicht nur auf „Bitte Passwörter nicht auf Post-Its schreiben“ und „Bitte keine merkwürdigen E-Mail-Anhänge öffnen“.

Laptops sind die besten Trojaner. EntwicklerInnen sind dazu angehalten, sich alle möglichen Technologien anzuschauen. Der Friedhof halb-fertiger Bastelprojekte der auf vielen Developer-Laptops zu finden ist, ist nahezu ein Meme. Wir nehmen unsere Laptops gerne an verschiedene Orte mit und arbeiten überall dort, wo es gratis WLAN gibt … direkt neben haufenweiser fremder Maschinen.

Mein Punkt ist, dass nur weil man kein Sysadmin ist, heißt das nicht, dass Security-Verbesserung einen selbst nicht betrifft. Wenn der eigene Laptop den Server der Ransomware-Gang von hinter der Firmen-Firewall aus anruft, ist der nächste IT-Security-Vorfall möglicherweise nur noch ein paar Tage weit weg.

Durch die Augen eines Angreifers

Hinweis: Cyber-Angriffe bitte nur gegen eigene Systeme (oder mit Erlaubnis) fahren, um rechtliche Schwierigkeiten zu vermeiden.

nmap -p- -sS -sV -O --script=all --traceroute -T4 -f -v mondbasis.mayflower.de

Die beste Möglichkeit sich effektiv auf einen Angriff vorzubereiten ist es, einen Angriff durchzuführen. Was sieht ein Angreifer, wenn er unser System sieht? Was ist erreichbar? Sollte das alles erreichbar sein?

Die Gegenmaßnahme hier ist eine gesund konfigurierte Firewall.

sudo ss -tuln
sudo iptables -L

Ein Server sollte grundsätzlich nur das Minimum an Ports offen haben. Je mehr Angriffsfläche ein Server anbietet, je mehr Informationen er preisgibt, desto einfacher wird es, Sicherheitslücken zu finden, die Zugang ermöglichen.

searchsploit -e 'Apache 2.2.8'

Einen vernünftigen Zaun außen rum

Eine restriktiv konfigurierte externe Firewall ist prinzipiell eine gute Idee, um ein System zu schützen. Des weiteren helfen Tools wie Fail2Ban, Bruteforce-Angriffen (dem wilden Raten von Passwörtern) entgegenzuwirken.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Nicht vergessen, den Dienst dann auch anzuschalten.

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Die IP-Adresse, die die konfigurierte Anzahl fehlgeschlagener Logins verursacht hat, wird per Firewall für die konfigurierte Anzahl an Minuten geblockt. Das ist für einen legitimen Nutzer einfach eine Kaffeepause, tötet aber einen Angriff, der Millionen von Passwörtern ausprobieren möchte, im Keim. Irgendwann gehen selbst dem größten Botnetz die IP-Adressen aus.

Lokale Privilegien einschränken

Wenn ein Service mit root-Privilegien läuft und kompromittiert wird, dann ist Dein Server nicht mehr Dein Server. Das Principle of Least Privilege greift hier. Also:

1. Jeder Service kriegt einen eigenen User.

sudo groupadd webshop
sudo useradd -r -s /bin/false -g webshop webshop_user

Dann besagten Service auch als diesen Nutzer ausführen. In systemd, zum Beispiel mit:

User=webshop_user
Group=webshop

und dann

sudo systemctl daemon-reload
sudo systemctl restart webshop

2. Besagter User darf nur auf die Dateien zugreifen, die absolut notwendig sind – und selbst dann lieber lesend als schreibend.

sudo chown -R webshop_user:webshop /pfad/zum/webshop

Und ja, es ist frustrierend in der Setup-Phase, wenn man „Permission Denied“ sieht und man dann erst einmal losere Privilegien setzen möchte, um den Fehler zu finden. Wichtig ist hier wieder, hinterher aufzuräumen. Wenn ihr nicht nach solchen Dateien sucht, tut es ein Angreifer für euch.

find /pfad/zum/webshop \( -type f -perm -o+r \) -o \( -type f -perm -o+w \) -o \( -type f -perm -o+x \)

3. Firewall-Regeln sollen Netzwerkverbindungen auf das Nötigste reduzieren. („Warum fährt mein Apache-Webserver einen Portscan gegen mein internes Netzwerk?“)

webshop_user_id=$(id -u webshop_user)
sudo iptables -A OUTPUT -m owner --uid-owner $webshop_user_id -j REJECT
sudo iptables-save

Das hier ist sicherlich eine extreme Konfiguration. Vielleicht muss der Webshop automatische Updates beziehen? Auf der anderen Seite spricht nichts dagegen, eine temporäre Ausnahme zu machen.

webshop_user_id=$(id -u webshop_user)
sudo iptables -A OUTPUT -m owner --uid-owner $webshop_user_id -d IP_DES_UPDATE_SERVERS -m time --timestart 12:00 --timestop 13:00 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner $webshop_user_id -j REJECT
sudo iptables-save

Updates werden von 12 bis 13 Uhr gesucht.

4. Auditing und Monitoring sollten ungewöhnliches Verhalten bemerken und melden.

Der Server sollte seine Logs idealerweise an eine zentrale Stelle übertragen, beispielsweise einen klassischen ELK-Stack. Wichtig an dieser Stelle sind alle security-relevanten Logs des Services sowie des Systems. Dazu zählen:

• Authentifizierungs-Logs. Klassicherweise /var/log/auth.log
• Webserver-Logs. /var/log/apache2/access.log und /var/log/apache2/error.log, bzw. /var/log/nginx/access.log und /var/log/nginx/error.log.
• Syslog. /var/log/syslog. Wenn irgendetwas merkwürdiges im System passiert, dann kann man es hier finden. Hier finden sich auch in der Regel die Firewall-Logs.
• Kernel-Logs. /var/log/kern.log für Ereignisse auf Hardwareebene.
• Fail2ban-Logs. /var/log/fail2ban.log. Es ist nützlich zu wissen, wenn jemand versucht den Login zu bruteforcen. Es ist noch nützlicher zu erfahren, wenn sie erfolgreich waren.

5. Nach Sicherheitslücken scannen

Potenzielle Fehlkonfigurationen sind zahlreich. Automatische Skripte schaffen Klarheit. LinPEAS ist ein klassisches Skript, das viele mögliche Privilege-Escalation-Methoden überprüft.

curl -O https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
chmod o+x linpeas.sh
su -s /bin/bash webshop_user
./linpeas.sh

Und natürlich kann ich eine ganze Reihe von potenziellen Sicherheitslücken mit Scannern wie dem Greenbone Vulnerability Manager oder kommerziellen Scannern wie Nessus finden.

Auch root kann nicht hellsehen

Wenn alles andere fehlschlägt, ist Verschlüsselung die letzte Verteidigungsmauer eines anderweitig kompromittierten Systems. Wenn der Schlüssel nicht auf dem System gespeichert ist, kommt ein Angreifer auch erstmal nicht an die Daten. Zumindest nicht, bis ein solcher Schlüssel durch längerfristiges Ausspionieren abgegriffen werden kann.

Noch besser: Vertrauliche Daten gar nicht erst auf dem System speichern. Das ist der ganze Grund, warum z. B. bei personenbezogenen Daten inzwischen strikte gesetzliche Richtlinien existieren. Wenn ich entwickle, reichen Testdaten. Nur der Produktionsserver muss wirklich auf die echten Daten zugreifen können.

Eigenen Systemen erst einmal nicht vertrauen

Ich habe mich hier erst einmal auf den Fall eines einzelnen Systems beschränkt. Generell ist es aber gut die Frage zu stellen „Was passiert, wenn ein Angreifer ein System innerhalb meines Netzwerks übernimmt?“. Die Antwort darauf kann je nach Umgebung vielschichtig und komplex sein und Netzwerksegmentierung, Intrusion-Prevention-Systeme und restriktive Firewall-Regeln beinhalten.

Was tun, wenn’s brennt?

In den allermeisten Fällen bemerkt man einen Angriff erst nachdem er passiert ist. Dann lässt sich – bei guten Logging-Strategien – erkennen, wie weit die Angreifer gekommen sind und wo sie schlussendlich gescheitert sind … wenn sie gescheitert sind.

• Schaden feststellen und Betroffene (und Behörden) informieren. Es gelten ggf. gesetzliche Meldefristen.
• Kompromittierte Systeme von installierten Hintertüren säubern. Wenn es Grund zu der Annahme gibt das ein Rootkit installiert wurde, muss das System komplett von Null auf neu aufgesetzt werden.
• Sicherheitslücken beheben. Nichts besseres als ein Angriff, um aufzuzeigen, wo sie liegen. Wenn Credentials kompromittiert wurden, sollten diese durch die Bank ausgewechselt werden.
• Lernen. Es hat grundsätzlich das System versagt, nicht einzelne Personen. Nur wenn man die gefundenen Ursachen auf operativer Ebene ausschließt bzw. mitgiert, werden Systeme langfristig sicherer.

Security ist der Job von ALLEN Beteiligten

Nur die wenigsten Firmen haben dedizierte IT-Security-Teams. Selbst in diesen Firmen sind es meist zwei oder drei Leute für hunderte, wenn nicht mehrere tausend Angestellte. Der Idealfall ist also, wenn alle mit darauf achten, dass Sicherheitsrichtlinien (erstens) existieren und (zweitens) eingehalten werden. Server hinter kugelsicheres Glas (oder in die Cloud) zu stellen bringt nicht viel, wenn der Zettel mit dem Passwort am Bildschirm klebt.