Il blog sull'informatica

Recentemente, tentando di installare alcune regole IPTABLES direttamente sul firewall mediante SCP, ho riscontrato la presenza del seguente messaggio di errore:

debug: Next authentication method: gssapi-with-mic
debug: An invalid name was supplied
Cannot determine realm for numeric host address

debug: An invalid name was supplied
Cannot determine realm for numeric host address

debug: An invalid name was supplied
Cannot determine realm for numeric host address

Uhm, evidentemente il problema sta proprio nel metodo di autenticazione, ovvero nel gssapi-with-mic.

Cosa fare dunque? Bhè, semplice... disabilitare tale metodo di autenticazione. Apro quindi in scrittura il file ssh_config presente nella directory /etc/ssh

nightfly@nightbox:~$ sudo nano /etc/ssh/ssh_config

e modifico la direttiva associata a GSSAPIAuthentication da yes a no.

Salvo il file ed il problema è stato risolto.

A presto.

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.

Oggi mi è capitato di avere a che fare con una macchina virtuale preesistente, alla quale è stato assegnato un HD da 10 GB.

Per ragioni che non sto qui a spiegarvi è stato necessario aumentare le dimensioni del disco rigido virtuale. Per fare ciò ho effettuato le seguenti operazioni:

1) Ho spento la macchina virtuale con uno "Shut donw guest";

2) Ho aperto una sessione SSH con la macchina VMWare ESX, possizionandomi nella dir in cui è presente la macchina virtuale che mi interessa:

[root@esx root]# cd /vmfs/volumes/nomedellostorage/nomedellamacchinavirtuale

3) ho lanciato un ls ed ho verificato che fosse presente un file con estensione .vmdk così formato:

nomedellamacchinavirtuale.vmdk

