กฎ IPTables เพื่ออนุญาตการเชื่อมต่อ SSH ขาเข้า


11

จุดประสงค์ของสคริปต์นี้คืออนุญาตการรับส่งข้อมูลผ่าน VPN เท่านั้นยกเว้น localhost <-> localhost และทราฟฟิก SSH ขาเข้า แต่เมื่อฉันรันสคริปต์ผ่าน SSH ฉันถูกตัดการเชื่อมต่อและถูกบังคับให้รีสตาร์ท vm เกิดอะไรขึ้นกับสคริปต์ของฉัน

#!/bin/bash
iptables -F

#Allow over VPN
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT

#Localhost
iptables -A INPUT -s 127.0.0.1/8 -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1/8 -j ACCEPT

#VPN
iptables -A INPUT -s 123.123.123.123 -j ACCEPT
iptables -A OUTPUT -d 123.123.123.123 -j ACCEPT

#SSH
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#Default Deny
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

คำตอบ:


10

ห่วงโซ่การส่งออกเป็นผู้รับผิดชอบใด ๆแพ็คเก็ตออกไป

สคริปต์ของคุณอนุญาตเฉพาะแพ็กเก็ตขาออกไปยังช่องสัญญาณอินเตอร์เฟสโฮสต์ท้องถิ่นและรีโมตโฮสต์ที่ 123.123.123.123

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

ในการอนุญาตให้แพ็กเก็ตขาออกจาก SSH daemon ของคุณไปยังไคลเอ็นต์ SSH คุณต้องเพิ่มกฎต่อไปนี้:

iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

คุณอาจต้องการเพิ่มเกณฑ์ IP ปลายทางในกฎด้านบนหากคุณเชื่อมต่อจากที่เดียวเท่านั้น กฎนี้ต้องมาก่อนกฎ DROP อย่างอื่นที่ดีที่สุดสำหรับห่วงโซ่ผลลัพธ์


+1 สิ่งนี้จะใช้งานได้และมีความเฉพาะเจาะจงมากกว่าการใช้กฎที่เกี่ยวข้องและกำหนดขึ้น (ทำให้เป็นประโยชน์มากหรือน้อยขึ้นอยู่กับบริบท)
goldilocks

ทั้งคำตอบที่ดีฉันได้เรียนรู้มากมาย! ฉันทดสอบ @SkyDan คำตอบแล้วมันใช้งานได้ดี!
Steven

Nitpick: ห่วงโซ่ผลผลิตไม่รับผิดชอบต่อแพ็คเก็ตที่ส่งต่อ
Björn Lindqvist

13

#SSHกฎของคุณหมายถึง ssh เป็นรูปแบบการสื่อสารทางเดียวซึ่งไม่ใช่ กำลังส่งข้อมูลไปและกลับ

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

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

ก่อนDROPกฎของคุณ(และควรอยู่ด้านบนสุดเนื่องจากกฎจะถูกประมวลผลตามลำดับและทั้งสองจะใช้กับแพ็กเก็ตส่วนใหญ่)

มีคำอธิบายว่าการเชื่อมต่อ TCP กลายเป็นสิ่งที่เกิดขึ้นได้อย่างไรที่นี่ ; โดยพื้นฐานแล้วความจริงของเซิร์ฟเวอร์ที่ตอบแพคเก็ตที่#SSH INPUTกฎของคุณอนุญาต


1
สิ่งนี้จะไม่ทำงาน ก่อตั้งขึ้นหมายถึงแพ็กเก็ตทั้งสองทิศทางสำหรับการเชื่อมต่อ TCP ที่กำหนดได้ถูกเห็น หากคุณเพิ่มกฎนี้เท่านั้นแพ็คเก็ตขาออกแรกจะยังคงถูกบล็อก
hellodanylo

2
@SkyDan ต่อไปนี้เป็นข้อมูลอ้างอิงสำหรับสิ่งนั้น สังเกตจากแผนภาพที่ว่าเมื่อเซิร์ฟเวอร์ส่ง syn / ack กลับไปยังไคลเอนต์หลังจากได้รับการเปิดแล้วการเชื่อมต่อจะถูกกำหนดขึ้น iptables จะอนุญาตให้แพ็กเก็ตตอบกลับนั้นผ่าน: "เมื่อได้เห็นหนึ่งแพ็กเก็ต (the SYN) จะพิจารณา การเชื่อมต่อเป็นใหม่เมื่อเห็นการส่งคืนแพ็กเก็ต (SYN / ACK) จะถือว่าการเชื่อมต่อเป็น ESTABLISHED " -> อีกครั้ง: iptables เห็นแพ็กเก็ตการส่งคืนที่เซิร์ฟเวอร์ต้องการส่ง, ตั้งค่าการเชื่อมต่อตามที่กำหนดไว้, และให้การตอบกลับผ่าน
goldilocks

1
โอเคฉันเห็นว่าทำไมมันถึงใช้ได้ มันค่อนข้างคลุมเครือเนื่องจากมนุษย์ iptables พูดถึงการมองเห็นแพ็กเก็ตทั้งสองทิศทางเท่านั้นไม่ใช่คำที่เกี่ยวกับแพ็กเก็ต TCP handshake ที่เป็นข้อยกเว้น ขอบคุณสำหรับการอ้างอิง!
hellodanylo

2
@SkyDan ในความเป็นจริงตรรกะไม่ได้ใช้เฉพาะกับ tcp - ฉันผิดเกี่ยวกับ-p tcpการสร้างความแตกต่างในแง่นี้และดูคำอธิบายที่ตามมาสำหรับ UDP ในหน้านั้น (มันเหมือนกัน) ประเด็นก็คือเซิร์ฟเวอร์ตอบกลับโดยไม่ทราบว่า iptables จะอนุญาตหรือไม่และเมื่อ iptables ได้รับการตอบกลับนั้นจากเซิร์ฟเวอร์บนระบบโลคัลระบบจะเห็นทราฟฟิกในทั้งสองทิศทาง (แม้ว่าไคลเอ็นต์ยังไม่ได้พิจารณา) สร้างการเชื่อมต่อและอนุญาตให้ตอบกลับ "เทคนิค" ที่นี่บานพับไฟร์วอลล์อยู่กลางทั้งสองฝ่าย
goldilocks

1
คุณถูกต้องแล้ว บางคนควรรวมข้อมูลนี้ไว้ใน man iptables
hellodanylo
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.