habilitar o serviço de eco e problemas de lacunas de segurança do Linux

3

para habilitar o serviço de eco, precisamos adicionar as linhas de eco como no exemplo a seguir:

more /etc/inetd.conf


echo   stream  tcp     nowait  root    internal
echo   dgram   udp     wait    root    internal

a questão é sobre questões de segurança que podem estar relacionadas ao fato de o serviço de eco ser ativado

existe algum problema de segurança na minha máquina Linux quando abrimos o serviço de eco?

Se sim, por favor, explique quais problemas de segurança podem aparecer quando o serviço de eco estiver aberto?

    
por maihabunash 26.11.2014 / 14:57

1 resposta

6

Você não deseja ativar o dgram (UDP).

Isso permite que um invasor faça sua máquina enviar pacotes UDP com qualquer conteúdo e, se os invasores puderem enviar pacotes com o endereço de origem falsificado, significa qualquer pacote UDP para qualquer destino.

Por exemplo, se o atacante:

packit -t UDP -s 10.10.10.10 -S 7 -d 10.10.10.11 -D 7 -p have-fun-with-that

Onde 10.10.10.11 é o seu endereço IP e 10.10.10.10 é o endereço IP de outra máquina em sua rede que também tem o dgram / UDP echo serviço habilitado, então isso iniciará um pingue-pongue contínuo entre esses dois (note que UDP chargen , time e daytime (entre os serviços criados na maioria das implementações inetd ) têm o mesmo problema e devem ser evitados também).

Então, enviando apenas um pacote (e ele pode injetar mais alguns para piorar), o atacante está gerenciando o uso da largura de banda entre as duas vítimas, com o mínimo de esforço. / p>

Torna-se ainda mais interessante quando você começa a usar as mensagens de transmissão.

Mesmo que a sua rede não permita que pacotes falsificados cheguem até você (e eles não podem fazer isso por pacotes vindos da Internet), outros não. Então você ainda pode ser enganado nesse jogo de pingue-pongue com eles (agindo como uma vítima e um atacante involuntário).

Habilitar o serviço UDP echo (e especialmente se você o expuser pela Internet) é um pouco como entrar voluntariamente em uma botnet (com as ações da botnet limitadas a enviar pacotes UDP arbitrários).

O fato de permitir que qualquer pessoa com acesso ao seu serviço echo mande qualquer pacote UDP para qualquer lugar também significa que eles podem fazer algo repreensível em seu nome (e, por exemplo, ter seu endereço IP banido por abuso) ou possivelmente -passar algum mecanismo de firewall.

Por exemplo, se sua máquina tiver várias interfaces (e filtragem de caminho inverso não ativada), por exemplo, uma com o endereço 10.0.0.1/24 e outra com 192.168.1.123/24, uma O invasor no host 10.0.0.2 pode forjar um pacote NAT-PMP com a fonte 192.168.1.1:5351 e o destino 10.0.0.1: 7 E seu echo seria enviado para 192.168.1.1 e se isso é um roteador / firewall aceitando NAT-PMP, o invasor poderia efetivamente perfurar esse firewall usando sua máquina como proxy (e em vez de um pacote NAT-PMP, que também pode ser um pacote SNMP PUT ou qualquer outra coisa como o pacote inicial de pingue-pongue evocado acima).

O problema com esse echo é que ele responde com os mesmos dados que recebe. Esse eco UDP foi substituído pelo echo do ICMP (conforme enviado pelo comando ping ), em que você tem diferentes pacotes ECHO_REQUEST e ECHO_REPLY e são diferentes dos pacotes UDP. Portanto, não é possível fazer muito mal com um ECHO_REQUEST falsificado (veja o ataque Smurf ).

Mais leitura em:

por 26.11.2014 / 16:25