ProtectHome TOTP-ის თესლის წინააღმდეგ: რატომ ვერ ხერხდება VPN-ში შესვლა

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

სამი მარცხიდან რომელია ეს?

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

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

ერთეულის ფაილური სისტემის ხედი ჩვეულებრივი დამნაშავეა, როცა მარტო სერვისი მარცხდება.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

ვარიანტი A: საიდუმლო სახლიდან გარეთ გადაიტანეთ

როცა სერვისი /home-ს მალავს და გსურთ ეს დაცვა შეინარჩუნოთ, შეინახეთ საიდუმლო იქ, სადაც ის დაინახავს. მოდული იღებს secret= ბილიკს და user= ანგარიშს, რომელიც ფაილურ ოპერაციებს ასრულებს, რაც საშუალებას აძლევს ცენტრალურ საცავს მრავალი იდენტობა მოემსახუროს.

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

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

სანამ ენდობით, შეამოწმეთ სამი რამ: ანგარიში არსებობს, მოდულის სამუშაო პროცესი მასზე გადასვლას შეძლებს, და ფაილები მას ეკუთვნის შემზღუდავი რეჟიმებით. ნუ გამოიყენებთ ~-ს ან სახლის ცვლადის ბილიკს user=-თან ერთად და ნუ გამორთავთ მოდულის საკუთრების შემოწმებებს ბილიკის ასამუშავებლად. შეინარჩუნეთ პაროლის ეტაპი და დანარჩენი სტეკი უცვლელად.

ვარიანტი B: დატოვეთ ფაილი და გახსენით ბილიკი

თუ საიდუმლო მომხმარებლის სახლში უნდა დარჩეს, ერთეულს სჭირდება ხედი, რომელიც მოიცავს მხოლოდ ამ ერთ საქაღალდეს ჰოსტის ყველა სახლის გამოუჩენლად. drop-in-ს შეუძლია დაამატოს ვიწროდ შემოფარგლული bind mount სენდბოქსირებული სახლის ქვეშ.

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

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

ვარიანტი C: შეინარჩუნეთ სენდბოქსი და შეასწორეთ მდგომარეობის ჩანაწერები

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

ეს მარცხი შემდეგ მცდელობაზე ცუდ კოდს ჰგავს და არა ამაზე, ამიტომ საათის გადახრას ურევენ.

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

გადაამოწმეთ როგორც სერვისი, და არა როგორც თქვენ

ყოველი მნიშვნელოვანი შემოწმება უნდა გაეშვას ერთეულის სენდბოქსში ერთეულის იდენტობით.

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

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