การ จำกัด การเข้าถึงเครือข่ายของคอนเทนเนอร์ Docker

ฉันกำลังอยู่ในขั้นตอนการสร้าง SFTP เฉพาะDocker container หนึ่งที่จะถูกใช้โดยหลาย ๆ คนเพื่อจุดประสงค์ในการอัพโหลดและจัดการไฟล์ในchrootสภาพแวดล้อม ed ของพวกเขาเอง

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

ฉันต้องการป้องกันไม่ให้คอนเทนเนอร์นี้เข้าถึงอินเทอร์เน็ตจากภายในยกเว้นเพื่อเป็นเซิร์ฟเวอร์ SFTP

เพื่อให้สิ่งต่าง ๆ ชัดเจน: ฉันรู้วิธีป้องกันไม่ให้โลกภายนอกเข้าถึงคอนเทนเนอร์ของฉัน - ฉันสามารถตั้งค่าiptablesกฎขาเข้าและฉันสามารถเปิดเผยเฉพาะพอร์ต SFTP ในคำสั่งเรียกใช้นักเทียบท่าของฉัน

อย่างไรก็ตามฉันต้องการที่จะทำให้คำสั่งต่อไปนี้ (เป็นตัวอย่าง) ล้มเหลวเมื่อวิ่งเข้าไปในภาชนะ:

curl google.com

ความตั้งใจของฉันคือลดปริมาณความเสียหายที่คอนเทนเนอร์ที่แฮ็กสามารถทำได้ (ไม่สามารถใช้เพื่อส่งอีเมลขยะ ฯลฯ )

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

ตกลงดังนั้นหลังจากได้รับความเห็นที่อธิบายว่าการกรองนั้นมีไว้สำหรับโฮสต์ของคอนเทนเนอร์มันก็ค่อนข้างชัดเจนว่าจะพยายามทำอะไรให้สำเร็จ ในกรณีนี้บนโฮสต์คุณจะต้องเพิ่มกฎที่คล้ายกับสิ่งนี้:

iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT
iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -j DROP

กฎสองข้อแรกใช้สำหรับการเข้าถึงระหว่างโฮสต์และคอนเทนเนอร์ กฎข้อที่สามบอก (อย่างคร่าว ๆ ) ว่าสิ่งใดก็ตามที่ไม่ใช่ซับเน็ตของโฮสต์ที่ใช้สำหรับ SFTP นั้นเป็นสิ่งที่เราต้องการ กฎข้อที่สี่คือกฎขาออกซึ่งโดยทั่วไปจะเป็นคู่กับกฎที่สาม กฎข้อที่ห้าเป็น catch-all (ในกรณีที่มีพอร์ตอื่น ๆ ที่เกี่ยวข้องที่ใช้) แม้ว่าจะไม่จำเป็นต้องใช้ แต่คุณอาจลบออกได้ กฎข้อสุดท้ายคือเวทย์มนตร์ที่ป้องกันการเข้าถึงสิ่งอื่นที่ไม่ใช่ซับเน็ตโฮสต์ เนื่องจากการเข้าถึงนั้นกำหนดไว้ในกฎสองสามข้อแรกมันจะไม่มีวันกระตุ้นจนกว่าจะไม่มีการใช้กฎก่อนหน้านี้ซึ่งในกรณีนี้เรากำลังพูดว่า "เราไม่สนใจสิ่งที่คุณต้องการคุณจึงไม่ตรงกับสิ่งที่คุณอนุมัติ ดังนั้นคุณไม่สามารถไปจากที่นี่ได้ " การรับส่งข้อมูลขาเข้าจากภายนอกจะเป็นไปตามกฎข้อที่ 3 และ 4

นี่ไม่ใช่ปัญหาเฉพาะนักเทียบท่าจริงๆ มีสองวิธีที่คุณสามารถแก้ไขปัญหานี้ได้

