שאלה איך אני מתמודד עם שרת שנפגע?


זה קנוניקל שאלה על שרת אבטחה - תגובה לאירועים הפרת (פריצה)
  ראה גם:

גרסה קנונית
אני חושד שאחד או יותר מהשרתים שלי נפגעים על ידי מנגנון האקרים, וירוסים או מנגנונים אחרים:

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

גרסה מקורית 

2011.01.02 אני בדרך לעבודה בשעה 9.30. ביום ראשון כי השרת שלנו כבר בסכנה איכשהו היה וכתוצאה מכך    DOS התקפה על ספק שלנו. השרתים ניגשים לאינטרנט   נסגר כלומר מעל 5-600 של אתרי הלקוחות שלנו כיום   מטה. עכשיו זה יכול להיות גרזן FTP, או חולשה כלשהי בקוד   אי שם. אני לא בטוח עד שאגיע לשם.

איך אני יכול לעקוב אחר זה במהירות? אנחנו נמצאים הרבה מאוד   ליטיגציה אם אני לא מקבל את השרת לגבות בהקדם האפשרי. כל עזרה היא   מוערך. אנו מפעילים את Open SUSE 11.0.


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

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

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

אז היינו יכולים לזהות את הקובץ הפוגע שהיה בתוך   תיקיית תמונות שהועלה בתוך ZenCart אתר אינטרנט.

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

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

העבודה נעשתה, ואני הייתי בבית במשך 2:00.


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


578
2018-01-02 21:31




אני יודע איך אתה מרגיש - אנחנו כבר בר מזל עם האקרים "מועיל" באתר זה, שם הם אומרים לנו מה הם עשו! אני מצפה לתשובות טובות לשאלה זו, רק למקרה שנקבל אורחים "לא כל כך מועילים" בעתיד. - Jarrod Dixon♦
התקשר מקצועי כדי לעזור! - marcog
אני לא רוצה להישמע חכם או לא אוהד (אני לא), וכמובן אני בורים על הפרטים של המצב שלך, אבל אם אתה האדם היחיד אחראי על הגדרת אתר 500-600, אולי להיות פגם בסיסי איך שרת זה מופעל. חברות מסוימות מעסיקות מסדר ייעודי שלא עושה שום דבר אחר כל היום, אבל לשמור על שרתים - משימה שהיא לא באופן אוטומטי בטווח של מתכנת, למרות שזה אולי נראה ככה. אולי זה משהו ששווה לשקול כאשר המשבר נגמר. בכל מקרה, ברגע זה, הטוב ביותר של מזל לקבל את המצב ביד לפתור. - Pekka 웃
Dont בהכרח להניח שיש לך מלא שורש ליבה ערכת השורש ואת סיסמת השורש שלך נפגעת. אולי רק שלה ערמומי bash / perl סקריפט, וזה אפשרי לנקות אותו ללא formating למרות מה המקהלה נבל על על כאן ... serverfault.com/questions/639699/... - Hayden Thring


תשובות:


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

אין פאניקה

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

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

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

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

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

אתה פשוט גילית כי השרת שלך (ים) יש פרוצים. עכשיו מה?

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

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

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

