Complementando,proponha a utilização do chroot, é uma excelente ferramenta para "enjaular" aplicações sem deixar que estas tenham acesso ao seu ambiente de forma global.
Em 22 de novembro de 2014 17:46, Rodrigo Cunha <rodrigo.root...@gmail.com> escreveu: > Bom, ai depende. > Dei uma olhada rapida no google, e recebi a informação que este problema é > de liberar acesso ao servidor. > Pensando brutamente, acredito que o mais basico seria bloquear o acesso a > seu servidor de ips não autorizados através de um firewall, segundo, para > melhorar o gerenciamento utilize o hosts.allow e hosts.deny para permitir > acessos autorizado a serviços. > Outra questão de segurança é a utilização do usuario root, não deixe que > seu ssh/ftp permita login apartir do usuario root, utilize o sudo para o > gerenciamento local. > > Outro checklist seria a padronização de seus repositorios e retirar de lá, > repositorios que utilizem softwares atualizados com bug.Isso rola muito em > servidores de aplicação. > > Atualização de servidores/serviços rotineiramente. > > Outra ponto para checklist é a utilização de monitoramento tanto para > serviços, quanto para arquivos em ambientes criticos, tais como arquivos de > permissão : /etc/passwd ,/etc/shadow , /etc/rc.local , /etc/hosts.deny , > /etc/hosts.allow. > > Levante a questão sobre a utilização de um servidor de VPN (OpenVON) pois > seria interessante para o acesso remoto ao seu ambiente.Isso impede que > acesso feito por redes inseguras coloquem em risco os dados de usuários. > > Mas cuidado, tem gestores que não gostam de iniciativas de seus > subordinados, principalmente de funcionários que não são de seu Setor ou > até mesmo que você está gerando demanda para a equipe deles.Vai de gestor > para gestor. > > Acho que isso pode ser um checklist basico interessante para, ao menos, > analisar a segurança de seu ambiente. > > > > Em 22 de novembro de 2014 10:44, Vitor Hugo <vitorhug...@hotmail.com> > escreveu: > > Uma medida rapida seria trocar a shell e desinstalar o bash depois com >> mais tempo reavaliar as atualizacoes dos pacotes e ver pq nao estao sendo >> atualizados. Alguns sistemas nao promoverao atualizacoes como no caso do os >> x leopard pra baixo e monowall geralmente voce pode atualizar por conta >> propria neste casos. >> >> Sent using CloudMagic >> <https://cloudmagic.com/k/d/mailapp?ct=ta&cv=5.1.10.7&pv=4.2.2> >> >> On sáb, nov 22, 2014 at 10:35 AM, Helio Loureiro <he...@loureiro.eng.br> >> wrote: >> >> Uma simples atualização dois servidores teria mitigado o problema. Se nem >> isso fizeram, não há segurança no mundo que se possa aplicar. Não com essa >> equipe. >> >> Helio Loureiro >> -= sent by Android =- >> On Nov 21, 2014 2:53 PM, "Anacleto Junior" <suporte.anacl...@gmail.com> >> wrote: >> >>> Bom dia pessoal, >>> >>> Recentemente tenho visto que no local onde trabalho alguns servidores >>> sofreram ataques devido ao Shell Shock. Como não sou da equipe responsável >>> por isso, não tenho permissão para analisar o caso e gostaria de saber a >>> opinião dos colegas, caso possível: >>> >>> - Quais seriam os primeiros procedimentos a serem feitos numa suspeita >>> de comprometimento da máquina? Desligar completamente? Existe algum >>> checklist que eu poderia consultar para já me inteirar do assunto? >>> >>> - Quais logs eu poderia monitorar além do lastlog, /var/log/wtmp, >>> access.log em um servidor executando Apache? >>> >>> Agradeço antecipadamente >>> >>> -- >>> Anacleto Júnior >>> Analista de TI e Redes >>> Linux User: #447388 >>> >>> -- To UNSUBSCRIBE, email to >> debian-user-portuguese-requ...@lists.debian.org with a subject of >> "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: >> https://lists.debian.org/blu436-smtp953d0fc022f2ac33a8799aa...@phx.gbl > > > > > -- > Atenciosamente, > Rodrigo da Silva Cunha > > -- Atenciosamente, Rodrigo da Silva Cunha
