Intel AMT (เทคโนโลยีการจัดการที่ใช้งาน) ไม่รบกวนการทำงานของสแต็กโฮสต์ TCP / IP อย่างไร


15

ชุด dev ของ Intel ที่ฉันใช้อยู่นั้นมีคุณสมบัติการจัดการระยะไกล (ดูหน้าอูบุนตูที่นี่ด้วย ) ซึ่งอนุญาตให้รีบูตระยะไกลในกรณีที่ระบบปฏิบัติการหยุดทำงาน

มันมีความสามารถในการฟังพอร์ตจำนวนหนึ่ง (16992 และ 16993 เฉพาะ) บนที่อยู่ IP ที่ใช้ร่วมกับระบบปฏิบัติการ (ไม่ว่าจะโดยการสอดแนมคำขอ DHCP หรือออกเป็นของตัวเองฉันไม่แน่ใจ แต่วิธีใดก็ตามที่ใช้ที่อยู่ MAC ที่ใช้ร่วมกันในโหมดนี้)

ฉันใช้ที่อยู่ IP แยกต่างหากเพราะฉันกังวลเกี่ยวกับกรณีการใช้งานที่อาจเกิดขึ้น: AMT จะป้องกันเครือข่ายโฮสต์สแต็คจากการขัดแย้งกับมันได้อย่างไร

กล่าวอีกนัยหนึ่งตอนนี้ซอฟต์แวร์การจัดการของ Intel กำลังฟัง [อย่างน้อย] สองพอร์ต TCP, out-of-band และไม่มีความรู้ของระบบปฏิบัติการ สมมติว่าฉันเริ่มต้นการเชื่อมต่อ TCP กับรีโมตโฮสต์และโฮสต์สแต็กเลือก 16992 หรือ 16993 เป็นพอร์ตโลคัลเพื่อฟัง [สำหรับแพ็กเก็ตที่กลับมาที่กล่อง]

แพ็กเก็ตที่ส่งคืนจากโฮสต์ระยะไกลจะไม่ได้รับ "แบล็กโฮลด์" และไม่สามารถเข้าถึงระบบปฏิบัติการได้หรือไม่ หรือมีมาตรการป้องกันเช่นไดรเวอร์ Intel ในเคอร์เนล Linux รู้ว่า TCP ควรหลีกเลี่ยงพอร์ต 16992 (ดูเหมือนไม่น่าเป็นไปได้เนื่องจากนี่เป็นคุณสมบัติที่ไม่เชื่อเรื่องพระเจ้า) หรือบางทีอินเตอร์เฟสการจัดการสามารถส่งต่อทราฟฟิกที่ส่งไปยังพอร์ต 16992 ที่ไม่ได้อยู่ในเซสชั่นการจัดการที่เป็นที่รู้จัก

ไม่ว่าจะด้วยวิธีใดฉันลังเลที่จะใช้สิ่งนี้ในการโหลดบนเครือข่ายมากจนกว่าฉันจะเข้าใจวิธีการทำงานของมัน ฉันค้นหาเอกสารของ Intelและไม่พบสิ่งใดในนั้น

ฉันคิดว่าสิ่งนี้สามารถทดสอบได้โดยเริ่มต้นการเชื่อมต่อ TCP ประมาณ 30,000 ครั้งและตรวจสอบว่าการเชื่อมต่อใช้งานได้แม้ว่าพอร์ตจะทับซ้อนกันหรือไม่ แต่ฉันยังไม่มีโอกาสทำเช่นนั้น

(เชิงอรรถ: ฉันรู้ว่าคำถามนี้คล้ายกับว่าคอมพิวเตอร์ที่ใช้ Intel vPro รักษาการเชื่อมต่อ IP ได้อย่างไรแต่คำถามนั้นกล่าวถึงการเชื่อมต่อทั่วไปไม่ใช่การเชื่อมต่อกับพอร์ต TCP เฉพาะที่ซ้อนทับกับโฮสต์สแต็ก)


