Nova Versão - Csf Firewall

[redirect]

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?

[itsnyc]

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

[joaopaulo]

2.

[itsnyc]

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

[chuvadenovembro]

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

 

[Fernando Rafs]

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?

[LucianoZ]

outra? nossa

 

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

[LeandroRS]

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

[chuvadenovembro]

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

[Visitante varallo]

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 **