תגית: הגנה

להגן על האתר שלך

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

מבחינת הגנה שנותן ספק האחסון בישראל, לא חשוב מי הספק, ההגנה לא תספק מבחינת התקפות DDoS וזאת מהסיבה הפשוטה שהתקפה כזו תופסת הרבה יותר משאבי רשת ממה שהוא הקצה לך כלקוח. אם אתה לדוגמא מארח שרת פיזי או שוכר שרת וירטואלי ותסתכל בהסכם, תראה שהספק מתחייב לספק לך רוחב פס של 5 מגהביט (כן, מגהביט ולא מגהבייט). רוצה עוד? תשלם. אצל חלק מהספקים אתה תקבל יותר רוחב פס אבל בכל מקרה – אם התקיפו את האתר שלך ב-DDoS (היום זה זול מבחינה פיננסית להתקיף אתר), אם ההתקפה לא תוריד את האתר שלך – הספק יוריד.

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

אם לדוגמא ברגע זה אתה מבין שהאתר שלך אינו נגיש ואתה שומע מהספק שאתה מותקף, אתה יכול לגשת לאתר של CloudFlare, לבחור את הדומיין שלך (אם יש לך מספר דומיינים שמציגים אתרים מאותו שרת – עבור על כל אחד מהדומיינים), ללחוץ על כפתור ה-Firewall ופשוט לבחור "I'm Under Attack", כמו בתמונה הבאה:

cf

מה שיקרה מעתה, זה שכל מי שיגלוש אל האתר שלך, יקבל דף עם עיגולים קופצים ל-5 שניות מהשרתים של CloudFlare (בזמן שאותם עיגולים קופצים נעשית בדיקה שמי שמנסה להתחבר אליך מתחבר מדפדפן אמיתי ולא חלק מסקריפט של התקפת DDoS) ותוך רגעים ספורים ההתקפה על אתריך נכשלת.

אבל אפשר להגן יותר (וכאן זה כבר בתשלום של 20$ לחודש ל-CloudFlare) – אם תעשה את המנוי, בדיוק באותו מקום ב-Firewall תוכל גם להגדיר בעצם מי המדינות שיכולות לגלוש לאתרים שלך. אם לדוגמא רוב הגולשים שלך הם מישראל, ארה"ב ובריטניה, אתה יכול לאפשר רק אותם וכל השאר יהיו חסומות, כך שהסיכוי להתקפת DDoS מתקטן באופן משמעותי מאוד.

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

cf2

