איך לחזק את האתר שלך מפני מתקפות השרת הנפוצות ביותר

רוב המתקפות מנצלות את הפרצות הברורות

רוב המתקפות המוצלחות על אתרים לא מנצלות איזו חולשת zero-day מסתורית. הן מנצלות הגדרות שלא נעולות מלכתחילה — סיסמאות ברירת מחדל, תוכנות שלא עודכנו, פורטים פתוחים שאין להם כל סיבה להיות פתוחים, ושרתים שמתייחסים אליהם כאל "הגדר ושכח".

אם אתם מנהלים אתר — בין אם מדובר בבלוג WordPress, חנות אונליין או אפליקציית SaaS — הבנת נקודות התורפה הנפוצות ביותר היא הצעד הראשון האמיתי להגנה מפניהן.

נוף האיומים: מה באמת מחכה לכם שם

Brute Force ו-Credential Stuffing

תוקפים לא תמיד פורצים פנימה. לפעמים הם פשוט מתחברים. מתקפות Brute Force מפציצות נקודות כניסה עם אלפי קומבינציות סיסמה בדקה. Credential Stuffing זה אפילו גרוע יותר — הוא לוקח שמות משתמש וסיסמאות אמיתיים שדלפו מפרצות מידע אחרות ובודק אותם מול האתר שלכם.

אם לוח הניהול שלכם נגיש בכתובת /wp-admin או /admin ואתם לא מגבילים ניסיונות כניסה כושלים — אתם מטרה. הפתרון פשוט: הטמיעו סיסמאות חזקות, הפעילו אימות רב-שלבי (multi-factor authentication), והגבילו את מספר ניסיונות ההתחברות הכושלים לפני חסימה זמנית של ה-IP.

SQL Injection ו-Cross-Site Scripting (XSS)

שניים אלה נמצאים ב-OWASP Top 10 כבר יותר מעשור — ולא בכדי. הם עדיין פוגשים אותנו בכל מקום.

SQL Injection קורה כשקלט שהמשתמש הזין מועבר ישירות לשאילתת מסד נתונים מבלי שעבר סניטציה. תוקף יכול לשנות את השאילתה כדי לשאוב את כל מסד הנתונים שלכם, למחוק רשומות, ואפילו לקבל גישה ל-shell — תלוי בהגדרות השרת.

מתקפות XSS מחדירות סקריפטים זדוניים לדפי אינטרנט שאז מורצים בדפדפן של משתמשים אחרים. חולשת XSS מאוחסנת בשדה תגובות, למשל, יכולה לגנוב בשקט session cookies מכל מבקר שטוען את הדף.

ההגנות כאן מוכרות וברורות: השתמשו ב-parameterized queries (לעולם אל תשרשרו קלט משתמש ישירות ל-SQL), קודדו את כל הפלט, והטמיעו כותרת Content Security Policy (CSP) חזקה.

מתקפות DDoS

מתקפת Distributed Denial of Service מציפה את השרת שלכם בכמות תעבורה כה גדולה עד שבקשות לגיטימיות לא מצליחות לעבור. מתקפות DDoS מודרניות הן מתוחכמות — הן יכולות לחקות התנהגות משתמש אמיתי כדי לעקוף הגבלות בסיסיות, ומתקפות נפחיות יכולות להרוות את כל חיבור הרשת שלכם עוד לפני שחבילה אחת מגיעה לאפליקציה.

אתרים קטנים יותר חושבים לעיתים קרובות שהם לא מטרה. הם טועים. בוטים סורקים את האינטרנט באופן אקראי לחלוטין. כתובת ה-IP של השרת שלכם היא כל מה שתוקף צריך.

ההגנה קורית ברמת הרשת, לא ברמת האפליקציה. web application firewall (WAF) ושכבת הגנה מפני DDoS שיושבת מול שרת המקור שלכם הן הגישה הסטנדרטית. התעבורה נבדקת ומסוננת לפני שהיא בכלל מגיעה לאפליקציה. בתשתית שלנו, כל בקשה נכנסת עוברת דרך צינור זה באופן אוטומטי — אפשר ממש לראות איך בקשות עוברות בכל שלב אבטחה, מה שמקל על זיהוי תעבורה חסומה לעומת תעבורה שעברה בבת אחת.

תוכנות לא מעודכנות

זה פחות מרגש אבל גורם ליותר פרצות מכמעט כל דבר אחר. חולשה בגרסה ישנה של WordPress, ספריית PHP, או מערכת ההפעלה של השרת יכולה לתת לתוקף שליטה מלאה על השרת שלכם אם לא תיעשה תיקון (patch).

