Firewall:არასწორი კონფიგი და შეცდომები Firewall-ის გამართვის დროს

WiKi MikroTik geo გვერდიდან
Jump to navigation Jump to search
Icon-warn.png

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


შესავალი

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

  1. ცრუკონფიგი. როგორც წესი, ასეთი წესები გავლენას არ ახდენს ქსელის მუშაობაზე. მხოლოდ ანაგვიანებს კონფიგურაციას და ამით ართულებს მის შემდგომ ანალიზს. ზოგჯერ შეიძლება და ზიანი მიაყენოს. ამ კატეგორიის მთავარი ნიშანი არის გარკვეული რთული პარამეტრების გამოყენება. ზოგჯერ ეს წესებს უწოდებენ "ტრუხამიცინი".
  2. ცარიელი წესები. როგორც წესი არაფერს არ აკეთებს. არც უარესი და არც უკეთესი. ასევე, მოიხმარენ პროცესორის რესურსებს უაზრო წესების დამოშავებისათვის. ცრუ პარამეტრების ფუნდამენტური განსხვავება რთული პარამეტრების გამოყენების ნაკლებობაა.
  3. შეცდომები. სახელი საუბრობს თავისთავად. პირობითად შეიძლება დაიყოს კატეგორიებად:
    • შედეგი, რომელიც ასეთ პარამეტრებს იძლევა, არ შეესაბამება იმას, რაც თავდაპირველად მოსალოდნელი იყო.
    • ცოდნის ნაკლებობა, თუ როგორ უნდა დააკონფიგურიროთ firewall. შედეგად ვღებულობთ იმას, რა უნდოდათ თავდაპირველად მიეღოთ, მაგრამ შეიძლება იყოს პრობლემები ან დაუცველობა.

ცრუცონფიგი

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

BOGON

აღწერა

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

კინსოლის მეშვეობით ეს გამოიყურება ასე:

/ip firewall address list
add address=0.0.0.0/8 list=BOGON
add address=10.0.0.0/8 list=BOGON
add address=100.64.0.0/10 list=BOGON
add address=127.0.0.0/8 list=BOGON
add address=169.254.0.0/16 list=BOGON
add address=172.16.0.0/12 list=BOGON
add address=192.0.0.0/12 list=BOGON
add address=192.0.2.0/24 list=BOGON
add address=192.168.0.0/16 list=BOGON
add address=198.18.0.0/15 list=BOGON
add address=198.51.100.0/24 list=BOGON
add address=203.0.113.0/24 list=BOGON
add address=217.67.177.164 list=BOGON
add address=224.0.0.0/3 list=BOGON

/ip firewall filter
add action=drop chain=input in-interface=WAN src-address-list=BOGON

მითების მსხვრევა

უპირველეს ყოვლისა, მოდით განვსაზღვროთ, რა არის "BOGON". BOGON — ეს არის IP-მისამართები, რომელიც არ უნდა შეგვხვდეს მარშრუტიზაციის ცხრილებში ინტერნეტში. ეს ტერმინი აღწერს კერძო და დარეზერვებულ მისამართების დიაპაზონებს. ამ ქსელების სია აღწერილია RFC 1918, RFC 5735 და RFC 6598. გთხოვთ გაითვალისწინოთ, რომ ჩვენ ვსაუბრობთ მარშრუტიზაციის ცხრილებზე ინტერნეტში, და არა მარშრუტიზაციის ცხრილებზე, პრინციპში. ასეთი მისამართები ხშირად შეიძლება გამოყენებულ იქნას DDoS თავდასხმებისთვის როგორც IP-მისამართის წყაროდ. გარდა ამისა, მხოლოდ BOGON, არსებობს ასევე FULLBOGON, რომელიც რატომღაც დავიწყებულია.

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

აქ მე მიყვარს კითხვის დასმა. რატომ გადაწყვიტეთ ქსელის ბლოკირება 192.0.2.0/24, მაგრამ ამასთან ერთად არ დაბლოკეთ 192.0.3.0/24 ან 192.0.4.0/24 ან 192.0.5.0/24? ამ კითხვაზე, როგორც წესი, ვერ პასუხობენ. უფრო მცოდნეები მიგვითითებენ rfc1166-ზე რომელშიც საუბარია, რომ ქსელი 192.0.2.0/24 დარეზერვირებულია "TEST-NET-1-თვის", რომელიც შეიძლება გამოყენებულ იქნას დოკუმენტაციაში ან მაგალითებზე. კონტრშეკითხვაზე: "რითი არ გაწყობს ნორმალურად ჩაკეტილი firewall?" როგორც წესი პასუხის გაცემა აღარ შეუძლიათ, რადგან ნორმალურად ჩაკეტილი firewall სავარაუდოდ უკვე გამოიყენება.

წავიდეთ წინ. დავუშვათ, როგორღაც მივიღეთ დინამიური "BOGON" და "FULLBOGON" სიები, რომლებიც ყოველთვის იქნება აქტუალურ მდგომარეობაში. მაშინ შესაძლოა თავად ამ BOGON-ბის დაბლოკვას არ ჰქონდეს აზრი? ალბათ მაშინ ექნება,მაგრამ სად დავაკონფიგურიროთ firewall სწორად ისე, რომ თქვენ არ დაგჭირდეთ დამატებითი წესების შექმნა. ამისათვის საჭიროა firewall-ის ნორმალურად კონფიგურაცია ნორმალურად დახურულ რეჟიმში და დავბლოკოთ invalid-ტრაფიკი.

/ip firewall filter
add action=accept chain=input connection-state=established,related #წესი №1 ჯაჭვში input
add action=drop chain=input connection-state=invalid #წესი №2 ჯაჭვში input
...
add action=drop chain=input #ბოლო წესი ჯაჭვში input
# ბოლო წესისათვის ხშირად დამატებით უთითებენ შემომსვლელ WAN-ინტერფეისს, მაგრამ ეს დამოკიდებულია კონკრეტულ პარამეტრებზე, რომლებიც ქსელის ადმინისტრატორს სურს

წესი, რომელიც ბლოკავს invalid-тტრაფიკს აუცილებლად უნდა წავიდეს მეორე დაუყონებლივ წესის შემდეგ, რომელიც იძლევა ნებართვას established და related ტრაფიკი. მაგალითად, თუ გავაკეთებთ ასე:

/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=accept chain=input protocol=icmp
add action=drop chain=input connection-state=invalid

მაშინ ჩვენ დაუცველობის რისკის ქვეშ ვხვდებით არალეგიტიმური ICMP ტრაფიკის გაგზავნის შესაძლებლობის სახით. და ეს მოხდება შემდეგნაირად:

  1. პირველი მავნე პაკეტი, რომელსაც როგორც წყარო ექნება მისამართი ნებისმიერი ქსელიდან, მათ შორის BOGON-დან, დამუშავდება მეორე წესით, რომელიც საშუალებას იძლევა ICMP ტრაფიკის. მარტივი ენაზე: ვინმე სავარაუდოდ გაგზავნის პასუხს ping-მოთხოვნებზე, რომელიც არ იყო რეალურად გაგზავნილი.
  2. ყველა შემდგომი პაკეტი დამუშავდება პირველივე წესით, რომელიც ნებასრთავს established & related ტრაფიკი.
  3. წესამდე რომელიც ბლიკავს invalid ტრაფიკს, საქმე არ მივა მაქამდე. კერძოდ, მას უნდა შეეჩერებინა თავდასხმა, მიუხედავად იმისა, თუ საიდან მოდის თავდასხმა BOGON ქსელიდან ან რომელიმე სხვა ქსელიდან.

რეზიუმე

იმისათვის, რომ არ მოხდეს პრობლემები BOGON- ქსელებთან, საკმარისია Firewall დაკონფიგურირდეს ნორმალურ დახურულ რეჟიმში. ამავე დროს, BOGON ქსელის პარამეტრი არ შეიძლება პირდაპირ ჩართული იყოს არანაირად.

TCP-კავშირების დაბლოკვა სანიშნეებით

ამ ცრუცონფიგს აქვს ბევრი ვარიანტი. ზოგადად, ეს გამოიყურება როგორც მცდელობა დავბლოკოთ რაღაც TCP-კავშირი სანიშნის საფუძველზე "tcp-flag" ოფციის გამოყენებით. ამ firewall-ის ცრუკონფიგს MikroTik-ზე აქვს ბევრი განსხვავებული ვარიაციები. ჩვეულებრივ მათ აერთიანებს, რომ აქვთ რამოდენიმე წესი რომელშიც რაღაც მსგავსი აუცილებლად შეგხვდებათ:

... protocol=tcp tcp-flags=fin,syn
... protocol=tcp tcp-flags=fin,psh,urg,!syn,!rst,!ack
... protocol=tcp tcp-flags=fin,syn,rst,psh,ack,urg

ცარიელი წესები

უმეტესწილად, ეს წესები ერთ რამეზე მიდის: იმის ნებართვას, რაც არ არის აკრძალული.

აღწერა

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

/ip firewall filter
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=161 protocol=udp src-address-list=zabbix
add action=accept chain=input dst-port=8291 protocol=tcp
add action=accept chain=input port=500,1701,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
...
არ არსებობს აკრძალვის არცერთი წესი

მითების მსხვრევა

Сპაკეტით, რომელიც ხვდება firewall-ში ამ წესების ნაკრებით მოხდება ორიდან ერთი:

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

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

რეზიუმე

გირჩევთ გააკეთოთ ორიდან ერთი:

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

შეცდომები

ნორმალურად გახსნილი firewall-ის გამოყენება

აღწერა

ძალიან ხშირად, Input ჯაჭვისთვის გამოიყენებენ ნორმალურად გახსნილ firewall-ს. ის ასე გამოიყურება:

/ip firewall filter
add action=drop chain=input dst-port=53 protocol=tcp
add action=drop chain=input dst-port=53 protocol=udp
add action=drop chain=input dst-port=22 protocol=tcp
add action=drop chain=input dst-port=80 protocol=tcp
add action=drop chain=input ...
add action=drop chain=input ...
add action=drop chain=input ...
add action=drop chain=input ...
...
სხვა ამკრზალველი წესები

პრობლემა

ამ მაგალითში, Input ჯაჭვისთვის გამოიყენება ნორმალურად გახსნილი firewall და იბლოკება ის, რაც ადმინისტრატორის აზრით წარმოადგენს რისკს. მართლაც, 53-ე პორტის (DNS) ღიად გამოყენება ინტერნეტისათვის ეს არის ძალიან დიდი რისკი იმისთვის, აღმოჩნდეთ "DNS Resolve" ტიპის სეტევაზე და მიიღეთ CPU-ის დატვირთვა DNS სერვისით 100%-ით.
პრობლემა იმაშია, რომ ნორმალურად გახსნილი firewall-ს გამოყენებისას ადმინისტრატორი დაიღლება აკრზალვებით. მაშინაც კი, თუ ვივარაუდოთ, რომ ადმინისტრატორმა 100%-ით იცის ყველაფერი, რა უნდა აკრზალოს, აშინ უმჯობესია არ გამოიყენოს ასეთი სქემა, იმიტომ, რომ საგრძნობლად გაიზრდება წესების რაოდენობა რომლის მეშვეობიტაც პაკეტი გაივლის. და რაც უფრო მეტი წესები გადაეცემა პაკეტს, მით უფრო მაღალია მოწყობილობის პროცესორზე დატვირთვა.

გამოსავალი

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

/ip firewall filter
add action=accept chain=input connection-state=established,related #წესი №1 ჯაჭვში input
add action=drop chain=input connection-state=invalid #წესი №2 ჯაჭვში input
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=8291 protocol=tcp
add action=accept chain=input port=500,1701,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=drop chain=input in-interface=WAN #ბოლო წესი ჯაჭვში input

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

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

წესების არასწორი რითობა

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

მაგალითი №1
მაგალითი იმისა, როდესაც ბლოკირების წესი არ მუშაობს:

/ip firewall filter
...
add action=accept chain=input protocol=tcp
...
add action=drop chain=input dst-port=22
...

ამ სიტუაციაში, წესი, რომელიც ბლოკავს SSH-ტრაფიკს (22-ე პორტი TCP) არ მუშაობს, რადგან არსებობს წესი, რომელიც ნებართვის საშუალებას აძლევს ნებისმიერ TCP ტრაფიკს.

მაგალითი №2
კიდევ ერთი მაგალითი სიტუაციისა, სადაც დაბლოკვის წესი არ მუშაობს:

/ip firewall filter
...
add action=accept chain=forward dst-address=192.168.15.0/24
...
add action=drop chain=forward in-interface=Guest out-interface=LAN
...

თუ ამ კონფიგურაციას განვიხილავთ დანარჩენი პარამეტრების გარდა, როგორც ჩანს, რომ ტრაფიკი "Guest"-დან "LAN"-ში უნდა იყოს აკრზალული, მაგრამ თუ შეხედავთ მთელ კონფიგურაციას, შეგიძლიათ იპოვოთ, რომ ქსელი 192.168.15.0/24 ეკუთვნის LAN ინტერფეისს:

/ip address
add address=192.168.15.254/24 interface=LAN network=192.168.15.0

ამდენად ჩვენ მივიღებთ, რომ ჩვენ გვაქვს ნებართვის წესი ამკრძალავის ზემოთ.


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

/ip firewall filter
...
 add action=drop chain=forward in-interface=DMZ out-interface=LAN
...
add action=accept chain=forward dst-port=80,443 protocol=tcp

ამ მაგალითში არსებობს წესი, რომელიც ნებას რთავს TCP-ტრაფიკს დანიშნულების პორტით 80 და 443. თუ განვიხილავთ წესს დანარცენებისაგან ცალკე, მაშინ ჩვენ შეგვიძლია ვივარაუდოთ, რომ DMZ- სგან შესაძლებელი იქნება LAN-შ ასეთი ტრაფიკით შეღწევა. მაგრამ სინამდვილეში ამის გაკეთება ვერ მოხდება, ვინაიდან ზემოთ არის აკრძალული წესი, რომელიც ბლოკავს ნებისმიერ ტრაფიკს DMZ-დან LAN-ში.

FastTrack-ის არასწორი გამოყენება

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

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related

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

FastTrack на схеме прохождения трафика MikroTik

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

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