firewall-ის წესები, რომლებიც მართლა მნიშვნელოვანია, და ისინი, რომლებიც არა

Firewall არის სია იმისა, რაც დაშვებულია, და ყველაფერი დანარჩენი უარყოფილია. ასე დაწერილი ტრივიალურად ჟღერს, და რეალურ სერვერს დამცავი წესების ნაკრები მართლაც მოკლეა: ერთი-ორი საჯარო პორტი, ადმინისტრაციული წვდომა შენ მიერ კონტროლირებადი მისამართებით შეზღუდული და სხვა არაფერი.

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

რას აკეთებს firewall და როგორია წესების ნაკრები, რომელიც გადარჩება#

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

ის არ აჩერებს მოცულობით ნაკადს (flood). როცა პაკეტი შენს მანქანამდე აღწევს, ის უკვე გადავიდა შენს uplink-ზე, ამიტომ მისი ადგილობრივად გადაგდება იმ არხს არ განთავისუფლებს, რომელიც მან დაიკავა. დიდი ნაკადების გაფილტვრა upstream-ზე უნდა მოხდეს - რას ვაკეთებთ თავდასხმების წინააღმდეგ პატიოსანი ანგარიშია იმისა, რასაც ეს იჭერს, ხოლო DDoS თავდასხმები გეიმ სერვერებზე ახსნილი თავდასხმის ტიპებს განიხილავს. ის არ გეხმარება ტრაფიკის წინააღმდეგ, რომელიც ზუსტად მოთამაშესავით გამოიყურება, რადგან პაკეტის დონეზე ის მოთამაშეა. და არაფერს აკეთებს სუსტ პაროლთან, გაუახლებელ plugin-თან ან მავნე mod-თან, რაც ისაა, რითაც სერვერების უმეტესობა სინამდვილეში იკარგება.

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

ჩონჩხს ხუთი წესი ქმნის, ამ თანმიმდევრობით:

1. მიიღე დამყარებული და დაკავშირებული ტრაფიკი. Connection tracking ნიშნავს, რომ იმ კავშირების პასუხები, რომლებიც შენ გახსენი, ყოველი მათგანისთვის წესის გარეშე დაშვებულია. ამის გარეშე default-deny პოლიტიკა ბლოკავს პასუხს ყველა მოთხოვნაზე, რომელსაც შენი სერვერი აკეთებს.
2. გადააგდე არასწორი (invalid) პაკეტები. ტრაფიკი, რომელიც არცერთ თვალყურდევნებულ კავშირს არ მიეკუთვნება და არც კანონიერი ახალია.
3. მიიღე ყველაფერი loopback-ზე. ლოკალური სერვისები ერთმანეთს 127.0.0.1-სა და ::1-ზე ელაპარაკებიან. მისი დაბლოკვა რამეებს დამაბნეველი გზებით არღვევს.
4. დაუშვი ICMP, რომელიც გჭირდება. Echo მოთხოვნები, რომ ხალხმა შენს სერვერზე ping გააგზავნოს, და, რაც გადამწყვეტია, შეტყობინებები, რომლებიც path MTU discovery-ს ამუშავებს. ICMPv6-ის მთლიანად გადაგდება IPv6-ს პირდაპირ არღვევს - IPv6 და გეიმ სერვერები დეტალურად ხსნის, რატომ.
5. შემდეგ მოკლე დაშვების სია, შემდეგ ყველაფრის აკრძალვა ნაგულისხმევად.

წესები, პორტ-პორტ#

ყოველი წესი სამ კითხვას პასუხობს: რომელი პორტი, რომელი პროტოკოლი და ვისთვის ღია. მესამეს ხალხი ტოვებს და სწორედ ის არის მნიშვნელოვანი.

ორ ჩანაწერს შენიშვნა სჭირდება. Query პორტები ღია უნდა იყოს, თორემ სერვერი შესანიშნავად მუშაობს და არავის browser-ში არასოდეს ჩნდება, რაც მარცხის ისეთი ფორმაა, რომელიც firewall-ის პრობლემას სულაც არ ჰგავს - გეიმ სერვერის პორტები ახსნილი ხსნის, რატომ. და Source engine-ის RCON არის TCP იმავე პორტის ნომერზე, რომელსაც თამაში UDP-ით იყენებს, რაც ნიშნავს, რომ მათ მხოლოდ პორტის ნომრით ვერ გამოყოფ: წესმა პროტოკოლები უნდა განასხვავოს.

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

წესების ჩაწერა ufw-ით#

ufw არის iptables-ის წინა მხარე, რომელიც ჩვეულებრივ წესების ნაკრებს ოთხ ბრძანებად ხდის. Debian-სა და Ubuntu-ზე ის ჩვეულებრივ უკვე დაყენებულია.

$ ufw default deny incoming$ ufw default allow outgoing$ ufw allow from 203.0.113.5 to any port 22 proto tcp comment 'ssh admin'$ ufw allow 25565/tcp comment 'minecraft java'$ ufw allow 2456:2457/udp comment 'valheim game and query'$ ufw enable

ამ თანმიმდევრობის შესახებ რამდენიმე რამ:

• SSH-ის წესი დაამატე მის ჩართვამდე. default-deny პოლიტიკის SSH-ით ჩართვა SSH-ის წესის გარეშე მანქანიდან გვერდით გაგდებს და უკან ერთადერთი გზა შენი პროვაიდერის პანელის კონსოლია.
• პორტების დიაპაზონს პროტოკოლი სჭირდება. ufw allow 2456:2457/udp სწორია, ufw allow 2456:2457 - არა.
• გამოიყენე `comment`. ექვს თვეში წესი, რომლის ახსნაც არ შეგიძლია, წესია, რომელსაც შიშით დატოვებ. კომენტარი ამას გადაწყვეტილებად აქცევს.
• `ufw limit 22/tcp` SSH-ს უშვებს, მაგრამ ზღუდავს მისამართს, რომელიც ოცდაათ წამში ექვსზე მეტ კავშირს აკეთებს. სასარგებლოა, თუ SSH-ის მსოფლიოსთვის გახსნა გიწევს, რასაც უნდა ეცადო, თავიდან აირიდო.
• IPv6 ცალკე წესების ნაკრებია, და ufw მას მხოლოდ მაშინ მართავს, როცა /etc/default/ufw-ში დაყენებულია IPV6=yes. თანამედროვე ინსტალაციებზე ის ნაგულისხმევად ჩართულია და მაინც ღირს შემოწმება.

შემდეგ ჩაიკითხე, რაც ააგე, რადგან სია დოკუმენტაციაა:

$ ufw status numberedStatus: active     To                         Action      From     --                         ------      ----[ 1] 22/tcp                     ALLOW IN    203.0.113.5     # ssh admin[ 2] 25565/tcp                  ALLOW IN    Anywhere        # minecraft java[ 3] 2456:2457/udp              ALLOW IN    Anywhere        # valheim$ ufw delete 3

ჩართე logging ufw logging low-ით და უარყოფილი პაკეტები /var/log/ufw.log-ში აღმოჩნდება. ხმაურიანია - ინტერნეტი ყველა მისამართს განუწყვეტლივ სკანირებს - მაგრამ ასე გებულობ, რომ რაღაც, რაც უნდა მუშაობდეს, დაბლოკილია. ufw-ის გზამკვლევი ინსტრუმენტს სათანადოდ გადის, ხოლო პირველი საათი ახალ VDS-ზე მას იმ თანმიმდევრობაში აყენებს, რომელსაც დანარჩენი მოწყობა ითხოვს.

იგივე წესები nftables-ში#

თუ აგებ რაღაცას, რასაც წლების განმავლობაში შეინარჩუნებ, nftables უკეთესი საფუძველია. ერთი inet ცხრილი ერთსა და იმავე წესების ნაკრებში IPv4-სა და IPv6-ს ფარავს, რაც ბაგების მთელ კატეგორიას აქრობს: "v4-ზე მუშაობს, v6-ზე ჩუმად იჭრება".

