Newsgroup: it.comp.sicurezza.varie
Titolo: Router e Attacchi

Ciao a tutti,
vi posso postare il log del mio router adsl...
01/01/1970 00:00:24> Firewall:IP Spoofing detected,from 192.168.100.1 to 
224.0.0.1
10/02/2005 11:19:10> Received time from Time Server 129.6.15.29
10/02/2005 11:20:12> Firewall:Winnuke detected,from 87.2.242.73 to 
87.2.134.140
E' normale che si verifichino in media ogni 2 ore attacchi di quest tipo?
Il router è configurato per loggare gli attacchi
SYN Flooding
Ping of Death
IP Spoofing
Win Nuke
Configurazione servizi disponibili esternamente
gli ho filtrati tutti
Ping from External Network
Telnet from External Network
FTP from External Network
DNS from External Network
IKE from External Network
RIP from External Network
DHCP from External Network
Router Table
      .0.0.0 0.0.0.0 192.168.100.1 ppp1
      10.0.0.0 255.0.0.0 10.0.0.2 br0
      127.0.0.1 255.0.0.0 127.0.0.1 lo0
      192.168.100.1 255.255.255.255 87.2.134.140  ppp1
consigli su come posso rendere sicura la rete?
Vorrei poter vedere i pacchetti che girano nel router ma è un po' un casino,
devo cambiare il mac address dalla mia scheda di rete su pc??
Ho provato con programmi sniffer ma mi vedono solo i pacchetti destinati 
alla mia scheda di rete su pc.
Il router li filtra... e non mi fa vedere neppure il portatile connesso al 
router...
Io vorrei capire se qualcuno si collega al mio gateway...
perchè spesso il router riceve attacchi proprio dal gateway...
Il mio ip è cambiato ora, quindi è inutile che pingate o winnukate :-)))
grazie a tutti
Max

 87.2.134.140
Questo e' l'unico ch epone qualche piccolo dubbio.
Potrebbe esserci ancora in giro qualcuno che si diverte con il winnuke,
ma tenderei ad escluderlo.
Per me, il tuo router trova solo dei pacchetti in arrivo sulla 139
causati da qualche tuo collega utente della stessa sottorete TIN che
ha la condivisione file di windows che cerca amici nell'etere.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

"roberto" <rpoggi...@softhome.net.invalid> ha scritto nel messaggio 
news:3qa2dsF...@individual.net...

10/03/2005 16:06:01> Firewall:Winnuke detected,from 87.0.159.213 to 
87.0.162.138
10/03/2005 17:41:00> Firewall:Winnuke detected,from 87.0.162.29 to 
87.0.162.138
Ti posto questo di oggi....
Anche qui allora come dici tu potrebbe essere sulla porta 139...
Timeserver etc so che si aggiorna automaticamente,
i miei dubbi riguardavano lo spoof ing e il winnuke, poi ho preso ed 
incollato senza badare agli altri comandi
sul file di log :-)
Grazie per la risposta esauriente.
X.

 Anche qui allora come dici tu potrebbe essere sulla porta 139...
Non e' che, come dico io, potrebbe, e' che il winnuke era composto da
pacchetti *strani* inviati sulla porta 139.
Si suicidavano i vecchi winsock, su win95 e nt.
E' per quello che non ci credo, al winnuke, troppo vecchio.


 pacchetti *strani* inviati sulla porta 139.
Se non ricordo male pacchetti OOB
-- 
Money is like a promise, easier made than kept. 
News 2000 [v 2.06] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 
Yes, sir, la sua memoria non la tradisce.
La nuova frontiera:
L'amarcord sugli attacchi informatici dei (bei?) tempi andati.


"roberto" <rpoggi...@softhome.net.invalid> ha scritto nel messaggio 
news:3qeso7F...@individual.net...

