|
|
Besucher 1260498
Ansichten 4350
Online 0 |
|
|
Ethernetbridge - iptables - snort-inline - Base -> Honeypot
| |
| Thema |
Verfasser |
Letzte Antwort |
| Ethernetbridge - iptables - snort-inline - Base -> Honeypot |
AndreasC ( ---.dip.t-dialin.net) |
12 Feb 2009 06:58 | Hallo Zusammen,
Ich habe auf einem Debian 2.6.18 eine Bridge zwischen eth1 und vmnet1 erstellt. In der VM läuft ein ein Opfersystem (XP Prof oder auch Ubuntu, beides möglich, aber jeweils nur eins in Betrieb) das als Honeypot dienen soll. Die Bridge wird in einem Skript in dem unter anderem auch die iptables Regeln sind (in Anlehnung an die Version von www.honeynet.org) erstellt und weiterhin verwende ich als NIPS snort_inline (ver. 2.6.1.5)
Nun habe ich jedoch ein Problem mit der Protokollierung. Wenn ich selber (manuell) z.B. einen Ping auf die Seite www.spiegel.de mache wird dieser nicht registriert (auch nicht wenn ich das System 3 Stunden durch pingen lasse) jedoch selbstständige pings (wo immer die herkommen) werden in die Snort Logs geschrieben:
Auszug snort_inline-fast: (XP Prof als Opfersystem)
01/20-14:30:46.533906 [Drop] [**] [1:466:4] ICMP L3retriever Ping [**] [Classification: Attempted Information Leak] [Priority: 2] {ICMP} 149.201.44.100 -> 149.201.44.200
01/20-14:30:49.047641 [Drop] [**] [1:466:4] ICMP L3retriever Ping [**] [Classification: Attempted Information Leak] [Priority: 2] {ICMP} 149.201.44.100 -> 10.8.0.1
Auch wenn ich mit einen Browser auf eine Internetseite zugreifen möchte (was nur gelegentlich funktioniert) wird dies nicht geloggt, jedoch folgende beiden Verbindungen die alle paar Minuten durch das Ubuntu System getätigt werden.
Auszug snort_inline-fast: (Ubuntu als Opfersystem)
01/20-15:44:55.284386 [**] [111:29:1] (spp_stream4) TCP wscale option normalized [**] {TCP} 149.201.44.100:57995 -> 141.76.2.130:80
01/20-15:45:40.163488 [**] [111:29:1] (spp_stream4) TCP wscale option normalized [**] {TCP} 149.201.44.100:58476 -> 91.189.88.37:80
Des weiteren habe ich Base zu graphischen Darstellung der Logs installiert. Kann es sein das es teilweise recht lange dauert bis da eine neue Aktion (TCP/ICMP Alarm) eingefügt wird? Kann man das irgendwie beschleunigen bzw hat man da überhaupt einfluss drauf?
Dann noch eine letzte Frage, kann mir jemand vielleicht sagen wie ich dieses System generell testen kann? Also ich möchte jetzt hier keine Erklärung fürs Hacken von euch, aber wenn der ein oder andere vielleicht weiß was man machen kann, was dann auf jedenfall registriert werden sollte wäre ich schon sehr dankbar darüber.
Da ich mir nicht ganz sicher bin wer dran schuld ist (iptables, snort_inline, Base (oder vielleicht doch ich selber?!?) habe ich dies mal unter Firewall eingebracht. Bitte seid mir nicht böse wenn es woanders besser aufgehoben wäre.
Danke schonmal im Vorraus an alle!
Gruß Andreas |
| ||
| RE: Ethernetbridge - iptables - snort-inline - Base -> Honey... | Ralf ( ---.dip.t-dialin.net) | 11 Feb 2009 06:49 |
Hallo Andreas,
das ist schwer zu sagen, wo das Problem ist. Prüfe doch bitte stichpunktartig die einzelnen Systeme.
1. Wurde die Bridge mit brctl oder von VMware selbst erstellt?
2. Prüfe die Konfiguration der Bridge.
3. Nehme Snort raus. Setze nur eine Protokollregel in iptables. Protokolliert nun iptables die Pakete?
Base ist nicht Echtzeit und muss manuell neu geladen werden oder per Javascript dazu aufgerufen werden. Wo ist die Datenbank? Wie protokolliert Snort in die Datenbank? Was sagt Snort, wenn Du es beendest? Wie sehen die Statistiken aus?
Gruß,
Ralf
| | RE: RE: Ethernetbridge - iptables - snort-inline - Base -> H... | AndreasC ( ---.dip.t-dialin.net) | 11 Feb 2009 11:13 |
Hallo Ralf,
zunächst Danke für deine Hilfe.
Zu 1.
brctl delif br0 ${INET_IFACE} 2> /dev/null
brctl delif br0 ${LAN_IFACE} 2> /dev/null
ifconfig br0 down 2> /dev/null
brctl delbr br0 2> /dev/null
ifconfig $INET_IFACE 0.0.0.0 up -arp
ifconfig $LAN_IFACE 0.0.0.0 up -arp
brctl addbr br0
brctl addif br0 ${LAN_IFACE}
brctl addif br0 ${INET_IFACE}
brctl stp br0 off
Den Teil habe ich fast 1 zu 1 übernommen und es funktoniert auch so.
Zu meinem eigentlichen Problem das von Snort-Inline nichts protokolliert wurde muss ich wohl zu meiner Schande gestehen das ich IPTables anfänglich nicht ganz richtig verstanden hatte. Ich habe daher einmal zu Testzwecken meine IPTables auf folgende beschränkt:
iptables -P INPUT QUEUE
iptables -P FORWARD QUEUE
iptables -P OUTPUT QUEUE
und siehe da, auf einmal wird nahezu alles protokolliert. Was mir an Base mittlerweile aufgefallen ist, ist das es wohl anscheinend an die Begrenzung des Systems (Hardware, Prozessor, Arbeitsspeicher) gekommen ist. Leider steht mir für die Arbeit "nur" ein AMD Athlon XP 2000+ - 1,67 GHz mit 1,5 GB Ram zur Verfügung. Ich habe einmal ein fertiges Honeywall-Image (mit Base) auf meinem Notebook in einer VM laufen lassen (Dual Core 2 mit 2 GB Ram) und da geschah die aktualisierung "fast" in Echtzeit, aber immerhin deutlich schneller.
Ich habe die Datenbank auf der Honeywall. Ich habe also demnach kein zusätzliches System zur Auswertung wie es eigentlich sein sollte. Ich habe also quasi auf meiner Honeywall die VM mit dem Opfer, einen MySQL Server sowie Base laufen. wird wohl alles was viel für das System sein.
Ich habe nun das IPTabels Regelwerk soweit auf meine Bedürfnisse angepasst (ein paar Dinge generell verboten, aber immer noch den größten Teil an Snort-Inline übergeben).
Was ich jetzt nur noch gerne funktionsfähig hätte, wäre ein Limittierung des Traffics (z.b. 50 TCP pro Stunde oder so) jedoch klappt das nicht so richtig.
SCALE="hour"
TCPRATE="10"
UDPRATE="20"
ICMPRATE="50"
OTHERRATE="10"
iptables -N tcpHandler
iptables -N udpHandler
iptables -N icmpHandler
iptables -N otherHandler
### als Bsp ICMP, läßt sich ja leicht testen ###
iptables -A FORWARD -p icmp -i $LAN_IFACE -m state --state NEW -m limit --limit ${ICMPRATE}/${SCALE} --limit-burst ${ICMPRATE} -s ${host} -j icmpHandler
iptables -A FORWARD -p icmp -i $LAN_IFACE -m state --state NEW -m limit --limit 1/${SCALE} --limit-burst 1 -s ${host} -j LOG --log-prefix "Drop icmp after ${ICMPRATE} attempts"
iptables -A FORWARD -p icmp -i $LAN_IFACE -m state --state NEW -s ${host} -j DROP
iptables -A icmpHandler -j LOG --log-prefix "OUTBOUND CONN ICMP: "
iptables -A icmpHandler -j QUEUE
Wenn ich nun von meinem Opfersystem aus "die Welt anpinge" und mir dann die Log-Dateien anschaue, so erscheinen dort dann die ganzen ICMP Meldungen und irgendwann auch die verworfenen. Jedoch werden die ICMP Versuche nach erreichen des Schwellwertes für den Rest der Stunde nicht verworfen, sondern nur ein paar, dann gehen wieder ein paar durch und wieder nicht.
Woran kann das noch liegen??
Danke
Gruß Andreas | | RE: RE: RE: Ethernetbridge - iptables - snort-inline - Base... | Ralf ( ---.dip.t-dialin.net) | 12 Feb 2009 06:58 |
On 11 Feb 2009 11:13 'AndreasC' wrote:
> Jedoch werden die ICMP Versuche nach erreichen des Schwellwertes für den Rest der Stunde nicht verworfen, sondern nur ein paar, dann gehen wieder ein paar durch und wieder nicht.
> Woran kann das noch liegen??
>
Wie prüfst Du? Mit Ping und durch Auswertung der Protokolle? Welchen Kernel verwendest Du? Da gibt es unter Umständen in Abhängigkeit der Kernelversion unterschiedliche Probleme mit der Zustandüberwachung. TCP ist unter Umständen besser für den Test.
Gruß,
Ralf
|
[ Zurück ] Um ein neues Thema hinzu zu fügen müssen sie eingeloggt sein.
|
|
|
|
Welche Distribution verwenden Sie?
| |
|
|
|
17 Oct 2008: