Dúvida sobre segurança [RESOLVIDO]

smkbarbosa escreveu:

Boa tarde,

tenho um servidor rodando ubuntu server 14 + apache2. Há uns 2 dias tenho tido problema de lentidão no acesso ao site.

Quando rodo um netstat -antp, entre os resultados, tenho esse que tem me intrigado um pouco:

tcp 0 1 200.138.149.187:48011 31.184.192.250:80 SYN_ENVIADO 7077/apache2
tcp 0 1 200.138.149.187:47975 31.184.192.250:80 SYN_ENVIADO 4183/apache2
tcp 0 1 200.138.149.187:47969 31.184.192.250:80 SYN_ENVIADO 6992/apache2
tcp 0 1 200.138.149.187:47994 31.184.192.250:80 SYN_ENVIADO 4312/apache2
tcp 0 1 200.138.149.187:47983 31.184.192.250:80 SYN_ENVIADO 4281/apache2
tcp 0 1 200.138.149.187:47997 31.184.192.250:80 SYN_ENVIADO 4292/apache2
tcp 0 1 200.138.149.187:48006 31.184.192.250:80 SYN_ENVIADO 4321/apache2
tcp 0 1 200.138.149.187:47966 31.184.192.250:80 SYN_ENVIADO 4323/apache2
tcp 0 1 200.138.149.187:47996 31.184.192.250:80 SYN_ENVIADO 6990/apache2
tcp 0 1 200.138.149.187:48007 31.184.192.250:80 SYN_ENVIADO 4285/apache2
tcp 0 1 200.138.149.187:48005 31.184.192.250:80 SYN_ENVIADO 4249/apache2
tcp 0 1 200.138.149.187:47999 31.184.192.250:80 SYN_ENVIADO 4253/apache2
tcp 0 1 200.138.149.187:47991 31.184.192.250:80 SYN_ENVIADO 6924/apache2
tcp 0 1 200.138.149.187:47987 31.184.192.250:80 SYN_ENVIADO 7010/apache2
tcp 0 1 200.138.149.187:47992 31.184.192.250:80 SYN_ENVIADO 7034/apache2
tcp 0 1 200.138.149.187:47995 31.184.192.250:80 SYN_ENVIADO 4324/apache2
tcp 0 1 200.138.149.187:48010 31.184.192.250:80 SYN_ENVIADO 4191/apache2

Já fiz bloqueio no iptables pra esse ip (input/output) porém não sei mais o que verificar.

Alguém poderia me dar um dica do que fazer?

Grato

Divulgada ferramenta de DDoS para Apache e Squid



Sistemas Operativos Implicados: Linux, Windows, Solaris, FreeBSDOpenBSD, NetBSD, OS2
Aplicações Implicadas: Apache
I. Descrição

Foi recentemente divulgada uma ferramenta de DoS/DDoS (Negação de Serviço) para Apache (1.x e 2.x) e Squid. Esta ferramenta tem a particularidade de exigir muito poucos recursos computacionais por parte do atacante, podendo mesmo ser levada a cabo através de um único cliente doméstico caso não sejam tomadas algumas medidas preventivas.

Esta ferramenta efectua vários pedidos HTTP incompletos ao servidor que pretende afectar, mantendo simultâneamente várias ligações abertas e levando ao eventual esgotamento do número máximo de ligações do servidor. Ao esgotar o número máximo de ligações os pedidos dos clientes legítimos não serão atendidos, criando assim uma condição de negação de serviço.

A ferramenta inicia uma ligação com um pedido aparentemente legítimo porém incompleto, como por exemplo:

GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n

Como se pode verificar, para finalizar o pedido está em falta o caracter de controle CRLF. Em seguida a ferramenta aguarda algum tempo e envia ciclicamente novos dados sem qualquer significado (ex: X-a: b\r\n), apenas com o objectivo de manter a ligação aberta.

II. Solução

Esta ferramenta não explora uma vulnerabilidade ou erro de construção do Apache ou Squid mas sim na implementação do protocolo HTTP nestas ferramentas pelo que não existe (ainda) nenhuma actualização que permita lidar com a situação acima descrita.

É possível no entanto tomar algumas medidas que podem permitir a mitigação deste problema.

Instalação de um reverse proxy

A instalação de um reverse proxy ou balanceador de carga em cima do Apache/Squid que não seja afectado por este comportamento pode evitar este tipo de ataques.

Redução do tempo definido na directiva TimeOut do Apache.

A directiva TimeOut do Apache define o tempo máximo que o servidor vai esperar por um pedido válido de um cliente. Na configuração por defeito do Apache esta directiva vem configurada para 300 segundos (5 minutos), o que significa que esta ferramenta pode manter cada ligação aberta por 5 minutos.

Recomenda-se a redução deste tempo para apenas alguns segundos, tendo obviamente o cuidado necessário na definição de um intervalo de tempo suficiente para permitir pedidos dos clientes legítimos.

Esta medida não evita no entanto o comportamento da ferramenta, apenas aumenta a quantidade de recursos (principalmente os recursos de rede) necessários por parte do atacante para a obtenção de algum sucesso no ataque.

Aumentar o número definido na directiva MaxClients do Apache

A directiva MaxClients do Apache define o número máximo de ligações simultâneas. Este valor está definido por defeito para 256 conexões simultâneas. Este valor pode ser aumentado tendo sempre em conta as limitações técnicas do servidor.

Limitar o acesso a endereços IP suspeitos

Se for detectado um elevado número de ligações abertas pelo mesmo endereço IP podem ser bloqueados ou reduzidos os recursos afectos aos pedidos desse mesmo endereço.

Para bloquear todos pedidos de um determinado IP pode-se recorrer a uma firewall ou configurar o Apache para não responder a pedidos desse endereço IP.

Para limitar os recursos afectados aos pedidos de um determinado IP pode-se utilizar o módulo mod_limitipconn para o Apache.

Analisar outras medidas preventivas contra ataques DoS/DDoS

Apache "Security Tips" - http://httpd.apache.org/docs/trunk/misc/security_tips.html
Instalar firewall aplicacional Mod_Security - http://www.modsecurity.org/
Preventing DDoS Attacks - http://www.linuxsecurity.com/content/view/121960/49/
III. Referências

Apache HTTP DoS tool released
http://isc.sans.org/diary.html?storyid=6601&rss

Apache HTTP DoS tool mitigation
http://isc.sans.org/diary.html?storyid=6613&rss

smkbarbosa escreveu:

Encontrei o seguinte referente ao ataque DDOS


Fonte: http://www.cert.pt/index.php/alertas/1501-divulgada-ferramenta-de-ddos-para-apache-e-squid

smkbarbosa escreveu:

Fiz os testes com o proxy reverso mais não funcionou.

Habilitei o SSL no apache, o site voltou a acessar normalmente.
Fiz os bloqueios no iptables para os IPs que estavam com conexão ativa e deixei somente ips brasileiros para acesso, porém ainda não resolveu.

Agora vou rever os arquivos com calma e achar a causa do problema.

Obrigado a todos.