Cyber & Code

🔓🤖 מה זה "הזרקת פרומפטים" ואיך משתלטים על מודלי AI? 🤖🔓 היי חברים. בטח שמעתם על כל מיני טריקים שגורמים ל-ChatGPT ודומיו "להשתגע" - פתאום הם מסכימים לענות על שאלות שאסור להם, חושפים מידע פנימי, או סתם מתחילים לדבר שטויות. לתופעה הזו קוראים הזרקת פרומפטים (Prompt Injection), וזו אחת מבעיות האבטחה הכי גדולות בעולם הבינה המלאכותית כיום. אז מה זה אומר בפועל? 🤔 דמיינו שלכל מודל AI יש "ספר חוקים" סודי (System Prompt) שהמפתחים שלו כתבו. בספר הזה כתוב לו איך להתנהג, מה אסור לו להגיד, ומה המטרה שלו. למשל: "היה מנומס", "אל תיצור תוכן פוגעני", "שמור על סודיות". הזרקת פרומפט היא פשוט מניפולציה חכמה שבה אנחנו, המשתמשים, כותבים לו הוראה (פרומפט) שמבלבלת אותו וגורמת לו להתעלם מספר החוקים המקורי שלו, ובמקום זאת להקשיב לחוקים החדשים שאנחנו נתנו לו. זה כמו להגיד לו: "תשכח מכל מה שאמרו לך, מעכשיו אני הבוס". תמיד רציתם לדעת איך לשחרר את הכלים האלה? יש מאגר גיטהאב מסודר בנושא! 🤓 חוקר אבטחה אסף מאגר מטורף שמכיל עשרות דוגמאות וטכניקות "פריצה" (Jailbreaks) לכל המודלים הגדולים, מ-OpenAI ועד גוגל ו-Claude. המאגר מראה איך באמצעות טקסטים יצירתיים, אימוג'ים ואפילו תמונות, אפשר לעקוף את ההגנות. זהו מקור מידע מדהים ללמוד איך ההתקפות האלה עובדות בפועל. הקישור למאגר: https://github.com/elder-plinius/L1B3RT4S.git תהנו , וזכרו השתמשו בידע הזה בתבונה ולמטרות חוקיות בלבד!!! הצטרפו לערוץ @CYBERSECURITYCODING

🚀 רוצים להתקדם בעולם הסייבר? בערוץ יוטיוב מקצועי מחכה לכם אוסף עשיר של הדרכות סייבר – מסביר שלב אחרי שלב איך להבין, לאתר ולהגן בדיוק כמו המומחים. ✅ תכנים בחינם ✅ הסברים פרקטיים וברורים ✅ מתאים גם למתחילים וגם למתקדמים 📌 זה המקום להפוך ידע תיאורטי ליכולות אמיתיות. לכניסה לערוץ היוטיוב 👉 [קישור לערוץ ה-YouTube] לכניסה לערוץ הטלגרם 👉 [קישור לערוץ הטלגרם]

סדרת פוסטים: כל מה שרציתם לדעת על JWT (5/5) 🛡️ כללי הברזל לאבטחת JWT 🛡️ בארבעת הפוסטים האחרונים יצאנו למסע. פירקנו את מבנה ה-JWT, ניפצנו את המיתוס סביב הסודיות שלו, הבנו את כוחו המהפכני באימות "חסר-מצב", וראינו כיצד תכונה תמימה יכולה להפוך לפרצת אבטחה קריטית. כעת, הגיע הזמן לאסוף את כל התובנות ולזקק אותן לכדי רשימת כללים מעשיים וברורים. אם תקפידו על הכללים הבאים, תוכלו להשתמש ב-JWT בביטחון וביעילות, ולהפוך אותו לנכס אבטחתי במערכות שלכם, ולא לנקודת תורפה. אלו הם כללי הברזל לעבודה נכונה עם JWT: כלל1: לעולם אל תסמכו על הקלט - הגדירו "רשימה לבנה" זהו הלקח הישיר מהפוסט הקודם והכלל החשוב ביותר. השרת שלכם חייב לדעת מראש באיזה אלגוריתם חתימה הוא מצפה להשתמש, ואסור לו להקשיב למה שהטוקן הנכנס "מציע" לו. בפועל, זה אומר שבקוד שלכם, בעת אימות הטוקן, אתם חייבים להגדיר במפורש את רשימת האלגוריתמים המותרים (Whitelist). ברוב המקרים, זו תהיה רשימה עם פריט אחד בלבד. דוגמה נכונה: verify(token, secret, { algorithms: ['HS256'] }) כך, גם אם תוקף ישלח לכם טוקן מושלם עם alg: "none" בכותרת, הקוד שלכם יזרוק אותו מיד כי "none" לא נמצא ברשימה הלבנה שלכם. זהו הפתרון הפשוט והמוחלט לפרצת ה-alg: 'none'. כלל 2: שמרו על המפתח הסודי כל אבטחת החתימה שלכם נשענת על סודיות המפתח. אם המפתח הסודי (Secret Key) שבו אתם משתמשים לחתימה דולף, תוקף יכול לחתום על כל טוקן שירצה, עם אילו הרשאות שיבחר, והשרת שלכם יאמין לו. השתמשו במפתחות חזקים: ודאו שהמפתח ארוך, אקראי, ולא ניתן לניחוש. אל תכתבו מפתחות בקוד: אחסנו את המפתח במשתני סביבה (Environment Variables) או במערכות ייעודיות לניהול סודות (Secret Managers). בצעו רוטציה: במערכות גדולות, החליפו את המפתח הסודי מדי פעם . כלל 3: תנו לטוקנים תאריך תפוגה קצר כל JWT צריך לכלול "טענת" תפוגה (exp - Expiration Time). טוקן שפג תוקפו יידחה אוטומטית על ידי השרת. ככל שתוקף הטוקן קצר יותר, כך חלון ההזדמנויות של תוקף (במקרה שהטוקן נגנב) מצטמצם. מומלץ להשתמש בטוקני גישה (Access Tokens) עם זמן חיים קצר, ובמקביל להשתמש ב"טוקן רענון" (Refresh Token) עם זמן חיים ארוך יותר כדי לחדש אותם בצורה מאובטחת. כלל 4: חזרו על המנטרה - JWT אינו כספת זהו סיכום של מה שלמדנו בפוסט השני. JWT הוא כלי להעברת טענות מאומתות, לא להעברת מידע סודי. אל תשימו ב-Payload שום מידע שלא הייתם רוצים שייחשף אם הטוקן יודלף. התובנה המרכזית אם צריך לסכם את כל הסדרה במשפט אחד, הוא יהיה זה: JWT הוא כלי להבטחת אמון, לא להבטחת סודיות. ההבנה העמוקה של המשפט הזה היא המפתח לשימוש נכון, יעיל ובטוח בטכנולוגיה העוצמתית הזו. בזאת סיימנו את הצלילה לעומק עולם ה-JWT. אני מקווה שהסדרה הייתה מועילה וסיפקה לכם ערך. זכרו תמיד את העיקרון החשוב ביותר בעולם הסייבר: אל תסמכו על קלט, תשאלו שאלות, ותמיד תחשבו "איך אפשר לשבור את זה?". שאלות? הערות? שתפו בתגובות 👇 הצטרפו לערוץ @CYBERSECURITYCODING

