OpenSnitch ไฟร์วอลล์แอปพลิเคชันแบบโต้ตอบสำหรับ GNU/Linux

 (github.com/evilsocket)
3 คะแนน โดย GN⁺ 2024-08-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenSnitch เป็นไฟร์วอลล์แอปพลิเคชันสำหรับ GNU/Linux ที่เน้นการกรองการเชื่อมต่อภายนอกของแอปพลิเคชันแบบโต้ตอบ
  • สามารถบล็อก โดเมนโฆษณา·ตัวติดตาม·มัลแวร์ ได้ทั้งระบบ และยังตั้งค่าไฟร์วอลล์ระบบที่อิงกับ nftables ได้จาก GUI
  • GUI รองรับการกำหนดค่า กฎของระบบ เช่น การตั้งค่านโยบายขาเข้าและการอนุญาตบริการขาเข้า รวมถึงจัดการหลายโหนดจากศูนย์กลางได้
  • การติดตั้งทำได้โดยดาวน์โหลดแพ็กเกจ deb/rpm แล้วติดตั้งด้วย apt หรือ dnf จากนั้นรัน opensnitch-ui หรือเปิด GUI จากเมนูแอปพลิเคชัน
  • มีพื้นที่สนทนา Show and tell สำหรับแชร์กรณีที่ตรวจจับการเชื่อมต่อที่ไม่คาดคิดได้ และมีความสามารถในการเชื่อมต่อกับ SIEM เพื่อนำไปใช้เฝ้าระวังการเชื่อมต่อในสภาพแวดล้อมการใช้งานจริง

OpenSnitch ทำอะไร

ความสามารถด้านไฟร์วอลล์และการจัดการโหนด

ดาวน์โหลดและติดตั้ง

  • ดาวน์โหลดแพ็กเกจ deb/rpm ได้จาก GitHub Releases
  • ติดตั้งแพ็กเกจ deb:
    • sudo apt install ./opensnitch*.deb ./python3-opensnitch-ui*.deb
  • ติดตั้งแพ็กเกจ rpm:
    • sudo dnf install opensnitch*.rpm
  • หลังติดตั้ง ให้รัน opensnitch-ui หรือเปิด GUI จากเมนูแอปพลิเคชัน
  • ดูข้อมูลการติดตั้งเพิ่มเติมได้ในเอกสาร

กรณีใช้งานและการมีส่วนร่วม