7
ฉันสังเกตเห็นว่ามีคนโหวตให้ปิดนี่เป็นนอกหัวข้อ ในกรณีนี้ฉันต้องการถามว่า: วิธีนี้ไม่เกี่ยวข้องกับผู้ดูแลเซิร์ฟเวอร์มืออาชีพ? หากคุณกำลังจะเปิดใช้งานเทคโนโลยีการจัดการนอกวงคุณไม่ต้องการที่จะรู้ว่ามันจะมีผลต่อการสื่อสารเครือข่ายของคุณหรือไม่?
mpontillo

ฉันเดาว่ามันจะดูที่ทราฟฟิกทั้งหมดบนพอร์ตเหล่านั้นและหากไม่ใช่สิ่งที่มันรับรู้มันจะส่งผ่านไปยังระบบปฏิบัติการ แต่นั่นเป็นการคาดเดาทั้งหมด
แกรนท์

1
คำถามที่ดี. ฉันคิดว่าการใช้คุณสมบัติดังกล่าวอย่างเหมาะสมจะต้องใช้สแต็ค IP ของตัวเองบนที่อยู่ MAC อื่นเพื่อหลีกเลี่ยงความขัดแย้งที่อาจเกิดขึ้นได้อย่างสมบูรณ์ คุณไม่จำเป็นต้องเชื่อมต่อ TCP 30000 เพื่อทดสอบความขัดแย้ง คุณสามารถลองทำสิ่งที่ชอบnc -p 16992 example.com 22และดูว่าเกิดอะไรขึ้นแทน
kasperd

@ kasperd ขอบคุณ; ฉันไม่รู้ว่าคุณสามารถทำได้อย่างง่ายดาย ฉันไปข้างหน้าและทำการทดสอบ ไม่ได้ดูดีสำหรับ AMT ...
mpontillo

คำตอบ:


8

หลังจากกำหนดค่า AMT เพื่อฟังที่อยู่ IP ที่ใช้ร่วมกันฉันได้ทำการทดสอบที่kasperdกล่าวไว้ในความคิดเห็นด้านบน (เทียบกับรีโมตโฮสต์ของฉันเองด้วยเซิร์ฟเวอร์ SSH ไม่ใช่example.comแน่นอน) นี่คือผลลัพธ์:

กรณีทดสอบเชิงบวก (ใช้พอร์ตที่AMT ไม่ได้ใช้):

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

กรณีทดสอบเชิงลบ (ใช้พอร์ตที่ AMT ใช้):

$ nc -p 16992 example.com 22
$

(หลังจากนั้นสองสามนาทีกรณีทดสอบเชิงลบหมดเวลาและกลับสู่พรอมต์ของเชลล์)

อย่างที่คุณเห็นแพ็คเก็ตที่กลับมาที่พอร์ต 16992 จะถูกทิ้งก่อนที่จะถึงสแต็ก TCP / IP ของโฮสต์

คำแนะนำ: หากระบบเครือข่ายที่เชื่อถือได้มีความสำคัญต่อคุณอย่าเปิดใช้งาน AMT บนที่อยู่ IP เดียวกันกับโฮสต์ TCP / IP ของคุณ!


2

มีเธรดที่ถกเถียงกันอยู่ที่ฟอรัม Intel การจับคู่ระหว่าง Host IP กับ Intel AMT Device IP พร้อมคำแนะนำนั้น

จะต้องกำหนดค่าที่อยู่ IP ที่แตกต่างกันสำหรับ AMT และโฮสต์เมื่อทำงานกับ IP คงที่

และคำอธิบาย:

เมื่อคุณกำหนดค่าเครื่อง vPro ด้วย IP แบบคงที่ AMT จะใช้ที่อยู่ mac ที่เรียกว่า mac ความสามารถในการจัดการซึ่งมาเล่นในโหมด IP แบบคงที่เท่านั้น ที่อยู่ mac สำหรับการจัดการแตกต่างจากที่อยู่ mac ที่โฮสต์แสดง

ฉันยืนยันว่าการใช้ DHCP กับ AMT และ Host ทำให้เกิดปัญหาการกำหนดเส้นทาง เช่น ping ทำให้เข้าใจผิด:

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

1

แพ็กเก็ตที่ส่งคืนจากโฮสต์ระยะไกลจะไม่ได้รับ "แบล็กโฮลด์" และไม่สามารถเข้าถึงระบบปฏิบัติการได้หรือไม่