סדרת פוסטים: כל מה שרציתם לדעת על JWT (4/5) 💥 המתקפה: איך לגרום לשרת לסמוך על טוקן מזויף? 💥 עד עכשיו, בנינו תמונה של מערכת מאובטחת. למדנו שהחתימה הדיגיטלית היא ה"שומר" של ה-JWT; היא מוודאת שהמידע אמין ולא זויף. אבל מה אם תוקף מתוחכם יכול פשוט... לבקש מהשומר לזוז הצידה? מה אם הוא יכול להגיש "תעודת VIP" עם פתק קטן מצורף שאומר "התעודה הזו לא צריכה חתימה, פשוט תאמין למה שכתוב בה"? זה נשמע אבסורדי, אבל זו בדיוק המהות של פרצת האבטחה הקלאסית והמסוכנת ביותר בעולם ה-JWT: מתקפת ה-alg: 'none'. פיצ'ר שהפך לבאג התקן של JWT מאפשר, באופן מובנה, ליצור טוקן לא חתום. איך המערכת יודעת שהטוקן לא חתום? פשוט מאוד: בתוך ה-Header (המפרט הטכני), במקום לציין אלגוריתם חתימה כמו HS256, פשוט כותבים alg: "none". 🤔 שאלה מתבקשת: למה שהפיצ'ר הזה יהיה קיים בכלל? זה נשמע כמו פרצת אבטחה מובנית, אז למה שהתקן יאפשר דבר כזה מלכתחילה? ישנן כמה סיבות לגיטימיות: שילוב עם הצפנה (JWE): לפעמים, ה-JWT עצמו "נעטף" בתוך שכבת הצפנה נוספת (בתקן נפרד שנקרא JWE). במקרה כזה, המעטפת המוצפנת החיצונית כבר מבטיחה שהמידע אמין ומוגן, ולכן החתימה על התוכן הפנימי (ה-JWT) הופכת למיותרת ויכולה להיחשב כבזבוז משאבים. מערכות פנימיות מהירות: בתוך רשת פנימית מאובטחת, בין שירותים (Microservices) שכבר סומכים אחד על השני, מפתחים לפעמים מוותרים על החתימה כדי לחסוך זמן עיבוד יקר. ההנחה היא שבסביבה המבוקרת הזו, אין סכנה של התערבות חיצונית וזיוף. בדיקות ופיתוח: בשלבי הפיתוח, לעיתים נוח יותר למפתחים לעבוד עם טוקנים לא חתומים כדי לבדוק את הלוגיקה של האפליקציה בלי להתעסק עם ניהול מפתחות וחתימות בכל שינוי קטן. הכוונה הייתה טובה לאפשר גמישות. הבעיה נוצרת כאשר ספריות בצד השרת, שנועדו לטפל בכל המקרים האפשריים, לא מכריחות את המפתח לבחור מראש באילו אלגוריתמים הוא תומך. הן משאירות את הבחירה "פתוחה", מה שמאפשר לתוקף לכפות על השרת את האופציה המסוכנת none. מתכון לאסון: תקיפת alg: 'none' שלב אחר שלב התוקף לא צריך להיות גאון קריפטוגרפי. הוא רק צריך לעקוב אחר ארבעה שלבים פשוטים: השגת טוקן תקין: התוקף נרשם לאתר כמו כל משתמש רגיל ומקבל JWT סטנדרטי, חתום כהלכה. פירוק ושינוי הכותרת (Header): התוקף לוקח את החלק הראשון של הטוקן (ה-Header), מפענח אותו מ-Base64, ומשנה ערך אחד בלבד: את שדה ה-alg הוא משנה מ-HS256 (או כל אלגוריתם אחר) לערך none. שדרוג הרשאות בתוכן (Payload): התוקף עובר לחלק השני (ה-Payload), מפענח גם אותו, ומשנה את "הטענות" לטובתו. למשל, הוא יכול לשנות את הערך "isAdmin": false ל-"isAdmin": true. הרכבה מחדש... בלי חתימה: עכשיו התוקף מקודד בחזרה את ה-Header וה-Payload החדשים. את החלק השלישי, החתימה המקורית, הוא פשוט מוחק. הטוקן המזויף שהוא שולח לשרת נראה כך: MODIFIED_HEADER.MODIFIED_PAYLOAD. רגע הכשל: כשהשרת סומך יותר מדי כאשר שרת שאינו מוגדר נכון מקבל את הטוקן המזויף הזה, קורה דבר נורא: הספרייה שאחראית על אימות ה-JWT קוראת קודם כל את ה-Header. היא רואה את ההוראה: alg: "none". היא מסיקה: "אה, לפי ההנחיות במסמך הזה, אני לא אמור לבדוק חתימה כלל". היא מקבלת את ה-Payload ששונה על ידי התוקף כאמת לאמיתה. בשלב הזה, המשחק נגמר. התוקף הוא עכשיו מנהל מערכת ויכול לעשות ככל העולה על רוחו. ראינו איך פיצ'ר תמים לכאורה יכול להפוך לכלי נשק הרסני בידיים הלא נכונות. החדשות הטובות הן שההגנה מפני המתקפה הזו היא פשוטה להפליא, אם רק מקפידים על כלל בסיסי אחד. בפוסט האחרון והמסכם שלנו נציג את הכללים וההגדרות המעשיות שיבטיחו שהמערכות שלכם יהיו חסינות לחלוטין מפני מתקפה זו ואחרות. שאלות? הערות? שתפו בתגובות 👇 הצטרפו לערוץ @CYBERSECURITYCODING

