- SilverSky9/DevToolNo1 GitHub Wiki

Top 10 :: Docker security จาก OWASP

แบบจำลองภัยคุกคาม

ในการจำลองภัยคุกคามจะมีการจำลองจากมุมมองของผู้โจมตี มีแบบจำลองดังนี้

  1. Container Escape (System) ในแบบจำลองนี้แอปพลิเคชันจะไม่ปลอดภัยเนื่องจาก ผู้โจมตีสามารถเข้าถึงและสามารถจัดการแอปพลิเคชันได้ เช่น เข้าถึงจากอินเทอร์เน็ต โดยสามารถเข้ามาใน container ได้ และในขั้นต่อมาผู้โจมตีซ่อน container จากผู้ใช้ที่เป็น host และจะตั้งตนเองขึ้นมาเป็น host เอง จากนั้น จะรูทและสามารถควบคุม container ทั้งหมดได้
  2. Other Containers via Network ในแบบจำลองนี้จะมีสถานการณ์เหมือนกับข้อแรก แต่ต่างกันที่จะมีการโจมตี container อื่นๆผ่านเครือข่าย ซึ่่งอาจจะมีการโจมตีจาก แอปพลิเคชันเดียวกัน หรือมาจากแอปพลิเคชันอื่นๆ ที่มีลูกค้าคนเดียวกัน
  3. Attacking the Orchestration Tool via Network ในแบบจำลองนี้จะมีสถานการณ์เหมือนกับสองข้อแรกผู้โจมตีสามารถเข้าถึงภายใน container ได้และเลือกที่จะโจมตีอินเทอร์เฟซการจัดการ หรือโจมตี orchestration tool
  4. Attacking the Host via Network แบบจำลองนี้จะมีการโจมตีจากพอร์ตที่เปิดอยู่จากโฮสต์ หากมีการป้องกันที่ไม่ดีพอผู้โจมตีจะมีโอกาสในการเข้าถึงรูทและจะมีสิทธิ์เป็น host
  5. Attacking other Resources via Network แบบจำลองนี้จะมีการโจมตีจากะบบไฟล์บนเครือข่ายที่ไม่มีการป้องกันซึ่งใช้ร่วมกันระหว่างคอนเทนเนอร์ที่สามารถอ่านหรือแก้ไขข้อมูลได้ หรืออาจจะมาจากการใช้ Jenkins ที่มีการกำหนดค่าเปิดเกินไปและสามารถเข้าถึงได้จากคอนเทนเนอร์
  6. Resource Starvation แบบจำลองนี้มีการโจมตีจากข้อจำกัดของทรัพยากร เช่น CPU, RAM เป็นต้นโดยผู้โจมตีอาจจะมีการใส่ข้อมูลให้กินทรัพยากรจนเต็ม การทำเช่นนี้จะทำให้ การใช้ container อื่นมีปัญหา
  7. Host compromise การโจมตีในที่นี้จะไม่เหมือนกับที่ผ่านๆมาที่ จะโจมตีผ่าน host แต่จะเป็นการพูดถึงการโจมตีที่ host โดยตรง
  8. Integrity of Images ในการทำ CD pipeline จะมีการที่เกี่ยวข้องกับการ hop อาจจะมีการโจมตีผ่านการ hop ได้

D01 - Secure User Mapping

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

ภัยคุกคาม

ภัยคุกคามมักจะเกิดขึ้นเมื่อรัน microservice ใน container ภายใต้ root ถ้า service มีช่องโหว่ attacker จะได้รับสิทธิ์เต็มที่ใน contrainer ในขณะที่ default protection ยังคงอยู่ ก็จะถูกลบการป้องกันออกหนึ่งlayer และขยายการโจมดี

สำหรับ privileged containers การแยกจาก microservice ไปยังcontainer นั้นเทียบได้กับการรันโดยไม่มี container Privileged containers นั้นเป็นอันตรายต่อhost และcontainerทั้งหมด

การป้องกันภัยคุกคาม

