הגנה על 1C-Bitrix מפני DDoS: תצורת Nginx רב-שכבתית, WAF, CDN

בכל יום באינטרנט הרוסי, עשרות התקפות DDoS פוגעות בחנויות מקוונות. אתרים על 1C-Bitrix פגיעים במיוחד: הארכיטקטורה שלהם עם רכיבים כבדים (קטלוג, חיפוש, עגלת קניות) הופכת אותם למטרה קלה. ראינו לקוחות שמפסידים עד 450–650 דולר לדקה של השבתה בשעות השיא. אבל אפשר לעצור התקפה לפני שהיא מגיעה ל-PHP—ברמת nginx ו-CDN. ב-12 שנים, בנינו תצורה שעומדת בגלים של עד 40 Gbps ללא אובדן נתונים.

נהיה ברורים: Bitrix עצמו לא יכול להגן מפני DDoS נפחי (L3/L4). זה תחום התשתית. אבל התקפות L7-DDoS בשכבת היישום—בוטים שמחקים משתמשים—ניתן לנטרל באמצעות הכלים המובנים של הפלטפורמה ותצורת nginx נכונה.

ההבדל בין L3/L4 ו-L7 DDoS

התקפות L3/L4 (ICMP flood, SYN flood) מעמיסות על הערוץ או על ציוד הרשת—רק CDN או WAF ענני יכול להדוף אותן. התקפות L7 (HTTP flood) מחקות מבקרים אמיתיים: פתיחת דפים, שליחת טפסים, חיפוש מוצרים. L7 מסוכן ל-Bitrix כי הוא צורך משאבי PHP ומסד נתונים.

מה אפשר לחסום באמצעות 1C-Bitrix עצמו

בקרת פעילות

המודול "אבטחה → בקרת פעילות" מגביל את מספר הבקשות מכתובת IP אחת בפרק זמן. פרמטרים:

• מקסימום בקשות לדקה—סף חסימה;
• פעולה—הפניה ל-CAPTCHA או לרשימה שחורה;
• משך חסימה (בדרך כלל 60–3600 שניות).

כתובות IP חסומות נכתבות לטבלת b_security_stop_list. רשומות ישנות מנוקות על ידי הסוכן Bitrix\Security\Stoplist::clearOldRecords(). לפרויקטים בעלי עומס גבוה, אנו ממליצים להגדיר סף של 30 בקשות לדקה—זה מכסה 95% מהמבקרים האמיתיים תוך ניתוק בוטים.

רשימה שחורה

הוספה ידנית של כתובות IP ותת-רשתות, תומכת במסכות (192.168.1.0/24). שימושי לחסימת טווחים ידועים, אבל לא פתרון קסם.

איך מגבלת קצב ב-nginx עובדת

לפני שבקשה מגיעה ל-PHP, nginx סופר את מספר הבקשות מכתובת IP. אם חריגה, הוא מחזיר 503 ללא צריכת משאבי שרת. הנה תצורה אופיינית ל-Bitrix:

http {
    limit_req_zone $binary_remote_addr zone=bitrix:10m rate=30r/m;
    server {
        location / {
            limit_req zone=bitrix burst=10 nodelay;
            # ... стандартная обработка
        }
        location ~ ^/(personal/|checkout/) {
            limit_req zone=bitrix burst=3 nodelay;
        }
    }
}

• http { limit_req_zone $binary_remote_addr zone=bitrix:10m rate=30r/m; server { location / { limit_req zone=bitrix burst=10 nodelay; # ... стандартная обработка } location ~ ^/(personal/|checkout/) { limit_req zone=bitrix burst=3 nodelay; } } } — הקצה 10 MB זיכרון למונה (~320,000 כתובות IP);
• zone=bitrix:10m — לא יותר מ-30 בקשות לדקה מכתובת IP אחת;
• rate=30r/m — אפשר פרץ קצר של עד 10 בקשות ללא עיכוב.

לדפי תשלום והתחברות, אנו מגדירים מגבלות מחמירות יותר: burst=10 nodelay, rate=10r/m. זה קריטי כי תוקפים מנסים לעתים קרובות לנחש סיסמאות או לשלוח הזמנות ספאם לשם.

מה עדיף: בקרת Bitrix מובנית או nginx? — השוואה

המודול המובנה עובד ברמת PHP, חוסם לאחר עיבוד הבקשה—צורך CPU. Nginx חוסם ברמת התעבורה, חוסך עד 80% ממשאבי השרת. למעשה, מגבלת קצב ב-nginx מפחיתה את עומס ה-CPU פי 5 בהשוואה למודול Bitrix (חיסכון של 80% לעומת 0%). אבל מודול Bitrix מציע גמישות: CAPTCHA, חסימה סלקטיבית לפי URL, אינטגרציה עם ניטור. הפתרון הטוב ביותר הוא שילוב: nginx מנתק את התעבורה העיקרית, המודול מטפל בחשודות.

WAF חיצוני ו-CDN

כדי להגן מפני התקפות נפחיות (10+ Gbps), אנו תמיד מחברים את Cloudflare, DDoS-Guard או Qrator. הם מסננים תעבורה במתקנים שלהם, ומעבירים רק תעבורה "נקייה" לשרת. Bitrix עובד נכון מאחורי פרוקסי הפוך בתנאי אחד: כתובת ה-IP האמיתית של הלקוח חייבת להיות מועברת.

דוגמה ב-burst=3:

if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $_SERVER['REMOTE_ADDR'] = trim(explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])[0]);
}