סדרת פוסטים: כל מה שרציתם לדעת על JWT (3/5) 🚀 הכוח האמיתי של JWT: אימות "חסר-מצב" (Stateless) 🚀 בשני הפוסטים הקודמים הבנו מהו JWT (תעודה דיגיטלית חתומה) ומה הוא לא (כלי להסתרת מידע). כעת הגענו לשאלת מיליון הדולר: אם המידע בו גלוי, למה הוא נחשב לטכנולוגיה ששינתה את עולם הפיתוח? התשובה טמונה במושג מהפכני שנקרא אימות חסר-מצב (Stateless Authentication). כדי להבין את הפתרון, בואו נסתכל לרגע על הבעיה, או "הדרך הישנה" שבה נהגו לאמת משתמשים. השיטה הישנה: אימות מבוסס-מצב (Stateful) בעבר, התהליך היה דומה לרישום אורחים במלון: כניסה (Login): משתמש שולח שם וסיסמה. יצירת "תיק אורח" בשרת: השרת מאמת את הפרטים, יוצר "סשן" (Session) ייחודי עבור המשתמש, ושומר אותו בזיכרון או במסד נתונים משלו. הוא בעצם פותח "תיק" שבו רשום: "מזהה סשן ABCDE שייך למשתמש דני". קבלה (Cookie): השרת שולח למשתמש "פתק" קטן (Cookie) עם מזהה הסשן ABCDE. ביקורים חוזרים: בכל פעם שהמשתמש מבקש דף חדש, הוא מציג את הפתק. השרת לוקח את המזהה ABCDE, מחפש אותו ב"קלסר התיקים" שלו, מוצא את התיק של דני, ומעניק לו גישה. זה עובד, אבל יוצר שתי בעיות ענק כשהמערכת גדלה: עומס על השרת: השרת צריך "לזכור" ולנהל תיק עבור כל משתמש שמחובר כרגע. עם מיליוני משתמשים, זה הופך לסיוט לוגיסטי. בעיית סנכרון (Scalability): מה קורה אם יש לנו 10 שרתים שונים כדי להתמודד עם העומס? אם דני נכנס דרך שרת מס' 1, התיק שלו נמצא שם. אם הבקשה הבאה שלו מגיעה לשרת מס' 7, לשרת הזה אין מושג מי הוא! זה מכריח פתרונות מסורבלים כמו סנכרון מאגרי ה"תיקים" בין כל השרתים. המהפכה של JWT: השרת לא צריך לזכור כלום כאן JWT משנה את כללי המשחק. הוא מאפשר אימות חסר-מצב, כלומר, השרת לא צריך לשמור שום "תיק" או "מצב" לגבי המשתמש. התהליך החדש נראה כך: כניסה (Login): המשתמש שולח שם וסיסמה. הנפקת "תעודה" חכמה: השרת מאמת את הפרטים, ובמקום לפתוח תיק, הוא מנפיק JWT. בתוך התעודה הזו כבר כתוב מי המשתמש ומה הרשאותיו ("user_id": "דני", "isAdmin": false), והכל חתום דיגיטלית. המשתמש מחזיק בתעודה: המשתמש שומר את ה-JWT אצלו (למשל בזיכרון הדפדפן). ביקורים חוזרים: בכל בקשה עתידית, המשתמש מציג את ה-JWT שלו. כל שרת שיקבל את הבקשה, לא צריך לחפש בשום מקום. הוא פשוט מסתכל על החתימה הדיגיטלית של התעודה. אם החתימה תקינה, הוא סומך מיד על מה שכתוב בפנים ומשרת את הבקשה. היתרונות אדירים: גדילה אינסופית (Scalability): אפשר להוסיף 200 שרתים חדשים מחר בבוקר. כל עוד לכולם יש את "המפתח הסודי" לבדיקת החתימה, כל שרת יכול לאמת כל משתמש באופן מיידי, ללא צורך בסנכרון. הפחתת עומס: השרתים פנויים מניהול הזיכרון של מיליוני סשנים. גמישות ארכיטקטונית: שיטה זו מושלמת למערכות מודרניות כמו מיקרו-שירותים (Microservices), שבהן שירותים שונים צריכים לתקשר ולאמת בקשות בינם לבין עצמם. ראינו את הכוח, אבל כאן גם טמונה סכנה. מה קורה כשהמערכת סומכת על התעודה הזו באופן עיוור מדי? ומה אם התוקף יכול לשנות את ה"חוקים" שכתובים על התעודה עצמה? בפוסט הבא נצלול לפרצת האבטחה המפורסמת והמסוכנת ביותר בעולם ה-JWT, מתקפת ה-alg: 'none', ונראה איך היגיון פשוט יכול להפוך למלכודת. שאלות? הערות? שתפו בתגובות 👇 הצטרפו לערוץ @CYBERSECURITYCODING

סדרת פוסטים: כל מה שרציתם לדעת על JWT (2/5) 🔓 יJWT - מעטפה שקופה או כספת נעולה? 🔓 בפוסט הקודם, פירקנו את ה-JWT לשלושת מרכיביו וראינו שהחלק המרכזי, ה-Payload, מכיל את המידע על המשתמש. כשרואים את מחרוזת התווים הארוכה והבלתי קריאה של הטוקן, קל מאוד ליפול למחשבה שהמידע הזה מוצפן וסודי. זוהי טעות נפוצה ומסוכנת. האמת היא שהמידע ב-JWT כלל אינו סודי. כדי להבין מדוע, אנחנו חייבים להכיר את ההבדל היסודי בין קידוד (Encoding) לבין הצפנה (Encryption). 🤔 קידוד (Encoding): שינוי צורה, לא הסתרה קידוד הוא תהליך של המרת מידע מפורמט אחד לאחר, למטרה של נוחות ויעילות העברה. אין כאן שום כוונה להסתיר את המידע. הקידוד שבו משתמש JWT נקרא Base64. המטרה היחידה שלו היא לקחת כל סוג של מידע (במקרה שלנו, טקסט בפורמט JSON) ולהפוך אותו למחרוזת טקסט שמורכבת רק מאותיות באנגלית, מספרים, והסימנים + ו-/. זה מבטיח שהטוקן יוכל לעבור בבטחה בכל מערכת אינטרנטית, ללא חשש שתווים מיוחדים "ישברו" את התהליך. האנלוגיה הפשוטה: חשבו על קידוד כמו תרגום משפה לשפה. אם אתם רואים טקסט ביפנית, הוא אולי נראה לכם כג'יבריש, אבל כל מי שיודע יפנית יכול לקרוא אותו מיד. לא צריך "מפתח סודי" כדי לתרגם, רק את מילון השפה. כך גם עם Base64 – זהו תקן פתוח, וכל אחד יכול לקודד ולפענח אותו בשנייה. 🔒 הצפנה (Encryption): הסתרה אמיתית הצפנה, לעומת זאת, נועדה להסתיר מידע. בתהליך ההצפנה, מידע קריא (Plaintext) הופך למידע בלתי קריא (Ciphertext) באמצעות "מפתח סודי". הדרך היחידה להחזיר את המידע למצבו המקורי היא להשתמש באותו מפתח. בלי המפתח, המידע נשאר נעול וחסר משמעות. זוהי הכספת הדיגיטלית. ✉️ אז מהו JWT? מעטפה שקופה עם חותמת מיוחדת האנלוגיה הטובה ביותר ל-JWT היא מכתב שנשלח במעטפה שקופה, שנסגרה באמצעות החותמת המיוחדת. המעטפה השקופה (קידוד Base64): כל אחד בדרך יכול להסתכל דרכה ולקרוא את תוכן המכתב (ה-Payload). החותמת(החתימה הדיגיטלית): היא לא מסתירה את התוכן, אבל היא מספקת שתי הבטחות קריטיות: שהמכתב אכן הגיע מהשולח הנכון (אותנטיות). שהמעטפה לא נפתחה ותוכנה לא שונה בדרך (שלמות). ⚠️ כלל הברזל: לעולם אל תשימו סודות ב-JWT ⚠️ זו הנקודה החשובה ביותר בפוסט הזה. מכיוון שה-Payload הוא מעטפה שקופה, אסור בתכלית האיסור לשמור בו מידע רגיש שחשיפתו תגרום נזק. מה אסור לשים ב-Payload? סיסמאות פרטי כרטיס אשראי מספרי תעודת זהות מפתחות API סודיים כל מידע אישי רגיש אחר רוצים לנסות? גשו לאתר jwt.io, הדביקו בחלונית השמאלית כל JWT שתמצאו (רק לא אחד אמיתי שלכם!), וראו כיצד ה-Header וה-Payload מופיעים מיד כטקסט קריא בחלונית הימנית. אז אם הוא לא נועד להסתיר מידע, מה הופך את ה-JWT לכלי כל כך חזק ומרכזי באפליקציות מודרניות? בפוסט הבא נגלה את כוחו האמיתי, ונבין כיצד הוא מאפשר "אימות חסר-מצב" (Stateless Authentication) – תפיסה ששינתה את הדרך בה אנו בונים מערכות יעילות ומדרגיות (Scalable). שאלות, הערות, שתפו אותנו בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