สิ่งสำคัญคือต้องเรียกใช้ microservice ด้วยสิทธิ์ที่ต่ำที่สุดเท่าที่จะเป็นไปได้

  • อย่าใช้ --privileged flag
  • กำหนดค่า mini distribution ของ container และ service ต้องใช้ user และ group เดียวกัน
  • ควรกำหนดค่าพอร์ตและแมปพอร์ตที่สูงกว่า 1024 ด้วยคำสั่ง expose
  • สำหรับผู้ใช้ Linux ควรใช้ namespaces ในการหาความแตกต่างของแต่ละ container

D02 - Patch Management Strategy

สิ่งที่เลวร้ายที่สุดคือการที่ host หรือ orchestration tool ถูกบุกรุกทำให้ผู้โจมตีสามารถควบคุมคอนเทนเนอร์ทั้งหมดที่ทำงานบน host และทำให้ผู้โจมตีสามารถควบคุมคอนเทนเนอร์ทั้งหมดบน host ได้และร้ายแรงกว่านั้นคือการที่เข้าถึง host และมีการใช้ประโยชน์จากเคอร์เนลจากภายในคอนเทนเนอร์โดยมีการเรียกใช้ Linux sys(tem) ในทางที่ผิด ซึ่งนำไปสู่การเข้าถึงรูท

ภัยคุกคาม

  • host หรือ orchestration tool ถูกบุกรุก
  • การใช้ประโยชน์จากเคอร์เนลภายในคอนเทนเนอร์โดยการเรียกใช้ Linux sys(tem) ในทางที่ผิด ซึ่งนำไปสู่การเข้าถึงรูท
  • ภัยคุกคามอื่นอาจเกิดขึ้นจากบริการ Linux บนโฮสต์ นอกจากนี้ หากการกำหนดค่าโฮสต์ให้มีความปลอดภัยพอที่เหมาะสมแล้ว หาก service ไม่ได้รับการรักษาความปลอดภัยผ่านเครือข่ายและการกำหนดค่าที่เหมาะสม ความเสี่ยงก็จะสูงขึ้น

การป้องกันภัยคุกคาม

Different Patch Domains - การดูแลรักษา infrastructure software นั้นไม่ตรงไปตรงมาแม้ว่าจะมี patch domains ที่แตกต่างกันสี่รายการ : Images: the container distribution Container software: Docker Orchestration software (Kubernetes, Mesos, OpenShift, ...) Host: operating system

D03 - Network Segmentation and Firewalling

การจัดการ interfaces โดย orchestration tool และโดยเฉพาะอย่างยิ่ง network services จาก host มีความสำคัญและจำเป็นต้องได้รับการป้องกันในระดับ network level และต้องตรวจสอบให้แน่ใจด้วยว่า microservice บนเครือข่ายอื่นแสดงให้เห็นเฉพาะคนที่ควรได้เห็น

ภัยคุกคาม

Internet expose การจัดการ frontends/APIs จาก orchestration tool LAN/DMZ expose การจัดการ frontends/APIs จาก orchestration tool การเข้าถึง host's services โดย microservice LAN/DMZ exposed microservices โดยไม่จำเป็น ใน LAN จากapplication เดียวกัน (token) LAN/DMZ exposed classical services โดยไม่จำเป็น (NFS/Samba, อุปกรณ์ CI/CD, DB) ไม่ได้แยก Network ระหว่าง tenant แบบ 100% เหมือนใช้ Networkเดียวกัน

การป้องกันภัยคุกคาม

เลือก network driver ที่เหมาะสมกับ environment แบ่ง DMZ อย่างเหมะสม ไม่ควรให้ tenant ใช้ network เดียวกัน กำหนดการสื่อสารที่จำเป็น ดูแลป้องกันไม่ expose frontends/APIs ใน internet ถ้าจำเป็นจริงๆให้อนุญาตเฉพาะ IP ที่เชื่อถือได้ และอย่า expose ใน DMZ ปกป้อง host services ในลักษณะเดียวกัน ใน orchestrated environment

D04 - Secure Defaults and Hardening

