Um meine Intrusion Detection auf meinem Router TP-Link WR1043ND noch etwas voran zu treiben und mein Netzwerk weiter abzusichern, habe ich mir noch eine Port Scan Detection eingebaut. Fangen wir aber Vorne an: “Port Scan Detection“, was ist das überhaupt? Möchte ein Angreifer in Dein Netzwerk einbrechen, dann ist die übliche Vorgehensweise ganz am Anfang erst einmal, das erste System an der öffentlichen IP-Adresse nach offenen Ports abzuscannen. Früher war es z.B. so, dass viele Windows-Rechner ohne Firewall ungesichert direkt am Internet mittels Modem angeschlossen waren, was dazu führte, dass man ohne Anstrengung direkt auf die Dateifreigaben oder die ganze Festplattte zugreifen konnte.

Heutzutage sperren die handelsüblichen Router und Firewalls sämtliche Ports und reagieren einfach nicht auf “Port Scans“. Diese Verhaltensweise ist auch vollkommen in Ordnung und die meisten Nutzer wären mit Sicherheit vollkommen überfordert, wenn die Firewall alle 2 Stunden einen Portscan meldet. Soviele waren es bei mir am ersten Tag der Aktivitäten meiner “Port Scan Detection” – die meisten Port Scans kamen übrigens von infizierten Rechnern auf Port 135 (bekannt dafür ist der W32.Blaster Wurm). Richtigerweise muss man jetzt aber auch mal über den Sinn und Unsinn der “Port Scan Detection” reden. Genau über diesen Sinn der “Port Scan Detection” hatte ich auch eine längere Diskussion mit der OpenWrt Community. Grundsätzlich ist es natürlich vollkommen ausreichend, die Ports einfach zu sperren und durch den Einsatz einer weiteren Software stellt diese natürlich auch eine gewisse Sicherheitslücke durch eventuelle Exploits dar.

Nichts desto trotz gibt es einen klaren Grund, warum “Port Scan Detection” absolut Sinn macht. Ein Angreifer, der gestreut Port Scans durchführt, interessiert natürlich nur begrenzt. Erkennt man jedoch einen Angreifer, der gezielt mehrmals unterschiedlichste oder die gleichen Ports scannt, dann kann das ein Anzeichen für die Vorbereitung eines Angriffs sein und dann hat die “Port Scan Detection” schon Ihren Sinn erfüllt: das rechtzeitige Erkennen von Port Scans.

Port Scan Detection mit Portsentry

Es gibt diverse Software für Port Scan Detection, jedoch ist Portsentry die wahrscheinlich beste Software und das Paket für OpenWrt funktioniert auch ganz gut. Gehen wir nun also schrittweise vor: Zuerst installieren wir Portsentry. Im Anschluss müssen wir dann an die Konfiguration ran. Meine Konfiguration ist so eingestellt, dass diese lediglich über Port Scans berichtet und keine weiteren Gegenmaßnahmen einleitet – ich denke, dass das auch so in Ordnung ist. Lässt man Portsentry bei iptables die Routen sperren, kann man sich mit seinen Tests schnell selbst aussperren – ich empfehle es nicht. Auch nicht zu empfehlen sind automatische Gegenangriffe, man will ja schließlich, dass der Angreifer einfach verschwindet.

Standardmäßig ist schon alles recht gut konfiguriert. Portsentry läuft im “advanced” Modus für TCP und UDP, was bedeutet, dass Portsentry sich an alle Ports unterhalb des konfigurierten Ports in ADVANCED_PORTS_TCP und ADVANCED_PORTS_UDP bindet. Der Wert steht standardmäßig auf 1024 – das reicht auch. Die Parameter “IGNORE_FILE“, “HISTORY_FILE” und “BLOCKED_FILE” haben falsche Pfade in der Standardkonfiguration, weswegen man noch einen entsprechenden Ordner dafür anlegen muss. Ich habe “/etc/portsentry” dafür angelegt und verwendet. Die Parameter “BLOCK_UDP” und “BLOCK_TCP” habe ich auf den Wert “2″ geändert, da dann nur noch der Befehl ausgeführt wird, der unter “KILL_RUN_CMD” konfiguriert ist und kein Eintrag in iptables erfolgt.

Unter “KILL_RUN_CMD” kann man dann ein beliebiges Batch-Skript einstellen, welches bei einem Port Scan mit Parametern aufgerufen wird. Bei mir steht dort: “sh /root/portscan/report-attack $TARGET$ $PORT$ $MODE$“. Target enthält die IP-Adresse des Angreifers, Port den gescannten Port und Mode den Modus von Portsentry (atcp oder audp).

Port Scan Detection Bericht mit PHP per E-Mail versenden

Mein Skript unter “/root/portscan/report-attack” sieht wie folgt aus und ruft ein PHP Skript auf meinem Webserver auf, welches dann entsprechend eine E-Mail an mich versendet.

#!/bin/ash
wget -qO- "http://www.kammerath.net/xxx/xxx/portscan-report.php" --post-data '&d='$1__$2__$3
sh /root/led/blink-qss 5 &

