Archivi tag: cisco 837

Abilitare e configurare il logging dei comandi lanciati da shell sul router Cisco 837

Non finirò mai di ribadire quanto sia importante “registrare” tutto ciò che accade sul nostro router, in modo da avere il pieno controllo su di esso. Tra i log “di vitale importanza” rientrano sicuramente quelli relativi ai comandi lanciati da shell: tale mini-guida ha come scopo principale proprio quello di illustrare la procedura per abilitare e configurare i log citati in precedenza.

 

Cisco 837, Cisco SOHO 77, Cisco SOHO 97, log, archive, command, logserver

 

Per prima cosa entriamo in modalità enable e successivamente accediamo alla modalità di configurazione del nostro router:

router>ena
router#conf t

Adesso posizioniamoci nell’archivio, ovvero dove verranno salvati i log che ci interessano:

router(config)#archive

Abilitiamo quindi il logging vero e proprio:

router(config-archive)#log config
router(config-archive-log-cfg)#logging enable

e successivamente configuriamolo, imponendogli di spedire i log al nostro logserver, avendo cura però di nascondere le eventuali password che verranno digitate in futuro (hidekyes):

router(config-archive-log-cfg)#notify syslog
router(config-archive-log-cfg)#hidekeys
router(config-archive-log-cfg)#exit
router(config-archive)#exit

Impostiamo il livello dei log da inviare al logserver (in questo caso settandolo su informational):

router(config)#logging trap informational

ed infine salviamo la configurazione:

router(config)#exit
router#copy run start

Da ora in poi il nostro logserver terrà traccia dei comandi lanciati dalla shell del router.

Bye.

PS: se non sapete come abilitare l’invio dei log su un server apposito, potete utilizzare questo post come riferimento.

PPS: il logging level da impostare sul server per poter ricevere i log dei comandi è pari 5 (o superiore).

Strani log sul router Cisco 837

Ieri, mentre facevo i soliti controlli di routine, ho dato un’occhiata al log dei comandi lanciati sulla shell del mio Cisco 837 ed ho avuto una sincope appena ho letto le seguenti info:

*Dec  8 00:00:21.523: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:access-list 199 permit icmp host 10.10.10.10 host 20.20.20.20
*Dec  8 00:00:21.835: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:crypto map NiStTeSt1 10 ipsec-manual
*Dec  8 00:00:22.119: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:match address 199

*Dec  8 00:00:22.315: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:set peer 20.20.20.20

*Dec  8 00:00:22.367: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:exit
*Dec  8 00:00:22.471: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:no access-list 199
*Dec  8 00:00:22.571: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:no crypto map NiStTeSt1

WTF!??? Una VPN? Sono riusciti ad ottenere l’accesso (abusivo) al mio router?

crypto.jpg

 

Bhè, per fortuna non era niente di grave, in quanto questi comandi vengono lanciati automaticamente ad ogni riavvio del router per verificare il corretto funzionamento del suo crypto engine.

Falso allarme… e vissero tutti felici e contenti.

A presto.

Cancellazione di una regola PAT sul router Cisco 837: %Static entry in use, cannot remove

Recentemente ho dovuto modificare le regole per il PAT presenti sul mio router Cisco 837, provando a rimuovere alcune entry. Poichè esse erano ancora in uso, ogni volta che provavo a cancellarle mi beccavo un messaggio del tipo:

%Static entry in use, cannot remove

Ho risolto semplicemente cancellando il contenuto della tabella relativa alle NAT translations, lanciando il comando:

clear ip nat translation *

e successivamente ho rimosso la regola per il PAT vera e propria.

Bye.

Script per il forward automatico della porta SSH sul router Cisco 837

La IOS C837-K9O3Y6-M sviluppata per il router Cisco 837 ha un bug, ovvero è possibile che dopo qualche reload si “dimentichi” di una o più PAT translations che riguardano porte più alte delle well-known (per intenderci, superiori alla 1023).

bug

Nel mio caso, il problema ha iniziato a verificarsi da quando ho deciso di mettere in ascolto SSH su una porta non standard, in modo da risparmiarmi i tentativi di attacco lanciati dagli scrip kiddie di turno.

Inoltre, per motivi di sicurezza, ho consentito l’accesso via SSH al router solo dagli host della LAN, quindi, nel caso in cui dovessi accedere alla sua configurazione, atterro sul server e da lì mi collego al router.

Ovviamente, se la porta SSH non è forwardata non posso atterrare sul server, dunque l’unica soluzione praticabile consiste nell’andare fisicamente dal cliente e ricreare la regola per il PAT.

E qui viene il bello: poichè mi sono stancato di dover perdere almeno un’ora per andare dal cliente, riconfigurare il tutto e tornarmene a casa, ho deciso di creare il seguente scrip, il quale si collega al router tre volte al giorno e ricrea la regola per l’SSH.

Ecco lo scrip:

#!/usr/bin/expect

set password1 "<password1>"
set password2 "<password2>"

spawn ssh -l <username> <IP del router>
expect "*?assword:*"
send "$password1r"
expect ">"
send "enar"
expect "Password:"
send "$password2r"
expect "#"
send "conf tr"
expect "(config)#"
send "no ip nat inside source static tcp <ip> <porta> interface Dialer0 <porta>r"
expect "(config)#"
send "ip nat inside source static tcp <ip> <porta> interface Dialer0 <porta>r"
expect "(config)#"
send "exitr"
expect "#"
send "copy run startr"
expect "?"
send "r"
expect "#"
send "exitr"
expect eof

Come al solito, mancano i backslash prima della r perchè myblog li filtra.

Una volta che avete creato lo scrip, convertitelo in eseguibile lanciando il comando:

nightfly@nightbox:~$ sudo chmod +x ssh_autoforward

e salvatelo nella directory /usr/bin:

nightfly@nightbox:~$ sudo mv ssh_autoforward /usr/bin

A questo punto potete creare la regola per cron, in modo da schedulare l’esecuzione dello scrip alle 6, alle 12 ed alle 18:

nightfly@nightbox:~$ sudo nano /etc/crontab

00 06,12,18   * * *     root          ssh_autoforward

Riavviamo cron:

nightfly@nightbox:~$ sudo service cron restart

ed abbiamo finito.

A presto.

PS: non preoccupatevi se lo scrip entra in esecuzione mentre siete loggati sul server: la regola per il forward dell’SSH non verrà rimossa poichè la state già utilizzando, quindi niente perdita di connessione.