ตัวติดตั้งพอร์ทัล VPN: แพ็กเกจ โปรไฟล์ หรือสร้างใหม่?

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

แม่กุญแจของเบราว์เซอร์ครอบ การรับส่ง ไม่ใช่อาร์ติแฟกต์.

ปลายทางการดาวน์โหลดคืนอะไรจริง ๆ

พอร์ทัลส่วนใหญ่ส่งคำขอดาวน์โหลดให้ตัวจัดการเล็ก ๆ ซึ่งจะสตรีมไฟล์ที่จัดเก็บไว้หรือประกอบไฟล์ขึ้นในทันที แล้วตั้งชื่อไฟล์และชนิดเนื้อหาก่อนการตอบกลับจะออกไป สิ่งที่มาถึงคือคอนเทนเนอร์ ได้แก่ MSI, PKG, DEB หรือ RPM หรือตัวห่อที่แตกตัวเองได้รอบหนึ่งในนั้น ข้างในคือไบนารีของไคลเอนต์ และไม่มีสิ่งใดในชื่อไฟล์ที่บอกได้อย่างน่าเชื่อถือว่าไบนารีนั้นมาจากผู้จำหน่ายหรือจากไปป์ไลน์การสร้างภายใน ไฟล์ที่ชื่อ client-setup.exe บันทึกการตัดสินใจเรื่องชื่อ ไม่ใช่ข้อเท็จจริงเรื่องที่มา

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

โปรไฟล์เข้าสู่ไคลเอนต์ตรงไหน

การตั้งค่าที่กรอกไว้ล่วงหน้ามักเดินทางเป็นไฟล์แยกที่ตัวติดตั้งคัดลอกไปยังเส้นทางต่อผู้ใช้หรือต่อเครื่อง ได้แก่โปรไฟล์ JSON หรือ XML บน Windows โปรไฟล์การกำหนดค่าบน macOS และชิ้นส่วนใต้ /etc บน Linux ค่าในไฟล์นั้น ได้แก่ชื่อโฮสต์ของเกตเวย์ สมอยึดความเชื่อถือ และบางครั้งวัสดุการลงทะเบียน จะกลายเป็นค่าเริ่มต้นของไคลเอนต์เมื่อเริ่มครั้งแรก นี่คือเหตุผลที่การดาวน์โหลดครั้งเดียวสามารถพาทั้งความลับและโค้ดไปด้วย

ถามว่าเส้นทางการอัปเกรดทำอะไรกับโปรไฟล์ ขึ้นอยู่กับการแพ็กเกจ มันอาจอยู่รอดจากการอัปเดตไคลเอนต์ ถูกเขียนทับโดยการอัปเดต หรือล้มเหลวในการตรวจสอบสคีมาในเวอร์ชันใหม่

สิ่งที่ห่วงโซ่ลายเซ็นไม่ได้พิสูจน์

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

การพิสูจน์ตัวตนของพอร์ทัลตอบคำถามข้อที่สาม คือเซสชันไปถึงเซิร์ฟเวอร์ที่ตั้งใจหรือไม่ การตรวจสอบสามแบบที่ต่างกัน และโหมดความล้มเหลวสามแบบที่ต่างกัน

ตรวจสอบอาร์ติแฟกต์ก่อนที่ใครจะรันมัน

วางไฟล์บนเครื่องที่แยกออกมาและอ่านเมทาดาทาก่อนดำเนินการใด ๆ คำสั่งเหล่านี้ตอบคำถามเรื่องผู้เผยแพร่บนสามแพลตฟอร์มหลัก

# Windows PowerShell
Get-AuthenticodeSignature .\client-setup.exe | Format-List Status, SignerCertificate, TimeStamperCertificate

# macOS
pkgutil --check-signature ./Client.pkg
codesign -dv --verbose=4 /Applications/Client.app

# Debian/Ubuntu
dpkg-deb -I ./client_amd64.deb
sha256sum ./client_amd64.deb

อ่านชื่อเรื่องของผู้ลงนาม ไม่ใช่แค่คำสถานะ การที่หน่วยงานออกใบรับรองภายในลงนามในบิลด์ภายในเป็นเรื่องคาดหมาย แต่ใบรับรองเดียวกันบนแพ็กเกจที่อ้างว่าเป็นรุ่นของผู้จำหน่ายไม่ใช่

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

การกำหนดความเป็นเจ้าของก่อนการนำไปใช้

คำถามสุดท้ายไม่มีคำสั่งรองรับ ค้นหาว่าใครอัปเดตอาร์ติแฟกต์เมื่อผู้จำหน่ายส่งไคลเอนต์ใหม่ ใครถือกุญแจลงนามสำหรับบิลด์ภายใน และโปรไฟล์ถูกหมุนเวียนอย่างไรเมื่อปลายทางย้าย เขียนชื่อเหล่านั้นไว้ข้างลิงก์ดาวน์โหลด

หากไม่มีใครเป็นเจ้าของคำตอบนั้น การดาวน์โหลดก็คือช่องทางกระจายที่ไม่สัญญาการบำรุงรักษา และนั่นคือสิ่งที่ควรรายงาน