את 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 מעבד קריאות מערכת והשפעתו על המעבד מורגשת במכונה עמוסה. ואם בשרת יש אתר אחד ועדיין אין לכם לא ניטור שלמות ולא עדכונים אוטומטיים ראויים, לא ממנו מתחילים.

הרגע שלו מגיע מאוחר יותר — אחרי שהבסיס נעשה ונשארת השאלה מה קורה בשרת שהיומנים אינם מראים. ומחלקה אחת של אירועים הוא מכסה טוב יותר מכל השאר יחד: מעטפת שהופעלה על ידי תהליך שרת האתר. איך נראים האירועים מופרדים לפי עדיפות וכלל מראה עמוד ההדגמה למטה.