Snitch – เครื่องมือ ss/netstat ที่ใช้งานคุ้นมือกว่า

 (github.com/karol-broda)
7 คะแนน โดย GN⁺ 2025-12-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Snitch เป็น เครื่องมือตรวจสอบการเชื่อมต่อเครือข่ายที่มนุษย์อ่านได้ง่ายกว่า ss หรือ netstat แบบเดิม โดยรองรับทั้งเทอร์มินัล UI (TUI) และตารางที่จัดรูปแบบอย่างสวยงาม
  • แสดงสถานะการเชื่อมต่อได้ทั้งแบบ หน้าจอโต้ตอบแบบเรียลไทม์ หรือ ตารางที่แสดงผลครั้งเดียวจบ พร้อมตัวกรองหลากหลาย เช่น TCP/UDP, listening, established
  • มีฟีเจอร์ ส่งออก JSON·CSV, แปลชื่อ DNS/ชื่อบริการ, เฝ้าดูและยุติโปรเซส, และ อัปเดตอัตโนมัติ
  • รองรับวิธีติดตั้งหลายแบบ เช่น Homebrew, Go, Nix, Arch Linux, Shell Script, Binary และมีความสามารถ ปลดคำเตือน Gatekeeper ของ macOS อัตโนมัติ
  • เป็นเครื่องมือที่มีประโยชน์สำหรับนักพัฒนาและผู้ดูแลระบบในการ มอนิเตอร์การเชื่อมต่อเครือข่ายอย่างเข้าใจง่าย และนำไปใช้กับสคริปต์อัตโนมัติ

ภาพรวม

  • Snitch เป็นเครื่องมือสำหรับ สำรวจการเชื่อมต่อเครือข่ายในรูปแบบที่มองเห็นได้ชัดเจน โดยออกแบบมาเป็นทางเลือกแทน ss หรือ netstat
  • แสดงสถานะการเชื่อมต่อผ่าน อินเทอร์เฟซ TUI หรือ ผลลัพธ์แบบตารางที่จัดสไตล์
  • ทำงานบน Linux และ macOS และอาจต้องใช้ สิทธิ์ root หรือสิทธิ์ CAP_NET_ADMIN

วิธีติดตั้ง

  • Homebrew: ติดตั้งได้ด้วยคำสั่ง brew install snitch
  • Go: go install github.com/karol-broda/snitch@latest
  • Nix/NixOS: nix-env -iA nixpkgs.snitch หรือเพิ่มเป็น flake input
  • Arch Linux (AUR) : yay -S snitch-bin หรือ paru -S snitch-bin
  • Shell Script: ติดตั้งด้วยคำสั่ง curl -sSL ... | sh โดยพาธเริ่มต้นคือ ~/.local/bin หรือ /usr/local/bin
    • บน macOS สคริปต์ติดตั้งจะ ลบ quarantine attribute อัตโนมัติ
  • ดาวน์โหลด Binary: มีเวอร์ชันสำหรับ Linux (.tar.gz, .deb, .rpm, .apk) และ macOS (.tar.gz) บน GitHub Releases

เริ่มต้นใช้งานอย่างรวดเร็ว

  • รัน snitch เพื่อเปิด TUI แบบโต้ตอบ
  • snitch -l จะ แสดงเฉพาะ listening sockets, ส่วน snitch ls จะ แสดงผลเป็นตารางแล้วจบการทำงาน
  • snitch ls -t -e จะ แสดงเฉพาะเซสชัน TCP ที่ established, และ snitch ls -p จะ แสดงผลแบบเรียบง่ายที่พาร์สได้

คำสั่งหลัก

  • snitch / snitch top : แสดงรายการการเชื่อมต่อที่รีเฟรชแบบเรียลไทม์
    • ตัวเลือก: -l(listening), -t(TCP), -e(established), -i(ช่วงเวลารีเฟรช)
    • ปุ่มลัด: j/k เลื่อน, t/u สลับ TCP·UDP, K ยุติโปรเซส, / ค้นหา, q ออก เป็นต้น
  • snitch ls : แสดงตารางครั้งเดียว และถ้าความสูงเกินหน้าจอเทอร์มินัลจะใช้ pager อัตโนมัติ
    • รูปแบบผลลัพธ์: ตารางปกติ, -o json, -o csv, -p(แบบเรียบง่าย), --no-headers(ไม่แสดงหัวตาราง)
  • snitch json : แสดงผลเป็น JSON เพื่อนำไปใช้ในสคริปต์ได้
  • snitch watch : สตรีมเฟรม JSON ตามช่วงเวลาที่กำหนด
  • snitch upgrade : ตรวจสอบเวอร์ชันและอัปเดตอัตโนมัติ

ตัวกรองและตัวเลือกการแปลชื่อ

  • แฟลกร่วม: -t(TCP), -u(UDP), -l(listening), -e(established), -4(IPv4), -6(IPv6)
  • การแปลชื่อ DNS และชื่อบริการ:
    • รองรับตัวเลือก --resolve-addrs, --resolve-ports, --no-cache
    • ทำ DNS lookup แบบขนานและแคชผลไว้ โดยสามารถปิดแคชได้ด้วย --no-cache
  • การกรองแบบละเอียด: ระบุชื่อโปรเซส พอร์ต สถานะ ฯลฯ ในรูปแบบ key=value
    • ตัวอย่าง: snitch ls proto=tcp state=listen, snitch ls proc=nginx

รูปแบบผลลัพธ์

  • ผลลัพธ์ตารางปกติ: แสดงชื่อโปรเซส, PID, โปรโตคอล, สถานะ, ที่อยู่โลคัล·พอร์ต
  • ผลลัพธ์แบบเรียบง่าย(-p) : ข้อความที่พาร์สได้
  • ผลลัพธ์ JSON/CSV: เหมาะกับงานสคริปต์อัตโนมัติและการวิเคราะห์ล็อก

การตั้งค่าและตัวแปรสภาพแวดล้อม

  • ไฟล์ตั้งค่า: ~/.config/snitch/snitch.toml
    • ตั้งค่า numeric, dns_cache, theme(auto/dark/light/mono) ได้
  • ตัวแปรสภาพแวดล้อม:
    • รองรับ SNITCH_THEME, SNITCH_RESOLVE, SNITCH_DNS_CACHE, SNITCH_NO_COLOR, SNITCH_CONFIG เป็นต้น

