RADIUS-ის OpenVPN-ში ჩართვა: პლაგინი თუ სკრიპტის კაუჭი?

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

მითი: პლაგინია მხარდაჭერილი გზა

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

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

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

რას აკავშირებდა პლაგინი

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

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

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

რას ენდობა სკრიპტის კაუჭი სინამდვილეში

კაუჭი კონფიგურირდება auth-user-pass-verify-ით და მიწოდების მექანიზმით: გარემოს ცვლადები ან დროებითი ფაილი. გარემოს ფორმაში OpenVPN მოითხოვს script-security 3-ს, დოკუმენტირებულ დონეს, რომელიც პაროლის სკრიპტებისთვის გამოვლენას იძლევა. ეს დონე ნაგულისხმევის განზრახ შესუსტებაა, და მას უნდა მოეპყრათ როგორც ნებართვას დართული დასაბუთებით.

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

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

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

გასვლის კოდები წყვეტენ ღიად ჩავარდებით თუ არა

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

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

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

რაზე ამბობთ უარს, როცა სერტიფიკატი ქრება

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

შეინარჩუნეთ საკონტროლო არხის დაცვა, რომ არაავთენტიფიცირებულმა წყვილმა ვერ შეძლოს ხელის ჩამორთმევის გამოკვლევა ან დატბორვა, და გამოიყენეთ username-as-common-name, როცა მომხმარებლისეული კონფიგურაცია საერთო სახელზეა დამოკიდებული. მართული კარიბჭეები ხშირად სხვაგვარად წყვეტენ ამას, ამთავრებენ სერტიფიკატის ავთენტიფიკაციას კარიბჭეზე, რომელიც EAP-TLS-ს საუბრობს RADIUS-თან, და ამ შემთხვევაში ამ სერვერის დირექტივებიდან არც ერთი არ ვრცელდება. დააკოპირეთ მოდელი, რომელსაც თქვენი პლატფორმა ადოკუმენტებს, და არა მეზობელი პროდუქტისა. მნიშვნელოვანი დირექტივები საკმარისად განსხვავდება, რომ მათი შერევა ქმნის კონფიგურაციას, რომელიც პარსდება და შემდეგ არავის ავთენტიფიცირებს.