עצור את הבעיה מלהיות יותר גרוע ממה שהיא כבר:

  1. הדבר הראשון שאתה צריך לעשות הוא לנתק את המערכות המושפעות מהאינטרנט. כל בעיה אחרת שיש לך, להשאיר את המערכת מחוברת לאינטרנט רק לאפשר להתקפה להמשיך. זאת אומרת, פשוטו כמשמעו; לקבל מישהו פיזית לבקר את השרת ולנתק כבלים לרשת אם זה מה שנדרש, אבל לנתק את הקורבן מן השודדים שלה לפני שאתה מנסה לעשות שום דבר אחר.
  2. שנה את כל הסיסמאות עבור כל החשבונות בכל המחשבים הנמצאים באותה רשת כמו במערכות שנפגעו. לא ממש. כל החשבונות. כל המחשבים. כן, אתה צודק, זה עלול להיות overkill; מצד שני, זה אולי לא. ללא שם: אתה לא יודע בכל מקרה, נכון?
  3. בדוק את המערכות האחרות שלך. הקדש תשומת לב מיוחדת לשירותים אחרים הפונים לאינטרנט, ולאלו המחזיקים בנתונים פיננסיים או נתונים רגישים אחרים.
  4. אם המערכת מחזיקה בנתונים האישיים של כל אדם, עליך להודיע ​​מיד לאדם האחראי להגנת נתונים (אם זה לא אתה) ולגייס גילוי מלא. אני יודע שזה קשה. אני יודע שזה יכאב. אני יודע כי עסקים רבים רוצים לטאטא את זה סוג של בעיה מתחת לשטיח אבל העסק הולך להתמודד עם זה - ואת צריכה לעשות זאת עם עין על כל וכל חוקי הפרטיות הרלוונטיים.

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

זוכר מה אמרתי קודם? הדבר הרע כבר קרה. השאלה היחידה עכשיו היא כמה טוב לך להתמודד עם זה.

הבנת הבעיה במלואה:

  1. לא לשים את המערכות המושפעות בחזרה באינטרנט עד שלב זה הוא מלא, אלא אם כן אתה רוצה להיות אדם אשר היה לכתוב את נקודת המפנה לי בעצם מחליט לכתוב את המאמר הזה. אני לא הולך לקשר את ההודעה כי אנשים יכולים לקבל צחוק זול, אבל הטרגדיה האמיתית היא כאשר אנשים נכשלים ללמוד מן הטעויות שלהם.
  2. בחן את המערכות המותקפות כדי להבין כיצד ההתקפות הצליחו לפגוע בביטחונך. לעשות כל מאמץ כדי לגלות איפה התקפות "בא", כך שאתה מבין מה יש לך בעיות צריך כתובת כדי להפוך את המערכת שלך בטוח בעתיד.
  3. בחן שוב את המערכות המותקפות, הפעם כדי להבין לאן התקפות, כך שתבין אילו מערכות נפגעו בהתקפה. ודא שאתה עוקב אחר כל מצביעים המציעים מערכות שנפגעו יכול להיות קרש קפיצה לתקוף את המערכות שלך עוד יותר.
  4. ודא את "שערי" המשמשים כל ההתקפות כל מובנים לחלוטין, כך שתוכל להתחיל לסגור אותם כראוי. (למשל אם המערכות שלך היו בסכנה על ידי התקף הזרקת SQL, אז לא רק אתה צריך לסגור את שורת פגום מסוים של קוד שהם פרצו על ידי, אתה רוצה לבדוק את כל הקוד שלך כדי לראות אם אותו סוג של טעות נעשתה במקום אחר).
  5. הבינו כי התקפות עשויות להצליח בגלל יותר מפגם אחד. לעתים קרובות, התקפות מצליחות לא באמצעות מציאת באג אחד גדול במערכת אלא על ידי חיבור מספר נושאים (לפעמים קטנים וקטנים כשלעצמם) על מנת לפגוע במערכת. לדוגמה, באמצעות התקפות הזרקת SQL לשלוח פקודות לשרת מסד נתונים, לגלות את האתר / יישום אתה תוקף פועל בהקשר של משתמש מינהלי באמצעות זכויות של החשבון הזה כמו אבן דריכה כדי להתפשר על חלקים אחרים של מערכת. או כמו האקרים כמו לקרוא לזה: "עוד יום במשרד ניצול של טעויות נפוצות אנשים לעשות".

למה לא רק "לתקן" את לנצל או rootkit זיהית והכניס את המערכת בחזרה באינטרנט?

במצבים כאלה הבעיה היא כי אין לך שליטה על המערכת יותר. זה כבר לא המחשב שלך.

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

