Honeypot IP Tables Konfiguration

Das Problem mit dem "Timeout" (der keiner ist, daher in Gänsefüßchen) ist, dass er sich bei jeden Kontakt innerhalb dieser Zeit erneut auf die volle Zeit setzt.
Für produktiv-Systeme empfiehlt sich eher ein kleiner Timeout. Denn ein Portscan geht innerhalb von 10 Minuten über die Bühne und ist dann vorbei. Wer dann zum zweiten Mal auf dem selben Port anklopft, betreibt also einen zweiten Scan.
Für statistische Zwecke dürfte es zwar Sinn machen den Wert so hoch zu ziehen. Auf der anderen Seite verfälscht es aber die Statistik, da ein zweiter Portscan innerhalb dieser Zeit nicht korrekt gezählt wird. ;)

Es hat also alles seine für und wieder...

huschi.
 
djrick said:
Wie erhöht man das iptalbes Limit...zB auf 1000?
Click to expand...

Code: 
rmmod ipt_recent
modprobe ipt_recent ip_list_tot=1000
Funktioniert natürlich nur, solang keine IPTables Regeln gesetzt sind, die das recent Modul nutzen.

Für den "Timeout" ist mir kein passenderer Begriff eingefallen. Wie würdest du es denn mit einem Wort nennen, Huschi? :)
Den richtigen Wert dafür zu finden, dürfte wohl immer recht schwer sein. Egal ob nun produktiv System oder wie in meinem Fall für Hobby-Statistiken. Und es kommt auch darauf an, welches Ziel man damit anstrebt. Will man wirklich nur Portscans blocken, reichen 10 Minuten sicherlich aus. Nur gehe ich davon aus, dass ein System, dass derartige Ports meines Servers kontaktiert, im Allgemeinen nichts positives von meinem Server möchte und gegebenfalls mehr als nur einen Portscan durchführen will. :)

Wobei ich hier ganz klar dazu sagen möchte, dass es sich bei mir um kein System handelt, dass wirtschaftlich produktiv genutzt wird und ich somit auch genügend Ram und CPU Ressourcen zur Verfügung habe. ;)

Mein aktuelles Limit liegt bei 100.000 Einträgen für das recent Modul. Für einen produktiven Server würde ich es nicht empfehlen. :)
(Soll ja User geben, die den Thread hier lesen ohne entsprechende Fachkenntnis und dies eventuell falsch interpretieren und erhoffen damit ihre Sicherheit zu steigern. Ungeachtet der Dinge, dass die Stabilität des Servers leiden könnte.)
 
Last edited by a moderator:
Wie sieht es eigentlich hier mit der Gefahr aus selbst ausgesperrt zu werden (Stichpunkt IP Spoofing)?

Die IP des Angreifers wird ja komplett in den iptables gesperrt, es wäre schlecht wenn die eigene IP durch einen Angriff in den iptables landet.
 
1. Dafür gibt es Whitelists
2. Mann kann auf einem anderen sicheren Weg (Web-Interface, serielle Konsole,...) die Firewall wieder öffnen.
Plesk hat dafür /usr/local/psa/var/modules/firewall/firewall-emergency.sh
 
Wie mir gerade aufgefallen ist, funktioniert mein Munin Plugin nicht so, wie man es erwarten sollte.
Bei meinem 2.6.26-1-openvz Kernel fliegen die IPs aus der Liste nicht raus, wenn sie nicht mehr geblockt werden. Daher steigt die Statistik auch nur permanent an. ;)

Muss ich wohl doch noch den last_seen Wert mit berücksichtigen.