visto la vostra preparazione,
colgo l'occasione per farvi una domandona...
visto che ormai parecchi server hanno disattivat la risposta ai messaggi 
ICMP ping,
perovvi motivi di sicurezza....
come diavolo si fa a fare un traceroute decente?
risposta:
non si fa....
nelle trame ip e tcp non c'è nulla sulla storia (ip router passati) del 
pacchetto...
per cui da quel che so niente trace...
sig... possibile..?

 non si fa....
Beh, non tutti i traceroute usano ICMP.
Ad esempio, per default su linux si usa UDP.


 pacchetto...
A parte il fatto che i metodi di tracerouting si basano sul ttl dei
pacchetti, ciò che hai scritto non è vero, in linea di principio.
Esiste un campo RECORD_ROUTE nell'header ip...
root@3[~]# ping -R 10.1.2.82
PING 10.1.2.82 (10.1.2.82): 56 data bytes
64 bytes from 
10.1.2.82
: icmp_seq=0 ttl=126 time=32.1 ms
RR:     10.66.0.250
        10.0.0.12
        10.1.1.1
        10.1.2.82
        10.0.0.6
        10.66.0.1
        10.66.0.250
64 bytes from 
10.1.2.82
: icmp_seq=1 ttl=126 time=27.2 ms        (same route)
64 bytes from 
10.1.2.82
: icmp_seq=2 ttl=126 time=37.8 ms        (same route)
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?


si non ci avevo pensato, ma il server deve pur sempre rimandare
indietro una risposta in udp...
Ad esempio UDP su che porta?

 Ad esempio UDP su che porta?
Un consiglio spassionato: fai tabula rasa e ricomincia.



è un opzione di Class number la Record route.
Si è vero, io stavo guardando l'header "classico".


scusa, fai tabula rasa su cosa?
che non ho conoscienze su TCP/IP ?
a me interessa il software e l'hardware,
faccio programmazione e sono ingnegnere
di robotica e intelligenzaartificiale, quindi non sapere alcune cose sul
TCP/IP non è che sia un gran danno... non è il mio campo.
ma tabula rasa direi di no su tutto...
magari cancello qualche partizione..
piuttosto spiegami  perchè alcuni server non rispondono ai ping,
se lo sai dimmelo scusa,
sarà per risparmiare banda?
per risparmiare tempo di processore?
per motivi anche di sicurezza?
boh, dimmi la tua idea e facciamo prima :-)
A.

 Ad esempio UDP su che porta?
Segui il consiglio di whip. Per questo argomento, fai tabula rasa
e ricomincia. :-)
Non e' un'offesa, eh, parti da presupposti errati, e' piu' facile
ripartire da capo.
Di solito si gioca sul ttl del pacchetto che invii per vedere dove
si ferma.


 ha passato li pacchetto...
Naahhh. Puoi definire tu il ttl del tuo pacchetto di test.
E cosi' lo costringi a morire a distanze precalcolate da te.
Pensa adesso a come si puo' sfruttare questo fatto nel tracerouting.


 Pensa adesso a come si puo' sfruttare questo fatto nel tracerouting.
Quasi lo dimenticavo.
Se Whip ti dice qualcosa sulle reti che ti sembra assurdo, prima
dagli retta lo stesso, per default, che poi scoprirai che assurdo
non era.
Ciao, whip, spero di non averne sparate di troppo grosse. ;-)


           |roberto poggi   
rpo...@softhome.net
non sto dicendo che dite cose assurde, anzi, le trovo coerente con ciň che 
sň,
semplicemente non ho pensato molto su queste problematiche.
č solo che a volte specialmente nei NG quando non ci si conosce si
pretende che in poche righe ci si capisca e ci sono persone che comunque
sono abituate a "trattare male gli altri".
Insomma da poche righe ti assicuro e vi assicuro che non si puň capire
 la conoscienza di una persona.  :-)
anche se si dicono imprecisioni, č vero....
ho capito perfettamente il trucchetto TTL....carino....  bastava poco no :-)
Ciao

 ma non quali e chi...
