מה זה Cloudflare, ומה הוא עושה לאתר מעבר ל‑CDN

מה זה Cloudflare, ולמה הוא יותר מ‑CDN

Cloudflare היא חברה שמפעילה רשת עולמית של מרכזי נתונים, שדרכה עוברת התעבורה של מיליוני אתרים. רוב האנשים מכירים את השירות שלה כ‑CDN, רשת שמגישה קבצים מהמקום הקרוב לגולש (הסברנו את זה לעומק במדריך על CDN). אבל הקאש הוא רק חלק אחד מהתמונה.

Cloudflare עומד בין הגולשים לבין השרת שלכם, וכל בקשה לאתר עוברת דרכו קודם. בנקודה הזו הוא יכול להצפין, לסנן, לחסום ולהאיץ. כל היכולות האלה נובעות ממודל אחד: Reverse Proxy (שרת מתווך שעומד לפני השרת שלכם ומדבר איתו בשם הגולשים). מי שמבין את המודל הזה מבין גם את רוב התקלות הנפוצות.

איך זה עובד: DNS והענן הכתום

כדי לחבר אתר, מעבירים את ניהול ה‑DNS (המערכת שמתרגמת שם דומיין לכתובת של שרת) ל‑Cloudflare: אצל רשם הדומיין מחליפים את שרתי השמות (Nameservers) לשני השרתים ש‑Cloudflare נותן. מרגע זה Cloudflare עונה על כל שאלה של "מה הכתובת של האתר הזה".

ליד כל רשומת DNS יש מתג עם ענן:

• ענן כתום (Proxied): Cloudflare מחזיר לגולשים כתובות של עצמו, ולא את כתובת השרת. הגולש מתחבר ל‑Cloudflare, ו‑Cloudflare פותח חיבור נפרד לשרת שלכם, שנקרא שרת המקור (Origin). ההגנות, הקאש וה‑SSL פועלים רק במצב הזה.
• ענן אפור (DNS only): Cloudflare רק עונה על שאלת ה‑DNS עם הכתובת האמיתית של השרת. התעבורה הולכת ישירות לשרת, בלי שום הגנה.

ה‑Proxy עובד על תעבורת אתרים, כלומר HTTP ו‑HTTPS. שירותים אחרים, כמו דואר, FTP או SSH, לא עוברים דרכו בתוכניות הרגילות, ולכן הרשומות שלהם חייבות להישאר אפורות. זה הכרחי, וזו גם הסיבה שהן יכולות להיות מסוכנות, כפי שנראה בהמשך.

הגנה מפני DDoS, חומת אש ובוטים

DDoS

מתקפת DDoS (הצפה של האתר בבקשות מהרבה מחשבים בו זמנית) נועדה להפיל את השרת. Cloudflare בולם מתקפות כאלה ברשת שלו, לפני שהן מגיעות אליכם, וזה כלול בכל התוכניות, גם בחינמית, בלי חיוב או הגבלה לפי גודל המתקפה. כשהאתר תחת מתקפה שעוברת את הסינון הרגיל, מפעילים את Under Attack Mode, שמציג לכל גולש בדיקה קצרה בדפדפן לפני הכניסה.

WAF וחוקים

WAF (Web Application Firewall, חומת אש לאתרים) בודק את תוכן הבקשה ולא רק מאיפה היא הגיעה: ניסיון להזריק קוד דרך טופס, גישה לקבצים רגישים, או ניצול של פרצה ידועה בתוסף. בתוכנית החינמית מקבלים סט חוקים מנוהל בסיסי שמכסה פרצות נפוצות וחמורות. סט החוקים המלא מתחיל בתוכניות בתשלום.

בנוסף אפשר לכתוב חוקים משלכם (Custom Rules), גם בתוכנית החינמית, במספר מוגבל. כמה דוגמאות שימושיות לאתר וורדפרס:

• אתגר (Managed Challenge) לכל מי שניגש ל‑/wp-login.php מחוץ לישראל, אם כל מנהלי האתר נמצאים בארץ.
• חסימה של /xmlrpc.php, אם אינכם משתמשים ב‑Jetpack או באפליקציה שצריכים אותו.
• הגבלת קצב (Rate Limiting) על עמוד הכניסה ועל טפסים, כדי לעצור ניסיונות ניחוש סיסמה.

