UFW-ის აპლიკაციის პროფილი არ არის? ის პორტებს აღწერს და არა სერვისებს
UFW-ის აპლიკაციის პროფილი პორტებისა და პროტოკოლების დასახელებული სიაა და არა სერვისი. წაიკითხეთ app info, შეადარეთ რეალურ მსმენელს და შეინახეთ დაბრუნების გზა გადატვირთვამდე.
UFW ამბობს, რომ OpenSSH-ის შესაბამის პროფილს ვერ პოულობს, და მიზეზის ძებნა პირდაპირ SSH სერვერთან მიდის. ეს არასწორი მიმართულებაა: შეტყობინება დასახელებულ firewall-ის განსაზღვრებას ეხება და არაფერს ამბობს იმაზე, არის თუ არა sshd დაყენებული, მუშაობს თუ უსმენს. UFW-ის აპლიკაციის პროფილი პორტებისა და პროტოკოლების სიაა ეტიკეტით. განსაზღვრების წაკითხვა ერთ ბრძანებას მოითხოვს და ჩვეულებრივ კვლევას ამთავრებს.
ნაბიჯი 1: ჩამოთვალეთ სახელები, რომლებიც UFW-მა ნამდვილად იცის
ჰკითხეთ firewall-ს, რა სახელები აქვს, სანამ ერთ-ერთის დაშვებას სთხოვთ. სია ამ მანქანაზე დაყენებული პროფილებიდან მოდის, ამიტომ დაკარგული სახელი ამ სისტემის შესახებ ფაქტია და არა იმ პროგრამული უზრუნველყოფისა, რომლის დაცვასაც ცდილობდით. თუ სახელი არსებობს, შეცდომა ბეჭდვითი შეცდომიდან ან თქვენი shell-ის ისტორიაში არსებული ძველი ფსევდონიმიდან მოვიდა.
ufw app list
ufw app info OpenSSH
სია ნაგულისხმევ ინსტალაციაზე მოკლეა და სახელები პაკეტების სახელები არ არის. OpenSSH-ის სახელის პროფილი შეიძლება არ იყოს, სანამ openssh-server პაკეტი დაყენებულია, და პირიქითაც შესაძლებელია. გამოიყენეთ ზუსტად ის სახელი, რომელსაც სია ბეჭდავს; მსგავსი წერილობის VPN პროფილის სახელი ან სამუშაო მაგიდის გამშვები UFW-ის აპლიკაციის პროფილი არ არის. თუ სასურველი სახელი არ არის, ეს არის დასკვნა და შემდეგი ნაბიჯია იმის ნახვა, რამ უნდა უზრუნველყოს ის.
ნაბიჯი 2: წაიკითხეთ განსაზღვრება და არა ეტიკეტი
პროფილი /etc/ufw/applications.d-ის ქვეშ არსებული INI სტილის ფაილია, სახელით, სათაურით, აღწერით და პორტების ველით. პორტების ველს შეუძლია რამდენიმე პორტისა და ტრანსპორტის ჩამოთვლა, ამიტომ ეტიკეტი განსაზღვრებაზე ნაკლებს გეუბნებათ. UFW-ის სახელმძღვანელო ამ ველებსა და აპლიკაციების განახლების ოპერაციას აღწერს. წაიკითხეთ ფაილი და ნუ ჩათვლით, რომ სახელი ერთ ნაცნობ პორტს ნიშნავს.
cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH
22/tcp-ის შემცველი განსაზღვრება TCP 22 პორტს აღწერს და სხვა არაფერს. ის არ ამტკიცებს, რომ ამ მანქანის დემონი იქ უსმენს, და არ ფარავს მეორე პორტს, რომელიც მოგვიანებით დაამატეთ. თუ დემონი სხვაგან მუშაობს, პროფილი არასწორი ნებართვაა, მიუხედავად იმისა, რომ მისი სახელი პროდუქტს ემთხვევა. შეადარეთ მსმენელი განსაზღვრებას, სანამ რომელიმეს დაუშვებთ.
ss -ltnp 'sport = :22'
შეჩერდით, თუ განსაზღვრება და მსმენელი არ ემთხვევა. პროფილის დაშვება, რომელიც პორტს ასახელებს, სადაც არავინ უსმენს, ქმნის წესს, რომელიც პროგრესს ჰგავს და არაფერს იცავს.
ნაბიჯი 3: გამოყავით პროფილი მომუშავე სერვისისგან
დასახელებული პროფილის დაშვება სერვისს არ აყენებს, არ რთავს და არ აკონფიგურირებს, და მომუშავე სერვისს მისაწვდომობისთვის შეფუთული პროფილი არ სჭირდება. ეს ცალკეული გადაწყვეტილებებია, რომლებსაც სხვადასხვა ხელსაწყო ფლობს: პაკეტების მენეჯერი, სერვისების მენეჯერი და firewall. მათ ერთად მიჩნევა იმ გზაა, რომლითაც ადამიანები არასასურველ სერვერს აყენებენ, რათა სიმბოლური სახელი გამოჩნდეს.
VPN სერვერისთვის გამოყოფა გრძელდება გარე მსმენელის დაშვების შემდეგ. დაშიფრული ტრანსპორტის პორტის ნებართვა kernel-ის გადაცემას არ რთავს, NAT წესს არ ამატებს და გვირაბის მომხმარებლებს LAN-ზე წვდომას არ აძლევს. თითოეული მათგანი ცალკე პოლიტიკაა საკუთარი განხილვით. VPN პროდუქტის სახელზე დარქმეული პროფილი მხოლოდ იმ პორტებს აღწერს, რომლებსაც ჩამოთვლის, და სერვერის კონფიგურაციის დარჩენილი ნაწილი კვლავ თქვენ უნდა დაწეროთ.
თუ პროფილი არ არის და ერთი გჭირდებათ, განხილული მკაფიო პორტის წესი ან applications.d-ის ქვეშ არსებული ლოკალური პროფილი ორივე ლეგიტიმურია. არასასურველი პაკეტის დაყენება ლეგიტიმური არ არის.
ნაბიჯი 4: შეინახეთ დაბრუნების გზა firewall-ის გადატვირთვამდე
ნებისმიერი წესის ცვლილებამდე დაადასტურეთ, რომ მანქანაში შესვლის მეორე გზა გაქვთ: კონსოლი, ზოლის გარეთ არსებული მისამართი ან დაგეგმილი უკან დაბრუნება. შემდეგ წაიკითხეთ წესების ნაკრები და ნაგულისხმევი პოლიტიკა, რადგან SSH წესის გარეშე ნაგულისხმევი უარი კლასიკური გზაა, რომ ტესტირებისას თავი გარეთ ჩაკეტოთ. შეცვალეთ ერთი წესი ერთდროულად და წაიკითხეთ დადასტურება, რომელსაც UFW ბეჭდავს. შენახული წესი, აქტიური წესი და მისაწვდომი სერვისი სამი განსხვავებული დაკვირვებაა.
ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH
ცვლილების შემდეგ გამოსცადეთ დაშვებული კავშირი და ერთი გზა, რომელიც ჯერ კიდევ უნდა იყოს უარყოფილი. უარის ტესტი ისეთივე მნიშვნელოვანია, როგორც დაშვების, რადგან განზრახულზე ფართო წესი პირველ ტესტს გადის და მეორეში ვარდება. ჩაწერეთ პროფილის სახელი, მისი პორტები და მსმენელი, რომლის მიმართაც შეამოწმეთ.
ჩამონათვალი მთავრდება, როცა სახელი არსებობს ან განზრახ შეცვლილია, განსაზღვრება რეალურ მსმენელს ემთხვევა, სერვისი ცალკე იმართება და თქვენ გამოსცადეთ როგორც დაშვებული, ისე უარყოფილი გზა აღდგენის გზით ხელში. სიაში სახელის არსებობა არც ერთი მათგანი არ არის.