Falco เป็นที่รู้จักในฐานะเครื่องมือของ Kubernetes และคู่มือเกี่ยวกับมันแทบทุกฉบับเขียนขึ้นสำหรับคลัสเตอร์ แต่มันไม่ได้ผูกกับคลัสเตอร์: มันเฝ้าดูการเรียกระบบ และบนเซิร์ฟเวอร์ธรรมดาที่มีเว็บไซต์มันก็ทำงานแบบเดียวกันเป๊ะ เพียงแต่แทบไม่มีใครเขียนถึงกรณีนี้

และมันมีประโยชน์ตรงที่เครื่องมืออื่นเงียบ web shell บนเว็บไซต์ไม่ได้ละเมิดสิทธิ์ใด ไม่สร้างการเข้าสู่ระบบที่ล้มเหลว และถ้าเขียนด้วยมือก็ไม่ตรงกับลายเซ็นใด แต่มันมีพฤติกรรมหนึ่งที่ผิดปกติสำหรับเว็บเซิร์ฟเวอร์: กระบวนการของ PHP-FPM รันเชลล์ขึ้นมา และนั่นแหละคือสิ่งที่ Falco เห็น

มันรับรู้อะไรได้บ้าง

เหตุการณ์ตัวแทนบนเซิร์ฟเวอร์ธรรมดา:

  • เชลล์ที่เกิดจากกระบวนการของเว็บเซิร์ฟเวอร์หรือ PHP — เป็นสัญญาณที่ไม่กำกวมของ web shell ในทางปฏิบัติ;
  • โปรแกรมที่รันจาก /tmp, /dev/shm หรือ /var/tmp;
  • การอ่านไฟล์ที่อ่อนไหว (/etc/shadow คีย์ส่วนตัว) โดยกระบวนการที่ไม่เกี่ยวข้องกับมันเลย;
  • การเปลี่ยนแปลงของไฟล์ไบนารีของระบบ;
  • การเชื่อมต่อขาออกจากกระบวนการที่ไม่ควรใช้เครือข่าย

การติดตั้ง

ทางเลือกสำคัญอยู่ที่ตอนติดตั้ง: Falco รับการเรียกระบบมาอย่างไร เส้นทางสมัยใหม่อิง eBPF และไม่ต้องทั้งสร้างโมดูลเคอร์เนลและไม่ต้องมีเฮดเดอร์ของเคอร์เนล:

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

โมดูลเคอร์เนลแบบคลาสสิกต้องการเฮดเดอร์และถูกสร้างใหม่หลังการอัปเดตเคอร์เนลทุกครั้ง — และบนเซิร์ฟเวอร์ที่อัปเดตติดตั้งอัตโนมัติ นั่นคือสาเหตุที่ทำให้บริการตายซ้ำแล้วซ้ำเล่า ถ้าเคอร์เนลใหม่พอ (5.8 ขึ้นไป) ให้เลือก eBPF แล้วลืมปัญหานี้ไปได้เลย

เพื่อให้แน่ใจว่าเหตุการณ์มาถึงจริง:

sudo systemctl status falco
sudo journalctl -u falco -n 50

เสียงรบกวนและการกำจัดมัน

และนี่คืองานหลัก ชุดกฎมาตรฐานเอนเอียงไปทางสภาพแวดล้อมคอนเทนเนอร์ และบนเซิร์ฟเวอร์ธรรมดาส่วนที่เห็นได้ชัดของมันไม่ก็ใช้ไม่ได้เลย ไม่ก็ทำงานตลอดเวลา

กฎที่ให้มา (/etc/falco/falco_rules.yaml) ไม่ควรแก้ไข — เมื่ออัปเดตไฟล์จะถูกแทนที่ การเปลี่ยนแปลงของคุณไปอยู่ใน /etc/falco/falco_rules.local.yaml และกฎที่ไม่ต้องการก็ถูกปิดที่นั่นเช่นกัน:

- rule: Terminal shell in container
  enabled: false