הפוך תוכנית להחלמה ולהביא את אתר האינטרנט שלך בחזרה באינטרנט לדבוק בה:

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

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

  1. אני מניח שהבנת את כל הבעיות שהובילו לחדירה מוצלחת מלכתחילה לפני שאתה אפילו להתחיל את החלק הזה. אני לא רוצה להפריז במקרה, אבל אם לא עשית את זה קודם אז אתה באמת צריך. מצטער.
  2. לעולם אל תשלם סחיטה / הגנה כסף. זהו סימן של סימן קל ואתה לא רוצה את הביטוי פעם השתמשו כדי לתאר אותך.
  3. אל תתפתו לשים את אותו שרת (ים) בחזרה באינטרנט ללא לבנות מחדש. זה צריך להיות הרבה יותר מהר כדי לבנות תיבה חדשה או "nuke השרת מן המסלול ולעשות התקנה נקייה" על החומרה הישנה יותר מאשר יהיה לבדוק כל פינה אחת של המערכת הישנה כדי לוודא שהוא נקי לפני לשים אותו בחזרה באינטרנט שוב. אם אתה לא מסכים עם זה אז אתה בטח לא יודע מה זה באמת אומר כדי להבטיח מערכת ניקה לחלוטין, או ההליכים שלך באתר הפריסה הם בלגן קדוש. אתה כנראה יש גיבויים ופריסות הבדיקה של האתר שלך, כי אתה יכול פשוט להשתמש כדי לבנות את האתר חי, ואם אתה לא אז להיות פריצה היא לא הבעיה הכי גדולה שלך.
  4. היזהר מאוד לגבי שימוש חוזר בנתונים שהיו "חיים" על המערכת בזמן גרזן. אני לא אומר "אף פעם לא לעשות את זה" כי אתה פשוט להתעלם ממני, אבל בכנות אני חושב שאתה צריך לשקול את ההשלכות של שמירה על נתונים סביב כאשר אתה יודע שאתה לא יכול להבטיח את שלמותה. באופן אידיאלי, אתה צריך לשחזר את זה מגיבוי שנעשה לפני החדירה. אם אתה לא יכול או לא תעשה את זה, אתה צריך להיות זהיר מאוד עם הנתונים כי זה נגוע. אתה צריך להיות מודע במיוחד את התוצאות לאחרים, אם הנתונים שייכים ללקוחות או מבקרים באתר ולא ישירות אליך.
  5. לפקח על המערכת (ים) בזהירות. אתה צריך לפתור את זה כתהליך מתמשך בעתיד (יותר בהמשך), אבל אתה לוקח עוד כאבים להיות ערניים במהלך התקופה מיד לאחר האתר שלך חוזר מקוון. הפולשים יהיו כמעט בוודאות לחזור, ואם אתה יכול לזהות אותם מנסה לפרוץ שוב אתה בהחלט יוכל לראות במהירות אם אתה באמת סגר את כל החורים הם השתמשו לפני פלוס כל שהם עשו לעצמם, ואתה יכול לאסוף שימושי מידע שאתה יכול להעביר על אכיפת החוק המקומי שלך.

צמצום הסיכון בעתיד.

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

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

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

