Ubuntu - Tráfego UDP na porta 123

2

Tenho notado que, ultimamente, o LED ethernet do meu Odroid está constantemente piscando, mesmo quando não estou esperando tráfego. Eu corri iptraf e, além das tentativas de tentativas de adivinhação de força bruta SSH (que são então bloqueadas por fail2ban ) eu não vi nenhum tráfego TCP. No entanto, notei uma enorme quantidade de tráfego UDP na porta 123 que não tenho idéia de onde está vindo.

| UDP (46 bytes) from 188.130.254.14:443 to 192.168.1.68:123 on eth0

| UDP (46 bytes) from 188.130.254.14:443 to 192.168.1.68:123 on eth0

| UDP (46 bytes) from 121.40.223.68:20630 to 192.168.1.68:123 on eth0

| UDP (46 bytes) from 45.63.62.141:33296 to 192.168.1.68:123 on eth0

Configurei meu roteador para encaminhar o tráfego UDP de entrada na porta 123 para um endereço IP desconhecido e ainda ver uma quantidade estúpida de pacotes UDP em iptraf . Alguém tem alguma idéia do que pode estar acontecendo?

Obrigado!

    
por Mauricio Ramalho 15.11.2017 / 12:24

5 respostas

2

Você afirma que

I have stopped ntpd

Então, o que você tem observado é quase certamente uma atividade ilegal. O UDP / 123 é um atribuído pela IANA port , ele não pode ser usado por nenhum outro aplicativo legítimo: o Estados da página de atribuição de porta da IANA oficial :

Assigned ports both System and User ports SHOULD NOT be used without or prior to IANA registration.

(As portas do sistema são definidas mais acima no mesmo documento que as portas no intervalo 0-1023).

O TCP / 123 da porta é usado por um malware bem conhecido, mostrando que, em sistemas em que as credenciais raiz foram obtidas As portas do sistema são usadas rotineiramente para contrabandear o tráfego ilícito. Existem muitas razões plausíveis para usar o UDP em vez do TCP, possivelmente o mais importante deles é o uso de uma VPN criptografada (caso em que wireshark não o ajudará em nada), e por usar uma Porta do Sistema (é mais fácil evitar a detecção se você usar uma porta inocente).

Mais que wireshark , seu amigo é ss :

ss -lnup | grep 123

lhe dará o ID do processo escutando na porta UDP / 123. Qualquer coisa, menos ntp , ou, pior ainda, nada, significa que você foi invadido. Mas nós vamos atravessar a ponte quando chegarmos lá.

EDITAR :

Uma continuação ao seu comentário. Essas evidências sugerem que você foi hackeado:

  1. um serviço misterioso rodando em UDP / 123, não deixando rastros (o que sugere a presença de um rootkit);

  2. um misterioso encaminhamento de porta no seu roteador;

  3. conexões de contas de consumidor (confira whatismyipaddress.com ou com whois comando). BTW, none dos três endereços IP fornecidos é conectado remotamente com um servidor ntp .

Sua aposta mais segura é reinstalar o sistema operacional e, em seguida, alterar a configuração (incluindo a senha !!) do seu roteador (possivelmente desativando o login de senha totalmente em favor do uso de chaves criptográficas) para permitir somente link conexões. Se você não deseja reinstalar o sistema operacional porque tem dados confidenciais, então pegue qualquer distribuição Linux rodando a partir de um pendrive USB (o Ubuntu está ótimo), inicialize seu computador a partir dele ( não do seu disco rígido), instale clamav , rkhunter e chkroot na chave USB, e configure-os para trabalhar em seu disco rígido. Isso evita a capacidade de alguns malwares evitem a detecção de programas antimalware porque o disco no qual o malware reside está sendo usado passivamente, isto é, os programas nele não estão sendo executados.

Além disso, lembre-se de que a proteção por senha ( fail2ban não obstante) não é proteção suficiente hoje em dia, e que você deve sempre usar chaves criptográficas. Além disso, mudar a porta padrão para as conexões ssh faz com que você fique invisível, pelo menos, para as kiddies de script (embora qualquer adversário determinado nunca seja enganado por tal estratagema). Além disso, você pode ler este post , incluindo as respostas, para obter mais algumas dicas.

