AnyConnect-ის არასანქციონირებული TLS ვერსია Linux-ზე: ჯერ განსაზღვრეთ გამოსწორების მასშტაბი

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

წაიკითხეთ შეტყობინება, სანამ პოლიტიკას შეეხებით

შეინახეთ ზუსტი სტრიქონი დიალოგიდან. ვერსიის ჩივილი პროტოკოლის დონეზე მიუთითებს, სერტიფიკატის ჩივილი ნდობაზე ან დასახელებაზე, ხოლო წარუმატებელი შესვლა სამაგიდო მონაცემებზე. გეითვეი, რომელიც გთავაზობთ TLS 1.0-ს 1024-ბიტიანი DHE ჯგუფით, AES-256-CBC-ით და SHA-1 ხელმოწერით, შეიძლება ჰქონდეს სრულიად ნამდვილი სერტიფიკატი და მაინც უარყოს თანამედროვე პოლიტიკამ თქვენი მონაცემების გაგზავნამდე.

შეამოწმეთ ბოლო წერტილი სისტემის OpenSSL-ით, რეალური ჰოსტის სახელისა და იმ პორტის გამოყენებით, რომელსაც კლიენტი იყენებს.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com-ის წარუმატებლობა, სანამ -tls1 -cipher DEFAULT@SECLEVEL=0 წარმატებულია, აჩვენებს, რომ ზღვარი ვერსია და გასაღების ზომა ერთად არის. თუ პირველი ბრძანება იტყობინება პატარა DH გასაღების შესახებ და არა პროტოკოლის გაფრთხილებას, ვერსია რიგშია და მხოლოდ ჯგუფს სჭირდება ყურადღება. არასოდეს ჩადოთ პირადი გასაღები ან პაროლი შემოწმებაში.

ვარიანტი 1: მთელი ჰოსტის შესუსტება კრიპტო პოლიტიკით

Fedora-ზე და RHEL 8 და 9-ზე update-crypto-policies --set LEGACY ამცირებს OpenSSL-ის სისტემურ პოლიტიკას, ხოლო update-crypto-policies --show ადასტურებს, რა არის აქტიური. ეს ჩვეულებრივ აღადგენს გვირაბს, მაგრამ პოლიტიკა იკითხება პროცესის გაშვებისას, ამიტომ ხელახლა ტესტამდე გადატვირთეთ კლიენტი და ყველა დამხმარე პროცესი, რომელიც მან შექმნა. ის ასევე ნებას რთავს ძველ პროტოკოლებსა და სუსტ ჯგუფებს მანქანის ყველა TLS კლიენტისთვის, მეზობელი ფანჯრის ბრაუზერიდან დაწყებული ბირთვის განახლების პაკეტის მენეჯერამდე.

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

Debian-სა და Ubuntu-ს ამისთვის ერთი გადამრთველი არ აქვთ. ეკვივალენტია /etc/ssl/openssl.cnf-ის რედაქტირება, რომელიც სისტემის ნაგულისხმევის განყოფილებაში დაბალ MinProtocol-ს და CipherString = DEFAULT@SECLEVEL=0-ს ადგენს. იგივე მასშტაბი, სხვა ფაილი, ოდნავ უფრო ადვილი თვალიდან დაკარგვა გამოშვების განახლებისას.

ვარიანტი 2: ერთი კონფიგურაციის ფაილი ერთი კლიენტისთვის

პროცესზე OpenSSL კონფიგურაცია ცვლილებას ერთი პროცესის ხის შიგნით ინახავს, მაგრამ მხოლოდ იმ შემთხვევაში, თუ ფაილი ისეა მიერთებული, როგორც ბიბლიოთეკა მოელის. ssl_conf განყოფილების დასახელება საკმარისი არ არის: OpenSSL კითხულობს ზედა დონის openssl_conf გასაღებს, მიჰყვება მას ინიციალიზაციის განყოფილებამდე და მხოლოდ შემდეგ აღწევს SSL-ის ნაგულისხმევს.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

მიუთითეთ OPENSSL_CONF ამ ფაილზე და გაუშვით VPN კლიენტი სახვევის გავლით, რომელიც მას ექსპორტს უკეთებს. ჰოსტზე ყველა სხვა რამ ინარჩუნებს ნაგულისხმევ პოლიტიკას და ეს არის ის თვისება, რომელიც მნიშვნელოვანია, როცა შესაბამისობის კითხვა მოდის. სანამ გეითვეის დაადანაშაულებთ, დაადასტურეთ, რომ ფაილი ნამდვილად ძალაშია: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 უნდა ჩამოთვალოს TLS 1.0 შიფრები, ხოლო ცარიელი შედეგი ნიშნავს, რომ ჯაჭვი გატეხილია და კლიენტმა ჩუმად შეინარჩუნა სისტემის ნაგულისხმევი.

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

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

ვარიანტი 3: ერთჯერადი VM ან კონტეინერი

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

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

რას გიტოვებთ შედარება

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

გამძლე გამოსწორება მოწყობილობას ეკუთვნის: TLS 1.2 ან უფრო ახალი, მინიმუმ 2048 ბიტიანი ჯგუფი, AEAD შიფრი და თანამედროვე ხელმოწერის სერტიფიკატი. სთხოვეთ ეს ცვლილება მოწყობილობის მფლობელს, შემდეგ დაადასტურეთ შეთანხმებული ვერსია და შიფრი კლიენტის ჟურნალში. ჩაწერეთ გამონაკლისი ჰოსტთან, გეითვეისთან, შეთანხმებულ პროტოკოლთან, დამამტკიცებელთან და ვადის გასვლის თარიღთან ერთად, რადგან სწორედ ეს ჩანაწერი უშლის ხელს დროებით გადაწყვეტას გახდეს ნაგულისხმევი.