נניח ויש לכם חבר, שנמצא מאחורי NAT (או Firewall), שצריך עזרה עם הלינוקס החדש שלו.
הוא ניובי אמיתי, ובטלפון כל דבר לוקח הרבה זמן, אז אידיאלית, היה אפשר להתחבר עם SSH, ולסדר את הכל. אבל למרבה הצער, אין לו אפשרות לפתוח פורט בNAT, כי הוא לא בשליטתו. (בדרך כלל קורה אם הוא נמצא בארגון).
אז מה עושים?
יש לSSH שני פרמטרים של יצירת מנהרה:
אחד מתאים למצב שבו יש גישה בSSH אל המחשב המרוחק, אבל יש שרותים שרצים על המחשב המרוחק שלא זמינים בגלל הNAT; במקרה הזה, יוצרים קידום מפורט במחשב המקומי, אל פורט במחשב המרוחק.
המקרה הזה לא מתאים כאן.
מה שכן מתאים זה אפשרות הקידום השניה:
נניח שבמחשב המקומי רץ שרות מסויים, אבל הוא לא זמין בגלל שהפורט חסום, ואתם רוצים לאפשר למישהו חיצוני להתחבר אל השרות המקומי.
זה בדיוק המצב שמתואר למעלה, והפתרון הוא כזה:
אומרים לSSH ליצור מנהרה במחשב המרוחק, מפורט מקומי שם אל הפורט של השרות המקומי.
מבלבל?
זה המצב לפני, שימו לב שהמחשב החיצוני לא יכול להתחבר לSSH המקומי:
(שתי התמונות לחיצות).
זה המצב אחרי שיוצרים מנהרה:
המחשב שמאחורי הNAT מתחבר למחשב המרוחק, המחשב המרוחק יוצר שרת מקומי, תוכנה במחשב המרוחק מתחברת לשרת המקומי והתקשורת שלה מקודמת על גבי החיבור הקיים אל תוכנה (במקרה הזה SSH Server) שרצה במחשב הראשון.
אז איך עושים את הקסם הזה?
אם לקצר, זו הפקודה שצריך להריץ הצד שיוזם את החיבור (זה שמאחורי הNAT):
ssh -R 1234:localhost:22 username@host
כאשר 1234 יהיה הפורט בו הSSH המרוחק יאזין, ו22 הוא הפורט המקומי שאליו תתבצע התקשורת דרך המנהרה.
תיעוד מלא של העסק נמצא כאן.
אני לא ארחיב יותר מדי הפעם לגבי מה המשמעות של זה מבחינת אבטחת רשת, אבל יש משמעויות רציניות.
נ.ב: לחבר שלום.
נ.ב2: יצרתי את התמונות בעזרת Inkscape, תוכנת קוד פתוח לגרפיקה ווקטורית.
המקרה הזה מוכר לי מאיפשהו
הראוטר שלי בשליטת הספקית … וברגע שאתה רוצה לעשות בו שימוש כגון פתיחת פרוטים הם אומרים שהשינויים על אחריותך והם מפסיקים את האחריות
לא הייתי מתגאה בגרפיקה, למרות שעשיתי באינקסקייפ דברים ממש יפים.
לא מתגאה, היא בסיסית לגמרי.
ובכל זאת, יחסית לכישורים הירודים שלי באינקסקיייפ ויחסית לזמן הקצר שהשקעתי בזה, יצא לי משהו סביר.
אני לא כל כך מבין איך זה קשור ל-NAT. בכל מקרה, זה לא אמור לעבוד אם יש לך אכיפה של שירותים ב-firewall. כלומר, אם הוא אוכף רק גישה החוצה ב-http, אתה לא אמור להיות בעל יכולת להעביר SSH, בלי קשר לפורט בו אתה עושה שימוש (נראה לי).
הבעיה עם NAT שהוא יוצר מעין firewall במובן הזה שהמכונות שמאחורי הNAT לא נגישות מבחוץ אם לא שינית את ההגדרות בNAT.
לגבי הטענה של הHTTP, היא לא נכונה.
אני יכול להעביר בHTTP מה שאני רוצה, כולל SSH.
אכיפת שרותים לא יכולה לעבוד ברמת הנתונים, אלא ברמת הכותרת (header), וגם אם כן, היא בטוח לא יכולה לעבוד ברמת הנתונים של HTTPS.
חיפוש קצר העלה את זה, בלי להתעמק, זה נראה כמו tcp-over-http.
דבר נוסף הוא שמעטות מאוד החברות שמאפשרות רק HTTP החוצה, בדרך כלל אין חסימה לנתונים היוצאים.
כדי להעביר SSH בתוך http (זה אפשרי) אתה צריך לעשות encapsulation ל-SSH כך שכל packet של ssh יהיה בתוך ה-payload של ה-http. אם זה מה שאתה עושה, אז באמת תוכל להעביר ssh על http. זה פשוט לא נשמע כמו מה שכתבת. הקישור שהבאת הוא (למיטב הבנתי) למשהו שמאפשר לך ליצור בשרת ה-web, אחרי שיצאת ב-http, קישור אחר. מעין proxy שעושה המרת פרוטוקולים. שזה בסדר.
ארגונים שלא מטפלים באבטחה מאפשרים לכל דבר לצאת החוצה. זו בדיוק הסיבה שסוסים טרויאנים עובדים. ארגון מאובטח יאפשר למשתמשים שלו לצאת רק בשירותים מסוימים החוצה, לרוב רק http. לגבי https אתה צודק עקרונית, אך גם זה ניתן לחסימה, או לגישה מאובטחת שניתן לסנן (מסורבל, אך אפשרי). NAT זה שירות שמשנה את כתובת ה-IP היוצאת מהארגון, הוא לא חוסם שירותים.
אני מקווה שעם כל המלים הלועזיות לא התבלבלבלתי.
כל מה שאמרת נכון.
הבעיה שמתוארת בפוסט היא לא "איך נצא מהארגון על אפו ועל חמתו של הIT), אלא "איך נתגבר על הNAT שמשנה את הכתובת של המכונה ונתחבר אליה בכל זאת".
שים לב שהזכרתי את הנושא של האבטחה בשורה וחצי בלבד.
לא על זה מדבר הפוסט.
לגבי אבטחה:
אני לא חושב שאפשר לתת חצי תקשורת.
או שאתה פוגע קשות במשתמשים (פתרונות נוסח – תתחברו רק למחשב הזה בפורט הזה) או שאתה חצי עבודה.
אי אפשר לאפשר תקשורת דו כיוונית לכל מכונה (ולא משנה אם זה בHTTP או בTCP או בUDP) אבל רק לדברים מסויימים.
אני פשוט חושב שבארגונים שמשקיעים באבטחה זה לא יעבוד. לכל הפחות, אם הם עושים בפועל את מה שהם מצהירים, זה לא אמור לעבוד.
מבחינת מה שמאפשרים למשתמשים – זה תמיד איזון ביחס לצרכי הארגון.
אתה צודק.
מה שתארתי לא יעבוד אם יש סינון ברמת השרותים, אבל כמו שאמרת בעצמך יש לזה פתרונות.
בשורה התחתונה, על משתמשים בתוך הארגון אתה חייב לסמוך ברמה זו או אחרת.
הפתרון האמיתי הוא לא טכנולוגי, אלא אנושי.
שאלה אחרת. איך הכי קל להתחיל עם לינוקס? אני מחפש משהו עם ממשק משתמש אנושי עד כמה שניתן.
אני התחלתי עם דביאן, אבל אולי הוא לא אידיאלי למתחילים.
לך על אובנטו, הוא מבוסס על דביאן, והוא יותר מלוטש איפה שחשוב לך.
תגובה לתגובות על לינוקס.
יצא לי בתקופות שונות בחיים להתקל ולעבוד ברמה זו או אחרת עם לינוקסים ויוניקסים שונים ומשונים.
אך אף פעם הם לא היו לי, איך לומר, user friendly.
במיוחד הייתי צריך להתאמץ בהתקנות וקינפוגים.
עד שפגשתי את ubunto (תודות לבעל הבלוג הכובד). הוא כל כך פשוט בהתקנתו ובקינפוג שזה מדהים.
בפשטות זה עובד כך:
– אתה מכניס CD שהורדת מאתר (אתה חייב לצרוב אותו) או קבלת בחינם בדואר (לא צריך לשלם דמי משלוח).
– מפעיל מחשב מחדש ו- UBUNTO עולה (Live CD).
– בשלב זה תוכל להתחבר כבר לאינטרנט דרך ה-WIZARD שלהם שיעבוד ברוב המקרים בהתחברות ADSL ועם קצת מאמץ בכבלים.
– תקנפג מה שאתה רוצה ואז פשוט תגיד לו שיתקין את המערכת איך שהיא נראית ברגע נתון. הוא ישאל אותך 3 שאילות בדיוק וסיימת.
שיר הלל זה אסיים בכך שעשיתי בדיקת ה"משתמש הממוצע". אחותי לא מוכנה להתקין וינדוס לעצמה וגם לא מוכנה לטפל בה, מה שאומר שצריך לבוא ולנקות או לתקין מע"ה מחדש. שיכנעתי אותה (בכלים לא מוסריים בעליל) להתקין UBUNTO. היא עשתה זאת, גלשה, השתמשה ב-ICQ וערכה מסמכי WORD שלה בלי עזרה שלי בכלל, פשוט לא הייתי זמין בכוונה.
ותשאולו אותי: "איך לעזאזל זה קשור לפוסט המקורי"? פשוט, UBUNTO תומן בתוכו סכנה שיהיו רבבות משתמשי לינוקס שיצטרכו פתרון המתואר בפוסט המקורי, כדי שיוכלו לתמוך בהם…
ויטלי, תודה על הביקורת על אובנטו.
עמרי,
NETCAT מאפשר לעשות אותו דבר, גם על WINDOWS.
חביב ביותר.
עומר – ברוב הארגונים המאובטחים אכן חוסמים יציאה בפיירוול של הכל חוץ משירותים מותרים. הבעיה שרוב הארגונים לא מוגנים 🙂
לגבי לינוקס- הכי פשוט להתחיל עם אחת הגרסאות החביבות למשתמש, אבל זו לא ההמלצה שלי.
אם אתה שואל אותי – תתחיל בלהגדיר למה אתה רוצה לעבור ללינוקס.
מה הסיבות?
לפי זה אפשר למצוא הפצה מתאימה..
גיא, אחלה, לא הכרתי את הכלי הזה.
גיא מוסר לך ד"ש
^ מפה http://www.hacking.org.il/1104
חסוי, תודה.
ואגב:
האקרים אמיתיים לא מריצים חלונות 😉