לדוגמה:

  1. האם הפגם הוא שאיפשר לאנשים לפרוץ לאתר שלך באגים ידועים בקוד ספק, שעבורו היה תיקון זמין? אם כן, האם אתה צריך לחשוב מחדש על הגישה שלך איך אתה תיקון יישומים על האינטרנט שלך מול שרתים?
  2. האם הפגם שאפשר לאנשים לפרוץ לאתר שלך באג לא מוכר בקוד הספקים, שעבורו תיקון לא היה זמין? אני בהחלט לא תומך לשנות ספקים בכל פעם משהו כמו זה נושך אותך כי לכולם יש את הבעיות שלהם ואתה מפעיל את הפלטפורמות בשנה לכל היותר אם אתה לוקח את הגישה הזאת. עם זאת, אם מערכת כל הזמן מאפשר לך לרדת אז אתה צריך לעבור משהו חזק יותר או לכל הפחות, מחדש אדריכל המערכת שלך, כך רכיבים פגיעים להישאר עטוף צמר גפן רחוק ככל האפשר מן העיניים העוינות.
  3. האם פגם באג בקוד שפותח על ידך (או קבלן עובד בשבילך)? אם כן, האם עליך לחשוב מחדש על הגישה שלך לאופן שבו אתה מאשר קוד להפעלה אל האתר החי שלך? האם הבאג נתפס עם מערכת בדיקה משופרת, או עם שינויים "תקן" קידוד שלך (למשל, בעוד הטכנולוגיה היא לא תרופת פלא, אתה יכול להפחית את ההסתברות של התקפה מוצלחת הזרקת SQL באמצעות טכניקות קידוד מתועד היטב ).
  4. האם הפגם נובע מבעיה עם אופן הפריסה של שרת או תוכנת היישומים? אם כן, האם אתה משתמש בהליכים אוטומטיים לבנייה ופריסה של שרתים במידת האפשר? אלה הם עזרה רבה בשמירה על עקבי "בסיס" המדינה על כל השרתים שלך, למזער את כמות העבודה המותאמת אישית שיש לעשות על כל אחד ולכן אני מקווה למזער את ההזדמנות לטעות לעשות. כך גם עם פריסת קוד - אם אתה צריך משהו "מיוחד" לעשות כדי לפרוס את הגרסה האחרונה של יישום האינטרנט שלך ואז לנסות קשה כדי להפוך אותו ולוודא שזה תמיד נעשה באופן עקבי.
  5. האם החדירה נתפסה קודם לכן עם ניטור טוב יותר של המערכות שלך? כמובן, ניטור 24 שעות או "על שיחה" המערכת עבור הצוות שלך לא יכול להיות חסכוני, אבל יש חברות שם בחוץ שיכולים לפקח על האינטרנט שלך מול שירותים בשבילך להתריע לך במקרה של בעיה. אתה יכול להחליט שאתה לא יכול להרשות לעצמך את זה או לא צריך את זה וזה בסדר גמור ... פשוט לקחת את זה בחשבון.
  6. השתמש בכלים כגון tripwire ו nessus לפי הצורך - אבל לא פשוט להשתמש בהם בעיוורון, כי אמרתי את זה. קח את הזמן כדי ללמוד כיצד להשתמש כמה כלי אבטחה טובים המתאימים לסביבה שלך, לשמור על כלים אלה מעודכנים ולהשתמש בהם על בסיס קבוע.
  7. שקול להעסיק מומחים אבטחה 'ביקורת' האבטחה באתר שלך על בסיס קבוע. שוב, אתה יכול להחליט שאתה לא יכול להרשות לעצמך את זה או לא צריך את זה וזה בסדר גמור ... פשוט לקחת את זה בחשבון.

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

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

  1. האם אתה יכול לצמצם את כמות השירותים שנחשפו ישירות לאינטרנט? האם אתה יכול לשמור על איזה פער בין השירותים הפנימיים שלך לבין שירותי האינטרנט שלך? זה מבטיח שגם אם המערכות החיצוניות שלך נפגעת הסיכויים להשתמש זה כמו קרש קפיצה לתקוף את המערכות הפנימיות שלך מוגבלים.
  2. האם אתה מאחסן מידע שאינך צריך לאחסן? האם אתה מאחסן מידע כזה "מקוון" כאשר הוא יכול להיות בארכיון במקום אחר. יש שתי נקודות לחלק זה; את אחד ברור כי אנשים לא יכולים לגנוב ממך מידע כי אין לך, ואת הנקודה השנייה היא שככל שאתה פחות לאחסן, פחות אתה צריך לשמור על קוד עבור, ולכן יש פחות סיכוי באגים כדי להחליק לתוך את הקוד או עיצוב מערכות.
  3. האם אתה משתמש בעקרונות "גישה פחותה" עבור אפליקציית האינטרנט שלך? אם משתמשים רק צריכים לקרוא מתוך מסד נתונים, ולאחר מכן לוודא את החשבון יישום האינטרנט משתמש לשירות זה יש רק גישה לקריאה, לא מאפשרים גישה לכתוב ובוודאי לא גישה ברמת המערכת.
  4. אם אתה לא מנוסה מאוד על משהו וזה לא מרכזי לעסק שלך, לשקול מיקור חוץ זה. במילים אחרות, אם אתה מפעיל אתר אינטרנט קטן מדבר על כתיבת קוד יישום שולחן העבודה ולהחליט להתחיל למכור יישומי שולחן עבודה קטנים מהאתר ולאחר מכן לשקול "מיקור חוץ" כרטיס האשראי שלך מערכת ההזמנה למישהו כמו Paypal.
  5. אם בכלל אפשרי, הפוך להתאמן להתאושש מערכות נפגעת חלק של התוכנית שלך התאוששות מאסון. זה יכול להיות רק עוד "תרחיש אסון" כי אתה יכול להיתקל, פשוט אחד עם קבוצה משלו של בעיות ונושאים נבדלים מן הרגיל "חדר השרת נתפס" / "היה פלשו על ידי שרת ענק אוכל furbies" סוג של דבר.

