UFW firewall-ის გზამკვლევი: default deny, პორტები და Docker

firewall ერთ სერვერზე ერთი გადაწყვეტილების განმეორებაა: არაფერი შემოდის, სანამ შენ არ დაუშვებ. UFW - Uncomplicated Firewall - ის ხელსაწყოა, რომელიც ამ გადაწყვეტილებას Debian-სა და Ubuntu-ზე იაფად ხდის, და მისი გამართვა ხუთი ბრძანებით ხდება. საინტერესო ყველაფერი მერე იწყება: წესი გეიმ სერვერის UDP წყვილისთვის, რას სჩადის limit SSH-ს, რატომ იგნორირდება შენი დამატებული წესი და ის, რომ Docker-ის პორტის გამოქვეყნება ამ პოსტის ყველა წესს პირდაპირ გვერდს უვლის. ეს უკანასკნელი იჭერს იმათაც, ვინც დანარჩენი ყველაფერი სწორად გააკეთა.

თუ მოკლე ვერსია გინდა და ახლა ახალ მანქანაზე ზიხარ: sudo ufw default deny incoming, sudo ufw default allow outgoing, sudo ufw allow OpenSSH, sudo ufw enable. მერე დანარჩენი წაიკითხე, სანამ სხვა რამეს დაამატებ, რადგან ამ ოთხი ბრძანების რიგითობა განსაზღვრავს, გექნება დაცული სერვერი თუ სერვერი, რომელშიც ვეღარ შეხვალ.

რა არის UFW და რა არ არის#

UFW firewall არ არის. firewall არის netfilter, Linux-ის ბირთვში, და ის აქ მთელი ამ ხნის განმავლობაში იყო ცარიელი პოლიტიკით. UFW არის command-line ინტერფეისი, რომელიც მასში წესებს წერს - iptables წესებად, რომლებსაც მიმდინარე Debian-სა და Ubuntu-ზე iptables-nft backend nftables-ად თარგმნის. როცა ufw allow 443/tcp-ს გაუშვებ, არაფერს იგონებ; ამატებ ერთ ხაზს ჯაჭვში სახელად ufw-user-input და მის გარშემო ყველაფერს UFW-ს უტოვებ.

ეს გარშემო არსებული სტრუქტურა არის ნამდვილი პროდუქტი. ხელით დაწერილ iptables წესების ნაკრებს უნდა ახსოვდეს loopback ტრაფიკის დაშვება, იმ კავშირების პაკეტების მიღება, რომლებიც შენ გახსენი, ICMP-ის გონივრულად დამუშავება და ყველაფრის თავიდან გაკეთება IPv6-ისთვის. UFW ამას აწვდის როგორც before.rules და after.rules, შენს წესებს შუაში დებს და ორივე მისამართების ოჯახს ერთმანეთთან შეთანხმებულს ინახავს. ფაილები /etc/ufw/-შია, და ის, რაც საბოლოოდ დაგაინტერესებს, არის /etc/ufw/before.rules, /etc/ufw/after.rules და /etc/default/ufw.

რა არ არის UFW:

• ის არ იცავს მოცულობითი შეტევებისგან. ნაკადი, რომელიც uplink-ს ავსებს, ბირთვის მიერ პაკეტების გადაგდებამდე უკვე გიჭამს გამტარუნარიანობას. ასეთი ფილტრაცია მანქანამდე, ზემოთ უნდა მოხდეს. DDoS შეტევები გეიმ სერვერებზე პირდაპირ ამბობს, რა შეიძლება და რა არა თითოეულ დონეზე.
• ის არ არის აპლიკაციის firewall. ის ადარებს მისამართებს, პორტებს და პროტოკოლებს. მას წარმოდგენა არ აქვს, 443 პორტზე მოთხოვნა არის ავტორიზაციის მცდელობა თუ იგივე მცდელობა ცხრა ათასჯერ გამეორებული - ეს fail2ban კითხულობს შენს ლოგებს და UFW-ს ჩანაცვლების კი არა, მის გვერდით მუშაობს.
• ის არ არის მიზეზი, რომ დაუცველი რამ გაუშვა. დახურული პორტი დაუპატჩავი სერვისის წინ დროს გიგებს და არა უსაფრთხოებას.
• ის არ ფილტრავს ტრაფიკს კონტეინერებს შორის, და არც აუცილებლად ფილტრავს მათში შემავალ ტრაფიკს. იხილე Docker-ის განყოფილება, რომელიც აქ ყველაზე გრძელია, და არა უმიზეზოდ.

პირველი ხუთი წუთი ახალ მანქანაზე#

Ubuntu-ს UFW დაყენებული და გამორთული მოყვება. Debian-ს სჭირდება apt install ufw. ქვემოთ მოცემული თანმიმდევრობა მნიშვნელოვანია: დააყენე ნაგულისხმევი პოლიტიკები, დაუშვი შენი დასაბრუნებელი გზა და მხოლოდ ამის შემდეგ ჩართე.

$ sudo apt update && sudo apt install -y ufw$ sudo ufw default deny incoming$ sudo ufw default allow outgoing$ sudo ufw allow OpenSSH$ sudo ufw enable

UFW გკითხავს, სანამ გაგწყვეტს - Command may disrupt existing ssh connections. Proceed with operation (y|n)? - და ეს კითხვა ბოლო გაფრთხილებაა. პარამეტრი გადატვირთვის შემდეგაც რჩება: ufw enable წერს ENABLED=yes-ს ფაილში /etc/ufw/ufw.conf და რთავს ufw systemd unit-ს, ამიტომ წესები ქსელზე ადრე ბრუნდება.

შეამოწმე, რა გაქვს:

$ sudo ufw status verboseStatus: activeLogging: on (low)Default: deny (incoming), allow (outgoing), disabled (routed)New profiles: skipTo                         Action      From--                         --          ----22/tcp (OpenSSH)           ALLOW IN    Anywhere22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

Default: ხაზი ის არის, რომელიც უნდა წაიკითხო. deny (incoming) მთელი აზრია; allow (outgoing) გონივრული ნაგულისხმევია სერვერისთვის, რომელსაც შენ აკონტროლებ, რადგან გამავალი ტრაფიკის დაკეტვა მანქანაზე, რომელსაც პაკეტების გადმოწერა, image-ების ჩამოტანა და API-ებთან საუბარი უწევს, ბრძანება კი არა, პროექტია. disabled (routed) ნიშნავს, რომ UFW გადამისამართებულ ტრაფიკს არ ფილტრავს, და სწორედ ეს არის ის ხვრელი, რომელშიც Docker მოგვიანებით გადის.

წესების წერა: ორივე სინტაქსი#

UFW-ს აქვს მოკლე ფორმა ჩვეულებრივი შემთხვევისთვის და გრძელი ფორმა დანარჩენისთვის. ისინი ერთი და იგივე სახის წესს ქმნიან.

# Short form: port, optional protocol, optional application profile$ sudo ufw allow 443/tcp$ sudo ufw allow 25565$ sudo ufw allow 'Nginx Full'# Long form: source, destination, port, protocol$ sudo ufw allow from 203.0.113.10 to any port 22 proto tcp$ sudo ufw allow from 10.0.0.0/8 to any port 5432 proto tcp$ sudo ufw deny from 198.51.100.0/24

რამდენიმე წერტილი, რომელიც help ტექსტიდან ცხადი არ არის:

• პროტოკოლის გამოტოვება ორივეს ხსნის. ufw allow 25565 ქმნის TCP წესსაც და UDP წესსაც. იყავი კონკრეტული, თუ ორივე არ გინდა; ზედმეტი ღია UDP პორტებით ხდება, რომ სერვერი სხვისი შეტევის ტრაფიკს ირეკლავს.
• ყოველი წესი იქმნება IPv4-ისთვისაც და IPv6-ისთვისაც, თუ მისამართის მითითებით კონკრეტულ ოჯახს არ დაასახელებ. თუ მანქანას საჯარო IPv6 მისამართი აქვს - შეამოწმე ip -6 addr-ით - მხოლოდ v4 წესი ღია კარს ნახევრად უკარგავს დაცვას.
• `deny` ჩუმად გადაყრის, `reject` პასუხობს. გადაგდებული პაკეტი პორტს ისე აჩვენებს, თითქოს გამორთულ მანქანას ეკუთვნის; უარყოფილი იღებს ICMP port-unreachable-ს ან TCP reset-ს, რაც უფრო სწრაფი და გულწრფელია შიდა სერვისებისთვის. ინტერნეტისკენ გამოიყენე deny, იქ კი, სადაც სწრაფი შეცდომა უფრო სასარგებლოა, ვიდრე ფარული, reject.
• კომენტარები მხარდაჭერილია და ბეჭდვად ღირს. sudo ufw allow 8443/tcp comment 'matrix bridge' ჩანს ufw status-ში და გიხსნის ექვსი თვის წინანდელი წესისგან, რომელიც ვერავინ ხსნის.

აპლიკაციის პროფილები მოდის /etc/ufw/applications.d-დან, და პაკეტები მათ იქ ინსტალაციისას აგდებენ. ufw app list აჩვენებს, რა არის ხელმისაწვდომი; ufw app info 'Nginx Full' ბეჭდავს სახელის უკან მდგომ პორტებს. ისინი მოხერხებულობაა და არა შესაძლებლობა - Nginx Full არის 80,443/tcp და მეტი არაფერი.

წესები იმისთვის, რასაც რეალურად გაუშვებ#

პორტის დიაპაზონი იყენებს ორწერტილს და უნდა დაასახელოს პროტოკოლი: ufw allow 27015:27020/udp მუშაობს, ufw allow 27015:27020 უარყოფილია. გრძელი ფორმა იმავეს წერს ასე: ufw allow proto udp from any to any port 27015:27020.

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

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

რიგითობა, წაშლა და limit წესი#

UFW წესებს რიგით ამოწმებს და პირველ დამთხვევაზე ჩერდება. აქედან მოდის "ჩემი წესი არაფერს აკეთებს" დაბნეულობის უმეტესობა. თუ 80 პორტზე საერთო allow დაამატე და შემდეგ ერთ მისამართზე 80 პორტზე deny, deny allow-ის ქვემოთაა და არასდროს აღწევს.

$ sudo ufw status numberedStatus: active     To                         Action      From     --                         --          ----[ 1] 22/tcp                     LIMIT IN    Anywhere[ 2] 80,443/tcp (Nginx Full)    ALLOW IN    Anywhere[ 3] 25565/tcp                  ALLOW IN    Anywhere$ sudo ufw insert 1 deny from 198.51.100.7$ sudo ufw delete 4$ sudo ufw delete allow 25565/tcp

insert N წესს კონკრეტულ პოზიციაზე სვამს, ასე ათავსებ ბლოკს allow-ის წინ. delete N ნომრით შლის - და ქვემოთ ყველაფერს თავიდან ანუმერებს, ამიტომ წაშალე ქვემოდან ზემოთ ან წაშლებს შორის ხელახლა გაუშვი status numbered. delete თავდაპირველი წესის ტექსტით ასევე მუშაობს და სკრიპტში უფრო უსაფრთხოა.

ufw limit საკუთარ აბზაცს იმსახურებს, რადგან ეს ხელსაწყოში ყველაზე სასარგებლო და ყველაზე ნაკლებად გაგებული რამ არის. ufw limit 22/tcp პორტს უშვებს, მაგრამ უარყოფს იმ წყაროს მისამართს, რომელმაც ბოლო ოცდაათ წამში ექვსი ან მეტი კავშირი გახსნა. ინტერნეტზე გამოსულ SSH პორტზე ეს პრაქტიკულად აქრობს პაროლების ავტომატური გამოცნობის მთელ ხმაურს, შენი რამის კონფიგურაციის გარეშე. ორი გაფრთხილება: ის კავშირებს ითვლის და არა წარუმატებელ ავტორიზაციებს, ამიტომ პარალელური scp ამოცანების ლეგიტიმურმა ტალღამ შეიძლება ის გამოიწვიოს, და UFW-ს ძველ გამოშვებებში ის მხოლოდ IPv4-ისთვისაა - სანამ ვივარაუდებ, რომ ორივე დაფარულია, ufw status-ში შეამოწმე LIMIT IN ჩანაწერი (v6) ხაზზე.

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

Docker-ის პრობლემა#

ეს ის ნაწილია, რომელიც ორჯერ უნდა წაიკითხო. Docker UFW-ს ვერიდება. თუ კონტეინერს -p 8080:80-ით გაუშვებ, 8080 პორტი ინტერნეტიდან ხელმისაწვდომია, მიუხედავად იმისა, რომ ufw status deny-ს ამბობს და მისთვის წესს არ აჩვენებს.