ขึ้นอยู่กับการเลือก host container operating system และ orchestration tool ต้องดูว่าไม่มีการติดตั้งส่วนประกอบที่ไม่จำเป็น นอกจากนี้ส่วนประกอบที่จำเป็นทั้งหมดจะต้องได้รับการกำหนดค่า และล็อคไว้อย่างเหมาะสม

ภัยคุกคาม

  • interface จาก orchestration tool เช่น dashboard, etcd, API
  • interface จาก host เช่น RPC services, OpenSSHD, avahi, network based systemd-services
  • interface ระหว่าง containerกับmicro service เช่น spring-boot หรือ distribution

การป้องกันภัยคุกคาม

  • Orchestration / Host สำหรับ orchestration tool สิ่งสำคัญคือต้องรู้ว่า serviceใดกำลังทำงานอยู่บ้าง และ serviceได้รับการปกป้องหรือมีdefault configurationที่เหมาะสมหรือไม่ โดยทั่วไป ต้องแน่ใจว่าคุณรู้ว่ามี service ใดบ้างจากแต่ละcomponent ใน LAN จากนั้นต้องตัดสินใจว่าจะทำอย่างไร

  • Containert สำหรับ Container แนวทางที่ดีที่สุดคือ: อย่าติดตั้งแพ็คเกจที่ไม่จำเป็น Alpine Linux นั้นมีขนาดเล็กและมีตามค่า default binaries on board น้อยกว่า และยังมาพร้อมกับชุด binaries เช่น wget และ netcat ในกรณีของแอปพลิเคชั่น breakout ใน container ซึ่ง binaries เหล่านั้นสามารถช่วย attacker ให้โจมตีได้

D05 - Maintain Security Contexts

การผสม production containers ที่ใช้งานจริงบน host กับขั้นตอนอื่นๆ ของคอนเทนเนอร์ที่ไม่ได้กำหนดไว้ หรือมีความปลอดภัยน้อยอาจเปิด backdoor ใน production ของคุณ เช่นผสม frontend กับ backend services บน host เดียวอาจส่งผลกระทบด้านลบต่อความปลอดภัย

ภัยคุกคาม

  • application มีช่องโหว่ ทำให้ attackerสามารถเข้าไปในเครือข่าย และเข้าถึง etcd หรือ http interface ของ the orchestration tool ได้

การป้องกันภัยคุกคาม

  • เอา production containers ไว้บน host system แยก และดูแลให้ดีว่าใครมีสิทธิ์ deployกับโฮสต์ที่มี production containers
  • การพิจารณา security value ของข้อมูลและแยก containerกันตามบริบท Databases, middleware, authentication services, frontend และ master components ไม่ควรอยู่ใน hostเดียวกัน

D06 - Protect Secrets

การตรวจสอบสิทธิ์ และการอนุญาตไมโครเซอร์วิสต่อเพียร์หรือบุคคลที่สามจำเป็นต้องเป็นความลับ สำหรับผู้โจมตีความลับเหล่านั้นอาจทำให้เขาสามารถเข้าถึงข้อมูลหรือบริการของคุณได้มากขึ้น ดังนั้น passwords, tokens, private keys หรือ certificates จึงต้องได้รับการปกป้องให้ดีที่สุด

D07 - Resource Protection

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

ภัยคุกคาม

  • ขึ้นอยู่กับโฮสต์ OSไม่ว่าจะเกิดจากความล้มเหลวของซอฟต์แวร์หรือเกิดจากสาเหตุโดย attacker หนึ่งในทรัพยากรเหล่านั้นทำงานไม่นาน ซึ่งส่งผลต่อทรัพยากรทางกายภาพของโฮสต์และคอนเทนเนอร์อื่นๆ ทั้งหมด
  • หากคอนเทนเนอร์มี default security ที่กำหนดโดย docker แชร์ทรัพยากรทางกายภาพกับคอนเทนเนอร์อื่นและโฮสต์ ดังนั้นหากคอนเทนเนอร์อื่นใช้ทรัพยากรเหล่านั้นอย่างกว้างขวาง คอนเทนเนอร์ของคุณจะเหลือไม่มาก
  • สำหรับหน่วยความจำ สิ่งสำคัญคือต้องเข้าใจว่ามีสิ่งที่เรียกว่า OOM

