Per tutti coloro che fossero alle prese con l’upgrade di una qualche IOS e non sapessero come funziona la complicatissima nomenclatura utilizzata da Cisco, ecco un documento riassuntivo che vi tornerà sicuramente utile.
A presto.
Archivi tag: cisco
Cisco 827 is up and running
Finalmente, dopo tanto tribolare, il mio Cisco 827 ha iniziato a fare il suo sporco lavoro. Per rendere il tutto un po’ più stabile e robusto, ho aggiunto un banco di RAM da 32 MB (in modo da non soffocarlo con le NAT translations) ed ho aggiornato la IOS, passando dalla c827v-y6-mz.121-1.XB (una EARLY DEPLOYMENT che non conosce nemmeno il significato di PPPoE) alla c820-k9osy6-mz.123-5.
Ecco lo sh ver:
NightRouter#sh ver Cisco Internetwork Operating System Software IOS (tm) C820 Software (C820-K9OSY6-M), Version 12.3(5), RELEASE SOFTWARE (fc1) Copyright (c) 1986-2003 by cisco Systems, Inc. Compiled Tue 28-Oct-03 10:31 by kellythw Image text-base: 0x80013148, data-base: 0x80A9890C ROM: System Bootstrap, Version 12.1(1r)XB1, RELEASE SOFTWARE (fc1) NightRouter uptime is 20 minutes System returned to ROM by power-on System restarted at 18:03:31 UTC Thu Nov 3 2011 System image file is "flash:c820-k9osy6-mz.123-5.bin" This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute or use encryption. Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately. A summary of U.S. laws governing Cisco cryptographic products may be found at: http://www.cisco.com/wwl/export/crypto/tool/stqrg.html If you require further assistance please contact us by sending email to export@cisco.com. CISCO C827 (MPC855T) processor (revision 0x501) with 31744K/1024K bytes of memory. Processor board ID JAD04330G9Y (2953292797), with hardware revision 0000 CPU rev number 5 Bridging software. 1 Ethernet/IEEE 802.3 interface(s) 1 ATM network interface(s) 128K bytes of non-volatile configuration memory. 8192K bytes of processor board System flash (Read/Write) 2048K bytes of processor board Web flash (Read/Write) Configuration register is 0x2102
Adesso il mio SOHO77 può andare meritatamente in pensione.
A presto.
Upgrade di un router Cisco da SOHO 77 a 827
Premessa
Per effettuare l’upgrade del nostro router da SOHO 77 a 827 è necessario che esso soddisfi i requisiti hw richiesti dalla IOS che abbiamo intenzione di installare.
Se ad esempio la IOS implementa diverse feature, come un firewall, la possibilità di gestire il traffico VOIP o di realizzare VPN PPTP, i requisiti in termini di RAM potrebbero superare di gran lunga quelli in dotazione al nostro router. Un ostacolo ancora maggiore potrebbe essere rappresentato dalle dimensioni della memoria flash (solitamente 8 MB), dunque è impossibile installarci sopra una IOS che abbia dimensioni superiori agli 8 MB.
Esistono, ovviamente, dei moduli di espansione per la flash (piuttosto costosi), mentre per la RAM potete utilizzare un banco di SDRAM a 100pin PC100 dalla capacità di 32 MB (per intenderci, quella installata sulle stampanti). Per la precisione anche un banco di RAM a 64 MB va bene, sappiate però che il router riuscirà a leggere (e quindi ad utilizzare) solo 48 MB dei 64 disponibili.
Upgrade della piattaforma
Ma vediamo come far digerire al nostro SOHO 77 una IOS sviluppata per l’827.
Spegniamo il router e riaccendiamolo. Una volta avviata la fase di boot teniamo premuto CTRL+PAUSA, in modo di accedere al rom monitor.
Successivamente, il prompt ci apparirà nel modo seguente:
rommon 1 >
Per avere una lista dei comandi disponibili è sufficiente digitare ?:
rommon 1 > ? alias set and display aliases command boot boot up an external process break set/show/clear the breakpoint confreg configuration register utility cont continue executing a downloaded image context display the context of a loaded image cookie display contents of cookie PROM in hex dev list the device table dir list files in file system dis display instruction stream dnld serial download a program module frame print out a selected stack frame help monitor builtin command help history monitor command history meminfo main memory information repeat repeat a monitor command reset system reset set display the monitor variables stack produce a stack trace sync write monitor environment to NVRAM sysret print out info from last system return tftpdnld tftp image download unalias unset an alias unset unset a monitor variable xmodem x/ymodem image download rommon 2 >
Ora, per fare l’upgrade del router occorre visualizzare il cookie che identifica la piattaforma. Per fare ciò basta digitare il comando cookie:
rommon 2 > cookie cookie: 01 01 00 01 96 71 b4 61 5b 00 01 00 01 ff 00 00 00 00 00 00 00 00 00 00 4a 41 44 04 33 30 47 39 59 05 01 00 00 00 00 00 00 ff ff ff 60 04 49 11 ec 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
A noi interessa modificare ESCLUSIVAMENTE il nono byte, portandolo da 5b a 3e. Tutti gli altri byte possono rimanere inalterati.
Per modificare il cookie occorre entrare in modalità privilegiata. E’ dunque necessario digitare il comando priv con relativa password, dove la password può essere calcolata mediante questo tool, dandogli in pasto solo la prima riga del cookie sopra riportato.
Una volta ottenuta la password utilizziamola per accedere alla modalità privilegiata. Riceveremo in output il seguente messaggio:
You now have access to the full set of monitor commands. Warning: some commands will allow you to destroy your configuration and/or system images and could render the machine unbootable. rommon 4 >
Digitiamo nuovamente il comando cookie per procedere con la modifica di quest’ultimo:
rommon 4 > cookie View/alter bytes of serial cookie by field -- Input hex byte(s) or: CR -> skip field; ? -> list values byte 0x00 - version: 01 >
Per lasciare inalterati i valori di default ci basterà premere INVIO. Per la precisione dobbiamo modificare solo il nono byte, il cui valore dovrà essere 3e.
Una volta terminata la modifica del cookie, possiamo installare la IOS dell’827 mediante il comando tftpdnld. Prima di utilizzarlo, però, si dovranno settare alcune variabili di sistema che tale comando utilizzerà, ovvero:
IP_ADDRESS IP_SUBNET_MASK DEFAULT_GATEWAY TFTP_SERVER TFTP_FILE
Ad esempio:
IP_ADDRESS=192.168.1.2 IP_SUBNET_MASK=255.255.255.0 DEFAULT_GATEWAY=192.168.1.1 TFTP_SERVER=192.168.1.1 TFTP_FILE=c827v-y6-mz.121-1.XB.bin
Controlliamo che le variabili siano state impostate correttamente digitando semplicemente set.
Adesso procediamo con il download dell’IOS mediante tftpdnld (come applicativo che funga da server TFTP vi consiglio di utilizzare tftp32):
rommon 10 > tftpdnld IP_ADDRESS: 192.168.1.2 IP_SUBNET_MASK: 255.255.255.0 DEFAULT_GATEWAY: 192.168.1.1 TFTP_SERVER: 192.168.1.1 TFTP_FILE: c827v-y6-mz.121-1.XB.bin Invoke this command for disaster recovery only. WARNING: all existing data in all partitions on flash will be lost! Do you wish to continue? y/n: [n]:
Digitiamo y e proseguiamo con l’installazione:
Receiving c827v-y6-mz.121-1.XB.bin from 192.168.1.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! File reception completed. Copying file c827v-y6-mz.121-1.XB.bin to flash. Erasing flash ................................................................ Programming flash ..............................
Digitiamo reset per riavviare il router e finalmente il nostro 827 è (o dovrebbe) essere pronto per l’uso.
A presto.
Configurare un router Cisco SOHO per PPPoE
Dopo una breve (ma necessaria) pausa ho deciso di riprendere la pubblicazione sul blog, trattando argomenti di grande interesse che durante questo lasso di tempo ho potuto approfondire.
Uno di questi riguarda la configurazione di un router Cisco SOHO, nella fattispecie il 77, per il PPPoE (Point-to-Point Protocol over Ethernet). Infatti, da qualche mese, Telecom sta convertendo le proprie linee da ATM a FullIP, costringendo gli utenti ad utilizzare la configurazione PPPoE, l’unica compatibile con il FullIP.
Ma quali sono i vantaggi di una rete FullIP? Beh, uno su tutti è sicuramente la possibilità di ridurre l’overhead, facendo aumentare di conseguenza la banda disponibile all’utente.
Dopo questa breve introduzione passiamo alla configurazione vera a propria.
La prima cosa da fare è munirci di un cavo console (quello che esce in dotazione con il dispositivo – Vedi foto) e collegarlo alla porta com del nostro pc ed alla porta console (di colore blu) del router. A collegamento avvenuto apriamo hyperterminal (Start -> Programmi -> Accessori -> Comunicazioni -> Hyper Terminal) associamo un nome alla connessione (nella finestra di popup che appare dopo l’avvio del programma) e premiamo su “OK”. Adesso selezioniamo la porta com del pc alla quale è collegato il cavo (nel mio caso COM1) clickiamo nuovamente su “OK” ed entreremo all’interno del menu di configurazione della porta precedentemente selezionata.
Scegliamo i seguenti parametri:
1) Bit per secondo: 9600
2) Bit di dati: 8
3) Parità: nessuno
4) Bit di stop: 1
5) Controllo del flusso: Hardware
Bene adesso selezioniamo “OK” e ci apparirà una schermata bianca (non vi preoccupate è perfettamente normale). Accendiamo quindi il router (dal pulsante opportuno presente nel retro del dispositivo) e vedremo apparire come per magia l’output relativo alla sequenza di bootstrap. Terminata tale operazione ci apparira il propt:
Router>
Entriamo in modalità enable che ci permette di accedere ai comandi di configurazione del router semplicemente digitando ena (oppure enable, è indifferente):
Router > ena
Adesso il prompt ci apparirà così:
Router#
Entriamo nel menù di configurazione vero e proprio digitando conf t (oppure configure terminal):
Router# conf t
Il prompt ci apparirà nel modo seguente:
Router(config)#
Impostiamo il nome del router utilizzando il comando hostname. Ad esempio:
Router(config)# hostname NightRouter
Il prompt cambierà nuovamente:
NightRouter(config)#
Definiamo password sia per la connessione via console sia per l’accesso tramite telnet, scrivendo rispettivamente:
NightRouter(config)# line console 0 NightRouter(config-line)# password <vostrapass> NightRouter(config-line)# login
mentre per telnet:
NightRouter(config-line)# line vty 0 4 NightRouter(config-line)# password <vostrapass> NightRouter(config-line)# login
Bene, adesso configuriamo la password per entrare in modalità enable:
NightRouter(config)# enable password <vostrapass> NightRouter(config)# enable secret <vostrapass> NightRouter(config)# service password-encryption NightRouter(config)# exit NightRouter#
Il comando service password-encryption serve a calcolare il digest md5 di tutte le password presenti all’interno del file di configurazione, in modo tale che un semplice show run non le mostri in chiaro.
Fatto ciò possiamo dedicarci alla configurazione delle varie interfacce. Cominciamo dall’interfaccia Ethernet:
NightRouter(config)# interface eth0
Associamo indirizzo ip e subnet mask alla stessa:
NightRouter(config-if)# ip address 192.168.1.0 255.255.255.0
“Accendiamo” l’interfaccia:
NightRouter(config-if)# no shutdown
Identifichiamo l’interfaccia interna per il NAT:
NightRouter(config-if)# ip nat inside
Usciamo dalla modalità di configurazione della porta Ethernet
NightRouter(config-if)# exit NightRouter(config)#
Configuriamo ora l’interfaccia ATM:
NightRouter(config)# interface ATM0 NightRouter(config-if)# pvc 8/35
Dopo aver digitato questo comando, il prompt ci apparirà nel modo seguente:
NightRouter(config-atm-vc)#
Settiamo il protocollo PPPoE:
NightRouter(config-atm-vc)# pppoe-client dial-pool-number 1
Configuriamo il Dialer:
NightRouter(config)# int Dialer0
Poichè spesso si utilizza ip pubblico dinamico assegnato direttamente dall’ISP occorre digitare:
NightRouter(config-if)# ip address negotiated
NB: Se si utilizza ip pubblico statico bisogna associarlo all’interfaccia attraverso il comando ip adcdress <indirizzo> <subnet mask>
Identifichiamo l’interfaccia esterna per il NAT:
NightRouter(config-if)# ip nat outside
Definiamo il protocollo di incapsulamento:
NightRouter(config-if)# encapsulation ppp
Specifichiamo quale dialer pool utilizzare:
NightRouter(config-if)# dialer pool 1
Definiamo adesso i parametri (userid e pass) per collegarsi all’ISP:
NightRouter(config-if)# ppp chap hostname <vostrauserid> NightRouter(config-if)# ppp chap password <vostrapassword>
Se il vostro provider utilizza il PAP anzichè il CHAP occorre digitare:
NightRouter(config-if)# ppp pap sent-username <vostrauserid> password <vostrapassword>
Ora, poichè si sta utilizzando il protocollo PPPoE, occorre definire la dimensione dell’MTU, che nella fattispecie è pari a 1492 byte (mentre per l’ATM è di 1500 byte).
NightRouter(config-if)# ip mtu 1492 NightRouter(config-if)# exit NightRouter(config)#
Non abbiamo ancora finito. Poichè il PPPoE supporta una dimensione massima dei segmenti TCP pari a 1452, occorre settare il seguente paramentro nell’ambito dell’interfaccia ethernet0 (altrimenti la navigazione sul Web ne risentirà parecchio):
NightRouter(config)# interface eth0 NightRouter(config-if)# ip tcp adjust-mss 1452 NightRouter(config-if)# exit NightRouter(config)#
Adesso possiamo configurare i DNS che il router utilizzerà per la risoluzione degli indirizzi:
NightRouter(config)# ip domain-lookup NightRouter(config)# ip name-server 151.99.125.2 NightRouter(config)# ip name-server 151.99.125.3
Configuriamo il NAT:
NightRouter(config)# ip nat inside source list 1 interface dialer 0 overload
Definiamo una default route:
NightRouter(config)# ip route 0.0.0.0 0.0.0.0 dialer0
Definiamo la policy per l’access list 1:
NightRouter(config)# access-list 1 permit 192.168.1.0 0.0.0.255
NB: tale access list permette a tutti gli host della net locale di uscire verso la rete esterna (Internet). Il paramentro 0.0.0.255 è detto wildcard mask ed effettua un check solo sugli ultimi 4 bit degli indirizzi ip locali.
Adesso non ci resta che bloccare l’accesso Telnet dall’esterno (ovvero da Internet) ed abilitare i log:
NightRouter(config)# line vty 0 4 NightRouter(config-line)# access-class 1 in NightRouter(config-line)# exit NightRouter(config)# service timestamps log datetime localtime show-timezone msec NightRouter(config)# service timestamps debug datetime localtime show-timezone msec NightRouter(config)# service sequence-numbers NightRouter(config)# logging queue-limit 10000 NightRouter(config)# logging buffered 1000000 notifications NightRouter(config)# logging console critical NightRouter(config)# logging monitor debug NightRouter(config)# logging history notifications NightRouter(config)# logging buffered 150000 NightRouter(config)# logging count NightRouter(config)# logging exception 100000
NB: per visualizzare i log basta lanciare il comando show log (dalla modalità enable).
Ah, quasi dimenticavo, per motivi di sicurezza conviene disabilitare il server HTTP interno:
NightRouter(config)# no ip http
Adesso salviamo quanto fatto fino ad ora digitando:
NightRouter# copy run start
Ecco completata la configurazione del nostro Router. A presto 🙂
PS: Per utilizzare alcuni programmi, quali ad esempio client p2p, è necessario impostare correttamente il port forwarding. Un esempio di rule è la seguente (porta tcp di aMule):
NightRouter(config)# ip nat inside source static tcp 192.168.1.4 4652 interface dialer0 4652
Dove 192.168.1.4 è l’host su cui è in esecuzione aMule, tcp il protocollo utilizzato e 4652 il numero della porta usata per la connessione al server p2p.
Script per il backup automatico della configurazione di un firewall Cisco PIX 501
In questo post ho riportato uno scrip da me creato il cui scopo è quello di eseguire un backup della configurazione di un router Cisco SOHO 77. Inoltre, sempre nell’ambito del post in questione, ho descritto la procedura per installare e configurare correttamente un server TFTP sulla nostra linux box. Dando per scontato che il server TFTP sia già attivo e che il file vuoto firewall.cfg sia già presente nella directory /tftpboot, vediamo come configurare il nostro firewall affinchè possa comunicare con il server in ascolto.
Una volta effettuato il login sul PIX 501 lanciamo un conf t e successivamente digitiamo il comando:
PIX501(config)# tftp-server inside <IP del server TFTP> /tftpboot/firewall.cfg
In questo modo stiamo dicendo al PIX qual è l’indirizzo del server ed il pathname del file su cui salvare la configurazione. Lanciamo un write mem per salvare le modifiche relative alla configurazione del firewall e successivamente accediamo alla nostra linux box. Fattò ciò creiamo il file backup_conf_pix501 il cui contenuto dovrà essere il seguente:
#!/usr/bin/expect set password1 "<pass1>" set password2 "<pass2> spawn telnet <IP del firewall> expect "Password:" send "$password1\r" expect "Password:" send "$password2\r" expect ">" send "ena\r" expect "Password:" send "$password\r" expect "#" send "write net\r" expect "#" send "exit\r" expect eof
Rendiamo il file eseguibile digitando:
nightfly@nightbox:~$ sudo chmod +x backup_conf_pix501
spostiamolo in /usr/bin e successivamente editiamo il file /etc/crontab aggiungendo la entry:
00 00 * * * root backup_conf_pix501
Riavviamo cron:
nightfly@nightbox:~$ sudo /etc/init.d/cron restart
ed il gioco è fatto. See ya.
Creare un utente locale per il login su dispositivi Cisco
Recentemente mi è capitato di dover creare un nuovo utente locale che potesse loggarsi (via vty, console oppure aux) su un router Cisco 2851. Per fare ciò mi è bastato digitare il comando:
Router(config)# username <vostro username> privilege 15 secret <vostra password>
Affinchè tale comando abbia effetto, è necessario che sia specificato il login local per ogni line, ad esempio:
Router(config)# line console 0 Router(config-line)# login local Router(config)# line vty 0 4 Router(config-line)# login local
e così via.
Lanciamo infine un copy run start per salvare le nuove impostazioni ed il gioco è fatto.
Fine del post, a presto.
Reply dei root nameserver: mistero svelato
In riferimento a questo post, il fatto che il mio PIX 501 inizi a strillare per la dimensione “eccessiva” dei pacchetti provenienti da alcuni root nameserver (nella fattispecie K e J), è dovuto principalmente ad una questione di standard. Infatti, lo standard originario del DNS (risalente ormai al lontano 1980) prevedeva una dimensione massima di 512 byte per i pacchetti instradati mendiante il protocollo UDP.
Successivamente, l’introduzione dell’IPv6, l’uso opzionale del protocollo TCP per il trasporto e la presenza di alcune flag aggiuntive, specificate all’interno dello standard EDNS0 (acronimo che sta per Extension Mechanism for DNS), ha fatto si che le reply potessero raggiungere delle dimensioni superiori ai 512 byte.
C’è da dire però che proprio tale “aggiornamento” ha reso possibili alcuni tipi di attacco DDoS diretti ai nameserver, tra cui il DNS amplification.
Spero di essere stato esaustivo.
Bye.
SOHO 77 e logging su una linux box
In questo post abbiamo visto come salvare i log di un Cisco PIX 501 su di un apposito server linux. Oggi invece descriverò la procedura per impostare correttamente il logging su di un router Cisco SOHO 77, affinchè le informazioni da esso generate vengano inviate ad una linux box che funge da logserver.
SOHO 77
Per prima cosa entriamo in modalità enable e lanciamo un conf t:
soho77# conf t soho77(config)#
Adesso digitiamo i seguenti comandi:
soho77(config)# logging <indirizzo IP del logserver> soho77(config)# log facility local2
Nel caso in cui si voglia impostare un certo livello di severity (ad esempio warning), deve essere usato il comando:
soho77(config)# logging trap 4
Infine, lanciamo un copy run start per rendere effettive le modifiche apportate alla configurazione del nostro router:
soho77(config)# copy run start
Linux box
Sulla nostra linux box (ovvero il logserver) occorre fare in modo che il demone rsyslogd intercetti a dovere gli eventi inviati dal router.
Per prima cosa apriamo in scrittura il file 50-default.conf presente nella directory /etc/rsyslog.d ed inseriamo la seguente stringa subito dopo user.* :
local2.4 /var/log/soho77.log
Creiamo il file che dovrà contenere i log del SOHO77:
nightfly@nightbox:/etc/rsyslog.d$ sudo touch soho77.log
Riavviamo quindi il demone rsyslogd:
nightfly@nightbox:/etc/rsyslog.d$ sudo service rsyslog restart
A questo punto non ci resta che definire appositamente la logrotation, in modo da tenere traccia dei log inviati dal router per un giusto lasso di tempo, magari sottoforma di tarball.
Per fare ciò posizioniamoci nella directory /etc/logrotate.d/ e creiamo il file soho77, il cui contenuto dovrà essere:
/var/log/soho77.log {
rotate 7
weekly
compress
missingok
notifempty
}
In particolare, il numero massimo di log che verranno conservati (comprese le tarball) è pari a 7 (rotate 7), ciascun log verrà compresso (compress) ed archiviato settimanalmente (weekly). Inoltre, nel caso in cui il file di log sia mancante non verrà generato alcun messaggio di errore (missingok) e la rotation non verrà attuata quando il file di log risulta vuoto (notifempty).
Fine del post, alla prossima.
Sincronizzare data ed ora dei dispositivi di rete mediante un server NTP
L’uso di un buon timeserver rappresenta la prima regola per ottenere dei log affidabili e soprattutto privi di eventuali inconsistenze. Inoltre, grazie ad esso, è possibile sincronizzare la data e l’ora sui vari dispositivi di rete, in modo da non dover necessariamente ricorrere ad un settaggio manuale di tali parametri.
Vediamo adesso come definire un timeserver su di un router Cisco SOHO 77, su di un firewall Cisco PIX 501 e su una macchina linux.
NTP su Cisco SOHO 77
Entriamo nella modalità di configurazione del nostro router:
SOHO77# conf t
e successivamente digitiamo il comando:
SOHO77(config)# sntp server <IP del server NTP>
In questo caso ho utilizzato come server NTP ntp.ubuntu.com, il cui indirizzo IP è 91.189.94.4
Adesso definiamo la timezone:
SOHO77(config)# clock timezone UTC +1
Come potete notare dal comando precedente, ho utilizzato la timezone UTC+1 poichè attualmente in Italia è in vigore l’ora legale.
Controlliamo che tutto sia andato a buon fine digitando il comando:
SOHO77(config)# sh clock
ed infine salviamo la configurazione:
SOHO77(config)# copy run start
NTP su Linux
Passiamo adesso all’installazione di un timeserver sulla nostra macchina linux.
Per fare ciò è sufficiente digitare:
nightfly@nightbox:~$ sudo apt-get install ntp
Ad installazione completata editiamo il file di configurazione relativo ad ntpd, ovvero il demone che funge da timeserver:
nightfly@nightbox:~$ sudo nano /etc/ntp.conf
Inseriamo i seguenti hostname:
# You do need to talk to an NTP server or two (or three). server ntp.ubuntu.com server ntp1.inrim.it server ntp2.inrim.it
Salviamo il file e riavviamo ntpd:
nightfly@nightbox:~$ sudo service ntp restart
NTP su Cisco PIX 501
Bene, ora non ci resta che configurare un server NTP sul nostro firewall. Per fare ciò occorre seguire questi step:
PIX501# conf t PIX501(config)# ntp server <IP della nostra macchina linux su cui gira ntpd> source inside PIX501(config)# clock timezone UTC +1
Inoltre, è necessario definire un’ACL apposita sul firewall in questione in modo da consentire il traffico udp sulla porta 123. Ciò si rende necessario poichè il server NTP interno (presente sulla macchina linux) deve poter ricevere gli aggiornamenti da quello esterno.
PIX501(config)# access-list inbound permit udp host 91.189.94.4 host <IP del server NTP interno> eq 123
Controlliamo che tutto sia andato a buon fine digitando:
PIX501# sh clock
ed anche:
PIX501# sh ntp status
il cui output dovrebbe essere simile al seguente:
Clock is synchronized, stratum 4, reference is <IP del server NTP interno> nominal freq is 99.9967 Hz, actual freq is 99.9966 Hz, precision is 2**6 reference time is d1161f31.f0ef3448 (14:18:41.941 UTC Mon Feb 28 2011) clock offset is 3.5382 msec, root delay is 78.16 msec root dispersion is 1386.23 msec, peer dispersion is 880.07 msec
ed infine salviamo la configurazione con un write mem.
Adesso i nostri dispositivi dovrebbero essere sincronizzati alla perfezione con i server NTP di riferimento.
A presto.
PIX 501: Dropped UDP DNS reply from outside to inside
Recentemente, spulciando i log del mio PIX ho notato una sfilza di entry del tipo:
%PIX-4-410001: Dropped UDP DNS reply from outside:151.99.125.2/53 to inside:****/24077; packet length 636 bytes exceeds configured limit of 512 bytes
Ora, non so perchè i DNS che sono solito utilizzare inviino delle reply da 636 bytes, fatto sta che dando un’occhiata alla configurazione del mio PIX ho trovato la seguente direttiva:
fixup protocol dns maximum-length 512
Ecco l’inghippo. Entro in modalità di configurazione e digito:
fixup protocol dns maximum-length 680
Lancio un write mem per salvare la configurazione ed il problema è stato risolto… in men che non si dica.
See ya.