მიზეზი სტრუქტურულია და არა შეცდომა. UFW-ს წესები ცხოვრობს INPUT ჯაჭვში, რომელიც თავად ჰოსტისკენ მიმართულ პაკეტებს ამუშავებს. გამოქვეყნებული კონტეინერის პორტს PREROUTING-ში destination-NAT ეკეთება და შემდეგ FORWARD ჯაჭვს გაივლის კონტეინერის namespace-კენ მიმავალ გზაზე - INPUT-ს არასდროს ეხება. Docker თავის წესებს სწორედ ამის დასაშვებად აყენებს FORWARD-ში, და Docker-ის წესები UFW-ს სიტყვამდე მუშავდება. შენი default deny არასწორი არ არის; მას სხვა მოგზაურობაზე ეკითხებიან.

ოთხი გამოსავალი, იმ თანმიმდევრობით, რომლითაც უნდა განიხილო:

1. გამოაქვეყნე loopback-ზე. -p 127.0.0.1:8080:80 გამოქვეყნებულ პორტს loopback ინტერფეისს აბამს, ამიტომ მანქანის გარედან ვერაფერი მიაღწევს, ჰოსტზე გაშვებული reverse proxy კი მაინც შეძლებს. ეს სწორია Docker-ის ყველა ვერსიაზე, დამატებით ხელსაწყოს არ საჭიროებს და სწორი ნაგულისხმევია ყველაფრისთვის, რაც nginx reverse proxy-ს უკან დგას.
2. საერთოდ არ გამოაქვეყნო. ერთსა და იმავე user-defined ქსელში მყოფი კონტეინერები ერთმანეთს სერვისის სახელით აღწევენ კონტეინერის პორტზე. გამოქვეყნებული პორტი მხოლოდ წინა კარს სჭირდება - ეს ის ფორმაა, რომელსაც Docker Compose პატარა stack-ებისთვის აგებს.
3. გამოიყენე `DOCKER-USER` ჯაჭვი. Docker ამ ჯაჭვს სწორედ hook-ად აძლევს, და ის Docker-ის საკუთარ წესებამდე მუშავდება, ამიტომ ეს არის კონტეინერის ტრაფიკის საკუთარი ფილტრაციის მხარდაჭერილი ადგილი.
4. გამოიყენე `ufw-docker` - community სკრიპტი, რომელიც forward-ჯაჭვის დამუშავებას ამატებს, რომ ufw route allow კონტეინერებისთვის ისე იმუშაოს, როგორც ელი. ის მუშაობს, ფართოდ გამოიყენება და კიდევ ერთი მოძრავი ნაწილია, რომელიც უნდა გაიგო, სანამ მასზე დაეყრდნობი.

მინიმალური DOCKER-USER წესი, რომელიც გამოქვეყნებულ კონტეინერის პორტებს ერთი მისამართით ზღუდავს, ასე გამოიყურება:

$ sudo iptables -I DOCKER-USER -i eth0 ! -s 203.0.113.10 -j DROP$ sudo iptables -L DOCKER-USER -n --line-numbers

ორი შენიშვნა. iptables-ით ხელით დამატებული წესები გადატვირთვას არ გადაურჩება, თუ მათ არ შეინახავ - iptables-persistent Debian-სა და Ubuntu-ზე, ან პატარა systemd unit, როგორც აღწერილია systemd სერვისები შენი აპლიკაციებისთვის-ში. და Docker-ის ქცევა ამ მხარეს ბოლო მთავარ გამოშვებებში გამკაცრდა, განსაკუთრებით კონტეინერის მისამართებზე პირდაპირი წვდომის მხრივ, ამიტომ ზუსტი სიმპტომები შენს ვერსიაზეა დამოკიდებული. იმის თვალყურის დევნის ნაცვლად, რომელი გამოშვება რას აკეთებს, აიღე პირველი ჩვევა: გამოაქვეყნე 127.0.0.1-ზე, თუ პორტი მართლა საჯაროს არ ეკუთვნის. ეს ყველგან სწორია.

IPv6, forwarding და ლოგირება#

სამი გადამრთველი ცხოვრობს /etc/default/ufw-ში, და სამივე მნიშვნელოვანია რეალურ სერვერზე:

IPV6=yesDEFAULT_INPUT_POLICY="DROP"DEFAULT_OUTPUT_POLICY="ACCEPT"DEFAULT_FORWARD_POLICY="DROP"

IPV6=yes მიმდინარე გამოშვებებზე ნაგულისხმევია და ასეც უნდა დარჩეს. თუ შენს VDS-ს მარშრუტიზებადი IPv6 მისამართი აქვს, მხოლოდ IPv4 წესების ნაკრები მანქანის ნახევარს იცავს. sudo ip6tables -L ufw6-user-input -n-ით დარწმუნდი, რომ შენი წესები ორივე ოჯახში არსებობს, ან უბრალოდ წაიკითხე (v6) სტრიქონები ufw status-ში.

