Vou despejar muitos pensamentos e observações disjuntas em você, no caso de qualquer um deles ser capaz de estimular seu pensamento ou de outra pessoa.
-
O endereço MAC de destino multicast corresponde ao endereço IPv4 unicast do seu firewall.
É como se algum software pegasse o endereço IP do seu firewall, fingisse ser um endereço multicast e seguisse a fórmula para gerar um endereço MAC multicast Ethernet correspondente. Ou seja, foram necessários os últimos 23 bits do endereço IP e anexados ao final do 01: 00: 5e OUI.Eu tenho uma vaga lembrança de que pode haver protocolos que fazem isso (use um endereço multicast baseado em um endereço unicast), mas minhas vagas memórias me dizem que isso é algo mais provável de ser feito no IPv6 do que no IPv4. Vou ter que pesquisar um pouco mais depois.
Atualização: Eu estava pensando no uso do IPv6 Neighbor Discovery (equivalente a ARP do IPv6) de um "endereço multicast de nó solicitado". Não tenho certeza se isso é uma grande vantagem, porque não vejo por que alguém iria querer fazer isso com pings IPv4.
-
As cargas úteis desses pacotes de ping multicasts que você capturou não se parecem com cargas de ping típicas; eles têm dados significativos que podem ser uma pista.
As cargas normais de ping geralmente contêm todo valor de byte de 0x00 a 0xff em ordem, portanto, na versão ASCII do dump, você verá todos os caracteres em ordem. Esses pings capturados parecem conter dados significativos. Eu vejo alguns endereços IP definidos e alguns números de porta possíveis:
0000 f8 17 44 fa 62 8d 00 00 80 11 42 da 8f e2 27 66 ..D.b.....B...'fe0010 8f e2 4e 0d 00 89 00 89 00 3a 2d df 00 00 00 00 ..N......:-.....No deslocamento
0x000c, vejo8f e2 27 66, que é o endereço IP[your class B].39.102. Pesquisa de DNS reverso que revelajustin.[your school].edu. Esse nome de host é significativo para você? Rastrear o que é esse host e quais softwares e serviços estão sendo executados (e possivelmente se estão infectados ou infectados) podem fornecer pistas sobre o que é esse tráfego.Seguindo diretamente, no deslocamento
0x0010, vejo8f e2 4e 0d, que é o endereço IP[your class B].78.13, no qual não consigo obter um resultado de DNS reverso, mas talvez você possa descobrir de que é onde você está.Diretamente depois desses endereços IP, vejo o que eu considero serem dois números de porta,
00 89(== 137, NetBIOS Name Service) e00 89novamente.Esta poderia ser uma mensagem do netbios-ns que de alguma forma foi escrita como ICMP em vez de UDP? Parece improvável. Muitos campos nos lugares errados, parece-me.
Isso deveria ser uma mensagem inacessível de destino ICMP em resposta a uma mensagem netbios-ns, mas o cabeçalho ICMP foi gravado errado (como "solicitação de eco", em vez de "destino inacessível")? Parece improvável também. Muitos campos nos lugares errados novamente.
Isso é algum tipo de mensagem de malware, coordenando quais hosts estão infectados / pwned e quais atacar em seguida? A navalha de Hanlon parece desconsiderar isso, mas acho que é plausível.
Update: Pensando nisso, talvez a possibilidade mais provável seja de que algo esteja apenas reutilizando um buffer para preencher o corpo dessa solicitação de ping. Assim, o conteúdo pode ser um arenque vermelho.
-
Os TTLs desses quadros sempre são apenas 2, ou você vê rajadas de TTLs decrescentes?
Os mesmos TTLs sempre indicam que a tempestade de pacotes é uma espécie de loop de bridge de camada 2 pura. Decrementar TTLs indicaria que a camada 3, a camada IP, está se envolvendo; um desses códigos de gateway NAT do roteador sem fio pessoal do aluno pode estar cheio de bugs e encaminhar certos quadros que ele não tem encaminhamento de negócios, criando potencialmente um loop.Ou seja, estou sugerindo que pode haver dois problemas separados interagindo aqui. Um é o que está enviando esses pings estranhos com cargas úteis para um endereço MAC multicast, mas um endereço IPv4 unicast. O segundo problema poderia ser um dispositivo de buggy separado que vê os quadros que normalmente não veria e os encaminha de volta para a rede por um tempo extra, criando um loop.