Schlagwort-Archive: security

ARP Poisoning mit Kali Linux

Grundlagen

ARP – Address Resolution Protocol

ARP, Address Resolution Protocol, ist ein Netzwerkprotokoll, welches in lokalen Netzwerken zu einer IP-Adresse, z. B. 10.0.0.1, die MAC-Adresse, z. B. 76:1b:4c:37:81:41, ermittelt.

MITM – Man in the middle

Als Man in the middle Attacke bezeichnet man einen Angriff, bei dem sich der Angreifer in die Kommunikation einklinkt. Er befindet sich damit zwischen (sozusagen in der Mitte / in the middle) Angreifer und Ziel:

MITM-trans-text

 

Statt der direkten Verbindung Zwischen Opfer und Gateway wird der Verkehr nun über den Angreifer umgeleitet und kann dort mitgeschnitten oder verändert werden.

ARP Poisoning

Beim ARP Poisoning werden für ein bestimmtes Ziel gefälschte ARP-Pakete ins Netzwerk gesendet. Somit können einerseits Anfragen wie oben beschrieben umgeleitet und für eine MITM Attacke genutzt werden. Ein weiteres Szenario ist das Umleiten von Anfragen an eine bestimmte Maschine an ein Ziel, welches nicht existiert. Hiermit kann der Zugriff auf bestimmte Systeme unterbunden werden, beispielsweise auf das Internet (Gateway) oder auf bestimmte Application Server.

Kali Linux

Kali Linux ist eine auf Debian basierende Linux-Distribution, welche auf  Sicherheitstests ausgerichtet ist.

Praxistest mit Ettercap

Vorwort

Die hier beschriebene Vorgehensweise sollte ausschließlich in Testumgebungen durchgeführt werden. Mir ist wichtig darauf hinzuweisen, dass unbedingt geltende Bestimmungen und Gesetze eingehalten werden sollen. Weiter sei angemerkt, dass durch das Umleiten bestimmter Komponenten im Netzwerk schnell ein ganzes Netz lahmgelegt werden kann und was als Test begann,  plötzlich zu heftigen Produktionsausfällen führen kann.

Konfiguration

Wir passen /etc/ettercap/etter.conf an zwei Stellen an.

…und weiter unten entfernen wir die Kommentarzeichen vor redir_command:

Danach kann der eigentliche Eingriff in das Netzwerk beginnen.

Durchführung

In einer Rootshell wird ettercap gestartet:

Zunächst wird unter Options „Promisc mode“ angehakt.

Danach wird unter Sniff > Unified Sniffing… eine Netzwerkschnittstelle ausgewählt, welche an das zu untersuchende Netz angebunden ist, z. B. eth0 oder wlan0.

Als nächstes wird unter Hosts mit „Scan for hosts“  nach Geräten im Netzwerk gesucht. Ein Klick auf Hosts > Host list zeigt die gefundenen Geräte. Möchten wir nur in eine bestimmte Verbindung eingreifen, suchen wir zunächst in der Hostliste das Gateway und wählen es mit „Add to Target 1“ aus, das Opfer wählen wir mit „Add to Target 2“ aus.

Unter Mitm > Arp Poisoning… haken wir „Sniff remote connections“ an.

Ettercap zeigt nun beispielsweise Benutzername und Passwort an, wenn von dem Gerät des Opfers eine Anmeldung an WordPress erfolgt. Startet man driftnet können die Bilder der aufgerufenen Websites angezeigt werden. Mittels urlsnarf werden die aufgerufenen Websites ausgegeben.

Beendet wird mit Start > Stop sniffing.

Schlusswort

Hiermit ist eindrucksvoll demonstriert, wie leicht es ist, in einem Netzwerk Informationen zu erlangen, die nicht für Dritte gedacht sind. Wer in unbekannten Netzen unterwegs ist, beispielsweise im Hotel, an der Universität, in der WG oder einfach mal schnell mit dem Smartphone im WLAN bei Freunden, sollte sich immer auch Gedanken um die Sicherheit machen.

Have fun!

SSH: 2-Wege-Authentifizierung mit Google Authenticator

Vorwort

Für ein gefühltes Stück mehr Sicherheit kann sshd um eine Zweifaktorauthentifizierung erweitert werden.

Installation

Wir beantworten einige fragen und erhalten dann einen QR-Code, der mit dem Smartphone gescannt werden kann, er wird dann mit der Google-Authenticator-App verarbeitet. Zusätzlich werden sogenannte Scratch-Codes mitgeteilt, dies sind Einmalpasswörter, die im Notfall genutzt werden können, sollte das Smartphone nicht zu Hand oder defekt sein.

Einrichtung

Wir erweitern /etc/pam.d/sshd wie folgt:

In /etc/ssh/sshd_config werden folgende Anpassungen vorgenommen:

Im Anschluss ist sshd neuzustarten. Beim erneuten Anmelden wird dann neben dem Passwort ein Auth-Code abgefragt:

Have fun!

Fail2ban – Regel für Bash-Sicherheitslücke Shellshock

Einleitung