DEFAULT_FORWARD_POLICY მართავს მარშრუტიზებულ ტრაფიკს - კონტეინერებს, VPN-ებს, ყველაფერს, სადაც მანქანა დანიშნულების ადგილი კი არა, შუა რგოლია. ufw default deny routed მას ბრძანების ხაზიდან აყენებს, ხოლო ufw route allow proto tcp from any to 10.0.0.5 port 80 გამონაკლისებს ამატებს. ფაილის ხელით რედაქტირების შემდეგ გაუშვი sudo ufw reload.

ლოგირება ნაგულისხმევად გამორთულია იმ აზრით, რომ low ჩუმია. sudo ufw logging medium წერს დაბლოკილ პაკეტებს და ახალ კავშირებს /var/log/ufw.log-ში syslog-ის გავლით, რაც საკმარისია კითხვაზე "ჩემი წესია თუ არა ამის გამტოვებელი". ის ასევე საკმარისია პატარა დისკის შესავსებად დატვირთულ საჯარო მისამართზე, ამიტომ debug-ის დროს აწიე და დასრულებისას დააბრუნე - sudo ufw logging low. ლოგები, რომლებიც ღირს შენახვად ამ კომპრომისის ზოგად ვერსიას შეიცავს.

დამტკიცება, რომ მუშაობს#

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

$ sudo ss -lntupNetid State  Local Address:Port   Processtcp   LISTEN 0.0.0.0:22           sshdtcp   LISTEN 127.0.0.1:3000       nodeudp   UNCONN 0.0.0.0:2456         valheim_server.x86

ყველაფერი, რაც 0.0.0.0-ს ან [::]-ს აბია, ქსელისთვის ღიაა და firewall-ზეა დამოკიდებული. ყველაფერი 127.0.0.1-ზე გარედან მიუწვდომელია, firewall რასაც არ უნდა ამბობდეს. ეს ერთი ბრძანება ამ პოსტის ნებისმიერ სხვა ბრძანებაზე მეტ დავას წყვეტს.

მეორე, რას ფიქრობს firewall: sudo ufw status verbose, ზემოდან წაკითხული, იმის გახსენებით, რომ პირველი დამთხვევა იმარჯვებს. sudo ufw --dry-run allow 8080/tcp ბეჭდავს iptables ხაზებს, რომლებსაც წესი შექმნიდა, გამოყენების გარეშე, რაც გამოგადგება, როცა გინდა ნახო, ჯაჭვში სად მოხვდებოდა.

მესამე, და ერთადერთი, რომელიც ითვლება, სხვა ადგილიდან:

$ nmap -Pn -p 22,80,443,3000,8080 203.0.113.10$ nmap -Pn -sU -p 2456,2457 203.0.113.10$ nc -zv 203.0.113.10 25565

დაასკანირე სხვა მანქანიდან და არასდროს თავად სერვერიდან - loopback უგულებელყოფს წესებს, რომელთა შემოწმებასაც ცდილობ. თუ პორტი, რომელიც დახურული გეგონა, პასუხობს, უკან გაჰყევი: გამოქვეყნებულია Docker-ით, არის თუ არა წესი შენს deny-ზე ზემოთ, ღიაა მხოლოდ IPv6-ზე. ამის გაკეთება stack-ის ყოველი ცვლილების შემდეგ ხუთწამიანი ჩვევაა, რომელიც იჭერს ბაზას, რომელიც debug-ისას გამოაჩინე და დაგავიწყდა.

როცა რამე არასწორად მიდის#

UFW ჩავრთე და SSH დავკარგე. პროვაიდერის კონსოლით აიღე shell, შემდეგ sudo ufw allow 22/tcp (ან შენი პორტი) და sudo ufw reload. თუ კონსოლი არ გაქვს, გაქვს reinstall. ეს არის წარუმატებლობა, რომლის თავიდან ასაცილებლადაც ეს პოსტი არსებობს.

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

პორტი ღიაა, მაგრამ სერვისი მიუწვდომელია. firewall შენი პრობლემა არ არის. შეამოწმე ss -lntup პროცესისთვის, შეამოწმე, რომ ის 0.0.0.0-ზეა და არა 127.0.0.1-ზე, და შეამოწმე სერვისის ლოგი.