סדרת פוסטים: כל מה שרציתם לדעת על JWT (1/5) 📜 מבוא ל-JWT: "תעודת הזהות" הדיגיטלית ששינתה את האינטרנט 📜 בעולם הדיגיטלי, אימות זהות הוא אתגר יסודי. איך מערכת אחת יכולה לסמוך על מערכת אחרת? איך שרת יכול "לזכור" משתמש שכבר הזדהה, מבלי לשמור רשימה ארוכה של כל המחוברים? תארו לעצמכם שאתם מקבלים כרטיס VIP לאירוע יוקרתי. על הכרטיס רשום שמכם, הגישה המותרת לכם ("מתחם אמנים"), ותאריך תפוגה. הכרטיס עצמו מוטבע בחותמת הולוגרפית מיוחדת שאי אפשר לזייף. השומר בכניסה לא צריך להכיר אתכם אישית או לחפש את שמכם ברשימה; הוא רק צריך לבדוק שהכרטיס נראה תקין ושהחותמת אמיתית. אם כן, הוא סומך על מה שכתוב בכרטיס ומכניס אתכם. הכרטיס הזה, בעולם הרשת, הוא JSON Web Token, או בקיצור JWT. זהו תקן פתוח שמאפשר העברה בטוחה של מידע בין צדדים בתור "אסימון" (Token) דיגיטלי, חתום ומהימן. 🤔 אז איך זה עובד? יJWT הוא בסך הכל מחרוזת טקסט ארוכה, שמורכבת משלושה חלקים המופרדים בנקודה. כל חלק מקודד בשיטה שנקראת Base64URL (עליה נרחיב בפוסט הבא), והמבנה נראה כך: XXXX.YYYY.ZZZZ. בואו נפרק את שלושת החלקים: 1️⃣ יHeader (הכותרת - המפרט הטכני) החלק הראשון הוא כמו הכריכה של מסמך רשמי. הוא מכיל מטא-דאטה, כלומר, מידע על המידע. הוא תמיד יכלול שני פרטים עיקריים: יtyp: סוג הטוקן (כמעט תמיד 'JWT'). יalg: האלגוריתם הקריפטוגרפי ששימש ליצירת החתימה (למשל HS256 או RS256). זה החלק החשוב ביותר, כי הוא אומר לשרת איך לוודא שהטוקן אמין. 2️⃣ יPayload (התוכן - גוף המידע) כאן נמצא ה"בשר" של הטוקן – המידע שאנחנו רוצים להעביר. המידע הזה נקרא "Claims" (טענות). למשל, ה-Payload יכול להכיל טענות כמו: יsub: זהות המשתמש (user_id: "12345"). יname: שם המשתמש ("John Doe"). יisAdmin: האם למשתמש יש הרשאות מנהל (true). יexp: תאריך תפוגה של הטוקן (Timestamp). חשוב להבין כבר עכשיו: המידע כאן אינו סודי. הוא רק מקודד, וכל אחד יכול לקרוא אותו בקלות. 3️⃣י Signature (החתימה - החותם הדיגיטלי) זהו רכיב האבטחה הקריטי. החתימה היא מה שהופך את ה-JWT לאמין ומונע זיופים. היא נוצרת על ידי השרת באמצעות תהליך קריפטוגרפי שלוקח את ה-Header, ה-Payload, ומוסיף להם "מפתח סודי" (Secret Key) שקיים רק בשרת. החתימה מבטיחה שני דברים: אותנטיות: היא מוכיחה שהטוקן אכן נוצר על ידי השרת שמחזיק במפתח הסודי. שלמות (Integrity): היא מוודאת שאף אחד לא שינה את ה-Header או ה-Payload בדרך. כל שינוי, אפילו של תו אחד, יגרום לחתימה להיות לא תואמת. לסיכום החלק הראשון: יJWT הוא שיטה גאונית להנפיק "תעודות זהות" דיגיטליות שהן: ניידות (Self-Contained): כל המידע הדרוש נמצא בתוך הטוקן עצמו. אמינות (Verified): החתימה הקריפטוגרפית מבטיחה שהמידע אמין ולא שונה. יעילות (Stateless): השרת לא צריך לשמור שום מידע על הטוקן, רק לוודא את החתימה בכל פעם. אבל רגע, אם התוכן גלוי לכל, איפה הסודיות? האם זו לא פרצת אבטחה? 🤔 בפוסט הבא נצלול להבדל המהותי בין קידוד להצפנה שאלות, הערות, שתפו אותנו בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

רוצים את הכלי? הנה איך להתקין ולהריץ! הנה מדריך מהיר להתקנה ושימוש בסורק האבטחה שלנו. אחרי זה, אתם מוכנים לסרוק! 🛠️ התקנה ב-3 צעדים ודאו שמותקן לכם פייתון ו-Nmap (בקאלי לינוקס Nmap כבר קיים). פרסו את קובץ ה-ZIP והיכנסו לתיקייה דרך הטרמינל. הריצו את הפקודה הזו להתקנת התלויות: pip install -r requirements.txt 🚀 איך מריצים? הפקודה הבסיסית היא: python scanner.py <IP> <MODE> מצבי הסריקה: י🔹 -q: מהירה - לבדיקה זריזה. י🔹 -m: בינונית - מאוזנת ומומלצת. י🔹 -d: עמוקה - יסודית (ולוקחת זמן). לדוגמה, לסריקה בינונית הריצו: python scanner.py 192.168.1.10 -m הדוח יחכה לכם בקובץ HTML באותה התיקייה. ⚠️ חובה לקרוא! הכלי נועד ללימודים ולבדיקות חוקיות בלבד! הצטרפו לערוץ @CYBERSECURITYCODING

🔎 הדגמה: סורק אבטחה חדש שמייצר דוחות ויזואליים שלום לכולם, הכנו לכם סרטון הדרכה על כלי פייתון חדש ושימושי שפותח כאן אצלנו בקהילה(המנהל המוכשר שעוזר לי לנהל את הערוץ). הכלי נועד לייעל את שלב איסוף המודיעין (Reconnaissance), על ידי שילוב של סריקת רשת וזיהוי שירותים עם הפקת דוח HTML נוח לניתוח. בסרטון תראו: 🔹 הסבר על שלושת מצבי הסריקה של הכלי ומה ההבדל ביניהם. 🔹 הדגמה של סריקה בינונית על מכונת המטרה Metasploitable 2. 🔹 כיצד לקרוא את הדוח הויזואלי ומה המשמעות של הממצאים, כמו זיהוי גרסאות ומערכת הפעלה. 🔹 טיפים לניתוח התוצאות והבנת הצעדים הבאים בבדיקת חדירות. זהו כלי נהדר למי שמחפש דרך נוחה ומסודרת לרכז את ממצאי הסריקה הראשונית שלו. מוזמנים לצפות. אם תרצו להתנסות עם הקוד בעצמכם, כתבו לנו בתגובות ונשמח לשתף אותו.

