Newsgroup: it.comp.sicurezza.varie
Titolo: fg-gip: cos'e'?

Salve a tutti.
Notando un curioso lampeggiare continuo della spia dati sul mio modem e
controllando i log di iptables ho scoperto che č da quando ho avviato il
PC (circa 2 ore e mezzo fa) che qualcuno, sempre con lo stesso IP
(FranceTelecom, se ho interpretato bene il whois) sta bussando alla mia
porta 3294 con una cadenza di un paio di volte al secondo. Ora, la cosa
non mi preoccupa particolarmente dato che iptables blocca tutto e che
comunque non ho nulla in ascolto su quella porta, ma vorrei capire che
accidenti vuole questo tizio.
Sgooglando e cercando su altri motori di ricerca ho scoperto solo che
questa porta č associata al sopracitato fg-gip: qualcuno sarebbe cosě
gentile da dirmi che cos'č? Ho cercato e ricercato, ho trovato diverse
pagine che lo nominano (quasi sempre in liste porte-servizi) ma non ne
ho ancora trovata una che mi spieghi che cos'č.
Grazie e ciao.
-- 
Lucio.
"Tutto quello che possiamo fare č sperare per il meglio, aspettarci 
il peggio e accontentarci di una via di mezzo"

 accidenti vuole questo tizio.
Posta qualche riga di log.
Fabio

 Posta qualche riga di log.
 
Mar  6 14:53:06 matrix248 kernel: fw-alte: IN=ppp0 OUT= MAC=
SRC=193.248.147.132 DST=80.116.113.68 LEN=44 TOS=0x00 PREC=0x00 TTL=242
ID=28033 PROTO=TCP SPT=65502 DPT=3294 WINDOW=2048 RES=0x00 ACK SYN
URGP=0 
Mar  6 14:53:06 matrix248 kernel: fw-alte: IN=ppp0 OUT= MAC=
SRC=193.248.147.132 DST=80.116.113.68 LEN=44 TOS=0x00 PREC=0x00 TTL=242
ID=28071 PROTO=TCP SPT=65502 DPT=3294 WINDOW=2048 RES=0x00 ACK SYN
URGP=0 
Mar  6 14:53:07 matrix248 kernel: fw-alte: IN=ppp0 OUT= MAC=
SRC=193.248.147.132 DST=80.116.113.68 LEN=44 TOS=0x00 PREC=0x00 TTL=242
ID=28105 PROTO=TCP SPT=65502 DPT=3294 WINDOW=2048 RES=0x00 ACK SYN
URGP=0 
Mar  6 14:53:07 matrix248 kernel: fw-alte: IN=ppp0 OUT= MAC=
SRC=193.248.147.132 DST=80.116.113.68 LEN=44 TOS=0x00 PREC=0x00 TTL=242
ID=28143 PROTO=TCP SPT=65502 DPT=3294 WINDOW=2048 RES=0x00 ACK SYN
URGP=0 
Mar  6 14:53:08 matrix248 kernel: fw-alte: IN=ppp0 OUT= MAC=
SRC=193.248.147.132 DST=80.116.113.68 LEN=44 TOS=0x00 PREC=0x00 TTL=242
ID=28177 PROTO=TCP SPT=65502 DPT=3294 WINDOW=2048 RES=0x00 ACK SYN
URGP=0 
Mar  6 14:53:08 matrix248 kernel: fw-alte: IN=ppp0 OUT= MAC=
SRC=193.248.147.132 DST=80.116.113.68 LEN=44 TOS=0x00 PREC=0x00 TTL=242
ID=28215 PROTO=TCP SPT=65502 DPT=3294 WINDOW=2048 RES=0x00 ACK SYN
URGP=0 
Queste sono le ultime 6, ma se vuoi ne ho abbastanza da riempire un file
da più di 3 Mb, tutte uguali.
Comunque chiunque fosse ce l'aveva unicamente con l'IP che mi era stato
assegnato in quel momento (ADSL Alice): dopo essermi scollegato per una
mezz'oretta i tentativi sono cessati.
Grazie e ciao.
-- 
Lucio.
"Tutto quello che possiamo fare è sperare per il meglio, aspettarci 


 URGP=0 
