it-swarm-pt.tech

Muitas conexões em SYN_RECV, não uma inundação de SYN, é algum ataque de reflexão?

Há pelo menos alguns meses, emitindo um netstat -t _ em nosso servidor web, que possui TCP portas 22, 80 e 443 expostas à Internet, geralmente revela dezenas de conexões em SYN_RECV status:

$ netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 128.1XX.XX.X:22         142.93.230.186:50603    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.89.196:36332    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         167.71.79.217:40430     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.235.90:36742     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.128.243.146:35451   SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.253.100:43994    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         188.166.91.16:42461     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         178.62.242.138:33381    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         142.93.235.90:57784     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        165.22.198.207:36181    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         68.183.11.83:63899      SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.93.253:41816    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.85.129:48833    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.62.207.43:59050     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         128.199.55.152:55891    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.205.23:52978     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         165.22.198.135:36668    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         165.22.203.65:65273     SYN_RECV
tcp        0      0 128.1XX.XX.X:80         68.183.15.91:46722      SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.4.136:55194      SYN_RECV
tcp        0      0 128.1XX.XX.X:80         142.93.228.103:60458    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.253.100:52599    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.89.56:46283     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.250.235:43637    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.7.181:37556      SYN_RECV
tcp        0      0 128.1XX.XX.X:80         104.248.89.200:64128    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.139.213:38821    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        104.248.92.161:63004    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         68.183.15.91:46210      SYN_RECV
tcp        0      0 128.1XX.XX.X:443        104.248.92.138:39651    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         178.62.241.74:43953     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         142.93.224.74:42996     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        165.22.196.167:38597    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.128.254.3:36751     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         104.248.93.27:32904     SYN_RECV
tcp        0      0 128.1XX.XX.X:443        167.71.78.255:60529     SYN_RECV
tcp        0      0 128.1XX.XX.X:22         165.22.201.209:45397    SYN_RECV
tcp        0      0 128.1XX.XX.X:80         178.62.207.205:39291    SYN_RECV
tcp        0      0 128.1XX.XX.X:22         165.22.198.207:61967    SYN_RECV
tcp        0      0 128.1XX.XX.X:443        178.62.234.81:39309     SYN_RECV
[---cut---]

O primeiro que tive foi que foi um ataque de inundação de SYN, no entanto (a) o servidor parece não sofrer nada com o "ataque", (b) a taxa de SYN é bastante baixa, com pouco mais de 2 pacotes/s., e (c) Geralmente, observo os pacotes SYN provenientes do mesmo bloco de rede, tanto no servidor (servidor Web do laboratório da Universidade hospedado em nossa rede da Universidade) quanto em um servidor doméstico que esteja em um bloco de rede completamente diferente (conectado por meio de um conexão de fibra residencial regular com um IP dinâmico público) e (d) o kernel do Linux nunca cumpre uma possível inundação SYN (os cookies TCP SYN estão ativados).

O que eu estou querendo saber é qual é o objetivo real desses pacotes SYN. Eles não parecem ter problemas de rede (firewalls mal configurados ou problemas semelhantes). Eles quase sempre vêm dos espaços IP dos datacenters, que mudam de um dia para outro (pode ser Amazon EC2, Serverius, DigitalOcean etc.). Às vezes, é apenas um para alguns IPs, às vezes há dezenas. Às vezes o IP responde se eu fizer ping, às vezes não. Embora eu tenha testado apenas esporadicamente, quase nunca encontrei um servidor da Web acessível nesses IPs na porta 80 ou 443 (nunca tentei varrer mais portas que essa), mas veja abaixo a primeira que encontrei hoje. Eles vêm em rajadas por talvez uma hora, depois desaparecem; Ainda não tentei detectá-los automaticamente para ter uma plotagem horária para ver se há algum "cronograma".

Eu também estava pensando que isso poderia ser algum tipo de ataque de amplificação usando endereços de origem IP forjados (cada pacote SYN recebido acabará por produzir 5 pacotes SYN ACK antes do tempo limite do servidor), mas não faz muito sentido (a) a o servidor normal responderia rapidamente com um pacote RST, interrompendo assim mais SYN ACKs; e (b) como mencionado, esses servidores não parecem hospedar sites públicos que possam valer um ataque de amplificação de DDoS.

Os endereços de origem (possivelmente falsificados?) Geralmente não possuem registro PTR ou genérico, mas em alguns casos eles fornecem nomes de host reais (por exemplo, na lista mencionada acima, 142.93.230.186 fornece parimatchklub.com, aparentemente um site de apostas esportivas na Rússia) . O site demorou muito para ser acessado; talvez seja, de fato, alguma forma de ataque de reflexão contra os aparentes endereços de origem?

Alguém já observou isso? Alguma explicação sobre o objetivo real desses pacotes?

3
Ale

Parece a pegada deixada para trás por algo como a descoberta de host do nmap. Nmap é uma ferramenta de descoberta de host e um scanner de porta.

a fase de descoberta de host do nmap pode enviar pacotes syn às portas dos servidores da web para detectar servidores que bloqueiam o ping icmp. Alguém pode estar usando o nmap para descobrir hosts ao vivo no seu intervalo de ip (ou mesmo 0.0.0.0/0) e pode não ter nenhum interesse em seu Host.

Provavelmente, você poderia detectar isso detectando pacotes SYN e ICMP e comparando-os com as varreduras descritas em: https://nmap.org/book/man-Host-discovery.html

Você também pode ver se eles estão acompanhando uma verificação de porta mais ampla. Eles podem estar procurando hosts com uma porta específica com uma vulnerabilidade conhecida por eles.

2
Fenster34

Alguma explicação sobre o objetivo real desses pacotes?

A saída de netstat mostra que seu servidor não conseguiu ESTABLISH conexão, que pode ser devido a problemas de conectividade intermediária ou pontos de extremidade de origem IP falsificados (forjados) - respostas enviadas simplesmente não atingiram nenhum iniciador (s).

Se escolhermos "versão falsificada", sugiro tentar rastrear essas conexões pelo menos no canal em que o servidor as está obtendo. Pode não ser a montante, mas a sua LAN (seja uma rede LAN real ou VMs, etc.).

Então, se estiver a montante, você poderá encaminhar suas preocupações para as deles NOC (a partir do suporte, provavelmente é claro). Se é o seu lado, bem - esclareça.

1
poige

Pode ser a evasão HTTP para ignorar a segurança do servidor. Os endereços IP são possíveis hosts maliciosos, porque são provedores de hospedagem econômica, conhecidos pelo Host Malware e participam da atividade do Botnet.

1
Olaf V