Monitorando o ASP.NET e o SQL Server para segurança

10

Qual é a melhor (ou boa) maneira de monitorar um aplicativo ASP.NET para garantir que ele seja seguro e detectar rapidamente a invasão? Como podemos saber com certeza que, a partir de agora, nossa aplicação é totalmente descompromissada?

Estamos prestes a lançar um aplicativo da Web do ASP.NET 4, com os dados armazenados no SQL Server. O servidor Web é executado no IIS em uma instância do Windows Server 2008 e o servidor de banco de dados é executado no SQL Server 2008 em uma instância separada do Win 2008.

Analisamos as recomendações de segurança da Microsoft e acho que nosso aplicativo é muito seguro. Nós implementamos "defesa em profundidade" e consideramos uma série de vetores de ataque.

Assim, "nos sentimos" confiantes, mas ainda não temos visibilidade real sobre a segurança do nosso sistema. Como podemos saber imediatamente se alguém penetrou? Como podemos saber se um pacote de algum tipo foi depositado em um de nossos servidores? Como podemos saber se um vazamento de dados está em andamento?

Quais são alguns conceitos, ferramentas, melhores práticas, etc.?

Obrigado antecipadamente, Brian

Pensamentos adicionais 22/4/11

Chris, obrigado pelas observações pessoais muito úteis e dicas abaixo.

Qual é uma abordagem boa e abrangente para monitorar a atividade atual de aplicativos para segurança? Além da vigilância constante na aplicação de melhores práticas, patches, etc., eu quero saber exatamente o que está acontecendo dentro do meu sistema agora. Eu quero ser capaz de observar e analisar sua atividade de uma forma que me mostre claramente qual tráfego é suspeito e qual não é. Por fim, quero que essa informação seja totalmente precisa e fácil de digerir.

Como nos aproximamos eficientemente disso? Uma boa solução não incluiria o monitoramento de logins, atividade de banco de dados, atividade do ASP.NET, etc. além de pacotes no fio? Quais são alguns exemplos de como assumir uma forte postura de segurança?

Brian

    
por BrianFinkel 21.04.2011 в 16:09

3 respostas

1

Eu ainda não experimentei, mas Lenny Zeltser me direcionou para o OSSEC, que é um sistema de detecção de invasões baseado em host que monitora continuamente um servidor inteiro para detectar qualquer atividade suspeita. Isso parece exatamente o que eu quero!

Adicionaremos mais informações assim que tiver a chance de testá-las completamente.

OSSEC pode ser encontrado em Ссылка

    
por BrianFinkel 04.08.2011 / 18:45
3

O termo que você está procurando é Sistema de Detecção de Intrusão (IDS). Existe um termo relacionado chamado Sistema de Prevenção de Intrusões (IPS).

O tráfego do monitor da IDS chega aos seus servidores no nível IP e envia alertas com base em análises sofisticadas do tráfego.

Os IPS são a próxima geração de IDS que realmente tentam bloquear certas atividades.

Existem muitos sistemas comerciais e de código aberto disponíveis, incluindo Snort , SourceFire , Endace e outros .

Em suma, você deve considerar a adição de um desses sistemas à sua mistura para monitoramento em tempo real e bloqueio potencial de atividades perigosas.

Eu queria adicionar mais algumas informações aqui, pois a área de comentários é um pouco pequena.

A principal coisa que você precisa entender são os tipos de ataques que você verá. Eles vão desde scripts automatizados relativamente pouco sofisticados até ataques direcionados altamente sofisticados. Eles também atingirão tudo o que puderem ver do próprio site para o IIS, .Net, servidor de email, SQL (se acessível), até o firewall e outras máquinas / serviços expostos. Uma abordagem holística é a única maneira de realmente monitorar o que está acontecendo.

De um modo geral, um novo site / empresa vai ser atingido com os scripts automatizados em poucos minutos (eu diria 30 no máximo) de ir ao vivo. Qual é o número um motivo para novas instalações do MS Windows manterem a rede severamente bloqueada durante a instalação. Heck, eu vi máquinas pregadas em 30 segundos depois de serem ligadas pela primeira vez.

A abordagem que os hackers / worms fazem é varrer constantemente amplos intervalos de endereços IP, isso é seguido por impressões digitais de máquina para aqueles que respondem. Com base no perfil, eles enviam certos tipos de ataques do seu jeito. Em alguns casos, a etapa de criação de perfil é ignorada e eles atacam determinadas portas, independentemente da resposta. A porta 1443 (SQL) é comum.

Embora a forma mais comum de ataque, os automatizados são de longe os mais fáceis de lidar. O desligamento de portas não utilizadas, o desligamento do ICMP (ping response) e a instalação de um firewall decente manterão a maioria dos scanners longe.