מסד הנתונים CVE מפרסם חולשות ידועות מדי יום. כלי סריקה אוטומטיים בודקים ברציפות את האינטרנט לאיתור שרתים שמריצים גרסאות תוכנה פגיעות. החלון בין גילוי חולשה לבין ניצולה הפעיל נמדד לעיתים קרובות בשעות, לא בימים.

עדכנו את ה-CMS, הפלאגינים ותוכנת השרת שלכם. ב-managed hosting, עדכוני kernel ורמת שרת מטופלים בדרך כלל עבורכם — כך שהמיקוד עובר לשכבת האפליקציה שלכם.

צעדי הקשחה מעשיים שאפשר לנקוט כבר היום

אבטחו את הכניסה

• השתמשו בסיסמאות ייחודיות וחזקות ובמנהל סיסמאות.
• הפעילו אימות דו-שלבי בכל חשבון ניהול.
• הגבילו גישה ללוח הניהול לפי כתובת IP אם תהליך העבודה שלכם מאפשר זאת.
• הגבילו ניסיונות כניסה כושלים וחסמו זמנית כתובות IP שחורגות מהסף.

שלטו במה שחשוף

• הריצו סריקת פורטים מול השרת שלכם (כלים כמו nmap מאפשרים זאת בקלות). סגרו כל פורט שלא חייב להיות פתוח.
• השביתו directory listing בשרת האינטרנט שלכם — חשיפת מבנה הקבצים שלכם היא מידע חינמי עבור תוקף.
• הסירו פלאגינים, תבניות ואפליקציות שאינם בשימוש. כל תוכנה מותקנת היא משטח תקיפה פוטנציאלי.
• אם אתם מריצים phpMyAdmin או כלי מסד נתונים דומה, אל תשאירו אותו נגיש לציבור. הגבילו אותו לפי IP או הורידו אותו לחלוטין.

הגדירו HTTP Security Headers נכונים

Security headers הם חינמיים ולוקח דקות להגדיר אותם. ובכל זאת, רוב האתרים מדלגים עליהם. לכל הפחות, הגדירו:

• Content-Security-Policy — מגביל אילו סקריפטים ומשאבים יכולים להיטען בדפים שלכם.
• X-Content-Type-Options: nosniff — מונע מדפדפנים לפרש קבצים כסוג MIME שונה.
• X-Frame-Options: DENY — חוסם הטמעת הדפים שלכם ב-iframes, ומגן מפני clickjacking.
• Strict-Transport-Security — מאלץ דפדפנים להשתמש ב-HTTPS בכל החיבורים העתידיים לדומיין שלכם.

תוכלו לבדוק את ה-headers שלכם בחינם בכתובת securityheaders.com.

אכפו HTTPS בכל מקום

אם חלק כלשהו מהאתר שלכם עדיין נטען דרך HTTP — תקנו את זה. לא רק בגלל SEO — תעבורה לא מוצפנת יכולה להיות מיורטת ושונה בזמן ההעברה. ודאו שתעודת ה-SSL שלכם תקפה, שה-redirect מ-HTTP ל-HTTPS קיים, ושהתעודה מתחדשת אוטומטית לפני שפגה תוקפה. רוב ה-managed hosts מטפלים בזה אוטומטית.

גבו לעיתים קרובות יותר ממה שאתם חושבים שצריך

שום עמדת אבטחה אינה מושלמת. גיבויים הם קו ההגנה האחרון כשהכל נכשל — בין אם ממתקפה, מחיקה בשוגג, או עדכון כושל.

גיבויים יומיים הם קו הבסיס. אם האתר שלכם משתנה לעיתים קרובות — חשבו על חנות WooCommerce פעילה שמעבדת הזמנות לאורך כל היום — יומי זה לא מספיק. הרצת גיבויים מספר פעמים ביום מצמצמת משמעותית את חלון אובדן הנתונים. אנחנו מאפשרים לבעלי שרתים להגביר את תדירות הגיבוי עד ארבע פעמים ביום, מה שמשנה לטובה כאשר עסקאות מתרחשות ברציפות.

אבטחה היא תהליך, לא רשימת משימות

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

המטרה אינה אבטחה מושלמת, שלא קיימת. המטרה היא להפוך את השרת שלכם למטרה מספיק קשה כך שתוקפים יעדיפו להתקדם לטרף קל יותר. רוב המתקפות האוטומטיות הן אופורטוניסטיות. סגירת הפרצות הברורות מציבה אתכם במצב טוב בהרבה מרוב האתרים באינטרנט.

התחילו עם חלק אחד מהמאמר הזה עוד היום. אתם לא צריכים לעשות הכל בבת אחת — אבל אתם כן צריכים להתחיל.