Dante-ში მომხმარებლის სახელით ავთენტიფიკაციის დამატება

Dante 1.4.4-ის SOCKS პოლიტიკა მხოლოდ წყაროთი დაშვებიდან ანგარიშის აშკარა შემოწმებაზე გადაიყვანეთ და წყაროსა და დანიშნულების შეზღუდვები შეინარჩუნეთ.

Dante 1.4.4-ში კლიენტის წესები კავშირს SOCKS შეთანხმებამდე უშვებს, ხოლო SOCKS წესები წყვეტს, რომელ ავთენტიფიცირებულ მოთხოვნებს შეუძლია გაგრძელება. ნებადართული წყაროდან კავშირს მეორე ეტაპზე მაინც შეიძლება მომხმარებლის სახელი დასჭირდეს.

ოპერაციული სისტემის მომხმარებლის სახელით ავთენტიფიკაციისას მეთოდთან ერთად სერვისის იდენტობებიც შეამოწმეთ. ანგარიშების ბაზის წაკითხვას შეიძლება პრივილეგირებული იდენტობა დასჭირდეს:

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

გამოიყენეთ Dante-სთვის დაყენებული რეალური, დაბალი უფლებების მქონე სერვისის ანგარიში. შექმენით ან აირჩიეთ მომხმარებლის სახელის backend-თან თავსებადი უფლებამოსილი კლიენტის ანგარიში; სერვისის იდენტობა და კლიენტის შესვლა სხვადასხვა როლს ასრულებს.

შეინარჩუნეთ მოთხოვნის საზღვრები

არსებული ვიწრო კლიენტის წესის შემდეგ ნებადართულ 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 სესია პროქსისთან ამ ადრინდელ გაცვლას არ იცავს. გამოიყენეთ კლიენტიდან სერვერამდე სათანადოდ დაცული გზა.

კონფიგურაციის წარმატებული შემოწმება ადასტურებს სინტაქსსა და იდენტობებს და არა ანგარიშების ბაზას ან ქსელურ გზას. სერვერის ჟურნალებში მოძებნეთ ეტაპი, რომელმაც რეალური ცდა უარყო.

დაკავშირებული სტატიები