בוטים

חלק ניכר מהתעבורה לאתרים מגיע מתוכנות אוטומטיות: סורקים שמחפשים פרצות, מעתיקי תוכן וניסיונות התחברות. בתוכנית החינמית יש Bot Fight Mode, שמאתגר תעבורה שנראית אוטומטית, וגם מתג לחסימת בוטים שאוספים תוכן לאימון מודלים של בינה מלאכותית. שימו לב: בתוכנית החינמית אי אפשר להגדיר חריגים ל‑Bot Fight Mode, ולכן הוא עלול לחסום גם חיבורים לגיטימיים, כמו הודעה מחברת סליקה שמאשרת תשלום או שירות ניטור. אם משהו כזה מפסיק לעבוד אחרי שהפעלתם אותו, זה המקום הראשון לבדוק.

מצבי SSL: למה Flexible הוא מלכודת

ברגע שיש Proxy, יש שני חיבורים נפרדים: בין הגולש ל‑Cloudflare, ובין Cloudflare לשרת שלכם. את הראשון Cloudflare מצפין תמיד, עם תעודה חינמית. מה שקורה בחיבור השני נקבע לפי מצב ה‑SSL:

Flexible נראה נוח, כי הוא מציג מנעול בדפדפן גם כשאין תעודה בשרת. אבל המנעול מטעה: הנתונים, כולל סיסמאות ופרטים מטפסים, עוברים בין Cloudflare לשרת בטקסט גלוי. ויש גם בעיה מעשית. השרת מקבל את הבקשה ב‑HTTP, ואם הוא או וורדפרס מוגדרים להפנות ל‑HTTPS, הוא שולח הפניה. הדפדפן חוזר ל‑Cloudflare ב‑HTTPS, Cloudflare פונה שוב לשרת ב‑HTTP, וחוזר חלילה. התוצאה היא השגיאה ERR_TOO_MANY_REDIRECTS.

הפתרון: מתקינים תעודה בשרת ועוברים ל‑Full (strict). אפשר להשתמש בתעודת Let's Encrypt רגילה, או בתעודת Origin CA חינמית ש‑Cloudflare מנפיק. תעודת Origin CA יכולה להיות תקפה עד 15 שנה, אבל רק Cloudflare מכיר בה, ולכן היא מתאימה רק לרשומות עם ענן כתום.

קאש: מה נשמר כברירת מחדל, ומה לא

כברירת מחדל Cloudflare שומר בקאש קבצים קבועים לפי הסיומת שלהם: תמונות, CSS, JavaScript, גופנים וקבצים להורדה. עמודי HTML לא נשמרים, ולכן בכותרת cf-cache-status של עמוד תראו בדרך כלל DYNAMIC.

אפשר לשמור גם עמודים, בעזרת Cache Rules, וזה יכול להוריד עומס גדול מהשרת. אבל כאן נמצאת הטעות המסוכנת ביותר: כלל שמכסה את כל האתר בלי חריגים. באתר וורדפרס חייבים להחריג לפחות את /wp-admin, את עמוד הכניסה ואת המשתמשים המחוברים (עוגייה שמתחילה ב‑wordpress_logged_in). בחנות WooCommerce מחריגים גם את העגלה, הקופה ו"החשבון שלי", וגולשים עם עוגיות של עגלה (שמתחילות ב‑woocommerce_ או ב‑wp_woocommerce_session). ל‑Cloudflare יש גם תוספת בתשלום לוורדפרס בשם APO, שמטפלת בחריגים האלה אוטומטית.

ועוד דבר שהשתנה: פעם Cloudflare גם הקטין קבצי CSS, JavaScript ו‑HTML (Auto Minify). התכונה הוסרה ב‑2024, והיום עושים את זה בתוסף באתר או בתהליך הבנייה שלו.

מה כלול בתוכנית החינמית

