☰

Ataque ao servidor Ubuntu? Como resolver?

tag-icon • tag-icon security ubuntu hacking malware udp
Ataque ao servidor Ubuntu? Como resolver?

Algo (Alguém) está enviando pacotes UDP enviados de todo o nosso intervalo de IP. Este parece ser DNS multicast.

Nosso host do servidor forneceu isto (nosso endereço IP está mascarado com XX):

Jun 3 11:02:13 webserver kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT=
MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX
DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353
DPT=5353 LEN=53
Jun 3 11:02:23 webserver kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT=
MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX
DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353
DPT=5353 LEN=53
Jun 3 11:02:32 webserver kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT=
MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX
DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353
DPT=5353 LEN=53
Jun 3 11:02:35 webserver kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT=
MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX
DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353
DPT=5353 LEN=53

Verifiquei meu arquivo /var/log/auth.log e descobri que alguém da China (usando o ip-locator) estava tentando entrar no servidor usando ssh.

...
Jun  3 11:32:00 server2 sshd[28511]: Failed password for root from 202.100.108.25 port 39047 ssh2
Jun  3 11:32:08 server2 sshd[28514]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.100.108.25  user=root
Jun  3 11:32:09 server2 sshd[28514]: Failed password for root from 202.100.108.25 port 39756 ssh2
Jun  3 11:32:16 server2 sshd[28516]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.100.108.25  user=root
...

Bloqueei esse endereço IP usando este comando: sudo iptables -A INPUT -s 202.100.108.25 -j DROP

Porém, não tenho ideia sobre o multicasting UDP, o que está fazendo isso? quem está fazendo isso? e como posso pará-lo?

Ninguem sabe?

Responder1

Francamente, por que se preocupar? A maioria dos servidores recebe centenas de verificações e tentativas de login por dia. É simplesmente impossível bloquear todos eles manualmente.

Seu firewall parece estar fazendo seu trabalho. Afinal, está bloqueando o tráfego indesejado.

Certifique-se de não executar nenhum serviço desnecessário. Quanto menos houver disponível, menos haverá para invadir.

Para proteger o SSH: Certifique-se de configurar o SSH para negar login por root. Verifique se as senhas de todas as contas SSH são fortes.Negar hostsbloqueará IPs automaticamente após algumas tentativas de login malsucedidas (muito útil), mas certifique-se de colocar seu próprio intervalo de IP na lista de permissões ou você mesmo correrá o risco de ser bloqueado. Também é muito eficaz executar o SSH em uma porta diferente, já que a maioria dos ataques tenta apenas a porta 22.

Eu só agiria quando isso afetasse seus serviços ou largura de banda. Verifique quem é o proprietário do netblock de onde vem o tráfego e forneça uma reclamação clara e amigável ao endereço de abuso do proprietário. Se eles não responderem em um prazo razoável, vá ao ISP, etc.

Responder2

Não há muito que você possa fazer para impedir que terceiros falsifiquem seu endereço IP - é como spam com seu endereço De. Tudo o que pode ser feito já pode ser feito com o filewall do seu ISP na frente da sua máquina.

Você pode bloquear mais facilmente as tentativas de login ssh.Negar hosts(que eu uso em todos os meus servidores) ou similarfail2ban(não apenas SSH), ambos verificam o (s) arquivo (s) de log e, após 'muitas' tentativas de login, bloquearão o endereço IP (geralmente faço como o DenyHosts faz e adiciono endereços IP a /etc/hosts.deny)

Responder3

O UDP é fácil de falsificar o endereço de origem; os pacotes podem vir de qualquer lugar. Alguém pode estar falsificando um pacote para o seu endereço de transmissão. Filtre a porta 5353 de entrada e saída, o DNS multicast deve ser local. Filtre o endereço de transmissão no seu firewall. Filtre o tráfego de saída para o endereço de destino para garantir que não é você quem está enviando o tráfego.

Isso se parece muito com os ataques de amplificação executados no DNS no ano passado. Isso foi feito falsificando o endereço de origem. Se for esse o caso, você é o verdadeiro alvo.

informação relacionada