Si parte definiendo un ttl che inizia di 1 e lanci una richiesta ICMP
di echoreplay all'indirizzo che desideri raggiungere. Il primo server
della catena trova che il ttl è defunto e ti rimanda la risposta. Hai
ottenuto il primo server. Al secondo pacchetto alzi il ttl a 2 ed 
ottieni il secondo passaggio... Aumenti sempre di 1 fino a 
raggiungere la tua destinazione.
-- 
IBM: Itty Bitty Machines


"Due di Picche" <mega...@TOGLISPAMaruba.it> ha scritto nel messaggio 
news:dhuqnt$onu$1...@area.cu.mi.it...

si si, dopo la risposta di Roberto ho inteso il trucchetto...
grazie però.

 Ad esempio UDP su che porta?
No UDP. ICMP. TIME_EXCEEDED, per essere precisi, e le inviano (a turno) 
i router posto sulla tratta di transito, fino a quando non si raggiunge 
la destinazione, e non la destinazione stessa.
Consiglio anche io, se vuoi capirne seriamente qualcosa, di cancellare 
quello che hai carpito a spizzichi e di iniziare un buon testo sul TCP/IP...

 router...
Uhm... dove sarebbe il portatile? Se e' collegato a uno switch integrato
nel router probabilmente non e' colpa del router, bensi' di qualche conf
del portatile (o dell'altro host).
Fabio

 pacchetti *strani* inviati sulla porta 139.
In realta' andrebbe bene qualsiasi porta tcp in ascolto, e forse (ma
non ho mai provato) anche all'interno d'una sessione stabilita dalla
vittima stessa. I tool lameri usavano la 139/tcp perche' solitamente
era l'unica porta tcp aperta su una macchina win9x, ma c'erano anche
aggeggi piu' "avanzati" che provavano pure sulla 135/tcp.
Fabio

       192.168.100.1 255.255.255.255 87.2.134.140  ppp1
Il router conosce benissimo dov'e' 192.168.100.1 e perche' si trova li' e
quindi non dovrebbe rilevarti questo traffico come tentativo di spoofing.
Fabio

 TCP/IP...
la questione è che non sono un hacker, e non sono un sistemista di rete,il 
mio lavoro è altro.
Io conosco le cose fondamentali del TCP/IP (standard...), non le tecniche 
per hackerare o le altre diavolerie per fare "danni".
Voi in realtà conosciete alcuni dei modi per usare impropriamente i 
protocolli.
Ripeto, non si può capire da una frase ciò che si sà tenetelo a mente.
Poi se vogliamo conosciere il TCP/IP significa conscere i protocolli,
ma è vero anche che bisogna conoscere i modi per usarlo impropriamente? Io 
direi proprio di no.
Se poi fai l'amministratore di rete beh... ti è utile sapere anche quello.
Allora potevate consigliarmi un buon libro di hacking :-)
Ma non vuole essere una polemica,
per quel che mi serve non devo conoscere il TCP/IP.
Certo, il trucchetto del TTL non mi verrai a dire ch'è TCP/IP cambiare 
impropriamente il campo TTL
in modo che il pacchetto muoia... significa modificarlo impropriamente, non 
utilizzare più quel campo per lo scopo che aveva...   che poi è una boiata 
intendiamoci chiaro chiaro...
difficile da capire? dove ? quando? e perchè?
Quindi ripeto, consigliatemi un hacking book... non una guida TCP/IP.
Non sono da confondere secondo me le due questioni, sebbene legate.
Da una parte c'è l'uso proprio di TCP/IP dall'altra l'uso improprio.
Secondo me voi ne fate un tuttuno.
:-)
A.

 ha scritto nel messaggio 
news:MPG.1dadb4ac6...@127.0.0.1...

appunto è quel che mi sembrava parecchio strano trovare nel log il gateway 
del router!