การป้องกันภัยคุกคาม

สิ่งที่ดีที่สุดคือ container ที่กำหนดขีดจำกัดที่เหมาะสมในแง่ของหน่วยความจำและ CPU เมื่อถึงขีดจำกัดเหล่านั้น container จะไม่สามารถจัดสรรหน่วยความจำเพิ่มเติมหรือใช้ CPU ได้มากขึ้น สำหรับหน่วยความจำ มีสองตัวแปรหลักสำหรับการตั้งค่า คือ hard limit -memory และ --memory-swap เพื่อป้องกันกระบวนการในคอนเทนเนอร์ คุณสามารถตั้งค่า --oom-kill-disable ถ้า container daemons มีค่า OOM ต่ำกว่าปกติจะไม่ถูกkil

D08 - Container Image Integrity and Origin

ระบบปฏิบัติการขั้นต่ำของ container ต้องการความน่าเชื่อถือ ตั้งแต่ origin up จนถึงการdeployment คุณต้องตรวจสอบให้แน่ใจว่าไม่มีการแก้ไข  image และ transfers

D09 - Follow Immutable Paradigm

บ่อยครั้งที่ container images ไม่จำเป็นต้องเขียนลงใน filesystem หรือ mounted filesystem เมื่อ set up และ deployed ในกรณีดังกล่าวจะได้รับประโยชน์ด้านความปลอดภัยเพิ่มเติมหากเริ่มcontainers ใน read-only mode

D10 - Logging

สำหรับ container image, orchestration tool และ host นั้นจำเป็นต้องเก็บ log เหตุการณ์ที่เกี่ยวกับ security ทั้งหมดบนระบบ และใน API level Logทั้งหมดควรเป็นremote ซึ่งควรมี timestamp และ tamper proof รวมถึงให้มี remote loggingด้วย

สรุป

  1. แยกกลุ่ม Container สำหรับแต่ละ Microservices ออกจากกัน เพื่อให้ขนาดของ Container Image เล็กอยู่เสมอ
  2. อย่าเปิดให้มีการ SSH ตรงเข้าไปยัง Container เด็ดขาด แต่ให้ใช้คำสั่ง docker exec แทน
  3. ใช้ Container Image ที่ได้รับการ Sign แล้ว จะได้มั่นใจว่าปลอดภัยขึ้น
  4. ทำการ Mount Device และ Volume ต่างๆ ในแบบ Read-only เท่านั้น
  5. เรียกใช้งาน Application ด้วยสิทธิ์อื่นๆ ที่ไม่ใช่ Root เท่านั้น แต่หากจำเป็นต้องใช้ Root จริงๆ ก็ให้ใช้แบบจำกัด Operation ที่จะสามารถเรียกใช้ได้ด้วยการใช้ Capabilities, Seccomp, SELinux/AppArmor
  6. หมั่นอัปเดต OS ให้ปลอดภัยอยู่เสมอ และแนะนำให้ใช้ OS ที่ถูกออกแบบมาสำหรับใช้ทำ Container ด้วย เพราะ OS เหล่านี้มักจะมีระบบ Push Update แบบอัตโนมัติมาให้ในตัว
  7. เก็บ Root Key และ Passphrase เอาไว้ในที่ปลอดภัย ห้ามเอาไปใส่ไว้ใน Dockerfile เด็ดขาด โดยหลังจากนี้ Docker มีแผนที่จะพัฒนาระบบจัดการ Key เอาไว้บน Docker Datacenter ให้ได้ใช้กันด้วย
  8. ใช้ Docker Official Image เพราะ Docker เองนั้นจะตรวจสอบทั้งในแง่ของประสิทธิภาพและความปลอดภัยของ Image เหล่านี้อยู่เสมอ
  9. ใช้เครื่องมือ Container Security Scanning เพื่อตรวจสอบหาช่องโหว่ที่อาจปรากฎบนระบบ
  10. ใช้ TLS เพื่อเข้าถึง Docker Daemon จากระยะไกลเสมอ