• ניהול DNS, ו‑CDN עם מרכזי נתונים בכל העולם, כולל בישראל.
• תעודת SSL חינמית לדומיין ולתתי הדומיין שלו ברמה אחת, כמו shop.example.co.il.
• הגנת DDoS בלי הגבלה לפי נפח.
• סט חוקי WAF בסיסי, מספר מוגבל של חוקים משלכם, והגבלת קצב בסיסית.
• Bot Fight Mode וחסימה של בוטים לאיסוף תוכן לבינה מלאכותית.
• Cloudflare Tunnel, שמחבר את השרת ל‑Cloudflare בלי לפתוח בו פורטים לאינטרנט.

התוכניות בתשלום מוסיפות בעיקר את סט חוקי ה‑WAF המלא, הגנת בוטים מתקדמת יותר, כיווץ תמונות אוטומטי ותמיכה ישירה. לאתר תדמית או לחנות קטנה, התוכנית החינמית בדרך כלל מספיקה. אתר עם הרבה תעבורה ומתקפות חוזרות ירוויח מהשדרוג.

הטעויות הנפוצות

קאש לעמודים אישיים

הסימן האופייני: גולש רואה את סרגל הניהול של וורדפרס, שם של לקוח אחר או עגלה שהוא לא מילא. מנקים מיד את כל הקאש (Purge Everything), ומתקנים את הכלל עם החריגים שתיארנו קודם.

חשיפת כתובת השרת

Cloudflare מגן רק על מי שמגיע דרכו. תוקף שיודע את כתובת ה‑IP האמיתית של השרת פשוט פונה אליה ישירות ועוקף את כל ההגנות. הכתובת דולפת בדרכים צפויות:

• רשומה אפורה שמצביעה לאותו שרת, למשל mail, ftp או cpanel.
• מיילים שהאתר שולח, שבכותרות שלהם מופיעה כתובת השרת.
• היסטוריית DNS: שירותים ציבוריים שומרים לאן הדומיין הצביע לפני שעבר ל‑Cloudflare.

ההגנה: בחומת האש של השרת מאפשרים חיבורים לפורטים 80 ו‑443 רק מטווחי הכתובות ש‑Cloudflare מפרסם בכתובת cloudflare.com/ips, או מחברים את השרת דרך Cloudflare Tunnel. אם הכתובת כבר ידועה ויש מתקפות, שווה לשקול להחליף אותה.

השרת לא רואה את כתובת הגולש

מאחורי Proxy, השרת רואה את כל הבקשות כאילו הגיעו מכתובות של Cloudflare. אם לא מגדירים את השרת לקרוא את הכתובת האמיתית מהכותרת CF-Connecting-IP, תוסף אבטחה עלול לחסום כתובת של Cloudflare, ואיתה גולשים רבים בבת אחת, והלוגים לא יראו מי באמת תקף.

איך בודקים שהכול מוגדר נכון

dig +short example.co.il
curl -sI https://example.co.il | grep -iE "^(server|cf-ray|cf-cache-status)"

• ה‑DNS מחזיר כתובות של Cloudflare, ולא את כתובת השרת.
• בכותרות מופיעות server: cloudflare ו‑cf-ray, כלומר הבקשה עברה דרך Cloudflare.
• בלוח הבקרה, תחת SSL/TLS, המצב הוא Full (strict).
• תמונה באתר חוזרת עם cf-cache-status: HIT בטעינה השנייה, ועמודי העגלה והניהול לא.

לבדיקה רחבה יותר של ההגדרות, כולל SSL וחומת אש, אפשר להריץ את בדיקת האבטחה החינמית שלנו.

בשורה התחתונה

Cloudflare הוא שכבה שעומדת לפני האתר: הוא בולם מתקפות, מסנן בקשות זדוניות, מצפין ומאיץ. אבל הוא טוב רק כמו ההגדרות שלו: Full (strict) ולא Flexible, קאש עם חריגים, ושרת מקור שלא חשוף לפניות ישירות. והוא לא מחליף אבטחה בשרת עצמו, עדכונים שוטפים וגיבויים. באחסון הוורדפרס של MVN Cloudflare כבר כלול, לצד חומת אש וסריקת נוזקות בשרת.