Como parar mensagens PAM do sudo no auth.log para um usuário específico?
Estou usando o Zabbix para monitorar meu ambiente e zabbix_agentdexecuta como usuário zabbixum script personalizado a cada 60 segundos; Ele usa sudopara executar este script como root.
Em /var/log/auth.logvejo a cada 60 segundos:
Quero impedir que esta mensagem inunde meu log. Adicionei a seguinte linha ao /etc/pam.d/sudoarquivo, imediatamente antes session required pam_unix.so:
e a mensagem desapareceu.
Mas o problema é que dessa forma eu suprimi todas as mensagens do PAM quando alguém está executando um script com sudoas root.
Quero parar a mensagem apenas para o usuário zabbix(nem todos os outros usuários). sudosabe que o zabbixusuário deseja executar o script com rootprivilégios e existe alguma maneira de informar isso ao PAM? Como posso dizer ao PAM para não registrar um usuário específico ao usar sudo?
Nota : Tentei filtrar as mensagens no syslog; embora isso funcione, ele tem o mesmo problema que o acima, ou seja, é indiscriminado demais, pois a mensagem de log não indica qual usuário está se tornando raiz.
— inivanoff1
Ele suporta filtragem e com a filtragem funciona. Eu tentei isso, mas não gosto, porque a filtragem não é uma maneira universal. Um dia, algum caractere da mensagem mudará ou algo mudará e meu filtro falhará. Estou procurando uma solução com parâmetro de configuração, diretiva ou algo semelhante para ter certeza de que isso será interrompido em todos os casos. E a mensagem diz session closed for user roote se eu filtrar de fato, estou filtrando todas as mensagens. Quero para um usuário específico que não é mencionado na mensagem e eu não posso filtrar por seu nome ...
Você parece bem próximo da sua linha de conf PAM:
Olhando para a página de manual pam_succeed_if, acho que você deseja testar se o usuário solicitante ( ruser) é zabbix.
Então eu sugiro:
Isso suprimirá o próximo teste quando o usuário zabbixse tornar root(mas nenhuma outra transição). Eu testei isso com um par de meus próprios usuários.
Remova o uid = 0teste acima, se você quiser se zabbixtornar um usuário silencioso , em vez de apenas fazer root.
Eu removi o service in sudoteste: é redundante, pois essa linha está inserida /etc/pam.d/sudo.
Obrigado! É isso que estou procurando. Perfeito! E obrigado pela sugestão para remover service in sudo.
Se você também quiser remover a [user] : TTY=unknown ; PWD=... ; USER=root ; COMMAND=...linha do log, bem como, você pode adicionar este a um sudoers.d / arquivo: Defaults:[user] !logfile, !syslog(substitua [user]quando necessário)
@thom_nic Qual é o caminho para esse arquivo?
Qualquer arquivo abaixo /etc/sudoers.d/- eu prefiro usar o nome do usuário, grupo ou aplicativo ao qual isso se aplica. Veja sudo.ws/man/1.8.15/sudoers.man.html
@thom_nic Você poderia postar isso como uma resposta um pouco mais expandida? Não vejo o formato que você propõe acima. Além disso, acho que não há um :lá dentro. E o logfilesexplícito ou algo que deve ser substituído?
Baseado na resposta de Toby, eu encontrei uma maneira de configurar isso de uma maneira um pouco diferente no Debian / Ubuntu. Para o contexto, consulte:
Portanto, o Debian / Ubuntu tem este pam-auth-updatecomando e, quando você olha /etc/pam.d/sudo, fica assim:
e /etc/pam.d/common-session-noninteractivefica assim:
Então, com certeza, eu poderia editar qualquer um dos arquivos acima, mas claramente há um "poder superior" em ação aqui. Como fazer minhas alterações funcionarem bem com outros pacotes que podem querer adicionar regras do pam? Ainda por cima, parecia que eu não poderia simplesmente adicionar uma linha /etc/pam.d/sudoentre os dois @includesegundos assim.
Depois de ler os links acima, bem como outros exemplos (consulte /usr/share/pam-configs/unix), vim com isso, em /usr/share/pam-configs/myapp:
Sessione Session-Typecontrolar quais arquivos são editados e Prioritydefine em que ordem eles entram. Depois de adicionar esse arquivo e executá-lo pam-auth-update, /etc/pam.d/common-session-noninteractivefica assim (na parte inferior :)
... o que queremos, porque nossa pam_succeed_iflinha precisa vir antes session required pam_unix.so. (Essa linha vem /use/share/pam-configs/unixe tem um, Priority: 256então termina em segundo.) Observe também que deixei o service = sudopredicado, pois common-session-noninteractivetambém pode ser incluído em outras configurações sudo.
No meu caso, eu já tinha embalado meu código como um instalador .deb então eu adicionei o /usr/share/pam-configs/myapparquivo, e acrescentou pam-auth-update --packageaos meus postinste prermroteiros e eu sou bom para ir!
Se você ler o artigo PAMConfigFrameworkSpec vinculado acima , ele definirá uma Session-Interactive-Onlyopção, mas não poderá especificar apenas regras não interativas . Então também/etc/pam.d/common-session foi atualizado . Eu não acho que há uma maneira de contornar isso. Se você concorda que as sessões interativas não estão sendo registradas para esse usuário (é uma conta de serviço, certo?), Você deve estar pronto!
Bônus: como remover também a saída do log do sudo
Além das session openened|closedlinhas que o PAM emite, sudoregistra informações adicionais sobre o comando executado. Se parece com isso:
Se você também deseja remover isso, abra este link e continue abaixo ...
Então ... você provavelmente conhece a /etc/sudoers.d/___configuração típica, que pode fazer algo assim para uma conta de serviço que precisa de privilégios de superusuário para algumas ações:
que pode entrar /etc/sudoers.d/10_myuser. Bem, entre outras coisas, você também pode especificarDefaults . Observe especificamente esta sintaxe'Defaults' ':' User_List
Agora, veja a seção SUDOERS OPTIONS . Bits interessantes incluem log_input, log_outputmas (provavelmente) mais importante, sysloge logfile. Parece-me que nas versões recentes do Debian, rsyslog ou sudolog para stdoutou stderrpor padrão. Então, para mim, isso estava aparecendo no log de diário do meu serviço, e não por exemplo, /var/log/auth.logonde não seria misturado nos logs de aplicativos. Para remover o registro do sudo, adicionei o seguinte ao seguinte /etc/sudoers.d/10_myuser:
YMMV, se você sentir que desabilitar o log cria problemas com as auditorias de segurança, você também pode tentar resolver isso por meio de filtros rsyslog.
A maneira como você implementou o material "sessão aberta / fechada" não funcionou para mim. Há dois motivos: (1) você não especificou o uso success=1(que ignora a próxima cláusula) e (2) porque como você especificou service = sudo, qualquer trabalho CRON em execução resulta em requirement "service = sudo" not met by user "root". (E possivelmente outros efeitos colaterais.) No entanto, seu material de bônus funcionou muito bem! Obrigado.
— Not2qubit 12/0518
Como são seus scripts postinste prerm?
@ not2qubit re: success=1- Prefiro não pular pam_unixcompletamente. Eu só quero parar de registrar a saída que [default=ignore]parece conseguir muito bem sem pular o pam_unix.
re: cronjobs e service = sudo: É possível que seus jobs cron estejam sendo executados como um usuário privado, mas você não está chamando sudocomo parte dos jobs cron?
Após alguns testes e pesquisas assustadores, eu encontrei uma solução funcional para o Debian Stretch (no Raspberry). Certamente há mais de uma maneira de realizar o que o OP pede. Mas a documentação do PAM é impressionante, então a maioria das coisas é realmente TL; DR.
Você pode adicionar um filtro de string personalizado para rsyslog em: /etc/rsyslog.d/anyname.confusando:
Você pode editar diretamente /etc/pam.d/sudo
Você pode fazer isso da maneira certa criando um arquivo de configuração PAM personalizado em: /usr/share/pam-configs/
Você pode fazer isso criando um arquivo de sudoers personalizado em:/etc/sudoers.d/020_pi
Eu vou te mostrar como fazer (2) e (4).
Não edite nenhum arquivo /etc/pam.d/sem antes alterar suas permissões de gravação mundial. Se não o fizer, e cometer um erro, poderá ficar bloqueado de qualquer uso futuro do sudo / su ! Portanto, verifique se você testou as novas configurações antes de alterá-las novamente. (O padrão é 644 )
Para se livrar da "sessão abrir / fechar":
Queremos nos livrar do seguinte /var/log/auth.logspam:
O que é de importância crucial aqui é que isso success=1significa pular a próxima cláusula 1 (ou no jargão do PAM "pule o próximo módulo na pilha"), se for bem-sucedida.
De man pam.conf:
ignorar - quando usado com uma pilha de módulos, o status de retorno do módulo não contribuirá para o código de retorno obtido pelo aplicativo.
done - equivalente a ok com o efeito colateral de encerrar a pilha de módulos e o PAM retornar imediatamente ao aplicativo.
N - equivalente a ok com o efeito colateral de pular os próximos N módulos na pilha.
Em seguida, reinicie e deixe executar algumas horas (para verificar tarefas cron, por exemplo) para testar se isso funciona. Em seguida, certifique-se de reinstalar as permissões de arquivo, caso contrário, haverá uma brecha de segurança no sistema. ( sudo chmod 644 /etc/pam.d/sudo)
Para se livrar das mensagens repetidas "TTY PWD COMMAND":
Também queremos nos livrar de mensagens como esta:
No meu caso, isso foi gerado por um script IDS que executava o arp-scan a cada poucos minutos. Para impedir que ele apareça nos logs, crie o seguinte arquivo:
(Aqui xxxestá o nome da sua máquina e pié o nome de usuário.)
> Não edite nenhum arquivo no /etc/pam.d/ sem antes alterar suas permissões mundiais de gravação .... Sugira altamente a execução de outra sessão do terminal como root. Por exemplo, sudo su - você não precisa definir permissões perigosas e corre o risco de esquecer de mudar de volta.
— Thom_nic 15/05
@thom_nic Você já testou isso? Meu palpite é que, se você bloquear acidentalmente o uso de sudo / su no PAM, não importa o que faça, produzirá um erro, mesmo em um shell raiz. Caso contrário, o PAM provavelmente não está funcionando como deveria.