war auch mein erster Gedanke. Aber wenn Honeywall in der Beziehung wieder aufgemacht wird kann das Honey-System doch für Angriffe mißbraucht werden.
Und wenn jetzt generierte Pakete zum Angreifer durchgelassen werden, nimmt der zum testen einfach eine echte Attacke. Was solls? Dies wird er schon lokal filtern. Wenn der Angriff nicht ankommt => Honeypot. Wenn Honeywall alles zum Angreifer durchläßt, kann er das System wiederum fürs Angreifen nutzen. Somit Honeypot seeehhr kontraproduktiv.
Aber das Paket geht doch den selben Weg raus, wie es rein gekommen ist, im Falle eines Pings. Es ist doch ungefährlich die korrekte Antwort zurückzuschicken, wenn es auf dem Hinweg schon kein schaden angerichtet hat. Und wenn man die Absenderadresse fälscht um sozusagen über Bande einen Rechner angreifen will, kommt zum echten Absender keine Rückantwort, solche Pakete sind also untauglich für den Honeypot-Test und können auch gefiltert werden. Außerdem stellt man doch Honeypots nicht so auf, die stehen doch wenigsten in der DMZ.
Ich erkenne nicht das Problem, bin aber auch nicht Träger des schwarzen Gürtels in Hacken oder Honeypots... Kann man jemand einen Dummen erklären warum das so nicht geht?
Ich glaub der Knoten ist jetzt bei mir geplatzt. Problem für den Honeypot ist es zu erkennen _ob_ die Sourceadresse gefälscht ist. Deswegen muss er alles filtern. Ich war irgendwie auf den Trip das man eine gefälschte Adresse erkennen könnte, kann man aber nicht, außer man zeichnet die Route auf die das Paket genohmen hat, was aber etwas schwierig sein dürfte.
Zwar auch ohne scharzen Gürtel, aber ich denke du wirst immer ein infiziertes von einem nicht-infizierten unterscheiden köennen und darum handelt es sich ja hier wohl im wesentlichen.
Selbst wenn auch diese Schwachstelle beseitig würde, wird irgendwann auffallen, dass nur der Honeypot infiziert werden kann, während alle anderen Rechner "gut" gesichert sind.
also eigentlich besagt dieser test gar nichts, ausser das zwischen dem rechner von dem der Hping abgesetzt wurde und dem server der antwortet irgendwo ein snort_inline laeuft was auf shellcode trigger und solche packete verwirft oder veraendert...wenn das zum testen auf honeypots verwendet werden sollte, kann ich nur jedem raten ein snort_inline in seinem netz laufen zu lassen, denn dann gilt ja jeder rechner im netz als honeypot und wird somit von hackern verschont...genial =)
"This allows us to detect a honeywall trivially by constructing some network communication containing strings which match snort inlines rewriting database and check if the communication is received in unaltered form."
Amir sollte sich mal das Paper "NoSEBrEaK Attacking Honeynets" von Maximillian Dornseif, Thorsten Holz, Christian N. Klein anschauen. Das ist aus dem Jahr 2004 und enthält obige passage.
indem man die Honeywall einfach etwas besser macht und die erwartete Antwort zurückgibt. Fertig.
Aber wenn Honeywall in der Beziehung wieder aufgemacht wird kann das Honey-System doch für Angriffe mißbraucht werden.
Und wenn jetzt generierte Pakete zum Angreifer durchgelassen werden, nimmt der zum testen einfach eine echte Attacke. Was solls?
Dies wird er schon lokal filtern. Wenn der Angriff nicht ankommt => Honeypot.
Wenn Honeywall alles zum Angreifer durchläßt, kann er das System wiederum fürs Angreifen nutzen. Somit Honeypot seeehhr kontraproduktiv.
Ich erkenne nicht das Problem, bin aber auch nicht Träger des schwarzen Gürtels in Hacken oder Honeypots...
Kann man jemand einen Dummen erklären warum das so nicht geht?
Ich war irgendwie auf den Trip das man eine gefälschte Adresse erkennen könnte, kann man aber nicht, außer man zeichnet die Route auf die das Paket genohmen hat, was aber etwas schwierig sein dürfte.
Selbst wenn auch diese Schwachstelle beseitig würde, wird irgendwann auffallen, dass nur der Honeypot infiziert werden kann, während alle anderen Rechner "gut" gesichert sind.
Muesst nur mal Feierabend sein :/
"This allows us to detect a honeywall trivially by constructing
some network communication containing strings
which match snort inlines rewriting database and check
if the communication is received in unaltered form."
Amir sollte sich mal das Paper "NoSEBrEaK Attacking Honeynets"
von Maximillian Dornseif, Thorsten Holz, Christian N. Klein
anschauen. Das ist aus dem Jahr 2004 und enthält obige passage.