Fail2ban-ის ფილტრი OpenVPN Access Server-ისთვის: real_ip და jail-ები
Access Server საკუთარი ჟურნალის ფორმატს წერს, ამიტომ სტანდარტული ფილტრები ვერაფერს პოულობენ. დაამაგრეთ real_ip-ზე, დაყავით jail-ები ზედაპირის მიხედვით და შეამოწმეთ, რომ მისამართი პროქსი არ არის.
თქვენ დააკოპირეთ OpenVPN jail სამეურნეო პოსტიდან, გადატვირთეთ fail2ban და არც ერთი მისამართი არასდროს იბლოკება. მიზეზი თითქმის ყოველთვის ჟურნალის ფორმატია: Access Server არ წერს ავთენტიფიკაციის წარუმატებლობის იმ ხაზებს, რომლებსაც სტანდარტული ფილტრი ელოდება. ფილტრზე შეხებამდე დაადასტურეთ, რომ ჩანაწერები საერთოდ არსებობს, რადგან შაბლონი ვერ დაემთხვევა იმას, რაც სერვისს არასდროს დაულოგავს.
ეს არის ის runbook, რომელსაც Access Server ჰოსტზე მივყვები: დავადასტურო ჩანაწერის ფორმა, დავწერო ერთი დამაგრებული გამოსახულება, გამოვცადო ის ნამდვილ ჟურნალზე, შემდეგ დავყო jail-ები შეტევის ქვეშ მყოფი ზედაპირის მიხედვით და შევამოწმო, რომ ბლოკი firewall-ს აღწევს.
დაადასტურეთ, რომ წარუმატებლობის ჩანაწერი არსებობს
Access Server თავის სტრუქტურირებულ ხაზებს /var/log/openvpnas.log-ში წერს, ხოლო კლიენტის მისამართი ბრჭყალებში მოცემულ real_ip ველშია და არა syslog ხაზის დასაწყისში. ნებისმიერი შაბლონის დაწერამდე მოძებნეთ წარუმატებელი შესვლა, რომელიც იცით, რომ მოხდა:
grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20თუ არაფერი გამოჩნდა, შემდეგი ეჭვმიტანილი ჟურნალის დონეა. Access Server-ს აქვს ჟურნალის მონაცემთა ბაზის გამართვის გადამრთველი /usr/local/openvpn_as/etc/as.conf-ში (DEBUG_LOGDB=1), და სერვისი უნდა გადატვირთოს მისი შეცვლის შემდეგ. მოეკიდეთ ამ გადამრთველს როგორც დიაგნოსტიკურ პარამეტრს, რომელიც უნდა ისევ ჩამოიწიოს, როცა შაბლონი მზად იქნება, და არა როგორც მუდმივ კონფიგურაციას.
სანამ ფაილში ხართ, შენიშნეთ, რომელი ზედაპირები წერენ მასში. კლიენტის პორტალის, ადმინისტრირების ინტერფეისის და გვირაბის ავთენტიფიკაციის წარუმატებლობები ერთსა და იმავე ფაილში ხვდება სხვადასხვა მარკერით, და ეს დეტალი მოგვიანებით განსაზღვრავს jail-ების განლაგებას.
დაამაგრეთ ერთი ფილტრი real_ip-ზე
შეინარჩუნეთ გამოსახულება ვიწრო. ფილტრი, რომელიც IP მისამართის შემცველ ყველა ხაზს ითვისებს, ხალხს ჩვეულებრივი გაწყვეტების გამო დაბლოკავს, და დატვირთულ სერვერზე ერთადერთი სიმპტომი ის არის, რომ მომხმარებლები ჩივიან ნოუთბუქის დახურვის გამო დაბლოკვაზე. მოითხოვეთ შეცდომის ჩანაწერი და დაიჭირეთ ბრჭყალებში მოცემული მისამართი:
# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =წამყვანი სივრცე კოსმეტიკა არ არის. Access Server თავის ჩანაწერებს აწეწავს შიგნით, და მასზე დამაგრება ხელს უშლის შაბლონს მოითხოვოს ასევე იმ სერვისების ხაზები, რომლებიც იმავე ფაილში წერენ. თუ თქვენს ჩანაწერებს თავში დროის ნიშანი აქვს, დაემთხვიეთ ამ პრეფიქსს, მაგრამ დაამაგრეთ იმაზე, რაც ნამდვილად არსებობს ყოველ ჩანაწერში, რომლის მოთხოვნასაც აპირებთ.
როცა ზედაპირის მიხედვით სიზუსტე გჭირდებათ, კიდევ უფრო შევიწროვეთ, მოითხოვეთ რა ზედაპირის მარკერი (WEB_CLIENT, WEB_ADMIN ან VPN) იმავე ხაზში. სამი შაბლონის მქონე ერთი ფილტრი უფრო ადვილად საშემოწმებელია, ვიდრე სამი ფილტრი, რომლებიც ერთი სიტყვით განსხვავდება.
გამოსცადეთ გამოსახულება jail-ის ჩართვამდე
არასოდეს ჩართოთ ფილტრი, რომელიც არ გაგიშვიათ წარმოების ჟურნალზე. დოკუმენტირებული ტესტი ფილტრს ორჯერ გაატარებს, ერთხელ ჩატვირთვისთვის და ერთხელ გამოყენებისთვის, და გამოტოვებული ხაზების ანგარიში სწორედ ის ნაწილია, რომლის წაკითხვაც ღირს:
fail2ban-regex --print-all-missed /var/log/openvpnas.log \
/etc/fail2ban/filter.d/openvpnaccess.local \
/etc/fail2ban/filter.d/openvpnaccess.local > missed.txtშეადარეთ დამთხვევების რაოდენობა იმ წარუმატებლობებს, რომლებიც პირველ საფეხურზე დაადასტურეთ. ნულოვანი დამთხვევა ნიშნავს, რომ შაბლონი არასწორია; დამთხვევები ხაზებზე, რომლებიც ავთენტიფიკაციის წარუმატებლობა არ არის, ნიშნავს, რომ ის ძალიან ფართოა. წაიკითხეთ missed.txt, სანამ ვერ ახსნით ყოველ ხაზს, რომლის მოთხოვნაზეც უარი თქვით.
ეს ტესტი ასლზე ჩაატარეთ, თუ ჟურნალი დიდია, და გაიმეორეთ Access Server-ის ყოველი განახლების შემდეგ. ჟურნალის ფორმატი არის ის ინტერფეისი, რომელსაც ემთხვევით, და ის სტაბილური API არ არის.
დაყავით jail-ები ზედაპირის მიხედვით და არა დემონის
ერთი Access Server წარმოადგენს რამდენიმე ავთენტიფიკაციის ზედაპირს: კლიენტის და ადმინისტრატორის ვებ ინტერფეისები 943/tcp-ზე, და გვირაბი 1194/udp ან 443/tcp-ზე უმეტეს განლაგებაში. ყველა მათგანის დამფარავი ერთი jail საშუალებას აძლევს გვირაბზე გამოცნობის ცდებს დაბლოკონ მისამართი, რომელიც თქვენი ადმინისტრირების გზაც არის, და მალავს, რომელი ზედაპირია რეალურად შეტევის ქვეშ. მიეცით ყოველ ზედაპირს საკუთარი jail საკუთარი პორტით და ზღვრებით:
# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled = true
port = 943
protocol = tcp
filter = openvpnaccess
logpath = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime = 1h
[openvpnas-tunnel]
enabled = true
port = 443
protocol = udp
filter = openvpnaccess
logpath = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime = 1hდაიწყეთ პატარა მთვლელებით და მოკლე ბლოკით, შემდეგ გაზარდეთ ისინი, როცა ერთი კვირის რეალურ ტრაფიკს დააკვირდებით. საერთო ოფისის მისამართზე გულუხვი ზღვარი ზღუდავს ყოველ მომხმარებელს ერთი NAT-ის უკან, ხოლო აგრესიული ბლოკი გვირაბის ზედაპირზე თიშავს ლეგიტიმურ კლიენტებს, რომელთა შენახული სერთიფიკატები ღამით გაუქმდა.
შეამოწმეთ ბლოკი, backend და გვერდითი ზიანი
გადატვირთვის შემდეგ სტატუსის გამოსავალი ყველაზე სწრაფი დადასტურებაა, რომ jail არსებობს და ითვლის:
fail2ban-client status
fail2ban-client status openvpnas-tunnelშემდეგ დაადასტურეთ, რომ ბლოკი აღწევს იმ firewall-ს, რომელსაც ნამდვილად მართავთ, რადგან backend-ისთვის გაწყობილი jail, რომელსაც არავინ აღასრულებს, არაფერს იცავს. iptables მოქმედებისას მისამართები ჩნდება jail-ის სახელის მქონე ჯაჭვში (f2b-openvpnas-tunnel); nftables მოქმედებისას ისინი ხვდებიან fail2ban-ის საკუთარ ცხრილში არსებულ სიმრავლეში. შეამოწმეთ ის, რასაც თქვენი ჰოსტი იყენებს, ვიდრე ჩათვლით.
ორი გვერდითი შემოწმება თავად ბლოკზე მნიშვნელოვანია. პირველი, დაადასტურეთ, რომ real_ip კლიენტის მისამართია და არა დატვირთვის გამანაწილებელი ან უკუპროქსი; პროქსის უკან ყოველი ბლოკი პროქსიზე ვარდება და მთელ სერვისს თან მიაქვს. მეორე, ჩაწერეთ ბლოკის მოხსნის პროცედურა, რადგან 02:00-ზე ზღვარს გადამკვეთი მისამართი ჩვეულებრივ მორიგე ინჟინერს ეკუთვნის: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.
დაიმახსოვრეთ საზღვარი რეგულირებისას. Fail2ban არის სიჩქარის შემზღუდველი ერთ ავთენტიფიკაციის ზედაპირზე და არა წვდომის კონტროლის შრე. ის არ ცვლის MFA-ს, ანგარიშის მიხედვით შეზღუდვებს ან ადმინისტრირების ინტერფეისის საჯარო ინტერნეტიდან მოშორებას, და Access Server-ს აქვს საკუთარი autoban პარამეტრები, რომელთა შემოწმებაც ღირს სანამ ერთსა და იმავე პორტზე ორ სიჩქარის შემზღუდველს დააწყობთ.