HTTPS და VPN არ ამოწმებს იმ პაკეტს, რომელსაც აყენებთ

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

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

ორი კონტროლი, რომლებიც სხვადასხვა კითხვას პასუხობენ

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

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

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

რას ამოწმებს apt სინამდვილეში

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

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

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

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

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

რას ამოწმებს dnf5 ცალკე

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

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

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

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

რას ამატებს გვირაბი და რას არა

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

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

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

დიაგნოსტირეთ ის საზღვარი, რომელიც ვერ შესრულდა

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

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

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