Newsgroup: it.comp.sicurezza.unix
Titolo: ICMP type 3

Nel log di iplogd mi sono ritrovato diverse righe come questa:
Wed Jul 28 12:01:09 1999:2: Spoofed ICMP packet type=3 code=1
al ritmo di 2-3 al secondo.
Ho dovuto bloccare l'ICMP in input con ipfwadm (la macchina ha il kernel
2.0.36) per fermare la cosa.
Il problema era dovuto ad un rompiscatole?
     Paolo
 
p.m...@mclink.it

 Il problema era dovuto ad un rompiscatole?
ICMP type 3 e' "destination-unreachable", quindi non penso...
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 ICMP type 3 e' "destination-unreachable", quindi non penso...
si, ma quando ne arrivano parecchi tutti insieme creano problemi, 
infatti la rete non rispondeva, poi appena ho chiuso i battenti tutto 
e' ripreso a funzionare normalmente.
Sulla pagina di iplogd si parla di "ICMP packet type=3" e di 2 
programmi che li possono generare....
      Paolo
 
p.m...@mclink.it

 programmi che li possono generare....
Si puo' essere che si trattasse di qualche coglioncello... fai una
cosa, se hai ipchains metti al volo una regola che rifiuti icmp _solo_
da quella sorgente e cosi' ti levi il pensiero.


da quella sorgente e cosi' ti levi il pensiero.
:-) gia' fatto...
     Paolo
 
p.m...@mclink.it

 :-) gia' fatto...
... e amen :)


Il problema era dovuto ad un rompiscatole?
Ovviamente. Non ci sono altri motivi normali per i quali dovrebbero essere
generati tali errori a tal ritmo. I due candidati DOC sono 'click' in ambiente
Windows e n00k in ambiente *nix che servono ad uccidere connessioni mediante
l'utilizzo, per l'appunto, di ICMP di type==3.
invy 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GSS/TW/O>AT d?(dx) s+:+, s: a-->a- C++(C+++) UL+++>UL++++ P+ L+++>L++++
E-- W(W-) N++ K? w-- O- M- V- PS++ PE Y+ PGP++ t++@ 5 X+ R+(R++) tv b+++
DI+++@ D+ G>G++ e++ h r+(r-) y++*
------END GEEK CODE BLOCK------

 l'utilizzo, per l'appunto, di ICMP di type==3.
Ovviamente dei lamer tools... non li avevo mai sentiti nominare
finora...


 l'utilizzo, per l'appunto, di ICMP di type==3.
lo supponevo...
      Paolo
 
p.m...@mclink.it

ICMP type 3 e' "destination-unreachable", quindi non penso...
Si, ma il fatto che sia un IP spoofato fa pensare che si tratti di un programma
simil ping che manda un ICMP di tipo 3.
Ciao,_
    /_)
   /ier
                   +---------------------------------+
                   |     Piergiorgio Ghezzo  [PJ]    |
                   |                                 |
                   | E-mail: 
P...@piggei.com
           |
                   |   Fido: 2:333/
70...@fidonet.org
 |
                   |    IRC: PJ on #AMIGAITA         |
                  /)    Web: 
www.piggei.com
          (\
                 / )                                 ( \
             (\ ( (+---------------------------------+) ) /)
              \(\\ \   / )                      / )  / //)/
               \\\\ \_/ /                       \ \_/ ////
                \      /                         \      /
                 \    /                           \    /

 simil ping che manda un ICMP di tipo 3.
Si, hai ragione... poi il saggio Invy ha individuato un "typical lamer
tool" usato da qualche deficiente... ed ho gia' dato la soluzione al
buon Paolo (soluzione che tra l'altro aveva gia' adottato di suo).


 buon Paolo (soluzione che tra l'altro aveva gia' adottato di suo).
che palle certa gente, non hanno nient'altro da fare....
      Paolo
 
p.m...@mclink.it

 che palle certa gente, non hanno nient'altro da fare....
Purtoppo... non avendo una vita sessuale devono ricorrere a questi
espedienti per provare orgasmi, che ci vuoi fare...


 >>da quella sorgente e cosi' ti levi il pensiero.
e' una stupidaggine, tu puoi mettere tutti i filtri che vuoi, ma i
pacchetti continueranno ad intasarti la linea, non importa se il tuo host
risponde o no, i pacchetti arrivano comunque fino alla tua macchina.

 simil ping che manda un ICMP di tipo 3.
qualcuno mi spiega come questo progidioso programma puo' capire se quei
pacchetti erano spoofed oppure no????

In un messaggio del 2 Aug 1999 07:16:50 GMT gAsp scriveva:

Tanta fede mi lascia perplesso... Ne sei cosi' sicuro? Un discorso e'
che non sia sano rifiutare gli ICMP ma non che non si possa fare. Per
esempio io rifiuto gli ICMP di tipo network-redirect, host-redirect,
TOS-network-redirect e TOS-host-redirect.