או דרך init.php:

'trusted_proxies' => [ 'value' => [ '173.245.48.0/20', // Cloudflare IPv4 '::/0' => false, ], ], 

למה חשובה תצורת trusted_proxies נכונה?

אם לא מצוינים trusted proxies, Bitrix יראה את כתובת ה-IP של Cloudflare במקום כתובת המבקר האמיתית. בקרת הפעילות תתחיל לחסום את עצמה—תוצאות חיוביות שגויות מובטחות. אנו בודקים פרמטר זה ראשון.

מקרה מבחן: חיפוש תחת DDoS

פעם הצוות שלנו קיבל התראה: חנות מקוונת (קטלוג של 150K פריטים) קרסה תוך 4 דקות. ההתקפה כוונה לדף החיפוש—בוטים שלחו בקשות עם if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { $_SERVER['REMOTE_ADDR'] = trim(explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])[0]); } אקראיים, כל אחד מפעיל חיפוש טקסט מלא ב-MySQL. פתרון בשלושה שלבים:

1. שמירת תוצאות חיפוש במטמון באמצעות bitrix/.settings.php למשך 15 דקות;
2. מגבלת קצב ב-nginx — 5 בקשות לדקה על 'trusted_proxies' => [ 'value' => [ '173.245.48.0/20', // Cloudflare IPv4 '::/0' => false, ], ], ;
3. אורך מינימלי של שאילתת חיפוש — 3 תווים (ברכיב).

לאחר היישום, התקפה דומה עברה בלי לשים לב—ניצול ה-CPU של השרת היה רק 12%. זמן התאוששות לאחר קריסה — 0. מנהל פרויקט.

מה כלול בהקמת הגנה

ציר זמן: הגנה בסיסית — מ-3 שעות; חבילה מלאה עם CDN — בין 2 ל-5 ימי עסקים. העלות מותאמת לפרויקט. אנו מבטיחים עבודה לפי חוזה עם SLA: שחזור גישה תוך 30 דקות. קבלו ייעוץ על הגנת פרויקט Bitrix שלכם—נעריך סיכונים תוך שעה. הזמינו ביקורת אבטחת אתר.

איך אנחנו עושים את זה: טכנולוגיה ותוצאות

במשך 5 שנים, יישמנו הגנה ל-80+ פרויקטים על 1C-Bitrix. זמן תגובה ממוצע לאירוע — 7 דקות. אנו משתמשים בפתרונות מוסמכים: Cloudflare Enterprise, Bitrix VM עם תצורות מותאמות.

שלבי הקמה מסוף לסוף:

1. ניתוח לוגים — זיהוי דפוסי בקשות אופייניים, איתור נקודות פגיעות.
2. תכנון — קביעת ספים, בחירת WAF, הגדרת חוקים.
3. יישום — שינוי nginx, רכיבי Bitrix, חיבור CDN.
4. בדיקות — סימולציית התקפות באמצעות siege/wrk, מדידת זמן תגובה ונזקים.
5. פריסה — העלאה לסביבת ייצור, ניטור למשך 48 שעות.
6. תמיכה — הדרכת הצוות שלכם, מסירת לוחות מחוונים, מענה לשאלות.

טעויות נפוצות בתצורה עצמית: הגדרת מגבלת קצב אחת לכל האתר (חוסמת משתמשים אמיתיים); שכחת X-Forwarded-For (CAPTCHA פוגעת בכתובת ה-IP של הפרוקסי); אי בדיקת עומס (5 בקשות לדקה מספיקות רק לאתרים סטטיים פשוטים). אנו בודקים כל נקודה—התוצאה עובדת שנים ללא תוצאות חיוביות שגויות.

להבנה מעמיקה של התקפות DDoS, אנו ממליצים לקרוא את הערך בוויקיפדיה. פרטים טכניים על מגבלת קצב ב-nginx מתוארים בתיעוד הרשמי.

12+ שנות ניסיון, אחריות על תצורות. צרו קשר לייעוץ.