Assinatura da Revista Linux Magazine com 28% de desconta
Comunidade CentOS-BR.org e Linux Magazine esta com 28% de desconta na assinatura anual.
A Linux Magazine, melhor publicação de tecnologia na área de Linux e Software de código aberto do mundo, firmou parceria com a Comunidade CentOS-BR.org para oferecer condições especiais e imperdóveis na assinatura da revista. 28% de desconto Por apenas 4×32,20 no cartão de crédito ou à vista no boleto Assinando a Linux Magazine você tem uma série de vantagens:
[ASSINAR] http://www.linuxmagazine.com.br/centosbr
1 - Desconto especial na assinatura. 2 - Não perde nenhum exemplar, recebe-os em mensalmente em seu endereço. 3 - Renovação com desconto especiais. 4 - Participa de promoções de produtos da editora e de parceiros. 5 - Fica atualizado sobre os lançamentos de novas tecnologias e suas aplicações. 6 - Fortalece a difusão do Software Livre no mercado corporativo
Campanha valida até 30/04/2009
by http://www.centos-br.org/2009/04/14/assinatura-da-revista-linux-magazine-com...
Olá meus amigos,
Estou com um problema sério aqui. Já tentei algumas coisas como mod_security mas mesmo assim não tá funcionando. Vira e mexe alguém consegue através do apache, baixar, instalar e rodar programas no sistema, bots e tal. O Servidor é um servidor web, por sorte esses arquivos rodam como dono o apache mas mesmo assim causam muitos problemas. Ainda agora descobri uns processos chamados portmap e que não eram o portmap e o programa estava rodando no /tmp como dono o apache.
Alguém tem alguma idéia do que eu possa bloquear no apache sem afetar as páginas que estão rodando?
Agradeço qualquer ajuda. :)
Grande abraço à todos.
Tu roda SuExec? Teu php roda como CGI? Tu roda mod_Evasive? Sobre cgi teus arquivos tem permissão 644 e os diretórios 755?
Atente para isto acima e metade das ocorrências deverá acabar (senão mais).
Depende muito de tuas rules também (no modsec).
Bom, quando monto um servidor apache, além do mod-security, ainda implemento duas políticas:
o apache tem permissão de somente leitura na estrutura em que ele pode consultar. Somente em local que realmente ele deve ter permissão de escrita que é liberado, do resto somente leitura.
outra coisa é você restringir usando o parametro do "php php_admin_value open_basedir "/var/www/caminho/httpdocs:/tmp"
ou seja, o php conseguirá acessar somente os caminhos que for estipulado aqui.
Atenciosamente ________________________________________________ Renato de Oliveira Diogo
Bacharel em Ciência da Computação UNESP - Bauru
LPIC1 - Linux Professional Institute Certification - Nível 1
renato.diogo@gmail.com renato.diogo@yahoo.com.br
2009/5/13 Little_Oak whilelive@gmail.com:
Tu roda SuExec? Teu php roda como CGI? Tu roda mod_Evasive? Sobre cgi teus arquivos tem permissão 644 e os diretórios 755?
Atente para isto acima e metade das ocorrências deverá acabar (senão mais).
Depende muito de tuas rules também (no modsec).
--
http://littleoak.wordpress.com -> Dia a dia http://www.nerdblog.info -> For Geeks ++++++++++++++++ Tragédia: E minha bisavó, antes de morrer lendo código sem comentários dizia: "Filho de uma égua..."
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Opa Renato,
Pois é todas as páginas tem essa instrução e o /tmp. Mas é no /tmp mesmo que ele tá colocando o arquivo e rodando. Não posso restringir permissão de escrita porque alguma aplicação que ainda estou vendo grava arquivos sess_????? no /tmp, provavelmente é o webmail. Vou checar isso. O que fiz por enquanto foi remover alguns módulos do apache e bloqueei o servidor de acessar portas externas que não sejam os serviços de correio e dns. Dessa maneira ele não vai conseguir baixar o arquivo. Antigamente o mod_security pegava e barrava ele, agora ele conseguiu um meio de burlar o mod_security. Estranho que ele só tá conseguindo isso no servidor que tá com CentOS no outro que é Debian não consegue. Será que existe alguma vulnerabilidade no apache do CentOS que eles ainda não viram? É uma pergunta à se fazer.
Em Qua, 2009-05-13 às 11:43 -0300, Renato de Oliveira Diogo escreveu:
Bom, quando monto um servidor apache, além do mod-security, ainda implemento duas políticas:
o apache tem permissão de somente leitura na estrutura em que ele pode consultar. Somente em local que realmente ele deve ter permissão de escrita que é liberado, do resto somente leitura.
outra coisa é você restringir usando o parametro do "php php_admin_value open_basedir "/var/www/caminho/httpdocs:/tmp"
ou seja, o php conseguirá acessar somente os caminhos que for estipulado aqui.
Atenciosamente ________________________________________________ Renato de Oliveira Diogo
Bacharel em Ciência da Computação UNESP - Bauru
LPIC1 - Linux Professional Institute Certification - Nível 1
renato.diogo@gmail.com renato.diogo@yahoo.com.br
2009/5/13 Little_Oak whilelive@gmail.com:
Tu roda SuExec? Teu php roda como CGI? Tu roda mod_Evasive? Sobre cgi teus arquivos tem permissão 644 e os diretórios 755?
Atente para isto acima e metade das ocorrências deverá acabar (senão mais).
Depende muito de tuas rules também (no modsec).
--
http://littleoak.wordpress.com -> Dia a dia http://www.nerdblog.info -> For Geeks ++++++++++++++++ Tragédia: E minha bisavó, antes de morrer lendo código sem comentários dizia: "Filho de uma égua..."
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Olá,
2009/5/13 Marcelo Gondim gondim@linuxinfo.com.br:
Pois é todas as páginas tem essa instrução e o /tmp. Mas é no /tmp mesmo que ele tá colocando o arquivo e rodando. Não posso restringir permissão de escrita porque alguma aplicação que ainda estou vendo grava arquivos sess_????? no /tmp, provavelmente é o webmail.
Primeiramente, uma olhada nos logs do Apache pode dar uma boa dica de "como" o hacker está entrando. A partir daí você pode começar a entender qual aplicação web é o problema e talvez tirá-la (ou uma parte dela) do ar. Talvez colocar o IP do hacker no iptables possa ajudar a aliviar o problema.
Como uma gambiarra para resolver o seu problema rapidamente, você pode criar uma partição adicional e montá-la no /tmp usando a opção noexec (pode user nodev e nosuid também). Dessa forma, mesmo que o hacker consiga criar um arquivo no /tmp, ele não vai conseguir executá-lo tão facilmente.
A médio termo, você deve pensar em implementar o SELinux, porque ele introduz restrições que vão tornar ainda mais difícil de alguém conseguir executar código na sua máquina a partir de uma aplicação web furada. O SELinux pode ser difícil de implementar no início, algumas aplicações podem precisar de configurações especiais, mas o retorno em segurança faz o esforço valer a pena.
E, obviamente, você deve deixar de rodar essas aplicações furadas. Se você está rodando aplicações open source, você deve procurar as últimas versões e ver se a equipe de desenvolvimento é consciente em relação a segurança. Se as suas aplicações são desenvolvidas in-house, você deve mostrar para os desenvolvedores o problema que a aplicação deles gerou, e indicar que o código seja revisado por um especialista em segurança antes de ser instalado no servidor.
Finalmente, se seu servidor foi comprometido, você não tem mais como garantir que está limpo e que o hacker não deixou nenhuma porta escondida que você não achou. A única coisa que você tem a fazer agora, depois de descobrir o que causou o problema e corrigir o bug, é reinstalar o servidor do zero, sem usar nenhum executável que esteja instalado agora, só backups de antes dele ser hackeado. Qualquer coisa diferente disso pode trazer surpresas para você no futuro.
HTH, Filipe
Alem de outra coisa que devemos considerar.
claramente o problema é a aplicação (o site), pois esse tipo de filtro, tratamento quem deveria garantir é a aplicação.
Agora vamos tentar separar algumas coisas: o apache é uma coisa, o php é outra coisa e assim vai. Então voce pode, por motivos de teste, colocar o php para rodar em modo seguro (do php).
No log, como o Felipe indicou, você pode ter uma ideia de como o hacker está se comportando, adaptando os filtros do mod-security para filtrar o hack.
[]s
Atenciosamente ________________________________________________ Renato de Oliveira Diogo
Bacharel em Ciência da Computação UNESP - Bauru
LPIC1 - Linux Professional Institute Certification - Nível 1
renato.diogo@gmail.com renato.diogo@yahoo.com.br
2009/5/13 Filipe Brandenburger filbranden@gmail.com:
Olá,
2009/5/13 Marcelo Gondim gondim@linuxinfo.com.br:
Pois é todas as páginas tem essa instrução e o /tmp. Mas é no /tmp mesmo que ele tá colocando o arquivo e rodando. Não posso restringir permissão de escrita porque alguma aplicação que ainda estou vendo grava arquivos sess_????? no /tmp, provavelmente é o webmail.
Primeiramente, uma olhada nos logs do Apache pode dar uma boa dica de "como" o hacker está entrando. A partir daí você pode começar a entender qual aplicação web é o problema e talvez tirá-la (ou uma parte dela) do ar. Talvez colocar o IP do hacker no iptables possa ajudar a aliviar o problema.
Como uma gambiarra para resolver o seu problema rapidamente, você pode criar uma partição adicional e montá-la no /tmp usando a opção noexec (pode user nodev e nosuid também). Dessa forma, mesmo que o hacker consiga criar um arquivo no /tmp, ele não vai conseguir executá-lo tão facilmente.
A médio termo, você deve pensar em implementar o SELinux, porque ele introduz restrições que vão tornar ainda mais difícil de alguém conseguir executar código na sua máquina a partir de uma aplicação web furada. O SELinux pode ser difícil de implementar no início, algumas aplicações podem precisar de configurações especiais, mas o retorno em segurança faz o esforço valer a pena.
E, obviamente, você deve deixar de rodar essas aplicações furadas. Se você está rodando aplicações open source, você deve procurar as últimas versões e ver se a equipe de desenvolvimento é consciente em relação a segurança. Se as suas aplicações são desenvolvidas in-house, você deve mostrar para os desenvolvedores o problema que a aplicação deles gerou, e indicar que o código seja revisado por um especialista em segurança antes de ser instalado no servidor.
Finalmente, se seu servidor foi comprometido, você não tem mais como garantir que está limpo e que o hacker não deixou nenhuma porta escondida que você não achou. A única coisa que você tem a fazer agora, depois de descobrir o que causou o problema e corrigir o bug, é reinstalar o servidor do zero, sem usar nenhum executável que esteja instalado agora, só backups de antes dele ser hackeado. Qualquer coisa diferente disso pode trazer surpresas para você no futuro.
HTH, Filipe _______________________________________________ CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Em Qua, 2009-05-13 às 13:54 -0400, Filipe Brandenburger escreveu:
Olá,
2009/5/13 Marcelo Gondim gondim@linuxinfo.com.br:
Pois é todas as páginas tem essa instrução e o /tmp. Mas é no /tmp mesmo que ele tá colocando o arquivo e rodando. Não posso restringir permissão de escrita porque alguma aplicação que ainda estou vendo grava arquivos sess_????? no /tmp, provavelmente é o webmail.
Primeiramente, uma olhada nos logs do Apache pode dar uma boa dica de "como" o hacker está entrando. A partir daí você pode começar a entender qual aplicação web é o problema e talvez tirá-la (ou uma parte dela) do ar. Talvez colocar o IP do hacker no iptables possa
Sim estou catando em todos os logs de todos os sites com grep e olhando e nada encontrado até agora mas tem muito à ver ainda pois são mais de 100 sites. Já fiz um bloqueio de firewall liberando OUTPUT somente as portas necessárias como 25/tcp, 53/udp e 53/udp. O restante está bloqueado e isso já vai impedir que ele baixe algo do servidor.
ajudar a aliviar o problema.
Como uma gambiarra para resolver o seu problema rapidamente, você pode criar uma partição adicional e montá-la no /tmp usando a opção noexec (pode user nodev e nosuid também). Dessa forma, mesmo que o hacker consiga criar um arquivo no /tmp, ele não vai conseguir executá-lo tão facilmente.
Uma excelente idéia também. :) vou tentar ela caso não funcione o bloqueio que fiz com o iptables. ;)
A médio termo, você deve pensar em implementar o SELinux, porque ele introduz restrições que vão tornar ainda mais difícil de alguém conseguir executar código na sua máquina a partir de uma aplicação web furada. O SELinux pode ser difícil de implementar no início, algumas aplicações podem precisar de configurações especiais, mas o retorno em segurança faz o esforço valer a pena.
Sim, vou parar para dar uma olhada nisso com certeza. Até o momento nunca havia precisado.
E, obviamente, você deve deixar de rodar essas aplicações furadas. Se você está rodando aplicações open source, você deve procurar as últimas versões e ver se a equipe de desenvolvimento é consciente em relação a segurança. Se as suas aplicações são desenvolvidas in-house, você deve mostrar para os desenvolvedores o problema que a aplicação deles gerou, e indicar que o código seja revisado por um especialista em segurança antes de ser instalado no servidor.
É o problema é que peguei recentemente esse servidor e nele já haviam pra lá de 100 páginas em PHP e já resolvi algumas com furos mas deve ter alguma ainda com certeza.
Finalmente, se seu servidor foi comprometido, você não tem mais como garantir que está limpo e que o hacker não deixou nenhuma porta escondida que você não achou. A única coisa que você tem a fazer agora, depois de descobrir o que causou o problema e corrigir o bug, é reinstalar o servidor do zero, sem usar nenhum executável que esteja instalado agora, só backups de antes dele ser hackeado. Qualquer coisa diferente disso pode trazer surpresas para você no futuro.
Não acredito que o root dele tenha sido comprometido porque desde o download como o arquivo em questão foram feitos apenas com o usuário apache, tudo que foi criado no sistema estava como usuário apache e o processo era um processo filho do apache. Passei alguns programas para checagem como o rkhunter e outros e não encontrei nada suspeito mesmo.
Bem vamos ver como vai ficar depois desses bloqueios que fiz. :) Estou suspeitando que a falha possa estar no webmail porque além de antigo, é aquele webmiau ele é o único que grava arquivos no /tmp as outras páginas estão confinadas em seus diretórios.
discuss-pt-br@lists.centos.org
-
Filipe Brandenburger -
Little_Oak -
Marcelo Gondim -
Renato de Oliveira Diogo -
Thiago Avelino