הוספת אימות בשם משתמש ל-Dante

ב-Dante 1.4.4, כללי הלקוח מקבלים את החיבור לפני המשא ומתן של SOCKS, ואילו כללי SOCKS קובעים אילו בקשות מאומתות רשאיות להמשיך. גם חיבור ממקור מורשה עשוי לדרוש שם משתמש בשלב השני.

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

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

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

שמרו על גבולות הבקשות

לאחר כלל הלקוח המצומצם הקיים, דרשו את החשבון בנתיב SOCKS המותר:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

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

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

בדקו משא ומתן וגישה בנפרד

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

משא ומתן המשנה בשם משתמש וסיסמה המוגדר ב-RFC 1929 אינו מצפין את הסיסמה. הפעלת HTTPS מאוחרת יותר מול היעד אינה מגינה על חילופי המידע הקודמים עם הפרוקסי. השתמשו בנתיב מוגן כראוי בין הלקוח לשרת.

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