ความต้องการของระบบ

  • ต้องใช้สภาพแวดล้อม Linux หรือ macOS
  • Linux: อ่านข้อมูลจาก /proc/net/* และหากต้องการข้อมูลโปรเซสทั้งหมดจะต้องใช้สิทธิ์ root หรือ CAP_NET_ADMIN
  • macOS: ใช้ system API และหากต้องการข้อมูลโปรเซสทั้งหมดต้องใช้ sudo

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

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

 
GN⁺ 2025-12-25
ความคิดเห็นจาก Hacker News
  • ค่าตั้งต้นของ lsof และ ss ใช้งานไม่สะดวกเกินไป
    ในเอาต์พุตเริ่มต้น ss แสดงข้อมูลที่ไม่ค่อยจำเป็นอย่างขนาดคิวรับส่ง แต่กลับไม่แสดงว่า socket นั้นเป็นของแอปพลิเคชันอะไร
    แถมยังละเว้น listening socket โดยค่าเริ่มต้น ทั้งที่นั่นคือสิ่งหลักที่คนใช้เครื่องมือแบบนี้อยากดู
    เข้าใจว่าการเลือกค่าเริ่มต้นที่ดีเป็นเรื่องยาก แต่นี่แทบจะเป็นตัวอย่างของการเลือกผิดแทบทุกอย่าง
    • เห็นด้วยอย่างยิ่ง เครื่องมือแบบ Unix มี ข้อจำกัดเชิงโครงสร้างที่ทำให้รักษาค่าเริ่มต้นที่สมเหตุสมผลได้ยากในระยะยาว
      เมื่อเวลาผ่านไป ผู้ใช้และกรณีการใช้งานก็เปลี่ยนไป ดังนั้นค่าเริ่มต้นก็ควรเปลี่ยนตาม แต่เครื่องมือ Unix มักมีเอาต์พุตที่กลายเป็น API ไปแล้ว พอเปลี่ยนก็เกิด ปัญหา backward compatibility
      ตัวอย่างเช่น ps aux ที่ตัดชื่อโปรเซสยาว ๆ เหลือราว 7 ตัวอักษรก็เป็นเพราะเหตุนี้
      บทความที่เกี่ยวข้อง: sh and the separation of data and representation
    • ตอนนี้เราเข้าใจเรื่อง UX กันลึกซึ้งขึ้นมากแล้ว ตอนที่นักพัฒนาในยุค 70 สร้าง ss หรือ lsof ขึ้นมา ดูเหมือนพวกเขาจะยังไม่ค่อยเข้าใจ ปัญหาด้านการใช้งาน เหล่านี้
    • เครื่องมือ CLI ยุคใหม่ อย่าง fd, ag, rg ก็เจอปัญหาคล้ายกัน
      ผมคิดว่า ความใช้งานได้อย่างเป็นธรรมชาติ สำคัญกว่าความเร็วหรือฟีเจอร์เสียอีก
    • netstat -utan กับ ss -utan ดูเหมือนจะแสดงข้อมูลแทบจะเหมือนกัน
  • เห็นชื่อแล้วตอนแรกนึกว่าหมายถึง Little Snitch เครื่องมือติดตามเครือข่ายบน Mac
    ชื่อซ้ำกันแบบนี้ อาจจะใช้ชื่ออื่นจะดีกว่า
    เว็บไซต์ทางการของ Little Snitch
    • ยังมีโคลนสำหรับ Linux ชื่อ OpenSnitch ด้วย
    • ผมว่าชื่อนี้โอเคนะ ไม่จำเป็นต้องเปลี่ยนเพียงเพราะมี Little Snitch อยู่แล้ว
    • คงยังไม่ถึงขั้นต้องเปลี่ยนชื่อ เพราะ จุดประสงค์การใช้งานต่างกันโดยสิ้นเชิง
      Snitch เป็นแค่เครื่องมือที่ทำให้ข้อมูลจาก ss/netstat ดูง่ายขึ้นในเทอร์มินัล
    • ว้าว เท่มาก ไม่รู้ว่ามี ตัวเลือกทดแทนสำหรับ Windows หรือ Linux ไหม
    • ตอนแรกผมก็นึกแบบนั้นเหมือนกัน ชื่อนี้ทำให้รู้สึกเขินแปลก ๆ
      มีเครื่องมือชื่อคล้ายกันอยู่แล้วในสาย IT แต่ยังจะใช้ชื่อนี้อีกก็ไม่ค่อยเข้าใจ
  • วิธีทำเดโมแบบ recording-as-code น่าสนใจดี
    ลิงก์เดโม
    • ขอบคุณ :) แทบไม่เคยเห็นแนวทางแบบนี้ในโปรเจกต์อื่นเลย
  • ช่วงนี้ดีใจมากที่มี เครื่องมือแบบ TUI เพิ่มขึ้นเรื่อย ๆ โปรเจกต์นี้ก็ดูน่าสนใจมาก เดี๋ยวต้องลองใช้แน่
    • แต่ก็สงสัยว่า TUI จะมี การเข้าถึงสำหรับผู้ใช้ ได้ดีเท่า GUI ไหม
      ไลบรารี GUI มักมีฟีเจอร์ต่าง ๆ สำหรับผู้ใช้ที่มีความบกพร่องทางสายตาและอื่น ๆ แต่ TUI อาจจะยังขาดในจุดนี้
  • ผมชินกับ ss แล้วเลยใช้งานได้ดีอยู่ เพียงแต่ไม่อยากเห็น ตัวเลขคิวรับส่ง
    มันทำให้ความกว้างหน้าจอมากเกินไปจนแทบวางแบบแบ่งครึ่งแนวตั้งบนโน้ตบุ๊กไม่ได้
    ผมคงไม่ติดตั้ง Snitch เพราะ ss มีติดตั้งมาอยู่แล้วบนทุกเซิร์ฟเวอร์ และก็ไม่ต้องการ TUI
    Snitch อาจจะเหมาะกับ การใช้งานส่วนตัวหรือบนเวิร์กสเตชัน แต่บนเซิร์ฟเวอร์ ss คือค่าเริ่มต้น
    • ใช่แล้ว บนเซิร์ฟเวอร์ก็ใช้ ss ที่ติดตั้งมาอยู่แล้วได้เลย
      Snitch เหมาะกับเวิร์กสเตชันหรือการดีบักใน homelab มากกว่า
      ตอนนี้ยังไม่แสดงคิวรับส่ง แต่ภายหลังมีแผนจะเพิ่ม compact mode หรือสวิตช์เปิดปิด
  • ดูดีนะ แต่ผมใช้ iptraf-ng มานานมากแล้ว และยังรู้สึกว่ามันดีกว่านิดหน่อย
    มีฟีเจอร์อะไรที่ผมอาจพลาดไปในวิดีโอเดโมหรือเปล่า?
    • ขอบคุณ! Snitch ใกล้เคียงกับการเป็น ตัวแทนของ ss/netstat มากกว่าจะเป็นเครื่องมือมอนิเตอร์ทราฟฟิก
      ฟีเจอร์มอนิเตอร์ทราฟฟิกมีอยู่ในแผน แต่ยังไม่ได้ทำ
  • ไม่ชอบชื่อเท่าไร แต่การ มอนิเตอร์สถานะการเชื่อมต่อด้วย TUI นี่เข้ากันดีมาก
    • ขอบคุณ อยากรู้เหมือนกันว่าตรงไหนของชื่อที่คุณไม่ชอบ
  • ผมลองติดตั้งด้วย Go แล้วเจอข้อผิดพลาดด้านล่าง 
    go install github.com/karol-broda/snitch@latest
go: github.com/karol-broda/snitch@latest: version constraints conflict:
module declares its path as: snitch
but was required as: github.com/karol-broda/snitch
    • เป็นปัญหาที่เกิดจากการประกาศโมดูลโดยใส่แค่ชื่อ ไม่ได้ใส่ URL แก้ไปเมื่อไม่กี่ชั่วโมงก่อนนี้เอง
      น่าแปลกที่ Go อนุญาต module barename ด้วย สุดท้ายในโปรเจกต์ส่วนตัวก็มักต้องใช้ URL อยู่ดี และผมคิดว่ามันเป็น แพตเทิร์นที่ไม่ค่อยดี
    • แก้แล้ว แต่ยังไม่รวมอยู่ในรีลีส
      ลิงก์คอมมิต
    • ตอนนี้แก้และออกรีลีสเรียบร้อยแล้ว ถ้าบิลด์ด้วย @latest ก็น่าจะทำงานได้ปกติ
  • ผมสงสัยมาตลอดว่าเครื่องมือแบบนี้จะมีประโยชน์แค่ไหนกับ ผู้โจมตีที่มีความชำนาญสูง
    เช่น ถ้ามัลแวร์ถูกออกแบบให้รอช่วงเวลาหนึ่ง หรือสื่อสารกับ C&C เฉพาะตอนที่ผู้ใช้มีการใช้งานเครือข่ายอยู่ ก็น่าจะตรวจจับได้ยาก
    • อย่างน้อยเครื่องมือแบบนี้ไม่ควร parse /proc ตรง ๆ
      เพราะ rootkit แบบ LD_PRELOAD สามารถปลอมผลลัพธ์ของฟังก์ชันใน libc เพื่อซ่อนกิจกรรมได้
      ss ยังพอเชื่อถือได้มากกว่าเล็กน้อย และ Snitch เขียนด้วย Go จึงไม่ได้ใช้ libc ทำให้ อาจทนต่อ rootkit แบบ LD_PRELOAD ได้ดีกว่า
      อย่างไรก็ตาม เครื่องมือแบบนี้ ไม่ได้มีไว้ตรวจจับทราฟฟิกอันตราย แต่มีไว้สำหรับดีบักบนเครื่องโลคัล
      เอกสารอ้างอิง: decloaker, บทความวิจัย arXiv, บทความวิจัย ACM, คำอธิบายโครงสร้าง proc
    • ใช่ Snitch ไม่ได้มีไว้เพื่อการตรวจจับด้านความปลอดภัย แต่ใช้สำหรับการดีบัก/ตรวจสอบบนเครื่องโลคัล
      ผู้โจมตีที่ชำนาญยังไงก็สามารถแฝงตัวไปกับทราฟฟิกปกติได้อยู่ดี
    • เครื่องมือแบบนี้ ไม่ได้ออกแบบมาสำหรับสภาพแวดล้อมที่เป็นปฏิปักษ์
      แม้แต่เครื่องมือเครือข่ายที่ใช้รับมือผู้โจมตีจริง ๆ ก็ยังไม่สมบูรณ์แบบ (คำค้น: bro vantage point problem)
  • อยากได้ฟีเจอร์ที่แสดง อัตราการส่งข้อมูลปัจจุบันและสะสม แยกตามแต่ละ socket/โปรเซส
    ตอนนี้ผมใช้ jnettop อยู่ แต่ไม่ชอบ UI เท่าไร
    • ฟีเจอร์นั้น มีแผนจะเพิ่มในเวอร์ชันถัดไป