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.
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$
#
# 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).
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$
#
# 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).
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.
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
.
+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.
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.
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.
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.
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>.