Boa sorte.

    
por 15.11.2017 / 13:10
2

A porta UDP 123 é a porta NTP padrão. Portanto, verifique sua configuração NTP. O mais provável é a sincronização padrão. Você teria que capturar pacotes com o tcpdump e inspecionar o conteúdo (wireshark).

    
por 15.11.2017 / 12:28
1

I noticed a massive amount of UDP traffic on port 123 that I have no idea where is coming from.

Na minha definição de massivo, isso significa que você vê o tráfego na porta 123 consistentemente a cada segundo, por exemplo, por um minuto inteiro.

E você diz que não solicitou isso. Por exemplo, você não se listou como um servidor NTP público :). Ou configurou 5 ou mais computadores para usar este servidor NTP e assistiu ao tráfego quando todos os 5 estão ligados ao mesmo tempo.

Se sim, existe outra possibilidade que poderia explicar isso. Alguém pode estar tentando usar seu computador como parte de um ataque de inundação em outra pessoa. Procure "ataque de amplificação NTP". Os principais resultados do Google incluem explicações de empresas como a Cloudflare, que vendem serviços que protegem sites contra ataques de inundação.

link

(Eu vi isso acontecer sozinho, mas com tráfego uPNP, porta UDP 1900, em um roteador consumidor com uma configuração ruim.)

Neste ponto, minha suposição é que os invasores ainda estão tentando usá-lo e continuarão por algum tempo. Se você bloqueá-los a meio de um ataque, eles não receberão necessariamente qualquer sinal de que isso aconteceu. Eles podem notar mais tarde, quando eles fazem uma nova varredura para amplificar os servidores NTP que podem usar.

Parece que a alteração na configuração do roteador simplesmente não funcionou por algum motivo ...

I guess the port forward I made on my router took a while to kick in. Basically what I did was forward all UDP traffic on port 123 to 192.168.2.3. On my LAN, all IPs are 192.168.1.*. I don't know why the traffic was being delivered to my Linux box in the first place. The router is supposed to block everything except the port forwards I manually define.

Oh. Se você adicionar essa condição, não entendi a situação, desculpe. Não consigo entender por que você veria essas condições, a menos que eu comece a criticar o que você disse.

Observe que às vezes as pessoas configuram uma configuração separada rotulada como "DMZ" ou "redirecionamento de porta padrão" para um servidor como o seu Odroid, que basicamente encaminha todas as portas para as quais você não tem uma regra específica. Eu inicialmente assumi que você tinha alguma configuração assim. Se eu fosse você, procuraria por essa opção de configuração. É bastante plausível que eu tenha definido essa opção antes e esquecido.

Não tenho 100% de certeza até agora. Eu também poderia verificar que estava vendo somente o UDP de entrada e que não estava vendo quantidades iguais ou maiores de UDP de saída. Se houver também uma "quantidade massiva" de UDP de saída inesperado na porta 123, isso sugeriria que o Odroid havia sido invadido. Em seguida, você deve reinstalá-lo a partir do zero com atenção cuidadosa à segurança (software atualizado e cuidado com o acesso SSH).

Acho que essas são as interpretações mais prováveis. O segundo caso é menos familiar para mim. Eu não vi artigos populares sobre distribuições Linux de servidor genérico sendo comprometidas por ataques de inundação (ou seja, comprometer através de SSH ou um servidor web) - e particularmente não por malwares compatíveis com ARM. Tudo isso é possível, mas não sei como é comum.

    
por 10.07.2018 / 13:23
0

pode ser systemd-timesyncd ...

Para saber, use (na raiz):

# ss -lnup | grep systemd-timesyn

Se o retorno for:

users:(("systemd-timesyn",pid=xxxx,fd=xx))

Então é isso.

Você também pode usar:

systemctl status systemd-timesyncd

Para parar uma desabilitação systemd-timesyncd (na raiz):

# systemctl stop systemd-timesyncd

# systemctl disable systemd-timesyncd
    
por 10.07.2018 / 13:04
-2

Você pode usar tcpdump para capturar o tráfego, depois copiar o arquivo pcap para o seu pc e inspecioná-lo no wireshark. Não se deixe enganar pelo nome, o tcpdump captura os pacotes do udp também.

    
por 15.11.2017 / 12:26

Tags