Olá!
Ter um servidor de logs em sua rede, é extremamente necessário. Os
routers e
switches Cisco têm um buffer interno (de tamanho variável e configurável) que atende de forma eficiente.
Porém, não acho prático ter que acessar um router sempre que quero ver um log, e esse buffer não será capaz de guardar logs por muito tempo.
Temos duas etapas simples, mas que podem dar trabalho. Principalmente se você estiver "garimpando" informações na Internet.
Precisamos, primeiro, configurar o router/switch para enviar o log para um servidor remoto. Por padrão, esses equipamentos estarão armazenando em um buffer interno e um output em tempo real para o terminal de console, mas, é possível ativar para linhas vty (tty no
GNU/Linux) ou para um servidor remoto.
Depois, precisamos configurar um servidor para que filtre os logs e salve em arquivos diferentes, as informações referentes a cada equipamento.
Estarei mostrando as configurações em um
CentOS 6.3 e em um
Debian 7. Bom, vamos começar pelo roteador.
Configurando seu router
Primeiro, você precisará ter acesso de privilégio 15. Depois, entre nas configurações globais com o comando:
# configure terminal
Primeiro, certifique-se que o log está ativado. Execute o comando:
# logging on
Essa próxima etapa é opcional, mas em minha opinião, quando se tem um servidor, torna-se desnecessário deixá-las ativadas.
Desabilite o envio de logs para ambos os outputs:
# no logging console
# no logging monitor
Agora, precisamos setar o IP de quem irá ser o servidor. Pode ser IPv4, nome (DNS) ou IPv6. Existem algumas opções, como setar um ID ou mudar o protocolo Layer 4, mas que não precisamos nos preocupar agora.
# logging host 172.16.1.10
Agora nos resta determinar qual o nível das mensagens que serão enviadas ao servidor.
Obs.: os níveis abaixo são cobrados em provas, como CCNA SECURITY. Caso você esteja se preparando para alguma prova, é sempre bom ter isso em mente.
E lembre-se, os níveis com valores mais altos agregam os com valores mais baixos.
# logging trap <0-7>
<0-7> Logging severity level
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)
Outra informação importante, é que esse comando seta o nível em termos globais. Existe também níveis de log para interfaces ou protocolos, por exemplo.
Caso você use o logging
trap 3, vai receber logs globais do nível 3 para baixo, mas, você pode receber um nível 5 de uma interface.
Veja o exemplo abaixo:
Jul 15 13:49:15 10.50.63.2 27: Jul 15 16:49:13.112: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
Jul 15 13:49:26 10.50.63.2 28: Jul 15 16:49:24.999: %SYS-5-CONFIG_I: Configured from console by admin on vty1 (IP.DO.USR.CONECTADO)
Jul 15 16:55:57 10.50.63.2 29: Jul 15 19:55:56.565: %SYS-5-CONFIG_I: Configured from console by admin on vty1 (XX.XX.XX.XX)
Jul 23 15:33:37 10.50.63.2 30: Jul 23 18:33:36.385: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Jul 23 15:34:06 10.50.63.2 31: Jul 23 18:34:05.395: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Jul 23 15:40:57 10.50.63.2 32: Jul 23 18:40:56.347: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Jul 23 15:41:49 10.50.63.2 33: Jul 23 18:41:48.354: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Jul 23 16:19:17 10.50.63.2 42: Jul 23 19:19:16.148: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Jul 23 17:43:48 10.50.63.2 43: Jul 23 20:43:47.712: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Jul 27 12:41:17 10.50.63.2 44: Jul 27 15:41:16.304: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
destaddr=XX.XX.XX.XX, prot=50, spi=0x339FA735(866101045), srcaddr=XX.XX.XX.XX
Jul 27 12:41:22 10.50.63.2 45: Jul 27 15:41:21.771: %CRYPTO-4-IKMP_NO_SA: IKE message from XX.XX.XX.XX has no SA and is not an initialization
offer
Aug 6 11:02:56 10.50.63.2 46: Aug 6 14:02:55.131: %SYS-5-CONFIG_I: Configured from console by admin on vty1 (XX.XX.XX.XX)
Aug 29 17:05:06 10.50.63.2 47: Aug 29 20:05:05.136: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Aug 29 17:05:37 10.50.63.2 48: Aug 29 20:05:36.697: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Note que a primeira parte faz referência ao tipo de mensagem (sistema, protocolo, link etc.), a segunda é o nível de severidade. A terceira é uma informação mais específica do erro (mudança de config, queda de link, etc):
- %SYS-5-CONFIG_I :: é referente ao nível global (SYS - Sistema) que você determina com o comando LOGGING TRAP.
- %LINEPROTO-5-UPDOWN :: se refere a logg de protocolo layer 2
- %LINK-3-UPDOWN :: nesse trata-se de uma mensagem relevante a Layer 1. Se um user desligou um cabo por exemplo, ou se o mesmo está quebrado.
- %CRYPTO-4-XX :: é referente a VPN configurada nesse router. Não precisamos entrar em detalhes.
Para que uma interface não envie mensagens do tipo
%LINK-3-UPDOWN toda vez que algum user desliga o PC, ou leva o Notebook para outro lugar, podemos executar o seguinte comando:
# logging event link-status
Nesse caso, mensagens de logs não serão geradas sempre que um cabo for desligado. Também pode ser usado para sub-interfaces.
Considerações
Não existe muito mistério nesta parte. Mas é muito importante tomar cuidado antes e saber o conceito. Saber o que é e para que serve, é chave no dia a dia.
No
GNS3, é possível usar interfaces virtuais para conectar um router à sua placa física e até mesmo interligar com máquinas virtuais.
Caso você esteja estudando para provas e não tenha equipamentos, não se limite ao Packet Tracer.
Na próxima etapa, veremos como configurar o GNU/Linux para receber esses logs.