บนเซิร์ฟเวอร์ที่ไม่มีคอนเทนเนอร์ มักต้องปรับอะไรบ้าง:

  • กฎเกี่ยวกับคอนเทนเนอร์ทั้งหมด — ถ้าไม่มีคอนเทนเนอร์ พวกมันก็แค่กินที่ในรายงาน;
  • «Write below etc» — ทำงานทุกครั้งที่ติดตั้งแพ็กเกจและทุกครั้งที่คุณแก้ไฟล์ตั้งค่า มันต้องการข้อยกเว้นสำหรับ apt, dpkg และ unattended-upgrades มิฉะนั้นเหตุการณ์จะมาเป็นน้ำท่วม;
  • «Read sensitive file untrusted» — ทำงานกับเอเจนต์เฝ้าดู เครื่องมือสำรองข้อมูล และเครื่องมือตรวจสอบอย่าง Lynis;
  • การรันจากไดเรกทอรีชั่วคราว — มีข้อยกเว้นที่ชอบธรรมอยู่: การบิลด์แอปพลิเคชัน หรือเบราว์เซอร์อัตโนมัติที่เปิดไดรเวอร์ในไดเรกทอรีชั่วคราว เหตุการณ์เช่นนั้นดูน่ากังวลแต่อธิบายได้ และดีกว่าที่จะเพิ่มข้อยกเว้นสำหรับเส้นทางเฉพาะนั้นทันทีแทนที่จะมานั่งคิดใหม่ทุกครั้ง

ลำดับที่สมเหตุสมผลเหมือนกับเครื่องมือตรวจจับอื่นใด: สัปดาห์แรกให้สังเกตอย่างเดียวและเพิ่มข้อยกเว้น แล้วหลังจากนั้นจึงถือว่าเหตุการณ์ที่โผล่มาคือสัญญาณ และกฎก็ง่าย ๆ — ถ้าในรายงานมีเหตุการณ์ที่คุณไม่อ่านอยู่เป็นประจำ แสดงว่ามันไม่ได้ทำอะไรให้คุณเลย

ควรส่งเหตุการณ์ไปที่ไหน

ผลลัพธ์ถูกตั้งค่าใน /etc/falco/falco.yaml: ไฟล์ เจอร์นัลของระบบ หรือสตรีมไปยังโปรแกรมภายนอก และสำหรับเซิร์ฟเวอร์เครื่องเดียว ไฟล์เดียวพร้อมการหมุนเวียนตามมาก็เพียงพอ — อย่าลืมการหมุนเวียน ไฟล์เหตุการณ์ก็โตเหมือนล็อกอื่นทุกไฟล์และโดยค่าเริ่มต้นไม่มีใครดูแลมัน

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

Falco กับ auditd ไม่ใช่สิ่งเดียวกัน

ทั้งคู่เฝ้าดูการเรียกระบบ แต่ด้วยจุดประสงค์ต่างกัน auditd บันทึกสิ่งที่เกิดขึ้นเพื่อให้ประกอบภาพขึ้นใหม่ได้ภายหลัง: มันไม่ประเมินอะไรและไม่แจ้งอะไร มันเก็บเจอร์นัล ในขณะที่ Falco ใช้กฎในวินาทีที่เหตุการณ์เกิดและบอกว่า «นี่ดูน่าสงสัย» — นั่นคือมันให้สัญญาณ ไม่ใช่บันทึก

และการมีทั้งคู่นั้นสมเหตุสมผล: เจอร์นัลไว้ประกอบภาพและสัญญาณไว้ตอบสนอง ถ้าต้องเลือกอย่างเดียว auditd มีประโยชน์กว่าบนเซิร์ฟเวอร์ที่สิ่งสำคัญที่สุดคือการประกอบลำดับเหตุการณ์ขึ้นใหม่หลังเกิดเหตุ ส่วน Falco เหมาะกับที่ที่ต้องการสัญญาณเตือนแต่เนิ่น ๆ เกี่ยวกับตัวขุดเหรียญที่กำลังทำงานหรือ web shell

มันคุ้มกับที่บนเซิร์ฟเวอร์เล็ก ๆ หรือไม่

คำตอบที่ซื่อสัตย์: ไม่เสมอไป Falco ประมวลผลการเรียกระบบและบนเครื่องที่ยุ่ง ผลกระทบต่อโปรเซสเซอร์ก็รู้สึกได้ และถ้าบนเซิร์ฟเวอร์มีเว็บไซต์เดียวและคุณยังไม่มีทั้งการเฝ้าดูความสมบูรณ์และการอัปเดตอัตโนมัติที่ดี ก็ไม่ควรเริ่มจากสิ่งนี้

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