ממש מענין.

אוקיי, בגלל שאהבתם את הסרטון וביקשתם את הקוד, אני מצרף אותו כאן בשבילכם. כדי להפעיל את העוזר תצטרכו לבצע את הצעדים הבאים: מה צריך? 1. תוכנת LM Studio מותקנת על המחשב. אם אין לכם, הנה הקישור להורדה: https://lmstudio.ai 2. מחשב עם חומרה מתאימה, ובעיקר כרטיס מסך. 3. בתוך LM Studio, חפשו והורידו את המודל הבא. פשוט העתיקו את השם לשורת החיפוש: שם המודל:google/gemma-3-12b- (זהו המודל המעודכן והמומלץ בסדרה שנקראת Gemma, והוא ייתן את הביצועים הטובים ביותר). הוראות הפעלה ⚙️ 1. פתחו טרמינל (CMD או PowerShell) בתיקייה הראשית של הפרויקט שקיבלתם. 2. הריצו את שתי הפקודות הבאות כדי להתקין את הספריות הדרושות:

    pip install openai
    

    pip install eel
    

3. ודאו שהשרת של LM Studio פועל ברקע עם המודל שטענתם. 4. לבסוף, הריצו את הסוכן עם הפקודה:

    python main.py
    

וזהו, הסוכן שלכם אמור להיפתח! ✨ 💡 טיפ חשוב: אם הסוכן לא מצליח לבצע פעולות מסוימות (כמו חיפוש קבצים או פתיחת תוכנות), סגרו את החלון והריצו את main.py שוב, אך הפעם "כמנהל מערכת" (קליק ימני על הטרמינל ובחרו הפעל כמנהל).

נמאס לכם לדאוג לפרטיות שלכם כשאתם משתמשים ב-AI? עשיתי לכם סרטון מיוחד שנוגע באחת הבעיות הגדולות של עולם הבינה המלאכותית: הפרטיות והבעלות על המידע שלנו. בניתי עוזר AI אישי שרץ 100% לוקאלית על המחשב, בלי לשלוח שום מידע החוצה. אפס תלות בחברות ענק, אפס דאגות אבטחה. הוא יכול לעשות דברים מדהימים כמו: לאבחן בעיות במחשב בזמן אמת. לכתוב ולהריץ סקריפטים של PowerShell כדי לבצע משימות מורכבות. לנהל קבצים ותיקיות על פי הוראות בשפה טבעית. והחלק הכי טוב? אתם בשליטה מלאה, עם אישור גרפי לכל פעולה שהוא רוצה לבצע. הכנתי סרטון שמדגים את כל התהליך, רוצים לבנות אחד כזה בעצמכם? כתבו לי בתגובות לסרטון ואשמח לשתף את קוד המלא! 💻

❤️🛡️ אז למה Tor כל כך חשוב, אם הוא לא מושלם? 🛡️❤️ פוסט 5 מתוך 5 סיכום הסדרה על Tor בארבעת הפוסטים האחרונים יצאנו למסע עומק אל תוך רשת Tor. למדנו על המשימה שלה (שבירת הקשר בין זהות לפעילות), על המכניקה המבריקה שלה (ניתוב בצל ושכבות הצפנה), וגם על החולשות המשמעותיות שלה (התקפות מתאם תעבורה והתקפות סיביל). הגענו למסקנה הבלתי נמנעת: Tor אינו גלימת היעלמות קסומה. מול יריב מדינתי חזק, בעל משאבים, שממוקד במטרה ספציפית (אתם) האנונימיות שלכם אינה מובטחת. אז אם כך, למה אנחנו מדברים עליו בכזו הערכה? למה הוא נחשב לאחד מכלי הפרטיות החשובים ביותר שנוצרו? 🎯 המטרה האמיתית: הגנה ממעקב המונים כאן אנחנו חייבים להפריד בין אנונימיות מוחלטת לבין הגנה יעילה. הכוח האמיתי של Tor הוא לא להפוך אדם אחד לבלתי נראה לחלוטין, אלא להפוך את המעקב אחר אוכלוסייה שלמה למשימה יקרה, מסובכת, וכמעט בלתי אפשרית. דמיינו שהאינטרנט הרגיל הוא עיר שבה כל אחד מסתובב עם שלט מעל הראש שאומר את שמו ולאן הוא הולך. קל מאוד לרשות מסוימת (או לכל אחד אחר) לעקוב אחרי כולם כל הזמן. רשת Tor, לעומת זאת, היא כמו נשף מסכות ענק שבו כולם לבושים אותו הדבר. האם שוטר נחוש יכול לעקוב אחרי אדם ספציפי בתוך הנשף? אולי, עם מספיק מאמץ ומשאבים. אבל האם הוא יכול לעקוב אחרי כולם בבת אחת? לא. 💸 שינוי כללי המשחק: הכלכלה של הריגול זו הנקודה החשובה ביותר: Tor משנה את הכלכלה של הריגול. ללא Tor: מעקב המונים הוא זול. ממשלות וחברות יכולות "לשאוב" כמויות אדירות של מידע באופן פסיבי ובעלות נמוכה יחסית. זהו מודל ה "dragnet" איסוף הכל על כולם, כל הזמן. עם Tor: המודל הזול והפסיבי הזה נשבר. כדי לגלות מה אדם ספציפי עושה, היריב חייב לעבור מאיסוף מידע זול להתקפה אקטיבית ויקרה נגד מטרה בודדת. הוא צריך להשקיע משאבים אדירים בניתוח תעבורה או בניסיון להשתלט על הרשת. יTor מכריח את הגורמים העוצמתיים ביותר בעולם להפסיק לרגל אחרי היער ולהתחיל להתמקד בעצים בודדים. עצם קיומו הופך את המעקב על אוכלוסייה שלמה ללא כדאי כלכלית. עבור מי זה קריטי? כל אחד מאיתנו: שרוצה להגן על פרטיותו מפני תאגידים וגורמים ממשלתיים שאוספים עלינו מידע ללא הרף. סיכום הסדרה יTor הוא לא מושלם, כי שום כלי אבטחה אינו מושלם. הוא תוצר של עולם לא מושלם. אבל חשיבותו אינה נמדדת ביכולתו לספק אנונימיות מוחלטת, אלא ביכולתו לשנות את מאזן הכוחות. הוא מהווה מחסום טכנולוגי וכלכלי בפני מעקב המונים, ומספק שכבת הגנה חיוניות. הוא תזכורת עוצמתית לכך שפרטיות היא זכות יסוד ששווה להילחם עליה. תודה רבה לכל מי שעקב אחרי הסדרה הזו! אני מקווה שהיא סיפקה לכם הבנה עמוקה יותר על אחד הכלים המרתקים בעולם הסייבר. שאלות? הערות? שתפו בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

