Ir para conteúdo

Featured Replies

Postado

Em teoria, se não optar pela opção 2, o csf deixa de fornecer avisos sobre bloqueios e sobre relay.

 

Sendo assim, quem não tem o habito de monitorar o servidor por esses emails acho que poderia desativar o syslog e ativar o cphulk.

 

fica sem os avisos, mas os bloqueis continuam sendo feitos?


Postado

o gringo aqui... here is the part of file... o começo da esplicação.

 

Infelizmente, é trivial para os usuários finais e os scripts executados por eles de "spoof" as linhas de registro que aparecem idêntico a qualquer linha de log relatada em registros mantido pelo syslog / rsyslog. Você pode identificar esses logs por olhar em / etc / syslog.conf ou / etc / rsyslog.conf.

 

Isso significa que qualquer um no servidor pode maliciosamente acionar aplicações que monitorar esses logs, como lfd faz para as seguintes opções:

 

LF_SSHD LF_FTPD LF_IMAPD LF_POP3D LF_BIND LF_SUHOSIN LF_SSH_EMAIL_ALERT
LF_SU_EMAIL_ALERT LF_CONSOLE_EMAIL_ALERT LF_DISTATTACK LF_DISTFTP
LT_POP3D LT_IMAPD PS_INTERVAL UID_INTERVAL WEBMIN_LOG LF_WEBMIN_EMAIL_ALERT
PORTKNOCKING_ALERT ST_ENABLE SYSLOG_CHECK LOGSCANNER CUSTOM*_LOG.

 

Para quem quiser consertar para ativar... amanhã eu escrevo como...

 

Good night



Postado

Questões atenuantes com registros syslog / rsyslog (RESTRICT_SYSLOG)
Um usuário mal-intencionado poderia usar essa questão para disparar e-mails confusos a respeito de tentativas de login bem-sucedidas ou fracassadas, as linhas de log do kernel (incluindo iptables as linhas de log) etc

Infelizmente, há muito pouco que pode ser feito sobre isso porque o syslog / rsyslog não tem estrutura de segurança. Foi feita alguma tentativa em versões mais recentes do rsyslog, mas esta versão não está disponível, nas versões atuais usados ​​por RedHat / CentOS v6. Ele também tem que ser ativado e pode ter efeitos adversos sobre utilitários que esperar um determinado formato para as linhas de log.

Para atenuar as tentativas de falsificação, recomenda-se o seguinte, se você estiver disposto a aceitar as consequências de linhas de registro falsificados:

  1.  Percorra as opções para garantir que somente aqueles que você necessita são ativados.
  2. Certifique-se que DENY_IP_LIMIT e DENY_TEMP_IP_LIMIT são definidas razoavelmente baixo (por exemplo, 200). Isso vai limitar as tentativas para bloquear um grande número de endereços de IP.
  3. Certifique-se de que os endereços IP do administrador / suporte estão enumerados no arquivo / etc / csf / csf.allow (permitir) e, talvez, o / etc / csf / csf.ignore (iginorar). Isso vai evitar o bloqueio malicioso de negar acesso ao servidor.
  4. Para confirmar logins bem sucedidos para SSH, use o utilitário "last" utilitário a partir da raiz "root"  shell, por exemplo:  last -da
  5. Verifique regularmente os dados do servidor e do usuário por vulnerabilidades "exploits", aplicações antigas mais vulneráveis e aplicativos do OS desatualizados
  6. Considere cuidadosamente qualquer aplicativo que você usa que centraliza ações e logs syslog / rsyslog e as implicações de linhas de registro "spoofed" falsificados
  7. Considere as implicações desta questão geral sobre aplicativos e scripts que não seja o CSF / LFD que utilizam os arquivos de log afetados
  8. Em última análise, você poderia considerar restringir o acesso a todos os sockets unix syslog / rsyslog configurados. Isso pode ser usado através de permissões de arquivo e de propriedade dos soquetes (eg / dev / log), mas existem várias advertências: permissões de arquivo e de propriedade tem que ser reaplicado sempre que syslog / rsyslog é reiniciado; logging restringindo vai quebrar / limitar alguma habilidade para de log no syslog / rsyslog, por exemplo crond.
  9. Não ative a recepção syslog / rsyslog via portas UDP / TCP

Postado

Ja saiu uma nova atualização:

 

 

6.42 - New BETA option RESTRICT_SYSLOG_GROUP. This has been added for a new

         RESTRICT_SYSLOG option "3" which restricts write access to the
	 syslog/rsyslog unix socket(s). See csf.conf and the new file
	 /etc/csf/csf.syslogusers for more information

	 The those running our MailScanner implementation, you must be running
	 at least ConfigServer MailScanner Script v2.91 for logging to work
	 with RESTRICT_SYSLOG_GROUP

	 csf UI option added for editing csf.syslogusers

         Fixed a bug in PT_LOAD not producing PS output

 

AtarWeb.com.br • Hospedagem de Site + SSL Grátis
█ Revenda de Hospedagem DirectAdmin SSD + SSL Grátis

Postado
  • Autor

Ja saiu uma nova atualização:

 

Hoje saiu outra!

 

Agora a opção 'RESTRICT_SYSLOG_GROUP' saiu da versão Beta, sendo agora estável.

 

Pelo que estive lendo agora a melhor opção seria a '3', não?

 

Porque a 3 protege o sistema, restringindo quem poderá acessar o syslog/rsyslog, e os alertas continuarão funcionando normalmente, apenas restringirá quem vai poder acessar.

 

O que vocês acham, seria melhor alterar de 2 para 3 agora?


Postado

outra? nossa

 

o dúvida danada eu tinha colocado 2 agora sei não em...

Chamou? Estamos ai!


Postado

E aí pessoal, a que pé anda esta discussão... qual opção é a mais recomendada?


Postado

Acho que isso vai do gosto do freguês :P

AtarWeb.com.br • Hospedagem de Site + SSL Grátis
█ Revenda de Hospedagem DirectAdmin SSD + SSL Grátis

Postado
Em 02/02/2014 at 11:45, chuvadenovembro disse:

Ja saiu uma nova atualização:

 

 

Verdade.

Aqui apareceu a opção 3:

3 = Restrict syslog/rsyslog access to RESTRICT_SYSLOG_GROUP ** RECOMMENDED **


Participe da conversa

Você pode postar agora e se cadastrar mais tarde. Se você tem uma conta, faça o login para postar com sua conta.
Nota: Sua postagem exigirá aprovação do moderador antes de ficar visível.

Visitante
Infelizmente, seu conteúdo contém termos que não são permitimos. Edite seu conteúdo para remover as palavras destacadas abaixo.
Responder

Quem Está Navegando 0

  • Nenhum usuário registrado visualizando esta página.

Informação Importante

Concorda com os nossos termos?