Edit:
Also soweit ich nun über Google und im Kernel Source gelesen habe, wird der last_seen Wert in /proc/net/ipt_recent/* in Jiffies angegeben. Die sich aus "Sekunden * Timer frequency (Debian Standard Kernel: 250HZ)" berechnen.
Demzufolge sollte also ein Unix-Timestamp*250 den gleichen Wert ergeben, wie der last_seen Wert wenn in der gleichen Sekunde auf den Honeypot Port zugegriffen wird. Dummerweise lieg ich da mit meiner Berechnung bisher um ca. den Faktor 100 daneben. :(

Beispiel von 13.04.2009 14:59:58:
Code: 
Unix Timestamp: 1239627598
last_seen Wert: 4802102261

Der Unix Timestamp könnte 1-2 Sekunden vom last_seen Wert abweichen.

Kernel (Debian Lenny):
Code: 
Linux snowball.eisscholle.net 2.6.26-1-openvz-amd64 #1 SMP Fri Mar 13 19:02:24 UTC 2009 x86_64 GNU/Linux

Hat vielleicht jemand eine Idee wo mein Fehler in der Berechnung liegen könnte?
 
Last edited by a moderator:
Bist du schon was weiter gekommen? Ich hab gerade mal versucht die last_seen Werte umzurechnen, bekomme da aber ganz merkwürdige Zahlen bei raus :confused:
 
Ähm, jiffies sind doch nur eine relative Zeiteinheit, während sich der Unix-Timestamp auf einen festen Zeitpunkt (1.1. 1970) bezieht.
Zur Umrechnung müßte man noch mindestens den Bootzeitpunkt des Kernels kennen - und den Rollover alle 28 Tage berücksichtigen.
 
Selbst wenn ich die Uptime in Sekunden und nicht die aktuelle Uhrzeit der Berechnung zu Grunde lege, komm ich bisher auf keinen sinnvollen Wert. :(

Uptime liegt noch unter 28 Tagen, somit brauch ich auch noch kein Rollover berücksichtigen.
Whistler, hast du vielleicht eine Formel für uns? :)
 
Whistler said:
Hast Du die Eisscholle zuletzt am 21.03.2009 um 03:20 gebootet?
Click to expand...
Fast, 21.03.2009 03:26:08. :)

Whistler said:
Code: 
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
Click to expand...
Sorry, aber von der Zeile versteh ich (Syntax bedingt) recht wenig. ;)

Whistler said:
Jetzt sollten es 4850876296 sein. Richtig?
Click to expand...
Abgesehen von unseren kleinen Abweichungen hier, kommt das fast ran.
Deine Berechnung scheinen also zu stimmen. Leider weiß ich immer noch nicht wie du eigentlich rechnest. :)

Whistler said:
Eventuell hilft http://www-sr.informatik.uni-tuebingen.de/~buendgen/folien/ws0506/time.pdf
Click to expand...
Hab das PDF nun 3 Mal gelesen und versteh es irgendwie nicht. :)
 
Linus fand es irgendwie cool, die Jiffies beim Booten auf minus 5 Minuten zu setzen (Zitat: Have the 32 bit jiffies value wrap 5 minutes after boot so jiffies wrap bugs show up earlier).

Als 32-Bit-Zahl ist das -300*250 oder 0xFFFEDB08.

Du hast aber ein 64-Bit-System, da wrappt nix :)

Zum von Dir genannten Zeitpunkt (13.04.2009 14:59:58) sind die Jiffies 4802102261, also 0x1E3A43F5.

Macht eine Differenz von 23,48194 Tagen (507209965 / 250 / 86400).
 
Ah ok. Hab dein Beispiel mit der Initialisierung der jiffies mit 4.294.892.296 durchgerechnet und das Ergebnis ergibt Sinn. :)

Nur bei einer Kleinigkeit hängts noch:

Whistler said:
Als 32-Bit-Zahl ist das -300*250 oder 0xFFFEDB08.
Click to expand...

-300*250 macht bei mir -75.000 und nicht 4.294.892.296. :confused:
Wie liegt denn da nun schon wieder mein Denkfehler? :o
 
In dem merkwürdigen Cast in der jiffies.h.

Ein unsigned long hat einen Wertebereich von 0 bis (2^32 - 1), negative Zahlen gibt es nicht.

Eine -1 wrappt zu (2^32 - 1), also 0xFFFFFFFF - die -75.000 werden entsprechend zu 2^32 - 75.000
 
Argh, ok das ergibt Sinn. :)
Aber müsste man dann bei einem 64Bit System nicht eigentlich mit 2^64 - 75.000 rechnen?
Soweit ich nun erlesen konnte, sollte ein long Wert doch auf 64Bit Systemen auch 64Bit groß sein.
 
Richtig.

Der Cast ist so angelegt, daß unter 32- und 64-bit-Systemen dieselbe Zahl herauskommt.

Danach geht's aber weiter - im Gegensatz zu Linus' Kommentar wrappt bei Dir nix.

Deswegen siehst Du ja auch jiffies-Werte > 2^32, auf einem 32-bit-Sytem wäre das nicht der Fall (hier müßte man jiffies_64 auswerten).
 
So, vielen Dank für die Hilfe. Dann kann ich nun endlich auch das Munin Plugin für die Stats korrigieren. :)

Code: 
#!/bin/bash

TIMEOUT=28800
HZ=250
RECENT_TABLE=/proc/net/ipt_recent/portscan
JIFFIE_INITIAL=4294892296

JIFFIE_TIMEOUT=$(echo "$(cat /proc/uptime | awk '{printf("%d\n",$1+=$1<0?-0.5:0.5)}') - ${TIMEOUT}" | bc)
JIFFIE_TIMEOUT=$(echo "${JIFFIE_TIMEOUT} * ${HZ}" | bc)
JIFFIE_TIMEOUT=$(echo "${JIFFIE_TIMEOUT} + ${JIFFIE_INITIAL}" | bc)

cat ${RECENT_TABLE} | 
while read SRC_IP x TTL x LAST_SEEN x; 
do 
	if [ "${LAST_SEEN}" -ge "${JIFFIE_TIMEOUT}" ]; then
		echo "${SRC_IP}"
	fi
done

exit 0

Und damit komm ich aktuell auf 211 IPs, welche innerhalb der letzten 8 Stunden auf die Honeypots zugegriffen haben. Klingt doch gleich viel realistischer. :)

Edit:
Und nochmal Gesamt als Munin Plugin:
Code: 
#!/bin/bash
function get_ipt_recent () {
	TIMEOUT=${2}
	HZ=250
	RECENT_TABLE=${1}
	JIFFIE_INITIAL=4294892296

	pscan=0

	JIFFIE_TIMEOUT=$(echo "$(cat /proc/uptime | awk '{printf("%d\n",$1+=$1<0?-0.5:0.5)}') - ${TIMEOUT}" | bc)
	JIFFIE_TIMEOUT=$(echo "${JIFFIE_TIMEOUT} * ${HZ}" | bc)
	JIFFIE_TIMEOUT=$(echo "${JIFFIE_TIMEOUT} + ${JIFFIE_INITIAL}" | bc)

	cat ${RECENT_TABLE} | {
	while read x x x x LAST_SEEN x; 
	do 
		if [ "${LAST_SEEN}" -ge "${JIFFIE_TIMEOUT}" ]; then
			pscan=$(echo "${pscan} + 1" | bc)
		fi
	done
	echo $pscan; }
}


if [ "$1" = "autoconf" ]; then
	echo yes 
	exit 0
fi

if [ "$1" = "config" ]; then
	echo 'graph_title Number of IPTables on System'
	echo 'graph_args --base 1000 -l 0 '
	echo 'graph_vlabel number of rules'
	echo 'graph_category Network'
	echo 'graph_order iptrulesnumstatic iptrulesnumdrop iptrulesnumpscan'
	echo 'graph_info This graph shows the number of Iptables Rules on System.'
	echo 'iptrulesnumstatic.label Static Rules'
	echo 'iptrulesnumstatic.draw AREA'
	echo 'iptrulesnumdrop.label Drop Rules'
	echo 'iptrulesnumdrop.draw STACK'
	echo 'iptrulesnumpscan.label Port Scans'
	echo 'iptrulesnumpscan.draw STACK'	
	exit 0
fi

drop=`iptables -L -n | grep -e "^DROP.*" | wc -l`
static=`iptables -L -n | grep -v Chain | grep -v -e "target.*prot.*opt.*source.*destination" | grep -v -e "^$" | wc -l`
static=`echo "${static}-${drop}" | bc`

echo "iptrulesnumstatic.value ${static}"
echo "iptrulesnumdrop.value ${drop}"
echo "iptrulesnumpscan.value $(get_ipt_recent "/proc/net/ipt_recent/portscan" "28800")"

Man könnte es sicherlich schöner lösen, aber es funktioniert erstmal. :)
 
Last edited by a moderator:
Hallo,

Noch eine Frage:
Code: 
echo "iptrulesnumpscan.value $(get_ipt_recent "/proc/net/ipt_recent/portscan" "28800")"

Die 28800 sind dein Timeout von 8 Stunden? Wenn jemand (wie ich) ein anderes Timeout gewählt hat, sollte er diesen Wert durch den Timeout den er beim erstellen der iptables Regel gewählt hat ersetzen, oder?

Edit:

Frage2: 32 und 64bit System ist jetzt kein Unterschied, wenn ich Whistler richtig verstanden hab? :confused:

Frage3:
Code: 
JIFFIE_INITIAL=4294892296
ist ein statischer Wert?
 
Last edited by a moderator:
djrick said:
Die 28800 sind dein Timeout von 8 Stunden? Wenn jemand (wie ich) ein anderes Timeout gewählt hat, sollte er diesen Wert durch den Timeout den er beim erstellen der iptables Regel gewählt hat ersetzen, oder?
Click to expand...
Jup. :)

djrick said:
Frage2: 32 und 64bit System ist jetzt kein Unterschied, wenn ich Whistler richtig verstanden hab? :confused:
Click to expand...
Bis auf das es beim 32Bit System irgendwann zu einem "Überlauf" kommt, weil die Jiffies nicht mehr in den 32Bit long Typ passen, jo.

djrick said:
Frage3:
Code: 
JIFFIE_INITIAL=4294892296
ist ein statischer Wert?
Click to expand...
Solang dein Kernel mit einer Timer Frequency von 250 HZ arbeitet, ja. ;)
Ansonsten darfst neu rechnen. :p
 
Mhm mhm...wieso bin ich von 600 auf 0 gefallen?...Also 0 glaube ich deinem Script nicht ;) *debug*

Edit: Also das Script gibt bei einem Timeout von 1500 einen Wert von 4516925046 für die Variable JIFFIE_TIMEOUT, was mir doch ein wenig hoch im Vergleich zu den LAST SEEN Werten erscheint, oder?
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top