🎭🛡️ שגורמים מנסים להשתלט על הרשת: התקפת סיביל ודרכי ההתגוננות 🛡️🎭 פוסט 4 מתוך 5 בסדרה על Tor בפוסט הקודם דיברנו על "הצופה הגלובלי" – יריב פסיבי שצופה בתעבורה כדי למצוא התאמות. אבל מה קורה כשהיריב מחליט שהוא לא רוצה רק לצפות במשחק, אלא לעלות על המגרש בעצמו? מה אם הוא מנסה להשתלט על התשתיות של Tor מבפנים? 🎭 האיום: "התקפת סיביל" (Sybil Attack) דמיינו שיריב בעל משאבים רבים (שוב, חשבו סוכנות ממשלתית) מחליט להקים אלפי צמתי Tor משלו. הצמתים האלה ייראו לגיטימיים לחלוטין ויציעו שירותי ניתוב כמו כל צומת אחר. המטרה של היריב היא "להציף" את הרשת בנוכחות שלו, ולהגדיל באופן דרמטי את הסיכוי שהמשתמשים יבחרו בצמתים שבשליטתו לבניית המעגלים שלהם. הסכנה הגדולה ביותר היא מצב שבו היריב מצליח לשלוט גם בצומת הכניסה וגם בצומת היציאה של המעגל שלכם. במקרה כזה, המשחק נגמר. הוא רואה את כתובת ה-IP האמיתית שלכם נכנסת, והוא רואה את התעבורה שלכם יוצאת ליעדה. הקשר נוצר, והאנונימיות שלכם נחשפה במאה אחוז. אם Tor היה בוחר צמתים בצורה אקראית לחלוטין בכל פעם, התקפת סיביל הייתה יעילה מאוד. ככל שהתוקף מריץ יותר צמתים, כך גדל הסיכוי הסטטיסטי ש"תיפלו" ברשת שלו. אז איך Tor מתגונן? 🛡️ ההגנה: "שומרי כניסה" (Entry Guards) כאן מפתחי Tor עשו משהו שנשמע בהתחלה לא אינטואיטיבי: הם ויתרו על אקראיות מוחלטת לטובת אסטרטגיה חכמה יותר. במקום לבחור צומת כניסה חדש ואקראי בכל פעם שאתם מתחברים, דפדפן ה-Tor שלכם נוקט בגישת ה"נאמנות": הבחירה הראשונית: בפעם הראשונה שאתם מפעילים את Tor, הלקוח שלכם בוחר מספר קטן מאוד (בדרך כלל 3) של צמתים שישמשו כ"שומרי הכניסה" הקבועים שלכם. מאגר האיכות: השומרים האלה לא נבחרים מכלל הרשת, אלא מרשימה מצומצמת של צמתים ותיקים, יציבים ומהירים, שזכו למוניטין גבוה וסומנו על ידי רשויות המדריך כצמתים אמינים (בעלי דגל Guard). הנעילה: מרגע שנבחרו, הלקוח שלכם "ננעל" על שומרי הכניסה האלה, וישתמש אך ורק בהם כנקודת הכניסה לרשת Tor לתקופה ארוכה מאוד (מספר חודשים). 🧠 למה האסטרטגיה הזו עובדת? בכך שאתם נצמדים למספר מצומצם של צמתים ותיקים ואמינים, אתם מקטינים דרמטית את הסיכוי שלכם להתקל בצומת זדוני חדש שהוקם במסגרת התקפת סיביל. במקום "להמר" מחדש בכל חיבור מול אלפי צמתים, אתם מהמרים פעם אחת על צמתים שכבר הוכיחו את אמינותם לאורך זמן. זה מצמצם באופן דרסטי את שטח התקיפה הפוטנציאלי. ⚠️ המחיר: ה-Trade-off של האבטחה כמו כל החלטת אבטחה טובה, גם לזו יש מחיר. האסטרטגיה הזו מבוססת על ההנחה ששומרי הכניסה שבחרתם הם אכן אמינים. אבל מה קורה אם היה לכם מזל רע, ואחד מהשומרים הקבועים שלכם הוא בעצם צומת זדוני (או נפרץ)? במקרה כזה, ליריב יש יתרון גדול. הוא אולי עדיין לא יודע לאן אתם גולשים, אבל הוא יודע בוודאות מתי אתם מתחברים לרשת Tor, ויודע לקשר את כל החיבורים האלה לזהות אחת. מידע זה מקל עליו מאוד לבצע התקפת מתאם תעבורה, כי הוא כבר מחזיק בחצי מהמידע הדרוש לו. זוהי פשרה מחושבת: Tor מקריב מעט כדי להגן מפני איום גדול יותר. הוא מעדיף סיכון נמוך יותר לחשיפה ממוקדת ומתמשכת על פני סיכון גבוה יותר לחשיפה רנדומלית ורחבת היקף. סיכום והקדמה לפוסט האחרון למדנו שהאויבים של Tor לא רק צופים מהצד, אלא מנסים באופן אקטיבי לחדור לרשת. מנגנון ה-Entry Guards הוא קו הגנה חיוני, אך גם הוא מגיע עם פשרות. ראינו ש-Tor אינו מושלם ושיש לו חולשות מול יריבים חזקים. זה מוביל אותנו לשאלה האחרונה והחשובה ביותר בסדרה: אם Tor אינו כלי לאנונימיות מוחלטת ובלתי-שבירה, אז למה הוא כל כך חשוב? עבור מי הוא כלי קריטי, ומהי תרומתו האמיתית לעולם? על כך נדון בפוסט הסיכום שלנו. הבנתם את הפשרה ש-Tor עושה? זהו עיקרון מפתח בהרבה מערכות אבטחה. דעתכם? שתפו בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

