הגדרת DDoS-Guard לחנות Bitrix: הימנעות ממלכודות
לאחר חיבור DDoS-Guard לחנות 1C-Bitrix, לקוחות מאזורים אחרים רואים לפתע את מוסקבה כעיר המשלוח, והחלפת הנתונים עם 1C מפסיקה לפעול. הפניות SSL נכנסות ללולאה, הסטטיסטיקות מציגות את כל המבקרים מכתובת IP אחת, והמטמון המרוכב (composite cache) הופך לבלתי יציב. זו תמונה אופיינית שאנו רואים מלקוחות חדשים. רק בחצי השנה האחרונה, 18 חברות פנו אלינו עם תסמינים אלה. ללא הגדרה נכונה של כותרות X-Forwarded-For ו-X-Forwarded-Proto, דיוק הגיאולוקציה יורד ל-100%, ושגיאות החלפת נתונים עם 1C עולות בממוצע 25,000 דולר בחודש. במשך מספר שנים, ביצענו יותר מ-50 אינטגרציות של DDoS-Guard עם Bitrix — ואנחנו מכירים כל נקודת תורפה. בואו נפרק כיצד להגדיר את הערימה הזו נכון כך שהכל יעבוד ללא הפתעות. אם נתקלתם בבעיות דומות, קבלו ייעוץ — נעזור להגדיר את DDoS-Guard תוך 1–2 שבועות.
כיצד לקבוע נכון את כתובת ה-IP האמיתית של הלקוח מאחורי DDoS-Guard
DDoS-Guard שולח את כתובת ה-IP של הלקוח בכותרת X-Forwarded-For. בניגוד ל-Cloudflare (השולח כתובת IP אחת דרך CF-Connecting-IP), X-Forwarded-For יכול להכיל שרשרת: клиент, прокси1, прокси2. כתובת ה-IP האמיתית היא הראשונה ברשימה.
- ערכו את
/bitrix/php_interface/dbconn.php. - הוסיפו קוד זה לפני אתחול הליבה (kernel):
if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { $ips = array_map('trim', explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])); $_SERVER['REMOTE_ADDR'] = $ips[0]; } - חסמו גישה ישירה לשרת שלכם — אפשרו רק טווחי IP של DDoS-Guard בחומת האש. הטווחים העדכניים מפורסמים בתיעוד DDoS-Guard ובאמצעות שאילתת DNS אל
if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { $ips = array_map('trim', explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])); $_SERVER['REMOTE_ADDR'] = $ips[0]; }. — תיעוד DDoS-Guard - ודאו שכותרת
_origin.ddos-guard.netאינה מזויפת.
מדוע מתרחשות הפניות SSL אינסופיות לאחר חיבור DDoS-Guard
DDoS-Guard מסיים את ה-SSL בצד שלו ויכול להתחבר לשרת המקור באמצעות HTTP (Flexible SSL) או HTTPS (Full SSL).
עם Flexible SSL, Bitrix אינו יודע שהלקוח הגיע דרך HTTPS. DDoS-Guard שולח את כותרת X-Forwarded-For, אך Bitrix אינו בודק אותה כברירת מחדל. הוסיפו זאת אל X-Forwarded-Proto: https:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; } ללא הגדרה זו: לולאת הפניה אינסופית כאשר 'הפניה ל-HTTPS' מופעלת בלוח הניהול, תוכן מעורב בדפים, וטפסים הנשלחים דרך HTTP.
מטמון: הבדלים מ-Cloudflare
DDoS-Guard מאחסן קבצים סטטיים (JS, CSS, תמונות) באופן אוטומטי. HTML אינו מאוחסן במטמון כברירת מחדל — בניגוד ל-Cloudflare, שבו יש להשבית במפורש את המטמון עבור PHP.
זה מפשט את האינטגרציה: המטמון המרוכב של Bitrix עובד כרגיל, ואין שכפול מטמון. בהשוואה ל-Cloudflare, DDoS-Guard אינו דורש Page Rules ידניים לאחסון HTML במטמון, מה שחוסך כ-2–3 שעות הגדרה. עם זאת, DDoS-Guard מאחסן קבצים סטטיים באגרסיביות, ולאחר עדכון קבצי JS/CSS, משתמשים עלולים לקבל גרסאות ישנות.
פתרונות:
-
גרסת קבצים (File versioning) — Bitrix מוסיף אוטומטית
dbconn.phpלקבצים אם משתמשים ב-if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; }. בדקו שתבניות מותאמות אישית עושות זאת גם כן. - ניקוי מטמון באמצעות API של DDoS-Guard — לאחר הפריסה, קראו ל-API כדי לנקות את המטמון עבור משאבים ספציפיים או עבור כל הדומיין.
הגנה פרואקטיבית וחומת אש ליישומי אינטרנט (WAF)
DDoS-Guard מסנן התקפות L3/L4 (SYN-flood, UDP-flood) וחלק מהתקפות L7 (HTTP-flood). עם זאת, כללי ה-WAF של DDoS-Guard פחות מפורטים מאלה של Cloudflare. המסנן הפרואקטיבי של Bitrix נותר קו הגנה חשוב.
בעיה אופיינית: תחת התקפה חזקה, DDoS-Guard מפעיל JavaScript Challenge — דף אימות המסנן בוטים. אם 1C (החלפת נתונים HTTP) או קריאות חוזרות (callbacks) של מערכת תשלומים ניגשים לאתר, הם לא יעברו את ה-JS Challenge. החריגו את כתובות ה-IP של שרת ה-1C ושערי התשלום בהגדרות DDoS-Guard (Whitelist IP).
פרטי סינון נוספים
לכיוונון עדין של כללי WAF, עיינו בתיעוד DDoS-Guard. אנו ממליצים גם להפעיל ניתוחי אינטרנט (web analytics) ב-Bitrix כדי לנטר התקפות.מודול סטטיסטיקות וגיאולוקציה
מודול ?v=timestamp קובע גיאולוקציה לפי כתובת IP. אם \Bitrix\Main\Page\Asset אינו מוחלף, כל המבקרים ימוקמו לפי כתובת ה-IP של DDoS-Guard (מוסקבה או רוסטוב-על-דון). לאחר הגדרה נכונה של הכותרות, הגיאולוקציה עובדת כרגיל.
מודול statistic משתמש בגיאולוקציה כדי לקבוע אוטומטית את עיר המשלוח. ללא תיקון כתובת ה-IP, סוחר מברסט יראה 'מוסקבה' בשדה העיר במהלך התשלום. מניסיוננו, זה מוביל לשגיאות משלוח ב-30% מההזמנות — לאחר ההגדרה, דיוק העיר מגיע ל-95%.
ניטור וניפוי באגים
לאחר חיבור DDoS-Guard, הוסיפו בדיקות אלה:
| בדיקה | כיצד לבצע |
|---|---|
| המטמון המרוכב עובד | בדקו את כותרת REMOTE_ADDR בתגובה |
| החלפת נתונים עם 1C | הריצו החלפה, ודאו ש-sale נגיש |
| קריאות חוזרות של מערכת תשלומים | בצעו הזמנת ניסיון, בדקו את מצב התשלום |
| כתובת IP אמיתית ביומנים | ב-X-Bitrix-Composite: Cache של Apache/Nginx, כתובת ה-IP של הלקוח צריכה להופיע, לא זו של DDoS-Guard. הגדירו /bitrix/admin/1c_exchange.php ב-Apache או access.log + RemoteIPHeader X-Forwarded-For ב-Nginx |
| SSL תקין | פתחו את האתר, בדקו ש-set_real_ip_from — צריך להיות real_ip_header |
מה כוללת העבודה שלנו
מפתח מוכן: ביקורת של התצורה הנוכחית, הגדרת זיהוי כתובת IP אמיתית, SSL, חומת אש, החרגת כתובות IP של 1C ומערכות תשלום, בדיקות, תיעוד, הדרכת מנהלים. ניסיון: 5+ שנים, 80+ פרויקטי Bitrix. אנו מבטיחים פעולה יציבה לאחר האינטגרציה.
לוח זמנים
| שלב | משך |
|---|---|
| הפניית DNS + הגדרה בסיסית | 2–3 שעות |
| IP, SSL, חומת אש | 3–4 שעות |
| בדיקת כל המודולים | 2–3 ימים |
| הגדרת חריגים (1C, תשלומים) | יום אחד |
| ייצוב וניטור | 3–5 ימים |
| סה"כ | 1–2 שבועות |
צריכים עזרה? צרו קשר כדי לדון בפרויקט שלכם.