יציאה 6379: Redis

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

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

הנחת האמון

Redis תוכננה לעולם שכבר לא קיים — עולם שבו "מאחורי חומת האש" פירושו "מהימן".

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

אז Redis שוחררה ללא דרישת סיסמה. היא קיבלה חיבורים מכל כתובת IP. היא העניקה לכל לקוח גישה מנהלתית מלאה.

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

מה קורה ל-Redis חשוף

שיטת הפעולה של התוקפים כמעט אלגנטית בפשטותה.

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

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

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

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

מה Redis באמת עושה

Redis (Remote Dictionary Server) הוא מאגר מפתח-ערך בזיכרון. אתה נותן לו מפתח, הוא מחזיר לך ערך — במיקרושניות במקום מילישניות.

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

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

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

תכונות בזמן אמת: הודעות pub/sub לצ'אט, התראות ועדכונים חיים. סטים ממוינים ללוחות תוצאות ודירוגים. מונים להגבלת קצב ואנליטיקס.

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

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

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

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

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

וכאשר נחשפות פגיעויות ב-Redis (הן קיימות בכל תוכנה), מופעים הפונים לאינטרנט עלולים להיות מנוצלים לפני שאפילו קראת את ייעוץ האבטחה.

התשובה פשוטה: Redis שייכת מאחורי חומת האש שלך. היא נקשרת ל-localhost או לכתובת IP פרטית. היא מקבלת חיבורים רק משרתי אפליקציות שאתה שולט בהם. אם אתה צריך גישה מרחוק, אתה משתמש ב-VPN או במנהרת SSH. אין תרחיש שבו Redis צריכה לקבל חיבורים מכתובות אינטרנט שרירותיות.

אימות שבאמת עובד

Redis מודרני (גרסה 6.0 ומעלה) מציע בקרת גישה אמיתית.

הדרך הישנה הייתה סיסמה יחידה לכולם. הגדר requirepass בתצורה שלך, ולקוחות שולחים AUTH <password> לפני הרצת פקודות. טוב מאשר כלום, אבל גס — סיסמה אחת, גישה מלאה לאחר אימות.

רשימות בקרת גישה (ACL) שינו זאת. אתה יכול ליצור מספר משתמשים עם סיסמאות שונות והרשאות שונות:

ACL SETUSER readonly on >secret1 ~cache:* +get +ttl
ACL SETUSER appserver on >secret2 ~* +@all
ACL SETUSER monitor on >secret3 +info +ping

המשתמש לקריאה בלבד יכול להריץ רק GET ו-TTL על מפתחות שמתחילים ב-cache:. לשרת האפליקציות יש גישה מלאה. המוניטור יכול רק לבדוק אם Redis פעיל. אם אישור אחד דולף, הנזק מוגבל.

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

הצפנה בתעבורה

Redis גרסה 6.0 גם הוסיפה תמיכה מובנית ב-TLS.

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

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

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

הגנה לעומק

אבטחת Redis אינה דבר אחד. היא שכבות.

רשת: קשור ל-127.0.0.1 או לממשק פרטי, לעולם לא ל-0.0.0.0. כללי חומת אש המאפשרים רק לשרתי אפליקציות מוכרים. באופן אידיאלי, Redis חי בפלח רשת משלו.

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

פקודות מסוכנות: שנה שם או השבת את FLUSHALL, FLUSHDB, CONFIG, DEBUG, SHUTDOWN. אם האפליקציה שלך לא צריכה אותן, הן לא צריכות להתקיים.

rename-command FLUSHALL ""
rename-command CONFIG "INTERNAL_CONFIG_a8f3e9b2"

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

הרשאה מינימלית: הפעל את Redis כמשתמש ללא הרשאות. אם נפרץ, התוקפים יורשים רק את ההרשאות המוגבלות הללו.

עדכונים: הירשם לעדכוני האבטחה של Redis. תקן בהקדם. יהיה לך תהליך מסודר.

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

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

מה Redis מלמדת אותנו

Redis ביציאה 6379 היא שיעור בהנחות.

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

Redis הסתגלה. גרסה 3.2 הוסיפה מצב מוגן שמסרב לחיבורים חיצוניים אלא אם מגדירים אימות במפורש. גרסה 6.0 הוסיפה ACLs ו-TLS. ברירות המחדל הפכו לבטוחות יותר.

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

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

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

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

שאלות נפוצות על אבטחת Redis

מדוע יציאה 6379 ממוקדת באופן ספציפי על ידי תוקפים?

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

האם ניתן לאבטח את Redis עם סיסמה חזקה בלבד?

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

מה ההבדל בין Redis AUTH ל-ACLs?

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

האם Redis בטוח לשימוש בסביבת ייצור?

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

כיצד אדע אם מופע Redis שלי חשוף?

הרץ redis-cli -h <your-public-ip> -p 6379 ping מחוץ לרשת שלך. אם הוא מגיב עם "PONG" ללא אימות — יש לך בעיה. בדוק גם את קבוצות האבטחה וכללי חומת האש של ספק הענן שלך. ועוד יותר טוב — השתמש בכלי כמו Shodan כדי לראות מה האינטרנט רואה לגבי התשתית שלך.