ข้อมูลโครงการ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-11
ความคิดเห็นบน Hacker News

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

    • ถ้าใช้ ไวลด์การ์ดซับโดเมน หรือซับเน็ต ก็จะค่อย ๆ สร้างชุดกฎที่เสถียรได้ค่อนข้างเร็ว และหลังจากนั้นก็แค่ตรวจคำขอไปยัง endpoint ใหม่เป็นครั้งคราว
      ความอุ่นใจที่ว่าถ้ามีการเข้าถึงใหม่ ระบบจะถามว่าจะอนุญาตไหม ทำให้ความยุ่งยากช่วงแรกคุ้มค่า และพอชินแล้วก็จัดการได้ค่อนข้างง่าย
      กฎที่หมดอายุก็ใช้บ่อย เช่น ถ้าเชื่อถือโปรแกรมติดตั้งและอยากปล่อยให้ทำงานได้อิสระชั่วคราว ก็เปิดกฎสำหรับไฟล์ executable นั้นให้หมดอายุในอนาคตอันใกล้ ตัวเลือกมีทั้งถาวร, จนกว่าจะรีบูต, 30 วินาทีถัดไป, 5 นาทีถัดไป ฯลฯ ทำให้งานที่มี endpoint จำนวนมากง่ายขึ้นมาก และไม่ทิ้งช่องโหว่ถาวรไว้
    • ดูเหมือนอาจทำให้ผู้ใช้ dev อนุญาตทราฟฟิก curl/wget ทั้งหมดได้ ส่วนผู้ใช้ normal ก็ยังตรวจจับต่อไป
      งานพัฒนาก็รันด้วยรูปแบบ su -c curl … dev
      ถ้าโปรแกรมอันตรายกำลังรันอยู่ในพื้นที่ของผู้ใช้ทั่วไป แอปไฟร์วอลล์ก็น่าจะจับการใช้ curl และ wget ได้อย่างเหมาะสม
      การต้องใส่รหัสผ่านทุกครั้งน่ารำคาญ จึงอาจตั้งค่า PAM ให้ใช้ YubiKey หรือการยืนยันตัวตนแบบไบโอเมตริกได้ และผู้ใช้นี้ควรล็อกอินไม่ได้และไม่มีรหัสผ่านด้วย
    • ฟังดูแปลก ๆ นะ ถ้ากังวลจริง ๆ ก็เปลี่ยนชื่อ curl หรือ wget ได้
      ผมใช้ไฟร์วอลล์ระดับแอปบนมือถือ แต่ไม่ได้ใส่ชื่อโปรแกรมไว้ในรายการอนุญาต หากเป็นการอนุญาตให้โปรแกรมเฉพาะเข้าถึง โดเมน/IP address เฉพาะ
      จากประสบการณ์ วิธีที่ง่ายที่สุดในการบล็อกการสื่อสารออกภายนอกของโปรแกรมหรือมัลแวร์คือ บล็อกการเข้าถึง DNS ทำแบบนั้นมาหลายสิบปีแล้ว และยังทำงานได้สมบูรณ์ “99%” ของโปรแกรม/มัลแวร์ที่สื่อสารออกภายนอกพึ่งพา DNS ไม่ใช่ IP ที่ hardcode ไว้
      โปรแกรม/มัลแวร์ส่วนน้อยที่ไม่ต้องใช้ DNS ก็ตรวจจับได้ง่าย และใน DNS ก็อนุญาตเฉพาะบางโดเมนเท่านั้น ทุกวันนี้ไม่ได้ใช้ local zone file ที่มี IP address ที่จำเป็นแล้วด้วยซ้ำ แต่ให้ forward proxy จัดการ mapping โดเมน→IP รายการอนุญาตที่ proxy อ่านจะคล้าย zone file แต่เป็นไฟล์ข้อความที่ง่ายกว่า
    • คิดว่าน่าจะตั้งค่าได้แบบว่า ถ้าคำสั่งแม่เป็นคำสั่งที่เชื่อถือ เช่น bash/zsh ที่ผู้ใช้เป็นเจ้าของ ก็ปล่อย curl ผ่าน ไม่อย่างนั้นก็บล็อก แต่ก็ดูค่อนข้างยุ่งยาก
    • ปัญหาแบบนั้นแก้ได้ EDR ขนาดใหญ่บางตัวที่ทำงานคล้ายกันสามารถประกาศความสัมพันธ์ parent/child ของไฟล์ executable ที่จะบล็อกได้
      เช่น ถ้า curl ถูกเรียกใช้ และเมื่อไล่ย้อนรายการ parent ขึ้นไปเจอโปรเซส /usr/bin/trusted ก็ควรประกาศได้ว่าให้อนุญาตการเรียก curl ครั้งนี้ แบบนั้นตราบใดที่ parent ของสคริปต์ bash คือ /usr/bin/trusted ก็จะอนุญาตให้สคริปต์นั้นรัน curl ได้

  • นี่เป็นเหตุผลที่ทำให้สุดท้ายย้ายไป NixOS
    สมัยก่อนตอนใช้ไฟร์วอลล์ระดับแอป มีการตั้งค่าเยอะ อัปเดตที path เปลี่ยนก็พังบ่อย และทุกครั้งที่ย้ายไปเครื่องใหม่ต้องทำใหม่ทั้งหมด เกิด churn และความสูญเปล่าเยอะมาก
    พอผสานเข้ากับ package manager ปัญหาพวกนั้นก็หายไป หลังตั้งค่ารายการอนุญาตเริ่มต้นเสร็จแล้ว เวลาเพิ่มแพ็กเกจใหม่ใน config ของ nix ก็ต้องทำงานเพิ่มอีกนิดหน่อยเท่านั้น
    ถ้าขี้เกียจเพิ่มรายการอนุญาตใน config ของ nix ก็ใส่รายการอนุญาตชั่วคราวที่คงอยู่จนถึงการรีบูตครั้งถัดไปได้ ช่วงเรียนรู้ชันและงานก็เยอะ แต่ตอนนี้บำรุงรักษาง่ายมาก

    • สงสัยว่าเขาทำสิ่งนี้ด้วย ตัวเลือก OpenSnitch Nix ที่อยู่ใน search.nixos.org/options หรือเปล่า

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

    • พูดแบบนี้อาจดูไม่ดี แต่ PR น่าจะได้รับการต้อนรับแน่นอน แน่นอนว่าตัวผมเองก็แทบไม่มีเวลาเหมือนกัน

  • บน Fedora แนะนำตัวนี้ได้มากกว่าการไปงมกับ firewalld/firewall-config

    • แล้วควรจัดการยังไงกับ dnf ที่ทุกครั้งที่อัปเดตก็ไล่เชื่อมต่อไปทั่วทั้งทวีป?
      https://news.ycombinator.com/item?id=41124755
      จะอนุญาตไปเลยก็ได้ แต่ไม่อยากทำแบบนั้น

  • อยากให้มีฟีเจอร์แบบนี้เวลารัน API หรือเว็บเซอร์วิสใน Docker container
    containerA: อนุญาตทราฟฟิกขาออกทั้งหมด
    containerB: บล็อกทราฟฟิกขาออก ยกเว้นกรณีตอบกลับ client
    containerC: เข้าถึงได้เฉพาะ updates.example.com
    นี่ก็แค่ iptables แยกตาม container หรือเปล่า? น่าจะยัด iptables เข้าไปใน image เดิมได้ แต่ดูงานเยอะ หรือควรจัดการด้วย iptables บน host?

    • อยากเสริมว่า netfilter หรือก็คือสิ่งที่ iptables ใช้เป็น frontend นั้นเป็น kernel subsystem จึงมีผลแบบ global กับ container ทั้งหมดบน host

  • บนโทรศัพท์ Android มีอะไรแบบนี้ไหม? อยากได้คำแนะนำดี ๆ

    • มี NetGuard แต่ฟีเจอร์อำนวยความสะดวกส่วนใหญ่อยู่หลังการจ่ายเงินเล็กน้อย
      https://netguard.me
    • GrapheneOS อย่างน้อยก็บล็อก ทราฟฟิกอินเทอร์เน็ต ของแอปเฉพาะได้ แต่ทำในระดับช่วงพอร์ตหรือโดเมนเฉพาะไม่ได้
    • น่าเสียดายที่ไฟร์วอลล์จริง ๆ ทั้งหมดต้องใช้ สิทธิ์ root
      ใช้ AFWall+ มานาน การควบคุมว่าแต่ละแอปจะอนุญาตหรือบล็อก Wi-Fi, cellular, LAN นั้นทำได้เรียบร้อยดี เป็น frontend ของ iptables/nftables จึงปรับแต่งกฎได้มากเท่าที่ต้องการ: https://github.com/ukanth/afwall
      ทำงานตั้งแต่ Android 2+
      ถ้าไม่มี root ก็ทำได้แค่โซลูชันแบบ VPN อย่าง Adguard
      ถ้าต้องการสถิติ ก็มี GlassWire เวอร์ชัน Android เคยลองแค่ beta เลยไม่รู้สถานะปัจจุบัน แต่ก็น่าลองดู
    • แอป "Rethink: DNS + Firewall + VPN" มีฟีเจอร์คล้ายกัน
    • AFWall+
      เปลี่ยนมาใช้ตัวนี้จาก NetGuard ที่พูดถึงด้านบน

  • อยากให้มีแพ็กเกจสำหรับ Arch และ OpenSUSE ด้วย

    • Arch Linux มีแพ็กเกจทางการอยู่แล้ว แต่ไม่รู้ด้วยเหตุผลอะไรจึงไม่รวม โมดูล eBPF ต้องไปเอาแยกจาก AUR
    • ใน repo extra ของ Arch มี opensnitch และใน AUR มี opensnitch-ebpf-module

  • เทียบกับของอย่าง UFW แล้วเป็นยังไง? สงสัยว่าแก่นหลักคือ UI สำหรับดู activity ที่กำลังเกิดขึ้นหรือเปล่า

    • OpenSnitch จะถามเมื่อมี network activity
      ถ้าแอปใด ๆ เรียก telemetry อะไรทำนองนั้น ก็เลือก whitelist/greylist ได้ละเอียด เช่น จะอนุญาตเฉพาะการเชื่อมต่อจาก executable นี้ไปยัง address นี้ไหม หรือจะอนุญาต address นี้เสมอไหม และยังมีตัวเลือกระยะเวลา เช่น ครั้งเดียว, 15 วินาที, จนกว่าจะรีบูต
      ถ้าผ่านด่านแรกของการใส่แอปที่ใช้และเชื่อถือไว้ในรายการอนุญาตไปได้ ก็ถือว่าดีมาก และช่วยให้เห็นว่าแอปหรือเกมกำลังทำอะไรที่เราไม่เคยรู้มาก่อน
    • เท่าที่ผมรู้ UFW ไม่ใช่ไฟร์วอลล์ระดับแอป แต่บล็อก/อนุญาตเฉพาะหมายเลขพอร์ตทั้งระบบ

  • มีแผนพอร์ตไป macOS ไหม? เคยใช้ Little Snitch อยู่พักหนึ่ง แต่ชอบ โอเพนซอร์ส มากกว่า ด้วยเหตุผลที่ไม่เกี่ยวกับการจ่ายเงิน

    • ลองใช้ LuLu ดู

  • เคยลองใช้เป็นพัก ๆ หลายครั้ง แต่มี แครชแบบสุ่ม เยอะเกินไป จนใช้งานค่อนข้างลำบาก