בחירת שיטות אימות SOCKS5 ב-Dante

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

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

מה הסדר של Dante שולט בו

Dante 1.4.x מכנה את ההגדרה ברמת הפרוטוקול socksmethod. התיעוד שלו אומר שהשיטות מפורטות לפי סדר עדיפות. עבור מדיניות שמתירה את שתי השיטות, הצהרה זו מעדיפה שם משתמש/סיסמה כאשר הלקוח מציע אותם:

socksmethod: username none

היפוך הרשימה מעדיף גישה ללא אימות כאשר שתי השיטות מוצעות:

socksmethod: none username

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

לאפשר none יש תוצאה מוחשית: לקוח שמציע רק ללא אימות עשוי להתקבל לפי הכללים החלים. הצבת username ראשונה אינה הופכת רשימה שמכילה none לדרישה שכולם יספקו סיסמה.

בחרו קודם את הדרישה

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

ל-Dante יש גם clientmethod, שעוסק בבדיקות המבוצעות כאשר לקוח ה-TCP מתחבר, לפני משא ומתן SOCKS. זו שכבה נפרדת מהשיטות המוחלפות בברכת SOCKS5. יש לקרוא קטעי תצורה שמשתמשים במילת מפתח ישנה יותר method מול המדריך של גרסת Dante המותקנת.

כששני לקוחות מתנהגים אחרת, השוו מה כל אחד מציע, מה Dante בוחר והאם משא ומתן המשנה של השיטה הנבחרת מצליח. לאחר מכן בדקו את תגובת היעד של SOCKS. הרצף הזה מזהה קריאה חוזרת של פרטי התחברות חסרים בלי לייחס כל כשל ל-FTP או לשנות את מדיניות האימות של השרת בעיניים עצומות.

לבסוף, אימות שם משתמש/סיסמה של SOCKS5 אינו מצפין את החלפת הסיסמה. השתמשו בהובלה או ברשת מוגנות כראוי כאשר פרטי ההתחברות האלה זקוקים לסודיות.