Cyber & Code

🔒💥🖥️  חשיפה: פרצה חדשה ב-Windows הופכת שרתים ציבוריים לצבא בוטנט להאקרים  משפט פתיחה:  חוקרי אבטחה גילו שיטה חדשה להפוך שרתי Windows ציבוריים לצבא בוטנט שמסוגל לבצע מתקפות DDoS עוצמתיות - ללא צורך בפריצה או בתשתית ייעודית.  🔍 מה קרה?  🔹 חוקרי SafeBreach חשפו פרצה קריטית ב-Windows המכונה "Win-DDoS", המנצלת פרוטוקולי RPC ו-LDAP כדי להשתלט מרחוק על שרתי Domain Controllers (DCs) 🕵️♂️  🔹 ההתקפה מאפשרת להפוך אלפי שרתים ציבוריים ברחבי העולם לבוטנט זדוני - ללא צורך בביצוע קוד או בהתחברות לחשבונות מנהל 👾  🔹 ההאקר שולח פקודת RPC לשרתים, שגורמת להם להפציץ שרת קורבן בבקשות LDAP חוזרות - עד להפלתו 💣  🔹 הפרצה מסוכנת במיוחד כי אינה דורשת רכישת תשתית או השארת עקבות - מה שמקשה על זיהוי וחסימה 🚨  🔹 התגלו גם 4 פרצות DoS נוספות ב-Windows (כולל CVE-2025-26673) הגורמות לקריסת שרתים מרחוק - חלקן דורשות רק גישה בסיסית לרשת 🛑  🔹 החוקרים מזהירים: הפרצה שוברת הנחות יסוד באבטחת ארגונים, כי מערכות פנימיות נחשבו "בטוחות" מניצול דומה ⚠️  🔹 מיקרוסופט כבר הוציאה טלאים - אך האיום עדיין רלוונטי לשרתים שלא עודכנו 🔄  (הכתבה פורסמה במקור ב-The Hacker News) 📜 לכתבה המלאה: 🔗 thehackernews.com 📢 הצטרפו לקבוצה שלנו לדיונים ועדכונים נוספים! 🔗 Cyber Security Coding שמרו על עצמכם! 🛡️🚀

