החוקים ב-Cloudflare שכמעט אף אחד לא מפעיל, וחבל
חסימת פורטים, הסרת Headers ומינימום TLS 1.3: מדריך אבטחה של 10 דקות שהתוקפים מקווים שלא תקראו
פורסם על ידי צוות ה-Cyber של SPD Hosting | יולי 2026
הקדמה
אני מניח שרובכם כבר "העברתם אתר דרך Cloudflare": שיניתם NS, הדלקתם את הענן הכתום, ראיתם שהאתר עולה, וסגרתם את הטאב בהרגשה שהאתר מוגן. האמת היא שהפעלתם אולי 20% ממה ש-Cloudflare באמת יודעת לתת, וזה נכון גם בחבילה החינמית.
במאמר הזה אספנו כמה חוקים שאנחנו רואים שוב ושוב שכמעט אף אחד לא מפעיל, למרות שהם דורשים דקות ספורות של הגדרה, לא עולים שקל, וסוגרים וקטורי תקיפה שאנחנו פוגשים בפועל ב-SOC שלנו מדי שבוע.
1. סגירת כל הפורטים חוץ מ-80 ו-443
הנה עובדה שמפתיעה הרבה אנשים: הפרוקסי של Cloudflare לא מאזין רק לפורטים 80 ו-443. כברירת מחדל הוא מעביר תעבורה גם דרך שורה של פורטים נוספים, בהם 8080, 8880, 2052, 2082, 2086 ו-2095 בצד ה-HTTP, וכן 8443, 2053, 2083, 2087 ו-2096 בצד ה-HTTPS. את הרשימה המלאה תמצאו בתיעוד הרשמי של Cloudflare.
למה זו בעיה?
עקיפת חוקים: חוקי WAF, Rate Limiting או Redirect שהוגדרו מתוך הנחה שהתעבורה מגיעה רק בפורטים 80 ו-443 עלולים פשוט לא לתפוס בקשות שמגיעות בפורט 2083.
סורקים אוטומטיים: בוטים סורקים את כל טווח הפורטים הפתוחים. פורטים "אקזוטיים" הם בדיוק המקום שבו הם מחפשים פאנלים ניהוליים וממשקים נשכחים.
רעש בלוגים: תעבורת זבל בפורטים שאתם בכלל לא משתמשים בהם רק מקשה לזהות את מה שחשוב באמת.
הפתרון: הפעלת חוק מובנה ב-Managed Rules
Cloudflare כבר כתבה עבורכם את החוק הזה, הוא פשוט כבוי כברירת מחדל. בתוך ה-Cloudflare Managed Ruleset מסתתר חוק בשם Anomaly:Port – Non Standard Port (not 80 or 443) שכל תפקידו לחסום בדיוק את התעבורה הזו.
כך מפעילים אותו:
- נכנסים אל Security ← WAF ← Managed rules
- לוחצים על Cloudflare Managed Ruleset ← Edit / Browse rules
- מחפשים Non Standard Port (או לפי Rule ID: 8e361ee4328f4a3caf6caf3e664ed6fe)
- מעבירים למצב Enabled ומגדירים את הפעולה ל-Block
מהרגע הזה, כל בקשה שמגיעה ל-Edge של Cloudflare בפורט שאינו 80 או 443 נחסמת עם קוד 403, עוד לפני שהתקרבה לשרת שלכם. שווה לדעת: הפורטים ימשיכו להיראות "פתוחים" בסריקת Netcat (זה אופי רשת ה-Anycast של Cloudflare), אבל שום תעבורה כבר לא תעבור דרכם.
הערה: ה-Cloudflare Managed Ruleset זמין בתוכניות בתשלום (Pro ומעלה). אם אתם על התוכנית החינמית, אפשר להשיג את אותה תוצאה עם Custom Rule פשוט: (not cf.edge.server_port in {80 443}) עם פעולת Block.
2. הסרת Headers "פטפטניים" שחוזרים מהשרת
פתחו את ה-DevTools בדפדפן, גשו לאתר שלכם והסתכלו על ה-Response Headers. באתרים רבים מאוד תמצאו שם דברים כמו:
Server: nginx/1.24.0
X-Powered-By: PHP/8.1.27
X-Generator: WordPress 6.5
מבחינת תוקף, זה זהב. השלב הראשון בכל מתקפה הוא איסוף מידע (Fingerprinting), וברגע שהתוקף יודע שרצה אצלכם גרסה ספציפית של PHP או nginx, הוא כבר יכול להצליב אותה מול מאגרי CVE ולתקוף בדיוק את החולשות הרלוונטיות. למה לחסוך לו את העבודה?
הפתרון: Transform Rules
נכנסים אל Rules ← Overview ← Modify Response Header (Response Header Transform Rules) ויוצרים חוק:
- When incoming requests match: All incoming requests (או hostname ספציפי)
- Then: Remove header, ומוסיפים שורה לכל אחד מהבאים: X-Powered-By · Server · X-Generator · X-AspNet-Version · X-AspNetMvc-Version · X-Drupal-Cache
שווה לדעת: את ה-header בשם Server קלאודפלייר ממילא מחליפה ברוב המקרים בערך cloudflare, אבל headers כמו X-Powered-By עוברים מהאוריגין אל הגולש כפי שהם, והם אלה שמסגירים את גרסת ה-PHP שלכם לכל העולם.
3. מינימום TLS 1.3: להפסיק לגרור פרוטוקולים מ-2008
כברירת מחדל, Cloudflare מאפשרת חיבורים החל מ-TLS 1.0, פרוטוקול שהוכרז כלא בטוח כבר לפני שנים, וחשוף למתקפות Downgrade ולחולשות הצפנה ותיקות. אין שום סיבה שאתר שנבנה היום יקבל חיבורים כאלה.
ההגדרה: SSL/TLS ← Edge Certificates ← Minimum TLS Version, ומעלים ל-TLS 1.3. מעבר לאבטחה, TLS 1.3 גם מהיר יותר: לחיצת היד (Handshake) מתקצרת, והאתר נטען מהר יותר, במיוחד בגלישה סלולרית.
רגע לפני שמעלים ל-1.3: דפדפנים מודרניים תומכים ב-TLS 1.3 כבר שנים, אבל אם קהל היעד שלכם כולל מערכות ישנות במיוחד (Windows 7 ישן, מכשירי אנדרואיד ותיקים, מערכות Embedded), בדקו קודם בגרף SSL/TLS Analytics בדשבורד איזה אחוז מהתעבורה שלכם עדיין מגיע בפרוטוקולים ישנים. אם קיימת תעבורה כזו, גם TLS 1.2 כמינימום הוא שיפור עצום לעומת ברירת המחדל.
ועוד כמה בונוסים קטנים ששווים הרבה
Managed Challenge על עמוד ההתחברות
אם האתר שלכם מבוסס וורדפרס, עמוד wp-login.php חוטף ניסיונות Brute Force בכל רגע נתון. חוק WAF פשוט עוצר את רובם המוחלט:
(http.request.uri.path contains "wp-login.php")
עם פעולת Managed Challenge. גולש אנושי כמעט לא ירגיש בכך, ובוטים ייעצרו בכניסה. אפשר גם להחריג את כתובת ה-IP של המשרד כדי שאתם תעברו בצורה חלקה.
חסימת xmlrpc.php
ממשק ותיק של וורדפרס שמעטים משתמשים בו היום, אבל תוקפים אוהבים אותו במיוחד, כי הוא מאפשר לבדוק אלפי סיסמאות בבקשה אחת. אם אין לכם אינטגרציה שדורשת אותו, חוק Block על xmlrpc.php וסגרנו פינה.
ולא לשכוח: להסתיר את האוריגין עצמו
כל החוקים בעולם לא יעזרו אם תוקף יודע את כתובת ה-IP האמיתית של השרת ופונה אליה ישירות, בלי לעבור דרך Cloudflare בכלל. ההשלמה הנכונה היא חסימה ברמת ה-Firewall של השרת, כך שתעבורת web תתקבל רק מטווחי הכתובות הרשמיים של Cloudflare.
סיכום
| החוק | מה הוא סוגר | זמן הגדרה |
|---|---|---|
| הפעלת Managed Rule לחסימת פורטים שאינם 80/443 | עקיפת WAF וסריקות בפורטים חלופיים | 2 דקות |
| הסרת Headers מהאוריגין | Fingerprinting של גרסאות PHP / שרת | 3 דקות |
| מינימום TLS 1.3 | פרוטוקולים חלשים ומתקפות Downgrade | דקה |
| Challenge על wp-login וחסימת xmlrpc | Brute Force אוטומטי | 3 דקות |
פחות מ-10 דקות עבודה, אפס עלות, וקפיצת מדרגה אמיתית ברמת האבטחה של האתר. Cloudflare היא כלי מדהים, אבל כמו בכל כלי, הערך האמיתי שלה נמצא בהגדרות שרוב האנשים אף פעם לא פותחים.
רוצים שנעבור על הגדרות ה-Cloudflare / WAF של האתר שלכם?
צוות הסייבר של SPD Hosting עושה את זה כל יום — ללקוחות האחסון שלנו זה חלק מהשירות. דברו איתנו: 03-6221258 או באתר spd.co.il