#!/usr/sbin/nft -fflush rulesettable inet filter {  chain input {    type filter hook input priority filter; policy drop;    ct state established,related accept    ct state invalid drop    iif lo accept    ip protocol icmp icmp type { echo-request, destination-unreachable, time-exceeded } accept    ip6 nexthdr icmpv6 accept    tcp dport 22 ip saddr 203.0.113.5 accept    tcp dport { 80, 443 } accept    tcp dport 25565 accept    udp dport 2456-2457 accept  }  chain forward { type filter hook forward priority filter; policy drop; }  chain output  { type filter hook output  priority filter; policy accept; }}

ჩატვირთე nft -f /etc/nftables.conf-ით და შეამოწმე nft list ruleset-ით. ჩართე nftables.service, რომ გადატვირთვას გადარჩეს, და წესების ნაკრები გატესტე მეორე სესიიდან, სანამ იმას დახურავ, რომლითაც მუშაობ.

Docker და რატომ იგნორირებულია შენი წესები#

ეს ისე უკვირთ ხალხს, რომ ცალკე განყოფილებას იმსახურებს. Container გამოქვეყნებული პორტით ხშირად ინტერნეტიდან მისაწვდომია, თუმცა ufw status აჩვენებს deny-by-default პოლიტიკას და მისთვის წესი არ არსებობს.

მიზეზი ისაა, რომ Docker საკუთარ წესებს პირდაპირ iptables-ში წერს, nat ცხრილსა და ჯაჭვებში, რომლებიც ufw-ის მართულებზე ადრე მოწმდება. პორტის -p 5432:5432-ით გამოქვეყნება ქმნის destination NAT-ს, რომელიც INPUT ჯაჭვს მთლიანად უვლის გვერდს. შენი firewall არ არის გატეხილი და მას არავინ მიმართავს.

სამი გამოსავალია და პირველი უნდა გამოიყენო:

1. გამოაქვეყნე loopback-ზე. -p 127.0.0.1:5432:5432 გამოქვეყნებულ პორტს მხოლოდ ლოკალურ ინტერფეისზე აბამს, ამიტომ container host-იდან მისაწვდომია და სხვა არსაიდან. Compose ფაილში ეს არის "127.0.0.1:5432:5432".
2. დაწერე წესები `DOCKER-USER` ჯაჭვში, რომელსაც Docker საკუთარზე ადრე მიმართავს და არ გადაწერს. ეს მუშაობს და მისი არასწორად გაკეთება ადვილია, რადგან პაკეტები NAT-ში უკვე გავიდა და მისამართები ის არაა, რასაც ელოდები.
3. პორტი საერთოდ არ გამოაქვეყნო. ერთსა და იმავე Docker ქსელში მყოფი container-ები ერთმანეთს სახელით უკავშირდებიან container-ის პორტზე. თუ ბაზას მხოლოდ შენი აპლიკაცია ელაპარაკება, ბაზას გამოქვეყნებული პორტი საერთოდ არ სჭირდება.

Docker VDS-ზე დანარჩენ მოწყობას განიხილავს, და იგივე მსჯელობა ეხება ნებისმიერ container runtime-ს, რომელიც საკუთარ ქსელს მართავს.

პორტები, რომლებიც ღიად რჩება, და როგორ იპოვო ისინი#

ამათგან სამი ისევ და ისევ ჩნდება და სამივე გონივრულმა ადამიანმა გონივრული მიზეზით გახსნა.

