როგორ აქცევს OpenConnect შესვლის ქუქის გვირაბად?

OpenConnect ორ ცალკეულ გაცვლას ერთი ხანმოკლე მნიშვნელობით აკავშირებს: ვებ შესვლას და VPN გვირაბს. პირველი გაცვლა ჩვეულებრივი HTTPS-ია: რწმუნებები, SAML-ის მოგზაურობა ან ტოკენი კარიბჭესთან მიდის და პასუხს ავთენტიფიკაციის ქუქი მოაქვს. მეორე გაცვლა იმავე კარიბჭეს წარუდგენს ამ ქუქის, როგორც მტკიცებას, რომ ვებ ეტაპი უკვე მოხდა, და მხოლოდ ამის შემდეგ ადის გვირაბი.

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

რას ცვლიან კლიენტი და კარიბჭე რიგრიგობით

ავთენტიფიკაციის ეტაპი ჩვეულებრივ დაცულ ვებგვერდს ჰგავს. OpenConnect აგზავნის მომხმარებლის რწმუნებებს ან მიჰყვება კარიბჭის გადამისამართებას იდენტობის მომწოდებელთან, და კარიბჭე პასუხობს დოკუმენტით, რომელშიც ავთენტიფიკაციის ქუქია ჩაშენებული. AnyConnect პროტოკოლში ეს მნიშვნელობა ქუქის თავსართში მიდის მომდევნო მოთხოვნებზე, ჩვეულებრივ webvpn-ის მსგავსი სახელით, და სახელმძღვანელო მას სესიის წინ წამყვან რწმუნებად თვლის.

მეორე ეტაპი CONNECT მოთხოვნაა კარიბჭის VPN ბოლო წერტილთან ამ ქუქის მიმაგრებით. კარიბჭე ამოწმებს მას, ანიჭებს მისამართს, და კლიენტი იწყებს CSTP-ს TLS-ზე, ხოლო DTLS არასავალდებულო უფრო სწრაფი მონაცემთა გზაა, როცა სესია უკვე არსებობს. მხოლოდ ამ მომენტში მყარდება გვირაბის პარამეტრები, მარშრუტები, DNS პარამეტრები და სესიის ტრაფიკის გასაღებები. ქუქიმ კლიენტი კარიდან გაატარა; მან არაფერი დაშიფრა.

ეს თანმიმდევრობა ხსნის, რატომ არსებობს openconnect --authenticate. გაუშვით და ის ასრულებს ვებ ეტაპს, ბეჭდავს shell ცვლადების პატარა ბლოკს, როგორიცაა COOKIE, HOST, CONNECT_URL და FINGERPRINT, და შემდეგ გადის გვირაბის აგებამდე. მერე გარსაცმი სკრიპტი ამ მნიშვნელობებით დაიწყებს ნამდვილ კავშირს, და სწორედ ეს გაყოფა სჭირდება თავისუფალ ან ორკონტეინერიან განთავსებას.

ქუქი სესიის მატარებელია, არა გასაღები

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

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

ნუ მოეპყრობით ქუქის, როგორც სხვა რწმუნებების საყოველთაო შემცვლელს. SAML მტკიცება, ბრაუზერის პაროლი და სხვა სერვისის მიერ გამოცემული ქუქი სხვადასხვა აუდიტორიის მქონე სხვადასხვა ობიექტია, და ერთის მეორის ველში ჩასმა ჩვეულებრივ კარიბჭესთან ფარდდება ან, რაც უარესია, წარმატდება არასწორი ნდობის საზღვრის წინააღმდეგ.

ქუქის გადაცემა ასლების დატოვების გარეშე

Linux-ზე ყველაზე უსაფრთხო მექანიკური გადაცემა სტანდარტული შესავალია. --cookie-on-stdin მნიშვნელობას stdin-იდან კითხულობს, ამიტომ ქუქი არასოდეს ჩნდება პროცესის არგუმენტების სიაში, სადაც ნებისმიერ ლოკალურ მომხმარებელს შეუძლია წაიკითხოს ის ps-ით. მილსადენი, რომელიც ერთ პროცესში ავთენტიფიცირებს და მეორეში კვებავს გვირაბს, მნიშვნელობას ინახავს მილში და არა ფაილში ან გარემოს ცვლადში.

არგუმენტები და გარემოს ცვლადები სხვადასხვა მიზეზით უფრო სუსტია. არგუმენტი პროცესების ცხრილში ჩანს კლიენტის მთელი სიცოცხლის განმავლობაში და ხშირად ხვდება shell-ის ისტორიაში. გარემოს ცვლადი მემკვიდრეობით გადადის შვილ პროცესებზე, და systemd ერთეული, რომელიც მას ერთეულის ფაილში აყენებს, საიდუმლოს წაკითხვად კონფიგურაციაში ინახავს. თუ ფაილი აუცილებელია, შეზღუდეთ ის სერვისის ანგარიშით და წაშალეთ სესიის დასრულებისას.

პრივილეგიების საზღვარიც განზრახ შეინახეთ. პროცესი, რომელიც იდენტობის მომწოდებელს ელაპარაკება და შესაძლოა ბრაუზერსაც ხსნის, უნდა მუშაობდეს როგორც ის მომხმარებელი, ვისაც ეკუთვნის ეს შესვლა. პროცესს, რომელიც მარშრუტებს, DNS-ს და გვირაბის მოწყობილობას აყენებს, შესაძლოა მეტი პრივილეგია დასჭირდეს. მთელი ბრაუზერის root-ად გაშვება იმისთვის, რომ მისი ქუქი root-ის საკუთრებაში არსებული გვირაბისთვის ხელმისაწვდომი იყოს, არასწორი გაცვლაა, და თანამედროვე OpenConnect-ის კონფიგურაციებს შეუძლიათ მნიშვნელობა ამ საზღვარს გადასცენ ცხადად.

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

შემოწმება და ვადის გასვლა მეორე ეტაპზე

მეორე ეტაპმა მაინც უნდა შეამოწმოს სერვერი. FINGERPRINT, რომელსაც --authenticate ბეჭდავს, სერტიფიკატის ჩამაგრებაა pin-sha256: ფორმით, და მისი --servercert-ით გვირაბის გამოძახებისთვის გადაცემა შემოწმებას ამაგრებს იმ კარიბჭესთან, რომლის წინააღმდეგაც ავთენტიფიცირდით. სერტიფიკატის შემოწმების გამორთვა სკრიპტის გასამარტივებლად აშორებს ერთადერთ მტკიცებას, რომ ქუქი განკუთვნილ ჰოსტს გადაეცემა.

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

ამის ავტომატიზებამდე შეამოწმეთ ოთხი რამ: გვირაბი მუშაობს სწორი ანგარიშით, ქუქი stdin-ით მოდის, სერტიფიკატის ანაბეჭდი ჩამაგრებულია და სესია იყრება, როცა გვირაბი იხურება. თუ რომელიმე მათგანი აკლია, ავტომატიზაციამ გააფართოვა ნდობა ქუქის მიმართ და არა ხელითი დინება გაამეორა.