4) ho lanciato questo comando (per portare la dimensione dell'HD da 10 GB a 40 GB):

[root@esx nomedellamacchinavirtuale]# vmkfstools -X 40G nomedellamacchinavirtuale.vmdk

Infine, ho riacceso la macchina virtuale, estendendo la partizione preesistente.

A presto.

Recentemente ho avuto a che fare con uno scenario piuttosto complesso, in cui gli utenti della LAN riescono a navigare sul Web grazie all'intermediazione di un proxy, nella fattispecie di Squid.

Ora, per facilitare la vita ai net admin, esiste un tool particolare che si integra alla perfezione con Squid e permette di analizzare il traffico generato da ciascun utente, in modo da poter osservare eventuali comportamenti ambigui e monitorare le loro attività sul Web. Tale software prende il nome di sarg, acronimo di Squid Analysis Report Generator.

Fin qui tutto chiaro, peccato però che i vari utenti si autentichino al proxy sfruttando NTLM e che il proxy identifichi gli spazi presenti negli username con la notazione ASCII, ovvero con %20. Quindi, nel momento in cui clicco su un link generato da sarg, del tipo:

nome%20cognome

il server apache che mi risponde interpreta il %20 come uno spazio, ragion per cui anzichè provare ad aprirmi il link:

http://proxy.dominio.com/sarg/nome%20cognome

cercherà di visualizzare il link

http://proxy.dominio.com/sarg/nome cognome

rispondendomi picche. Come fare dunque per risolvere tale problematica? Semplice, sfruttando il mod_rewrite messo a disposizione da Apache.

In particolare, tale feature consente di modificare al volo le URL richieste dall'utente, permettendo la sostituzione del %20 con un backslash, il carattere di escape , il quale serve proprio ad indicare al Web server che il %20 va interpretato in modo letterale e non come uno spazio.

Ma passiamo ai fatti. Per prima cosa identifichiamo la directory in cui è installato sarg, che per la distro CentoOS 5.0 è /var/www/sarg.

Posizioniamoci ora nella directory relativa al file di configurazione di apache, ovvero /etc/httpd/conf ed apriamo tale file di configurazione (httpd.conf) in scrittura:

[root@proxy conf]# vi httpd.conf

Verifichiamo che sia presente la direttiva:

LoadModule rewrite_module modules/mod_rewrite.so

e che non sia commentata.

Adesso inseriamo le seguenti direttive per la directory in cui si trova sarg:

<Directory "/var/www/sarg">

Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all

</Directory>

In realtà, quello che ci interessa è abilitare l'ovverride per la directory di sarg, in modo da consentire il corretto funzionamento del mod_rewrite.

Posizioniamoci adesso nella dir relativa a sarg e creiamo il file .htaccess:

[root@proxyint sarg]# vi .htaccess

e successivamente inseriamo all'interno del file le seguenti direttive:

RewriteEngine On

RewriteRule ([^ ]+) ([^ ]+) ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2%20$3%20$4 [R=301,L]

RewriteRule ([^ ]+) ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2%20$3 [R=301,L]

RewriteRule ([^ ]+) (.+) http://proxy.dominio.com/sarg/$1%20$2 [R=301,L]

Adesso verifichiamo che il mod_rewrite funzioni correttamente. Per fare ciò creiamo una directory all'interno di /var/www/sarg e chiamiamola pro%20va:

[root@proxyint sarg]# mkdir pro%20va

Infine, proviamo ad accedere a tale directory mediante il nostro browser, digitando nella barra degli indirizzi la seguente URL:

http://proxy.dominio.com/sarg/pro%20va

Se il server Web vi risponde con un errore 404 (page not found), vuol dire che il mod_rewrite non sta funzionando. Viceversa, se la directory pro%20va è vuota ed il browser vi risponde con la pagina Index of /sarg/pro%20va, vuol dire che tutto sta funzionando alla perfezione (noterete anche la presenza nella URL del backslash codificato in ASCII, ovvero %25).

Da questo momento in poi, ogni volta che proverete ad accedere alle statistiche generate da sarg, verrete correttamente reindirizzati alla pagina che state cercando.

A presto.

Recentemente mi è capitato di avere a che fare con un tool per il monitoraggio della rete (weathermap). Questo tool, affinchè riesca a monitorare il traffico che interessa le varie interfacce di uno switch o di un router, effettua banalmente delle query SNMP.

Ora, la versione di tale protocollo abilitata sui vari device è la 2, ergo, utilizzando snmpwalk posso interrogare l'agente (e i vari subagent) in esecuzione sul dispositivo di mio interesse semplicemente digitando:

snmpwalk -v 2c -c <community string> <ip del dispositivo> 1.3.6.1.2.1.2.2.1.1

Direte voi... cos'è quel numero strano in coda alla query? Ebbene, quello è l'OID (Object Identifier) relativo alle interfacce del Catalyst. Ogni OID viene generato a partire dal cosiddetto SMI (Structure of Management Information), che presenta una struttura "ad albero". Per maggiore completezza, un esempio di SMI è riportato nella figura sottostante:

Da buon (presunto) sistemista Unix, disconosco (in parte) i server Microsoft. Però, recentemente ho avuto a che fare con un DC (Domain Controller) basato su Active Directory, che svolge (ovviamente) anche funzioni di DNS. Ora, da una rapida occhiata ai record, ho notato la presenza di diverse entry duplicate. Dove sta l'intoppo? Semplice, sta nel cosiddetto scavenging, ovvero un parametro che specifica ogni quanto verranno effettuate della scansioni automatiche sui record DNS alla ricerca di eventuali duplicati (per rimuovere le entry scadute, soprattutto nel caso in cui i stia usando un server DHCP). Basta quindi abilitare tale funzionalità (e settarla a dovere) per risolvere questo problema.

See ya.

Uno dei primi argomenti che vengono trattati nell'ambito del corso CCNA riguarda l'uso del comando service password-encryption per cifrare le password impostate durante la configurazione dei dispositivi di casa Cisco (altrimenti esse verrebbero salvate come plaintext, ovvero "in chiaro").

Peccato però che tale comando sia completamente inutile, in quanto l'algoritmo utilizzato per cifrare le password si è rivelato del tutto inadeguato per garantire un livello di sicurezza sufficiente. Basta quindi procurarsi un file di configurazione in cui sono presenti le password cifrate in modalità 7,  ovvero mediante un algoritmo proprietario Cisco che nasce inizialmente come sistema di cifratura one-way per poi rivelarsi (nel 2008) totalmente reversibile, per conoscere tutte le password settate dall'amministratore.

Mi sono imbattuto in tale problematica recentemente, studiando in modo piuttosto approfondito la configurazione di alcuni switch. Nella fattispecie, volevo verificare che le password definite fossero corrette.

Potete avere conferma di quanto detto semplicemente copiando una password cifrata in modalità 7 per poi incollarla nell'apposito campo di input presente su questo sito.

Ma come fare per ovviare a tale problema?

Per prima cosa conviene utilizzare enable secret anzichè enable password per definire la password relativa all'EXEC mode del nostro dispositivo. Inoltre, se la nostra configurazione viene postata su forum vari, soprattutto per testarne la qualità e verificare l'eventuale presenza di errori, è necessario rimuovere completamente la password cifrata in modalità 7.

Ma perchè enable secret consente di ottenere un livello di protezione superiore? Semplicemente perchè tale comando genera un digest MD5 della nostra password, molto più "solido" dell'algoritmo di cifratura Cisco, anche se non completamente sicuro (ma tale regola vale per tutti gli algoritmi di cifratura one-way).

Ci aggiorniamo. Bye.

Potrebbe capitare di dover effettuare un upgrade/downgrade della IOS presente sul nostro switch. Dopo aver seguito la solita procedura, lanciando 3 comandi in croce, come erase flash, copy tftp flash:image e reloadci accorgiamo che al reboot del Catalyst viene visualizzato un errore del tipo:

Loading "flash:c3750-ipbase-mz.122-25.SEC2/c3750-ipbase-mz.122-25.SEC2.bin"...flash:c3750-ipbase-mz.122-

25.SEC2/c3750-ipbase-mz.122-25.SEC2.bin: no such file or directory

Error loading "flash:c3750-ipbase-mz.122-25.SEC2/c3750-ipbase-mz.122-25.SEC2.bin"

Ciò si verifica poichè il boot loader si aspetta di trovare l'immagine della IOS nella directory c3750-ipbase-mz.122-25.SEC2. Inoltre, il file che il boot loader cerca è c3750-ipbase-mz.122-25.SEC2.bin, ovvero il filename della vecchia IOS.

Possiamo dunque impostare il nuovo pathname della IOS appena caricata semplicemente digitando il comando:

Router(config)# boot system flash:<nome_IOS.bin>

Salviamo la configurazione:

Router(config)# copy run start

Riavviamo:

Router(config)# reload

e finalmente il boot loader cercherà all'avvio il file della IOS corretto.

A presto.

Lo switch Cisco Catalyst 6500 è a mio avviso uno dei migliori core switch in circolazione. Esso è dotato di moduli di supervisione, altrimenti detti "schede supervisor", il cui compito, come si può facilmente intuire, è quello di gestire le operazioni di tale dispositivo (sia a livello 2 che a livello 3).

Ora, poichè questo switch è modulare, quando si interviene su una rete che non si conosce a priori, potrebbe tornare utile identificare il tipo ed il numero di moduli installati sul dispositivo in questione.

Per fare ciò si può utilizzare un semplice comando, ovvero show module all:

SW-6500# show module all

L'output sarà simile al seguente:

   Mod Ports Card Type                              Model              Serial No.

   --- ----- -------------------------------------- ------------------ -----------   

     2    2  Catalyst 6000 supervisor 2 (Active)    WS-X6K-SUP2-2GE    SAD04450LF1   

     3   48  48 port 10/100 mb RJ-45 ethernet       WS-X6248-RJ-45     SAD03181468   

     5    0  Switching Fabric Module (Active)       WS-C6500-SFM       SAD04420JR5   
       

   Mod MAC addresses                       Hw    Fw           Sw           Status   

   --- ---------------------------------- ------ ------------ ------------ -------   

     2  0001.6461.39c0 to 0001.6461.39c1   1.1   6.1(3)       6.2(0.97)    Ok   

     3  00d0.bb0f.9808 to 00d0.bb0f.9837   1.0   4.2(0.24)    6.2(0.97)    Ok   

     5  0001.0002.0003 to 0001.0002.0003   1.0   6.1(3)       6.2(0.97)    Ok   
       

   Mod Sub-Module                  Model           Serial           Hw     Status   

   --- --------------------------- --------------- --------------- ------- -------   

     2 Policy Feature Card 2       WS-F6K-PFC2     SAD04440HVU      1.0    Ok   

     2 Cat6k MSFC 2 daughterboard  WS-F6K-MSFC2    SAD04430J9K      1.1    Ok   
       

   Mod Online Diag Status   

   --- -------------------   

     2 Pass   

     3 Pass   

     5 Pass   

Per visualizzare, invece, informazioni relative ad uno specifico modulo basta digitare:
 
SW-6500# show module <numero modulo>
 
A presto.