Intel AMT (Aktif Yönetim Teknolojisi) TCP / IP ana bilgisayar yığınına nasıl müdahale etmez?

Kullandığım Intel dev kitinde , işletim sisteminin askıda kalması durumunda uzaktan yeniden başlatmaya izin veren bir uzaktan yönetim özelliği (ayrıca buradaki Ubuntu man sayfasına bakın ) içerir.

İşletim sistemiyle paylaştığı bir IP adresinde bir avuç bağlantı noktasını (16992 ve 16993, spesifik olarak) dinleme özelliğine sahiptir. (DHCP isteklerini gizleyerek veya kendi isteğini vererek; Emin değilim, ancak her iki durumda da bu modda paylaşılan bir MAC adresi kullanır)

Potansiyel bir kullanım durumu hakkında endişelendiğim için ayrı bir IP adresinde çalışıyorum: AMT, ana ağ yığınının kendisiyle çakışmasını nasıl önler?

Başka bir deyişle, Intel yönetim yazılımı artık bant dışı ve işletim sisteminin bilgisi olmadan en az iki TCP bağlantı noktasını dinliyor. Uzak bir ana bilgisayara TCP bağlantısı başlattığımı ve ana makine yığınının 16992 veya 16993'ü yerel bağlantı noktası olarak seçerek [kutuya geri gelen paketler için] seçtiğini varsayalım.

Uzak ana bilgisayardan dönen paketler "kara delikli" olmaz ve işletim sistemine asla ulaşmaz mı?Yoksa, Linux çekirdeğindeki bir Intel sürücüsü gibi TCP'nin 16992 numaralı bağlantı noktasından kaçınması gerektiğini bilen bir önleyici tedbir var mı? (Bu işletim sistemi agnostik bir özellik olduğu için olası görünmüyor.) Ya da belki de yönetim arabirimi bilinen bir yönetim oturumuna ait olmayan 16992 numaralı bağlantı noktasına gönderilen trafiği ana bilgisayar yığınına geri yönlendirebilir?

Her iki durumda da, bunun nasıl çalıştığını anlayana kadar ağ yoğun yükler için kullanmakta isteksizim. Intel belgelerini aradım ve orada da hiçbir şey bulamadım.

Sanırım bu yaklaşık 30.000 TCP bağlantısı başlatılarak ve bağlantı noktası çakışsa bile bağlantının çalışıp çalışmadığını kontrol ederek test edilebilir. Ama henüz bunu yapma şansım olmadı.

(Dipnot: Bu soru benzer farkında ? Intel vPro tabanlı bilgisayar IP bağlantısı korumak nasıldır . Belirli TCP bağlantı noktaları için genel değil, bağlantı içinde, ama bu sorular adresleri bağlantı konak yığını ile örtüşme olduğunu)

AMT'yi paylaşılan bir IP adresini dinleyecek şekilde yapılandırdıktan sonra, kasperd tarafından belirtilen testi yukarıdaki yorumlarda yaptım . (bir SSH sunucusuyla kendi uzak ana makineme karşı, aslında değil example.com, elbette) İşte sonuç:

(Bir bağlantı noktasını kullanarak Pozitif test durumu değil AMT tarafından kullanılır):

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

Negatif test durumu (AMT tarafından kullanılan bir port kullanılarak):

$ nc -p 16992 example.com 22
$

(Birkaç dakika sonra negatif test durumu zaman aşımına uğradı ve kabuk istemine geri döndü.)

Gördüğünüz gibi, 16992 numaralı bağlantı noktasına geri dönen paketler, ana bilgisayarın TCP / IP yığınına ulaşmadan önce bırakıldı.

Tavsiye: Güvenilir ağ iletişimi sizin için önemliyse, ana TCP / IP yığınınızla aynı IP adresinde AMT'yi etkinleştirmeyin!

Intel forumunda Host IP ve Intel AMT Device IP arasında Eşleme ile şu tartışmaya açık bir konu vardır:

statik IP'lerle çalışırken AMT ve ana bilgisayar için farklı IP adresleri yapılandırılmalıdır.

ve bir açıklama:

VPro makinesini statik IP'lerle yapılandırdığınızda AMT, yalnızca statik IP modunda çalmaya gelen yönetilebilirlik mac adlı mac adresini kullanır. Yönetilebilirlik mac adresi, ana bilgisayar tarafından sunulan mac adresinden farklı.

Hem AMT hem de Host ile DHCP kullanmanın yönlendirme sorunlarına yol açtığını onaylıyorum. örneğin ping yanlış yönlendirmesi:

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

Uzak ana bilgisayardan dönen paketler "kara delikli" olmaz ve işletim sistemine asla ulaşmaz mı?

"AMT bağlantı noktaları" olan uzak ana bilgisayardaki tüm paketler hiçbir işletim sistemine ulaşmaz. Intel ME / AMT tarafından durdurulurlar. Varsayılan olarak bunlar 16992-16995, 5900 (AMT ver. 6+), 623, 664 bağlantı noktalarıdır.

Dikkat edilmesi gereken, AMT'nin sunucu değil istemci OOBM teknolojisi olarak tasarlanmasıdır. Bu nedenle, evet, bilgisayarınızın yalnızca AMT bağlantı noktalarını kullanmaya karar vermesi, ancak bunu özellikle bunu yapılandırmanız durumunda ortaya çıkabilir. İşletim sistemlerinin çoğu, IANA belirtimi tarafından önerilen 49152 ila 65535 aralığında önceden yapılandırılmış geçici portlar, 32768 ila 61000 ile bazı Linux dağıtımları ve 1025-5000 ile eski Windows ile birlikte gelir.

Bu yüzden benim bakış açımdan, portları geçici aralıkta olmadığından (ne yaptığınızı bilmediğiniz ve bu ayarı değiştirmedikçe) AMT için paylaşılan IP kullanmak kaydedildi ve herhangi bir uygulama tarafından dinleme portu olarak kullanılmamalıdır.

Çözümlerden biri, kullanarak Windows TCP yığını için bağlantı noktalarını ayarlamak olabilir netsh.

Windows varsayılan olarak 49152 >> 65636 numaralı bağlantı noktasını (veya üst sınır her ne ise) kullanır. Böylece AMT'yi kullanmak çok güvenlidir. Port aralığını ile ayarlayabilirsiniz netsh. Örneğin, çevre makineleri için her zaman yaklaşık 1000 bağlantı noktası kullanıyorum.

Ayrıca Intel, AMT komutlarını keser ve bu bağlantı noktalarındaki diğer tüm trafiği (aslında 16991-16995!) İşletim sistemine (Bir işletim sistemi varsa) geçirir. AMT aralığında bir bağlantı noktası açan bir uygulamanız varsa, trafik hala işletim sisteminden uygulamaya geçecektir, çünkü söylediğim gibi, Intel yalnızca AMT yönetim komutlarını kaldırır. Uygulamanızın AMT komutları göndermesi pek olası değildir.