Das Skript ist wirklich sehr simpel und sendet einfach die Informationen des Port Scan an ein PHP Skript auf meinem Webserver. Wer meinen Beitrag “Wi-Fi Intrusion Detection mit OpenWrt und PHP” gelesen hat, weiß dass ich grundsätzlich aus Performance-Gründen nur die Datenerfassung und Erkennung auf dem Router mache. Das Reporting übernimmt der Webserver, welcher dann auch die Datenbank und den E-Mail Versand bereitstellt. Im Falle eines Totalschadens des Routers bleiben die Daten dann auf dem zentralen Server für Gegenmaßnahmen verfügbar.

Nachfolgend sieht man dann das PHP Skript für den Versand des Berichts, welches auch noch eine kleine Erweiterung zur Abfrage der Provider-Daten beim RIPE besitzt.

require_once('whois.php');
 
if(array_key_exists('d',$_POST)){
	// explode the data provided in IP__PORT__MODE format
	$data = explode('__',$_POST['d']);
 
	// split it into several variables
	$ip = $data[0];
	$port = $data[1];
	$mode = $data[2];
 
	$ip_data = ripe_whois($ip);
 
	$subject = "IDS PortScan Alert";
	if(substr($ip,0,3)=="192"){
		$subject = "IDS CRITICAL: Internal PortScan Alert";
	}
 
	// define the message for portscans
	$text = "IDS detected a portscan from ".$ip
			." (".$ip_data['netname'].",".$ip_data['country'].") "
			."on port ".$port." using ".$mode.".nn"
			."*** FULL INFORMATION FOR ".$ip_data['netname']." ***n"
			.$ip_data['fullinfo'];
 
	// send mail to the admin
	mail("jankammerath@googlemail.com", $subject, $text, 
		"From: Intrusion Detection rn");
}

Dazu braucht man jetzt nicht allzu viel zu sagen. Das Skript für die Abfrage von RIPE sieht dann entsprechend wie folgt aus und vervollständigt unsere Port Scan Detection.

/*
Queries the ripe database and returns
the record within ripe as an array with
the following keys.
 
netnum, netname, descr, country, fullinfo
 
 
*/
function ripe_whois($query){
	$record_data = array();
	$result = file_get_contents("http://lab.db.ripe.net/whois/search?source=ripe&query-string=".$query);
	$data = simplexml_load_string($result);
	$fullinfo = "";
	foreach($data->objects->object as $entry){
		$entry_name = $entry->attributes()->type;
		foreach($entry->attributes->attribute as $attr){
			$entry_key = $entry_name."_".$attr->attributes()->name;
			$entry_value = trim($attr->attributes()->value);
			$fullinfo .= $entry_key.":tt".$entry_value."n";
 
			if($entry_key=="inetnum_inetnum"){
				$record_data['netnum'] = $entry_value;
			}if($entry_key=="inetnum_netname"){
				$record_data['netname'] = $entry_value;
			}if($entry_key=="inetnum_descr"){
				$record_data['descr'] = $entry_value;
			}if($entry_key=="inetnum_country"){
				$record_data['country'] = $entry_value;
			}
		}
	}
	$record_data['fullinfo'] = $fullinfo;
	return $record_data;
}

Soweit haben wir dann alles zusammen für unsere “Port Scan Detection” und wenn man nun vom internen Netz aus mit z.B. “nmap” Port Scans durchführt, dann wird man die entsprechende Benachrichtung erhalten. Damit wir nun jedoch die entsprechenden Benachrichtigungen für Port Scans auf der WAN Schnittstelle erhalten, müssen wir zunächst die Firewall anpassen.

Anpassung der Firewall für Port Scan Detection auf der WAN Schnittstelle

Damit Portsentry auch die Pakete für die Port Scans bekommt, müssen die Ports auf der Firewall geöffnet werden. Hierbei ist jedoch unbedingt zu beachten, dass alle Dienste auf den Ports unterhalb von 1024 entweder noch separat geblockt oder verschoben werden. Ich habe alle Ports von 1 bis 250 geöffnet, bis auf 53 (DNS). Den SSH Server Dropbear habe ich auf einen höheren Port verschoben, was man in der “/etc/config/dropbear” Datei konfigurieren kann. Die Dokumentation zur Konfiguration der Firewall in OpenWrt sollte man sich in Ruhe durchlesen! Hier gilt in der Datei “/etc/config/firewall” immer der erste Eintrag. D.h. bei mir steht erst, dass alle Pakete auf Port 53 zurückgewiesen werden (REJECT) und dann folgt die Anweisung alle Pakete auf Port 1 bis 250 zu aktzeptieren. Anschließend werden dann auch die Port Scans von Port 1 bis 250 – bis auf Port 53 – berichtet.

Fazit zur Port Scan Detection

Es ist definitiv sinnvoll, um rechtzeitig gezielte Angriffe zu erkennen und sich darauf vorbereiten zu können. Nichts desto trotz sollte man die Port Scan Berichte überprüfen und gegebenenfalls noch ein paar weitere Ports aussperren. Sehr viele Port Scans stammen einfach nur von Zombie-Rechnern, die von teilweise veralteten Viren infiziert sind (insbesondere auf Port 135). Die Ports kann man dann anschließend wie bei Port 53 nach und nach sperren bzw. die Pakete von iptables zurückweisen lassen. Mir tun die infizierten Leute einfach Leid und es sind noch Tausende.

Bücher zum Thema „Netzwerksicherheit“