... ולבסוף

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

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


988
2018-01-02 21:46



+1 עבור פוסט מעולה יש על היד כדי לגרום לאנשים להתחיל בכיוון. אני יודע כמה נפוץ עבור מנהלי השרתים חובבים להיכנס למצב זה פאניקה בפעם הראשונה יש להם "גרזן" לקרות להם. זה ענק טעות להיות במקום הזה, אבל זה קורה. התקווה היא שזה לא יקרה לאותו אדם, פעמיים. - Andrew Barber
+1 "... אבל זה לא הזמן לתת לאגו שלך להגיע בדרך של מה שאתה צריך לעשות." זה חשוב עבור מנהלי Sys להבין לפעמים. לא משנה עד כמה אתה ידע, יש תמיד אלה (לפעמים זדוניים) מי הם יותר ידע או חכם יותר ממך. - Grahamux
תשובה טובה. אני לא בטוח למה כולם מתייחסים "צעד אכיפת החוק" צעד אופציונלי אם כי. אם אתה אחראי לנתונים של אנשים אחרים (ומודאגים מהתדיינות משפטית), זה אמור להיות אחד הדברים הראשונים ברשימת הפעולות שאתה צריך לעשות. - wds
טוב מאוד לכתוב, רק אחד gotcha - "לעשות גילוי מלא וגלויה לכל אדם מושפע באופן מיידי." כבוד, אבל לא תמיד נכון. בתגובה לפשרה, ייתכן שיהיה עליך לחתוך כמה פינות ממשל, והחברה שלך בדרך כלל לחתוך לך קצת רפיון, עם זאת ... גילוי או לא, במיוחד כאשר יש השלכות הגנה על נתונים עשוי להיות עניין מעל הציון שלך לשלם ו יכולות להיות לה השלכות משפטיות. עדיף להציע לך מיד ליידע את האדם אחראי להגנת נתונים (אם זה לא אתה) ו URGE גילוי מלא. - TheoJones
@GilesRoberts המארחים מכונה וירטואלית בדרך כלל יש לוח בקרה המאפשר לך לתפעל את ההגדרות של האורחים שלהם, ואפילו שלט רחוק אותם ללא שימוש RDP או SSH כדי להיכנס בפועל לאורח. אתה אמור להיות מסוגל לבודד את האורח באמצעות פקדים של המארח לעשות זאת ולאחר מכן להשתמש בכלי צפייה מרחוק שלה לחקור את האורח בשעות הפנאי שלך. - Rob Moir


