טיפים לאבטחת אתרים (חלק 2 מתוך 2)

בחלק זה (החלק השני) אני אדבר יותר על שרתים. חלק זה מיועד לאנשי סיסטם שמכירים מעט ענייני אבטחה וגם לאלו שמכירים טוב סיסטם אך אינם בקיאים בכל עניין אבטחה. שימו לב: מדובר על אבטחת שרתים שנמצאים מחוץ למשרדי החברה (Hosting, Co-Location, VPS וכו'). אלו המעוניינים במידע בסיסי עבור אבטחה כלקוח שיש לו שרת באחסון משותף, כדאי להסתכל בחלק הראשון, כאן.

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

אתחיל מנקודה מעניינת שרבים מאנשי הסיסטם בחברות טועים בה: ההסתמכות על חומת האש של ספק האחסון. מדוע טועים? מכיוון שאין לכם כלקוחות שום שליטה או בקרה על חומת האש של ספק האחסון ותצטרכו לקחת את מילתו בנושא. אם חומת האש תיפול בין אם בצורה יזומה (תחזוקה לדוגמא) או בצורה מפתיעה (פריצה), במקרים רבים אתם לא תדעו על כך מהסיבה הפשוטה שספקי אחסון לא ששים לספר על כך ונדיר מאוד שחברות מוציאות הודעה מסודרת על כך. למען האמת, ב-20 שנה שאני נותן שרותי סיסטם, עוד לא יצא לי אפילו פעם אחת לקבל הודעה מספק אחסון שחומת האש שלו תהיה למטה או שחומת האש למטה מכל סיבה כלשהי. לכן, כששוכרים שרת או ששמים שרת אצל חברת אחסון, חובה להתקין חומת אש משלך, בין אם זה שרת וירטואלי או שרת פיזי. אם יש מס' שרתים אצל ספק האחסון, כדאי לדאוג לחומת אש אחת (לפחות) שתגן על השרתים. איזו חומת אש? פה כבר נכנסים שיקולים של עלות (האם לרכוש חומת אש כמו של צ'ק פוינט לדוגמא), שימוש במוצר מבוסס קוד פתוח (האם לבנות חומש אש על iptables של לינוקס, או להשתמש ב-pfsense מבוסס FreeBSD והאפשרויות רבות) וכו'. כל אחד ושיקוליו, אך חשוב לבנות חומת אש עם מינימום הכרחי של חוקים ולסגור את השאר. למהדרין כדאי להוסיף logging לחומת האש (לוג של תעבורה) ושהלוג ישלח יומית לאיש הסיסטם/אבטחה בחברה.

גישה לשרתים:

אם אלו שרתי לינוקס, מומלץ לשנות את פורט ה-SSH מ-22 לכל דבר אחר, ולא לאפשר כניסה ישירה של משתמש root מרחוק. כדאי להשתמש בתוכנת nmap על מנת לסרוק מקומית את השרת החדש ולבדוק ששרותים לא הכרחיים לא רצים. רבים לדוגמא לא מודעים שהתקנת ברירת מחדל של CentOS או RedHat מתקינה שרות X גרפי, שרות מדפסות CUPS, בלוטות' ושאר מרעין בישין שאותם מומלץ לבטל (ב-CentOS/RedHat לדוגמא, עצירת השרות מתבצעת עם פקודת service וביטול השרות מתבצע עם chkconfig) גם את המצב הגרפי מומלץ לבטל (אפשר לתקן זאת בקובץ etc/inittab/ בשורת ה-id לעבור מ-5 ל-3). יש לוודא כי אך ורק השרותים שאנו זקוקים להם רצים, וכך נחסוך בזבוז משאבים מיותר וסכנות אבטחה פוטנציאליות.

אם מדובר בשרת Windows וצריך שליטה על השרת ברמת RDP, כדאי להשתמש בהצפנה. המאמר כאן מ-Technet של מיקרוסופט מסביר כיצד לבצע זאת. אני הייתי ממליץ לשנות את הפורט של RDP מ-3389 לפורט אחר ואפשר לראות איך עושים זאת כאן.

נקודה שאולי כדאי לחשוב עליה היא VPN. ה-VPN בעצם מוסיף "שכבת הגנה" שחוסמת גישה לשרתים ויוצרת רשת פרטית וירטואלית. פעם זה היה דבר מאוד יקר, כיום יש פתרונות מבוססי קוד פתוח כמו OpenVPN שיחסית די קל להגדרה (ויש גם Client ל-Windows). שימוש ב-VPN לא רק שנותן אבטחה, אלא נותן את האפשרות לשלב את השרת ולעבוד עליו כאילו השרת נמצא ליידנו (מבחינת אינטגרציה).

הרשאות:

אחת מנקודות התורפה שפורצים רבים משתמשים בהם זו נקודת ההרשאות וסיסמאות. לעיתים עושים דברים מבלי לתכנן מקודם ואז יוצרים בשרתים משתמשים חדשים עם הרשאות יותר ממה שצריך, או שקובעים הרשאות ל-DB הרבה יותר ממה שצריך או שהסיסמאות קלות (יחסית) לפריצה: סיסמאות קצרות וצפויות (!@#$, qwerasdfzxcv, 1q2w3e4r, ושאר סיסמאות צפויות). סיסמאות צריכות להיות מורכבות לפחות מ-8 אותיות ומספרים ועדיף גם סימנים. אפשר לכתוב סקריפט שיצור סיסמאות או שאפשר להשתמש בשרות הזה לדוגמא, על מנת לקבוע סיסמאות. במקרים כמו SSH מומלץ לחשוב לעבור משימוש בסיסמאות לשימוש במפתחות ולמהדרין אפשר להשתמש גם עם כרטיסים חכמים. חשוב גם להשתמש בסיסמאות מסובכות בכל הקשור ל-SQL, FTP וכו' ולצערי ראיתי מקרים שפרצו לאנשים בגלל סיסמאות צפויות.

מעקב:

הנה נקודה שהרבה אנשים שחדשים בתחום הסיסטם לא מבצעים: מעקב אחר השרתים. עם לינוקס החיים יותר קליים, יש דבר כמו logwatch המדווח לך מדי יום מה קרה ב-24 שעות בשרתים שלך. מעקב יותר רציני אפשר לעשות עם כלים כמו TripWire ואחרים המאפשרים ניטור לראות אם המערכת שונתה ומי שינה מה (מבחינת כתובת IP וכו'). סוג כלים נוסף שחשוב להכיר ולהשתמש בו הוא סוג ה-IDS (ר"ת: Intrusion Detection System), ובו אפשר למצוא כלים כמו Snort, Saint וכו'. אלו כלים המאפשרים לך לסרוק את השרתים שלך מבחינת פריצות ידועות ולראות האם השרתים שלך ניתנים לפריצה ומה כדאי לשנות/להקשיח. חשוב לזכור: מעקב רציף, "נסיונות פריצה" יזומים ע"י בעל השרת הם חלק מאוד חשוב שמאפשר להגן ביתר יעילות על השרת שלך ועל התוכן שברשותך ובכך לחסוך נזק ואובדן פרודקטיביות.

קוד:

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

סיכום:

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

Comments

comments

11 תגובות בנושא “טיפים לאבטחת אתרים (חלק 2 מתוך 2)

  1. הייתי מוסף שמומלץ לבצע התקנה מינימלית של השרתים, וזאת כדי להוריד את כמות התוכנה עליהם. פחות תוכנה, פחות בעיות.
     

  2. מה קשור ססמאות מסובכות לftp? הרי בftp הכל עובר גם ככה בקליר טקסט אז לא משנה איזו ססמא מסובכת תשים..

    • ה-FTP היה רק דוגמא. אני כמובן ממליץ על שימוש ב-sftp או ב-Webdav אבל לא רציתי להתחיל להיכנס יותר מדי לפרטים.

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

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

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

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

  7. לגבי הפורט הSSH:
    אני לא רואה טעם בשינוי הפורט, מי שבאמת רוצה יוכל להשתמש בnmap כדי לגלות בקלות באיזה פורט רץ אצלך SSH.
    מה שכן, רצוי מאוד לאפשר כניסה עם מפתח ציבורי בלבד לשרת פרודקשן.
    יש מלא מידע על זה ברשת, למשל פה:
    http://sial.org/howto/openssh/publickey-auth/
     

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

  8. ידוע גם ידוע, ואפילו נכנסו לי פעם ככה לשרת:
    http://firefang.net/blog/1102
    אבל לשנות את הפורט לא יציל אותך ממישהו שתוקף אותך אישית.
    הפיתרון האמיתי נגד ניחוש סיסמאות הוא לבטל לחלוטין את האפשרות להכנס עם סיסמא ולעבוד עם מפתחות ציבוריים בלבד.

  9. הפתרון אל מול פריצה סיסמאות הוא להגביל את מספר הנסיונות ולתת באן לאחר מספר סיסמאות.
    בשום אופן לא לייצר חשבון FTP ל ROOT !!!!
    סיסמאות מורכבות כגון משפט מהחיים שכותבים באנגלים עם המרת אותיות, לדוגמה :
    נשרתי מקורס טיס, והסיסמה תהיה :
    nashart1m3kursta1s
    כזו סיסמה אפילו שמורכבת רק מאותיות קטנות קשה מאוד לפרוץ, כי היא ארוכה, האותיות ללא קשר עם מילים קיימות ממילון, והכי הכי חשוב לא סבירה.
    לפרנואידים ניתן לשלב אות גדולה לאחר כל סיפרה ובכך הסיסמה תהיה עוד יותר משוגעת, יתרונות: קל לזכור, חסרונות: שכחת נדפקת :).
    עוד מידע : שרת וירטואלי

סגור לתגובות.