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

แต่บน Debian และ Ubuntu มาตรฐานมีอยู่แล้ว และมันไม่ใช่ของคุณ: ทุกแพ็กเกจที่ติดตั้งพก checksum ของไฟล์ตัวเองมาด้วย การเทียบกับพวกมันไม่ต้องตั้งค่าและไม่ต้องมีสแนปช็อตล่วงหน้า และใช้ได้บนระบบใดก็ได้ในเวลาใดก็ได้ เครื่องมือนั้นชื่อ debsums

การใช้งาน

sudo apt install debsums
sudo debsums -c

ธง -c พิมพ์เฉพาะไฟล์ที่ไม่ตรงกับมาตรฐาน ถ้าไม่มีมัน ผลลัพธ์จะเป็นรายงานทีละบรรทัดของทุกไฟล์ในระบบ หลายหมื่นบรรทัด

การตรวจใช้เวลาไม่กี่นาทีและสร้างภาระให้ดิสก์ ดังนั้นบนเซิร์ฟเวอร์ที่ใช้งานจริงควรรันด้วยลำดับความสำคัญที่ลดลง:

sudo ionice -c3 nice -n19 debsums -c

อ่านผลลัพธ์อย่างไร

ผลลัพธ์ว่างเปล่าหมายความว่าทุกไฟล์ที่ตรวจตรงกับที่ดิสทริบิวชันติดตั้งไว้ ผลลัพธ์ที่ไม่ว่างต้องดู และสิ่งที่พบแบ่งเป็นสองประเภทที่ต่างกันมาก

ไฟล์ตั้งค่าใน /etc การเปลี่ยนมันคืองานปกติ: คุณแก้ sshd_config ตั้งค่า nginx เพิ่มพารามิเตอร์เคอร์เนล ความต่างเช่นนั้นเป็นสิ่งที่คาดไว้แล้ว เพื่อไม่ให้มันเกะกะ มีโหมดแยกต่างหาก:

sudo debsums -e -c

-e ตรวจเฉพาะไฟล์ตั้งค่า — บางครั้งมีประโยชน์สำหรับดูรายการทุกอย่างที่คุณเปลี่ยนบนเครื่องนี้

ไฟล์ปฏิบัติการและไลบรารี ความต่างใน /usr/bin, /usr/sbin, /bin หรือ /usr/lib คือสิ่งที่การตรวจนี้ถูกรันเพื่อมัน มีสาเหตุที่ชอบธรรมอยู่ แต่ไม่มาก: ไฟล์ถูกแก้ด้วยมือขณะแก้จุดบกพร่อง มีการใช้แพตช์จากบุคคลที่สาม แพ็กเกจกำลังอัปเดตอยู่ระหว่างการตรวจ ถ้าไม่มีข้อไหนตรงเลย ก็ถึงเวลาต้องดูอย่างจริงจัง

เป้าหมายคลาสสิกของการแทนที่คือ ls, ps, netstat, ss, find, sshd เวอร์ชันที่ถูกแทนที่จะซ่อนบรรทัดที่สำคัญออกจากผลลัพธ์ของมัน และการตรวจทุกอย่างของคุณหลังจากนั้นก็เลิกบอกความจริง

ความครอบคลุมไม่สมบูรณ์ — และต้องรู้เรื่องนี้

ข้อจำกัดที่มักไม่ถูกกล่าวถึง: ไม่ใช่ทุกแพ็กเกจที่ส่ง checksum มาด้วย ไฟล์จากแพ็กเกจเช่นนั้นไม่ถูกตรวจเลยและจะไม่ปรากฏในรายงานไม่ว่าในกรณีใด ดูรายการได้แบบนี้:

sudo debsums -l

ดังนั้นรายงาน debsums ที่สะอาดจึงหมายความว่า «ในส่วนที่ถูกตรวจนั้นทุกอย่างเรียบร้อย» ไม่ใช่ «ระบบไม่ได้ถูกแก้ไข» เรื่องเดียวกันใช้กับทุกอย่างที่ติดตั้งนอกตัวจัดการแพ็กเกจ: คอมไพล์จากซอร์ส ดาวน์โหลดมาเป็นไบนารี ติดตั้งด้วยสคริปต์จากเว็บของผู้พัฒนา — debsums ไม่เฝ้าดูสิ่งเหล่านั้นเลยโดยนิยาม และตรงนั้นเองที่ต้องใช้ AIDE

การรันเป็นประจำ

แพ็กเกจมาพร้อมงานสำเร็จรูป ซึ่งเปิดใช้ใน /etc/default/debsums:

CRON_CHECK=weekly

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

ถ้าไฟล์ถูกแทนที่จริง ๆ

แรงกระตุ้นแรกคือติดตั้งแพ็กเกจใหม่เพื่อเอาของเดิมกลับมา:

sudo apt install --reinstall coreutils

คำสั่งถูกต้อง แต่ไม่ใช่ในฐานะการกระทำแรก ไบนารีระบบที่ถูกแทนที่แปลว่ามีคนมี root และการกู้ไฟล์คืนไม่ได้แก้ปัญหานั้น — มันเพียงทำลายร่องรอย ลำดับควรกลับกัน: ก่อนอื่นเก็บสำเนาไฟล์ที่น่าสงสัยพร้อมเวลาที่มันถูกแก้ไข ดูว่าในช่วงเวลาเดียวกันมีอะไรเปลี่ยนอีก ตรวจงาน cron คีย์ SSH และรายชื่อผู้ใช้ แล้วจึงค่อยกู้คืน

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

ตำแหน่งของมันในภาพรวม

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

ตามปกติ ประเด็นไม่ได้อยู่ที่การรันมันแต่อยู่ที่การมีผลลัพธ์ล่าสุดพร้อมวันที่อยู่ตรงหน้า ภาพนั้นเป็นอย่างไรดูได้ที่เดโมด้านล่าง