זה נשמע כאילו הם קצת מעל הראש שלך; זה בסדר. התקשר אל הבוס שלך והתחל במשא ומתן על תקציב חירום לאבטחה. $ 10,000 יכול להיות מקום טוב להתחיל בו. אז אתה צריך לקבל מישהו (PFY, עמית לעבודה, מנהל) כדי להתחיל להתקשר לחברות המתמחות בתגובה אבטחה האירוע. רבים יכולים להגיב תוך 24 שעות, ולפעמים אפילו מהר יותר אם יש להם משרד בעיר שלך.

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

לאחר מכן, אתה צריך ...

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

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

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

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

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

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

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

יש לך את הנחמות שלי על המצב שלך. בהצלחה.


199
2018-01-02 22:16



+1 תשובה מצוינת. זה נשמע כמו OP אין תגובה מוגדרת מראש "חירום" ואת ההודעה שלך, בין דברים טובים אחרים, צריך להצביע עליהם לקראת מקבל את זה להגדיר. - Rob Moir


ל- CERT יש מסמך צעדים להתאוששות מ UNIX או NT מערכת פשרה זה טוב. הפרטים הטכניים הספציפיים של מסמך זה הם מעט מיושנים, אבל הרבה עצות כלליות עדיין חל ישירות.

סיכום מהיר של הצעדים הבסיסיים הוא זה.

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

אני רוצה להפנות אותך באופן ספציפי לסעיף E.1.

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

אם אין לך מערכת כבר במקום כמו tripwire אין דרך אפשרית לך להיות 100% בטוח שיש לך ניקה את המערכת.


105
2018-05-08 09:02



גם אז tripwire יכול להיות fooled עם מודולים ליבה כאלה. התקן מחדש. - reconbot
השאלה בנושא בנושא איך להגיב במשבר עשוי גם להיות שימושי כאן. - Zoredache


  1. לזהות הבעיה. קרא את היומנים.
  2. כולל. ניתקת את השרת, כך שזה נעשה.
  3. לבער. התקן מחדש את המערכת המושפעת, קרוב לוודאי. לא למחוק את הכונן הקשיח של אחד פרוצים אף, השתמש אחד חדש. זה בטוח יותר, וייתכן שתזדקק לזקן כדי לשחזר פריצות מכוערות שלא גובו, ולעשות פלילי כדי לגלות מה קרה.
  4. שחזר. התקן את כל הדרוש לך לשחזר גיבויים כדי לקבל את הלקוחות שלך באינטרנט.
  5. מעקב. להבין מה היתה הבעיה, ולמנוע ממנה לקרות שוב.

64
2018-01-02 21:49





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

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

עם זאת, אתה כמעט בוודאות רק קורבן של תסריטאי kiddy שרצה כרית השיגור של התקפות DoS, או משמרות IRC, או משהו לגמרי לא קשור לאתרים של הלקוחות שלך נתונים. לכן, כצעד זמני בזמן הבנייה מחדש, ייתכן שתשקול להעלות את חומת האש היוצאת על התיבה שלך. אם אתה יכול לחסום את כל חיבורי UDP ו- TCP היוצאים שאינם נחוצים לחלוטין לתפקוד האתרים שלך, תוכל בקלות להפוך את התיבה הנפרעת שלך לחסרת תועלת לכל מי שמלווה אותה ממך, ולהפחית את ההשפעה על הרשת של הספק שלך לאפס.

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

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

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

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


49
2018-01-03 13:48





אתה צריך להתקין מחדש. שמור את מה שאתה באמת צריך. אבל יש לזכור כי כל הקבצים runnable שלך ​​עלול להיות נגוע ו טמבל. כתבתי את הדברים הבאים בפייתון: http://frw.se/monty.py אשר יוצר MD5-sumbs של כל הקבצים שלך בספרייה נתון בפעם הבאה שאתה מפעיל אותו, הוא בודק אם משהו השתנה ולאחר מכן פלט מה הקבצים השתנו מה השתנה בקבצים.

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