แพ็คเก็ตทั้งหมดจากโฮสต์ระยะไกลด้วย "AMT- พอร์ต" ไม่เคยเข้าถึงระบบปฏิบัติการใด ๆ พวกเขาถูกดักจับโดย Intel ME / AMT โดยค่าเริ่มต้นคือพอร์ต 16992-16995, 5900 (AMT ver. 6+), 623, 664


1

สิ่งที่ควรสังเกตคือ AMT นั้นตั้งใจไว้ว่าเป็นเทคโนโลยี OOBM ของลูกค้าไม่ใช่เซิร์ฟเวอร์ ดังนั้นใช่อาจเป็นไปได้ว่าคอมพิวเตอร์ของคุณตัดสินใจใช้พอร์ต AMT แต่เฉพาะในกรณีที่คุณกำหนดค่าเฉพาะให้ทำเช่นนั้น ระบบปฏิบัติการส่วนใหญ่มาพร้อมกับพอร์ตชั่วคราวที่กำหนดไว้ล่วงหน้าในช่วง 49152 ถึง 65535 ตามที่ IANA กำหนดไว้, Linux distros บางรุ่นที่มี 32768 ถึง 61000 และ Windows เก่าที่มี 1,025–5000

ดังนั้นจากมุมมองของฉันการบันทึกเพื่อใช้ IP ที่ใช้ร่วมกันสำหรับ AMT เนื่องจากพอร์ตไม่ได้อยู่ในช่วงชั่วคราว (เว้นแต่คุณจะรู้ว่าคุณทำอะไรและเปลี่ยนการตั้งค่านี้โดยเฉพาะ) และไม่ควรใช้เป็นพอร์ตรับฟังโดยแอปพลิเคชันใด ๆ


-2

วิธีการแก้ปัญหาหนึ่งที่อาจจะมีการตั้งพอร์ตสำหรับสแต็คของ Windows TCP netshโดยใช้

โดยค่าเริ่มต้น Windows ใช้พอร์ต 49152 >> 65636 (หรืออะไรก็ตามที่สูงกว่า) ดังนั้นคุณจึงปลอดภัยมากที่จะใช้ AMT netshคุณสามารถตั้งค่าช่วงพอร์ตด้วย ตัวอย่างเช่นฉันมักจะใช้ประมาณ 1,000 พอร์ตสำหรับเครื่องปริมณฑล

นอกจากนี้ Intel จะตัดคำสั่ง AMT และส่งการรับส่งข้อมูลอื่น ๆ ทั้งหมดบนพอร์ตเหล่านั้น (16991-16995!) ไปยังระบบปฏิบัติการ (หากมีระบบปฏิบัติการอยู่) ดังนั้นหากคุณมีแอปพลิเคชั่นที่เปิดพอร์ตในช่วง AMT การรับส่งข้อมูลจะยังคงผ่าน OS ไปยังแอปพลิเคชันเพราะอย่างที่ฉันพูด Intel จะตัดคำสั่งการจัดการ AMT เท่านั้น แอปพลิเคชันของคุณไม่น่าจะส่งคำสั่ง AMT


4
คำตอบนี้ถือว่า (1) คุณกำลังใช้ Windows และ (2) คุณไม่ได้ใช้ซอฟต์แวร์ใด ๆ ที่อาจพยายามใช้พอร์ต AMT ที่ทับซ้อนกันด้วยเหตุผลอื่น ๆ (ตัวอย่างเช่นคุณอาจใช้แอปพลิเคชั่น VoIP ที่ใช้พอร์ต UDP แบบสุ่ม) นอกจากนี้ยังอ้างสิทธิ์ว่าคำสั่ง AMT ของ Intel "ลอกออก" ซึ่งแสดงให้เห็นอย่างชัดเจนว่าเป็นคำตอบที่ผิดของฉัน คุณสามารถให้ข้อมูลอ้างอิงเพื่อสนับสนุนข้อเรียกร้องของคุณได้หรือไม่? ฉันจะไม่แปลกใจถ้า Intel พิจารณาข้อบกพร่องนี้และแก้ไขมันในวันหนึ่ง แต่ในเวลาที่ฉันโพสต์คำตอบของฉันพวกเขาไม่ได้ชัดเจน
mpontillo
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.