In un messaggio del 2 Aug 1999 07:17:46 GMT gAsp scriveva:

Non lo fa ipchains... ma un piccolo script che usa una apposita
feature del kernel e che tra l'altro avevo anche postato.
Fai una ricerca con Deja News e guardatelo.


feature del kernel e che tra l'altro avevo anche postato.
si, ma in questo caso il fatto che era spoofed lo diceva iplogd, quindi
bisogna chiedere all'autore.
     Paolo
 
p.m...@mclink.it

 bisogna chiedere all'autore.
E' attualmente in Francia, AFAIK, ma dovrebbe rispondere alle e-mail :)


risponde o no, i pacchetti arrivano comunque fino alla tua macchina.
state parlando di due cose diverse :)
un conto e' il flood prospettato da gasp, che come ripetuto alla follia in
questo gruppo, NON viene 'parato' mediante filtri ed affini quanto mediante
modifiche da parte dell'ISP della banda e del downstream, cosa NON alla portata
dell'utente di TIN e co. [mi scusi MCLINK per la mancata citazione :) ma avete
gia' una rivista che lo fa :P]; questo perche' il flood si basa su un banale
braccio di ferro  tra due diversi 'canali' e NON sulla natura del materiale
inviato (se non in attacchi che creino storm)
invece l'attacco da me prospettato si basa su vecchie implementazioni TCP/IP
derivate da Berkeley capaci di chiudere connessioni alla ricezione di ICMP
di tipo unreach (se validi) invece di affidarsi ai meccanismi di timeout e
retransmission di TCP. In questo caso, volendo, i filtri fungono eccome.


 Tanta fede mi lascia perplesso... Ne sei cosi' sicuro? 
Guarda il DoS Smurf, flooda con una bufera di pacchetti icmp mandati in
risposta dagli ip di broadcast, e sebbene questi non implicano risposta
da parte della vittima, riescono ugualmente ad oscurarla dalla rete
intasando la sua banda.
anche se ignori quei pacchetti icmp essi occupano cmq la tua banda.
Vecna

 E' attualmente in Francia, AFAIK, ma dovrebbe rispondere alle e-mail :)
basta fare un gethostbyname() o una qualcue funzione che lavori sull'ip
sorgente. nel caso esso corrisponde ad un ip inesistente, si sa' x certo
che era spoofing.
(nel caso lui impersoni un altro questo non vale xo' )
Ciao.
Vecna.

 intasando la sua banda.
E su quello siamo d'accordo... ma se hai letto il post di Invy ci sono
altri tipi di attacchi basati su vecchie implementazioni di TCP/IP
che chiudono la connessione alla ricezione di un icmp unreach e
che possono essere evitati eccome con dei filtri del firewall.


 che era spoofing.
Ma un IP puo' anche semplicemente risultare "inesistente" se e'
fra quelli della classe di IP di un provider che li assegna
dinamicamente. Di fatto esiste ma puo' esserci un intervallo fra
2 istanti in cui non e' assegnato ma cio' non significa che non
sia valido.


 sia valido.
"intervallo tra 2 istanti" ... cosa intendi ?
Bye.

> E su quello siamo d'accordo... ma se hai letto il post di Invy 
scusa ma non l'ho mai visto... potresti passarmelo x piacere ?
Ciao.

In un messaggio del Sat, 07 Aug 1999 13:26:48 +0200 Vecna scriveva:

L'istante in cui l'IP e' assegnato e poi non lo e' piu' perche'
l'utente si e' scollegato.


risponde o no, i pacchetti arrivano comunque fino alla tua macchina.
state parlando di due cose diverse :)
un conto e' il flood prospettato da gasp, che come ripetuto alla follia in
questo gruppo, NON viene 'parato' mediante filtri ed affini quanto mediante
modifiche da parte dell'ISP della banda e del downstream, cosa NON alla portata
dell'utente di TIN e co. [mi scusi MCLINK per la mancata citazione :) ma avete
gia' una rivista che lo fa :P]; questo perche' il flood si basa su un banale
braccio di ferro  tra due diversi 'canali' e NON sulla natura del materiale
inviato (se non in attacchi che creino storm)
invece l'attacco da me prospettato si basa su vecchie implementazioni TCP/IP
derivate da Berkeley capaci di chiudere connessioni alla ricezione di ICMP
di tipo unreach (se validi) invece di affidarsi ai meccanismi di timeout e
retransmission di TCP. In questo caso, volendo, i filtri fungono eccome.
invy
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GSS/TW/O>AT d?(dx) s+:+, s: a-->a- C++(C+++) UL+++>UL++++ P+ L+++>L++++
E-- W(W-) N++ K? w-- O- M- V- PS++ PE Y+ PGP++ t++@ 5 X+ R+(R++) tv b+++
DI+++@ D+ G>G++ e++ h r+(r-) y++*
------END GEEK CODE BLOCK------
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=> CLIP HERE < =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