אבל הדבר היחיד שאתה צריך לעשות עכשיו, הוא הסרת המחשב מהאינטרנט.


38
2018-05-08 08:02



ללא שם: אז ... יישמת tripwire. - womble♦
כן, משהו לא בסדר עם זה? - Filip Ekberg
+1 לנתק, לנתח (לגרום למישהו לעשות פלילי אמיתי על זה) ולנגב - Oskar Duveborn
בהינתן הבחירה בין סקריפט פייתון אנונימי לבין פתרון סטנדרטי, נתמך (במידה מסוימת), נתמך היטב, אתה מקווה שהם יבחר את הראשון? - tripleee


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

במתקנים האקדמיים שלנו יש לנו כ -300 חוקרים שעושים רק חישוב. יש לך 600 לקוחות עם אתרי אינטרנט כך הפרוטוקול שלך יהיה כנראה שונה.

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

  1. זהה שהתוקף הצליח להשיג שורש (הרשאות גבוהות)
  2. נתק את השרתים המושפעים. רשת או כוח? בבקשה תראה דיון נפרד.
  3. בדוק את כל המערכות האחרות
  4. אתחול השרתים המושפעים מתקליטור חי
  5. (אופציונאלי) תפוס את התמונות של כל כונני המערכת עם dd
  6. התחל לעשות את הזיהוי שלאחר המוות. תראו את יומנים, להבין את הזמן של ההתקפה, למצוא קבצים ששונו באותו זמן. נסו לענות איך? שאלה.

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

גם אם "כל backdoors ו rootkits מנוקים למעלה", אל תסמוך על מערכת זו - להתקין מחדש מאפס.


34
2018-05-18 22:36



-1 לנתק את השרת מן החשמל? יש לך רק איבד חצי של נתונים משפטיים שלך! - Josh Brower
@Josh, אני מותאם את התשובה שלי - עכשיו זה ניטרלי על מה לנתק את השאלה. - Aleksandr Levchuk
יכולות זיהוי פלילי של RAM (למשל / dev / shm) יכולות להיות מועילות. אני מעדיף לנתק את כבל החשמל (אבל נסה להיכנס rsync / proc ממש לפני). אנו יכולים גם להציג תמונות VM תכופות, כך שניתן יהיה לעשות זאת באמצעות זיהוי פלילי של זיכרון RAM. הסיבות ללכת על כבל החשמל הם (1) כאשר אתה עושה פלילי במערכת פרוצים, אתה "דורך בכל זירת הפשע"; (2) ערכת השורש ממשיכה לפעול - לא כל כך קשה לזדוני לבצע משהו (למשל, מחיקת מערכת) ב- קישור רשת למטה אירוע. קייל רנקין במבוא היפה שלו לזיהוי פלילי (goo.gl/g21Ok) מומלץ למשוך את כבל החשמל. - Aleksandr Levchuk
אין גודל אחד מתאים לכל פרוטוקול IR - ארגונים מסוימים אולי יצטרכו לשמור על מערכת נפגעת באינטרנט במשך זמן רב יותר, מכל סיבה שהיא. (RAM & temp יומן פלילי, אינטראקציה עם הפולשים, וכו ') הנקודה שלי היא שזה יהיה טוב יותר להמליץ ​​על פרוטוקול IR גנרי (כמו Jakob Borgs לעיל) ולא אחד שמתחיל עם "משוך את תקע החשמל של השרת שנפגע. " - Josh Brower


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

פורמט זה גור.

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

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

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

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


28
2018-01-03 14:31



'עיצוב זה גור'. - +1, ייעוץ מרווה. ראה גם: "Nuke זה ממסלול, זו הדרך היחידה להיות בטוח." - Avery Payne