מי שלא מכיר לוגים של כניסות לאתרים לא יבין מה הבעיה, מי שמבין רואה שיש כאן נסיונות כניסה עם מחרוזות רנדומליות שנועדו לעקוף חוקים שחוסמים כניסה. במקרים כאלו ה-WAF יכול לסייע ולחסום דבר כזה בשניות (תומכי CloudFlare כותבים עבורך את החוק אם תתן להם קובץ access_log או שאתה יכול לכתוב בעצמך). מעבר לכך, חוקי ה-WAF מתעדכנים מצד CloudFlare נון סטופ, כך שאתה מקבל הגנה גם על דברים שאינך מודע אליהם (לדוגמא אם אתה משתמש בתוכנה כמו WHMCS (זו תוכנה שקשורה ל-Billing ואוטומציה של שרותי Hosting), אז בעבר היו מספר פריצות לתוכנה, ועד שיצרן התוכנה תיקן אותם, ב-CloudFlare הכניסו חוקי הגנה ל-WAF ללקוחותיהם, כך שאם מישהו היה מנסה לפרוץ ל-WHMCS שלך, הוא היה נכשל בשעה שאצל אחרים הפורץ היה "חוגג".

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

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

  • עדיף שההגנות לאתרך לא יבוצעו בשרת הפרטי שלך אלא ברמת ספק ה-CDN, ובמקביל – לא מומלץ לאפשר גלישה ישירה לאתר שלך, אלא גלישה רק דרך ספק ה-CDN.
  • אל תסמוך על הבטחות ההגנה של ספק התשתית שלך. במקרים מסויימים הוא יפיל את האתר שלך, ובמקרים אחרים אתה עלול ליפול לתומכים שלא ממש יודעים מה הם עושים. יש להם הגנות מכאן עד הודעה חדשה? זה לא רלוונטי לגביך.
  • הגנה רצינית אינה עניין של להגן על הוורדפרס/ג'ומלה/דרופל שאתרך מריץ, אלא על המון פרמטרים אחרים שחלקם אולי אינך מודע אליהם. מומלץ לשכור מישהו חד פעמית כדי לבצע הערכה ותוכנית מה צריך להגן, מה צריך להסיר ואם אפשר – איך להגיע לביצועים אופטימליים עם הגנה.
  • הגנות טובות גם מצריכות תחזוקה מתמשכת, ולכן כדאי לסגור עם מי שמטפל בך טכנית שגם יעדכן את השרת שלך אחת לכמה שבועות.
  • חשוב: אם האתר שלך חשוב מאוד ו/או מייצר לך רווחים, אל תאחסן אותו באחסון משותף (Shared Hosting). לצערי כמות ההגנה שניתן לבצע על אתר שמאוחסן באחסון משותף היא מאוד קטנה (לא ניתן להגן עליו מ-DDoS, לא ניתן להטמיע WAF "מבחוץ", לא ניתן להגן על המכונה ועוד).

ההגנה הכי טובה–ההגנה שלכם

10276894_s

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

נתחיל בשאלה שנשאלת הכי הרבה: על איזה ספק שרתי VPS ניתן לסמוך בעיניים עצומות? תשובתי אולי תפתיע חלק מהקורים: אף ספק. לא בישראל ולא בעולם.

הרשו לי להסביר מדוע.

לא חשוב מי יהיה הספק שאיתו תבחרו לעשות עסקים. בין אם זה ספק “מחשוב ענן”, בין אם זה ספק שרתים וירטואליים (VPS), ובין אם זה ספק שמוכר שרות אחסון אתרים – כולם יבטיחו לכם שהם משתמשים במילה האחרונה של הטכנולוגיה להגנה. “חומת האש הכי חדשה של צ’ק-פוינט? יש לנו!” “חומת האש המפלצתית של סיסקו? קנינו אותה ראשונים”, “אנחנו מבצעים בדיקות שוטפות לגבי נסיונות חדירה”, “יש לנו את מיטב המומחים לענייני הגנה ואבטחת מידע” ועוד הבטחות כאלו ואחרות.

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

לחברת “שוקי הקופץ” יש איש ממש “שפיץ” בכל הנוגע לחומות אש. קוראים לו איציק. איציק לא יושב כל היום על הגדרות של החומות אש, הוא גם מגדיר שרתי לינוקס ו-Windows עבור לקוחות החברה, הוא גם כותב סקריפטים, ואין לו שום כח בעולם להיכנס להגדרות ה-Firewall על כל פיפס של לקוח, אז הוא יוצר משתמש נוסף בחומת האש עבור יוסי, הבחור שמקבל פניות מלקוחות בקשר להגדרות של החומת אש. הבעיה? יוסי לא כל כך מבין מה ההבדל בין TCP ל-UDP, מה זה לכל הרוחות ICMP ומה בעצם צריך להגדיר אם הלקוח שולח בקשה להגדרות פורטים של FTP? פורט 21? רגע, מה זה Passive ו-Active ב-FTP?

אז מה יוסי עושה במקרים רבים? פותח מה שנקרא “ANY ANY”. הלקוח מרוצה? כן, בהחלט. יוסי מבחינתו סיים את המטלה? סיים. עם מה נשארנו? עם כניסה מלאה לשרת, והדבר היחיד שעומד בין פורץ משועמם לבין השרת –הן ההגדרות של השרת. אם הלקוח השאיר SSH פתוח לקבלת סיסמאות בפורט 22 והסיסמא שהלקוח הגדיר היא: !1q2w3e4r – אז הולכות להיות צרות צרורות ללקוח.

מי אשם? אם תשאלו את הלקוח, יוסי אשם שפתח את הכל. אם תשאלו את יוסי, סביר להניח שהוא ואיציק יאשימו את הלקוח על הסיסמא הצפויה ועל כך שהוא השאיר פורט 22 פתוח לקבלת סיסמאות. האשמה היא כמובן ב-2 הצדדים, וסביר להניח שטוב .. לא יצא מהסיפור הזה.

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

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

מצבך ההתחלתי: דמיין לך ששכרת אצל ספק כלשהו מקום לאחסן שרת שלך. קיבלת כבל חשמל, כבל רשת, כתובות IP ו… זהו. יש 0 חוקים בחומת האש שחלים על השרת שלך. זה המצב שאתה צריך לחשוב עליו ולדמיין אותו.

עד כאן יש? מצוין. עכשיו מתחילים השלבים הבסיסיים בהגנה:

  1. יש לך שרת Windows? מצוין. קודם כל תשנה את חיבור ה-RDP לפורט אחר, לא ברירת המחדל (3389). איך עושים זאת? תסתכל כאן.
  2. יש ל-Windows 2008 חומת אש לא רעה (בהשוואה לגרסאות קודמות). כדאי שתיכנס קצת ותראה מה הפורטים הפתוחים מבחוץ פנימה. אתה צריך פינג? לא? בטל ICMP. יש לך כל מיני שרותים שרצים ונותנים פתרון לחשבונות לוקאליים? סגור אותם לכניסה מבחוץ. מוכן להשקיע קצת? חברות כמו MCAFEE מוכרות חומת אש ל-Windows, תחשוב על לרכוש אחת.
  3. נקודה נוספת שרבים שוכחים: לסגור את הפורטים המיותרים גם מבפנים החוצה.מדוע? מספיק שסקריפט כלשהו יוטמע באתרך, הוא ינסה להתחבר לאיזה “מרכז בקרה” של הפורץ, וסביר להניח שזה יהיה בפורט לא סטנדרטי (כמו 6667). חסימת הפורטים לא תמנע מהסקריפט הזה להיות מושתל באתרך (על כך בהמשך), אבל לפחות תמנע מהסקריפט להתחבר ל”מרכז בקרה”.
  4. סביר להניח שהספק יכול להציע לך שרות VPN בתשלום נוסף. לא צריך, יש קוד פתוח. תכיר את OpenVPN שקיים גם ל-Windows. עם OpenVPN תוכל להגדיר לך כתובת פנימית שרק דרכה תוכל להתחבר לשרותים כמו RDP.

יש לך שרת לינוקס? כאן הדברים קצת שונים אבל עדיין לא מסובכים:

  1. מומלץ לשנות את הפורט SSH מ-22 לכתובת אחרת, כדאי לשים לב שהכתובת לא מתנגשת עם כתובות אחרות. בד”כ השינוי מתבצע בקובץ sshd_config. השינוי יחול רק לאחר שתפעיל את השרות. אל תפעיל את השרות מחדש אלא רק לאחר שביצעת את הסעיפים בהמשך…
  2. לא מומלץ לפתוח פורטים כמו של MySQL החוצה! רבים פותחים חיבורים לשרת MySQL החוצה כדי לנהל אותו עם איזה כלי GUI ושוכחים שברירת המחדל MySQL אינו מוצפן. אם אתם זקוקים לחיבור מבחוץ, עשו זאת עם VPN או שתשתמשו בהוראות האלו כדי להעביר את הנתונים עם SSL.
  3. תכירו תוכנה בשם CSF. זוהי תוכנה קטנה ונחמדה שיודעת לשלוט בחומת אש הפנימית של מערכות לינוקס, ויש בה עוד חלקים שיכולים מאוד לסייע כמו סגירה של פורטים לא נחוצים מבפנים החוצה וההיפך, חסימה אוטומטית של משתמשים אחרי שלא הכניסו סיסמא נכונה 3 פעמים, ועוד המון המון דברים נחמדים שיכולים לסייע המון. אם אתם משתמשים בה, אז עשו טובה קטנה ותרמו להם כמה דולרים בפייפאל, הם עושים עבודה מעולה.
  4. אם יש לך דיסק-אן –קי שהולך איתך קבוע או מחשב נייד שלך שהוא ממש צמוד עליך, עדיף לעבוד עם SSH בשיטה של מפתח פרטי/ציבורי ולחסום בקשת סיסמאות. בדרך זו תחסום סקריפטים רבים שמנסים להיכנס דרך SSH לשרת שלך.
  5. גם כאן מומלץ לחשוב לעבוד עם OpenVPN שנכלל בכל הפצת לינוקס.

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

נקודה קריטית נוספת אם כי לא זולה: קחו איש אבטחת מידע (ולא, אני לא איש אבטחת מידע) ושלמו לו כדי לבדוק את המערכת שלכם, ולחסום פרצות בקוד, ב-DB ובשאר החלקים.

עוד נקודה נוספת: רבים סומכים על הגיבוי שספקים שונים מציעים. זו טעות. מה אם מחר נדפקים הדיסקים של הגיבוי שלכם? לא נעים. לכן, מומלץ לבצע snapshot למערכת, לבקש את קובץ ה-snapshot ולשמור אותו אצלכם בצד, ולהשכיר שטח גיבוי שאליו תבצעו גיבוי משלכם שבמקרה חרום הספק ירים לכם מכונה בתולית, תוכלו להטמיע את ה-snapshot ולשחזר גיבויים. מדוע גיבוי משלכם ולא גיבוי מרוכז של הספק? כי אין לכם שום מושג מה מצב הגיבוי, כמה הגיבוי והשרת עצמו מוגנים, וכו’. בגלל זה מומלץ להתקין תוכנת גיבוי משלכם (אנשי לינוקס יכולים פשוט לכתוב סקריפט פשוט לבצע rsync או קבצי tar מוגנים בסיסמא) שישבו בשרת פיזי אחר

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

בהצלחה

איך מגינים על שרת וירטואלי?

אנשים לוקחים לצרכיהם שרתים וירטואלים, בין אם בארץ או בחו"ל (יותר מוכר בארץ כ-שרתי VPS בחו"ל זה יותר מוכר כ-Virtual Hosting או Virtual Server) כדי להריץ על השרת כל מיני דברים, בין אם אתר בינוני עד גדול, אפליקציות וכו'. טכנולוגיית הויטוראליזציה עצמה אינה משנה לתוכן פוסט זה, בין אם זה KVM, Hyper-V, Virtuozzo, Xen, OpenVZ או VMWare.