questo router probabilmente anzi sicuro lavora come switch sulla lan,
mentre per quando riguarda vedere i pacchetti direttamente sul router non 
c'è nessuna opzione
non possono essere visti direttamente sul router.

 non possono essere visti direttamente sul router.
Se proprio sei curioso, quindi, puoi vedere se hai la possiiblita' di
fare un dnat verso l'ip del tuo host di tutto il traffico in ingresso
sull'interfaccia esterna del router. Se non puoi farlo di tutto tutto
potresti limitarti a fare nat per le porte tcp 135, 139 e 445 (stiamo
parlando del traffico relativo al "sospetto" winnuke, che io ora vedo
su queste porte). Ovviamente, ti dovrai accertare che la tua macchina
sia _protetta_adeguatamente_. Toglierei questo nat al piu' presto.
Se, invece, non lo vuoi/puoi fare... ti regalo un pacchettino che con
ogni probabilita' e' molto simile ai tuoi winnuke:
09:37:13.476507 IP 151.36.105.202.1469 > 151.36.98.219.445: S \
1934786589:1934786589(0) win 65535 <mss 1460,nop,nop,sackOK>
   0x0000:  4538 0030 e922 4000 7d06 197f 9724 69ca  E8.0."@.}....$i.
   0x0010:  9724 62db 05bd 01bd 7352 801d 0000 0000  .$b.....sR......
   0x0020:  7002 ffff 0e5d 7eea 0204 05b4 0101 0402  p....]~.........
                           ^^^^
... dove con ^^^^ ho evidenziato la parte incriminata.
Fabio

 Secondo me voi ne fate un tuttuno.
Non direi.
Perennemente presente sulla mia scrivania c'è "TCP/IP Illustrated" di 
W.Richard Stevens, ovvero "La Bibbia" del TCP/IP: 20a ristampa di un 
testo del 1994, scritto da uno di coloro che il TCP/IP lo hanno 
(letteralmente) creato.
Traceroute e il suo funzionamento sono spiegati al capitolo 8 (di 30), 
immediatamente dopo la spiegazione del funzionamento del protocollo ICMP 
e del programma "ping".
*Molto prima* di toccare la parte "realmente profonda" dello stack 
protocollare, come il concetto di porta, UDP, TCP e la gestione delle 
finestre di trasmissione.
Nella mia accezione, sapere come funziona traceroute e perchè *è* una 
conoscenza *di base* del TCP/IP...
Bye!

 Bye!
Vogliamo mettere su come funziona la Cwnd? E le politiche sul controllo 
della congestione...  :-)
avevo previsto questa risposta con citazione della bibbia del TCP/IP.
giusta precisazione, ma forse le politiche di ontroll odella congestione 
vengono
successivamente perchè più complesse? più belle?

 successivamente perchè più complesse? più belle?
Perchè, semplicemente, hanno un funzionamento di livello più "elevato", 
dal punto di vista delle funzionalità da raggiungere...
Trasponendola sul linguaggio umano, potremmo (IMHO) dire che
- IP è l'alfabeto
- ICMP è la punteggiatura
- TCP e UDP sono le parole
- il congestion control è parte della grammatica
- le applicazioni sono le opere scritte
Gli argomenti si appoggiano uno sull'altro, con gli ultimi che sono 
dipendenti dai primi.
Nulla di strano che un testo di alfabetizzazione le affronti in questo 
ordine ;-)

 ha scritto nel messaggio 
news:di0j8b$u3t$1...@half.spin.it...

:-)
la mia era più una burla. tutto vero ciò che dici, un punto di vista 
particolare questo.
in grammatica però non esiste la pila protocollare e  gli Hardware 
Abstraction Layer...
se esistessero noi potremmo scrivere in italiano corretto partendo dallo 
scrivere la divina commedia
per poi arrivare alla conoscienza della punteggiatura... e ancor di più 
senza conoscere l'alfabeto
sarebbe molto divertente.
A.

 Si è vero, io stavo guardando l'header "classico".
Perchè, esiste un header ip moderno?


 In realtà però, ti si inondava di echo *reply*
Oh, beh, potrei anche essere in netta superiorità di banda
e ricorrere ad un flood diretto di request. :-)


 protocolli.
L'unico modo di tentare di sovvertire un protocollo è conoscerlo. ;-)


 ha scritto nel messaggio 
news:di0qk7$klt$3...@posted-at.bofh.it...

certo, quello che citi è un prerequisito.
ma è anche possibile conoscere molto semplicemente il modo per sovvertirlo 
avendolo sbirciato
qua e la e poi costruire ad hoc un programma.... senza sapere tutti i 
meandri del protocollo.
Molti oggi fanno così. :-)
Mentre per cercare nuovi modi ed usi impropri c'è bisogno diciamo di una 
certa creatività...
non è detto però che conoscere un protocollo significhi anche saperlo usare 
impropriamente.
E' questa la differenza che citavo io.
A.


era tra virgolette...
Ciao

 motivazioni?
Perchè alcuni ritengono di rendere la macchina meno visibile così...

 era tra virgolette...
Ah, ok. :-)
Ciao.

 Perchè alcuni ritengono di rendere la macchina meno visibile così...
e finalmente ci siamo arrivati alla questione....!!!
che in realtà pittura un po' com'è la rete, e se vogliamo anche scelte di 
alcuni amministratori.
magari tu non le condividi, ok, però non è un errore.
A.

 Ciao.
ok, come ho risposto,
queste sono scelte, sono daccordo che esistono altri modi,
tutto č insicuro a questo punto.
Voi dite ch'č irrilevante, ma non ne sarei cosě convinto.
Certo non crei un blocco sul server, ma consumi tempo macchina e con le 
bande crescenti non č irrilevante.
ricordiamoci che la banda cresce di piů della potenza dei processori nel 
tempo.
Per cui con una banda crescente si avranno piů pacchetti da processare.
Con tutto il lavoro che si fa in hardware e software per ottimizzare e 
parallelizzare questi processi
io non direi trascurabile.
A.

senza polemica :-)
"ma secondo me (come capita in parecchi NG daltronde ne siamo consci tutti)
voi cercate più il pelo nell'uovo che il succo della questione."
un po' di metafore :-)
A. 

 
Non capisco... ho un fornitore che ha il server web non pingabile..
Prendo hping2 e gli pingo la porta 80 che (sicuramente) risponde: dov'è 
il guadagno in sicurezza?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
La gente non e' che voglia una macchina a poco prezzo.
La gente vuole una macchina carissima che costi meno.
		-- Steven Wright

 magari tu non le condividi, ok, però non è un errore.
No, non è un errore, ma dipende sempre da dove lo applichi...
Se lo applichi ad una macchina destinata a fare da router/firewall può 
anche star bene: tanto la macchina in sè non pubblica nulla, e al 
massimo ti complichi il debug quando c'è qualche stupido problema di 
rete, col vantaggio di essere "visibile" solamente quando sei *tu* a 
contattare qualcuno.
La cosa è decisamente più inutile quando applicata a macchine che invece 
presentano servizi aperti all'esterno, come faceva presente Roberto qui 
sotto. E questo non è necessariamente valido solo per una macchina 
"professional" come un webserver... Se dovessi rilevare la presenza in 
rete di una macchina client, di questi tempi, lascerei probabilmente da 
parte i ping e userei un hping verso la 4662, con i tempi che corrono.. :-)
[1] di qualcuno che ha in gestione una macchina su cui vede arrivare 
giornalmente, per varie ragioni, pacchetti tra i più disparati e 
talvolta assurdi... :-D

 io non direi trascurabile.
Il "succo" e' che se hai un server che fornisce un servizio, dovrai
necessariamente farlo rispondere su qualcosa. Se non e' il ping, e'
qualcos'altro. Quindi se qualcuno volesse floodarti, potrebbe farlo
comunque sul servizio che risponde. Qualunque esso sia, e qualsiasi
sia la risposta (ricorda che il flood e' un attacco mirato). Quindi
perche' filtrare un protocollo che potrebbe anche essere utile?
In realta' c'e' un motivo per cui un flood di echo request potrebbe
essere piu' efficace di altre soluzioni. Ma mi pare che l'approccio
del thread sia maieutico, quindi... a te la risposta :-)
Fabio

 essere piu' efficace di altre soluzioni.
Uhm...a cosa pensi, di preciso? :-)
Se spoofo il mittente, ad esempio, potrei colpire un bersaglio
con i request spoofati ed i reply colpirebbero un secondo bersaglio
(il mittente apparente, appunto).
O avevi altro in mente?


 ha scritto nel messaggio 
news:oe31f.2754$8p3....@twister1.libero.it...

ripeto i osono dell'idea che ci sono più fattori cheseppur minimi
insieme contribuiscono a rendere rilevante la questione e visto la 
semplicità,
non richiede nessuno sforzo quindi la domanda giusta è perchè non farlo?
1)sicurezza (anche se minima, è come quando compri un antifurto che vale 
poco come deterrente...)
2)Banda (mi spiace ma occupa banda se se si prendono tutti i ping della 
rete....)
3)tempo di CPU (poco, ma ne prende...)
se si vendono tutti i fattori e se configurare il server è facile allora la 
dmoanda è perchè non farlo?
certo non ti rende sicuro da chissà quali attacchi...
secondo la mia opinione tutto ciò che si può fare per la sicurezza fallo!
specialmente le cose semplici.
A.

 assurdi... :-D
:-)

 
Io leggo altro, cioè che può anche star bene; da qui ad arrivare ad un 
"è giusto farlo" ce ne corre


 ha scritto nel messaggio 
news:MPG.1daf028f4...@127.0.0.1...



<Fabio
sono daccordo, nessuno dice il contrario. certo.
Poi booccare un server sulla orta 80 è relativamente facile,
mandando richieste di get da più sistemi contemporaneamente, metodo rozzo ma 
hai suoi effetti.
A.

 giusto farlo" ce ne corre
però da questo ad essere un errore, voi me lo avete descritto come un 
errore...
o come se chi lo fa fa una cosa totalmente inutile...  non è del tutto vero.
tutto ciò che si può fare per migliorare anche di poco la sicurezza fallo 
specialmente s'è semplice.
questa è la mia idea.
A.

 ecco , per magia ora vien fuori che su alcune macchine è giusto farlo...
Credo ci sia qualche problema di comunicazione, perchè io non vedo 
scritta 'sta cosa.
Errori di linea che cambian le lettere a caso?
/me, le scimmie e Shakespeare

 ha scritto nel messaggio 
news:di2uv4$nb0$1...@half.spin.it...

forse ho un attacco sulla mia macchina?

 forse ho un attacco sulla mia macchina?
di scimmie?

 ha scritto nel messaggio 
news:di3040$p6i$1...@half.spin.it...

no,
č sulla porta 9876
Servizio TCP
ho una dll sul sistema chiamata
ModificaAttivaDeiIPacchettiDiNGperAvereSempreRagione.dll
tu vorresti invece inserirmi una dll di questo tipo
AllaRicezioneNGSkullMandaUnPostDiAgree.dll
ma il mio sistema č protetto per questa dll.
A.

 E' questa la differenza che citavo io.
ma è detto che se non lo conosci non puoi fargli troppo male, fidaty. Parola 
di castoro.
-- 
Ciao, Dmitry
X-Privat F.A.Q. : 
http://www.x-privat.org/faq.php

