[Pluto-security] tentativo di attacco - forse

[Fabio Panigatti]

>Questa è una tecnica che si utilizza, si manda un pacchetto di ack (che
>quindi a un firewall non stateful sembra si risposta), con porta origine la
>80 (molti firewall non stateful accettano di default il traffico
>proveniente dalla 80), e porta di destinazione quella da testare: in base a
>un eventuale pacchetto di risposta, sai in che stato è la porta.

La risposta ad un pacchetto ACK e' sempre RST. Questa tecnica non serve a
vedere lo stato della porta ma a testare le acl del firewall. Comunque il
presupposto e' che l'host sia raggiungibile, cosa che e' da escludere nel
caso di Andrea, perche il suo netfilter e' dietro a un nat e il pacchetto
che ha ricevuto non e' source routed (cosa che in prima battuta scarterei
comunque, vista l'attuale politca dei provider). Quindi quel traffico (se
si escludesse la ritrasmissione) potrebbe provenire soltanto dal router o
dalla sua sottorete pubblica (se non bloccasse in ingresso i martians sul
router adsl). Il primo caso e' da escludere, perche' gli strumenti che il
router mette a disposizione non ti consentono di forgiare un pacchetto di
quel tipo. Il secondo pure, perche' chi fa la scansione non ricevera' mai
la risposta (visto che andrebeb da blixer).

Io penso che l'unica spiegazione possa essere la ritrasmissione di un FIN
di una sessione che era gia chiusa per netfilter ma non per il connection
tracking del nat del router, che probabilmente e' piu' tollerante.

Le ritrasmissioni dei FIN, tra l'altro, sono molto frequenti, soprattutto
nelle connessioni a server web di advertising o a cluster di server web.
Per dare un idea :-) (dopo 4 giorni su una una rete di una cinquantina di
client che accedono a internet):

[root@fw:~]$ grep SPT=80.*FIN /var/log/messages|wc -l
    450

La situazione qui' e' aggravata perche' non resetto i FIN ritrasmessi che
quindi vengono... ri-ritrasmessi :-) ancora tre o quattro volte.


Fabio

PS: non mi risulta che rdesktop vada sulla 33067/tcp.