პორტი დახურულია, თუმცა დავუშვი. შეამოწმე პროტოკოლი - UDP თამაში TCP წესით კლასიკური შემთხვევაა. შეამოწმე IPv6. შეამოწმე, ხომ არ არის მანქანის წინ მეორე firewall პროვაიდერის დონეზე.

კონტეინერი ხელმისაწვდომია და მე არასდროს დამიშვია. Docker. იხილე ზემოთ.

გადატვირთვის შემდეგ წესები გაქრა. sudo systemctl is-enabled ufw უნდა ამბობდეს enabled. UFW-ს გარეთ ხელით დაწერილი iptables წესები თავისით არ რჩება.

`ufw reset`-მა ყველაფერი წაშალა. ეს არის მისი ქცევა: ის firewall-ს თიშავს და არსებულ წესების ფაილებს დროის ნიშნულიანი backup-ებით /etc/ufw/-ში გადააქვს. ძველი წესები დისკზე ისევ არის, თუ უკან წაკითხვა დაგჭირდება.

RE:NODE-ის VDS-ზე ყველაფერი ეს შენი გასაშვებია, რადგან გეგმა არის მანქანა სრული root წვდომით და არა მართული კონტეინერი - firewall, ბირთვი და ყოველი მოსმენადი პორტი შენს კონტროლშია და არავისი სხვისი. ეს არის გარიგება: მართულ თამაშის ან აპლიკაციის გეგმაზე კონფიგურირებადი firewall საერთოდ არ არის, რადგან ყველა გეგმას თავისი პორტების განაწილება მოყვება და პორტებს Network ჩანართზე ამატებ ან შლი. VDS-ზე მოქნილობას და პასუხისმგებლობას ერთად იღებ, და ეს პოსტი პასუხისმგებლობის ნაწილია. პირველი დღის დანარჩენი ნაწილი არის პირველი საათი ახალ VDS-ზე-ში.

FAQ#

უნდა შევცვალო SSH პორტი, რომ დავმალო?

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

UFW თავისთავად საკმარისია?

ერთი სერვერისთვის, რომელზეც რამდენიმე სერვისი მუშაობს, default-deny პოლიტიკა მოკლე allow სიით ამ დონეზე არსებული სარგებლის უმეტესობაა. ის პროგრამულ უზრუნველყოფას არ ალაგებს, ავტორიზაციის გამოცნობას rate limiting-ზე მეტად არ აჩერებს და არ დაგეხმარება ნაკადში, რომელიც არხს ავსებს. მიიჩნიე ის ოთხი-ხუთი რამიდან ერთ-ერთად და არა იმ ერთადერთად.

რატომ არის ჩემი Docker კონტეინერი ხელმისაწვდომი, როცა UFW deny-ს ამბობს?

იმიტომ, რომ გამოქვეყნებული კონტეინერის პორტები გადამისამართდება და არა ჰოსტს მიეწოდება, და Docker-ის forwarding წესები UFW-ს წესებამდე მუშავდება. სადაც შესაძლებელია, გამოაქვეყნე 127.0.0.1-ზე, შიდა სერვისები საერთოდ არ გამოაქვეყნო და გამოიყენე DOCKER-USER ჯაჭვი, როცა საჯარო კონტეინერის პორტის მისამართით შეზღუდვა მართლა გჭირდება.

მჭირდება წესები გამავალი ტრაფიკისთვის?

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

რა განსხვავებაა deny-სა და reject-ს შორის?

deny პაკეტს პასუხის გარეშე აგდებს, ამიტომ გამგზავნი timeout-ს ელოდება. reject აგზავნის ICMP unreachable-ს ან TCP reset-ს, ამიტომ გამგზავნი მაშინვე ვარდება. ინტერნეტისკენ გადააგდე, იქ კი, სადაც სწრაფი და გასაგები შეცდომები სიჩუმეზე სასარგებლოა, უარყავი.

მუშაობს UFW nftables-თან?

დიახ. მიმდინარე Debian-სა და Ubuntu-ზე iptables ბრძანებებს, რომლებსაც UFW გასცემს, iptables-nft თარგმნის ფენა ამუშავებს და ბირთვში ისინი nftables წესებად ჩნდება. შედეგი შეგიძლია sudo nft list ruleset-ით ნახო, თუმცა გამოტანა ufw status-ზე გაცილებით ნაკლებად იკითხება.