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

Question

O kit de desenvolvimento da Intel que tenho usado inclui um recurso de gerenciamento remoto (veja também a página do manual do Ubuntu aqui ) que permite reinicializações remotas caso o sistema operacional trava.

Ele tem a capacidade de ouvir um punhado de portas (16992 e 16993, para ser específico) em um endereço IP que compartilha com o sistema operacional. (ou por snooping pedidos DHCP ou em emitir o seu próprio, não tenho certeza, mas de qualquer forma ele usa um endereço MAC compartilhado neste modo)

Estou executando em um endereço IP separado, porque estou preocupado com um possível caso de uso: como a AMT impede que a pilha da rede host entre em conflito com ela?

Em outras palavras, o software de gerenciamento da 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 escolhe 16992 ou 16993 como a porta local para ouvir [os pacotes voltando para a caixa].

Os pacotes que retornam do host remoto não recebem "blackholed" e nunca alcançam o sistema operacional? Ou há alguma medida preventiva, como um driver Intel no kernel Linux, sabendo que o TCP deve evitar 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 maneira, estou relutante em usar isso para cargas com uso intensivo de rede até entender como isso funciona. Eu pesquisei na documentação da Intel e também não consegui encontrar nada.

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

(Nota de rodapé: percebo que essa pergunta é semelhante a Como um computador baseado em Intel vPro mantém a conectividade IP? , mas essas questões abordam a conectividade em geral, não a conectividade com as portas TCP específicas que se sobrepõem à pilha do host.

    

Answer 1

Depois de configurar o AMT para ouvir em um endereço IP compartilhado, executei o teste mencionado por kasperd nos comentários acima. (contra o meu próprio host remoto com um servidor SSH, não na verdade 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).

Então, como você pode ver, os pacotes voltando para a porta 16992 foram descartados antes de chegarem à pilha TCP / IP do host.

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

    

Answer 2

Won't packets returning from the remote host get "blackholed" and never reach the OS?

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

    

Answer 3

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

Portanto, do meu ponto de vista, é melhor usar o IP compartilhado para AMT, pois suas portas não estão no intervalo efêmero (a menos que você saiba o que fazer e altere essa configuração específica) e não devem ser usadas como porta de escuta por nenhum aplicativo.

    

Answer 4

Existe um tópico controverso no fórum da Intel Mapeamento entre o IP do host e IP do dispositivo Intel AMT com a sugestão de que

one must configure different IP addresses for AMT and host when operating with static IPs.

e uma explicação:

When you configure the vPro machine with static IPs, AMT will use the mac address called manageability mac which comes to play only in static IP mode. Manageability mac address is different from the mac address presented by the host.

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

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!)

    

Answer 5

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 seja qual for o limite superior) Então você está muito seguro de usar 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 AMT e transmite todos os outros tráfegos nessas portas (16991-16995, na verdade!) para o sistema operacional (se houver um sistema operacional). Portanto, se você tivesse um aplicativo que abrisse uma porta na faixa AMT, o tráfego ainda passaria pelo sistema operacional para o aplicativo, porque, como eu disse, a Intel só tira os comandos de gerenciamento da AMT. É improvável que seu aplicativo esteja enviando comandos AMT.