1. ใช้iptablesกฎstateful เพื่ออนุญาตการเชื่อมต่อขาเข้าและที่เกี่ยวข้อง / สร้างการรับส่งข้อมูลแล้วบล็อกทุกอย่างอื่น

2. ใช้บริการ sftp เท่านั้นเช่นProFTPDที่ไม่สามารถใช้เชลล์ได้

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

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

เพื่อป้องกันทราฟฟิกขาออกบนไม่ใช่ SSH (SFTP) และพอร์ตเว็บคุณอาจต้องการใช้นโยบายผ่าน IPTABLES หรือไฟร์วอลล์ Layer4 อื่นเพื่อ DROP หรือทราฟฟิก REJECT ที่มาจากเซ็กเมนต์ที่ใช้โดยคอนเทนเนอร์ปลายทางที่ 0.0.0.0/0 ยกเว้นเมื่อปลายทาง พอร์ตคือ TCP22

ในการแก้ปัญหาที่ไม่ได้รับอนุมัติสถานที่บนเว็บคุณอาจต้องการลองตั้งค่าอินสแตนซ์ของพร็อกซีการกรอง / แคชเช่น squid หรือ bluecoat ซึ่งกำลังฟังบนอินเตอร์เฟส docker0 และกำลังใช้งานอยู่ เส้นทาง defalt ของโฮสต์เพื่อออกไปยังอินเทอร์เน็ต จากที่นั่นคุณสามารถใช้นโยบายตามเกณฑ์หลายอย่างรวมถึงการบันทึกการใช้เครือข่ายโดยการแคชเนื้อหาแบบคงที่ คุณอาจต้องการใช้ NAT (ฉันคิดว่า IPTABLES และ Masquerade จัดหาสิ่งนี้ใน Linux) บนเครื่องโฮสต์เพื่อบังคับใช้พร็อกซีอย่างโปร่งใส (ฉันอธิบายสิ่งนี้ในการตอบกลับของ ฉันฉันต้องการพร็อกซี HTTP เท่านั้น แต่ฉันไม่แน่ใจว่าจะทำอย่างไร ทำกับการจราจร HTTPS ) สิ่งนี้แสดงถึงเหตุผลที่จะเข้าสู่เว็บตั้งแต่แรกที่ปฏิบัติตามนโยบายของ บริษัท ของคุณ

เนื่องจากลักษณะของ SSH (ซึ่งใช้ SFTP) คุณจะไม่สามารถให้การรับส่งข้อมูลสำหรับการย้ายไฟล์เว้นแต่ว่าคุณจะใช้นโยบายโดยที่คอนเทนเนอร์อาจใช้คู่คีย์ที่ได้รับจากคุณเท่านั้น นี่เป็นสิ่งที่ดีสำหรับคุณเพราะมันทำให้คุณมีบางอย่าง " ฉันไม่สามารถมองเห็นหรือควบคุมไฟล์ที่ถ่ายโอนได้"การป้องกันหากลูกค้าคนใดคนหนึ่งของคุณถ่ายโอนบางสิ่งผิดกฎหมาย (เช่นการละเมิดทรัพย์สินทางปัญญาหรือใช้บริการของคุณเพื่อ exfiltrate ข้อมูลที่มีฉลากจัดประเภทหรือพวกเขาค้าขายใน CP) หากคุณถูกนำตัวขึ้นศาลเพื่อทำสิ่งที่ลูกค้าทำ สถานะผู้ให้บริการร่วมกันสำหรับ telcos) สิ่งนี้ไม่ดีสำหรับคุณเนื่องจากคุณไม่สามารถแคชถ่ายโอนไฟล์ที่ไม่มีการเปลี่ยนแปลงบ่อยครั้งและเนื่องจากนโยบายใด ๆ ที่คุณเขียนลงในสัญญากับลูกค้าของคุณจะไม่สามารถบังคับใช้ได้ด้วยวิธีการทางเทคนิค