เป็นไปได้หรือไม่ที่จะสร้างไฟร์วอลล์ที่อนุญาตทราฟฟิกเว็บเซิร์ฟเวอร์ที่ถูกต้องตามกฎหมายบนพอร์ต 443 และไม่ใช่บริการอื่น ๆ

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

อย่างไรก็ตามตอนนี้ฉันอยู่ในเครือข่ายที่มีไฟร์วอลล์ซึ่งฉันไม่เคยเห็นมาก่อนและฉันก็ไม่รู้ด้วยซ้ำว่ามันเป็นไปได้

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

สิ่งนี้เป็นไปได้อย่างไร มีไฟร์วอลล์ที่มีความซับซ้อนอย่างยิ่งที่สามารถวิเคราะห์ทราฟฟิกที่เข้ารหัสเพื่อตรวจสอบว่าเป็นทราฟฟิก https ที่ถูกต้องหรือไม่ อย่างไร?

networking ssh firewall

— Petr
แหล่งที่มา

มันเรียกว่า SPI อุปกรณ์ปลายทางที่สูงกว่าสามารถทำการตรวจสอบขั้นสูงขึ้นและยุติการเชื่อมต่อที่ไม่ต้องการ

— Linef4ult

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

— Ramhound

คุณสามารถใช้เช่น Obfsproxy เพื่อทำให้ทราฟฟิก SSH เป็นทราฟฟิก HTTP (S) ที่ไม่เป็นอันตราย

— Michael

ใช่แล้วพวกเขาไม่ต้องการเวทย์มนตร์ใด ๆ ที่นี่เพียงจับคู่เล็กน้อยบนเนื้อหาแพ็คเก็ต TCP แม้ว่า SSH และ TLS (SSL) เข้ารหัสเพย์โหลดของตนแต่ส่วนหัวของโพรโทคอลเองก็ยังสามารถแยกแยะได้และแตกต่างจากกันมาก ตัวอย่างเช่นการเชื่อมต่อ SSHv2 เริ่มต้นด้วยการส่งลูกค้าSSH-2.0-(client name and version)เสมอ ในทำนองเดียวกันแม้ว่าไฟร์วอลล์ของคุณไม่สามารถจริงๆรู้ว่าการเชื่อมต่อ TLS ดำเนิน HTTP ภายในก็สามารถรับรู้TLS ตัวเอง

การตรวจสอบเลเยอร์เหนือ TCP ดังกล่าวโดยทั่วไปจะอยู่ภายใต้ "การตรวจสอบแพ็คเก็ตลึก" ซึ่งเป็นคุณสมบัติทั่วไป

วิธีหนึ่งที่ชัดเจนในการหลีกเลี่ยงสิ่งนี้คือการทำ SSH ใน TLS ตัวอย่างเช่นการใช้ stunnel, haproxy หรือ sniproxy (นอกเหนือจากอุโมงค์ธรรมดาที่พอร์ต 443 ทุ่มเทให้กับ SSH-over-TLS พวกเขายังสามารถเพิ่มโปรโตคอล SSH / HTTP / อื่น ๆ ผ่านพอร์ตเดียวกันตาม SNI และ ALPN)

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

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

— grawity
แหล่งที่มา

ดังนั้น SSH จึงมีความปลอดภัยระดับแอปพลิเคชันของตัวเองแทนที่จะเป็นเพียงโปรโตคอลอื่นผ่าน TLS (โดยค่าเริ่มต้นซึ่งไม่ได้ใช้)

— Medinoc

@Medinoc: ใช่มันดำเนินคุณสมบัติคล้ายกัน (ใน SSHv2 "ขนส่ง" และ "การตรวจสอบ" ชั้น ) และไม่จำเป็นต้อง TLS สำหรับการอะไร

— grawity

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

— Petr

POST / HTTP / 1.0 base64garbage HTTP / 200 200 base64garbage ตกลงทำให้โปรโตคอลการขนส่ง

— โจชัว

@Petr ขยายความคิดเห็นของ grawity ถ้ามันเป็นเจ้าของคอมพิวเตอร์ที่ใช้ certs อาจถูกติดตั้งก่อนที่จะส่งให้คุณ และไฟร์วอลล์ MITM จะได้รับการกำหนดค่าดังนั้นหากคุณไม่ได้ใช้ใบรับรองของพวกเขาจะไม่อนุญาตให้มีการรับส่งข้อมูล https ดังนั้นตัวเลือกของคุณจะปฏิบัติตามนโยบายหรือไม่มี https OTOH ในกรณีนั้นการตรวจสอบใบรับรองอาจจะพูดอะไรบางอย่างเช่น "ตรวจสอบโดยชื่อผู้ประกอบการ" และสิ่งที่คล้ายกันในชื่อ CA ถ้าคุณเจาะลึก เช่นบนคอมพิวเตอร์ที่ทำงานของฉันมันคือ bluecoat.companyname.com (โดยที่ bluecoat เป็นแบรนด์ของไฟร์วอลล์ที่ใช้งานอยู่)

— Dan Neely