ბაზის პორტი, რომელიც სახლიდან კავშირის გასატესტად გაიხსნა. Postgres 5432-ზე და MongoDB 27017-ზე ათი წუთით ექსპონირდება, რომ desktop კლიენტიდან query გაეშვას, და მერე ასე რჩება. Postgres-ისთვის firewall ისედაც მხოლოდ ნახევარი კონტროლია: listen_addresses postgresql.conf-ში წყვეტს, რომელ ინტერფეისებს მიება, ხოლო pg_hba.conf - ვის შეუძლია ავთენტიფიკაცია და როგორ. ხაზი, როგორიცაა host all all 0.0.0.0/0 md5 pg_hba.conf-ში, რეალური კარია, და firewall-ის დახურვა ამ ხაზის დატოვებით გამოსწორებაა, რომელიც firewall-ის წესის ტოლ ხანს გასტანს. ბაზის უსაფრთხოების checklist მთლიანი სიაა, ხოლო PostgreSQL-თან დისტანციური დაკავშირება ამას უსაფრთხო გზით აკეთებს.

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

ადმინისტრირების ან debug ინტერფეისი, რომელიც ყველა ინტერფეისზეა მიბმული, რადგან ასეთი იყო ნაგულისხმევი. ვებ ადმინი 8080-ზე, metrics endpoint 9090-ზე, სამუშაო სერვერი 3000-ზე, profiler, რომელიც გამოძიების შემდეგ ჩართული დარჩა. მასობრივი სკანერები მათ გახსნიდან საათებში პოულობენ და არა დღეებში.

მათი პოვნა ორ ბრძანებას სჭირდება. თავად მანქანიდან:

$ ss -ltnp$ ss -lunp

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

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

$ nmap -Pn -p- --open node.example.com$ nmap -Pn -sU --top-ports 50 node.example.com

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

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

Egress: წესები, რომელსაც არავინ წერს#

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

კომპრომეტირებული პროცესი - მავნე mod, ფორუმიდან აღებული plugin, უკანა კარიანი dependency - გამავალ კავშირებს იყენებს ყველაფრისთვის, რაც შემდეგ მოდის: მეორე ეტაპის ჩამოტვირთვა, botnet-ში გაერთიანება, შენი მონაცემების სადმე გაგზავნა ან spam-ის გადაგზავნა. შენი firewall-ის შემომავალ მხარეს აქ არაფერი ეხება.

ორი egress წესი იაფია და თითქმის ნებისმიერ სერვერზე ღირს ქონად:

• დაბლოკე გამავალი TCP 25. გეიმ ან აპლიკაციის სერვერზე არაფერი კანონიერად არ აგზავნის ფოსტას პირდაპირ. ეს წესი "ჩვენი მანქანა spam-ის გასაგზავნად გამოიყენეს და ახლა ჩვენი მისამართი blocklist-შია" ჩანაწერად log-ში აქცევს.
• დაბლოკე გამავალი კავშირები შენი ბაზის container-იდან, თუ გაქვს. ბაზას არაფერი აქვს საქმე ინტერნეტში კავშირების დამყარებასთან და თუ იწყებს, უნდა გაიგო.

სრული egress allow-list-ი - ყველა დანიშნულების დასახელება, სადაც სერვერს შეუძლია მიაღწიოს - რეალისტურია მოწყობილობისთვის და მტკივნეული გეიმ სერვერისთვის, სადაც mod-ები ათეულობით ჰოსტიდან იტვირთება, რომლებიც არასოდეს გსმენია. შეაფასე ის იმით, რასაც სერვერი აკეთებს. თუ mod-ის განახლება იმიტომ ფუჭდება, რომ CDN-ს ვერ მიაღწია, წესები უფრო მეტს ჯდება, ვიდრე დაზოგეს - მოდიფიცირებული სერვერის სისუფთავეში შენახვა ამ კომპრომისის უფრო ფართო ვერსიაა.

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

პანელზე firewall შენი არ არის#

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

რას აკონტროლებ სამაგიეროდ:

• რომელი პორტები არსებობს. თითოეული გეგმა თავის განაწილებებს აცხადებს, ხოლო პორტები ემატება და იშლება სერვერის Network ჩანართზე, query-ისა და RCON-ის ჩათვლით. პორტი, რომელიც განაწილებული არ არის, მიუწვდომელია, რაც firewall-ის წესია, გამოხატული სიის სახით, რომელსაც ერთი შეხედვით კითხულობ.
• იზოლაცია. ერთი container თითო სერვერზე, CPU-ით, როგორც მყარი throttle იმ წილამდე, რომელიც იყიდე. შენი მეზობლები შენს მანქანაზე არ არიან ისეთი გაგებით, რომელსაც მნიშვნელობა აქვს.
• კონსოლი RCON-ის ნაცვლად. პანელის კონსოლი იგივე შესაძლებლობაა იმ ანგარიშის უკან, რომელსაც უკვე სათანადოდ იცავ, და არა მეორე credential ღია პორტზე.
• ანგარიშის უსაფრთხოება, რომელიც ახლა ნამდვილი პერიმეტრია. TOTP ორფაქტორიანი ავთენტიფიკაცია ერთჯერადი აღდგენის კოდებით, bcrypt პაროლის hash-ები, captcha და rate limit-ები შესვლაზე, სესიების სია, საიდანაც გამოსვლა შეგიძლია, და API გასაღებები, რომლებიც მისამართით შეიძლება შეიზღუდოს. ორფაქტორიანი ავთენტიფიკაცია შენი პანელის ანგარიშზე ხუთი კარგად დახარჯული წუთია.
• ყველაზე მცირე პრივილეგია ადამიანებისთვის. Subuser-ები, როლები და გუნდები დეტალური უფლებებით - მხოლოდ კონსოლი, მხოლოდ ფაილები, ბილინგის გარეშე - დროში შეზღუდული წვდომა და თითო სერვერის აქტივობის log. ეს არის კონტროლი, რომელიც მნიშვნელოვანია, როცა წვდომა ერთზე მეტ ადამიანს აქვს, და აღწერილია subuser-ებსა და ყველაზე მცირე პრივილეგიაში.

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

თუ სრული firewall უკან გინდა, ეს არის VDS-ის არგუმენტი, ყველაფერთან ერთად, რასაც მერე თავად უნდა მოუაროთ - VDS-სა და გეიმ პანელს შორის არჩევანი ორივეს პატიოსნად აწონის.

FAQ#

მჭირდება firewall, თუ ჩემი სერვერი მხოლოდ ერთ თამაშს უშვებს?

თუ ეს შენი მანქანაა, დიახ. გეიმ სერვერი იშვიათად მუშაობს მარტო: SSH, პაკეტების მენეჯერის სერვისები, monitoring აგენტი და ის, რაც გასულ თვეს რაღაცის გამართვისთვის დააყენე, ყველა უსმენს. Default deny არის ის, რაც ექსპონირებული სერვისების სიას იმ სიას ამთხვევს, რაც გქონდა განზრახული.

იცავს თუ არა firewall DDoS თავდასხმებისგან?

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

უნდა შევცვალო SSH-ის პორტი 22-დან?

ის ამცირებს ავტომატური სკანერების log-ის ხმაურს და უსაფრთხოება არ არის. რაც სინამდვილეში მნიშვნელოვანია, არის მხოლოდ გასაღებით ავთენტიფიკაცია PasswordAuthentication no-ით, პორტის შეზღუდვა შენ მიერ კონტროლირებადი მისამართებით და fail2ban მასზე. პორტის შეცვლა არჩევითია და არაფერს ცვლის იმაში, ვინ შემოდის.

რატომ მიაღწევენ ხალხი ჩემს container-ს, თუ ufw ყველაფერს უარყოფს?

იმიტომ, რომ Docker საკუთარ iptables წესებს წერს, რომლებიც ufw-ის მართულ ჯაჭვებზე ადრე მოწმდება, ამიტომ გამოქვეყნებული პორტი შენს პოლიტიკას უვლის გვერდს. გამოაქვეყნე 127.0.0.1-ზე ყველა ინტერფეისის ნაცვლად, ან პორტი საერთოდ არ გამოაქვეყნო, თუ მხოლოდ სხვა container-ს სჭირდება.

რამდენად ხშირად უნდა გადავხედო firewall-ის წესებს?

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