Questo potrebbe essere il backscatter di un DoS a carico del povero
193.248.147.132 condotto spoofando l'ip che avevi assegnato in quel
momento (80.116.113.68). Come puoi vedere dai flag TCP si tratta di 
_risposte_ a dei tentativi di connessione. Si potrebbero stimare un
30-40 ip sorgente apparenti diversi come origine del flood, ma sono
ipotesi che lasciano il tempo che trovano.
Se questo e' traffico NEW in entrata direi che tu sei stato solo un
impotente spettatore del fattaccio. 
Fabio

 impotente spettatore del fattaccio. 
Quindi mi sarei preso solo un po' di "colpi di rimbalzo", se ho ben
capito.
Ok, grazie e ciao.
-- 
Lucio.
"Tutto quello che possiamo fare č sperare per il meglio, aspettarci 


 capito.
E una regola reject anziche' drop avrebbe anche giovato, in questi casi
(non ti avrebbe parato il culo, eh)

 (non ti avrebbe parato il culo, eh)
 
Uhm, non ci avevo pensato. Quindi, se la cosa mi capitasse di nuovo,
potrei tentare di risolvere la cosa impostando temporaneamente una
regola reject specifica per la porta "richiesta", in modo da rendere
esplicito che non c'è nulla a cui collegarsi?
Grazie e ciao.
-- 
Lucio.
"Tutto quello che possiamo fare è sperare per il meglio, aspettarci 


 l'host che ti inviava le risposte.
Aggiungo, a titolo di chiarimento di quanto detto da HC, che se tu avessi
avuto reject anzichè drop, avresti dato una mano al floodato perchè gli
RST provenienti dalla tua macchina avrebbero contribuito ad liberare i
buffer allocati dal flood...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 :-p
L'ho vista subito dopo... :-/
Cmq, io ho detto ben tre parole più di te... tiè tiè tiè... :-P


On Sat, 06 Mar 2004 14:00:02 GMT, lchiandu wrote:
[CUT]
Ringrazio tutti per il thread chiarificatore: adesso ho le idee più
chiare.
Ciao.
-- 
Lucio.
"Tutto quello che possiamo fare è sperare per il meglio, aspettarci 


> Il guessing l'hai fatto a partire dalla sequenza degli IPID, giusto?
C'ho provato :-) Mi sembrava una stima ragionevole.
Fabio

 esplicito che non c'è nulla a cui collegarsi?
Be', al limite dovresti farlo sempre per evitare che i lamerozzi di
turno ti spoofino l'ip per dei SYN flood come quello, ma i vantaggi
sono per il sistema attaccato [1]. Ci sono dei pro e dei contro per
chi e' vittima di questo attacco: se tu fai --reject-with tcp-reset
aiuti i sistemi remoti dal punto di vista del "SYN flood" in se per
se, perche gli chiudi il socket aperto in SYN-RECEIVED, ma nel caso
in oggetto gli avresti peggiorato la situazione in termini di banda
perche' al flood diretto si sarebbe sommato quello dei tuoi RST. Il
SYN flood di cui tu hai visto gli effetti era, infatti, volto sia a
esaurire la banda disponibile sia le risorse della macchina, questa
e' la complicazione. Il rate, infatti, sembra essere di 2 SYNACK al
secondo e, se accettiamo l'ipotesi dei 40 flood, facendo 2 conti...
(della serva)
2 pack/s*flood x 50 byte/pack x 40 flood = 4000 byte/s = 32.000 bps
E contando le sue risposte fanno circa 64.000 bps (un poco di meno,
in effetti, visto che ho arrotondato per eccesso a favore della mia
tesi [2]).
Andiamo a vedere:
# whois 193.248.147.132
[skip]
descr:        Network Access Server BRX
Parrebbe che si tratti d'una ISDN e, incidentalmente, i 64 kbps gli
stanno anche saturando la banda, oltre che esaurendo le risorse del
suo host [3]. L'attaccante ha approfittato della porta in LISTEN ed
ha portato (se cosi' e' andata) un DoS combinato (flood+SYN flood),
e qualunque delle due cose tu avessi fatto (REJECT o DROP) avresti,
in ogni caso, peggiorato la situazione della vittima. Tra l'altro i
tuoi log non danno indicazioni sul fatto che tu abbia fatto un DROP
o un REJECT ma, come dicevo, a mio parere cambia poco.
C'e' una certa dose di arbitrarieta' in questa analisi ma mi sembra
uno scenario plausibile, nel complesso.
Fabio
[1] in realta non rispondere ti fa risparmiare banda in uscita, ma,
    di solito, in questi casi non e' un grosso problema.
