stunnel vpn traffic และตรวจสอบให้แน่ใจว่าดูเหมือนว่าปริมาณข้อมูล SSL บนพอร์ต 443


13

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

การกำหนดค่าของฉันเป็นดังนี้:

STUNNEL บนแล็ปท็อป:

[openvpn]
# Set sTunnel to be in client mode (defaults to server)
client = yes  
# Port to locally connect to
accept = 127.0.0.1:1194  
# Remote server for sTunnel to connect to
connect = REMOTE_SERVER_IP:443

OPENVPN กำหนดค่าบนแล็ปท็อป:

client
dev tun
proto tcp
remote 127.0.0.1 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun

การกำหนดค่าแบบ STUNNEL บนเซิร์ฟเวอร์:

sslVersion = all
options = NO_SSLv2
;chroot = /var/lib/stunnel4/
; PID is created inside the chroot jail
pid = /stunnel4.pid
; Debugging stuff (may useful for troubleshooting)
 debug = 7
 output = /var/log/stunnel4/stunnel4.log
setuid = root
setgid = root
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
compression = zlib
[openvpn]
accept = REMOTE_SERVER_IP:443
connect = REMOTE_SERVER_IP:11440
cert=/etc/stunnel/server.pem
key=/etc/stunnel/server.key

OPENVPN CONFIG บนเซิร์ฟเวอร์:

local REMOTE_SERVER_IP
port 11440
proto tcp

พยายามเรียนรู้แง่มุมใหม่ที่มี VPNs และโปรโตคอลเครือข่ายที่เข้าใจพร้อมกับการวิเคราะห์ ect ...
เจสัน

2
คุณสามารถตอบคำถามที่ 2 ด้วย wireshark ที่ทำงานบนแล็ปท็อปของคุณและอาจเรียนรู้มากขึ้นระหว่างทาง
Alec Istomin

ไม่ใช่ว่าคุณควรปิดการใช้งานการบีบอัด TLS (เพราะ CRIME) และ จำกัด จำนวนโปรโตคอล TLS และ cryptosuites ที่มีอยู่เพื่อหลีกเลี่ยงการโจมตีที่ง่ายในอุโมงค์ TLS ของคุณ ( ฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์) หากคุณต้องการใช้งานจริง โลก.
ysdx

คุณสามารถใช้พอร์ตอื่นสำหรับ SSL / TLS ฉันทำมันผ่าน SCTP และ IPv6
Skaperen

คำตอบ:


22

OpenVPN ผ่าน TLS

VPN ของคุณใช้ TCP เป็นโปรโตคอลการขนส่ง อินสแตนซ์ stunnel ใช้เพื่อสรุปเนื้อหาของสตรีม TCP ใน TLS / TCP คุณได้รับโปรโตคอลสแต็กนี้:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 เซิร์ฟเวอร์ stunnel ทำให้มึนงงไคลเอ็นต์

ระหว่างอินสแตนซ์ stunnel คุณมีโปรโตคอลสแต็กนี้บน wire:

[IP]
[OpenVPN]
[TLS]
[TCP (443)]
[IP]
[... ]

เมื่อ TLS เข้ารหัสส่วนของข้อมูลผู้โจมตีจะเห็นเฉพาะ:

[??? ]
[TLS]
[TCP (443)]
[IP]
[... ]

ดังนั้นใช่มันเป็นการรับส่งข้อมูล TLS ธรรมดา (อาจเป็น HTTP / TLS, SMTP / TLS, POP / TLS หรืออย่างอื่นสำหรับคนที่ดูการรับส่งข้อมูล แต่มันดูเหมือน HTTP / TLS มากเนื่องจากใช้พอร์ต TCP 443) คุณสามารถตรวจสอบสิ่งนี้ได้โดยใช้ wireshark: บันทึกการรับส่งข้อมูลระหว่างอินสแตนซ์ stunnel ใน wireshark UI (ปุ่มขวาบนแพ็คเก็ตของสตรีม) คุณสามารถขอ wireshark เพื่อตีความปริมาณการใช้ข้อมูลเป็น TLS: มันจะรับรู้ว่าเป็นการรับส่งข้อมูล TLS (คุณจะเห็นข้อความ TLS ที่แตกต่างกัน แต่ไม่ใช่ payload ของเซสชัน TLS) .

คุณอาจต้องการใช้SNIในไคลเอนต์เพื่อให้ดูเหมือนว่าเบราว์เซอร์สมัยใหม่จะทำอะไร คุณอาจต้องการใช้ALPNด้วยเช่นกัน แต่ stunnel ในปัจจุบันไม่สามารถจัดการได้

OpenVPN พร้อม TLS ในตัว

ในการเปรียบเทียบหากคุณใช้ OpenVPN คุณจะมีดังนี้:

[IP]
[OpenVPN]
[TCP]
[IP]
[... ]

ซึ่งมีลักษณะเช่นนี้:

[??? ]
[OpenVPN]
[TCP]
[IP]
[... ]

เลเยอร์ TLS ในตัวไม่ได้ห่อหุ้มแพ็กเกจ (IP, Ethernet) แต่ใช้สำหรับตั้งค่าเซสชันและตรวจสอบสิทธิ์เท่านั้น:

[TLS]
[OpenVPN]
[TCP]
[IP]
[... ]

ในกรณีนี้การรับส่งข้อมูลของคุณจะไม่เหมือนการรับส่งข้อมูล TLS ธรรมดา แต่เห็นได้ชัดว่าเป็น OpenVPN หากคุณตีความการรับส่งข้อมูลนี้เป็น OpenVPN ใน wireshark คุณจะจดจำข้อความ OpenVPN และภายในข้อความ TLS (แต่ไม่ใช่เพย์โหลด)

คำเตือน

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

OpenVPN บน TLS ด้วยการตรวจสอบสิทธิ์ลูกค้า

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

* คำเตือน: ** ฉันไม่ได้พูดถึงการสนับสนุน TLS ในตัวใน OpenVPN (ดูคำอธิบายด้านบนเกี่ยวกับสาเหตุที่ไม่สามารถช่วยคุณได้)

มัลติเพล็กซ์ OpenVPN / TLS และ HTTP / TLS

อีกวิธีคือให้บริการทั้ง HTTP และ OpenVPN ผ่านเซสชัน TLS sslhสามารถใช้เพื่อตรวจหา payload ของโปรโตคอลโดยอัตโนมัติและส่งไปยังเซิร์ฟเวอร์ HTTP / TCP ธรรมดาหรือเซิร์ฟเวอร์ OpenVPN / TCP ของคุณ เซิร์ฟเวอร์จะมีลักษณะเหมือนเซิร์ฟเวอร์ HTTP / TLS มาตรฐาน แต่มีคนพยายามพูด OpenVPN / TLS ด้วยเซิร์ฟเวอร์นี้จะสามารถตรวจพบว่าในความเป็นจริงแล้วเซิร์ฟเวอร์ OpenVPN / TLS เช่นกัน

        ทั้ง OpenVPN / TCP
          หรือ HTTP / TCP       
[1] .--------- .------. โปรโตคอล HTTP / TCP .-------------
-> | stunnel | ----> | sslh | -------> | เซิร์ฟเวอร์ HTTP
   '---------' '------' | '-------------'
                           | .----------------
                           '------> | เซิร์ฟเวอร์ OpenVPN
                        OpenVPN / TCP '----------------'

[1] = อาจเป็น OpenVPN / TLS / TCP หรือ HTTP / TLS / TCP

OpenVPN ผ่าน HTTP CONNECT ผ่าน TLS

อีกวิธีคือใช้เซิร์ฟเวอร์ HTTP / TLS มาตรฐานและใช้ HTTP CONNECT / TLS เพื่อเชื่อมต่อกับเซิร์ฟเวอร์ OpenVPN: มันจะดูเหมือนเซิร์ฟเวอร์ HTTP มาตรฐาน คุณสามารถแม้แต่ต้องการการรับรองความถูกต้องของไคลเอนต์เพื่ออนุญาตการร้องขอ HTTP CONNECT (ปลาหมึกควรทำเช่นนี้)

OpenVPN มีตัวเลือกให้ใช้ HTTP Proxy:

http-proxy proxy.example.com

คุณควรจะสามารถรวมสิ่งนี้กับอินสแตนซ์ stunnel ที่เชื่อมต่อกับ HTTPS PROXY ระยะไกล:

http-proxy 127.0.0.1 8443
remote vpn.example.com

ซึ่งจะใช้โปรโตคอลสแต็กนี้:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [HTTP] <-------------> [HTTP]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 เซิร์ฟเวอร์ HTTPS PROXY สตันลูกค้า

คุณช่วยอธิบายเกี่ยวกับวิธี HTTP CONNECT ให้ละเอียดได้ไหม? ฉันจะหาคำแนะนำในการตั้งค่านี้ได้ที่ไหน
kontextify

kobtextify: เพิ่มรายละเอียดบางอย่างเกี่ยวกับการใช้งานที่เป็นไปได้ของ OpenVPN / HTTP_CONNECT / TLS
ysdx

ขอบคุณ! เว็บเซิร์ฟเวอร์หรือส่วนของ Squid จะมีลักษณะอย่างไร
kontextify

ฉันเดาว่าทุกอย่างเช่น« acl VPN_SERVER dstdomain vpn.example.com »« acl VPN_PORT พอร์ต 1194 »« acl วิธีเชื่อมต่อ CONNECT เชื่อมต่อ»« http_access อนุญาตให้ VPN_SERVER VPN_PORT CONNECT »« http_access ปฏิเสธทั้งหมด»
ysdx

4

คำตอบของ ysdx นั้นยอดเยี่ยมมากและอธิบายได้อย่างชัดเจนว่าการรับส่งข้อมูลจะดูบนเส้นลวดอย่างไร

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

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

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

OTOH การเชื่อมต่อ OpenVPN อาจใช้เวลาหลายชั่วโมงหรือหลายวันและจะส่งข้อมูลจำนวนมากกลับไปกลับมาไปยังเซิร์ฟเวอร์ openvpn

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


2
ใช่. ยิ่งไปกว่านั้นฉันคิดว่าอาจเป็นไปได้ที่จะดูรูปร่างของการรับส่งข้อมูล (เช่น "burstiness") และเปรียบเทียบกับ HTTP / TLS มาตรฐาน IMAP / TLS, POP / TLS, OpenVPN / TLS คุณอาจพยายามจำแนกทราฟฟิก TLS ที่กำหนดพร้อมกับโปรไฟล์ของทราฟฟิกเหล่านั้นและมีแนวคิดเกี่ยวกับประเภทของทราฟฟิกที่ห่อหุ้มในการเชื่อมต่อ TLS ของคุณ
ysdx
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.