Reti e Dintorni 1_new

8/6/2019 Reti e Dintorni 1_new

1/9

EADEM MUTATA RESURGO

Gennaio - Marzo 2008 N 1


2/9

2

2008 Reti & DintorniPermission is granted to copy, distribute and/or modify this document under the terms of the GNU

Free Documentation License, Version 1.1 or any later version published by the Free SoftwareFoundation;

Number 1January 2008

2008 Reti & DintorniE' garantito il permesso di copiare, distribuire e/o modificare questo documento seguendo i termini

della GNU Free Documentation License, Versione 1.1 o ogni versione successiva pubblicata dalla FreeSoftware Foundation;

Numero 1Gennaio 2008


3/9

3

EEEDDDIIITTTOOORRRIIIAAALLLEEE...................................................................................................................................................4 Dove eravamo rimasti ............................................................ ............................................................ .............................4

INTRODUZIONE ALLANALISI DI RETE.....................................................................................................................5

INTRODUZIONE TEORICA.........................................................................................................................................5ANALISI MINIMA DI RETE........................................................................................................................................5Posizionamento dellanalizzatore di protocollo ................................................................................. .........................5Broadcast e Multicast..................................................................................................................................................5Unicast flooding..........................................................................................................................................................6

I filtri di WireShark.........................................................................................................................................................8UTILIZZO DI SCRIPT BASH PER MODIFICHE DI CONFIGURAZIONI....................................................................9


4/9

4

EEEEEEEEEEEEDDDDDDDDDDDDIIIIIIIIIIIITTTTTTTTTTTTOOOOOOOOOOOORRRRRRRRRRRRIIIIIIIIIIIIAAAAAAAAAAAALLLLLLLLLLLLEEEEEEEEEEEE

Dove eravamo rimasti