> ModificaAttivaDeiIPacchettiDiNGperAvereSempreRagione.dll
posto anche la parte centrale di codice relativa:
if   !(packet.ip && FF.FF.FF.FF)  then {
          Packet pa=new Packet();
          pa.ip=myip;
         ......
         ......
          pa.payload("Non hai ragione ma ho ragione io");
          ....
          ....
          session.Send(pa);
       }
if   !(packet.ip  == myip)  then {
          Packet pa=new Packet();
          pa.ip=myip;
         ......
         ......
          pa.payload("Hai perfettamente ragione");
          ....
          ....
          session.Send(pa);
      }
session.close();
cercare il bug nel programma....
A. 

 errore...
Per l'icmp echo request la cosa è inutile, sostanzialmente.
Il punto è che tipicamente c'è gente a cui hanno fatto credere
di essere uns ecurity admin che filtra tout court il protocollo
icmp.
Allo studioso lettore il compito di scoprire i danni che
questo tipo di scelta può provocare.


 ma il mio sistema è protetto per questa dll.
"Protetto" e "dll" nella stessa frase sanno tanto di ossimoro. :-)


 di castoro.
non è necessariamente vero.
Se conosci l'exploit allora gli fai male eccome. solo perchè lo hai 
sbirciato...
Ripeto è rozza la questione ma non credere chemolti non facciano così.
In pochi scoprono e studiano davvero i protocolli.
Come dire che esistono molti meno hacker di coloro che si spacciano tali


 ha scritto nel messaggio 
news:di316g$u2q$1...@posted-at.bofh.it...

:-)
Per l'hacker la cosa migliore è far credere che il sistema sia sicuro quando 
invece non lo è.
A.

 ha scritto nel messaggio 
news:di318u$u2q$2...@posted-at.bofh.it...

:-) 

 Però molti oggi si credono hacker perchè conoscono nu exploit...
vero, molti si credono castori solo perchè sono miei amici, pensa :)


 O avevi altro in mente?
Quello che avevo in mente e' che con gli echo puoi forzare chi risponde 
a farlo con pacchetti di dimensioni scelte da te, e possibilmente belli
grossi, perche' nel reply l'host deve quotare il payload che rova nella
request. Potrebbe aumentare l'efficacia sia nei flood diretti (saturare
la banda del canale di upstream), sia in un flood "a rimbarzo" (request
con sorgente spoofata come ricordavi nel post precedente).
Altra considerazione sul problema "filtro o non filtro" potrebbe essere
che per saturare il canale di upstream non e' sempre necessario che sia
il server a rispondere: anche il router che gestisce la connessione con
la rete pubblica, il cui link e' normalmente il collo di bottiglia, non
e' un bersaglio da scartare. Magari sollecitando l'emissione di icmp di
tipo diagnostico, che nessun admin assennato, su un router, filtrerebbe
deliberatamente come policy abituale.
Fabio

 Quello che avevo in mente e' che con gli echo 
[snip]
Ottime considerazioni, in effetti.


 e' un bersaglio da scartare.
Il che potrebbe portare ulteriormente alla considerazione che filtrare 
echo-request sulla macchina "dietro" il suddetto router è una misura 
inutile comunque? ;-)


Per sapere come la penso, non ti resta che pingare i miei server :-)
Fabio

 Per sapere come la penso, non ti resta che pingare i miei server :-)
Messaggio per 
82.52.189.59
: ho detto _i_server_
Fabio

 Messaggio per 
82.52.189.59
: ho detto _i_server_
ROTFLASTC!


 Messaggio per 
82.52.189.59
: ho detto _i_server_
/me SBAM

 Messaggio per 
82.52.189.59
: ho detto _i_server_
/me rotfla scompostamente
Un Paperino che i fusilli fanno male quando escono dal naso.

 Un Paperino che i fusilli fanno male quando escono dal naso.
LOL
soprattutto perche` rigano l'interno della narice :-P
-- 
ciao, hal