Como o Intel AMT (Active Management Technology) não interfere na pilha de host TCP / IP?

O kit de desenvolvimento Intel que estou usando inclui um recurso de gerenciamento remoto (veja também a página de manual do Ubuntu aqui ) que permite reinicializações remotas no caso de travamento do sistema operacional.

Ele tem a capacidade de escutar algumas portas (16992 e 16993, para ser específico) em um endereço IP que ele compartilha com o sistema operacional. (espionando solicitações DHCP ou emitindo suas próprias; não tenho certeza, mas de qualquer forma, ele usa um endereço MAC compartilhado nesse modo)

Eu o tenho em execução em um endereço IP separado, porque estou preocupado com um possível caso de uso: como a AMT impede a pilha da rede host de entrar em conflito com ele?

Em outras palavras, o software de gerenciamento Intel agora está ouvindo [pelo menos] duas portas TCP, fora de banda e sem o conhecimento do sistema operacional. Digamos que eu inicie uma conexão TCP com um host remoto e a pilha do host escolha 16992 ou 16993 como a porta local para escutar [para pacotes voltando à caixa].

Os pacotes que retornam do host remoto ficam "trincados" e nunca chegam ao sistema operacional? Ou existe alguma medida preventiva, como um driver Intel no kernel Linux, sabendo que o TCP deve evitar a porta 16992? (parece improvável, pois esse é um recurso independente do sistema operacional.) Ou talvez a interface de gerenciamento possa encaminhar o tráfego enviado para a porta 16992 que não pertence a uma sessão de gerenciamento conhecida de volta à pilha do host?

De qualquer forma, estou relutante em usar isso para cargas intensivas em rede até entender como isso funciona. Eu procurei na documentação da Intel e também não consegui encontrar nada.

Suponho que isso possa ser testado iniciando cerca de 30.000 conexões TCP e verificando se a conectividade funciona mesmo que a porta se sobreponha. Mas ainda não tive a chance de fazer isso.

(Nota de rodapé: Percebo que esta pergunta é semelhante a Como um computador baseado em Intel vPro mantém a conectividade IP?, Mas que aborda a conectividade em geral, não a conectividade às portas TCP específicas que se sobrepõem à pilha do host.)

Após configurar o AMT para escutar um endereço IP compartilhado, executei o teste mencionado por kasperd nos comentários acima. (contra meu próprio host remoto com um servidor SSH, na verdade não example.com, é claro) Aqui está o resultado:

Caso de teste positivo (usando uma porta não usada pela AMT):

$ nc -p 16991 example.com 22
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
^C
$

Caso de teste negativo (usando uma porta usada pela AMT):

$ nc -p 16992 example.com 22
$

(Após alguns minutos, o caso de teste negativo expirou e retornou ao prompt do shell.)

Como você pode ver, os pacotes que retornam à porta 16992 foram descartados antes de atingirem a pilha TCP / IP do host.

Recomendação: se uma rede confiável é importante para você, não ative a AMT no mesmo endereço IP da pilha TCP / IP do host!

Há um tópico controverso no fórum da Intel Mapeando entre o IP do host e o IP do dispositivo Intel AMT com a sugestão de

é preciso configurar endereços IP diferentes para AMT e host ao operar com IPs estáticos.

e uma explicação:

Quando você configura a máquina vPro com IPs estáticos, a AMT usa o endereço mac chamado gerenciabilidade mac, que é reproduzido apenas no modo IP estático. O endereço mac de gerenciamento é diferente do endereço mac apresentado pelo host.

Confirmo que o uso do DHCP com AMT e Host leva a problemas de roteamento. por exemplo, ping enganoso:

64 bytes from 192.168.1.11: icmp_seq=18 ttl=64 time=0.559 ms
64 bytes from 192.168.1.11: icmp_seq=18 ttl=255 time=0.614 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=19 ttl=64 time=0.579 ms
64 bytes from 192.168.1.11: icmp_seq=19 ttl=255 time=0.630 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=20 ttl=64 time=0.553 ms
64 bytes from 192.168.1.11: icmp_seq=20 ttl=255 time=0.602 ms (DUP!)

Os pacotes que retornam do host remoto ficam "trincados" e nunca chegam ao sistema operacional?

Todos os pacotes do host remoto com "portas AMT" nunca atingem nenhum sistema operacional. Eles são interceptados pelo Intel ME / AMT. Por padrão, são as portas 16992-16995, 5900 (AMT ver. 6+), 623, 664.

O que deve ser observado é que a AMT é projetada como tecnologia OOBM de cliente e não como servidor um. Portanto, sim, pode acontecer que o seu computador decida usar as portas AMT, mas apenas no caso de você o ter configurado especificamente. A maioria dos sistemas operacionais vem com portas efêmeras pré-configuradas no intervalo de 49152 a 65535, conforme sugerido pela especificação da IANA, algumas distribuições de Linux com 32768 a 61000 e Windows antigo com 1025-5000.

Portanto, da minha perspectiva, é recomendável usar o IP compartilhado para AMT, pois suas portas não estão no intervalo efêmero (a menos que você saiba o que faz e altere essa configuração específica) e não deve ser usado como porta de escuta por nenhum aplicativo.

Uma solução pode ser definir as portas para a pilha TCP do Windows usando netsh.

Por padrão, o Windows usa a porta 49152 >> 65636 (ou qualquer que seja o limite superior). Portanto, você está muito seguro para usar o AMT. Você pode definir o intervalo de portas com netsh. Por exemplo, eu sempre uso cerca de 1000 portas para máquinas de perímetro.

Além disso, a Intel retira os comandos da AMT e passa todo o tráfego nessas portas (16991-16995 na verdade!) Para o sistema operacional (se houver um sistema operacional). Portanto, se você tiver um aplicativo que abriu uma porta no intervalo da AMT, o tráfego ainda passará pelo sistema operacional para o aplicativo, porque, como eu disse, a Intel retira apenas os comandos de gerenciamento da AMT. É improvável que seu aplicativo esteja enviando comandos AMT.