VPN მისამართზე მიბმული NFS ექსპორტი: რას არ ამტკიცებს ის
ექსპორტის წესი ამოწმებს, საიდან მოვიდა პაკეტი; AUTH_SYS აცხადებს ლოკალურ UID-ს, Kerberos კი ავთენტიფიცირებს მომხმარებელს. გადაწყვიტეთ, რომელი სჭირდება თქვენს ფაილურ სერვისს.
ჰოსტი დირექტორიას აექსპორტებს VPN მისამართზე, მონტაჟი წარმატებით სრულდება და დიზაინი ავთენტიფიცირებულად ფიქსირდება. სინამდვილეში ეს წესი მხოლოდ იმას ზღუდავს, თუ საიდან ჩანს პაკეტების მოსვლა. თუ ფაილური ოპერაციის გამძღოლი პიროვნება ნამდვილად ის არის, ვისაც თავს ასაღებს, ეს დამოკიდებულია NFS უსაფრთხოების რეჟიმზე, და ამ ტიპის ექსპორტების უმეტესობაში არავის შეცვლილა ის ნაგულისხმევიდან.
სამი იდენტობა შეიძლება გამოჩნდეს ერთ მოთხოვნაში
VPN პარტნიორი ატარებს რეგისტრირებულ იდენტობას, როგორიცაა კლიენტის სერტიფიკატი ან პარტნიორის გასაღები. შიდა IP პაკეტი ატარებს წყაროს მისამართს. ფაილური ოპერაცია ატარებს იმ მომხმარებლის სანდოობებს, რომლებსაც მისი NFS მექანიზმი აწვდის. დიზაინი, რომელიც მისამართს სამივეს შემცვლელად თვლის, ჩუმად ჩათვალა სწორედ ის ნაწილი, რომელიც უნდა შემოწმებულიყო.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
ამ სამი სტრიქონის ჩაწერა მთელი სავარჯიშოა. კამათის უმეტესი ნაწილი იმაზე, უსაფრთხოა თუ არა ექსპორტი, იშლება, როცა ცხადი ხდება, რომელ სტრიქონში ცხოვრობს რომელი კონტროლი.
მისამართის საკუთრება იმპლემენტაციის დეტალია
შესასვლელს შეუძლია მიღებულ პარტნიორს გამოუყოს გვირაბის მისამართი, ან მისთვის დაუშვას მარშრუტიზებული ქვექსელი. თუ იმპლემენტაცია შემდეგ უარყოფს პაკეტს, რომლის შიდა წყარო სხვა კლიენტს ეკუთვნის, ეს იმ იმპლემენტაციის თვისებაა და ღირს შემოწმება, ვიდრე ვარაუდი.
ტრადიციული Community OpenVPN მომხმარებლის სივრცის სერვერის კოდს შეუძლია, მაგალითად, უარყოს სხვა კლიენტთან დაკავშირებული წყარო, სანამ პაკეტი TUN მოწყობილობით გადაეცემა. ეს არის მისამართის საკუთრების შემოწმება რეალური ღირებულებით და ის ჯერ კიდევ არ არის NFS მომხმარებლის ავთენტიფიკაცია, რადგან არაფერს ამბობს იმაზე, რომელი ანგარიში ასრულებს ოპერაციას.
წყაროს თარგმნა ახშირებს ამასაც. NAT შესასვლელს შეუძლია ყველა კლიენტი ერთ მისამართად წარმოადგინოს, და მაშინ ექსპორტის წესი ვერ გაარჩევს მის უკან მდგარ ადამიანებს. წესის აშკარა სიზუსტე შემდეგ დიაგრამით შენახულ გამონაგონად იქცევა. თუ ექსპორტს მნიშვნელობა აქვს, შეინარჩუნეთ მისამართება ცხადი, ნაცვლად იმისა, რომ თარჯიმანმა გადაწყვიტოს, ვინ ვის ნაცვლად ითვლება.
წაიკითხეთ უსაფრთხოების რეჟიმი, სანამ ექსპორტს ენდობით
Red Hat-ის NFS სახელმძღვანელო გამოჰყოფს sec=sys-ს, რომელიც იყენებს ლოკალურ UNIX UID-ებს და GID-ებს AUTH_SYS-ის მეშვეობით, Kerberos რეჟიმებისგან. krb5 ამატებს მომხმარებლის ავთენტიფიკაციას, krb5i ამატებს მთლიანობის დაცვას, ხოლო krb5p ამატებს ტრაფიკის კონფიდენციალურობის დაცვას.
AUTH_SYS სანდოობები შეიცავს ველებს, როგორიცაა გამომძახებლის UID და ჯგუფის იდენტიფიკატორები, და RFC 5531 ღიად აფრთხილებს, რომ ეს რეჟიმი თავისთავად უსაფრთხოებას არ იძლევა და გარე დაცვაზეა დამოკიდებული. VPN-ის შიგნით მისი გაშვება ტრანსპორტს დაცვას აძლევს და პაკეტის შიგნით არსებულ მტკიცებაში არაფერს ცვლის.
exportfs -v
showmount -e nfs.example.internalწაიკითხეთ რეჟიმი ამ გამოსავალში, სანამ კლიენტების სიას წაიკითხავთ. შეზღუდულად მოჩვენებული ექსპორტი შეიძლება მხოლოდ მისამართით იყოს შეზღუდული, მაშინ როცა ყოველი გამომძახებელი კვლავ აცხადებს ნებისმიერ UID-ს.
აირჩიეთ მოდელი, შემდეგ შეინარჩუნეთ ნებართვები
აირჩიეთ ფაილური სერვისის ავთენტიფიკაციის ის მოდელი, რომელიც შეესაბამება თქვენ მიერ რეალურად მართულ კლიენტებს. Kerberos მოითხოვს იდენტობას და სერვისის განლაგებას თავის უკან, ამიტომ ერთი მონტაჟის პარამეტრის შეცვლა მიგრაცია არ არის და უბრალოდ ჩავარდება, სანამ Kerberos დომენი, პრინციპალები და keytab-ები არ არსებობს.
ორივე მოდელში შეინარჩუნეთ ექსპორტის ნებართვები და ფაილური სისტემის ავტორიზაცია, რომლებიც ზღუდავს, თუ რა შეუძლია ავთენტიფიცირებულ პრინციპალს. ავთენტიფიკაცია გეუბნებათ, ვინ იკითხავს; ავტორიზაცია წყვეტს, პასუხი უნდა იყოს თუ არა დიახ. ამ ორის ერთ პარამეტრად შერწყმა ის გზაა, რომლითაც მიგრაცია ბოლოს ძველ კონფიგურაციაზე მეტს ანიჭებს.
გამოიყენეთ მისამართის წესი მისი ნამდვილი დანიშნულებისთვის
სერვისის დამტკიცებულ გზასა და წყაროებზე შეზღუდვა კვლავ ღირს, მათ შორის ჰოსტის შემავალი პოლიტიკა, როცა VPN-ის ბოლო წერტილი და NFS სერვერი ერთ მანქანას იზიარებს. ტრაფიკის გადამისამართებელი წესები არ მართავს მოთხოვნებს, რომლებიც მიმართულია იმავე ჰოსტზე ლოკალურად მომუშავე სერვისზე. ეს ხარვეზი ხსნის გასაკვირად ბევრ ექსპორტს, რომლებიც პირადი უნდა ყოფილიყო. შეამოწმეთ ლოკალური შემავალი პოლიტიკა ცხადად, ნაცვლად იმისა, რომ ჩათვალოთ გვირაბის წესების მისი დაფარვა.
შეამოწმეთ, რომ სხვა ინტერფეისი ან წყაროს თარგმნის შესასვლელი ვერ შეასრულებს წესს მოულოდნელად, და მიიჩნიეთ ეს წარმომავლობის დადგენის მიზეზად, და არა მტკიცებად, რომ მისამართის გაყალბება მუშა მონტაჟს იძლევა გარანტიას.
გაატარეთ სამი მიღების შემთხვევა ერთის ნაცვლად. დაიწყეთ დამტკიცებული კლიენტით, რომელიც დამტკიცებულ მომხმარებლად მოქმედებს, შემდეგ გაიმეორეთ იმ პარტნიორიდან, რომელიც არასდროს დამტკიცებულა, შემდეგ სცადეთ ის, რაც დამტკიცებულ მომხმარებელს ჯერ არ აქვს ნებადართული. შემდეგ ჰკითხეთ, რა იცვლება, თუ ავტორიზებული კლიენტი კომპრომეტირდება, რადგან ტრანსპორტის ავთენტიფიკაცია არ ხდის ამ მანქანის ყველა პროცესს სანდოს. მოპარული სერტიფიკატი და ცნობისმოყვარე ლოკალური ანგარიში სხვადასხვა პრობლემაა სხვადასხვა კონტროლით.