זהו מדריך להתקנה, הגדרה ותחזוקה של Arcivéo Security Monitor. הסעיפים מקובצים: סקירה כללית, פריסת הלוח, חיבור כלי אבטחה, מודולים מובנים ואבחון. ניתן להעתיק פקודות באמצעות הכפתור מימין.
התקנת הפאנל מתוארת בעמודים נפרדים שלב-אחר-שלב. בחרו שיטה:
Arcivéo Security Monitor — לוח בקרה לאבטחת השרת. אוסף נתונים מהכלים המותקנים (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco ועוד) ומציג אותם בממשק אחיד עם דאשבורד, מפת התקפות ודפים מפורטים לכל כלי.
המוניטור אינו אמצעי הגנה פעיל — הוא אינו חוסם התקפות בעצמו. תפקידו לרכז מידע מהכלים שכבר פועלים ולהציג אותו בצורה נוחה.
המוניטור פועל מקומית בלבד — יש להתקין אותו על אותו שרת שאותו הוא מנטר. אין SSH או API מרוחק.
את כל הפקודות (fail2ban-client, ufw status, ipset list וכו') הפאנל מריץ בשם משתמש שרת האינטרנט (בדרך כלל www-data, ובפאנלי אירוח — חשבון האתר) עם קבוצת הרשאות מצומצמת של sudo — רק לכלים ספציפיים, ללא גישת root כללית. התוצאות מנותחות ומוצגות בדפדפן.
שני קצבי עבודה. דפי הלוח פונים אל הכלים ברגע הפתיחה — ולכן אתם רואים תמיד את המצב הנוכחי. נוסף על כך פועלות ברקע משימות לפי לוח זמנים (cron):
הרשימה המלאה של המשימות נמצאת בפרק “כל משימות cron במקום אחד”.
הציון מתחיל מהמקסימום ויורד עבור כל בעיה שמזוהה:
PermitRootLogin yes) — −20PasswordAuthentication yes) — −10X11Forwarding מופעל, MaxAuthTries גדול מ-3, או ש-sshd_config קריא לכל החשבונות — −5TRACE מופעלת, או שחסרה הכותרת Strict-Transport-Security או X-Frame-Options — −5סיכום: 80+ = מוגן, 60–79 = לתשומת לב, <60 = בסיכון.
WebAuthn — תקן אימות ללא סיסמה באמצעות מפתח חומרה. תומך ב-YubiKey, Touch ID, Face ID, Windows Hello, Passkey.
לאחר ההתחברות בסיסמה, המערכת מבקשת אישור באמצעות מפתח רשום. גם אם הסיסמה תדלוף — בלי המפתח הפיזי או הביומטריה אי אפשר להתחבר.
להגדרה, פתחו את מפתחות WebAuthn בתפריט הצד ולחצו על “רישום מפתח”. רשמו מיד שני מפתחות: אם המפתח היחיד יאבד או יישבר, לא ניתן יהיה להתחבר לפאנל באמצעותו.
יש ארבעה ערוצים: Telegram, אימייל, webhook והתראות דחיפה בדפדפן. הם בלתי תלויים זה בזה — הפעילו כל אחד מהם, ואפילו את ארבעתם. באותם ערוצים עצמם נשלחים דוח האבטחה היומי, התראות העומס וממצאי חיישן האירועים; הכול מוגדר פעם אחת כאן, בפרק “הגדרות”.
Telegram. נדרשים טוקן של הבוט ו-chat id:
@BotFather ← /newbot ← קבלו טוקן בצורה 123456:ABC....@userinfobot, או פתחו https://api.telegram.org/bot<TOKEN>/getUpdates ומצאו "chat":{"id":...}.אימייל. שתי דרכים לבחירה ב“הגדרות” ← Email:
re_...) ודומיין שולח מאומת.Webhook. כתובת אחת שמקבלת POST מכסה את Slack, Discord, Mattermost, n8n וגם מטפל משלכם. “הגדרות” → Webhook: הדביקו את הכתובת והפעילו את המתג.
{"text": …}, ואל Discord נשלח {"content": …} (Discord דוחה הודעות ארוכות מ-2000 תווים, ולכן הטקסט מקוצר);text, event, severity, source, count, host, ts — אין צורך לפרק שוב את טקסט ההודעה.התראות דחיפה. ההודעה מגיעה ישירות לדפדפן, ואם הלוח נוסף למסך הבית של הטלפון — כהתראת אפליקציה רגילה, בלי בוט ובלי שרת דואר באמצע. “הגדרות” → התראות דחיפה: הפעילו את המתג ולחצו “חברו את המכשיר הזה” בכל מכשיר שאמור לקבל התראות. המונה “מכשירים מחוברים” מראה כמה יש.
סטטוס הדוח: “שים לב” או “תקין”. הכותרת הופכת ל“שים לב” רק בעת בעיה אמיתית או פעולה ממתינה: זוהה איום ClamAV, שינויי קבצים ב-AIDE, אירועים קריטיים של Falco (Emergency/Alert/Critical ב-24 השעות האחרונות), שירות שנפל ב-Monit, נדרשת הפעלה מחדש, פג תוקף SSL (≤14 ימים) או ממתינים עדכוני אבטחה. רעש רקע — ניסיונות SSH של בוטים, כתובות IP שנחסמו ב-fail2ban, התראות Suricata, אזהרות Lynis ובקשות ModSecurity שכבר נהדפו — אינו מעלה את הסטטוס, ולכן מספרים כאלה בדוח אינם משמעם “שים לב” כשלעצמם.
מודולי הניטור המפורטים (Lynis, UFW, ModSecurity, מפת התקפות, AIDE, ClamAV ועוד) נפתחים בעת קיום רישיון בתוקף. בלעדיו לוח הבקרה, ההגדרות והחשבון פועלים, אך המודולים מציגים כרטיס “נדרש רישיון”.
לאחר הרכישה באזור האישי יש ברשותכם קוד הפעלה בפורמט ARCIVEO-XXXX-XXXX-XXXX-XXXX. יש “להפעיל” אותו על הדומיין של הפאנל שלכם — פעולה זו הופכת את הקוד לקובץ רישיון חתום (בלוק [license]), שאותו אתם מדביקים בפאנל.
איך מפעילים (3 שלבים):
my.arciveo.com ← מדור “רישיונות” / “הפעלת רישיון” — העתיקו את הקוד ARCIVEO-….monitor.example.com). לחצו הפעל — המערכת תיצור קובץ רישיון הקשור לדומיין זה ותציג אותו בשדה עם הכפתור “העתק”.הפאנל בודק את המפתח קריפטוגרפית: החתימה, הקישור לדומיין ותוקף הרישיון.
APP_URL שב־config.php והזינו רק את שם המארח — ללא https:// וללא הקידומת www. ההפעלה חד־פעמית: הקוד הופך לרישיון עבור הדומיין שהוזן ואינו ניתן להפעלה חוזרת — אם תטעו בדומיין, המפתח לא יתאים לפאנל שלכם, והקוד ינוצל. לכן הזינו את הדומיין בקפידה.
כל הפרמטרים העיקריים של הפאנל מוגדרים בקובץ יחיד config.php בשורש (לצד התיקייה public/) בעזרת קבועים רגילים define(). הקובץ נוצר בעת ההתקנה; לעריכה ידנית תזדקק לעיתים רחוקות — בעיקר בעת החלפת דומיין, העברה או חיבור למסד נתונים אחר. לאחר כל עריכה הפעל מחדש את PHP-FPM (אחרת בגלל OPcache השינויים לא ייכנסו לתוקף).
הצב את הערכים שלך במקומות המודגשים; את השאר השאר כפי שהוא:
מסד נתונים. פרטי החיבור ל-MySQL/MariaDB:
DB_HOST — מארח מסד הנתונים, כמעט תמיד localhost;DB_NAME — שם מסד הנתונים של הפאנל;DB_USER — משתמש מסד הנתונים (גישה למסד שלו בלבד);DB_PASS — הסיסמה של משתמש זה;DB_CHARSET — קידוד החיבור, השאר utf8mb4.אפליקציה.
APP_URL — הכתובת המלאה של הפאנל (למשל https://monitor.example.com). חייבת להתאים לדומיין שעליו הופעל הרישיון — אחרת המפתח יידחה (ראה סעיף “רישיון”);TIMEZONE — אזור הזמן של PHP: משפיע רק על אופן הצגת התאריכים והשעות בפאנל. על זמן הפעלת משימות ה-cron אינו משפיע — שם חל אזור הזמן של המערכת (ראה “כל משימות ה-cron”).זמן הפעלה. SESSION_LIFETIME — פסק זמן של חוסר פעילות בהפעלה, בשניות (מתגלגל: מתעדכן בעת פעילות). כברירת מחדל 28800 = 8 שעות; לאחר זמן זה של חוסר פעילות הפאנל יבקש להיכנס מחדש. לדוגמה, 3600 = שעה אחת, 86400 = יממה.
תיעוד שגיאות. שגיאות לעולם אינן מוצגות למבקרים, אלא נכתבות ל-logs/php_errors.log — הן נראות בדף “יומני האפליקציה”. את השורות הללו (display_errors=0, log_errors=1, הנתיב error_log) בדרך כלל אין צורך לשנות — ההגדרות נקבעו ישירות בקובץ ואינן תלויות ב-php.ini.
public/), ואצל פאנל זה שורש האתר (DocumentRoot) הוא בדיוק שורש הפאנל, לא public/. הקובץ עצמו אינו “דולף”: ב-.htaccess שבשורש קיים איסור מפורש עליו (Require all denied) — השרת מחזיר 403. גם בלי כלל זה קוד המקור לא היה דולף: זהו PHP — השרת מריץ אותו ולא מחזיר אותו כטקסט. ליתר ביטחון: אל תעלה אותו למאגרים ציבוריים ואל תעביר לתמיכה עם סיסמה אמיתית. הרשאות הקובץ — 640.
הלוח סגור מאחורי כניסה עם סיסמה, ואם מסנן ה-IP מופעל — גם מאחוריו. לתוכנה לא מתאים אף אחד מהשניים, ולכן למערכות חיצוניות יש כניסה משלהן — שתי כתובות לקריאה בלבד המוגנות באסימון. האסימון אינו משנה דבר בשרת: אפשר רק לשלוף איתו נתונים.
הפעלה — “הגדרות” ← “API לקריאה בלבד”: המתג “הפעלת ה-API”; האסימון נוצר אוטומטית בשמירה הראשונה. הכפתור “אסימון חדש” מנפיק אסימון אחר ובאותו רגע מנתק את כל מי שהשתמש בקודם.
/api/status.php — JSON: ציון האבטחה, מצב המודולים, המדידה האחרונה של העומס עם התהליכים הכבדים ביותר, ואירועי האבטחה של 24 השעות האחרונות;/api/metrics.php — אותם מספרים בתבנית הטקסט של Prometheus (מדדי arciveo_*: arciveo_security_score, arciveo_fail2ban_banned, arciveo_cpu_busy_pct וכן הלאה).אם הלקוח שלכם אינו יודע לצרף כותרת, האסימון מתקבל גם כפרמטר — ?token=…. שימו לב שבצורה הזו הוא מגיע ליומן הגישה של שרת האינטרנט, ולכן הכותרת עדיפה.
Prometheus. בלוק מוכן עבור scrape_configs:
api disabled — ה-API כבוי בהגדרות. בקשות שנדחו נכתבות ליומן האפליקציה יחד עם כתובת ה-IP של השולח, ולכן ניסיונות לנחש את האסימון נראים בדף “יומני האפליקציה”.
הלוח מותקן על כל שרת בנפרד ועונה היטב על השאלה “מה שלום המכונה הזו”. על השאלה “מה שלום כל המכונות שלי” הוא אינו עונה — ולכן כל לוח יכול לשלוח סיכום קצר אל האזור האישי, שם השרתים נראים ברשימה אחת.
מה לוקחים באזור האישי my.arciveo.com ← הפרק “השרתים שלי”: שם מונפק אסימון (בצורה fk_…) ומצוינת כתובת המקבל https://my.arciveo.com/api/fleet.php. האסימון הוא אחד לכל חשבון — זהה לכל השרתים שלכם.
מה מגדירים בלוח — “הגדרות” ← “סיכום שרתים”: כתובת המקבל, האסימון, שם השרת (כפי שייקרא ברשימה; אם תשאירו ריק ייבחר הדומיין של הלוח) והמתג “שליחת הסיכום”. הכפתור “שלחו עכשיו” בודק את הקישור מיד, בלי להמתין ללוח הזמנים.
מכאן ואילך הסיכום נשלח דרך cron, כל 15 דקות:
מה בדיוק נשלח: שם השרת והדומיין שלו, מערכת ההפעלה, זמן הפעילות, גרסת PHP; ציון האבטחה; מצב המודולים (UFW, מספר ה-jails של Fail2ban, חסימות היום, האם CrowdSec, Suricata ו-Falco פועלים, איומי ClamAV, שינויי AIDE, מדד Lynis, עדכונים ממתינים, האם נדרשת הפעלה מחדש, ימים עד פקיעת התעודה, מספר הפורטים המסוכנים הפתוחים); המדידה האחרונה של העומס (load, מעבד, זיכרון, דיסק, inodes); מוני האירועים של 24 השעות האחרונות והאירוע הקריטי האחרון. אין בסיכום יומנים, סיסמאות או תוכן קבצים.
sudo crontab -l), ומה עונה הכפתור “שלחו עכשיו”. שגיאות שליחה נכתבות ליומן האפליקציה עם הסימון FLEET — שם יתברר אם האסימון נדחה (HTTP 401) או שהחיבור עצמו כלל לא נוצר.
UFW (Uncomplicated Firewall) — ממשק פשוט ל-nftables/iptables. חוסם את כל הפורטים הנכנסים מלבד אלה שהותרו במפורש. הדף “חומת אש UFW” מציג את הסטטוס ואת הכללים.
ufw enable יש להתיר SSH (ufw allow OpenSSH), אחרת תאבד את הגישה לשרת.
deny אינו נחשב נגיש מבחוץ.
Skipping adding existing rule — זו אינה שגיאה. כך UFW מודיע שכלל זהה כבר קיים ואינו מוסיף אותו שוב. בהרצה חוזרת של ההגדרה האוטומטית (שהיא אידמפוטנטית) זו הודעה שגרתית — אין צורך להגיב.
חוסם אוטומטית כתובת IP לאחר חריגה ממספר ניסיונות הכניסה הכושלים. מנתח את יומני SSH, nginx, Apache ושירותים נוספים.
ההתקנה הבסיסית — למעלה. כאן — תצורת עבודה שמעניקה עשרות jail פעילים ואלפי חסימות: הגדרות כלליות, jail מרכזיים וחסימה אוטומטית של כתובות IP זדוניות מהרשימה ipsum.
הקובץ /etc/fail2ban/jail.local — הגדרות כלליות ו-jail החשובים ביותר:
ignoreip חובה לרשום את ה-IP שלכם ואת הרשתות המהימנות, אחרת אפשר לחסום את עצמכם. אחרי העריכה: sudo fail2ban-client reload.
טעינה אוטומטית של רשימת החסימות ipsum — ל-cron של root (sudo crontab -e): level 1 (100+ אלף IP) נטען אל הסט ipsum, שנחסם בחומת האש (פרטים נוספים — בפרק “רשימת חסימות IPset”):
ipsum — זה מה שהדשבורד קורא (הכרטיס “IPset ipsum”). רמות: levels/1.txt — כיסוי מרבי, levels/3.txt — מדויק יותר (3+ מקורות).
מדוע “מוניטור האבטחה” מחולק לשני אזורים. ההגנה פועלת בשתי רמות, והדשבורד לא מערבב ביניהן:
sshd, apache-*, nginx-* וכדומה) ועבריינים חוזרים זדוניים (jail recidive — אלה שכבר נחסמו כמה פעמים). אלו כתובות IP שבאמת ניסו לפרוץ אליכם — הן על מפת המתקפות וב“ציר הזמן”.ipset ipsum, שנחסמת בחומת האש באמצעות כלל DROP. רוב הכתובות האלה בכלל לא נגעו בשרת שלכם — הן נחסמות מראש; המונה “IPset ipsum” מציג כמה נחסמו באופן מונע.ההבדל פשוט: תגובתי — “אלה תקפו וקיבלו חסימה”, מונע — “אלה נחסמו עוד לפני הניסיון”. בעבר הוזרם ל-recidive באופן מלאכותי list-3 של ipsum (מכאן החלוקה הישנה “recidive מהרשימה”); כעת recidive — רק עבריינים חוזרים אמיתיים, וההגנה המונעת כולה בחומת האש.
ipsum — רשימה ציבורית של כתובות IP זדוניות, מתעדכנת מדי יום. המוניטור מציג את מספר הכתובות שנטענו בלוח הבקרה ובמפת המתקפות ומביא אותו בחשבון בציון האבטחה (−10 אם הרשימה לא נטענה).
הגרסה המינימלית ללא fail2ban — רשימה נפרדת ipsum עם חסימה דרך iptables:
@reboot. אגב כך הפקודה create … -exist מגדירה מגבלה maxelem 300000 (ברירת המחדל 65536 — level 1 לא נכנס, יופיע “Hash is full”):
ipsum, ואם חומת האש מנוהלת על ידי המתקין (VPS חדש — פרופילי “מלאה”/“מוקלת”), מחבר את הרשימה ל-UFW בכלל DROP — התעבורה מכתובות ה-IP הללו נחסמת בפועל. הכלל ממוקם אחרי ESTABLISHED,RELATED, ולכן החיבורים הקיימים (כולל ה-SSH שלכם) לא מתנתקים — נחסמים רק חיבורים חדשים מהרשימה. הרשימה משוחזרת בעת טעינת השירות ipsum-load.service לפני חומת האש (אחרת UFW לא היה עולה), ומתעדכנת בקרון ב-04:00. בשרת שכבר מוגדר (פאנל, חומת אש משלכם) המתקין לא נוגע בחומת האש — שם ipsum נשארת רשימה עבור לוח הבקרה ומפת המתקפות, וכלל ה-DROP מתווסף ידנית לפי הצורך (הגרסה המינימלית עם iptables … --match-set ipsum … -j DROP — למעלה). בהתקנה אוטומטית אין צורך לעשות דבר ידנית.
תחליף מודרני ל-Fail2ban עם threat intelligence קהילתי: חסימות מהקהילה בתוספת כללים משלך. דורש bouncer נפרד ליישום החסימות על חומת האש.
systemctl is-active crowdsec). הפעלה: sudo systemctl enable --now crowdsec; בעת כשל בדוק sudo journalctl -u crowdsec -n 30. אותו כלל לכל שירות בסטטוס “לא פועל” (Suricata, Falco, Monit, MySQL).
stream halted / החסימות אינן מיושמות. זהו מפתח api יתום: ה-bouncer הוסר מ-cscli bouncers list, אך המפתח הישן שלו נשאר ב-/etc/crowdsec/bouncers/*.yaml. רשום מחדש את ה-bouncer והזן מפתח חדש:
AIDE (Advanced Intrusion Detection Environment) יוצר תמונת מצב של מערכת הקבצים, ובכל בדיקה מדווח על שינויים ב־/etc, /bin, /usr. לאחר ההתקנה חובה לאתחל את מסד הנתונים (aideinit).
aideinit הטרמינל תקוע 5–15 דקות על השורה Running aide --init... — זה תקין (חישוב האש של כל מערכת הקבצים, עומס על הדיסק). אל תפסיקו ב-Ctrl+C. אם התהליך “תקוע” אך לא כותב דבר — ייתכן שהוא ממתין לתשובה על בקשה נסתרת Overwrite existing aide.db.new [Yn]? (הקישו Y). לבדיקת פעילות מסשן אחר: pgrep -af aide.
aideinit: “21_aide_spamassassin … printf: invalid number” (return code 20) — באג ידוע במקטע התצורה של AIDE ב-Ubuntu 22.04. המסד לא נוצר. הוציאו את המקטע הפגום וחזרו על הפעולה:
aideinit לא הופעל, או (Ubuntu 24.04) שהתיקייה /var/lib/aide נוצרה במצב 700 ואינה נגישה ל-www-data — נפתר עם sudo chmod 755 /var/lib/aide (ראו הבלוק למעלה). “לא בוצעו בדיקות” = המסד קיים, אך עדיין לא בוצעה בדיקה — זו אינה שגיאה. את התוצאות המוניטור קורא מ־/var/log/aide/aide.log.
/etc/cron.daily/aide הרגיל ב-Ubuntu/Debian החדשים עשוי לא לכתוב את /var/log/aide/aide.log בצורה הנדרשת (וגם aide.wrapper כבר אינו קיים בהם). אמין יותר להוסיף cron משלכם עם --config מפורש — הוא כותב יומן מ-root במצב 644, והמוניטור קורא אותו ללא קבוצות נוספות:
chmod 755 /var/lib/aide ו-cron בדיקה ב-02:00 — אין צורך בכלום ידנית.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
סורק אנטי-וירוס ל-Linux. שימושי במיוחד לבדיקת /var/www אחר PHP-שלים וקוד זדוני.
enable --now? שלוש סיבות אופייניות:
1. בקובץ ההגדרות נותרה השורה Example — clamd מסרב לעלות כל עוד היא קיימת:
2. מסד החתימות לא הורד — clamd לא עולה בלעדיו:
3. פשוט נטען — clamd טוען כ-8 מיליון חתימות לזיכרון תוך 30–60 שנ'. המתן ובדוק: systemctl is-active clamav-daemon (מצב activating ← עדיין נטען).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd רק מחזיק את החתימות בזיכרון, הוא עצמו אינו סורק דבר לפי לוח זמנים. הפאנל מציג את תוצאות הסריקה המתוזמנת, לכן דרוש cron שסורק וכותב יומן. ההתקנה האוטומטית מתקינה עטיפה /usr/local/bin/clamav-scan.sh ו-cron בשעה 01:30 — לאחר ההרצה הראשונה יתמלאו “קבצים שנבדקו” ו“סריקה אחרונה”. להרצה מיידית, בלי להמתין ללוח הזמנים: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) — סורק תוכנות זדוניות לאיומים מבוססי-אינטרנט: PHP-שֶלים, דלתות אחוריות לאתרים, מורידנים. משתמש במנוע של ClamAV ומשלים אותו בחתימות משלו.
maldet --report.
update-rc.d: error: unable to read /etc/init.d/maldet — היא לא מזיקה. maldet אינו משתמש ב-init.d, עדכון החתימות והסריקות מופעלים דרך /etc/cron.daily/maldet. אם למטה מופיע installation completed — הכול הותקן.
apt אלא ב-/usr/local/maldetect, וכאשר open_basedir מופעל, נוכחותו נבדקת דרך shell — ראה סעיף “העמוד ריק למרות שהנתונים קיימים בשרת”.
מערכת רשתית לזיהוי חדירות: מנתחת את התעבורה ברמת החבילות ומכירה אלפי חתימות של מתקפות. משלימה את ModSecurity (שפועל ברמת HTTP, בעוד Suricata פועלת ברמת TCP/IP).
/var/log/suricata/eve.json תחת root עם הרשאה 750 על התיקייה, ושרת האינטרנט (www-data) אינו יכול לקרוא אותה. פתחו את התיקייה למעבר — הקבצים שבתוכה נשארים מוגנים:
יירוט קריאות מערכת דרך eBPF/kernel module וזיהוי חריגות בזמן אמת: shell מתוך nginx, קריאת /etc/passwd על ידי תהליך אינטרנט, כתיבה אל /bin וכדומה.
journalctl -u falco (ללא sudo — דרך הקבוצה systemd-journal). ודא ש‑www-data נמצא בקבוצה זו — ראה “הגדרת sudo” (סעיף 2) בעמוד ההתקנה הידנית.
/etc/passwd, כתיבה אל תיקיות מערכת). אפס אירועים קריטיים ביממה בשרת רגוע — זהו מצב בריא.
journalctl דורשת הרשאות ליומן; כדי שהלוח יראה את האירועים באופן יציב, ההתקנה האוטומטית מפעילה ב‑Falco את file_output ← /var/log/falco/falco.log ומגדירה לשירות UMask=0022 (היומן נקרא על ידי שרת האינטרנט). בהתקנה חדשה אין צורך להגדיר זאת ידנית.
ModSecurity — חומת אש לאתרים (WAF) עבור Apache או Nginx. חוסמת מתקפות ברמת האפליקציה: הזרקות SQL, XSS, מעבר נתיבים, סורקים.
IncludeOptional /etc/modsecurity/*.conf, ואילו החבילה מניחה רק את modsecurity.conf-recommended — הוא אינו נכלל בתבנית *.conf. אם לא תעתיק אותו אל modsecurity.conf, SecRuleEngine נשאר Off: המודול נטען, כללי CRS נטענים, אך התעבורה אינה נבדקת ויומן הביקורת אינו נוצר. המצב הביניים DetectionOnly רק רושם אירועים ליומן מבלי לחסום בקשות — הלוח מציג אותו בצהוב.
גישת הלוח ליומן הביקורת. היומן /var/log/apache2/modsec_audit.log שייך ל-root (הרשאות 640), משתמש הרשת אינו יכול לקרוא אותו. הלוח מקבל את הנתונים דרך עוטף — צרו אותו:
SecRuleEngine האחרונה ללא הזחה: שורות עם הזחה נמצאות בתוך בלוקים של <LocationMatch>/<Directory> (למשל, ניטרול ה-WAF עבור phpMyAdmin) ואינן קובעות את המצב הגלובלי.www-data, וב-HestiaCP מאגר האתר רץ תחת בעל האתר (למשל, admin) — בדקו עם grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.X-Forwarded-For. לסטטיסטיקה נכנסות רק טרנזקציות עם כלל שהופעל: הדירקטיבה SecAuditLogRelevantStatus רושמת ליומן הביקורת כל תגובת 4xx/5xx, ולכן נכנסות לשם גם 403/500 רגילות — הלוח אינו מחשיב אותן כאירועי WAF.---RULES--- נחוץ למקטע “כל הכללים הפעילים” — הלוח מציג לא רק כללים שהופעלו, אלא בכלל את כל כללי ה-CRS שנטענו + מותאמים אישית. שלושת הנתיבים בלולאה for f in … הם המקומות הטיפוסיים לכללי CRS ולתוספות מקומיות; אם אצלכם פריסה אחרת (החבילה מניחה קבצים בספריה משלה, או שהכללים המותאמים אינם ב-/etc/modsecurity/custom-rules.conf), מצאו את הנתיבים האמיתיים בפקודה sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null והציבו אותם ברשימה. אם העוטף ישן (ללא מקטע זה) — המקטע פשוט יציג אזהרה “לא זמין”, שאר העמוד עובד כמקודם.
Auditd (Linux Audit Daemon) מתעד קריאות מערכת ברמת הליבה: כניסות ויציאות, פקודות sudo, ניסיונות אימות כושלים ושינויים בקבצים. המוניטור מציג כניסות, ניסיונות כושלים ופקודות sudo של היום.
ausearch (/usr/sbin/ausearch) ובמידת הצורך מתוך /var/log/audit/audit.log באמצעות הפקודה tail. שניהם חייבים להיות ב-sudoers.
עוקב אחר שירותים (nginx, php-fpm, mysql וכו') ומפעיל אותם מחדש בעת קריסה. יכול לשלוח התראות לאימייל.
monit status. בקובץ /etc/monit/monitrc חייב להיות מופעל ממשק ה-HTTP (בלוק set httpd עם allow localhost), אחרת monit status יחזיר שגיאה.
monitrc השורה set httpd מסומנת כהערה (כברירת מחדל היא מופיעה כ-# set httpd port 2812 …). הסר את סימון ההערה מהבלוק והתר את localhost. (2) httpd מופעל כשלעצמו אינו עוקב אחר דבר — Monit סופר רק את מה שמוגדר בסטנזות check; בלעדיהן הרשימה ריקה גם כשהממשק פועל. תצורת מינימום עובדת:
conf.d מוכן עם httpd על 2812 וסט בדיקות — בהתקנה חדשה אין צורך בהגדרה ידנית.
PSAD מנתח את יומן iptables ומזהה סריקות פורטים ומתקפות רשת, ומקצה לכל מקור רמת סיכון (1–5). משלים את fail2ban ואת Suricata.
psad --Status (נדרש ב-sudoers). ללא תיעוד iptables הדף יהיה ריק — זה תקין כל עוד לא בוצעו סריקות.
Mandatory Access Control מגביל לאילו קבצים ומשאבים תוכנית יכולה לגשת, גם אם נפרצה. ב-Ubuntu/Debian משתמשים כברירת מחדל ב-AppArmor (בדרך כלל כבר מותקן ופעיל).
aa-status (נדרש ב-sudoers). מציג את מספר הפרופילים במצב enforce/complain ותהליכים ללא פרופיל.
“פרופילים טעונים” יותר מ-enforce + complain — זה תקין. ב-AppArmor 4.x (Ubuntu 24.04 ומעלה) נוסף מצב unconfined: הפרופיל טעון בקרנל, אך אינו מגביל דבר. Ubuntu מסמנת כך עשרות פרופילים לתוכניות המשתמשות ב-user namespaces (דפדפנים, לקוחות torrent וכדומה). כשקיימים פרופילים כאלה, הכרטיס “פרופילים טעונים” הופך לענבר ומציג את מספרם — לדוגמה unconfined: 90 מתוך 120 טעונים ו-26 ב-enforce. באמת מגינים רק הפרופילים ב-enforce; ב-Ubuntu 22.04 (AppArmor 3.x) אין מצב זה והמספרים תמיד מסתדרים.
unconfined רק באופן מודע: הם כבויים לא בטעות, אלא כי אחרת עבודת התוכניות עצמן נשברת. פרופילים ב-complain — עניין אחר: שם הכללים כבר כתובים ורק לא מיושמים.
debsums בודק שקבצי החבילות המותקנות תואמים לסכומי הביקורת מהמאגר — מזהה קבצי מערכת בינאריים מוחלפים (משלים את AIDE). בדיקה מלאה נמשכת 1–2 דקות, ולכן מופעלת דרך cron, והלוח קורא את התוצאה מ־data/debsums/debsums.log וממיין אותה לקטגוריות בעצמו (חשובים רק קבצים בינאריים וספריות).
המשימה נכנסת ל־root-cron (sudo crontab -e). העטיפה המוכנה debsums-scan.sh מונחת ב־/usr/local/bin/ (chmod +x; ראה סיכום משימות cron) וכותבת את הדוח בעצמה אל data/debsums/ של הלוח.
העטיפה debsums-scan.sh מאתרת בעצמה את data/ של הלוח — אין צורך לציין נתיב.
/etc/ (קונפיגורציה) וב־/usr/share/ (משאבים) בשרת הם בדרך כלל תקינים — הלוח מסמן אותם בצבע נפרד. מדאיגים שינויים בקבצים בינאריים ובספריות (/bin, /sbin, /usr/lib וכד') — הכרטיס “קבצים בינאריים / ספריות” מציג בדיוק אותם.
ניתן להריץ את Lynis ידנית או דרך cron. יש לשמור את הדוח בתיקייה data/lynis/ של הפרויקט — המוניטור קורא את הקובץ lynis-report.dat.
lynis-scan.sh ברקע ישירות מהפאנל (בלי להמתין ל-cron): מציג “סורק…” ובסיום מעדכן את הדוח בעצמו. לשם כך משתמש הווב צריך שורת sudoers להרצת הסקריפט — תוכנת ההתקנה מוסיפה אותה אוטומטית ל-/etc/sudoers.d/monitor. אם הפאנל הותקן ידנית/מוקדם יותר, הוסיפו אותה עם אותו משתמש שכבר מצוין בקובץ:
על Logwatch לשמור דוחות יומיים בתיקייה data/logwatch/ של הפרויקט בפורמט .txt. המוניטור מציג את הדוח האחרון ואת הארכיון.
ניטור הרשת אינו דורש התקנה — זהו דף מובנה בלוח הבקרה. הוא מציג את מצב הרשת של השרת ממקורות מקומיים:
/proc/net/dev;ip;ss;journalctl -k.שלושת המקורות הראשונים פועלים ללא sudo, ולכן הממשקים, התעבורה, החיבורים והפורטים גלויים מייד. מקטע “אירועי ליבה” משתמש ב-journalctl -k — הוא נקרא דרך הקבוצה systemd-journal (“הגדרת sudo”, סעיף 2), ואין צורך ב-sudo. כדי לבדוק שהכול נגיש למשתמש הרשת:
UFW BLOCK אינן מופיעות כאן — הן בדפים “חומת האש UFW” ו“מפת התקפות”. מקטע ריק עם וי ירוק = ביממה האחרונה לא היו תקלות רשת.
העמוד המובנה מציג שלושה דברים:
df); הסרגל מאדים ב-90%≤;lsblk), רק הממשיים (loop/snap מוסתרים);smartctl).המקום ורשימת ההתקנים פועלים מיד, ללא הגדרה. עבור SMART נדרשת החבילה smartmontools. תהליך ה-Web אינו ניגש ישירות להתקני הדיסק, ולכן ה-SMART נאסף באמצעות cron אל הקובץ data/disk/smart.txt, והלוח קורא אותו.
המשימה נמצאת בקרון של root (sudo crontab -e). עטיפה מוכנה smart-scan.sh ממוקמת ב-/usr/local/bin/ (chmod +x; ראו סיכום משימות cron) וכותבת בעצמה אל data/disk/ של הלוח.
העטיפה smart-scan.sh מאתרת בעצמה את data/ של הלוח — אין צורך לציין נתיב. בתוכה lsblk -e7,11 מחריג loop/cdrom.
הדף מציג את היסטוריית העומס של השרת ב-24 השעות האחרונות — Load Average, ניצול CPU והמתנת I/O, RAM/Swap, תעבורת רשת (קבלה/שליחה), I/O של דיסק (קריאה/כתיבה), ניצול הדיסק וה-inodes, מתארי קבצים פתוחים וחיבורי MySQL, ובנוסף מספר חיבורי ה-TCP והתהליכים הנוכחי. ברירת המחדל היא חלון של 24 שעות: הכפתורים למעלה מחליפים אותו ל7 ימים או ל30 יום.
הנתונים נאספים על ידי cron/collect_metrics.php — אחת ל-5 דקות נכתב תצלום “גולמי” יחיד של המונים (/proc/loadavg, /proc/meminfo, /proc/stat, /proc/net/dev, /proc/diskstats, df/df -i, /proc/sys/fs/file-nr, SHOW GLOBAL STATUS LIKE 'Threads_connected') לטבלת ה-DB system_metrics; את האחוזים והמהירויות הדף מחשב בעצמו לפי ההפרש בין תצלומים סמוכים (ניצול דיסק/inodes/מתארים/חיבורי MySQL — ערכים רגעיים, ללא חישוב מחדש). אין צורך ב-sudo — המקורות נקראים ללא הרשאות root.
שני עומקי שמירה. תצלומי המצב ה“גולמיים” שנלקחים כל חמש דקות חיים יממה (ועוד שעה של מרווח, כדי שגם לנקודה הוותיקה ביותר בגרף יהיה קודמת לחישוב). כל שעה שהסתיימה מקופלת לשורה אחת; סדרה שעתית זו נשמרת 30 יום, והתצוגות “7 ימים” ו“30 יום” קוראות בדיוק אותה. כך חודש של היסטוריה עולה כ-720 שורות במקום כ-8600.
העוטף collect-metrics-all.sh (ראו סיכום משימות ה-cron) מאתר בעצמו את כל מופעי הפאנל המותקנים בשרת ומריץ את cron/collect_metrics.php של כל אחד בשם בעל האתר.
התהליכים הכבדים ביותר. מתחת לגרפים יש שתי טבלאות ובהן חמשת התהליכים שצורכים הכי הרבה מעבד:
שתי הטבלאות מתארות תמיד את 24 השעות האחרונות, גם כשהגרפים מציגים חודש: תצלום של התהליכים קיים רק בשורות של חמש הדקות, והן אינן נשמרות יותר מיממה.
ps, סקריפט ה-PHP שאוסף את הנתונים ושרשרת cron/sudo שמעליו) מוחרגים מהרשימה — אחרת הם היו עומדים בראש כל תצלום: ps ברגע ההפעלה מראה כמעט 100 % מעבד. משימות cron אחרות שרצו באותה דקה כן מופיעות, ובדיוק לשם כך הטבלה קיימת.
התראות עומס (הפרק “הגדרות” ← “התראות עומס”) — בעת חריגה מסף המעבד/הזיכרון/הדיסק/ה-inodes הלוח שולח התראה בכל הערוצים המופעלים (Telegram, אימייל, webhook, התראות דחיפה — אותם ערוצים שבהם נשלח הדוח היומי; אין צורך להפעיל דבר בנפרד עבור ההתראות), ועוד אחת כשהמדד חוזר לתקנו. כל עוד הסף נשמר אין הצפה חוזרת: ההתראה הבאה תגיע רק אחרי מחזור “חזר לתקנו ← חרג שוב”.
collect_metrics.php בכל הרצה (אחת ל-5 דקות) — אין צורך ב-cron נפרד. המצב “כבר התרענו / עדיין לא” נשמר ב-data/alerts_state.json, הספים — בהגדרות הפאנל.
הדוח היומי עונה על השאלה “מה שלום השרת”. החיישן עונה על שאלה אחרת — “מה קרה ממש עכשיו”. כל 5 דקות הוא פונה אל המקורות המהירים ורושם רק את מה שהשתנה מאז הבדיקה הקודמת; הדף “אירועי אבטחה” בתפריט מציג את רשימת הממצאים.
בבדיקות האיטיות — Lynis, debsums, עדכוני חבילות, תוקף ה-SSL — החיישן אינו נוגע: המספרים שלהן משתנים ממילא פעם ביממה והן נשארות באחריות הדוח היומי.
מה הוא מבחין בו — תשעה מקורות:
[Priority: 1] מעלה את הממצא לדרגת קריטי;FOUND חדשות ביומן הסריקה;root (קריטי) וכניסה מכתובת שלא נראתה קודם (אזהרה);כלי שאינו מותקן, או שהלוח אינו מצליח לקרוא את היומן שלו, פשוט שותק — וזו אינה שגיאה ואינה אירוע.
data/secwatch_state.json), וההרצה הראשונה רק כותבת את הסימון הזה. אחרת, ברגע הפעלת המעקב הייתה מגיעה התראה על כל מה שהיומנים צברו במשך חודשים.
הגדרה — “הגדרות” ← “מעקב אחר אירועים”:
23-7 שבמהלכו אזהרות אינן נשלחות.ההתראות נשלחות באותם ערוצים כמו הדוח היומי (Telegram, אימייל, webhook, התראות דחיפה) — אין צורך להפעיל דבר בנפרד. כל הממצאים נרשמים ברשימה בין אם נשלחה התראה ובין אם לא, ונשמרים 90 יום.
רשימת האירועים. מסננים: טווח (24 שעות, 7, 30 או 90 יום), חומרה ומקור; מוצגות 500 הרשומות האחרונות. הכפתור “בדקו עכשיו” מריץ בדיוק את אותה בדיקה ש-cron מריץ — נוח מיד לאחר ההגדרה, כדי לא לחכות חמש דקות; והוא גם מציין את הסיבה כשלא נשלחה התראה (“מתחת לסף החומרה”, “שעות שקטות”, “לא הוגדר אף ערוץ התראות”). המונה האדום ליד פריט התפריט הוא מספר האירועים הקריטיים ב-24 השעות האחרונות.
כרטיס הכתובת. לחיצה על שורה ברשימת האירועים או בבלוק כתובות מקושרות פותחת את כל מה שידוע על כתובת אחת: ציר הזמן של האירועים שלה, המדינה ובשורה הראשונה מסקנה. שורה ברשימה פותחת את הכרטיס כאשר האירוע נוגע לכתובת אחת בדיוק; אם יש כמה, הקישורים הם הכתובות שבתוך השורה. יש ארבע מסקנות:
מתחת לציר הזמן נמצא הבלוק מה קרה בשרת באותו זמן: אירועים שאין להם כתובת כלל. AIDE אינו יודע מי שינה את הקובץ, ClamAV אינו יודע מי הביא את הנגוע. מוצגים אלה שנפלו בזמן הפעילות של הכתובת ובשש השעות שאחריה. דווקא הכניסה יחד עם מה שבא אחריה היא שמפרידה בין ניסיון לבין גישה ממשית.
לוח זמנים. המשימה נכנסת ל-crontab של root (sudo crontab -e), בהיסט של 2 דקות מאיסוף המדדים, כדי שהשתיים לא יתחילו יחד:
php cron/security_watch.php. ה-wrapper מוצא את כל התקנות הלוח בשרת ומריץ את הבדיקה בשם בעל האתר — עם אותן הרשאות sudo שהלוח משתמש בהן מן הרשת. קריאה ישירה מ-crontab של root תיצור את קובץ המצב data/secwatch_state.json בבעלות root, והכפתור “בדקו עכשיו” בלוח יפסיק לעבוד.
הדף “שרת אינטרנט” מנתח את יומן הגישה ומראה כמה בקשות היו, איזה חלק מהן הסתיים בשגיאה ומי שלח אותן. ModSecurity עונה על השאלה “מה נחסם”, והדף הזה עונה על השאלה “מה בכלל הגיע אל האתר”.
מה נראה כאן: מספר הבקשות, RPS, שיעור השגיאות, מונה נפרד ל-5xx ונפח התעבורה שנשלחה; גרף בקשות לפי שעות; התפלגות הקודים 2xx/3xx/4xx/5xx; כתובות נפוצות, כתובות IP נפוצות, שגיאות נפוצות (קוד ונתיב) ולקוחות (User-Agent). הטווח: 24 שעות או 7 ימים.
המקור הוא יומן הגישה בתבנית combined, ולכן מתאימים גם Nginx וגם Apache, ואין צורך במודול נוסף. הלוח מחפש את היומן בין הקבצים התקניים:
/var/log/nginx/access.log/var/log/apache2/access.log/var/log/apache2/other_vhosts_access.log/var/log/httpd/access_logמלבדם, הלוח בודק גם קבצים בשם *access*.log ו-*requests*.log בתיקיות /var/log/nginx/, /var/log/apache2/ ו-/var/log/httpd/. כך נמצא גם יומן שאתר כותב לקובץ משלו בהנחיה CustomLog — למשל arciveo-monitor_requests.log, שיוצר המתקין של Arcivéo.
נקרא יומן אחד בלבד: כאשר Nginx עומד לפני Apache, חיבור שני יומנים היה סופר כל בקשה פעמיים. הלוח לוקח את היומן הראשון ברשימה שלמעלה שנכתב אליו ביממה האחרונה (הקבצים שנמצאו לפי תבנית שם נבדקים אחריו, מהחדש לישן); אם לא נכתב לאף אחד במשך יממה, נלקח היומן הלא־ריק העדכני ביותר. לכן יומן שרוקן על ידי logrotate או שנשאר משרת אינטרנט שהופסק כבר אינו מסתיר את היומן הפעיל. נקרא החלק האחרון של היומן (3 מ״ב) והתוצאה נשמרת במטמון ל-5 דקות — ולכן באתר עמוס ייתכן שהטווח שנבחר לא יכוסה במלואו; הכיסוי בפועל רשום מעל הגרף.
adm, ומשתמש הרשת אינו חבר בה. המתקין של Arcivéo מוסיף אותו לקבוצה זו; אחרי התקנה ידנית יעזור wrapper קטן של root שמותר לו דבר אחד בלבד — להציג את היומן (דף ModSecurity פועל באותו אופן). ה-wrapper בוחר את היומן לפי אותם כללים כמו הלוח. הפקודה מוצגת בדף עצמו; והנה היא גם כאן. הדביקו אותה במלואה — זו פקודה אחת:
משתמש הרשת עשוי להיות שונה מ-www-data — בדקו תחת איזה משתמש רץ מאגר ה-PHP-FPM של האתר (ps -o user= -C php-fpm) והכניסו אותו לשורת ה-sudoers. אם שם היומן אינו מכיל לא access ולא requests, הוסיפו את הנתיב שלו בתחילת השורה L=… בתוך ה-wrapper.
ניסיונות לנצל פרצות מוכרות. הפאנל משווה את הבקשות ביומן לחתימות של כעשרים ניצולים נפוצים: PHP-CGI, מעבר בין תיקיות ב-Apache, PHPUnit, Log4Shell ופרצות בנתבים, במצלמות ובשערי VPN. לכל ניסיון הוא עונה אם הוא יכול להצליח בשרת הזה, על סמך עובדות: הגרסאות המותקנות של Apache ו-PHP, האם Java קיימת, וקוד התגובה של השרת לבקשת הקובץ. באדום מסומן רק מה שבאמת יכול להצליח.
הקשחת שרת האינטרנט. הפאנל פונה לכל אתר בשרת דרך 127.0.0.1 ובודק מה מקבל המבקר: האם נראות הגרסאות של שרת האינטרנט ו-PHP, האם שיטת TRACE מופעלת, והאם קיימות כותרות ההגנה Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy ו-Content-Security-Policy. האתרים נלקחים מהכתובת שבה נפתח הפאנל ומקובצי המארחים הווירטואליים, אם הפאנל יכול לקרוא אותם. התוצאה מתעדכנת כל 10 דקות.
אם משהו חסר, מופיעה מתחת לטבלה פקודה אחת. היא יוצרת קובץ נפרד, zz-arciveo-hardening.conf, וטוענת מחדש את שרת האינטרנט רק אחרי שבדיקת התצורה עברה; כותרות שהאתר כבר שולח בעצמו אינן מוכפלות. CSP אינו מוצע כשורה אחת: את המדיניות בונים לכל אתר בנפרד, אחרת הוא יפסיק לטעון את הסקריפטים, הסגנונות והגופנים שלו. ביטול השינוי ב-Apache:
ServerSignature) אינה מסומנת אם גרסת שרת האינטרנט כבר מוסתרת: בלי הגרסה היא מציגה רק את שם השרת ואת שם המארח.
העמוד “מפת התקפות” מזהה את המדינה לפי כתובת IP באמצעות הפקודה geoiplookup. ללא חבילת GeoIP המדינות לא יזוהו והנקודות לא יופיעו על המפה:
/usr/share/GeoIP/GeoIP.dat קריא לכולם, והתוצאות נשמרות במטמון ב-tmp/geoip_cache.json. המפה עצמה (Leaflet + אריחי OpenStreetMap) נטענת בדפדפן — נדרש חיבור אינטרנט במחשב שבו פתוח הלוח.
שני כרטיסים מובנים בלוח הבקרה שמציגים לא “מופעל/כבוי” של הכלי, אלא את רמת ההגנה האמיתית של השרת. אינם דורשים התקנה ונקראים מקומית ללא sudo.
חשיפה חיצונית — כמה שירותים מאזינים על כל הממשקים (0.0.0.0/[::]) וזמינים מבחוץ. מסומן באדום אם מסדי נתונים או מטמון בולטים החוצה (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) — זו פרצה ישירה (−10 לציון האבטחה). מקור: ss -tuln.
127.0.0.1 (bind-address בהגדרות MySQL/PostgreSQL, bind 127.0.0.1 ב־Redis) או סגרו את הפורט ב־UFW.
127.0.0.1 (loopback) גלוי רק לשרת עצמו — מבחוץ אי אפשר להגיע אליו, גם אם הפורט “פתוח”. לכן Postfix בפורט 25 הקשור ל־loopback הוא בטוח: ההגדרה האוטומטית מציבה inet_interfaces = loopback-only (בתוספת smtpd_banner ניטרלי — סוגר את הערת Lynis MAIL-8818 על חשיפת גרסה). הכרטיס “חשיפה חיצונית” סופר כחשיפה החוצה רק את מה שמאזין על 0.0.0.0/[::]; שירותי loopback אינם נכללים.
/etc/postfix/main.cf הגדירו smtpd_banner = $myhostname ESMTP (ללא גרסה ומערכת הפעלה) ו־inet_interfaces = loopback-only, ולאחר מכן sudo systemctl restart postfix.
עדכוני אבטחה — כמה תיקוני אבטחה ממתינים להתקנה והאם נדרשת הפעלה מחדש לאחר עדכון הליבה (−5 לציון האבטחה כשקיימים תיקונים). מקור: /usr/lib/update-notifier/apt-check, קובץ /var/run/reboot-required. רשימה מפורטת — בעמוד “עדכוני אבטחה”.
update-notifier-common). אם apt-check חסר — המוניטור סופר תיקונים דרך apt-get -s upgrade.
עדכוני אבטחה אוטומטיים (unattended-upgrades) — בעמוד “עדכוני אבטחה” כרטיס נפרד מציג האם ההתקנה האוטומטית של תיקוני אבטחה מופעלת ומתי הופעלה בפעם האחרונה. אין צורך ב־sudo — הסטטוס נקרא דרך apt-config dump.
גיבוי הוא ביטוח החשוב מכול: אובדן נתונים מסוכן מכל פריצה. צריך שני דברים — גיבוי של השרת/האתרים ובנפרד גיבוי של מסד הנתונים של הפאנל (שם המשתמשים, מפתחות WebAuthn, ההגדרות והרישיון).
אפשרות A — HestiaCP: לשונית Backup אצל המשתמש ← לחצן יצירת גיבוי (או לפי לוח זמנים בהגדרות השרת). הגיבוי כולל את האתרים ואת מסדי הנתונים שלהם.
אפשרות B — ידני (cron): דאמפ של מסד הנתונים + ארכיון של תיקיית data/ של הפאנל:
עדכון לגרסה חדשה. תחילה בצעו גיבוי. לאחר מכן העלו מחדש את קובצי הקוד, תוך שמירה על הנתונים שלכם:
public/, includes/, assets/, cron/, database/, וכן קובצי .htaccess בשורש (בקר החזית — אין להשאיר את הניתוב מהגרסה הישנה), manifest.json, sw.js;config.php (נתוני מסד הנתונים), data/ (דוחות), logs/, tmp/ (הפעלות ומטמון).SSH_FX_PERMISSION_DENIED — Permission denied. קבצי הפאנל שייכים ל-www-data (כך הוגדרו בהתקנה), בעוד לקוח ה-SFTP מתחבר עם המשתמש שלכם, שאין לו הרשאת כתיבה. מסירת כל הפאנל ל-www-data “כדי שיעבוד” היא בדיוק מה שמוביל לשגיאה הזו; להלן שלוש דרכים, כל אחת מהן פותרת את הבעיה.
data/ (דוחות), tmp/ (הפעלות ומטמון), logs/; הן נשארות בבעלות www-data. השאר הוא קוד, ושרת האינטרנט זקוק לו לקריאה בלבד, שאותה מעניקה הקבוצה www-data עם הרשאות 644. יתרון נלווה: עם חולשה ב-PHP כבר לא ניתן לדרוס את קבצי הפאנל. בפאנלים של אירוח (HestiaCP ודומיהם) אפשרות A אינה נחוצה: שם קובצי האתר ממילא שייכים לחשבון שאיתו אתם מתחברים ב-SFTP, ושרת האינטרנט קורא אותם דרך הקבוצה.
chmod נוסף על הקבצים מאפס את מסכת ה-ACL, והגישה נעלמת בשקט. אם אחרי “סידור ההרשאות” ההעלאה נתקלת שוב ב-Permission denied — הריצו שוב את שתי הפקודות setfacl.
2 באפשרות C הוא setgid: קבצים שהועלו ב-SFTP נשארים בקבוצה www-data, אחרת הפאנל לא יוכל לדרוס אותם. אחרי אפשרות C התחברו מחדש ב-FileZilla — הקבוצה החדשה נכנסת לתוקף רק בכניסה חדשה. בדיקה: id deploy (צריכה להופיע הקבוצה www-data) ו-ls -ld /path/to/monitor (drwxrwsr-x — האות s פירושה ש-setgid מוגדר).
העברה לשרת אחר:
config.php, data/.mysqldump בישן ← ייבוא בחדש; עדכנו את נתוני מסד הנתונים ב-config.php.adm, משימות cron.הפאנל כבר פועל, ובאותו שרת דרוש אתר נוסף — עם דומיין משלו לצד המוניטור. אחרי ההתקנה האוטומטית השרת הוא Apache + PHP-FPM רגיל, ולכן לאתר דרושים שלושה דברים: תיקייה משלו, vhost משלו ותעודה משלו. בפאנל לא נוגעים: הוא מנטר את השרת כולו, ואין צורך בעותק שני עבור הדומיין השני.
site2.example.com הוא הכתובת של האתר החדש. זה יכול להיות גם דומיין נפרד (mycompany.com) וגם תת-דומיין (shop.mycompany.com) — עבור Apache אין הבדל, שונים רק רשומת ה-DNS (שלב 1) והנפקת התעודה (שלב 5). site2 הוא רק שם קצר של האתר: כך נקראים התיקייה /var/www/site2 וקובץ התצורה site2.conf. אין לו כל קשר לדומיין, Apache לוקח את הכתובת רק מ-ServerName; השם יכול להיות כל דבר — למשל עבור shop.mycompany.com נוח לבחור shop: תיקייה /var/www/shop, תצורה shop.conf.
1. DNS. בפאנל ה-DNS אצל רשם הדומיין צרו רשומת A אל כתובת ה-IP של השרת הזה:
אחרי כמה דקות בדקו: dig +short site2.example.com אמור להחזיר את ה-IP של השרת.
2. תיקיית האתר.
3. ה-vhost. הבלוק מודבק לטרמינל בשלמותו — הנתיב אל סוקט PHP-FPM מזוהה מעצמו:
4. הפעילו את האתר ובדקו את התצורה לפני טעינה מחדש:
5. SSL. certbot כבר הותקן על ידי ההתקנה האוטומטית; בשלב זה ה-DNS כבר צריך להצביע אל השרת:
דומיין שלישי והבאים אחריו מתווספים באותו אופן — חזרו על שלבים 1–5 עם דומיין ותיקייה אחרים.
Host אינו תואם לאף ServerName (כניסה לפי IP או דומיין זר שמכוון לשרת שלכם), Apache מגיש את האתר המופעל הראשון לפי סדר האלפבית מתוך /etc/apache2/sites-enabled/. את אתר ברירת המחדל 000-default ההתקנה האוטומטית משביתה, ולכן התפקיד ה“תורן” נשאר אצל ה-vhost של הפאנל (arciveo-monitor.conf) — על אתרים שנפתחים בשמם שלהם אין לכך השפעה. אם ברצונכם שדרך ה-IP ייפתח אתר אחר, קראו לקובץ שלו בשם שיבוא ראשון לפי האלפבית (למשל 000-site2.conf).
site2_error.log ו-site2_access.log בתיקייה /var/log/apache2/.
.htaccess משלו (בקר קדמי), ואתר מקונן יגיש משהו אחר ממה שאתם מצפים. החזיקו את האתרים זה לצד זה: /var/www/monitor, /var/www/site2.
אם אינך מצליח להתחבר — הכול ניתן לתיקון ישירות במסד הנתונים מהשרת. פתח את מסד הנתונים (השם — מתוך config.php):
אבד מפתח WebAuthn (הגורם השני אינו עובר) — כבה 2FA, התחבר עם סיסמה ורשום מפתח חדש:
שכחת את הסיסמה — הגדר גיבוב חדש (צור אותו בשרת והחלף):
חסמת את עצמך במסנן IP — בטל את ההגבלה:
sudo mysql בשרת, או phpMyAdmin / מדור מסד הנתונים בלוח הבקרה של האחסון. לאחר השחזור הפעל מחדש את WebAuthn ואת מסנן ה-IP.
סיכום המשימות נמצא בcrontab של root בשרת (מתווספות דרך sudo crontab -e). השאירו רק את השורות של הכלים שאתם משתמשים בהם; התאימו את הנתיבים לשרת שלכם.
sudo crontab -l ושירות cron פעיל.
TIMEZONE מתוך config.php. הקבוע TIMEZONE משפיע רק על PHP (כיצד הלוח מציג תאריכים), אך דמון ה-cron מריץ משימות לפי שעון המערכת של מערכת ההפעלה. אם אזור הזמן של השרת לא תואם לשלכם, הדוח של “08:00” יגיע בזמן אחר. דוגמה: השרת נמצא באזור זמן אחר (Europe/Berlin, UTC+2), ואתם בירושלים (UTC+3) → הדוח של “08:00” יגיע ב-09:00 לפי הזמן שלכם. בדקו ובמידת הצורך התאימו את אזור הזמן של המערכת לשלכם:
0 8 * * * תופעל ב-08:00 לפי הזמן המקומי. אחרת היה צורך להזיז את ה-cron עצמו, אך במעבר לשעון חורף/קיץ ההיסט שוב יסטה — לכן נכון יותר להגדיר את אזור הזמן של המערכת.
crontab.txt) נמצאים בתיקייה system/ ליד הפרויקט, מחוץ ל-public_html. זה לא חלק מהאתר — אין צורך להעלות אותם לשורש האתר; מקמו אותם על השרת בנתיבי המערכת (כמו ב-crontab שלמעלה):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — מריץ lynis audit system, בזמן הסריקה מציב את הדגל /tmp/lynis-running ומעתיק את lynis-report.dat אל data/lynis/ של הלוח;logwatch_daily.sh → /usr/local/bin/ (chmod +x) — יוצר דוח Logwatch יומי (sshd, fail2ban, sudo, postfix) אל data/logwatch/;smart-scan.sh → /usr/local/bin/ (chmod +x) — קורא את מצב הדיסקים (smartctl) אל data/disk/;debsums-scan.sh → /usr/local/bin/ (chmod +x) — בודק שלמות חבילות (debsums) אל data/debsums/;clamav-scan.sh → /usr/local/bin/ (chmod +x) — סריקת אנטי־וירוס של ClamAV בנתיבים מסוכנים (web, home, temp); כותב סיכום אל /var/log/clamav/scan.log, שממנו קורא אותו עמוד ClamAV (שורת 01:30 ב-crontab שלמעלה);load-ipsum.sh → /usr/local/bin/ (chmod +x) — מעדכן את סט ה-ipset ipsum (level 1) במקום, בלי לשבור את כללי חומת האש הפעילים (שורת 04:00 ב-crontab למעלה);daily-report-all.sh → /usr/local/bin/ (chmod +x) — מריץ את דוח cron/daily_report.php של הלוח (שורת 08:00 ב-crontab שלמעלה);daily_report.php — כבר כלול בלוח (cron/daily_report.php), מופעל דרך daily-report-all.sh, אין צורך להתקין בנפרד;collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — מריץ את cron/collect_metrics.php של הלוח (עמוד “ביצועים”, שורת */5 ב-crontab שלמעלה); collect_metrics.php כבר כלול בלוח, אין צורך להתקין בנפרד;security-watch-all.sh ← /usr/local/bin/ (chmod +x) — מריץ את cron/security_watch.php של הלוח בשם בעל האתר (הדף “אירועי אבטחה”, השורה 2-57/5 ב-crontab שלמעלה); security_watch.php כלול כבר בלוח ואין צורך להתקינו בנפרד;fleet-push-all.sh ← /usr/local/bin/ (chmod +x) — שולח את סיכום השרת אל האזור האישי דרך cron/fleet_push.php של הלוח (השורה 3,18,33,48 שלמעלה);crontab.txt (system/cron/) — דוגמת משימות; את השורות הדרושות הזינו דרך sudo crontab -e./usr/local/bin/. אי אפשר לכתוב לשם ישירות מ-FileZilla — התיקייה בבעלות root, ולקוח ה-SFTP יקבל SSH_FX_PERMISSION_DENIED. סדר הפעולות: תחילה העלו את הקובץ ל-/tmp (לשם כולם יכולים לכתוב), ואז העבירו אותו למקומו בפקודה אחת:
/tmp בשורש השרת — לא /var/tmp ולא tmp/ בתוך הלוח עצמו (האחרון בבעלות www-data וסגור בפני המשתמש שלכם). בעץ של FileZilla /tmp הוא ענף ברמה העליונה, ליד var, ולא בתוכו.
/usr/local/bin/, יומן — /var/log/arciveo-cron.log) — אין צורך לעשות דבר ידנית.
/home/*/web/*/public_html ו-/var/www/*, ומניחים את הדוחות ב-data/ שלהם. אם הלוח נמצא בנתיב אחר — הוסיפו אותו לשורה for app in … בתוך הסקריפטים, אחרת דוחות Lynis/SMART/debsums/Logwatch לא יגיעו ללוח.
logs/cron.log יוצר ראשון cron של root — הוא יהיה בבעלות root, ולשונית “יומן cron” בלוח לא תוכל לקרוא אותו ולא לנקות אותו. צרו את הקובץ מראש בשם משתמש הרשת (הבעלים של תיקיית האתר; ב-HestiaCP זהו החשבון, למשל admin) — כך cron של root רק יוסיף לו, בלי לשנות את הבעלים:
stat -c %U /path/to/monitor.
sudo crontab -e), אחרת היא תרוץ פעמיים.
sudo crontab חשוף (זו הייתה הסלמה ישירה ל-root על ידי כל מי שיקבל גישה להפעלת הלוח), אלא סקריפט צר עם שתי פקודות (list/set), הנוגע רק בבלוק שלו בין הערות השירות. התקינו פעם אחת:
www-data — בדקו תחת איזה משתמש רץ מאגר ה-PHP-FPM של האתר (ps -o user= -C php-fpm), והציבו אותו בשורת sudoers.
public/crontab_monitor.php הועלה ב-FTP/SFTP תחת משתמש מערכת אחר (למשל root) מזה של שאר קבצי האתר, שרת הרשת לא יוכל לקרוא אותו. השוו את הבעלים וההרשאות לקובץ סמוך והתאימו:
המוניטור מזהה את הימצאות הכלים באמצעות dpkg-query — מסד החבילות של APT. אם הכלי לא הותקן דרך apt (ידנית, מ-snap או מקוד המקור), dpkg לא רואה אותו.
שגיאה 500 — בדקו את יומני PHP, nginx והמוניטור עצמו:
www-data, אלא תחת חשבון המשתמש (למשל admin — הבעלים של תיקיית האתר). את כל כללי sudo וחברות בקבוצות (adm, systemd-journal) צריך להגדיר למשתמש הזה, אחרת המודולים יציגו “לא פעיל / 0” בזמן ששירותים פועלים. לבירור משתמש PHP האמיתי: ps -o user= -C php-fpm | sort -u או הבעלים של תיקיית האתר stat -c '%U' /path/to/monitor. בהמשך בכל הפקודות למטה הציבו אותו במקום www-data. ההתקנה האוטומטית מזהה את משתמש הרשת בעצמה ומגדירה עבורו את sudoers.
הנתונים לא מוצגים — כמעט תמיד הרשאות sudo שלא הוגדרו. בדקו את הפקודה הספציפית בשם משתמש הרשת (החליפו את www-data בשלכם). הדגל -n = ללא סיסמה, כמו ב-PHP — אם מבקש סיסמה, סימן שאין כלל ב-sudoers:
sudo aa-status בטרמינל מציג פרופילים, ועמוד “AppArmor” — “לא פעיל”). הסיבה: למשתמש הרשת אין הרשאת sudo לפקודה של המודול הזה. בדקו אותה מהרשימה למעלה: אם מבקש סיסמה — הוסיפו את השורה החסרה אל /etc/sudoers.d/monitor (“הגדרת sudo”). פקודות “חדשות” נפוצות: /usr/sbin/aa-status (MAC), /usr/sbin/psad --Status (PSAD).
apache2ctl, ausearch, aa-status או ss, או שמשתמש הרשת אינו בקבוצות adm/systemd-journal (משם נקראים יומני fail2ban/auth/modsec ו-journalctl — Falco ואירועי ליבה).
סימפטום: בשרת יש נתונים (נראים דרך shell), אבל הדף מציג “אין נתונים” או סטטוס שגוי — לדוגמה AIDE מציג “לא מאותחל”, למרות שהמסד נוצר.
הסיבה היא open_basedir: פאנלים ואירוחים רבים מגבילים את מאגר PHP-FPM לתיקיית הדומיין, ולכן פונקציות PHP file_exists(), file_get_contents(), filemtime() לנתיבי מערכת (/var/lib/aide, /var/log, /proc…) נחסמות. המוניטור עוקף זאת בכך שהוא קורא נתיבים אלה באמצעות פקודות מערכת רגילות (cat, test, stat).
open_basedir. הפתרון הנכון הוא קריאה באמצעות פקודות מערכת (כבר בוצע עבור AIDE ומוניטור הרשת). אין צורך להרחיב את open_basedir אל /var, /proc וזה גם פחות בטוח.
המוניטור בודק תעודות בכך שהוא מתחבר לדומיינים ישירות דרך פורט 443. אם הדומיין אינו נגיש מהשרת עצמו או שהפורט חסום על ידי חומת האש — הבדיקה תיכשל.
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) ושל Apache (/etc/apache2/sites-enabled/) בתוספת המארח הנוכחי מתוך HTTP_HOST.
המוניטור מתחבר ל-MySQL תחת המשתמש מ-config.php, שיש לו גישה רק למסד שלו. MySQL מציג ב-information_schema רק מסדים שיש עליהם הרשאות — ולכן היתר אינם נראים.
כדי שהמוניטור יראה את כל מסדי הנתונים, העניקו למשתמש זה הרשאת קריאה בלבד (פעם אחת כ-root; הזינו את שם המשתמש מ-config.php):
sudo mysql: רשימת המסדים מתקבלת דרך חיבור ה-PDO שלו עצמו.
PostgreSQL דורש הרשאות ברמת המשתמש postgres, שאין למשתמש הרשת של הפאנל. פתיחת sudo psql רחב מתוך PHP אינה בטוחה — במקום זאת הפאנל קורא לעטיפה מצומצמת ללא פרמטרים, שמדפיסה רק את הגרסה, מספר החיבורים ורשימת מסדי הנתונים עם הגדלים. צור אותה:
monitor-pgstat מ-sudoers (שלב 13 של ההתקנה הידנית) ואל תיצור את הסקריפט עצמו: כרטיס PostgreSQL פשוט יישאר לא פעיל.
הדשבורד מציג מה קורה; להלן — מה לעשות במצבים אופייניים. עיקרון כללי: לא להיכנס לפאניקה, להצליב מול פעילות לגיטימית (הפעולות שלך, עדכונים, גיבויים) ולהגיב לפי חומרה.
ignoreip./etc, מחוץ ל-/usr/share) — פוטנציאל להחלפה. הצלב את החבילה: debsums PACKAGE_NAME, ובמקרה של ספק התקן אותה מחדש (apt install --reinstall).127.0.0.1 או סגור את הפורט ב-UFW. זהו פרצה אמיתית.certbot renew או את ההגדרות בדשבורד).sudo apt update && sudo apt upgrade; אחרי עדכון הליבה אתחל את השרת.