בנוגע ל "חסימת פורטים" בספקיות האינטרנט השונות - עמוד 2 - רשתות ואינטרנט - HWzone פורומים
עבור לתוכן
  • צור חשבון

בנוגע ל "חסימת פורטים" בספקיות האינטרנט השונות


oneworld21

Recommended Posts

  • תגובות 31
  • נוצר
  • תגובה אחרונה

לגבי ה Telnet - כאשר אמרתי חסום התכוונתי

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

להלן הסיכונים בלתת לאחרים להתחבר לשרת שלך או למחשב שלך באמצעות telnet:

http://istpub.berkeley.edu:4201/bcc/Winter2002/sec.telnet.html

אפילו ב SP2 כברירת מחדל לא ניתן להתחבר אלייך ב telnet אלא אם כן הפעלת את ה service בעצמך

זה שהשרת הספציפי המדובר מאפשר להתחבר אליו כך - זה החלטה שלהם

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

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

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

אבל אנחנו סוטים מהעיקר ;)

קישור לתוכן
שתף באתרים אחרים

זה פשוט לא נכון מה שאתה אומר על טלנט

אני לא מדבר על השירות טלנט , לא על הפרוטוקול טלנט.

ע"י קליינט טלנט יש לך את האפשרות לפתוח session tcp/ip מול שרת כלשהוא על פורט מסויים (שוב, לא רק לשירות טלנט)

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

כשאני עושה טלנט לשרת X בפורט Y, אני בעצם יוזם פתיחת session מול אותו שרת X

מה שקורה אחרי פתיחת ה session כבר לא רלוונטי לצורך הדיון.

אין כזה דבר service של טלנט במובן שאני מדבר עליו

אתה אולי מדבר על telnet הדיפולטי, בפורט 23,

אני מדבר על פתיחת session בפורט שאני קובע

אז כן, אם ה"שירות" חסום במחשב או בנתב שלי, אז לא תוכל לעשות למחשב שלי טלנט בפורט 23

אבל אם יש לי במחשב שירות X (לאו דווקא טלנט) שמאזין על פורט Y, ולא חוסם אותו שום פירוול,

אז תוכל ע"י טלנט, לפתוח session מול המחשב שלי בפורט Y

כמו למשל שרת FTP שמאזין על פורט 21 ויושב במחשב שלי

תכול לפתוח session מולו על פורט 21 ע"י טלנט לצורך העניין

השרת שבמחשב שלי לא יידע איך אתה פותח את ה session (כלומר האם אתה עושה את זה ע"י תוכנת FTP , או ע"י טלנט)

מכיוון שאין לו דרך לזהות את זה ! session נפתח באותה דרך בכל המקרים

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

הוא יכול לחסום את זה עם הפיירוול שלו לפי כתובת IP, זה כן -

כלומר לתת לאנשים XYZ את האפשרות לפתוח session מול השירות

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

רק אחרי שה- session נפתח, יש הזדהות, החלפת פרוטוקולים וכו', ואז השרת יכול להחליט אם אתה לקוח לגיטימי או לא

(לפי קלט שהוא מצפה לו למשל, או מהירות תגובה אפילו)

ולחתוך את ה session ןלזרוק אותך החוצה.

קישור לתוכן
שתף באתרים אחרים

אם יש לך רשת נסה להתחבר למחשב ברשת שלך ב telnet לא משנה באיזה פורט ותראה שלא תצליח ואם תצליח כנס לרשימת ה services של windows בטל את ה service : Telnet ונסה שוב ותראה שהפעם לא תצליח (כברירתמחדל זה אמור להיות חסום)

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

לצורך העניין אני מניח שרוב השרתים מבוססי unix\linux אז בבקשה- שים לב כמה פשוט לנטרל את שירות ה telnet:

http://blog.webhosting.uk.com/2006/08/12/how-to-disable-telnet-access-on-server/

ברגע שעשיתה את זה לא משנה באיזה פורט - לא תוכל להתחבר ב telnet לשרת! לא ב 23 לא ב 25 או כל פורט אחר.

נסה להתחבר למחשב בבית ב telnet ולא משנה באיזה פורט! גם המחשב מאזין בפורט מסויים לא תצליח להתחבר.

שרתי דואר למשל לרוב מאפשרים להתחבר אליהם ב telnet

קישור לתוכן
שתף באתרים אחרים

בלינק שהבאת כתוב

ELNET server listens for incoming messages on port 23, and sends outgoing messages to port 23.

שוב אני אומר :

אני לא מדבר על ה service של טלנט

תקרא שוב את כל מה שכתבתי

telnet server port

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

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

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

שוב - אני לא מדבר על ה service טלנט.

ואני אפילו לא מדבר בהכרח על telnet שמייושם בדוס/WIN

אתה לא יכול לחסום "נסיון פתיחת session מול שרת בפורט מסויים" כי כל התקשרות לשרת בפורט הזה תחסם.

בשביל זה יש פירוולים (לאפשר גישה רק למורשים למשל) ובשביל זה היישומים שמאזינים לתקשורת בפורט הזה,

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

גם אם אתה מקבל במאית שניה connection refused - זה אומר שה- session נפתח (כלומר תקשורת עברה בפורט)

ואז נסגר במיידית.

קישור לתוכן
שתף באתרים אחרים

מישהו מכיר client טוב לא משנה איזה שמצפין תקשורת ברמה טובה? כי מה שקודמי אמר בנושא הגיוני - קרוב לוודאי שפקטה שיקח יותר מידי זמן לפענח אותה תשלח לדרכה (ואם לא אזי יום הדין למורידי הקבצים הגיע :) לפחות לבינתיים)...

קישור לתוכן
שתף באתרים אחרים

אם הבנתי נכון ,

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

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

יש בזה עילה לתביעה משפטית?

קישור לתוכן
שתף באתרים אחרים

אם הבנתי נכון ,

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

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

יש בזה עילה לתביעה משפטית?

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

קישור לתוכן
שתף באתרים אחרים

מישהו מכיר client טוב לא משנה איזה שמצפין תקשורת ברמה טובה? כי מה שקודמי אמר בנושא הגיוני - קרוב לוודאי שפקטה שיקח יותר מידי זמן לפענח אותה תשלח לדרכה (ואם לא אזי יום הדין למורידי הקבצים הגיע :) לפחות לבינתיים)...

אז לא קראת מה שאמרתי עד הסוף :)

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

אתה שולח פאקטה מוצפנת מהמחשב שלך לשרת X

שרת X ידוע כשרת שיתוף קבצים גדול שהספקית מונעת מעבר מידע אליו או מתעדפת אותו בעדיפות נמוכה.

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

לעניות דעתי זה מה שקרה בעצם ב 013 (וזאת רק דעה)

אם שמת לב, בדיונים המקוריים שהתחילו את כל הנושא הזה, שבעקבותיו באה הכתבה שלנו באתר וב YNET,

אנשים שניסו להצפין אמרו שזה לא עוזר במקרה הזה.

קישור לתוכן
שתף באתרים אחרים

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

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

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

קישור לתוכן
שתף באתרים אחרים

כלומר אין כבר מה לעשות הא?

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

יש למישהו הצעות??? משהו??? עצם???

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

קישור לתוכן
שתף באתרים אחרים

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.


×
  • צור חדש...