11.7. Configurando o log do sistema
Anterior | Capítulo 11. Configuração e Ajuste | Próxima

## 11.7. Configurando o log do sistema

Contribuído por Niclas Zeising .

Gerar e ler logs do sistema é um aspecto importante da administração do sistema. As informações nos registros do sistema podem ser usadas para detectar problemas de hardware e software, bem como erros de configuração dos aplicativos e do sistema. Essas informações também desempenham um papel importante na auditoria de segurança e na resposta a incidentes. A maioria dos daemons e aplicativos do sistema geram entradas de log.

O FreeBSD fornece um registrador de sistema, o syslogd, para gerenciar o registro. Por padrão, o syslogd é iniciado quando o sistema é inicializado. Isto é controlado pela variável `syslogd_enable` no `/etc/rc.conf`. Existem vários argumentos de aplicação que podem ser definidos usando `syslogd_flags` no `/etc/rc.conf`. Consulte syslogd(8) para obter maiores informações sobre os argumentos disponíveis.

Esta seção descreve como configurar o criador de logs do sistema FreeBSD para log local e remoto e como executar a rotação de log e o gerenciamento de log.

### 11.7.1. Configurando os logs locais

O arquivo de configuração, `/etc/syslog.conf`, controla o que o syslogd faz com as entradas de log à medida que são recebidas. Existem vários parâmetros para controlar o tratamento de eventos recebidos. O facility descreve qual subsistema gerou a mensagem, como o kernel ou um daemon, e o level descreve a gravidade do evento que ocorreu. Isso possibilita configurar onde uma mensagem de log é registrada, dependendo da instalação e do nível. Também é possível executar uma ação dependendo do aplicativo que enviou a mensagem e, no caso de log remoto, o nome do host da máquina que gera o evento de log.

Este arquivo de configuração contém uma linha por ação, em que a sintaxe de cada linha é um campo seletor seguido por um campo de ação. A sintaxe do campo seletor é `facility.level`, que corresponderá às mensagens de log de `facility` no nível `level` ou superior. Também é possível adicionar um sinalizador de comparação opcional antes do nível para especificar mais precisamente o que está registrado. Vários campos seletores podem ser usados ​​para a mesma ação e são separados por um ponto-e-vírgula (`;`). Usar `*` irá corresponder a tudo. O campo de ação indica para onde enviar a mensagem de log, como para um arquivo ou host de log remoto. Por exemplo, aqui está o `syslog.conf` padrão do FreeBSD:

    # $FreeBSD: head/pt_BR.ISO8859-1/books/handbook/book.xml 53285 2019-07-30 23:45:23Z dbaio $
    #
    #       Spaces ARE valid field separators in this file. However,
    #       other *nix-like systems still insist on using tabs as field
    #       separators. If you are sharing this file between systems, you
    #       may want to use only tabs as field separators here.
    #       Consult the syslog.conf(5) manpage.
    *.err;kern.warning;auth.notice;mail.crit                /dev/console
    *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages
    security.*                                      /var/log/security
    auth.info;authpriv.info                         /var/log/auth.log
    mail.info                                       /var/log/maillog
    lpr.info                                        /var/log/lpd-errs
    ftp.info                                        /var/log/xferlog
    cron.*                                          /var/log/cron
    !-devd
    *.=debug                                        /var/log/debug.log
    *.emerg                                         *
    # uncomment this to log all writes to /dev/console to /var/log/console.log
    #console.info                                   /var/log/console.log
    # uncomment this to enable logging of all log messages to /var/log/all.log
    # touch /var/log/all.log and chmod it to mode 600 before it will work
    #*.*                                            /var/log/all.log
    # uncomment this to enable logging to a remote loghost named loghost
    #*.*                                            @loghost
    # uncomment these if you're running inn
    # news.crit                                     /var/log/news/news.crit
    # news.err                                      /var/log/news/news.err
    # news.notice                                   /var/log/news/news.notice
    # Uncomment this if you wish to see messages produced by devd
    # !devd
    # *.>=info
    !ppp
    *.*                                             /var/log/ppp.log
    !*

Neste exemplo:

- A linha 8 combina todas as mensagens com um nível de `err` ou superior, bem como `kern.warning`, `auth.notice` e `mail.crit`, e envia essas mensagens de log para o console (`/dev/console`).

- A linha 12 combina todas as mensagens do recurso `mail` no nível `info` ou acima e registra as mensagens em `/var/log/maillog`.

- A linha 17 usa um sinalizador de comparação (`=`) para corresponder apenas as mensagens no nível `debug` e registrá-las em `/var/log/debug.log`.

- A linha 33 é um exemplo de uso de uma especificação de programa. Isso faz com que as regras que a seguem apenas sejam válidas para o programa especificado. Neste caso, somente as mensagens geradas pelo ppp são registradas em `/var/log/ppp.log`.

Os níveis disponíveis, na ordem dos mais para o menos críticos, são `emerg`, `alert`, `crit`, `err`, `warning`, `notice`, `info`, and `debug`.

As facilities, em nenhuma ordem particular, são `auth`, `authpriv`, `console`, `cron`, `daemon`, `ftp`, `kern`, `lpr`, `mail`, `mark`, `news`, `security`, `syslog`, `user`, `uucp`, and `local0` through `local7`. Esteja ciente de que outros sistemas operacionais podem ter recursos diferentes.

Para registrar tudo do nível `notice` e superior para `/var/log/daemon.log`, adicione a seguinte entrada:

    daemon.notice                                        /var/log/daemon.log

Para obter mais informações sobre os diferentes níveis e facilities, consulte syslog(3) e syslogd(8). Para maiores informações sobre `/etc/syslog.conf`, sua sintaxe e exemplos de uso mais avançados, veja syslog.conf(5).

### 11.7.2. Gerenciamento de log e rotação

Os arquivos de log podem crescer rapidamente, ocupando espaço em disco e dificultando a localização de informações úteis. O gerenciamento de log tenta atenuar isso. No FreeBSD, o newsyslog é usado para gerenciar arquivos de log. Este programa interno rotaciona e comprime periodicamente arquivos de log e, opcionalmente, cria arquivos de log ausentes e sinaliza os programas quando os arquivos de log são movidos. Os arquivos de log podem ser gerados pelo syslogd ou por qualquer outro programa que gere arquivos de log. Enquanto o newsyslog é normalmente executado a partir do cron(8), ele não é um daemon do sistema. Na configuração padrão, ele é executado a cada hora.

Para saber quais ações executar, o newsyslog lê seu arquivo de configuração, `/etc/newsyslog.conf`. Este arquivo contém uma linha para cada arquivo de log que o newsyslog gerencia. Cada linha indica o proprietário do arquivo, suas permissões, quando rotacionar esse arquivo, flags opcionais que afetam a rotação do log, como compactação, e programas para sinalizar quando o log é rotacionado. Aqui está a configuração padrão no FreeBSD:

    # configuration file for newsyslog
    # $FreeBSD: head/pt_BR.ISO8859-1/books/handbook/book.xml 53285 2019-07-30 23:45:23Z dbaio $
    #
    # Entries which do not specify the '/pid_file' field will cause the
    # syslogd process to be signalled when that log file is rotated.  This
    # action is only appropriate for log files which are written to by the
    # syslogd process (ie, files listed in /etc/syslog.conf).  If there
    # is no process which needs to be signalled when a given log file is
    # rotated, then the entry for that file should include the 'N' flag.
    #
    # The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'.
    #
    # Note: some sites will want to select more restrictive protections than the
    # defaults.  In particular, it may be desirable to switch many of the 644
    # entries to 640 or 600.  For example, some sites will consider the
    # contents of maillog, messages, and lpd-errs to be confidential.  In the
    # future, these defaults may change to more conservative ones.
    #
    # logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
    /var/log/all.log                        600  7     *    @T00  J
    /var/log/amd.log                        644  7     100  *     J
    /var/log/auth.log                       600  7     100  @0101T JC
    /var/log/console.log                    600  5     100  *     J
    /var/log/cron                           600  3     100  *     JC
    /var/log/daily.log                      640  7     *    @T00  JN
    /var/log/debug.log                      600  7     100  *     JC
    /var/log/kerberos.log                   600  7     100  *     J
    /var/log/lpd-errs                       644  7     100  *     JC
    /var/log/maillog                        640  7     *    @T00  JC
    /var/log/messages                       644  5     100  @0101T JC
    /var/log/monthly.log                    640  12    *    $M1D0 JN
    /var/log/pflog                          600  3     100  *     JB    /var/run/pflogd.pid
    /var/log/ppp.log        root:network    640  3     100  *     JC
    /var/log/devd.log                       644  3     100  *     JC
    /var/log/security                       600  10    100  *     JC
    /var/log/sendmail.st                    640  10    *    168   B
    /var/log/utx.log                        644  3     *    @01T05 B
    /var/log/weekly.log                     640  5     1    $W6D0 JN
    /var/log/xferlog                        600  7     100  *     JC

Cada linha começa com o nome do log a ser rotacionado, seguido opcionalmente por um proprietário e um grupo para arquivos rotacionados e recém-criados. O campo `mode` define as permissões no arquivo de log e `count` indica quantos arquivos de log rotacionados devem ser mantidos. Os campos `size` e `when` informam o newsyslog quando rotacionar o arquivo. Um arquivo de log é rotacionado quando seu tamanho é maior que o campo `size` ou quando o tempo no campo `when` tiver terminado. Um asterisco (`*`) significa que este campo é ignorado. O campo `flags` fornece instruções adicionais, por exemplo, como compactar o arquivo rotacionado ou criar o arquivo de log se ele estiver ausente. Os dois últimos campos são opcionais e especificam o nome do arquivo de ID de Processo (PID) e um número de sinal para enviar a esse processo quando o arquivo é rotacionado.

Para obter maiores informações sobre todos os campos, sinalizadores válidos e como sobre especificar o tempo de rotação, consulte newsyslog.conf(5). Como o newsyslog é executado a partir do cron(8), ele não pode rotacionar arquivos com mais frequência do que a que está planejada para ser executada no cron(8).

### 11.7.3. Configurando o log remoto

Contribuído por Tom Rhodes.

Monitorar os arquivos de log de vários hosts pode se tornar difícil à medida que o número de sistemas aumenta. Configurar o log centralizado pode reduzir parte da carga administrativa da administração dos arquivos de log.

No FreeBSD, a agregação, a fusão e a rotação centralizada de arquivos de log podem ser configuradas usando o syslogd e o newsyslog. Esta seção demonstra um exemplo de configuração, em que host o `A`, chamado `logserv.example.com`, coletará informações de log para a rede local. O host `B`, denominado `logclient.example.com`, será configurado para transmitir informações de log para o servidor de registro em log.

#### 11.7.3.1. Configuração do servidor de log

Um servidor de log é um sistema que foi configurado para aceitar informações de log de outros hosts. Antes de configurar um servidor de log, verifique o seguinte:

- Se houver um firewall entre o servidor de log e qualquer cliente de log, certifique-se de que o conjunto de regras do firewall permita a porta 514 do UDP para os clientes e o servidor.

- O servidor de log e todas as máquinas clientes devem ter entradas de nome diretas e reversas no DNS local. Se a rede não tiver um servidor DNS, crie entradas no `/etc/hosts` de cada sistema. A resolução adequada de nomes é necessária para que as entradas de log não sejam rejeitadas pelo servidor de log.

No servidor de log, edite o `/etc/syslog.conf` para especificar o nome do cliente para receber as entradas de log, o recurso de log a ser usado e o nome do log para armazenar as entradas de log do host. Este exemplo adiciona o nome do host de `B`, registra todos os recursos e armazena as entradas de log em `/var/log/logclient.log`.

Exemplo 11.1. Configuração do servidor de log de exemplo

    +logclient.example.com
    *.*     /var/log/logclient.log

Ao adicionar vários clientes de log, adicione uma entrada semelhante de duas linhas para cada cliente. Maiores informações sobre os recursos disponíveis podem ser encontradas em syslog.conf(5).

Em seguida, configure o `/etc/rc.conf`:

    syslogd_enable="YES"
    syslogd_flags="-a logclient.example.com -v -v"

A primeira entrada inicia o syslogd na inicialização do sistema. A segunda entrada permite entradas de log do cliente especificado. A opção `-v -v` aumenta a verbosidade das mensagens registradas. Isso é útil para ajustar os recursos, pois os administradores podem ver o tipo de mensagens que estão sendo registradas em cada facility.

Múltiplas opções `-a` podem ser especificadas para permitir o registro de múltiplos clientes. Endereços IP e netblocks inteiros também podem ser especificados. Consulte syslogd(8) para obter uma lista completa de opções possíveis.

Finalmente, crie o arquivo de log:

    # touch /var/log/logclient.log

Neste ponto, o syslogd deve ser reiniciado e verificado:

    # service syslogd restart
    # pgrep syslog

Se um PID for retornado, o servidor será reiniciado com êxito e a configuração do cliente poderá ser iniciada. Se o servidor não reiniciar, consulte `/var/log/messages` para visualizar o erro.

#### 11.7.3.2. Configuração do cliente de log

Um cliente de log envia entradas de log para um servidor de log na rede. O cliente também mantém uma cópia local de seus próprios logs.

Uma vez que o servidor de log foi configurado, edite o `/etc/rc.conf` no cliente de registro:

    syslogd_enable="YES"
    syslogd_flags="-s -v -v"

A primeira entrada ativa o syslogd na inicialização. A segunda entrada impede que os logs sejam aceitos por esse cliente de outros hosts (`-s`) e aumenta a verbosidade das mensagens registradas.

Em seguida, defina o servidor de log no `/etc/syslog.conf` do cliente. Neste exemplo, todos os facilities registrados são enviados para um sistema remoto, indicado pelo símbolo `@`, com o nome do host especificado:

    *.*		@logserv.example.com

Depois de salvar a edição, reinicie o syslogd para que as alterações entrem em vigor:

    # service syslogd restart

Para testar se as mensagens de log estão sendo enviadas pela rede, use o logger(1) no cliente para enviar uma mensagem para syslogd:

    # logger "Test message from logclient"

Esta mensagem agora deve existir tanto no `/var/log/messages` do cliente e no `/var/log/logclient.log` do servidor de log.

#### 11.7.3.3. Debugando servidores de log

Se nenhuma mensagem estiver sendo recebida no servidor de log, a causa provavelmente é um problema de conectividade de rede, um problema de resolução de nome de host ou um erro de digitação em um arquivo de configuração. Para isolar a causa, certifique-se de que o servidor de log e o cliente de log sejam capazes de comunicarem através do `ping` usando o nome do host especificado em seu `/etc/rc.conf`. Se isso falhar, verifique o cabeamento da rede, o conjunto de regras do firewall e as entradas de nome de host no servidor DNS ou `/etc/hosts` no servidor de log e nos clientes. Repita até que o `ping` seja bem-sucedido em ambos os hosts.

Se o `ping` for bem-sucedido em ambos os hosts, mas as mensagens de log ainda não estiverem sendo recebidas, aumente temporariamente o detalhamento do log para diminuir o problema de configuração. No exemplo a seguir, o `/var/log/logclient.log` no servidor de log está vazio e o `/var/log/messages` no cliente de log não indica uma razão para a falha. Para aumentar a saída de debug, edite a entrada `syslogd_flags` no servidor de log e execute uma reinicialização:

    syslogd_flags="-d -a logclient.example.com -v -v"

    # service syslogd restart

Dados de debug semelhantes aos seguintes irão aparecer no console imediatamente após a reinicialização:

    logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
    syslogd: restarted
    logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
    Logging to FILE /var/log/messages
    syslogd: kernel boot file is /boot/kernel/kernel
    cvthname(192.168.1.10)
    validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
    rejected in rule 0 due to name mismatch.

Neste exemplo, as mensagens de log estão sendo rejeitadas devido a um erro de digitação que resulta em uma incompatibilidade de nome de host. O nome do host do cliente deve ser `logclient`, não `logclien`. Corrija o erro de digitação, execute uma reinicialização e verifique os resultados:

    # service syslogd restart
    logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
    syslogd: restarted
    logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
    syslogd: kernel boot file is /boot/kernel/kernel
    logmsg: pri 166, flags 17, from logserv.example.com,
    msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2
    cvthname(192.168.1.10)
    validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
    accepted in rule 0.
    logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2
    Logging to FILE /var/log/logclient.log
    Logging to FILE /var/log/messages

Neste ponto, as mensagens estão sendo recebidas e colocadas corretamente no arquivo correto.

#### 11.7.3.4. Considerações de segurança

Como com qualquer serviço de rede, os requisitos de segurança devem ser considerados antes de implementar um servidor de log. Os arquivos de log podem conter dados confidenciais sobre serviços ativados no host local, contas de usuário e dados de configuração. Os dados enviados pela rede do cliente para o servidor não serão criptografados nem protegidos por senha. Se houver necessidade de criptografia, considere o uso do security/stunnel, que transmitirá os dados de log em um túnel criptografado.

A segurança local também é um problema. Os arquivos de log não são criptografados durante o uso ou após a rotação do log. Usuários locais podem acessar arquivos de log para obter informações adicionais sobre a configuração do sistema. Definir permissões adequadas nos arquivos de log é crítico. O rotacionador de log integrado, newsyslog, suporta a configuração de permissões em arquivos de log recém-criados e rotacionados. A configuração de arquivos de log no modo `600` deve impedir o acesso indesejado por usuários locais. Consulte newsyslog.conf(5) para obter informações adicionais.

Anterior | Acima | Próxima
11.6. Hosts Virtuais | Principal | 11.8. Arquivos de Configuração

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.