Wie stört Intel AMT (Active Management Technology) den TCP / IP-Host-Stack nicht?

Das von mir verwendete Intel-Entwicklungskit enthält eine Remote-Verwaltungsfunktion (siehe auch die Ubuntu-Manpage hier ), die einen Remote-Neustart ermöglicht, falls das Betriebssystem hängen bleibt.

Es kann eine Handvoll Ports (16992 und 16993, um genau zu sein) auf eine IP-Adresse lauschen, die es mit dem Betriebssystem teilt. (Entweder durch Abhören von DHCP-Anfragen oder durch Ausgabe einer eigenen; ich bin mir nicht sicher, aber in beiden Fällen wird in diesem Modus eine gemeinsam genutzte MAC-Adresse verwendet.)

Ich habe es auf einer separaten IP-Adresse ausgeführt, weil ich mir Sorgen über einen möglichen Anwendungsfall mache : Wie verhindert AMT, dass der Host-Netzwerkstapel mit ihm in Konflikt gerät?

Mit anderen Worten, die Intel-Verwaltungssoftware überwacht [mindestens] zwei TCP-Ports außerhalb des Bandes und ohne das Wissen des Betriebssystems. Nehmen wir an, ich initiiere eine TCP-Verbindung zu einem Remote-Host und der Host-Stack wählt 16992 oder 16993 als lokalen Port zum Abhören [für Pakete, die zurück zur Box kommen].

Werden Pakete, die vom Remote-Host zurückkehren, nicht "schwarz gelocht" und erreichen nie das Betriebssystem? Oder gibt es eine vorbeugende Maßnahme wie einen Intel-Treiber im Linux-Kernel, der weiß, dass TCP Port 16992 vermeiden sollte? (Scheint unwahrscheinlich, da dies eine betriebssystemunabhängige Funktion ist.) Oder kann die Verwaltungsschnittstelle den an Port 16992 gesendeten Datenverkehr, der nicht zu einer bekannten Verwaltungssitzung gehört, zurück an den Hoststapel leiten?

In jedem Fall zögere ich, dies für netzwerkintensive Lasten zu verwenden, bis ich verstehe, wie dies funktioniert. Ich habe die Intel-Dokumentation durchsucht und dort auch nichts gefunden.

Ich nehme an, dies könnte getestet werden, indem etwa 30.000 TCP-Verbindungen hergestellt und überprüft werden, ob die Konnektivität auch dann funktioniert, wenn sich der Port überschneidet. Aber ich hatte noch keine Chance dazu.

(Fußnote: Mir ist klar, dass diese Frage der Frage " Wie wird die IP-Konnektivität auf einem Intel vPro-basierten Computer aufrechterhalten?" Ähnelt. In dieser Frage geht es jedoch um die Konnektivität im Allgemeinen und nicht um die Konnektivität zu den spezifischen TCP-Ports, die sich mit dem Host-Stack überschneiden.)

Nach der Konfiguration von AMT zum Abhören einer freigegebenen IP-Adresse habe ich den von kasperd in den obigen Kommentaren erwähnten Test ausgeführt . (gegen meinen eigenen Remote-Host mit einem SSH-Server, example.comnatürlich nicht wirklich ) Hier ist das Ergebnis:

Positiver Testfall (über einen von AMT nicht verwendeten Port ):

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

Negativer Testfall (über einen von AMT verwendeten Port):

$ nc -p 16992 example.com 22
$

(Nach einigen Minuten lief der negative Testfall ab und kehrte zur Shell-Eingabeaufforderung zurück.)

Wie Sie sehen, wurden die an Port 16992 zurückkommenden Pakete verworfen, bevor sie den TCP / IP-Stapel des Hosts erreichten.

Empfehlung: Wenn Ihnen ein zuverlässiges Netzwerk wichtig ist, aktivieren Sie AMT nicht auf derselben IP-Adresse wie Ihr Host-TCP / IP-Stack!

Es gibt einen kontroversen Thread im Intel Forum Mapping zwischen der Host IP und der Intel AMT Device IP mit dem Vorschlag, dass

Wenn Sie mit statischen IP-Adressen arbeiten, müssen Sie unterschiedliche IP-Adressen für AMT und Host konfigurieren.

und eine Erklärung:

Wenn Sie den vPro-Computer mit statischen IP-Adressen konfigurieren, verwendet AMT die Mac-Adresse "Verwaltbarkeits-Mac", die nur im statischen IP-Modus wiedergegeben wird. Verwaltbarkeit Die MAC-Adresse unterscheidet sich von der vom Host angegebenen MAC-Adresse.

Ich bestätige, dass die Verwendung von DHCP mit AMT und Host zu Routingproblemen führt. zB Ping irreführen:

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

Werden Pakete, die vom Remote-Host zurückkehren, nicht "schwarz gelocht" und erreichen nie das Betriebssystem?

Alle Pakete vom entfernten Host mit "AMT-Ports" erreichen niemals ein Betriebssystem. Sie werden von Intel ME / AMT abgefangen. Standardmäßig sind dies die Ports 16992-16995, 5900 (AMT Ver. 6+), 623, 664.

Zu beachten ist, dass AMT als Client-OOBM-Technologie gedacht ist und nicht als Server. Aus diesem Grund kann es vorkommen, dass sich Ihr Computer für die Verwendung von AMT-Ports entscheidet, dies jedoch nur, wenn Sie ihn speziell dafür konfiguriert haben. Die meisten Betriebssysteme verfügen über vorkonfigurierte ephemere Ports im Bereich von 49152 bis 65535, wie in der IANA-Spezifikation angegeben, einige Linux-Distributionen mit 32768 bis 61000 und alte Windows-Versionen mit 1025 bis 5000.

Aus meiner Sicht ist es also sicher, Shared IP für AMT zu verwenden, da sich die Ports nicht im kurzlebigen Bereich befinden (es sei denn, Sie wissen, was Sie tun, und ändern diese bestimmte Einstellung) und von keiner Anwendung als Überwachungsport verwendet werden sollten.

Eine Lösung könnte darin bestehen, die Ports für den Windows-TCP-Stack mithilfe von festzulegen netsh .

Standardmäßig verwendet Windows Port 49152 >> 65636 (oder was auch immer das obere Limit ist). Sie können AMT also sehr sicher verwenden. Mit können Sie den Portbereich einstellen netsh. Zum Beispiel verwende ich immer ungefähr 1000 Ports für Perimeter-Maschinen.

Außerdem entfernt Intel die AMT-Befehle und leitet den gesamten anderen Datenverkehr an diesen Ports (tatsächlich 16991-16995!) An das Betriebssystem weiter (sofern ein Betriebssystem vorhanden ist). Wenn Sie also eine Anwendung haben, die einen Port im AMT-Bereich geöffnet hat, wird der Datenverkehr weiterhin über das Betriebssystem an die Anwendung weitergeleitet, da Intel, wie gesagt, nur die AMT-Verwaltungsbefehle entfernt. Es ist unwahrscheinlich, dass Ihre Anwendung AMT-Befehle sendet.