[2] suvvia, lo ha fatto anche mendel coi piselli ed e' passato alla
    storia comunque :-p
[3] in realta' e' la sua connessione ISDN il collo di bottiglia che
    limita il rate del flood osservato.

 in ogni caso, peggiorato la situazione della vittima.
Pero' il RST blocca le ritrasmissioni dei SYN-ACK (ammesso che giunga a
destinazione).

 o un REJECT ma, come dicevo, a mio parere cambia poco.
Ho impostato Iptables per droppare qualsiasi cosa eccetto le risposte
alle mie richieste.
Grazie per l'esauriente spiegazione, anche se, a causa della mia
conoscenza relativamente scarsa, ho dovuto leggermela 4 o 5 volte per
afferrarne il senso. Comunque credo di aver capito, almeno a grandi
linee, quello che mi volevi dire.
Grazie e ciao.
-- 
Lucio.
"Tutto quello che possiamo fare č sperare per il meglio, aspettarci 


 del syn-ack, non ricevendo ne' un acknowledgment ne' un reset.
Ok, ora la cosa mi è chiara (almeno credo).
Grazie e ciao.
-- 
Lucio.
"Tutto quello che possiamo fare è sperare per il meglio, aspettarci 


 a destinazione).
Direi proprio di si. C'e' un dubbio, pero', che mi sovviene riguardo
a questo caso specifico (ma che non possiamo risolvere causa logging
poco verboso che non ci mostra anche il numero di sequenza). Il flud
(se e' un flud) sembra condotto con una porta sorgente fissa [1]. In
questo caso il socket in SYN-RECEIVED dovrebbe rispondere con un ACK
e non con dei SYN-ACK, nel tentativo di risincronizzare la sessione.
Quindi: a) mi chiedo se sia il traffico di ritorno di un syn flood o
se non sia solo mascherato da tale (vero bersaglio era ichiandu [2])
b) se era un flood che diavolo di stack tcp/ip c'e' dall'altra parte
e c) perche' non me ne sono accorto subito (ma questo e' facile: son
scemo). In pratica, ammettendo l'ipotesi del flud, pare che lo stack
remoto stia usando sempre lo stesso socket chiudendolo e riaprendolo
e quindi il numero max di socket aperti contemporaneamente e' pari a
il numero di ip apparenti che partecipano al flood. Quindi, nel caso
specifico, non penso che ci fosse consunzione di risorse a carico di
quell'host, ma solo di banda.
Per avere qualche info in piu', direi ad ichiandu di fare un tracert
e contare il numero di hop tra lui e l'ip (ip apparente, aggiungerei
a questo punto) e verificare che ci sia qualche coerenza col TTL del
traffico loggato.
Fabio
[1] quindi e' un pessimo SYN flood visto che i socket aperti saranno
    al max quanti sono gli ip apparenti che partecipano al flood;
[2] flood maldestro, ovviamente.

 traffico loggato.
 
Quale IP? Intendi quello della presunta origine di questi pacchetti
misteriosi?
Temo che la discussione stia cominciando ad andare un po' troppo sul
tecnico per le mie conoscenze, non so se sarò in grado di parteciparvi
per molto.


 ne' un rst?
Come dici, non c'è modo di verificarlo, però se son DUP c'è da capir
perchè quelle risposte vengono duplicate, mentre l'ipotesi ritrasmissione
per assenza di RST salta per questioni di tempo...


 che nessuno era"disposto" a mandare ne' un ack ne' un rst?
