คู่มือเกี่ยวกับ Suricata แทบทุกฉบับจบลงด้วยการติดตั้ง Elasticsearch, Logstash และ Kibana สำหรับ VPS เครื่องเดียวนั่นเป็นคำแนะนำที่แย่: ชุดนี้จะขอหน่วยความจำสี่กิกะไบต์และการดูแลอย่างต่อเนื่อง ในขณะที่สิ่งที่คุณต้องการมีเพียงการดูว่า IDS จับอะไรได้บ้างในวันที่ผ่านมา Suricata ทำงานได้ดีโดยไม่มีพวกมัน — แต่มันมีคุณสมบัติหนึ่งที่ทำให้ผู้คนติดตั้งแล้วถอนออกในอีกหนึ่งสัปดาห์

กับระเบิดในการตั้งค่าเริ่มต้น

ทันทีที่แกะกล่อง Suricata เขียนเหตุการณ์มากกว่าสามสิบประเภทลงใน eve.json: ไม่ใช่แค่ alert แต่รวมถึงทุกคำขอ DNS ทุก TLS handshake ทุกธุรกรรม HTTP, ARP, DHCP, flow แล้ว flow เล่า บวกกับ stats.log แยกอีกทุกแปดวินาที และในระหว่างนั้น Suricata ไม่ได้ตั้งค่าการหมุนเวียนล็อกให้ — นั่นเป็นงานของผู้ดูแลระบบ และไม่มีที่ไหนเขียนไว้ตัวโต ๆ

ตัวเลขจากเซิร์ฟเวอร์จริง: 15 กิกะไบต์ในสองวัน — เก้าอยู่ใน eve.json และเกือบหกอยู่ใน stats.log เหลือเวลาราวห้าวันก่อนดิสก์เต็ม เซิร์ฟเวอร์เครื่องนั้นก็ไม่ได้มีทราฟฟิกมากด้วย บนโหนดที่ยุ่งเรื่องนี้คงเป็นเรื่องของชั่วโมง

ตรวจของคุณตอนนี้เลย:

sudo du -sh /var/log/suricata/*

เก็บเฉพาะสิ่งที่คุณอ่าน

ถ้าคุณดู alert ไม่ใช่ทำนิติวิทยาศาสตร์เครือข่าย คุณต้องการเหตุการณ์เพียงประเภทเดียวจาก eve-log ใน /etc/suricata/suricata.yaml ให้หาบล็อก outputs แล้วใน types ของ eve-log เหลือไว้แค่ alert แล้วคอมเมนต์ที่เหลือออก และปิดผลลัพธ์สถิติตรงที่เดียวกัน:

  - stats:
      enabled: no

หลังแก้ไข การตรวจสอบไฟล์ตั้งค่าเป็นสิ่งบังคับ — ก่อนเริ่มบริการใหม่:

sudo suricata -T -c /etc/suricata/suricata.yaml -v

ลำดับสำคัญ: การตรวจสอบจะไม่ผ่านถ้ากฎยังไม่ถูกโหลด ก่อนอื่น suricata-update จากนั้นตรวจไฟล์ตั้งค่า แล้วจึงเริ่ม

การหมุนเวียนที่ทำงานจริง

ไฟล์ /etc/logrotate.d/suricata:

/var/log/suricata/*.log /var/log/suricata/*.json {
    daily
    rotate 7
    maxsize 200M
    missingok
    compress
    delaycompress
    create 0664 suricata suricata
    su suricata suricata
    postrotate
        systemctl kill -s HUP suricata
    endscript
}

ตรงนี้มีสองบรรทัดที่ไม่ชัดเจนและทั้งคู่วิกฤต

su suricata suricata — ถ้าไม่มีบรรทัดนี้ logrotate จะข้ามทุกไฟล์อย่างเงียบ ๆ ไดเรกทอรี /var/log/suricata เป็นของกลุ่ม suricata ไม่ใช่ root และ logrotate ถือว่าการจัดวางแบบนี้ไม่ปลอดภัย จะไม่มีข้อผิดพลาดในเมลและไม่มีในล็อก คุณจะเพียงมั่นใจว่ามีการหมุนเวียนอยู่จนกระทั่งดิสก์หมด วิธีเดียวที่จะจับได้ล่วงหน้าคือการรันแบบแห้ง:

sudo logrotate -d /etc/logrotate.d/suricata

create 0664 suricata suricata — สิทธิ์ของไฟล์ใหม่ ด้วยค่าเริ่มต้น (0640) แผงหรือสคริปต์ใด ๆ ที่อ่านล็อกในฐานะผู้ใช้ที่ไม่ใช่ root จะไม่เห็นอะไรเลยหลังการหมุนเวียนครั้งแรก

นอกจากล็อกแล้วควรตั้งค่าอะไรอีก

HOME_NET ตัวนี้บอกว่า Suricata ถือว่าอะไรเป็นของตัวเอง ค่าเริ่มต้นระบุช่วงที่อยู่ส่วนตัวทั้งหมด ในขณะที่ VPS มีที่อยู่สาธารณะ — กฎบางข้อจึงไม่ทำงาน หรือทำงานกลับด้าน ระบุเครือข่ายของคุณเองให้ชัดเจน

กฎ ชุด Emerging Threats Open ถูกดึงมาโดย suricata-update ซึ่งควรอยู่ใน cron วันละครั้ง ลายเซ็นแต่ละตัวที่ส่งเสียงดังถูกปิดด้วยตัวระบุใน /etc/suricata/disable.conf — อย่ากลัวที่จะใช้มัน: ชุดนี้ทำมาสำหรับเครือข่ายองค์กร และบนเว็บเซิร์ฟเวอร์ธรรมดากฎเป็นโหลจะทำงานตลอดเวลาและโดยไม่มีเหตุผล

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

อ่านมันอย่างไรโดยไม่มี Kibana

alert แบบสั้นอยู่ใน /var/log/suricata/fast.log — หนึ่งบรรทัดต่อหนึ่งเหตุการณ์ อ่านด้วยตาได้:

sudo tail -50 /var/log/suricata/fast.log

รายละเอียดอยู่ใน eve.json หนึ่งอ็อบเจ็กต์ JSON ต่อหนึ่งบรรทัด ทุกอย่างที่คนมักติดตั้ง Kibana เพื่อทำนั้นย่อลงเหลือคำสั่งเดียว:

sudo jq -r 'select(.event_type=="alert") | .alert.signature' \
    /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20

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

มี Fail2ban อยู่แล้วจะเอาตัวนี้ไปทำไม

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

เก็บไว้ทั้งคู่ก็ได้ พวกมันไม่ขัดกัน คำถามเดียวคือมีใครอ่านผลลัพธ์ของพวกมันบ่อยกว่าไตรมาสละครั้งหรือเปล่า alert เดียวกันเมื่ออยู่บนหน้าเดียวโดยแยกตามหมวดหมู่และแหล่งที่มาเป็นอย่างไร — ดูได้ที่เดโมด้านล่าง