Para os ataques por script, certifique-se de não expor os pacotes normalmente instalados, como o PhpMyAdmin, as ferramentas de administração da Web do IIS ou até mesmo a Área de Trabalho Remota fora do seu firewall. Além disso, livre-se de qualquer conta chamada "admin", "administrator", "guest", "sa", "dbo", etc. Finalmente, certifique-se de que suas senhas não sejam permitidas como nome de alguém e definitivamente NÃO sejam a única que enviado com um produto.

Ao longo destas linhas, certifique-se de que seu servidor de banco de dados NÃO esteja diretamente acessível fora do firewall. Se por algum motivo você tiver acesso direto, mude, pelo menos, a porta # para a qual ela responde e reforce a criptografia.

Uma vez que tudo isso é feito corretamente e garantido, os únicos serviços expostos devem ser os da web (porta 80/443). Os itens que ainda podem ser explorados são bugs no IIS, no .Net ou em seu aplicativo da Web.

Para IIS e .net, você DEVE instalar as atualizações do Windows a partir do MS, assim que forem liberadas. A MS tem sido extremamente boa em promover atualizações de qualidade para Windows, IIS e .Net. Além disso, a grande maioria das atualizações é para vulnerabilidades que já estão sendo exploradas no mundo. Nossos servidores foram configurados para instalar atualizações automaticamente assim que estiverem disponíveis e nós nunca foi gravado sobre isso (voltando ao menos quando o servidor 2003 foi lançado).

Além disso, você precisa ficar por dentro das atualizações do seu firewall. Não faz muito tempo que um dos firewalls da Cisco tinha um bug onde poderia ser sobrecarregado. Infelizmente, deixa todo o tráfego passar quando isso acontece. Embora corrigidos rapidamente, as pessoas ainda estavam sendo marteladas mais de um ano depois, porque os administradores não conseguiam acompanhar os patches do IOS. Mesmo problema com as atualizações do Windows. Muitas pessoas foram hackeadas simplesmente porque não aplicaram as atualizações que a impediriam.

Os ataques mais direcionados são um pouco mais difíceis de lidar. Um bom número de hackers está indo atrás de aplicativos da web personalizados. Coisas como postar para nos contatar e formulários de login.As postagens podem incluir JavaScript que, uma vez visualizado por um administrador, pode fazer com que as credenciais sejam transferidas ou levar à instalação de keyloggers ou trojans nos computadores dos destinatários.

O problema aqui é que você pode ficar comprometido sem nem mesmo saber. As defesas incluem garantir que HTML e JavaScript não sejam enviados por meio de seu site. tendo sólidas (e constantemente atualizadas) checagens de spam e vírus no servidor de e-mail, etc. Basicamente, você precisa olhar de todas as maneiras possíveis para uma entidade externa enviar algo para você e fazer algo a respeito. Muitas empresas da Fortune 500 continuam sendo atingidas por coisas como essa ... o Google incluiu.

Espero que o acima ajude alguém. Se assim for e isso leva a um ambiente mais seguro, então serei um cara feliz. Infelizmente, a maioria das empresas não monitora o tráfego, por isso não faz ideia de quanto tempo é gasto com suas máquinas, evitando esse lixo.

    
por NotMe 21.04.2011 / 18:46
2

Eu posso dizer que alguns pensam - mas ficarei feliz em ouvir mais idéias.

  

Como podemos saber imediatamente se alguém penetrou?

Isto não é tão fácil e, na minha opinião, ** uma ideia é fazer algumas armadilhas ** dentro do seu backoffice, juntamente com o monitor para logins duplos de diferentes ips .

uma armadilha pode ser qualquer coisa que você possa imaginar, por exemplo uma página não real que diga "criar novo administrador" , ou "alterar senha do administrador", no backoffice , e lá alguém pode entrar e tentar fazer um novo administrador é, com certeza, um penetrador - é claro que essa armadilha deve ser conhecida apenas em você, ou então não há sentido para isso.

Para mais segurança, qualquer alteração aos administradores deve precisar de uma segunda senha e, se alguém tentar fazer uma alteração real na conta do administrador, ou tentar adicionar um novo administrador, e falhar nessa segunda senha, deve ser considerado como um penetrador.

  

maneira de monitorar um aplicativo ASP.NET

Acho que qualquer ferramenta que monitore as páginas para alteração de texto pode ajudar nisso. Por exemplo, este Network Monitor pode monitorar o texto específico na sua página e alertá-lo, ou realizar algumas ações se este texto não for encontrado, isso significa que alguém muda a página.

Então você pode adicionar algum texto especial, e se você não encontrou, então você pode ter certeza de que alguém irá alterar o núcleo da sua página, e provavelmente é um arquivo de mudança.

  

Como podemos saber se um pacote de algum tipo foi depositado em um de nossos servidores

Esta pode ser qualquer página aspx carregada no seu servidor e agir como um navegador de arquivos. Para isso, não sugiro adicionar arquivos web.config aos diretórios usados ​​para fazer o upload de dados, e neste web.config não é permitido executar nada.

<configuration>
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
</configuration>
    
por Aristos 21.04.2011 / 18:30