🕵️‍♂️🌐 האם Tor בלתי-שביר? הכירו את "הצופה הגלובלי" 🌐🕵️‍♂️ פוסט 3 מתוך 5 בסדרה על Tor בפוסטים הקודמים צללנו למכניקה המרשימה של Tor: שכבות הצפנה, ניתוב דרך שלושה צמתים, ופירוק המידע לתאים בגודל אחיד. אחרי כל המנגנונים המתוחכמים האלה, קל לחשוב שהרשת היא מבצר בלתי חדיר. אבל ההתקפה המסוכנת ביותר נגד Tor כלל לא מנסה לפרוץ את ההצפנה. 🛡️ עקב אכילס: הצפנה חזקה, אבל מה עם המטא-דאטה? ההצפנה של Tor (AES, RSA וכו') נחשבת חזקה מאוד ועד היום לא נפרצה בפועל. החולשה האמיתית של הרשת לא נמצאת בתוכן שעובר בה, אלא בדפוסים של התעבורה עצמה. זהו התחום של ניתוח תעבורה (Traffic Analysis) הסקת מסקנות על ידי צפייה בתזמון, בנפח ובקצב של חבילות מידע, מבלי לראות את התוכן שלהם. 👀 היריב: הכירו את ה"צופה הגלובלי" (Global Adversary) כדי לבצע ניתוח תעבורה יעיל נגד Tor, התוקף צריך להיות בעל יכולות יוצאות דופן. לא מדובר בהאקר בודד, אלא ביריב בסדר גודל של מדינה או סוכנות ביון (כמו ה-NSA). ליריב כזה יש יכולת לנטר חלקים עצומים מתעבורת האינטרנט העולמית. הוא יכול "לשבת" על כבלים תת-ימיים, נקודות החלפה מרכזיות (IXPs) וספקיות אינטרנט גדולות. היכולת הזו מאפשרת לו לראות גם את התעבורה שנכנסת לרשת Tor במדינה אחת, וגם את התעבורה שיוצאת מצומת יציאה במדינה אחרת. 🔗 ההתקפה: מתאם קצה-לקצה (End-to-End Correlation) כפי שרמזנו בפוסט הקודם, ההתקפה לא מסתכלת על תאים בודדים, אלא על "טביעת האצבע" של זרם התקשורת כולו. כך זה עובד: שלב א' - צפייה בכניסה: הצופה הגלובלי מזהה את התעבורה שלכם (יוצאת מכתובת ה-IP שלכם) כשהיא נכנסת לצומת הכניסה של Tor. הוא לא יכול לראות לאן אתם הולכים, אבל הוא מתעד את הפרופיל של התעבורה: תזמון: מתי החיבור התחיל והסתיים. נפח: כמה מידע (כמה תאים) עובר בכל רגע נתון. דפוס: האם התעבורה רציפה (כמו בסטרימינג 🎥) או שהיא מגיעה ב"פרצים" (כמו בגלישה רגילה 🌐)? שלב ב' - צפייה ביציאה: במקביל, הצופה סורק את התעבורה שיוצאת מאלפי צמתי יציאה ברחבי העולם. הוא מחפש זרם תעבורה שיוצא מאחד הצמתים ופונה לאתר אינטרנט כלשהו, אבל עם פרופיל זהה לזה שהוא זיהה בכניסה. ההתאמה: אם הצופה מוצא זרם שיוצא מצומת יציאה בשעה 18:05:02 עם דפוס שנראה בדיוק כמו הזרם שנכנס מצומת הכניסה בשעה 18:05:01 (בהתחשב בהשהיה קלה), הוא יכול להסיק בסבירות סטטיסטית גבוהה מאוד שהוא מצא התאמה. הוא הצליח לקשור בין המקור (אתם) ליעד (האתר), וכל זה מבלי לפצח אפילו שכבת הצפנה אחת. 🎭 המסקנה: להיות בקהל, ולהתנהג כמוהו ההגנה של Tor מבוססת על הרעיון של "להיטמע בקהל". אבל אם אתם היחידים בקהל שלובשים חולצה כתומה וצועקים, ימצאו אתכם בקלות. אם הפעילות שלכם ב-Tor יוצרת "טביעת אצבע" ייחודית מאוד (למשל, שימוש בפרוטוקול נדיר או חיבור רציף 24/7), אתם מקלים על הצופה הגלובלי לסנן את הרעש ולמצוא אתכם. לכן, אנונימיות אמיתית דורשת לא רק שימוש בכלי הנכון, אלא גם התנהגות שמטשטשת אתכם בין שאר המשתמשים. סיכום והקדמה לפוסט הבא למדנו שההצפנה של Tor היא חזקה, אבל הרשת אינה חסינה לחלוטין. מול יריב עוצמתי בעל ראייה גלובלית, ניתוח תעבורה הוא איום ממשי. אז אם צפייה פסיבית היא אפשרית, מה קורה כשהיריב מחליט לעבור למתקפה אקטיבית? מה אם הוא לא רק צופה ברשת, אלא מנסה להפוך לחלק ממנה על ידי הקמת אלפי צמתים זדוניים משלו? בפוסט הבא נדבר על "התקפת סיביל" ועל מנגנון ההגנה החכם של Tor נגדה. מה דעתכם? שתפו בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

🧅💡 איך הבצל עובד? מבט טכני אל המכניקה של Tor 💡🧅 פוסט 2 מתוך 5 בפוסט הקודם הבנו את העיקרון המנחה של Tor: שבירת הקשר בין המקור ליעד. עכשיו נצלול עמוק יותר למנגנונים הטכניים שמאפשרים זאת. לא רק האנלוגיה, אלא הפרוטוקול עצמו. שלב 0: הכרת הרשת - Directory Authorities ו-Consensus לפני שהדפדפן שלכם (Tor Browser) אפילו חושב על בניית מסלול, הוא צריך לדעת אילו צמתים (relays) קיימים ופעילים ברשת. איך הוא עושה את זה? רשויות המדריך (Directory Authorities): יש קבוצה קטנה (כ-10) של שרתים אמינים ומוכרים, שהכתובות שלהם צרובות (hardcoded) בקוד המקור של Tor. תפקידם הוא לסרוק את הרשת באופן קבוע ולוודא אילו צמתים פעילים, מהירים ויציבים. הקונצנזוס (Consensus): בערך כל שעה, רשויות המדריך "מצביעות" ומגיעות להסכמה על רשימה עדכנית של כל הצמתים המוכרים ברשת. המסמך הזה, שנקרא Consensus, מכיל את כתובות ה-IP, המפתחות הציבוריים, רוחב הפס והגדרות המדיניות (למשל, האם הצומת הוא צומת יציאה) של אלפי הצמתים הפעילים. הלקוח שלכם מוריד את מסמך הקונצנזוס הזה כדי שיהיה לו "תפריט" של צמתים לבחור מהם. שלב 1: בניית המעגל (Circuit) והצפנה אחרי שהלקוח יודע אילו צמתים קיימים, הוא בונה "מעגל" (Tor Circuit) – מסלול אקראי דרך שלושה מהם: Entry Guard, Middle Relay, ו-Exit Relay. בניית המעגל וההצפנה הן לב ליבה של Tor. זה עובד באמצעות הצפנה היברידית: יצירת קשר עם הצומת הראשון (Entry Guard): הלקוח משתמש בהצפנה א-סימטרית. הוא משיג את המפתח הציבורי של ה-Entry Guard (מתוך הקונצנזוס) ומצפין באמצעותו בקשה ליצירת מפתח סימטרי זמני (לרוב AES). רק ה-Entry Guard, עם המפתח הפרטי שלו, יכול לפענח את הבקשה. מרגע זה, כל התקשורת בין הלקוח ל-Entry Guard מוצפנת באמצעות המפתח הסימטרי המהיר שהם יצרו. הרחבת המעגל (Extending the circuit): עכשיו, התהליך חוזר על עצמו, אבל דרך "מנהרה". הלקוח שולח בקשה מוצפנת דרך ה-Entry Guard אל ה-Middle Relay, כדי ליצור מפתח סימטרי שני, שונה, שמוכר רק ללקוח ול-Middle Relay. ה-Entry Guard רק מעביר את המידע המוצפן הלאה; אין לו מושג שהוא מסייע ביצירת קשר חדש. השלמת המעגל: התהליך קורה פעם שלישית, כאשר הלקוח שולח בקשה דרך ה-Entry Guard וה-Middle Relay אל ה-Exit Relay, כדי ליצור מפתח סימטרי שלישי. בסוף התהליך, ללקוח יש שלושה מפתחות סימטריים נפרדים – אחד לכל צומת במעגל. שלב 2: עטיפת הבצל - Layered Encryption כשהלקוח רוצה לשלוח מידע (למשל, בקשת GET לאתר כלשהו), הוא לא שולח אותו "כמו שהוא". הוא מצפין אותו בשלוש שכבות, מהפנים החוצה: המידע מוצפן עם המפתח של צומת היציאה. התוצאה המוצפנת הזו מוצפנת שוב, הפעם עם המפתח של הצומת האמצעי. התוצאה המוצפנת הכפולה מוצפנת פעם שלישית ואחרונה, עם המפתח של צומת הכניסה. כשהחבילה הזו נשלחת, כל צומת "מקלף" שכבה אחת בלבד: ה-Entry Guard משתמש במפתח שלו, מפענח שכבה אחת, ומגלה את הכתובת של ה-Middle Relay. הוא שולח את יתרת החבילה לשם. ה-Middle Relay משתמש במפתח שלו, מפענח את השכבה הבאה, ומגלה את הכתובת של ה-Exit Relay. הוא שולח את מה שנשאר אליו. ה-Exit Relay משתמש במפתח שלו, מפענח את השכבה האחרונה, וחושף את המידע המקורי (בקשת ה-GET) ואת כתובת היעד הסופית. הוא שולח את הבקשה לאינטרנט הפתוח. שלב 3: דיבור ב"תאים" - Tor Cells כדי להוסיף עוד שכבת הגנה מפני ניתוח תעבורה, Tor לא שולח חבילות מידע בגדלים משתנים. הפרוטוקול מפרק את כל המידע – גם פקודות לבניית מעגלים וגם מידע גלישה – ליחידות בגודל קבוע של 512 בייט, הנקראות "תאים" (Cells). זה מקשה על צופה חיצוני להבחין בין סוגי תעבורה שונים (למשל, הודעת צ'אט קצרה לעומת טעינת תמונה) רק על סמך גודל החבילות. סיכום הבנו שהמכניקה של Tor נשענת על שלושה עמודי תווך טכניים: רשויות מדריך המספקות רשימה אמינה של צמתים, הצפנה היברידית ליצירת מעגלים מאובטחים עם שכבות הצפנה, ושימוש בתאים בגודל קבוע של תעבורה. המערכת הזו מתוחכמת מאוד, אבל מה יקרה אם יריב בעל יכולות אדירות, כמו סוכנות ביון ממשלתית, יוכל לנטר חלקים נרחבים מתעבורת האינטרנט העולמית? האם הוא יוכל למצוא "טביעות אצבע" בתעבורה ולהתאים בין מי שנכנס לרשת Tor לבין מי שיוצא ממנה, גם בלי לפרוץ את ההצפנה? על כך נדבר בפוסט הבא. שאלות, הערות, בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

🧅🛡️ מהי אנונימיות, בעצם? ההבטחה האמיתית של רשת Tor 🛡️🧅 פוסט 1 מתוך 5 בסדרה על Tor כולנו שמענו את השם "Tor" (קיצור של The Onion Router), ולרוב הוא נקשר למושגים כמו "דארק ווב", האקרים או פעילות חשאית 🤫. אבל האם זה כל הסיפור? התשובה היא ממש לא. היום נתחיל לפרק את המיתוסים ונבין מה המטרה האמיתית של רשת Tor, והיא הרבה יותר עמוקה ומתוחכמת מאשר "פשוט להיות אנונימי". 🤔 הבעיה: האינטרנט לא שוכח (והוא גם אוהב לרכל) כשאנחנו גולשים באינטרנט רגיל, אנחנו משאירים עקבות דיגיטליות בכל מקום. חשבו על שני "צופים" עיקריים שתמיד מסתכלים על התעבורה שלנו: ספק האינטרנט שלכם (ISP) 🏢: לספק שלכם (בזק, הוט, פרטנר וכו') יש תמונה כמעט מלאה של מי אתם. הוא יודע את השם שלכם, הכתובת, ומספק לכם את כתובת ה-IP הציבורית שלכם. הוא רואה שאתם (מכתובת IP ספציפית) יוצרים קשר עם שרת מסוים (כתובת IP של גוגל, פייסבוק, או כל אתר אחר). גם אם התוכן מוצפן (HTTPS), הספק עדיין יודע בדיוק לאילו אתרים אתם מתחברים ומתי. האתר שאליו אתם גולשים 💻: כשהגעתם לאתר היעד, הוא לא יודע מי אתם בשם (בדרך כלל), אבל הוא רואה בבירור את כתובת ה-IP הציבורית שלכם. הוא יודע מאיפה הגעתם ומה אתם עושים באתר שלו. שימו לב לדפוס: צד אחד יודע מי אתם, והצד השני יודע לאן הגעתם. אם שני הצדדים האלה ישתפו פעולה (או ייאלצו לשתף פעולה על ידי גורם ממשלתי, למשל), נוצרת תמונה מלאה של הפעילות שלכם. 💡 המטרה הגדולה של Tor: שבירת הקשר הקריטי כאן נכנסת המערכת של Tor. המטרה המרכזית של הרשת היא לא רק להסתיר אתכם, אלא לבצע פעולה אחת, קריטית וחכמה: לשבור את הקשר בין מי שאתם (כתובת ה-IP שלכם) לבין מה שאתם עושים (האתר שאליו אתם גולשים). 🔗➡️❌ העיקרון פשוט: Tor רוצה ליצור מצב שבו: ספק האינטרנט שלכם יראה שאתם מתחברים לרשת Tor, אבל לא יהיה לו מושג לאן אתם ממשיכים משם. אתר היעד יראה שמגיעה אליו תעבורה מרשת Tor, אבל לא יהיה לו מושג מאיפה בעולם (או מאיזו כתובת IP) היא הגיעה במקור. במילים אחרות, אף אחד מהצדדים לא מחזיק בתמונה המלאה. הם לא יכולים לקשור את הזהות שלכם לפעילות שלכם. זוהי הליבה של האנונימיות ש-Tor מספק. 🧅 טיזר לפוסט הבא: איך המבנה דמוי הבצל עושה את הקסם? אז איך המערכת המתוחכמת הזו מצליחה לפרק את המידע וליצור את ההפרדה החיונית הזו? 🤔 התשובה טמונה בשם שלה - "נתב הבצל". התעבורה שלכם לא נשלחת ישירות ליעד, אלא "מתקלפת" דרך שכבות של הצפנה ועוברת במסלול עקלקל דרך רשת של מחשבים מתנדבים ברחבי העולם. בפוסט הבא נצלול לעומק המכניקה: נבין איך עובדים שלושת הצמתים (כניסה, אמצעי ויציאה), מה כל אחד מהם יודע (ומה לא), ואיך שכבות ההצפנה שומרות על הסוד שלכם בכל שלב בדרך. 🛡️ מקווה שההקדמה הזו הבהירה את המטרה האמיתית של Tor! זהו כלי עוצמתי להגנה על פרטיות, אבל הוא לא מושלם כפי שנראה בפוסטים הבאים בסדרה. שאלות? הערות? שתפו אותי בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING