ღრუბლოვანი უსაფრთხოების ჯგუფი VPN-ისთვის: გახსენით მსმენელი და არა ყველაფერი

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

დაასახელეთ პროტოკოლი წესამდე

წესი არის პროტოკოლი, პორტების დიაპაზონი და წყარო. WireGuard UDP-ზე ისმენს, ჩვეულებრივ 51820. OpenVPN ჩვეულებრივ UDP ან TCP 1194-ია კონფიგურაციის მიხედვით. IPsec-ს სჭირდება IKE გაცვლა UDP 500 და 4500-ზე, ასევე თავად ESP პროტოკოლი, რომელიც პროტოკოლის ნომერია და არა პორტი. TCP-ის გამოცნობა იმიტომ, რომ სხვა წესები TCP-ია, იძლევა წესს, რომელიც სწორად გამოიყურება და არაფერს ემთხვევა.

მსმენელი წაიკითხეთ მომუშავე სერვისიდან და არა სახელმძღვანელოდან. ერთ მისამართზე მიბმული დემონი არ მიიღებს სხვა მისამართზე მოსულ ტრაფიკს.

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

უსაფრთხოების ჯგუფები მდგომარეობის მქონეა; ქვექსელის ACL-ები არა

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

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

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

ჰოსტის ფაირვოლი ცალკე საზღვარია

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

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

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

მსმენელის დაშვება კლიენტების მარშრუტიზაცია არ არის

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

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

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

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

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

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

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