פוסט 5/5: 🗺️⚖️ ניתוח מקרה: מאחורי הקלעים של שיחת וואטסאפ (חלק ב' - זרימת המדיה והפשרות) ⚖️🗺️ בפוסט הקודם, השארנו את שני המכשירים במצב מוכנות מלא: תהליך האיתות (Signaling) הושלם, מפתח הצפנה סודי ומשותף נוצר, ורשימות של נתיבי תקשורת פוטנציאליים (מועמדי ICE) הוחלפו. כעת, כשהשיחה נענית, תהליך ה-ICE כבר סיים את בדיקות הקישוריות שלו ברקע ובחר את הנתיב האופטימלי. בפוסט זה, נבחן את שתי התוצאות האפשריות לזרימת המידע (Data Plane) ונסכם את הפשרות הארכיטקטוניות המורכבות שכל אפליקציית תקשורת מודרנית נאלצת לבצע. פרקטיקה: ניתוח נתיבי המדיה האפשריים תהליך ה-ICE יבחר באחד משני הנתיבים המרכזיים הבאים להעברת האודיו והווידאו שלכם: נתיב A (העדיפות העליונה): חיבור P2P (Peer-to-Peer) ישיר זהו התרחיש המועדף והאידיאלי, שאליו ICE שואף תמיד. מתי הוא מתרחש? כאשר בדיקות הקישוריות של ICE מצליחות בין מועמדי ה-Host או ה-Server-Reflexive של שני המכשירים. הדבר אפשרי לרוב כאשר לפחות אחד מהצדדים נמצא מאחורי NAT שאינו מסוג Symmetric. איך זה עובד? חבילות המידע של השיחה, לאחר שהוצפנו באמצעות המפתח הסודי שנוצר, נשלחות ישירות ממכשיר א' למכשיר ב' דרך רשת האינטרנט. שרתי וואטסאפ אינם מעורבים כלל בהעברת המידע עצמו. יתרונות טכניים ועסקיים: יLatency נמוך: זהו הנתיב הקצר והישיר ביותר בין שני המשתמשים. התוצאה היא זמן השהייה מינימלי, שמתורגם לאיכות שיחה גבוהה, סנכרון טוב בין קול לתמונה וחווית שיחה טבעית יותר. עלות תפעולית אפסית (עבור Meta): מכיוון שהתעבורה אינה זורמת דרך השרתים של Meta (פייסבוק), החברה חוסכת סכומי עתק על רוחב פס יקר. נתיב B (תוכנית הגיבוי): חיבור דרך שרת ממסר (Relay) באמצעות TURN זהו נתיב הפשרה, שנבחר רק כאשר כל ניסיונות החיבור הישיר נכשלים. מתי הוא מתרחש? כאשר ICE לא מוצא שום נתיב P2P ישיר שעובד. התרחיש הנפוץ ביותר הוא שני משתמשים שכל אחד מהם נמצא מאחורי Symmetric NAT או חומת אש ארגונית מגבילה. במקרה זה, זוג המועמדים שנבחר יהיה מסוג Relayed. איך זה עובד? מכשיר א' שולח את חבילות המידע המוצפנות שלו אל שרת TURN של וואטסאפ. השרת פועל כ"שליח עיוור" – הוא מקבל את החבילה ומעביר אותה הלאה למכשיר ב', ללא כל יכולת לראות את תוכנה. דגש אבטחה: חשוב להזכיר שוב *לטענתם* גם בנתיב זה, ההצפנה מקצה-לקצה (E2EE) נשמרת במלואה. השרת רואה רק תעבורה מוצפנת ואינו יכול לפענח את השיחה. חסרונות טכניים ועסקיים: יLatency גבוה יותר: המסלול שהמידע עובר ארוך (מכשיר א' שרת TURN מכשיר ב'), מה שמוסיף זמן השהייה ועלול לפגוע באיכות השיחה. עלות תפעולית גבוהה (עבור Meta): החברה צריכה לתחזק תשתית גלובלית של שרתי TURN חזקים ולשלם עבור כל רוחב הפס שהשיחות הללו צורכות, במיוחד בשיחות וידאו. סיכום: משולש הפשרות הארכיטקטוני האסטרטגיה של וואטסאפ, ושל רוב אפליקציות התקשורת המודרניות, היא דוגמה מצוינת לאיזון בין שלוש מטרות, שלעיתים מתנגשות: אבטחה (Security) 🛡️: עדיפות: עליונה ובלתי ניתנת לפשרה. פתרון: ממומש בשכבת האפליקציה באמצעות הצפנה מקצה-לקצה (פרוטוקול Signal), מה שהופך את האבטחה לבלתי תלויה בנתיב הרשת שנבחר. ביצועים ואיכות (Performance & Quality) 🚀: עדיפות: גבוהה מאוד, קריטית לחוויית המשתמש. פתרון: מושג באמצעות התעדוף של ICE, שתמיד יחפש ויבחר בנתיב P2P ישיר כדי למזער את ה-Latency. אמינות וזמינות (Reliability & Availability) 💪: עדיפות: קריטית. שיחה חייבת להתחבר. פתרון: מושג באמצעות השימוש ב-TURN כמנגנון גיבוי אמין. הוא מבטיח שהשיחה תתקיים גם בתנאי הרשת המאתגרים ביותר. מסקנה סופית לסדרה: תקשורת זמן-אמת באינטרנט המודרני אינה פתרון של "זבנג וגמרנו". זוהי אסטרטגיה שנועדה להסתגל לתנאים הבלתי צפויים של הרשת הגלובלית. היא מאזנת בצורה מתוחכמת בין צרכים של אבטחה, ביצועים ואמינות, ובכל פעם שאנו מקיימים שיחה, היא בוחרת באופן דינמי את הנתיב הטוב ביותר האפשרי. תודה שעקבתם אחר הסדרה! בפעם הבאה שאתם בשיחת וידאו צלולה וחלקה, או לחילופין בשיחה עם קצת דיליי, תוכלו להעריך את התהליכים המורכבים שרצים ברקע וקובעים את איכות החיבור שלכם. שאלות ? הערות? שתפו אותי! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

בפוסט האחרון בסדרה, נחבר את הכל יחד ונראה כיצד תוצאות תהליך ה-ICE קובעות את נתיב זרימת המידע, מה ההבדל המעשי בין חיבור P2P לחיבור דרך שרת Relay, ומהן הפשרות שוואטסאפ מבצעת. שאלות? הערות? שתפו אותי! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

פוסט 4/5: 🔬🔒 ניתוח מקרה: מאחורי הקלעים של שיחת וואטסאפ (חלק א' - Signaling והצפנה) 🔒🔬 בפוסטים הקודמים בנינו את ארגז הכלים הטכני להבנת תקשורת מודרנית: למדנו על הבעיה (NAT) ועל הפתרונות (STUN, ICE, TURN). עכשיו, הגיע הזמן לראות איך כל הכלים האלה משתלבים יחד באחת האפליקציות הנפוצות בעולם. מה קורה בשניות הספורות שבין הלחיצה שלכם על כפתור החיוג בוואטסאפ ועד שהטלפון של הצד השני מתחיל לצלצל? מתרחשים שני תהליכים קריטיים במקביל: הקמת ערוץ האיתותים (Signaling) וביסוס ערוץ התקשורת המוצפן. רקע תיאורטי: הפרדת תפקידים Control Plane מול Data Plane בארכיטקטורת תקשורת מודרנית, קיימת הפרדה לוגית חדה בין שני מישורים (Planes): יData Plane (מישור הנתונים): זהו הנתיב שבו זורמים הנתונים עצמם – שיחת האודיו, שידור הווידאו. זהו התוכן של השיחה. הנתיב המדויק של מישור זה ייקבע על ידי תהליך ה-ICE. יControl Plane (מישור הבקרה): זוהי מערכת הניהול והתיאום שאחראית להקים, לנהל ולסיים את השיחה. היא עוסקת בהודעות בקרה, כמו "אני רוצה להתקשר אליך", "הוא מצלצל", "הוא ענה", ולא בתוכן השיחה עצמה. בוואטסאפ, מישור הבקרה מנוהל על ידי שרתי איתותים (Signaling Servers) של החברה. חשוב להדגיש: אלו אינם שרתי STUN או TURN, אלא רכיב נפרד עם תפקידים מוגדרים: ניהול נוכחות (Presence): בדיקה האם המשתמש השני מחובר וזמין לקבל שיחה. הזמנה לשיחה (Invite): שליחת בקשת השיחה למכשיר היעד. ניהול מצב השיחה: עדכון שני הצדדים על סטטוס השיחה (Ringing, Answered, Ended). מתווך להודעות ICE: וזה התפקיד המרכזי שמחבר אותנו לפוסט הקודם. מכיוון ששני המכשירים עדיין לא מכירים את כתובות ה-IP אחד של השני, שרת ה-Signaling משמש כ"תיבת דואר" מאובטחת להעברת רשימות המועמדים של ICE ביניהם. פרקטיקה: אתגר ההצפנה מקצה-לקצה (E2EE) ההבטחה המרכזית של וואטסאפ היא הצפנה מקצה-לקצה (E2EE): רק המשתתפים בשיחה יכולים לפענח את תוכנה. אבל כאן טמון פרדוקס: אם שרת ה-Signaling של וואטסאפ מתווך את כל תהליך ההקמה, כיצד נוכל להבטיח שהוא לא מבצע התקפת Man-in-the-Middle (MitM)? בתרחיש כזה, השרת יכול להציג את עצמו כצד ב' כלפי צד א', וכצד א' כלפי צד ב', ובכך ליירט ולפענח את כל השיחה. האתגר הטכני הוא לאפשר לשני מכשירים, שמתקשרים דרך צד שלישי לא מהימן, להסכים ביניהם על מפתח הצפנה סודי ומשותף לשיחה הנוכחית. הפתרון הקריפטוגרפי: פרוטוקול Signal וואטסאפ משתמשת בפרוטוקול Signal המוכר, שמממש את הפתרון בצורה אלגנטית: בסיס האמון - מפתחות זהות (Identity Keys): בעת התקנת האפליקציה, כל לקוח וואטסאפ מייצר צמד מפתחות א-סימטריים ארוכי-טווח: מפתח זהות פרטי (שנשמר בסוד על המכשיר) ומפתח זהות ציבורי (שנשלח לשרתי וואטסאפ ומקושר למספר הטלפון). מפתח זהות זה הוא תעודת הזהות הקריפטוגרפית של המשתמש. הסכמה על מפתח - החלפת מפתחות דיפי-הלמן (Diffie-Hellman): עבור כל שיחה חדשה, יש צורך במפתח הצפנה חד-פעמי (Ephemeral Key) כדי להבטיח סודיות מושלמת קדימה (Perfect Forward Secrecy). מפתח זה נוצר באמצעות פרוטוקול דיפי-הלמן (DH)(הסברנו על זה בהרחבה בסדרה על ssh ). באופן פשטני, כל צד מייצר צמד מפתחות DH זמני, והם מחליפים ביניהם את החלקים הציבוריים דרך שרת ה-Signaling. באמצעות שילוב של המפתח הפרטי הזמני שלהם עם המפתח הציבורי הזמני של הצד השני, שני המכשירים יכולים לחשב באופן עצמאי את אותו מפתח סודי משותף, מבלי שצד שלישי שהאזין להחלפה יוכל לשחזר אותו. אימות ומניעת MitM - חתימות דיגיטליות: כדי למנוע התקפת MitM, יש לוודא שמפתחות ה-DH הזמניים שהוחלפו אכן הגיעו מהמשתמשים הנכונים. כאן נכנסים לפעולה מפתחות הזהות מהשלב הראשון. כל הודעה המכילה מפתח DH ציבורי זמני, נחתמת דיגיטלית באמצעות מפתח הזהות הפרטי של השולח. הצד המקבל משתמש במפתח הזהות הציבורי של השולח (שאותו הוא קיבל משרתי וואטסאפ) כדי לאמת את החתימה. אם האימות מצליח, יש לו הוכחה מתמטית שההודעה הגיעה מהאדם הנכון ולא שונתה בדרך. 📝 סיכום ומסקנות: בסוף תהליך האיתות, עוד לפני שהצלצול נשמע, הושלמו שני מהלכים קריטיים: ברמת הרשת: המכשירים החליפו ביניהם את רשימות המועמדים של ICE, וכעת כל צד יודע את כל הכתובות הפוטנציאליות של הצד השני. ברמת האבטחה: המכשירים ביצעו תהליך קריפטוגרפי מאובטח, יצרו מפתח הצפנה סודי וייחודי לשיחה הנוכחית, ועשו זאת באופן שמונע משרתי וואטסאפ להאזין. כעת, כשהמכשירים חמושים במפתח הצפנה סודי וברשימת נתיבי תקשורת אפשריים, הם מוכנים לשלב הבא.

עכשיו, כשהבנו את כל המכניקה של יצירת החיבור NAT, STUN, ICE, ו-TURN איך כל זה משתלב יחד באפליקציה אמיתית כמו וואטסאפ? וחשוב מכך, איך מוסיפים לכל זה שכבת הצפנה חזקה מקצה-לקצה? על כך נדבר בפוסט הבא, שבו נתחיל לנתח שיחת וואטסאפ אמיתית. שאלות? הערות? שתפו אותי! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

פוסט 3/5: אז איך עובדת הקישוריות ⚙️🏗️ ניהול משא ומתן עם ICE והגיבוי באמצעות TURN 🏗️⚙️ בפוסטים הקודמים ביססנו ש-NAT שובר את הקישוריות הישירה, וש-STUN הוא כלי יעיל לגילוי הכתובת הציבורית, אך הוא לא מספיק כדי להבטיח חיבור, במיוחד מול סוגי NAT מגבילים כמו Symmetric NAT. הפתרון לבעיה המורכבת הזו אינו פרוטוקול בודד, אלא מסגרת מקיפה שנועדה לנהל את כל תהליך יצירת החיבור. מסגרת זו נקראת ICE. רקע תיאורטי: מהי מסגרת ICE? 🛡️ הגדרה טכנית: יICE (Interactive Connectivity Establishment), הוא מנגנון סטנדרטי שתפקידו למצוא את נתיב התקשורת היעיל והאמין ביותר בין שני מכשירים (Peers) שרוצים לתקשר. חשוב להבין: ICE הוא לא פרוטוקול תקשורת בפני עצמו, אלא "מתכון" או אסטרטגיה שמשתמשת בכלים אחרים – בעיקר STUN ו-TURN – כדי להשיג את מטרתה. מטרת העל של ICE היא להצליח ליצור חיבור P2P ישיר בכל פעם שזה אפשרי, ובמקרים שבהם זה נכשל, לספק מנגנון גיבוי אמין שיבטיח שהתקשורת עדיין תתקיים. פרקטיקה: שלבי תהליך ה-ICE תהליך ה-ICE הוא שיטתי ומורכב מכמה שלבים לוגיים: שלב 1: איסוף מועמדים (Candidate Gathering) בשלב הראשון, כל לקוח (Peer) אוסף רשימה של כל הכתובות הפוטנציאליות שדרכן ניתן ליצור איתו קשר. אלו נקראים "מועמדים" (Candidates). ישנם מספר סוגי מועמדים: יHost Candidate: הכתובת המקומית של המכשיר ברשת הפנימית (למשל, 192.168.1.50). מועמד זה שימושי בעיקר אם שני המכשירים נמצאים באותה רשת מקומית. יServer-Reflexive Candidate (srflx): הכתובת הציבורית של המכשיר (IP ופורט), כפי שהתגלתה על ידי שרת STUN. זוהי הכתובת של המכשיר כפי שהיא נראית מהאינטרנט הציבורי. יRelayed Candidate: כתובת IP ופורט על גבי שרת מתווך (Relay), שמתקבלת משרת TURN. מועמד זה הוא חלק מתוכנית הגיבוי. שלב 2: החלפת מועמדים באמצעות ערוץ איתותים (Signaling) לאחר שכל לקוח אסף את רשימת המועמדים שלו, עליו להעביר אותה ללקוח השני. תהליך זה לא מתבצע ישירות, אלא דרך ערוץ צדדי המכונה Signaling Channel. זהו בדרך כלל שרת ייעודי של האפליקציה (למשל, של וואטסאפ או זום), שתפקידו להעביר הודעות ניהול ובקרה בין הלקוחות לפני שנוצר חיבור המדיה הישיר. רשימות המועמדים נארזות בדרך כלל בפורמט SDP (Session Description Protocol) ומועברות דרך שרת זה. שלב 3: בדיקות קישוריות ותעדוף (Connectivity Checks) זהו השלב האקטיבי והחשוב ביותר. לאחר שכל לקוח קיבל את רשימת המועמדים של חברו, הוא מתחיל בתהליך של בדיקות שיטתיות: יצירת זוגות: ה-ICE יוצר זוגות של מועמדים לבדיקה (ה-Host שלי מול ה-Host שלו, ה-srflx שלי מול ה-srflx שלו, ה-Host שלי מול ה-srflx שלו, וכן הלאה). בדיקות STUN: עבור כל זוג, הלקוח שולח הודעות STUN Binding Request קלות כדי לבדוק אם תעבורה יכולה לעבור בין שתי הנקודות. תעדוף: ל-ICE יש מנגנון תעדוף מובנה כדי להבטיח שהנתיב היעיל ביותר ייבחר. סדר העדיפויות הוא בדרך כלל: יHost Candidates: החיבור הישיר והמהיר ביותר (הכי פחות Latency). יServer-Reflexive Candidates: חיבור P2P ישיר דרך האינטרנט. פחות מהיר מ-Host, אך עדיין יעיל מאוד. יRelayed Candidates: החיבור האיטי והיקר ביותר מבחינת משאבים, ולכן בעדיפות האחרונה. הזוג הראשון שמצליח לבצע בדיקת STUN דו-כיוונית מוצלחת, נבחר כנתיב הפעיל עבור העברת המדיה. תוכנית הגיבוי: מנגנון TURN יTURN (Traversal Using Relays around NAT), הוא הפתרון למקרים שבהם כל בדיקות ה-P2P הישירות נכשלות – למשל, כאשר שני הלקוחות נמצאים מאחורי Symmetric NAT. איך זה עובד? במקום לנסות לדבר ישירות, כל לקוח פונה לשרת TURN. הוא מבצע תהליך הקצאה (Allocation) ומקבל כתובת IP ופורט על השרת עצמו. זוהי הכתובת של ה-Relayed Candidate. תהליך התקשורת: שני הלקוחות שולחים את המידע שלהם (שכבר מוצפן) אל שרת ה-TURN. השרת פועל כתחנת ממסר (Relay) ומעביר את המידע מהאחד לשני. הפשרה: מנגנון TURN מבטיח קישוריות כמעט בכל תרחיש רשת. עם זאת, המחיר הוא זמן השהייה (Latency) גבוה יותר (המידע עובר דרך ארוכה יותר) ועלות משאבים גבוהה לספק השירות, שכן כל תעבורת השיחה עוברת דרך השרתים שלו. 📝 סיכום ומסקנות: יICE הוא המנגנון המתוחכם שהופך את התקשורת המודרנית לאפשרית. הוא פועל כאלגוריתם לניהול משא ומתן, אשר לוקח סביבת רשת מבולגנת ובלתי צפויה, ובאופן שיטתי בודק, מתעדף ובוחר את נתיב התקשורת הטוב ביותר הקיים. הוא מאמץ גישה של העדפה מוחלטת ל-P2P, אך עם רשת ביטחון אמינה של TURN כדי להבטיח שהחיבור תמיד יצליח.

פוסט 2/5: פתרון בעיית הגילוי 🪞🔍 פתרון בעיית הגילוי: איך מכשיר לומד את זהותו הציבורית עם STUN 🔍🪞 בפוסט הקודם, קבענו ש NAT יוצר שתי בעיות מרכזיות לתקשורת ישירה (P2P): בעיית הגילוי (אני לא יודע מה הכתובת הציבורית שלי) ובעיית הקישוריות (גם אם אדע, ה NAT שלי יחסום חיבורים נכנסים). היום נתמקד בפתרון לבעיה הראשונה. איך אפליקציה, שרצה על מכשיר מאחורי נתב, יכולה לגלות מהי כתובת ה IP והפורט שהעולם החיצון רואה? התשובה היא פרוטוקול פשוט וחכם בשם STUN. רקע תיאורטי: מהו פרוטוקול STUN? 🛡️ הגדרה טכנית: יSTUN (Session Traversal Utilities for NAT) הוא פרוטוקול Client-Server פשוט. חשוב לדייק: מטרתו העיקרית של STUN היא לא לבצע את חציית ה NAT בעצמו, אלא לספק ללקוח מידע על הסביבה הציבורית שלו. הוא כלי דיאגנוסטיקה וגילוי. הפרוטוקול עובד כמו "מראה" (Reflection) ברשת. השרת של STUN הוא נקודת קצה ציבורית, שכל תפקידה הוא לקבל בקשה מלקוח, לבחון את פרטי הרשת של הבקשה כפי שהיא נראית מהצד הציבורי, ולדווח על פרטים אלו בחזרה ללקוח. הוא קל משקל, רץ בדרך כלל מעל UDP, ודורש משאבים מינימליים מהשרת, ולכן קיימים שרתי STUN ציבוריים רבים (למשל, של גוגל). פרקטיקה: ניתוח תהליך STUN Binding Request התהליך להשגת הכתובת הציבורית נקרא STUN Binding. השלבים: שליחת הבקשה (Client): אפליקציה על המכשיר (למשל, וואטסאפ) שרוצה לגלות את זהותה הציבורית, שולחת חבילת UDP קטנה, STUN Binding Request, לכתובת ידועה מראש של שרת STUN. תרגום הכתובת (NAT): בדרכה החוצה מהרשת המקומית, החבילה עוברת דרך הנתב. הנתב מבצע את פעולת ה NAT/PAT: הוא מחליף את כתובת ה IP והפורט הפרטיים של המכשיר בכתובת ה-IP הציבורית שלו ובפורט פנוי שהוא בוחר. הוא רושם את המיפוי הזה בטבלת ה NAT שלו. קבלת הבקשה (STUN Server): שרת ה STUN מקבל את החבילה. הדבר היחיד שמעניין אותו הוא ה "מעטפה" של החבילה כלומר, מאיזו כתובת IP ומאיזה פורט היא הגיעה (Source IP & Port). זוהי, למעשה, הזהות הציבורית של הלקוח באותו הרגע. שליחת התשובה (STUN Server): השרת מרכיב הודעת תשובה, STUN Binding Response. בתוך הודעה זו, הוא מכליל מספר שדות (Attributes). השדה החשוב ביותר הוא MAPPED-ADDRESS. הערך של שדה זה הוא צמד ה IP והפורט שהשרת זיהה כשולח הבקשה. קבלת התשובה (Client): הלקוח מקבל את התשובה, מפענח אותה, ושולף את הערך מתוך שדה ה-MAPPED-ADDRESS. התוצאה: הלקוח למד מהי כתובת ה-IP והפורט הציבוריים שלו. בתהליך של פרוטוקול ICE (שעליו נרחיב בפוסט הבא), כתובת זו נקראת Server-Reflexive Candidate. יכולות נוספות: STUN ככלי לאבחון סוג ה NAT מעבר לגילוי הכתובת, STUN יכול לשמש גם ככלי לאבחון סוג ה NAT. באמצעות שליחת סדרת בקשות STUN מתוחכמות, הלקוח יכול ללמוד על "התנהגות" ה NAT שהוא נמצא מאחוריו (למשל, האם הוא Cone NAT או Symmetric NAT). הידיעה הזו קריטית עבור כל התהליך (ICE), כדי להעריך את הסיכויים להצלחת חיבור P2P ישיר. השלכות טכניות ומגבלות מובנות כאן המקום לדייק ולהדגיש את מגבלות הפרוטוקול: יSTUN פותר רק את בעיית הגילוי. הוא אינו מסייע ישירות בפתרון בעיית הקישוריות. העובדה שהלקוח יודע את כתובתו הציבורית לא מבטיחה שה NAT שלו יאפשר ל Peer אחר לשלוח תעבורה נכנסת לכתובת זו. חוסר תועלת מול Symmetric NAT: במקרה של Symmetric NAT, פרוטוקול STUN לבדו כמעט חסר תועלת ליצירת P2P. הסיבה לכך טכנית: Symmetric NAT יוצר מיפוי (IP:Port) חיצוני ייחודי עבור כל יעד שאליו פונים. המשמעות היא שהמיפוי שנוצר עבור התקשורת מול שרת ה-STUN יהיה שונה מהמיפוי שייווצר עבור התקשורת מול ה Peer. לכן, הכתובת שהתקבלה משרת ה STUN פשוט אינה רלוונטית עבור ה Peer השני. 📝 סיכום ומסקנות: יSTUN הוא כלי חיוני והכרחי בארסנל הפתרונות לחציית NAT. הוא משמש כשלב איסוף המודיעין הראשוני, ומספק ללקוח מודעות עצמית לגבי זהותו ברשת הציבורית. עם זאת, הוא רק פיסה אחת בפאזל. הוא אינו פתרון קסם, ואת בעיית הקישוריות המורכבת יותר הוא משאיר למנגנונים אחרים לפתור. אז אם STUN הוא רק כלי איסוף מודיעין, מהו המנגנון שמנהל את כל המידע הזה, בודק את נתיבי התקשורת בפועל, ומחליט איך לחבר בין שני מכשירים? בפוסט הבא נכיר את המנגנון המרכזי שמתזמר את כל התהליך: שנקרא ICE. שאלות? הערות? שתפו אותי! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

📝 סיכום ומסקנות: השימוש הנרחב ב-NAT הפך לסטנדרט באינטרנט. הוא חיוני לחיסכון בכתובות IPv4 ומספק שכבת אבטחה בסיסית על ידי הסתרת הרשת הפנימית. עם זאת, הוא יצר אתגר ארכיטקטוני עצום עבור כל יישום מודרני המסתמך על תקשורת ישירה – החל משיחות VoIP וגיימינג ועד לשיתוף קבצים. אז איך בכל זאת אנחנו מצליחים לנהל שיחות וידאו, לשחק אונליין ולהעביר קבצים? כאן נכנסים לתמונה פרוטוקולים מודרניים שנועדו בדיוק "לתקן" את הבעיה ש-NAT יצר. על הפתרון הראשון, STUN, נדבר בפירוט בפוסט הבא. שאלות טכניות? הערות? שתפו אותי! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

🌐🛠️ הקונפליקט היסודי: איך ומדוע האינטרנט המודרני סטה מהמודל המקורי שלו? 🛠️🌐 שלום לכולם! היום אנחנו פותחים סדרה טכנית שתצלול לאחד מעקרונות הבסיס של רשת האינטרנט, ולשינוי המשמעותי שעיצב את הדרך שבה כולנו מתחברים היום. אי פעם תהיתם מדוע המחשב שלכם בבית מקבל כתובת IP כמו 192.168.1.100, אך זו לא הכתובת האמיתית שבה אתרים ושירותים חיצוניים "רואים" אתכם? הפוסט הזה יענה בדיוק על כך. רקע תיאורטי: חזון האינטרנט המקורי ועקרון קצה-לקצה 🛡️ המודל המקורי: רשת שטוחה וקישוריות מלאה בימיו הראשונים, האינטרנט תוכנן על בסיס עיקרון פשוט ועוצמתי: קישוריות קצה-לקצה (End-to-End Connectivity). הרעיון היה שלכל מכשיר ברשת, או "צומת" (node), תהיה כתובת IP ציבורית וייחודית משלו, אשר ניתנת לניתוב מכל מקום אחר ברשת. במודל זה, הרשת הייתה "שטוחה". לא היו מתווכים או "מתרגמי כתובות". אם למחשב באוניברסיטת סטנפורד הייתה כתובת IP ציבורית, ולמחשב ב-MIT הייתה כתובת IP ציבורית, הם יכלו ליצור קשר ישיר אחד עם השני באמצעות פרוטוקולים כמו FTP או Telnet ללא שום מכשול. כל צומת היה גם לקוח וגם שרת פוטנציאלי. 📉 הבעיה הטכנית: התכלות מאגר הכתובות של IPv4 החזון הזה התבסס על פרוטוקול האינטרנט גרסה 4 (IPv4), אשר משתמש בכתובות באורך 32 סיביות. מתמטית, זה מאפשר מספר כתובות ייחודיות, שהן כ-4.3 מיליארד. בשנות ה-70 וה-80, זה נראה כמו כמות כמעט אינסופית. אך עם הפיצוץ של האינטרנט המסחרי בשנות ה-90 והעלייה המעריכית בכמות המחשבים האישיים, הטלפונים החכמים, ובהמשך מכשירי ה-IoT, המאגר הזה החל להתרוקן בקצב מסחרר. הפתרון ארוך הטווח, IPv6 (עם 2^128 כתובות), עדיין נמצא בתהליכי אימוץ איטיים. היה צורך בפתרון ביניים מיידי כדי למנוע את קריסת הרשת. פרקטיקה: NAT - הפתרון הזמני שהפך לסטנדרט קבוע כאן נכנס לתמונה מנגנון ה-NAT (Network Address Translation), או בעברית "תרגום כתובות רשת". 🛠️ מהו NAT ואיך הוא פועל? יNAT הוא מנגנון הממומש על התקן שער (Gateway), כמו הנתב הביתי או הארגוני שלכם. מטרתו העיקרית היא לאפשר למספר רב של מכשירים ברשת מקומית (LAN) לחלוק כתובת IP ציבורית אחת ויחידה. המכשירים ברשת הפנימית מקבלים כתובות מתוך טווחים פרטיים שהוגדרו בתקן RFC 1918. אלו הכתובות המוכרות: 10.0.0.0 עד 10.255.255.255 (10.0.0.0/8) 172.16.0.0 עד 172.31.255.255 (172.16.0.0/12) 192.168.0.0 עד 192.168.255.255 (192.168.0.0/16) כתובות אלו אינן מנותבות באינטרנט הציבורי. נתבים ברחבי האינטרנט מוגדרים להתעלם מהן. תהליך התרגום: תעבורה יוצאת (LAN to WAN): מחשב עם כתובת פרטית 192.168.1.100 שולח בקשה לשרת גוגל. הבקשה מגיעה לנתב. הנתב משנה את כתובת ה-IP של השולח (Source IP) מ-192.168.1.100 לכתובת ה-IP הציבורית שלו (לדוגמה 80.70.60.50). בנוסף, הוא יוצר מיפוי בטבלה פנימית הנקראת NAT Translation Table, שרושמת איזה מכשיר פנימי יזם את החיבור. טבלה זו היא Stateful – היא זוכרת את מצב החיבורים הפעילים. תעבורה נכנסת (WAN to LAN): כאשר שרת גוגל משיב, הוא שולח את התשובה לכתובת ה-IP הציבורית של הנתב. הנתב מקבל את החבילה, בודק בטבלת ה-NAT שלו, רואה שהחיבור הזה שייך למחשב 192.168.1.100, מבצע את התרגום ההפוך (משנה את כתובת היעד לכתובת הפרטית), ומעביר את החבילה למחשב הנכון ברשת הפנימית. רוב הנתבים הביתיים משתמשים בווריאציה שנקראת PAT (Port Address Translation), שבה הנתב משנה לא רק את ה-IP אלא גם את פורט המקור (Source Port), מה שמאפשר לאלפי חיבורים ממכשירים שונים לחלוק את אותה כתובת IP ציבורית בו-זמנית. השלכות טכניות: שבירת מודל ה-P2P למרות ש-NAT פתר את בעיית התכלות הכתובות, הוא עשה זאת במחיר של שבירת עיקרון קצה-לקצה. הוא יצר שתי בעיות טכניות מהותיות עבור תקשורת Peer-to-Peer (P2P): בעיית הגילוי (Discovery Problem) ❓: לקוח הנמצא מאחורי NAT אינו מודע לכתובת ה-IP הציבורית שלו ולפורט שהוקצה לו בטבלת ה-NAT. לכן, הוא אינו יכול לפרסם את כתובתו לצד שני כדי שיזום אליו חיבור. בעיית הקישוריות (Connectivity Problem) 🧱: גם אם הלקוח יגלה את כתובתו הציבורית איכשהו, הקישוריות עדיין בעייתית. בגלל אופיו ה-Stateful של ה-NAT, הוא יאפשר תעבורה נכנסת רק אם היא תואמת לחיבור קיים בטבלת התרגום שלו – כלומר, חיבור שיצא מתוך הרשת הפנימית. כל חבילת מידע נכנסת שלא הוזמנה מראש (Unsolicited Packet), למשל מ-Peer שמנסה ליזום חיבור, תיחשב כלא רצויה ותיזרק על ידי הנתב. זוהי למעשה פונקציונליות של חומת אש בסיסית.

הסבר על ממה נובעות דליפות של נתונים פרטים ממודלים של ai. רוצים ללמוד על עוד דברים ספרו לנו. הצטרפו לערוץ @CYBERSECURITYCODING

🚨🔒🇮🇳  האקרים הודים תוקפים חברות הגנה טורקיות בדרך מתוחכמת  האקרים מטעם ממשלת הודו פועלים לגניבת מידע רגיש מחברות הגנה טורקיות באמצעות מתקפת דיוג מתוחכמת.  🔍 מה קרה?  🔹 קבוצת ההאקרים "Patchwork" (הקשורה להודו) שולחת מיילים מזויפים עם קובץ LNK זדוני, המתחזה להזמנה לכנס על כלי טיס בלתי מאוישים 🎣  🔹 הקובץ מפעיל שרשרת התקפה מורכבת עם 5 שלבים, כולל הורדת תוכנה זדונית מהשרתים של ההאקרים ⛓️  🔹 המתקפה מתוזמנת עם מתיחות בין הודו לפקיסטן ושיתוף פעולה הגנתי בין טורקיה לפקיסטן 🌍  🔹 ההאקרים משתמשים ב-PDF כפיתיון ויזואלי, בזמן שהתוכנה הזדונית פועלת ברקע ללא ידיעת הקורבן 📄👀  🔹 הקבוצה שדרגה את יכולותיה - עברה מקבצי DLL ל-PE מתקדמים עם פקודות משופרות 💻⚡  🔹 המטרה: איסוף מודיעין על יכולות טורקיות בתחום רחפנים וטילים היפרסוניים (טורקיה שולטת ב-65% משוק הרחפנים העולמי!) 🚀📊 📜 לכתבה המלאה: 🔗 thehackernews.com 📢 הצטרפו לקבוצה שלנו לדיונים ועדכונים נוספים! 🔗 Cyber Security Coding שמרו על עצמכם! 🛡️🚀

אם משב רוח מרענן על הפנים זה מה שאתם מחפשים, אז צאו לגעת בדשא. אבל אם חסר לכם ערוץ שיש בו הכל מהכל, בלי לוז מסודר, לפעמים נעלם לחצי שנה ולפעמים מפרסם שלושה פוסטים באותו שבוע, שיכול לפרסם סקריפט לטרמוקס יום אחד, טיפים לשימוש בAI [🪙טוקנים - זה המטבע שאתם צריכים לחשוב איתו כשאתם משתמשים במודלי שפה] באחר ותגובות לפוסטים מערוצים מוכרים אחרים - אז הגעתם (לפרסומת של) למקום הנכון! שרלוק'ס האב (שזה אני), זה ערוץ בו אתם יכולים למצוא מלאאא דברים רנדומליים, שהמכנה המשותף שלהם הוא שהם מעניינים אותי - אני לא מתחייב לכלום. בדרך כלל יהיה מדובר במדריכים בנושאי פרטיות וסייבר, סקריפטים לטרמוקס (הייעוד המקורי של הערוץ), דברים רנדומליים אחרים, ואם תישארו מספיק זמן תוכלו לראות גם את השרלוקבוט... בוט טלגרם שיכיל ככל הנראה את כל מה שאתם צריכים אם סייבר וטכנולוגיה זו נשמת חייכם. סקרנים? מוזמנים להציץ וגם להישאר. Sherlock's Hub

🛡️✨ יSSH השכבה האחרונה - הגנה על המפתח ! ✨🛡️ עברנו דרך ארוכה ביחד. בסדרת הפוסטים שלנו, למדנו לאמת את השרת שאליו אנו מתחברים, בנינו מנהרה מוצפנת כדי להגן על התקשורת, הבנו מדוע סיסמאות הן נקודת תורפה, ועברנו לשיטת האימות המאובטחת ביותר - אימות מבוסס מפתחות. נראה שהגענו למבצר בלתי חדיר. אבל נותרה שאלה אחת, קריטית, אחרונה: מה קורה אם תוקף מצליח, באמצעות נוזקה או פישינג, לגנוב את קובץ המפתח הפרטי (id_ed25519) מהמחשב שלנו? 😱 בידיו נמצא המפתח הראשי לכל השרתים שלנו. האם הכל אבוד? לא אם נוסיף את שכבות ההגנה האחרונות. קו ההגנה הראשון: ה-Passphrase (סיסמת המפתח) 🛡️ כשאתם יוצרים זוג מפתחות SSH חדש, אתם נשאלים שאלה אופציונלית: Enter passphrase (empty for no passphrase):. רבים נוטים לדלג על שלב זה למען הנוחות, וזו טעות חמורה. מה זה Passphrase? זוהי סיסמה שמטרתה היא לא לאמת אתכם מול השרת, אלא להצפין את קובץ המפתח הפרטי שלכם על הדיסק הקשיח. איך זה עובד? כאשר אתם מגדירים Passphrase, קובץ המפתח הפרטי נשמר כגוש מוצפן. גם אם תוקף יצליח להעתיק את הקובץ מהמחשב שלכם, הקובץ יהיה חסר תועלת עבורו ללא הסיסמה הזו. הוא יצטרך לפצח את הצפנת הקובץ עצמו, משימה קשה ביותר אם בחרתם סיסמה חזקה. הבעיה: הגברנו את האבטחה, אך פגענו בנוחות. כעת, בכל פעם שנרצה להשתמש במפתח (למשל, בחיבור ssh או בפעולת git push), נצטרך להקליד מחדש את ה-Passphrase. זה יכול להפוך למטרד במהירות. אז איך נהנים מהאבטחה של Passphrase בלי לוותר על הנוחות? הפתרון של ssh-agent 🎩✨ כאן נכנס לתמונה אחד הכלים השימושיים והלא מוערכים מספיק בעולם ה-SSH: ה-ssh-agent. מה זה ssh-agent? זהו "סוכן" מאובטח, תוכנית שרצה ברקע ומשמשת כמעין צרור מפתחות זמני עבור סשן העבודה שלכם. תהליך העבודה האידיאלי: הפעלה: אתם מתחילים את יום העבודה ופותחים את הטרמינל. ה-ssh-agent בדרך כלל רץ אוטומטית. הוספת המפתח: אתם מריצים את הפקודה ssh-add (או ssh-add ~/.ssh/id_ed25519). הקלדה חד-פעמית: כעת, תתבקשו להזין את ה-Passphrase של המפתח הפרטי. אתם מקלידים אותו פעם אחת בלבד. שמירה בזיכרון: ה-ssh-agent משתמש בסיסמה כדי לפענח את המפתח הפרטי ושומר אותו בצורה מאובטחת בזיכרון המחשב (RAM), לא על הדיסק. קסם! מכאן ואילך, למשך כל סשן העבודה שלכם, בכל פעם שתתחברו לשרת, לקוח ה-SSH יפנה אוטומטית ל-ssh-agent ויבקש ממנו לבצע את פעולת החתימה הדיגיטלית. הסוכן יעשה זאת בשמחה, ללא כל צורך בהקלדת סיסמה נוספת. השילוב של מפתח פרטי המוצפן עם Passphrase, יחד עם שימוש ב-ssh-agent לניהול הסשן, נותן לנו את הטוב משני העולמות: אבטחה מקסימלית ונוחות מרבית. המסקנה הסופית: איפה שורש האמון האמיתי? 🤔 עברנו על כל שכבות האבטחה של פרוטוקול SSH. הוא מגן עלינו מפני ציתות, התקפות אדם בתווך, ניחושי סיסמאות, ואפילו גניבה של קובץ המפתח. אבל יש אמת אחת שחשוב להבין: שורש האמון האמיתי הוא המחשב האישי שלכם. גם עם כל ההגנות הללו, אם תוקף הצליח להשתלט על המחשב שלכם בזמן אמת (למשל, באמצעות נוזקת שליטה מרחוק - RAT), וה-ssh-agent שלכם טעון ופעיל – התוקף יכול פשוט להשתמש בטרמינל שלכם כדי להתחבר לשרתים שלכם. הוא לא צריך את המפתח או הסיסמה, כי אתם כבר מאומתים. פרוטוקול SSH עושה עבודה פנומנלית בהגנה על התקשורת ברשת. הוא לא יכול להגן על נקודת הקצה (המחשב שלכם) אם היא נפרצה. 📝 סיכום הסדרה: בסדרת הפוסטים הזו בנינו יחד הבנה עמוקה של אבטחת SSH: התחלנו עם אימות השרת כדי למנוע התחזות. הבנו איך נוצרת מנהרה מוצפנת יש מאין. זיהינו את החולשות של סיסמאות ועברנו לאימות מפתחות. ראינו את תהליך האימות המתוחכם מבוסס המפתחות. ולבסוף, למדנו להגן על המפתח הפרטי עצמו באמצעות Passphrase ו-ssh-agent. אני מקווה שהסדרה הזו העניקה לכם ידע, וכלים מעשיים לעבוד בצורה מאובטחת יותר. שאלות ,הערות , בתגובות👇 הצטרפו לערוץ @CYBERSECURITYCODING

בפוסט הבא והאחרון בסדרה... הבנו שאימות מפתחות הוא הדרך הנכונה. אנחנו מוגנים. אבל... מה קורה אם תוקף מצליח לגנוב את קובץ המפתח הפרטי עצמו מהמחשב שלנו? 😱 איך אנחנו מגינים על המפתח? ואיך עושים זאת בלי להקליד סיסמה ארוכה בכל פעם מחדש? בפוסט הבא נדבר על שכבות ההגנה האחרונות: החשיבות הקריטית של Passphrase על המפתח הפרטי, והתהליך של ssh-agent שמעניק לנו גם אבטחה וגם נוחות. ✨🛡️ הצטרפו לערוץ @CYBERSECURITYCODING

🔐⚙️י SSH Deep Dive: איך השרת באמת יודע שזה אתה? ⚙️🔐 בפוסטים הקודמים בנינו יחד את היסודות: וידאנו שאנחנו מדברים עם השרת הנכון ויצרנו מנהרת תקשורת מוצפנת. עכשיו הגענו לשלב האמת, לב הליבה של האבטחה: האימות (Authentication). זהו התהליך שבו אנחנו, המשתמשים, צריכים להוכיח לשרת שאנחנו מי שאנחנו טוענים שאנחנו. היום נצלול לעומק המנגנונים ש-SSH מציע כדי לעשות זאת, מהשיטה הבסיסית ביותר ועד ל-Gold Standard של התעשייה. הבסיס: קובץ הקונפיגורציה sshd_config לפני שנכיר את שיטות האימות, חשוב להכיר את "מרכז הבקרה" של שרת ה-SSH. על השרת, בקובץ /etc/ssh/sshd_config, מנהל המערכת קובע אילו שיטות אימות מותרות, באילו נסיבות, ובאיזה סדר. הבנת השיטות השונות תעזור לכם להבין למה השרת מתנהג כמו שהוא מתנהג, ואיך לאבטח אותו נכון. שיטה 1: אימות באמצעות סיסמה (Password Authentication) זו השיטה המוכרת והאינטואיטיבית ביותר. איך זה עובד? הלקוח (המחשב שלכם) פונה לשרת ומציין את שם המשתמש (ssh user@server). השרת, שרואה בקובץ הקונפיגורציה שלו שאימות סיסמה מותר (PasswordAuthentication yes), מבקש מהלקוח את הסיסמה. אתם מקלידים את הסיסמה. הלקוח שולח אותה לשרת דרך המנהרה המוצפנת שבנינו. השרת מקבל את הסיסמה, מבצע לה גיבוב (Hashing) ומשווה את התוצאה לגיבוב השמור בקובץ /etc/shadow שלו (במערכות לינוקס). אם יש התאמה – אתם בפנים. יתרונות: פשוט להבנה ולשימוש. חסרונות: השיטה הכי פחות מאובטחת. פגיעה למתקפות ניחוש (Brute Force/Dictionary), מעודדת שימוש חוזר בסיסמאות, ובעייתית מאוד לאוטומציה. שיטה 2: אימות מבוסס מפתחות (Public Key Authentication) - ה-Gold Standard 👑 זוהי השיטה המומלצת, המאובטחת והמקצועית ביותר לעבודה עם SSH. היא מבוססת על קריפטוגרפיה א-סימטרית. הקונספט: מנעול ומפתח 🔑🔒 בשיטה זו, לכל משתמש יש זוג מפתחות: מפתח פרטי (id_ed25519 או id_rsa): זהו המפתח הסודי שלכם. הוא נשמר אך ורק על המחשב שלכם, ומוגן היטב (רצוי עם סיסמה משלו - Passphrase). אסור לשתף אותו לעולם. מפתח ציבורי (id_ed25519.pub או id_rsa.pub): זהו "המנעול" שמתאים למפתח הפרטי שלכם. את הקובץ הזה אתם מעתיקים לכל השרתים שאליהם תרצו להתחבר, ושמים אותו בקובץ מיוחד בשם ~/.ssh/authorized_keys בתיקיית המשתמש שלכם בשרת. תהליך האימות התהליך כאן מתוחכם ומונע לחלוטין את הצורך לשלוח סוד (כמו סיסמה) על גבי הרשת: הצגה עצמית: הלקוח פונה לשרת ואומר: "שלום, אני המשתמש 'david', ואני רוצה להתחבר באמצעות המפתח הציבורי שלי". האתגר (Challenge): השרת בודק בקובץ authorized_keys של המשתמש 'david'. הוא רואה את המפתח הציבורי, ומבין שהוא יכול לאתגר את הלקוח. השרת יוצר מחרוזת אקראית וחד-פעמית (שנקראת "nonce") ושולח אותה ללקוח. החתימה (Response): הלקוח מקבל את המחרוזת האקראית. הוא משתמש במפתח הפרטי שלו כדי "לחתום" דיגיטלית על המחרוזת הזאת. חתימה דיגיטלית היא תוצאה מתמטית שניתן לייצר רק באמצעות המפתח הפרטי. האימות (Verification): הלקוח שולח את החתימה בחזרה לשרת. השרת משתמש במפתח הציבורי (ששמור אצלו) כדי לבדוק אם החתימה שהתקבלה אכן מתאימה למחרוזת האקראית המקורית. הצלחה! אם החתימה מאומתת, השרת יודע בוודאות שהלקוח שמולו מחזיק במפתח הפרטי המתאים, מבלי שהמפתח הפרטי עצמו נשלח או נחשף. הגישה מאושרת. יתרונות: מאובטח בצורה קיצונית (כמעט בלתי אפשרי לנחש מפתח), עמיד בפני התקפות ניחוש ופישינג, ומצוין לאוטומציה. חסרונות: דורש הגדרה ראשונית. ניהול המפתחות הפרטיים הוא קריטי – גניבת מפתח פרטי היא כמו גניבת סיסמת-על. שיטה 3: אימות אינטראקטיבי (Keyboard-Interactive) זוהי שיטה גמישה המאפשרת לשרת לנהל "דיאלוג" עם המשתמש ולשאול אותו מספר שאלות. איך זה עובד? במקום שהשרת יבקש רק "סיסמה", הוא יכול ליזום סדרה של בקשות "אתגר-תגובה" שהמשתמש צריך לענות עליהן מהמקלדת. שימוש נפוץ וחשוב: אימות רב-שלבי (MFA/2FA). זהו השימוש המרכזי בשיטה זו כיום. ניתן להגדיר את השרת כך ש: יבקש תחילה את הסיסמה של המשתמש (שאלה 1). לאחר מכן, יבקש קוד אימות חד-פעמי (OTP) מאפליקציה כמו Google Authenticator או מפתח חומרה כמו YubiKey (שאלה 2). שילוב של אימות מפתחות (שיטה 2) עם אימות אינטראקטיבי (MFA) נחשב למאובטח ביותר. 📝 סיכום: יSSH מספק ארסנל של שיטות אימות, כל אחת עם היתרונות והחסרונות שלה. סיסמה: פשוטה אך לא מומלצת. מפתח ציבורי: הסטנדרט המאובטח והמומלץ כברירת מחדל. אינטראקטיבי: חיוני להוספת שכבת אבטחה נוספת כמו MFA. ההמלצה המקצועית היא תמיד לבטל אימות סיסמאות בקובץ sshd_config (PasswordAuthentication no) ולהתבסס אך ורק על אימות מפתחות, ובסביבות רגישות במיוחד, להוסיף מעל זה גם אימות רב-שלבי (MFA).

🚇🤝י SSH חלק 2: המנהרה הסודית - איך בונים אמון? 🤝🚇 בפוסט הקודם דיברנו על החשיבות הקריטית של אימות טביעת האצבע של השרת 🛡️. אישרנו שאנחנו מדברים עם השרת הנכון ונמנענו מהתקפת "אדם בתווך". עכשיו עומדת בפנינו בעיה חדשה, לא פחות גדולה: איך אנחנו, הלקוח, יכולים לשלוח לשרת מידע רגיש (כמו סיסמה) דרך רשת האינטרנט הפתוחה והלא בטוחה? 😱 כל אחד בדרך – ספק האינטרנט שלכם, ה-Wi-Fi בבית הקפה, תוקפים פוטנציאליים – יכול "להאזין" לתעבורה. אנחנו צריכים להצפין את השיחה. אבל כאן מתחיל פרדוקס. 🤔 הפרדוקס: בעיית "הביצה והתרנגולת" של ההצפנה 🥚🐔 כדי להצפין שיחה, שני הצדדים (הלקוח והשרת) צריכים להסכים על מפתח סודי משותף. זה המפתח שישמש לנעול (להצפין) ולפתוח (לפענח) את כל המידע שיישלח ביניהם. אבל איך הם יכולים להסכים על מפתח סודי, אם כל מה שהם אומרים אחד לשני עלול להיות חשוף? אם הלקוח יגיד לשרת: "היי, בוא נשתמש במפתח הסודי 12345", כל מי שמאזין יראה את המפתח! אם השרת ישלח ללקוח מפתח, אותה בעיה בדיוק. זוהי בעיית "הביצה והתרנגולת": כדי לשתף סוד צריך ערוץ מאובטח, אבל כדי ליצור ערוץ מאובטח צריך סוד. אז איך SSH פותר את זה? עם אחד האלגוריתמים האלגנטיים והיפים ביותר בקריפטוגרפיה. 🎨 הפתרון הגאוני: החלפת מפתחות דיפי-הלמן האלגוריתם נקרא Diffie-Hellman Key Exchange. כדי להבין איך הוא עובד בלי להסתבך במתמטיקה, נשתמש באנלוגיה מפורסמת: ערבוב צבעים. דמיינו שהלקוח (נקרא לו אליס) והשרת (נקרא לו בוב) רוצים ליצור צבע סודי משותף, אבל הם יכולים לשלוח אחד לשני רק קופסאות צבע דרך דואר שקוף שכולם יכולים לראות. הסכמה על צבע פומבי 🎨: אליס ובוב מסכימים ביניהם בפומבי על צבע בסיס משותף. נניח, צהוב. כל מי שמאזין יודע שהם התחילו עם צבע צהוב. בחירת צבעים סודיים 🤫: אליס בוחרת לעצמה צבע סודי שאף אחד לא יודע עליו: אדום. בוב בוחר לעצמו צבע סודי שאף אחד לא יודע עליו: כחול. הצבעים הסודיים האלה לעולם לא נשלחים על גבי הרשת. ערבוב ושליחה 📨: אליס מערבבת את הצבע הפומבי (צהוב) עם הצבע הסודי שלה (אדום) ומקבלת כתום. היא שולחת את הצבע הכתום לבוב. בוב מערבב את הצבע הפומבי (צהוב) עם הצבע הסודי שלו (כחול) ומקבל ירוק. הוא שולח את הצבע הירוק לאליס. התוקף, רואה את הצבע הכתום והירוק עוברים ברשת. אבל, קשה מאוד מבחינה חישובית "להפריד" צבעים. הוא לא יכול לדעת בקלות איזה צבע סודי התווסף לצהוב כדי ליצור כתום. הקסם - יצירת הסוד המשותף ✨: אליס מקבלת את הצבע הירוק מבוב, ומוסיפה לו את הצבע הסודי שלה (אדום). ירוק (צהוב+כחול) + אדום = חום סודי. בוב מקבל את הצבע הכתום מאליס, ומוסיף לו את הצבע הסודי שלו (כחול). כתום (צהוב+אדום) + כחול = חום סודי. בסוף התהליך, גם לאליס וגם לבוב יש בדיוק את אותו צבע חום סודי, למרות שהצבע הזה מעולם לא נשלח על גבי הרשת! התוקף נשאר עם צבע צהוב, כתום וירוק, ולא יכולה לשחזר את הצבע החום הסופי. שימו לב בפועל הערבוב הוא של מספרים ככה שאין מצב לדעת מה הם היו לפני ההוספות. 🔒 התוצאה: מנהרה מוצפנת ומוכנה לפעולה ה"צבע החום הסודי" הזה הוא מפתח ההפעלה (Session Key). מהרגע הזה, הלקוח והשרת משתמשים במפתח המשותף הזה כדי להצפין את כל התקשורת ביניהם באמצעות אלגוריתם הצפנה סימטרי ומהיר (כמו AES). עכשיו, ורק עכשיו, אפשר לשלוח בבטחה מידע רגיש. כשאתם מתבקשים להכניס סיסמה, היא נשלחת דרך המנהרה המוצפנת הזאת, וגם אם מישהו יירט את המידע, הוא יראה רק ג'יבריש מוצפן לחלוטין. 📝 סיכום: יSSH פותר את פרדוקס שיתוף המפתחות בצורה מבריקה. באמצעות אלגוריתם דיפי-הלמן, הוא מאפשר לשני צדדים ליצור מפתח סודי משותף על גבי רשת פתוחה, מבלי לחשוף את המפתח עצמו. התהליך הזה קורה בשבריר שנייה בכל פעם שאתם יוצרים חיבור SSH, ומבטיח שהשיחה שלכם פרטית ומוגנת מהרגע הראשון. בפוסט הבא בסדרה... יש לנו מנהרה מוצפנת והסיסמה שלנו מוגנת בזמן המעבר. אז אנחנו בטוחים, נכון? לא בדיוק. בפוסט הבא נדבר על החוליה החלשה ביותר בשרשרת האבטחה - הסיסמה שלכם עצמה, ואיך תוקפים מנסים לנחש אותה גם כשהיא בתוך המנהרה. 🎯 הצטרפו לערוץ @CYBERSECURITYCODING

רק אחרי שווידאתם ב-100% שהטביעה שמוצגת לכם בטרמינל זהה לזו מהמקור האמין, רק אז הקלידו yes בלב שלם. 📝 סיכום: ההודעה על "אותנטיות המארח" אינה סתם הודעה טכנית, היא קו ההגנה החשוב ביותר שלכם בחיבור הראשוני. התייחסו אליה בכבוד הראוי. אימות טביעת האצבע הוא הבסיס שעליו נבנה כל האמון העתידי שלכם עם השרת. אל תהיו "Yes Men" – תהיו אנשי מקצוע שבודקים לפני שהם סומכים. ומה הלאה? בפוסט הבא בסדרה... אימתתם את השרת והתחברתם. מעולה! 🥳 אבל איך SSH דואג שהסיסמה שלכם לא תיגנב במהלך השיחה, גם ברשת Wi-Fi לא מאובטחת? נדבר על התהליך הקריפטוגרפי שבונה מנהרה מוצפנת🚇✨ הצטרפו לערוץ @CYBERSECURITYCODING

🔐⚠️י SSH - הלחיצה על 'yes' שעלולה לעלות לכם ביוקר! ⚠️🔐 היי חברים! היום אנחנו צוללים לעומק של אחד הרגעים הכי שגרתיים, והכי מסוכנים, בעבודה של כל איש סייבר, מפתח או מנהל מערכת. הרגע הזה שבו אתם מתחברים לשרת חדש, והטרמינל שואל אתכם שאלה קריטית, אבל רובנו פשוט עונים yes ועוברים הלאה. בואו נבין אחת ולתמיד למה ההרגל הזה מסוכן, מה באמת קורה שם מתחת למכסה המנוע, ואיך להגן על עצמנו. 🛠️ 🤔 הסיטואציה המוכרת: "למה הוא שואל אותי את זה בכלל?" אתם מקלידים ssh user@new-server.com בפעם הראשונה, ומיד קופצת ההודעה הזו: The authenticity of host 'new-server.com (123.45.67.89)' can't be established. ED25519 key fingerprint is SHA256:aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? השאלה הזאת היא מנגנון ההגנה הראשון והחשוב ביותר של פרוטוקול SSH. המחשב שלכם (הלקוח) אומר לכם: "היי, אני רואה שרת בכתובת הזאת, אבל בחיים שלי לא דיברתי איתו. אין לי שום דרך לדעת אם זה השרת האמיתי או מתחזה. האם אתה, המשתמש, מוכן לקחת אחריות ולאשר לי שזה בסדר לסמוך עליו?" ⚙️ מאחורי הקלעים: טביעות אצבע והתקפת "האדם שבתווך" (MITM) כדי להבין את הסיכון, אנחנו חייבים להכיר שני מושגים: טביעת האצבע של השרת (Key Fingerprint): לכל שרת SSH יש זוג מפתחות קריפטוגרפיים ייחודיים (ציבורי ופרטי). טביעת האצבע היא ייצוג קצר וייחודי של המפתח הציבורי של השרת. חשבו על זה כמו מספר סידורי של דרכון 🛂 – הוא ייחודי לדרכון הזה בלבד, וקשה מאוד לזייף אותו. יש סוגים שונים של מפתחות (כמו RSA, ECDSA, Ed25519), ולכל אחד מהם השרת שלכם מייצר טביעת אצבע. התקפת "האדם שבתווך" (Man-in-the-Middle / MITM): זוהי התקפת סייבר קלאסית שבה תוקף 😈 ממקם את עצמו בין שני צדדים שמנסים לתקשר. האנלוגיה: דמיינו שאתם יושבים בבית קפה ☕ ומתחברים לרשת ה-Wi-Fi החינמית "Cafe_Net_Free". אבל, תוקף הקים רשת Wi-Fi מזויפת עם שם זהה. ברגע שהתחברתם, כל התעבורה שלכם עוברת דרך המחשב שלו. ההקשר ל-SSH: כשאתם מנסים להתחבר לשרת שלכם, התוקף (שיושב על אותה רשת קפה, או שהשתלט על נתב בדרך) מיירט את הבקשה שלכם. הוא מציג לכם את טביעת האצבע של השרת שלו, לא של השרת האמיתי. אם תאשרו (yes), אתם למעשה יוצרים חיבור SSH מוצפן ותקין... עם התוקף! 💣 הוא מצידו פותח חיבור לשרת האמיתי שלכם, ומעביר את כל התקשורת דרכו. 🛡️ השלכות אבטחת מידע: מה קורה אחרי שלחצתם 'yes' לתוקף? ברגע שאישרתם את טביעת האצבע של התוקף, הוא שולט בכל השיחה: גניבת סיסמאות: הוא יראה את הסיסמה שלכם בטקסט רגיל כשתקלידו אותה. גניבת מפתחות: אם אתם משתמשים באימות מפתחות, הוא יוכל להעביר את האתגר הלאה ולנסות לגנוב מידע על המפתח הפרטי שלכם. הזרקת פקודות: הוא יכול לשנות פקודות שאתם שולחים. אתם תקלידו ls -la כדי לראות קבצים, והוא ישנה את זה ל-rm -rf / ויוסיף פקודה להורדת נוזקה. ציתות וגניבת מידע: הוא יכול להקליט את כל הסשן, לגנוב קבצים רגישים, קוד מקור, מפתחות API מה שעובר במנהרה. המודל הזה נקרא Trust On First Use (TOFU). מרגע שאישרתם טביעת אצבע, המחשב שלכם שומר אותה בקובץ טקסט פשוט בשם ~/.ssh/known_hosts. מעתה והלאה, הוא יצפה לראות רק את טביעת האצבע הזאת מהשרת. אם תתחברו ופתאום תופיע טביעת אצבע אחרת, SSH יצעק עליכם באזהרה אדומה ענקית: @@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@. זוהי נורת אזהרה קריטית שאומרת שאו שהשרת הותקן מחדש, או שאתם תחת התקפת MITM. 🛠️ הפרקטיקה הנכונה: איך מוודאים ולא מאשרים עיוורת? הפתרון הוא אימות מחוץ לערוץ (Out-of-Band Verification). כלומר, לאמת את טביעת האצבע בערוץ תקשורת אחר, שאתם סומכים עליו. בדקו מול ספק הענן: אם השרת שלכם ב-AWS, DigitalOcean, Azure וכו', היכנסו לקונסולת הניהול של השרת. כמעט תמיד יש שם אפשרות לראות את טביעות האצבע של השרת. השוו אות-אחר-אות. השתמשו בקונסולת החירום: לרוב הספקים יש קונסולה מבוססת דפדפן שנותנת גישה ישירה לשרת. התחברו דרכה (זה חיבור מאובטח מראש) והריצו את הפקודה הבאה כדי לראות את טביעות האצבע ישירות מהמקור: Bash # Check fingerprints for all public keys in the ssh directory for f in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$f"; done שאלו את מנהל הרשת: התקשרו, או גשו פיזית למנהל המערכת ובקשו ממנו לוודא אתכם את טביעת האצבע.