Eccoci qua dopo circa quattro anni, (l'ultimo numero fu il numero 20 del Marzo2004, ma il penultimo del Maggio 2003!) a cercare di riprendere un discorso, (oun monologo) a cui tenevo molto, ma che per vari motivi venne interrottobruscamente. In questa nuova serie di Reti & Dintorni (Eadem Mutata Resurgo), sicercher di trattare maggiormente il tema "Dintorni", che comunque per i primi 20numeri era stato trascurato. Uno dei temi che si cercher di approfondire l'utilizzo del mondo linux per il mondo delle reti. L'obiettivo quello di arrivare aconoscere e testare vari applicativi del mondo open source, e non solo rimanerelegati a prodotti commerciali delle multinazionali. Il percorso lungo edambizioso, ma la fatica ne varr la pena. Per chi abituato da anni ai comodisistemi operativi Microsoft, dove al massimo si va avanti con una sequenza di

click del mouse, affrontare il mondo linux significava entrare in un mondo nonimmediato n semplice. Far riconoscere a linux un device era, il pi delle volteun'impresa un po' pi complicata del semplice mondo Windows. Ma da qualchetempo le cose non sono pi cos, e linux ormai sufficientemente semplice (quasicome Windows), e una delle migliori distribuzioni Ubuntu1 la quale facilitamolto la vita per chi ha intenzione di fare il grande passo. Logicamente il temaspecifico delle reti (protocolli etc.) non sar abbandonato, ma anzi, si cercherdove possibile di trattare argomenti nuovi e non precedentemente trattati.La filosofia della rivista basata sulla libera collaborazione dei lettori, e per lastesura degli articoli si rispettino le seguenti regole:

- non sono ammessi articoli che riportino informazioni private, come nomidi clienti, indirizzi IP effettivi di una rete utilizzata da un cliente,configurazioni con password (in chiaro o criptate) utilizzate

effettivamente in una rete reale;- gli articoli devono essere scritti tramite Microsoft Word o Open OfficeWord, utilizzando come font Times New Roman con dimensione 10. Iltesto inoltre deve avere una formattazione di tipo giustificata e su duecolonne;

- se possibile, si cerchi di dividere il testo in almeno due parti: la primaparte dovrebbe trattare largomento nella sua veste pi generale, mentre laseconda parte deve essere dedicata agli esempi particolari e specifici;

- non sono ammessi articoli che trattino esattamente gli stessi argomentitrattati in numeri precedenti, ma nel caso si deve fare riferimentoallarticolo precedente e trattare solo gli eventuali approfondimenti nontrattati in precedenza;

- la rivista inviata ai lettori che collaborano almeno con un articolo,

pubblicato sulla rivista, in un anno;- la pubblicazione di unarticolo deciso in base allimportanzadellargomento trattato e alla qualit della descrizione;

Roberto [email protected]

1Non ci si vuole dilungare sulla conoscenza specifica del sistema operativo Linux, ma si presuppone che il lettore abbia con esso dimestichezza.


5/9

5

INTRODUZIONE ALLANALISI DI RETER. Gaeta

INTRODUZIONE TEORICAUna rete per trasmissione dati, un sistema complesso,che deve soddisfare diverse funzionalit.

In generale esiste uninsieme di reti possibili { } composte da diverse topologie di rete e diversi insiemidi protocolli, che possono soddisfare lo stesso insieme

di funzionalit { } . Formalizzando si definisca

{ }{ }iii ; la rete N i-esima formata dallatopologia di rete i-esima e dallinsieme di protocolli

{ } i-esimo. Fra tutte le reti { } i che

soddisfano linsieme di funzionalit { } , ne esiste unache viene definita ottima. Una rete ottima se ilnumero di protocolli utilizzati il minimo possibile, e

che fra tutte le topologie possibili, utilizzi la topologiadi rete che, contemporaneamente, minimizzi il numerodi nodi e di link e che massimizzi laffidabilit di ognisingolo percorso.

Il problema di trovare la rete ottima dato { } nonha generalmente una soluzione formalizzata.Generalmente si procede cercando di suddividerelinsieme delle funzionalit da soddisfare in due

sottoinsiemi { } { } { }{ }PT ; uno per le richiestedi funzionalit di topologia e laltro per le funzionalitdi protocollo. Allora si procede con la seguente

approssimazione: dato { }T si trovi la topologia

i ottima, e dato { }P si trovi linsieme di protocolli

{ }i ottimo. unapprossimazione, in quanto, alcuni protocollipossono dipendere dalla topologia o viceversa.Il problema di trovare la topologia ottima, viene trattatodalla teoria dellaffidabilit e dalla teoria dei grafi, esar argomento di un prossimo articolo. Mentre pertrovare linsieme di protocolli ottimo, non esistonoteorie formali che possano essere di aiuto. Esistonoinvece delle regole pratiche, che rappresentano lasintesi dellesperienza. Esse sono:

1. Disattivate tutti i protocolli, non essenziali altrasporto e alla sicurezza;2. Se due o pi protocolli, possono soddisfare la

stessa funzionalit, scegliete di utilizzare il pisemplice per leventuale troubleshooting(anche se questo pu comportare un maggiorelavoro di configurazione iniziale);

La ricerca della rete ottima pu essere fatta sia in fasedi progettazione sia in fase di analisi post-installazionecon la rete operativa.

Nel seguito si descrive la procedura pratica, per

unanalisi di basso livello di una rete gi operativa,formata da apparati Cisco, e si cerca di fornire alcunesoluzioni per alcune problematiche comuni.

ANALISI MINIMA DI RETE

Posizionamento dellanalizzatore di protocollo

La topologia fisica di rete pu essere vista comelunione di tutte le topologie virtuali create dalle

vlans iV . Sia i

iV se 0

iV/

i

allora

esiste almeno un nodo di rete S tale che

ivS i . Generalmente questo nodo

corrisponde ad uno switch di centro stella2. Si configurisu questo nodo uninterfaccia disponibile come portatrunk IEEE802.1Q. Se operate su apparati Cisco, siricordi che quando si configura una porta tramite ilcomando switchport mode trunk in realt

linterfaccia st operando in modalit hybridIEEE802.1Q. La seguente tabella confronta laterminologia standard IEEE802.1Q con la terminologia(errata) utilizzata da Cisco e i relativi comandi:

TerminologiaStandard

IEEE802.Q

Terminologiausata da Cisco

Comandi da utilizzare su apparati Cisco

Access Access R(config-if)#switchport mode accessR(config-if)#switchport access vlan id

Hybrid Trunk R(config-if)#switchport trunk encapsulation dot1qR(config-if)#switchport mode trunk

Trunk - R(config)#vlan dot1q tag nativeR(config-if)#switchport trunk encapsulation dot1q

R(config-if)#switchport mode trunk

Purtroppo la Cisco, oltre a non usare la terminologiastandard (creando non poca confusione quando sidevono fare interoperare apparati Cisco con apparati di

altri produttori) non permette sullo stesso apparato diavere contemporaneamente le tre modalit previstedallo standard. Su unapparato Cisco operativo, non consigliabile taggare la vlan nativa, in quanto ilcomando a livello di configurazione globale.Ora prendete il vostro PC con il sistema operativo linux(ubuntu) e collegatelo allinterfaccia prima configurata,iniziamo ad analizzare il traffico in arrivo (i sistemioperativi Microsoft non devono essere utilizzati perlimpossibilit di ottenere driver non a pagamento chepermettano lutilizzo dello standard IEEE802.1Q sulleinterfacce di rete).Il software da utilizzare sar Wireshark (ultima

evoluzione di Ethereal).Broadcast e Multicast

La prima cosa da fare su una rete analizzare il traffico

di broadcast e di multicast. Sia ( )ti la funzione chedescrive la quantit di broadcast, presenti nella vlan

iV , al tempo t, e sia ( )ti lanaloga funzione per imulticast.Il PC collegato, come descritto nel paragrafo precedente ricever una quantit di broadcast

2Nel caso si abbia 0iV

/=i

significa che non esiste nella rete

un singolo nodo che permetta di raccogliere i dati desiderati da tuttele vlans contemporaneamente in unica sessione di cattura.


6/9

6

( ) ( )=i

i tt e una quantit di multicast

( ) ( )=i

i tt . Possiamo avere le seguenti

possibilit:

1. ( ) ( ) tquasi tt : questa lasituazione che possiamo ritenere normale;2. ( ) ( ) tquasi > tt : in questo caso

siamo quasi sicuramente in presenza ditraffico multicast utilizzato come trasmissionedati, e non solo come traffico di controllo. La prima cosa da verificare, su quali vlans inparticolare viene utilizzato questa tipologia ditraffico, e cercare di verificare se possibileutilizzare le tecniche di controllo del multicasttipo IGMP Snooping, ecc.;

Si deve in ogni caso verificare che almeno il 95% dei broadcast (e dei multicast) abbia una lunghezzaallinterno del range 64 160 bytes e il resto abbia unalunghezza compresa allinterno del range 161 640 bytes. Se cos non fosse vuole dire che delleapplicazioni utilizzano pacchetti broadcast pertrasmettere dati, ed necessaria quindi unulterioreanalisi. Si pu ottenere questa informazione tramitewireshark cliccando sul menu Statistics PacketLength e sulla finestra del filtro scrivete: eth.addr ==ff:ff:ff:ff:ff:ff per trovare la distribuzione dilunghezza dei broadcast e eth.addr[0] == 01 &&eth.addr[0] == 03 && eth.addr[0] == 05 &&eth.addr[0] == 07 && eth.addr[0] == 09 &&

eth.addr[0] == 0B && eth.addr[0] == 0D &&eth.addr[0] == 0F per trovare la distribuzione dilunghezza dei multicast3. consigliabile configurare su ogni interfaccia di ogniswitch di rete un controllo che permetta di limitare laquantit di broadcast in ingresso. Sugli apparati ciscoesiste il comando di interfaccia storm-controlbroadcast level L. Per decidere il livello L (inpercentuale rispetto alla velocit (b/s) di interfaccia),si analizzi il traffico broadcast per pi giorni (ilcampionamento deve essere ogni secondo!), si prendail valore di picco massimo PB(b/s) e lo si moltiplichi per 3, allora il valore di livello L sar:

100

P3L B . La seguente tabella pu essere di

aiuto:Interfaccia configuratacome access su vlan i

( ){ }100

Bmax3L i

t

Interfaccia configuratacome trunk

( )100

Bmax3L

t

3I mac multicast che iniziano con 0B, 0D, 0F, 07 e 05 non sonousuali. I mac multicast che iniziano con 09 sono utilizzati dal

protocollo ZIP dellarchitettura AppleTalk. I mac multicast cheiniziano con 03 sono utilizzati dal NETBIOS. La maggioranza deimulticast presenti su una rete hanno un mac address che inizia con01. La stessa tipologia di filtraggio serve per ottenere il grafico deibroadcast e dei multicast.

Anche se la limitazione dei multicast desiderata, in pratica la sua implementazione pu comportare deiproblemi dovuti al comportamento differenziato che si pu ottenere in relazione allhardware utilizzato.Prendiamo come esempio i vari comportamenti dialcuni apparati cisco:

Moduli:- WS-X6748-SFP- WS-X6724-SFP- WS-X6748-GE-TX- WS-X6704-10GE- WS-SUP32-GE-3B- WS-SUP32-10GE-3B

La configurazione delcontrollo multicast suquesti moduli da evitaresulle interfacce trunk, inquanto quando vienesuperata la soglia, vengonosoppressi anche i BPDU.

Switch serie 37xx Quando viene superata lasoglia, non sono soppressi imulticast di controllo tipoBPDU e CDP, ma tutti glialtri multicast vengonosoppressi (tipo HSRP,VRRP, OSPF ecc,).

Switch serie 35xx Quando viene superata lasoglia vengono soppressi

tutti i pacchetti unicast,broadcast e multicast (unicaesclusione i BPDU)!

Vista la differenziazione di comportamentogeneralmente si sconsiglia lutilizzo del controllo deimulticast, a meno di unattenta pianificazione.

Unicast flooding

In teoria posizionando un analizzatore di protocollo suuna qualsiasi porta di una rete switching, si dovrebberovedere soltanto broadcast e multicast, tranne ogni tanto

qualche singolo unicast. Il singolo unicast possibile,in quanto il timeout tm delle entry della tabella dei macaddress diverso dal timeout della tabella dei PC odelle interfacce di livello 3. Unesempio possibile ilseguente: si abbiano due PC con un arp timeout t1 > tmche abbiano gi effettuato un trasferimento dati fra diloro, allora se effettuano il secondo trasferimento datidopo un tempo t2 tale che t1 > t2 > tm allora un singolo pacchetto unicast sar trasmesso su tutte le porteassociate a quella vlan. Ora cerchiamo di analizzarequando invece si pu generare una grande quantit dipacchetti unicast flooding in sequenza.

- Unicast flooding dovuto ad arp timeoutdifferente dal timeout della tabella macaddress: il timeout delle entry della tabellamac address di 300 secondi, larp timeoutdelle interfacce di livello 3 di 4 ore, larptimeout dei pc dipende dal sistema operativo(windows 120s, linux 60s, solaris 300s). Neldiscorso precedente del singolo pacchettounicast in flooding, si considera che il pc didestinazione non sia stato spento. Nel caso siastato spento, e i pacchetti sono inviati da unasorgente con un arp timeout t1 > tm allora si pu avere unintenso traffico di unicast

flooding per tutto il tipo di traffico che non siaspetta un ack (quindi per esempio udp, snmp,icmp, ecc.). Normalmente solo le interfacce dilivello 3 hanno un arp timeout t1 > tm e per


7/9

7

evitare questo tipo di unicast flooding siconsiglia di configurare sulle interfacce dilivello 3 un arp timeout t1 = tm. Sugli apparaticisco si utilizzi il comando di interfaccia arptimeout 300.

- Unicast flooding dovuto a esaurimento della

memoria per tabella dei mac address: cidipende normalmente da un attacco, che inviacostantemente pacchetti con il source macsempre diversi. Se la tabella pu memorizzarefino ad un massimo di mac address, allora sufficiente che lattaccante invii almeno,

300

pacchetti al secondo ognuno con source

mac diverso, per ottenere lunicast floodingdel traffico reale. Su linux esistono varie possibilit per ottenere questo effetto, peresempio si pu usare il comando sing che

permette di cambiare il mac address dei pacchetti inviati. Per evitare questo tipo diattacco, sugli switch cisco possibileconfigurare il port-security sulle porte access,limitando il numero massimo di mac addressammessi ad 1 se un pc ed a 2 se presenteun telefono cisco (il port-security non deveessere configurato sulle porte trunk).

- Unicast flooding dovuto a Topology Change Notification (TCN): le TCN sono funzionali per il buon funzionamento del protocollo dispanning tree. Ogni volta che uno switch, conSTP (o RSTP) abilitato rileva una variazione

dello stato di una porta invia un pacchettoTCN, le interfacce che lo ricevono procedonocon una eliminazione di tutti i mac addressassociati a quella interfaccia. Ci pu generareunicast flooding eccessivo se non vieneconfigurata sulle porte access la funzionalitdi portfast (per gli switch cisco), per gliswitch non cisco sufficiente non abilitare lospanning tree sulle porte access.

La figura mostra cosa accade ogni qualvolta si in presenza di TCN. I segmenti rossisegnano la presenza delle TCN, le linee sulgrafico rappresentano la quantit di pacchettiunicast. Una volta che tutte le porte accesssono configurate in modo da non inviare TCN,

allora eventuali presenze di TCN, possonoessere utilizzati per evidenziare problematichesottili dovute allo spanning-tree. Per trovaredove si generato il topology change usare a

ritroso il comando show spanning-treedetail. Se lemissione di TCN non correlata a un effettivo cambio di stato fisicodi una porta, allora possiamo essere inpresenza di perdita di BPDU, o di Hacks del processo di spanning-tree, che devono essere

analizzati ulteriormente.

- Unicast flooding dovuto a due (o pi) apparaticonfigurati in active-active: molto spessoapparati configurati in active-active (tipofirewall o server) usano una tecnica chepurtroppo genera unicast flooding. Una coppiadi apparati configurati in active-active, si presentano sulla rete con un ip virtuale ipv eun mac address virtuale macv. Ci che succede che alla richiesta di un client di conoscere ilmac address associato a ipv la risposta a livelloarp contiene il mac virtuale ma a livello

ethernet viene usato il mac fisico. Il macvirtuale in sostanza verr sempre usato dalclient come destinazione, ma mai comesorgente, ottenendo, di fatto, un unicastflooding. Cerchiamo di riassumere:CLIENT

MAC = MACcIP = IPc

APPARATIACTIVE_ACTIVE

MAC VIRTUALE = MACvIP VIRTUALE = IPvMAC FISICO APP. 1 = MAC1MAC FISICO APP. 2 = MAC2

SpedisceARPREQUEST

Source DestinationMAC: MACc MAC: BroadcastARP Sender MAC: MACc ARP Target MAC: ?ARP Sender IP: IPc ARP Target IP: IPv

Destination SourceMAC: MACc MAC: MAC1ARP Target MAC: MACc ARP Sender MAC: MACvARP Target IP: IPc ARP Target IP: IPv

SpedisceARPREPLY

Inizia aspedire i

pacchettiunicast

verso IPv

Source DestinationMAC: MACc MAC: MACvIP: IPc IP: IPv

Destination SourceMAC: MACc MAC: MAC1IP: IPc IP: IPv

Rispondesempre

utilizzandoil macfisico

Quindi gli switch non conosceranno mai aquale porta associare questo mac virtuale, elunica cosa che possono fare inviare i pacchetti trasmessi dal client (con il macdestinazione uguale a quello virtuale) su tuttele porte dello switch (logicamente della stessavlan). Unica soluzione per evitare questodisastro, porre ogni singola coppia diapparati active-active in singole differenti vlan(e logicamente differenti subnet).

- Unicast flooding dovuto a RoutingAsimmetrico: il documento id: 23653 dellacisco, afferma che una delle maggiori cause di

unicast flooding dovuto al routingasimmetrico. Ritengo che questa affermazionesia errata in quanto il ragionamento espressonel documento, si regge implicitamente nel


8/9

8

considerare che gli arp timeout dei pc sianoinfiniti. In realt come gi affermato inprecedenza abbiamo che larp timeout dei pcdipende dal sistema operativo (windows 120s,linux 60s, solaris 300s), e i valorinormalmente sono al di sotto dei 5 minuti.

Ritengo dunque, che in situazione di arptimeout di default dei pc, lunicast floodingdovuto al routing asimmetrico sia inesistente otrascurabile.

- La seguente tabella riassume le varie cause diunicast flooding:

CAUSA TIPO DITRAFFICOUNICAST

SEVERIT

Arp timeout delleinterfacce L3diverso dal timeoutdella tabella macdegli switch

Tutto il trafficounicast che nonrichiede conferma(ack): UDP, SNMP,ICMP, ecc.

Medio alta.

Esaurimento dellatabella mac

Tutto. Alta

Topology ChangeNotification

Se non sonoconfigurate in modoopportuno le portedi accesso, lunicastflooding di questotipo quasi semprepresente ed interessatutti i tipi di trafficounicast.

Alta

Apparati in active-active

Interessa tutto iltrafficounidirezionale verso

questi apparati.

Alta

Routingasimmetrico

Tutto. Bassa.

I filtri di WireSharkEsistono due tipologie di filtri per WireShark, uno ilfiltro di cattura e laltro il filtro di visualizzazione .Il filtro di cattura permette di specificare, in dettaglioci che si vuole (o non si vuole) catturare. Esso vieneutilizzato, normalmente in una seconda fase diraffinamento della cattura dati. Normalmente non unabuona regola iniziare la prima campagna di cattura daticon un filtro di cattura, in quanto generalmente, del problema da risolvere se ne conoscono soltanto glieffetti, ma non le cause, e applicare un filtro di catturasignifica aver gi congetturato delle ipotesi escludendoaltre. Comunque le regole di costruzione di un filtrocattura sono le seguenti:

Operatori logici: and , or , not , less , greater Tipo: host , net , port , portrange Direzione: src , dst , src or dst , src and dst Protocollo: ether , fddi , tr , wlan , ip , ip6 , arp , decnet , tcp , udp , ip

proto[icmp|icmp6|igmp|igrp|pim|ah|esp|vrrp] , ip protochain [type protocol] ,ip broadcast , ether multicast , ip multicast , ether broadcast , ether proto[ip|ip6|arp|rarp|atalk|aarp|decnet|sca|lat|mopdl|moprc|iso|stp|ipx|netbeui] ,vlan [vlan id] , mpls [label num] , pppoed , pppoes

Speciali: broadcast , multicast , gateway Icmp: icmp-echoreply, icmp-unreach, icmp-

sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply

Esempi di filtri di cattura: ether host 00:08:15:00:08:15 (Cattura solo i

pacchetti Ethernet con sorgente o destinazioneuguale allo specifico mac-address).

host 192.168.0.1 (Cattura solo i pacchetti ipche abbiano sorgente o destinazione uguale

allo specifico ip).

Il filtro di visualizzazione , ha un altro tipo disintassi, ma facilitato nella costruzione del filtro,tramite il pulsante Expression, il quale permette dicostruire, o almeno di conoscere, la sintassi esatta dautilizzare.Per esempio i due filtri di cattura precedenti, traslaticome filtri di visualizzazione diventano:

eth.addr == 00:08:15:00:08:15 (Visualizzasolo i pacchetti Ethernet con sorgente odestinazione uguale allo specifico mac-address).

Ip.addr == 192.168.0.1 (Visualizza solo i pacchetti ip che abbiano sorgente odestinazione uguale allo specifico ip).

La costruzione di filtri complessi nascer poi dallesingole esigenze di analisi, costretti dalla navigazioneimpervia in un mare di dati.

R. Gaeta


9/9

9

UTILIZZO DI SCRIPT BASH PER MODIFICHE DI CONFIGURAZIONI

R. Gaeta

Si supponga di dover modificare la configurazione dicentinaia di apparati gi attivi in breve tempo. Ci

possibile se abbiamo le seguenti condizioni: Le password di accesso agli apparati sono

sempre le stesse; Tutti gli apparati sono raggiungibili tramite

telnet; Le modifiche coinvolgono esattamente tutti

gli apparati, con esattamente gli stessicomandi;

Tutto ci pu essere effettuato tramite il seguentesemplice script bash (denominatelo scanf.sh). Lo scriptbash attualmente ottimizzato per apparati Cisco, manon dovrebbe risultare difficile modificarlo per altre

tipologie di apparati:

#! /bin/bash

###### Script che permette di configurare pi devices uguali tramite telnet con la###### stessa confingurazione###### Esempio di utilizzo bash scanf.sh conf.txt address.txt###### Il file conf.txt deve essere un normale file di configurazione.###### il file address.txt deve contenere gli indirizzi ip

for y in `cat $2`do(sleep 3# echo user #mettere lo user se viene utilizzato!echopass_telnet # mettere la password di telnetsleep 1echo " "echo " "echo " "echo " "

echo " "echo " "echo " "echo "enable"sleep 1echopass_enable # mettere la password di enablesleep 1echo undebug allsleep 1echo "conf t"sleep 1OLDIFS=$IFSIFS="

"for i in `cat $1`doecho $isleep 1

doneecho "exit"sleep 1echo "write mem"sleep 1echo "exit"sleep 1IFS=$OLDIFSsleep 1) | telnet $y# echo -n "Per continuare premi return" # Questa linea da utilizzare in debug# read pippo # Questa linea da utilizzare in debug

doneexit 0

Spiegazione generica dello script:

Abbiamo un primo ciclo for (for y in `cat $2`) che v aleggere di volta in volta gli indirizzi ip posti nel fileaddress.txt (il file visto come variabile $2). Vieneaperta una shell tramite lapertura di parentesi tonde

(.), e allinterno delle parentesi abbiamo i comandifissi utilizzati per il telnet tipo le password, alcunicomandi specifici tipo enable, ecc.. inoltre vengonointrodotti dei comandi sleep che tengono conto

dellasincronia della sessione telnet. Viene modificatoIFS (InterFrame Spacing), e posto uguale al return.

Viene attivato un altro ciclo for che va a leggere il fileconf.txt (variabile $1), ed estrae ogni singola riga dicomando presente nel file, e immesso sulla sessionetelnet. Al termine viene salvata la configurazione, eviene riportato il valore di IFS al valore originale.Al termine della parentesi tonda ) esiste un pipe | cheimmette tutti i comandi precedenti nella sessione telnet(il comando in particolare (..) | telnet $y dove allinternodelle parentesi c tutto ci che stato descritto pocanzi. Il ciclo continua finch non si arrivaallultimo indirizzo ip presente nel file address.txt.Si consiglia prima di effettuare un cambiamento diconfigurazione massiva, di effettuare vari test su pochi

apparati, per verificare che non siano presenti errori neicomandi di configurazione.

R. Gaeta

Documents

Reti e Dintorni 1_new