העניין הוא שרבים לחסוך ולחתוך מחירים, ובד"כ הם מוותרים על שרותי סיסטם מצד הספק. אחרי הכל "כמה זה כבר מסובך לנהל אבטחה של Linux או Windows? יש לי כזה בבית שרץ על VMWare / VirtualBox ולא קרתה שום בעיה עם מה שאני מתקין ועושה". כך אמר לי לדוגמא אדם אחד שרצה לשכור את שרותי הפרילנס שלי לטפל ב"תקלה קטנה". מהות התקלה? שום דבר מיוחד, הוא בטעות מחק את תיקיות sbin, /bin, /usr/ והוא התפלא למה המערכת לא עולה.

מכיוון שזהו אינו פוסט "בואו קחו את שרותיי", אלא פוסט "מה אתם יכולים לעשות כדי להגן על המכונה שלכם", נתחיל בכמה צעדים בסיסיים כדי להגן. פוסט זה מדבר ספציפית על Linux, לא חשוב איזו הפצה: בניגוד למכונה שלך בבית, שרת וירטואלי אצל רוב הספקים מקבל IP אמיתי (בין אם דרך רכיב NAT בתשתית הספק ובין אם מוגדרת כתובת IP על השרת עצמו). בבית שלך, אתה מאחורי NAT של הראוטר שלך אז בברירת המחדל אף אחד לא מגיע אליך (כמעט), מה שאומר שהמכונה שלך מרגע שהיא עלתה, היא חשופה ולא חשוב איזו חומת אש יש מעליה, לפיכך חשוב לבצע את הצעדים הבאים:

  1. לא לעבוד כ-root! הנה טעות שרבים עושים – מתקינים מכונת Linux (או מקבלים התקנה מוכנה מהספק) עם שם וסיסמא ומשאירים את המצב כך. חובה להגדיר משתמש רגיל ולעבוד אך ורק איתו ולא כ-root. איך עושים פעולות של root עם משתמש רגיל? אם אתה משתמש ב-CentOS אז תוכל לקרוא כאן איך להשתמש ב-sudo. בהפצות כמו אובונטו, שם המשתמש הראשון שמוגדר בעת ההתקנה יש לו הרשאות sudo.
  2. לבטל כניסת משתמש root – סקריפטים רבים שמנסים לפרוץ לשרתים (יש המון כאלו) בודקים קודם כל אם יש כניסה למשתמש root עם כל מיני סיסמאות, ולכן מומלץ לבטל אפשרות כניסת root ע"י שינוי קובץ etc/ssh/sshd_config/ השינוי: חפש את PermitRootLogin Yes – תמצא בהתחלה סולמית (#) ליידו, מחק את הסולמית ושנה את ה-Yes ל-No, ולאחר מכן הפעל את שרות ה-ssh מחדש (פקודת: service sshd restart). הדבר אינו פוגע בכניסת משתמש root דרך הקונסולה (לא דרך SSH) אם ספק השרות נותן לך קונסולה. מומלץ באותה הזדמנות לשנות את כניסת (פורט) SSH מ-22 למשהו אחר (נניח 1340 או מספר אחר מעל 1024).
  3. אם הינך משתמש ב-MySQL והשרת שלך הוא התקנה חדשה, הרץ (עם sudo) את פקודת mysql_secure_installation והזן את הפרטים שהתוכנה מבקשת ממך. לאחר הזנת הפרטים, המערכת תסגור כניסות ותמחק משתמשים מיותרים.
  4. אם יש לך מספר אתרים שמתארחים על השרת, פתח לכל אחד שם משתמש וקבוצה משלו (UID, GID) והשתמש בדברים כמו mod_suphp (ניתן להתקין את זה בפקודת yum install suphp על Centos או apt-get install suphp באובונטו/Debian). כאן תוכל למצוא הוראות איך להשתמש ב-suphp עם CentOS וכאן עם דביאן/אובונטו. בשיטה זו, תוכל לראות בקלות איזה אתר משתמש במשאבים ובכמה.
  5. תוכנות כמו Putty ב-Windows או תוכנות טרמינל במק ובלינוקס מאפשרות בקלות ליצור ולהשתמש במפתחות על מנת להיכנס (Login) לשרות. מומלץ להשתמש בשרות זה במקום סיסמאות, כך תוכל להגן על השרת שלך הרבה יותר, מכיוון שאף אחד לא יוכל לנסות לעשות Login לשרת שלך. איך עושים זאת? עוקבים אחר ההוראות כאן (ההוראות מתאימות לכל ההפצות).
  6. אל תפתח סתם פורטים: רבים אוהבים את השימוש בתוכנות גרפיות כדי לנהל דברים כמו MySQL עם Client שמותקן על המחשב בבית ולשם כך הם פותחים את פורט 3306. זו שגיאה נפוצה כי פורצים יכולים להאזין למידע ומשם לפרוץ בקלות לשרת שלך. אם אתה רוצה כלי וובי טוב לנהל בקלות MySQL, כדאי להשתמש ב- phpmyadmin (שימו לב להגדיר את האבטחה שבו, כי גם תוכנה זו פופולרית מאוד בקרב הסקריפטים המנסים לפרוץ לשרתים).
  7. סגור שרותים שאינך צריך: אצל ספקים שונים, הלינוקס מותקן כמו שהוא ללא שום הגדרות אבטחה מסויימות וללא ביטול שרותים שאינם נחוצים (מתי לאחרונה השתמשת בשרות Bluetooth על שרת?). ב-CentOS תוכל להשתמש בפקודה chkconfig ובדביאן/אובונטו תוכל להשתמש בפקודות שמופיעות כאן כדי להגדיר מה יפעל ומה לא. אם אינך יודע מהו כל שרות, גוגל יכול לסייע לך.
  8. ודא כי כל הסיסמאות הן סיסמאות חזקות, הווה אומר לפחות 3 מספרים ו-5 אותיות (גדולות וקטנות) מוגדרות לכל בסיס נתונים, שם משתמש וכו'.
  9. אל תסמוך על חומת האש של הספק! לקוחות רבים שומעים מאנשי מכירות כמה הספק השקיע בתשתית ויש חומת אש אכזרית של צ'ק פוינט/סיסקו שעולה מליוניםם ושהיא הודפת התקפות בקלות ושלל מעשיות נוספות, אבל גם חומת אש הכי יקרה בעולם יכולה לשמש כאבן שאין לה הופכים אם יש איש סיסטם מטומטם שמגדיר חוקים עם ANY ANY לכל הכתובות, לכן חשוב להגדיר את חומת האשהפנימית בשרת שלך שתגן על המכונה שלך.
  10. גיבויים – שוב, ספקים רבים מבטיחים גיבוי, אבל מי ערב לך שהגיבוי עובד ותקין ולא מוזנח (כי לאנשי הסיסטם יש משימות אחרות והם לא טיפלו חודשים רבים בגיבוי… ראיתי כבר ספקים עם המצב הנ"ל) וביום פקודה זה לא יעבוד? לכן חשוב מאוד לעשות גיבוי משלך למקום אחר (עדיף לאחסן את הגיבוי מחוץ לתשתית המקומית של הספק, או להשתמש באחסון חיצוני כמו S3 של אמזון).
  11. כשזה מגיע לבסיסי נתונים, תהיה מקורי בשמות בסיסי הנתונים. אם יש לך בלוג וורדפרס לדוגמא, בסיס נתונים עבורו בשם wpdb זה רעיון לא טוב! חשוב ליצור שמות מקוריים ויחודיים על מנת שלא לעשות חיים קלים לאלו הפורצים אתרים. זכור גם להכניס סיסמאות מסובכות (צריך שרות ליצירת סיסמאות מסובכות? קבל)
  12. הכר את נושא ה-Cross Site Scripting (נקרא גם XSS) – זו אחת השיטות הידועות ביותר לפרוץ לאתרים ורוב האתרים המסחריים בארץ חשופים לשיטה זו, לכן אם הנתונים חשובים לך, אז יש צורך בעדיפות עליונה להגן על האתר שלך נגד שיטת פריצה זו. אם אתה משתמש בדפדפן Firefox לדוגמא, אז תוסף XSS-ME יכול לבדוק את האתר שלך אם אתה פרוץ או לא בכל מיני מקומות באתרים שלך.
  13. עדכונים – חשוב תמיד לעדכן את המערכת שלך בעדכוני האבטחה האחרונים. עדכוני מערכת ניתן לעדכן בקלות בעזרת פקודת yum update (ב-CentOS) או apt-get upgrade בדביאן/אובונטו.
  14. לעקוב אחרי ה-Logs – בדרך כלל ניתן לראות היכן מתחילות הבעיות – ברישומי לוגים. אנשים עם מכונות אובונטו/דביאן מוזמנים לקרוא בנושא כאן. ב-CentOS יש פרק שלם על כך כאן.

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

זיכרו: עדכון, מעקב ומניעה – יכולים לתת לכם מכונה שתשרת אתכם לזמן רב בצורה יציבה.