Cosi' tanto?
da me
happycactus@wiseowl:happycactus$ cat \
/proc/sys/net/ipv4/tcp_synack_retries 
5
Quindi significa che da qualche parte c'era
1) un server con uno stack tcp malconcio oppure mal configurato
2) un qualche elemento che "stimolava" l'emissione di synack.
Potrebbe essere un semplice flood fatto direttamente dalla macchina SRC
con un qualche tool un po' naif...
Le porte non mi dicon nulla (poi, questo fg-gip.... non significa
assolutamente nulla, cercando con google non si ottiene un cavolo,
tranne il numero di porta - <rant>Veramente utili questi database di
porte</rant> )
per cui e' abbastanza difficile anche fare supposte^H^Hizioni sul
syn-flood: per quale ragione un server dovrebbe avere qualcosa in
ascolto sulla 3294?

 mostratici avevano la stessa porta sorgente)
Stessa porta sorgente in tutti i casi, la 65502.
Ciao.


 oppure varia.
Ah, scusa. Comunque anche la DPT è sempre la stessa (da li la domanda
iniziale del thread, per capire a cosa fosse associata).


 iniziale del thread, per capire a cosa fosse associata).
A nessun servizio noto, ma non e' importante: chi ha sferrato
l'attacco potrebbe aver semplicemente fatto un portscan della
vittima e trovato quella porta aperta. Cosa ci ascoltasse non
e' rilevante: potrebbe essere un demone che l'utente aveva in
ascolto su una porta non standard o qualcosa di proprietario,
ma l'importante e' che fosse aperta, per i suoi fini.
Fabio

 nebbioso.
Proviamo a fare un riassuntino:
1) flusso di 2 SYN-ACK al sec con porta sorgente e destinazione
   sempre uguali;
2) delta IP-ID tra due SYN-ACK ~ 40 => probabilmente ci sono 40 
   flood verso l'ip src apparente di questo traffico; questo e'
   un valore confortato anche da una successiva speculazione in
   merito alla banda passante teorica della vittima (se ISDN);
3) lo stack remoto ha un comportamento peculiare, in quanto con
   il socket in SYN-RECEIVED non risponde ACK, ma SYN-ACK, a un
   ulteriore tentativo di connessione con uguali porte src-dst;
4) non conosciamo i numeri di sequenza (@# \^#);
5) lo stack remoto, in apparenza, non corrisponde a nessuno tra 
   quelli piu' diffusi (Linux, *BSD, windows... forse potrebbe,
   sparo, essere un cisco); si puo' dir poco, pero', con i soli
   SYN-ACK e sapendo soltanto la lunghezza delle opzioni tcp;
6) ha una porta inusuale in listening, apparentemente;
7) non ci dovrebbero essere ritrasmissioni, visto che non penso
   ci siano stack che fanno la prima ritrasmisisone prima di .5
   secondi ed il socket, in apparenza, viene chiuso e riaperto;
8) *manca* distanza in hop tra ichiandu e la sorgente apparente
   del traffico (traceroute 193.248.147.132 va benissimo, ma un
   router a monte di quell'ip filtra i time exceeded, quindi ci
   si deve fermar li. Probabilmente e' il router immediatamente
   prima.
Per ora mi vengono in mente:
A) flood ai danni di 193.248.147.132, che ha uno stack esotico;
B) flood ai danni di 193.248.147.132, che usa syn-cookies;
C) blando flood ai danni dell'ip posseduto, in quel momento, da
   ichiandu, ma condotto in modo da dissimulare la vera natura;
C) uno scherzo a ichiandu;
D) uno scherzo di ichiandu;
Fabio stasera sushi

    router a monte di quell'ip filtra i time exceeded
Non e' vero, mi sono sbagliato.

 Il guessing l'hai fatto a partire dalla sequenza degli IPID, giusto?
E` bello quando esplicitate gli ``arcani'' dei file di log, grazie :-)
-- 
Vuoi fare colpo su di lei con me?
Fai colpo su di lei con me! Fai colpo su di lei con me!
[Dr. Gonzo : Paura e delirio a Las Vegas]