ერთი banaction, ორი ტრანსპორტი: fail2ban-VPN-jail-ის შეკეთება

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

წაიკითხეთ ჯაჭვი და არა jail-ის შეჯამება

fail2ban თავის ჯაჭვს სერვისის ჯაჭვამდე ამატებს, ამიტომ მრიცხველების სია ზუსტად აჩვენებს, რა არსებობს. ჯაჭვი, რომელსაც jail-ის სახელი აქვს და ერთი წესი უჭირავს, სადაც პროტოკოლის სვეტში udp წერია, სრული ახსნაა მუდმივად მომავალი TCP შესვლებისთვის. უარყოფილია მხოლოდ აკრძალული წყაროს UDP პაკეტები. სერვისს აქვს TCP მსმენელი და ამ ჯაჭვში არაფერი ეხება მას.

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

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

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

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

გახადეთ ban ორივე ტრანსპორტის დამფარველი

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

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

ნუ შეეცდებით ამის შემოკლებას protocol = all-ით. ნაგულისხმევი banaction multiport მოქმედებაა და ის -p <protocol> -m multiport --dports <port>-მდე ფართოვდება; L4 პროტოკოლის გარეშე პორტის დამთხვევას საცდელი არაფერი აქვს, ამიტომ iptables უარყოფს წესს, სანამ jail კვლავ წარმატებულ ban-ს აცნობს. ყველა პორტის მოქმედება, როგორიცაა iptables-allports ან nftables-allports, ერთ ჩანაწერს იღებს, მაგრამ ბლოკავს ყველა პორტს ამ წყაროზე, რაც სხვა გადაწყვეტილებაა და საკუთარ დასაბუთებას მოითხოვს. დატოვეთ protocol tcp-ზე ან udp-ზე და მიიღეთ ორივე ჩანაწერი.

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

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

ყოველმა ჯაჭვმა ერთი წესი უნდა ჩამოთვალოს, პირველში -p tcp და მეორეში -p udp, ორივე აკრძალულ მისამართს ასახელებს. შემდეგ დაადასტურეთ, რომ იგივე მისამართი ორივე ტრანსპორტზე უარყოფილია. ban, რომელიც ჯაჭვში არ გინახავთ, იმედია და იმავე სიმპტომის შემდეგი ანგარიში კვლავ იმავე საათი დაგიჯდებათ.

რას კვლავ გამოტოვებს ban და შემდეგი შემთხვევა

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

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

შეინახეთ გადატვირთვის ბრძანება და ჯაჭვების სია runbook-ში jail-ის გვერდით. შემდეგ ადამიანს ორივე დასჭირდება და jail-ის შეჯამება არც ერთს არ ეტყვის.