Re: kleines netzwerk tool

From: Marian Hettwer <mh(at)kernel32.de>
Date: Wed, 24 Jan 2007 10:39:58 +0100

Hi Bernd,

On Wed, 24 Jan 2007 10:11:46 +0100, Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> On Wed, Jan 24, 2007 at 08:59:12AM +0100, Marian Hettwer wrote:
>> Hallo Liste,
>>
>> ich bin grade auf der Suche nach einem kleinen Tool welches ich
>> einsetzen kann, um zum Beispiel einen connect auf einen Apachen zu
>> machen, einen Request abzusetzen, aber dann die entsprechenden
>> Rückgabewerte des apachen zu ignorieren.
>> Im speziellen Fall möchte ich einen beliebigen String dem apachen vor
>> die füße werfen und dann aber ignorieren, daß er die Verbindung
> beenden
>> möchte. Sprich die FIN's ignorieren.
>> telnet reagiert leider aufs FIN und schließt die Verbindung
>> netcat (nc) ebenfalls :(
>
> Nein - die beiden Programme machen das nicht, sondern der Kernel.
> Jedenfalls teilweise.
Oha.

> Da die IIRC FIN-Packete auch Daten enthalten können wird es vermutlich
> auch schwierig die per Packetfilter zu entsorgen.
Packetfilter ist ein gutes Stichwort... ich müsste doch theoretisch (rein zum testen) FIN Pakete von dem spezifischen Host droppen können...
Mit pf(4) könnte das vielleicht so aussehen:

drop in on $interface proto tcp from $hostname flags F

Mal gucken ob das tut...

>
>> Irgendeiner ne Idee wie ich das erreichen kann?
>>
>> Hintergrund der Geschichte:
>> Es gibt nen blödes P2P Netz namens DCPP (http://www.dcpp.net/) bei dem
>> man scheinbar sagen kann "Hej Ho, ich behaupte mal, ich hab diese IP und
>> den TCP Port, los, connected euch alle zu mir".
>> Ich kann also ne x-beliebige IP Adresse angeben und alle anderen Peers
>> connecten drauf los.
>> Wenn hinter der angegebenen IP aber nen Apache läuft, ist der gnadenlos
>> überfordert mit der Menge an Anfragen (die ja gar kein http sind). Und
>> der doofe dcpp client reagiert scheinbar nicht auf den Verbindungsabbau
>> des apachen. Ergebnis: Apache slots sind sinnlos belegt bis der Timeout
>> zuschlägt.
>
> Evtl lässt sich mit Accept-Filtern was machen.
> => accept_filter(9)/accf_http(9)
> Der Kernel verschweigt dem Programm den Connect, bis er einen request
> sieht.
> Du müsstest den Filter wohl patchen, damit der keine anderen Daten
> durchlässt.
> Der Kernel dann braucht zwar immer noch den Socket, aber du hast keine
> Resourcen beim Apache belegt.
das wäre ein Lösungsansatz um den angegriffenen Apachen zu entlasten.
Leider wird das mit accept_filter / accf_http nix, da die angegriffene Kiste eine Linux Maschine ist :(

Mir gings ja vielmehr darum selbst zu testen wie sich der Apache verhält wenn ich als Client das FIN ignoriere.

>
>> Ich würde nun gerne dieses Verhalten nachstellen (ignorieren des
>> Verbindungsabbaus), damit ich gucken kann wie und ob mod_security beim
>> apachen für dieses Problem abhilfe schafft.
>
> Inwiefern ignorieren die anderen den Verbindungsabbau?
Man kann in der Apache prozessliste (server-status) recht gut sehen, dass die Anfrage reinkommt, vom Apachen mit einem BAD-REQUEST beantwortet wird (woraufhin der Apache gerne die Verbindung beenden würde), aber die gegenseite ist recht unbeeindruckt und hält die Verbindung offen (schickt aber keine weiteren Anfragen).
Verschwinden tut die entsprechende Verbindung scheinbar erst, nachdem der Timeout erreicht ist.
In wiefern ich das so korrekt interpretiere weiss ich auch nicht... Ich müsste mich wohl mal mit tcpdump auf die Lauer legen.
Das wird aber schwieriger, da diese Angriffe nur kurz, aber dann intensiv, auftreten. Wann sie auftreten ist ebenfalls unklar.

> Klingt für mich eher danach, als wenn sich die Protokolle einfach
> nur verhacken, also keiner einen Abbau anfordert, ansonsten würde es
> keinen Sinn ergeben, dass der Apache nach dem Timeout doch noch was
> erreicht.
>
Da hast du recht.
Aber wie sollte man es sonst erklären.
Client schickt Request "FOOBAR" an den Apachen.
Der Apache sagt "BAD REQUEST" und würde dann die Verbindung beenden.
Das kann man nachstellen in dem man einfach ein "telnet $HOST 80" macht und "FOOBAR" eingibt. Ergebnis: Bad Request und Verbindung zu.
Im Falle der Angreifer steht die Verbindung nach dem Bad Request noch fuer 5 Minuten (Timeout 300) in der Prozessliste.
hm hm...

Aber danke für den Input! :)

Gruß,
Marian

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 24 Jan 2007 - 10:41:23 CET

search this site