Zurzeit ist die Bash-Sicherheitslücke Shellshock in aller Munde. Vereinfacht ermöglicht diese Sicherheitslücke, in Umgebungsvariablen ungeprüften Code einzufügen, welcher beim nächsten Start einer Bash-Shell dann ausgeführt wird. Betroffen sind insbesondere Webserver, hier reicht ein gezielter Aufruf mittels wget oder curl, welcher bestimmte Parameter beinhaltet. Da die Bash generell sehr häufig genutzt wird, ist die Sicherheitslücke nicht bloß auf Webserver beschränkt sonder voraussichtlich auf ein weites Feld von Anwendungen, die Bash nutzen.

Ganz wichtig ist, dass die Fail2ban-Erweiterung kein Ersatz für ein gepatchtes System ist, sondern lediglich eine Ergänzung. Voraussetzung ist in jedem Fall, dass zunächst das System aktualisiert wird, alle gängigen Distributionen halten bereits seit Tagen entsprechende Updates bereit.

Apache-Logs

Die verdächtigen Apache-Logs habe ich mit cat /var/log/apache2/access.log | grep „() { :;“ durchsucht, die Ausgabe könnte so aussehen:

Bei nicht gepatchten System bedeutet dies im Zweifen den GAU.

Filterregel

Wir erstellen eine neue Regel /etc/fail2ban/filter.d/shellshock-scan.conf wie folgt:

Gefunden habe ich diese Regel habe hier. Sie war zugegebenermaßen etwas besser als meine, vielen Dank an dieser Stelle.

Jail.local

In /etc/fail2ban/jail.conf wird folgendes ergänzt:

Fail2ban muss im Anschluss neugestartet werden, um die neue Regel zu aktivieren.

Test

Hiermit kann die neue Filterregel getestet werden:

Die Ausgabe sieht dann so in etwa aus:

Have fun!

Fail2SQL, eine fail2ban-Erweiterung

Vorwort

Ich nutze seit geraumer Zeit fail2ban zum Blocken von IP-Adressen, von welchen aus mittels Brute-Force massive Login-Versuche entdeckt werden. Beim Stöbern bin ich dann auf fail2sql gestoßen. Damit lassen sich die geblockten IP-Adressen mit nützlichen Zusatzinformationen in einer MySQL-Datenbank ablegen.

Installation

Download von fail2ban, anschließend entpacken:

Datenbank

Es wird eine Datenbank fail2ban mit gleichnamigem Benutzer und entsprechenden Berechtigungen erstellt:

Anschließend wird das mitgelieferte Skript eingespielt:

Datenbank-Verbindung ist anzupassen (Host/User/Passwort):

Update der GeoIP-Datenbank

Fail2Ban

Schließlich ist noch „actionban“ anzupassen:

Somit sind die Vorbereitungen abgeschlossen.

Links

http://sourceforge.net/projects/fail2sql/
http://www.dbsysnet.com/howto-geolocation-for-fail2ban/

Karte

fail2ban Installation und Konfiguration

Was ist fail2ban?

In der deutschen FAQ wird diese Frage wie folgt beantwortet:

Fail2Ban durchsucht Logdateien wie /var/log/pwdfail oder /var/log/apache/error_log und blockt IP-Adressen, die zu viele fehlgeschlagene Loginversuche haben. Es aktualisiert Firewallregeln, um diese IP-Adressen zu sperren. Fail2Ban kann mehrere Logfiles lesen – beispielsweise die von sshd oder apache. Die IP-Adressen werden nach einer vorher festgelegten Zeitspanne wieder aktiviert.

Vielleicht sind bereits Log-Einträge aufgefallen, bei denen von der gleichen IP-Adresse ausgehend der SSH penetriert wird:

Hierbei ist xxxxx die angegriffene Maschine und xxx.xxx.xxx.xxx die IP des Angreifers. Fail2ban durchsucht nun jene Log-Files und sperrt per Firewall-Regel den den Agreifer für eine definierbare zeit aus.

Installation

Das Paket wird mittels apt-get installiert.

 Konfiguration

Allgemein

Ich nutze Debian, hier liegen die Konfigurationsdateien unter /etc/fail2ban. Anzupassen ist hier die Datei /etc/fail2ban/jail.conf. Da fail2ban in den meisten Fällen bereits out-of-the-box läuft, möchte ich nur einige interessante Parameter aufführen:

Mit ignoreip können (eigene) IP’s definiert werden, welche nicht gesperrt werden sollen. Bantime gibt an, wie lange eine Sperrung erfolgen soll, der Wert wird hier in Sekunden angegeben, ich habe mich für einen ganzen Tag entschieden. Maxretry gibt die Standardeinstellung an, wie viele Verbindungsversuche erlaubt sind, bis es zur Sperrung kommt.

Mail

Fail2ban bietet die Möglichkeit, seine Tätigkeit per Mail zu protokollieren. Der Benutzer ann wählen, wohin gemailt werden soll und mit welcher Detailtiefe. Die Mailadresse wird unter destmail angegeben, action gibt die Detailtiefe an.

Mit dieser Einstellung wird ein detailliertes Protokoll an <Ihre@Mailadresse> versandt. Ein Auszug aus der Konfigurationsdatei zeigt weitere Einstellungsmöglichkeiten:

ssh

Die bereits angesprochene Standardeinstellung maxretry kann für jeden konfigurierten Dienst individuell überschrieben werden, ich verwende auch hier 2.

fail2ban starten

Damit die Änderungen aktiv werden, wird der Dienst einfach neugestartet

Beachten Sie danach einfach die Logs und die Mails unter der eingestellten Mailadresse.