tun0 არ არის? შეადარეთ გაშიფრული IPsec nftables-ში meta ipsec-ით

თქვენ ელით გვირაბის ინტერფეისს, ეძებთ მას და firewall-ში შესადარებელი არაფერია. ეს ნორმალურია პოლიტიკაზე დაფუძნებული კარიბჭე ტიპისთვის: დაშიფრული გაცვლა ფიზიკურ ინტერფეისზე მოდის, და შემდეგ გადაცემული გაშიფრული შიდა პაკეტიც აღიქმება იმავე ინტერფეისზე მომავალად. tun0 არ არის, რადგან ვერაფერმა არ შექმნა ის.

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

ორი პაკეტი, ერთი ინტერფეისი

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

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

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

დაწერეთ გადაცემის წესი

დავუშვათ, არსებობს ავთენტიფიცირებული IPv4 დისტანციური წვდომის სერვისი კლიენტებით 10.90.0.0/24-ში და ერთი დამტკიცებული დანიშნულება 203.0.113.40-ზე. ამ ნაკადის წესის ფრაგმენტი ასე გამოიყურება.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

გარე გაცვლის ნებართვები ცალკეა. კარიბჭის შემავალ ბილიკს სჭირდება ის IKE და ESP ან UDP-შეფუთვის პორტები, რომლებსაც ის რეალურად იყენებს, და ეს ნებართვები არაფერს უშვებს შიგნით გაშიფრულ პაკეტთან დაკავშირებით. ორივეს შერევა ის გზაა, რომლითაც მომუშავე გვირაბი აღმოჩნდება firewall-თან, რომელიც ყველაფერს გადასცემს.

შემომავალი კონტექსტი გამავალი კონტექსტი არ არის

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

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

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

NAT firewall-ის გადაწყვეტილება არ არის

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

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

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

გადაამოწმეთ ზუსტი შიდა სერვისი

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

nftables-ის ცნობარი აღწერს meta ipsec-ს, rt ipsec-ს და მიმართულების სპეციფიკურ გამონათქვამებს, და სწორედ იქ უნდა შეამოწმოთ სინტაქსი თქვენს დაყენებულ ვერსიასთან. და შეინახეთ მოცულობა ცხადად: ეს IPv4-ის მაგალითია, ის არაფერს ამბობს IPv6-ზე და არ აქცევს თვითნებურ საჯარო პორტების გადაცემას VPN სერვისის ნაწილად.