Mi sento un po’ arrugginito. Non scrivo un articolo sistemistico/networking da ormai un bel po’ di tempo, pertanto partirò nella maniera più naturale che mi viene in mente ovvero raccontandovi la mia storia.
Dopo molti anni che non mettevo le mani su un router mi hanno commissionato un lavoro interessante. Decisi per la passione di mettermi d’impegno. Ho guardato tutte le configurazioni fino a quel punto fatte e nessuna mi sodisfava in particolar modo. Pertanto man mano mi sono messo a ragionare su cosa potrebbe essere una buona base e come creare una configurazione della quale, nel mio piccolo, essere orgoglioso. Da questo ragionamento partiranno un paio di articoli e questo è il primo della serie.
Perche questo? Per avere un feedback da tutti voi e allo stesso tempo cercare di migliorare il mio lavoro.
Voleve creare un modo semplice per accedere al mio router, però allo stesso tempo sicuro.
Sono partito cosi:
Intanto ho separato la configurazione dei virtual terminal, ovvero, ho riservato due virtual terminal per accessi dalle reti esterne e tre dalla rete interna.
line vty 0 1 line vty 2 4
Successivamente ho deciso che da esterno si possa accedere soltanto via SSH, mentre dalla rete interna sia via telnet che SSH.
Non affronterò le questioni tecniche del protocollo SSH, la rete è piena di ottime spiegazioni. Basta sapere questo al momento. SSH (Secure SHell, shell sicura) è un protocollo che permette di stabilire una sessione remota cifrata (tutti i dati che partono dal client finchè non arrivino sul terminal sono crittografate, ovvero non viaggiano in chiaro come via telnet).
line vty 0 1 transport input ssh line vty 2 4 transport input telnet ssh
Successivamente ho configurato l’accesso via SSH.
Intanto bisogna accertarsi che il nome di dominio e l’hostname siano configurati. Serve come base per poter generare una chiave crittografica. Se sul vostro router non è impostato un hostname o avete l’hostname di default, sarà opportuno cambiarlo.
hostname MyRouter
Mentre per il nome del domino utilizzate il seguente commando.
ip domain-name areanetworking.it
Adessio siamo a buon punto. Generiamo la nostra chiave con la quale i dati saranno crittografati.
crypto key generate rsa
Una volta impartito questo comando ci verrà chiesto di scegliere la “dimensione” della chiave. Il mio suggerimento è di lasciarla sul valore di default (512), il quale è più che sufficente per il 99% dei casi.
Finita la generazione della chiave riceveremo la conferma che SSH è stato attivato e che la versione è la 1.5.
Per chiarire, non esiste una verisone SSH 1.5, è il modo in cui Cisco ci indica che SSH1 è abilitato sul router. Nel caso, questa informazione è ottenibile eseguento il commando:
show ip ssh
Se indica SSH 1.99, significa che sia SSH1 che l’SSH2 sono abilitati sul router, mentre se è indicato SSH 2.0 vuol dire che il router accetta soltanto la connessione SSH2.
Passiamo adesso a limitare l’accesso sulle vty alle quali è possibile accedere via telnet.
Creiamo una access list da applicare sulla vty:
access-list 15 permit 10.10.10.0 0.0.0.255 log
Supponiamo che la rete interna sia la 10.10.10.10/24 ed applichiamo l’access list.
line vty 2 4 access-class 15 in
Se adesso proviamo da remoto ad accedere al router via telnet, la nostra richiesta andrà in time-out.
Se tentiamo l’accesso via SSH il router ci risponerà, e potremo stabilire la nostra connessione.
Il prossimo step è limitare le connessioni solo alla versione 2.0 del protocollo e dimostrare alcune piccolezze.
ip ssh time-out 60 ip ssh authentication-retries 5 ip ssh source-interface ATM0.1 ip ssh version 2
indichiamo l’intervallo di time-out per il protocollo SSH e lo impostiamo a 60 secondi. Dopo indichiamo il numero massimo di tentativi di autenticazione, scegliamo l’interfaccia dalla quale veranno generate le risposte del server SSH e li passiamo l’interfaccia esterna e poi, con l’ultimo comando, indichiamo la versione del protocollo SSH da utilizzare.
Inizialmente pensavo che questo bastasse. Successivamente dopo aver configurato il logging, vedovo che nel log non ci sono i riscontri quando una persona si è collegata. Ritenevo questo una cosa molto importante.
Alla fine ho trovato questi due comandi:
login on-failure log login on-success log
Il primo comando abilita i logging dei tentativi di connessione al router che non sono andati a buon fine, mentre l’altro quelli andati a buon fine.
Fin qui tutto perfetto. Dopo pochi giorni, consultando i log, vedo che sto ricevendo dei attacchi brute-force sull’accesso del mio router. A questo punto decido di prevenire questa cosa. Inizialmente ho subito pensato ad una access-list, però visto che al router mi collego da remoto sempre con un indirizzo dinamico, ho subito escluso questa possibilità.
Dopo una ricerca, ho trovato, secondo me, il modo ideale.
Lasciare che sia il router a bloccare gli indirizzi IP che violano una certa regola. Eccola:
login block-for 300 attempts 3 within 30
In pratica indichiamo al router di bloccare un indirizzo IP per 5 minuti se questo effettua più di 3 tentativi di autenticazione entro 30 secondi.
Con questo ho risolto tutte le mie preoccupazioni riguardo all’accesso al router (almeno finora, finche un altro problema non si presenterà).
Tutti i suggerimenti, come sempre sono benvenuti.
Un ultima cosa, vi riporto un estratto dal syslog riguardo al brute-force sull’ssh e il quite mode.
2009-01-27 08:28:48 Local7.Warning 10.10.10.254 81: 000086: Jan 27 08:28:47.028 Berlin: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: nagios] [Source: 210.192.123.204] [localport: 22] [Reason: Login Authentication Failed] at 08:28:47 Berlin Tue Jan 27 2009 2009-01-27 08:28:53 Local7.Warning 10.10.10.254 82: 000087: Jan 27 08:28:52.194 Berlin: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: user] [Source: 210.192.123.204] [localport: 22] [Reason: Login Authentication Failed] at 08:28:52 Berlin Tue Jan 27 2009 2009-01-27 08:28:57 Local7.Warning 10.10.10.254 83: 000088: Jan 27 08:28:57.169 Berlin: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: test] [Source: 210.192.123.204] [localport: 22] [Reason: Login Authentication Failed] at 08:28:57 Berlin Tue Jan 27 2009 2009-01-27 08:28:57 Local7.Alert 10.10.10.254 84: 000089: Jan 27 08:28:57.169 Berlin: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 19 secs, [user: test] [Source: 210.192.123.204] [localport: 22] [Reason: Login Authentication Failed] [ACL: sl_def_acl] at 08:28:57 Berlin Tue Jan 27 2009 2009-01-27 08:33:58 Local7.Notice 10.10.10.254 85: 000104: Jan 27 08:33:57.083 Berlin: %SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 08:33:57 Berlin Tue Jan 27 2009
Un saluto!
