Fail2ban VDS-ზე: jail-ები, ban-ები და დამტკიცება, რომ მუშაობს

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

ის ასევე რეგულარულად გადაჭარბებულად არის შეფასებული. Fail2ban ვერ აჩერებს განაწილებულ თავდასხმას, სადაც ყოველი მცდელობა სხვა მისამართიდან მოდის, ვერ აჩერებს volumetric flood-ს და თუ SSH-ზე პაროლით ავთენტიფიკაცია უკვე გამორთე, brute-force მცდელობები, რომლებსაც ის ბლოკავს, მაინც არასოდეს გაჭრიდა. დააყენე ის იმიტომ, რომ ლოგები იკითხება და CPU თავისუფალია და არა იმიტომ, რომ ის ყუთს უსაფრთხოს ხდის. SSH-ს უსაფრთხოს პაროლების გამორთვა ხდის, რაც სხვა პოსტია: SSH გასაღებები და გამაგრება.

როგორ მუშაობს სინამდვილეში#

სამი ნაწილი, და მათი გამიჯვნის გაგება ყოველ პრობლემას უფრო ადვილს ხდის.

Filter არის რეგულარული გამოსახულებების ნაკრები, რომელიც კონკრეტული ლოგის ფორმატში ჩავარდნას ცნობს. ისინი ცხოვრობს /etc/fail2ban/filter.d/-ში, თითო ფაილი სერვისზე, და დისტრიბუცია ათეულობით მათგანს აწვდის: sshd.conf, nginx-http-auth.conf, postfix.conf და ასე შემდეგ.

Jail filter-ს ლოგის წყაროსთან და რიცხვების ნაკრებთან აკავშირებს: რამდენი ჩავარდნა, რა ფანჯარაში და რამდენ ხანს გრძელდება ban. Jail-ები განსაზღვრულია /etc/fail2ban/jail.conf-ში და, რაც მნიშვნელოვანია, შენ მათ სხვაგან გადაფარავ.

Action არის ის, რაც ხდება, როცა jail გაისვრის. ნაგულისხმევი წერს iptables ან nftables წესს, რომელიც მისამართს იმ პორტებზე უარყოფს, რასაც jail ფარავს. Action-ები ცხოვრობს /etc/fail2ban/action.d/-ში და არსებობს ალტერნატივები, რომლებიც ufw-ს იძახებენ, ფოსტას აგზავნიან ან API-ს ეძახიან.

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

დაყენება და ერთადერთი ფაილი, რომელიც უნდა შეცვალო#

$ apt update && apt install fail2ban$ systemctl enable --now fail2ban$ fail2ban-client status

jail.conf-ს ხელი არ ახლო. ეს პაკეტის ფაილია, ყოველი განახლებისას იცვლება და შენი ცვლილებები ჩუმად ქრება. ნაცვლად შექმენი /etc/fail2ban/jail.local, რომელიც შემდეგ იკითხება და იმარჯვებს. ყველაფერი, რასაც jail.local-იდან გამოტოვებ, მიწოდებულ ნაგულისხმევზე ბრუნდება, ამიტომ ფაილში მხოლოდ ის უნდა იყოს, რასაც ცვლი.

[DEFAULT]bantime  = 1hfindtime = 10mmaxretry = 5ignoreip = 127.0.0.1/8 ::1 203.0.113.42# Ban for longer each time the same address comes back.bantime.increment = truebantime.maxtime   = 5w[sshd]enabled  = truemode     = aggressivemaxretry = 4bantime  = 2h

მიწოდებული ნაგულისხმევებია bantime = 10m, findtime = 10m და maxretry = 5. ათი წუთი მოთმინებიან scanner-ის წინააღმდეგ თითქმის დეკორატიულად მოკლეა, სწორედ ამიტომ არის უმეტესობის პირველი ცვლილება bantime.

bantime.increment არის პარამეტრი, რომელიც ცოდნად ღირს და რომელსაც ხალხი ტოვებს. მასთან, მისამართი, რომელიც პირველი ban-ის გასვლის შემდეგ თავს ისევ დაბანვინებს, ბანდება ორჯერ უფრო დიდხანს, შემდეგ ოთხჯერ, bantime.maxtime-მდე. ერთი ცნობისმოყვარე სტუმარი ერთი საათით გარეთაა; რაც კვირაობით ბრუნდება, ხუთით ბოლოვდება. ეს არაფერი ღირს და თითქმის მთელ სასარგებლო საქმეს აკეთებს.

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

sshd jail და ლოგი, რომელსაც ვერ პოულობს#

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

Fail2ban ტრადიციულად კითხულობს /var/log/auth.log-ს, რომელსაც rsyslog წერს. ბოლო დროის მინიმალური Debian და Ubuntu image-ები rsyslog-ს საერთოდ არ აყენებენ და ყველაფერი systemd journal-ში მიდის. ასეთ სისტემებზე sshd jail ვერ ეშვება და შეცდომა journalctl -u fail2ban-ში ლოგის დაკარგულ გზაზეა და არა იმაზე, რაც შენ გააკეთე. გამოსწორება ერთი ხაზია:

[sshd]enabled = truebackend = systemd

შეამოწმე, რომელ სიტუაციაში ხარ, სანამ დაუშვებ: ls -l /var/log/auth.log. თუ ფაილი არსებობს და იზრდება, ნაგულისხმევი file backend კარგია. თუ არ არსებობს, დააყენე backend = systemd და jail journal-ს პირდაპირ კითხულობს.

sshd filter-ის mode პარამეტრი დაყენებად ღირს. normal ჩვეულებრივ ავთენტიფიკაციის ჩავარდნებს ემთხვევა. aggressive ამატებს ავთენტიფიკაციამდე დახურული კავშირის ხაზებს და დეფექტური პაკეტების ხმაურს, რასაც scanner-ები წარმოქმნიან, რაც იჭერს bot-ებს, რომლებიც ცდიან პაროლის გაგზავნის გარეშე. სერვერზე, სადაც პაროლით ავთენტიფიკაცია უკვე გამორთულია, aggressive არის რეჟიმი, რომელიც რეალურად ვინმეს ბანავს, რადგან bot, რომელიც პაროლებს key-only daemon-ზე ცდის, კლასიკურ ჩავარდნის ხაზს არასოდეს წარმოქმნის.

Ban-ის დრო, find-ის დრო და რას ნიშნავს რიცხვები#

სამი რიცხვი განსაზღვრავს ქცევას და ისინი ისე ურთიერთქმედებს, რომ უკუღმა გაგება ადვილია.

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

გონივრული საწყისი რიცხვები სერვერისთვის, რომელშიც მხოლოდ შენ შედიხარ: maxretry = 4, findtime = 30m, bantime = 1h, ჩართული bantime.increment-ით. თუ ყუთს სხვებიც იყენებენ, პირველ დარღვევაზე უფრო მშვიდად იყავი და დაე increment დაისაჯოს, რადგან ერთადერთი ადამიანი, რომელიც მკაცრ jail-ს აუცილებლად ჩაუვარდება, კოლეგაა, რომლის ძველი გასაღები agent-შია.

არსებობს fail2ban-ის მეორე რიგის jail, რომლის ჩართვაც ღირს, როცა დანარჩენი მუშაობს, და მას თითქმის არავინ რთავს:

[recidive]enabled  = truebantime  = 1wfindtime = 1dmaxretry = 5

recidive jail კითხულობს fail2ban-ის საკუთარ ლოგს და ბანავს მისამართებს, რომლებმაც თავი ნებისმიერი სხვა jail-ის მიერ დღეში ხუთჯერ დაბანვინეს. ეს არის ყველაფრის დამჭერი, რაც ban-ის გასვლის შემდეგ ბრუნდება, და ფარავს მასპინძლებს, რომლებიც შენს სერვისებს შორის ნელა ტრიალებენ. მას სჭირდება, რომ /var/log/fail2ban.log არსებობდეს; თუ შენი install journal-ში წერს, ამ jail-ზეც დააყენე backend = systemd.

Jail-ები web სერვერისთვის#

თუ VDS-ზე nginx გაქვს, სამი მიწოდებული jail თავის ადგილს იმსახურებს. დაამატე ისინი jail.local-ში და ლოგის გზები შენს მოწყობას მოარგე.

[nginx-http-auth]enabled = truelogpath = /var/log/nginx/error.log[nginx-botsearch]enabled = truelogpath = /var/log/nginx/access.log[nginx-limit-req]enabled = truelogpath = /var/log/nginx/error.logmaxretry = 10findtime = 1m

nginx-http-auth იჭერს brute force-ს HTTP basic ავთენტიფიკაციაზე. nginx-botsearch ემთხვევა მოთხოვნებს ბილიკებზე, რომლებზეც scanner-ები ყოველთვის კითხულობენ, რაც WordPress საიტზე დღის განმავლობაში მუდმივი წვეთია. nginx-limit-req საინტერესოა: ის არაფერს აკეთებს, სანამ nginx-ის საკუთარ limit_req ზონებს არ გამართავ, შემდეგ კი კლიენტს, რომელიც rate limit-ს ურტყამს, "შეზღუდულიდან" "firewall-ზე დაბანილად" აქცევს, რაც მომსახურებისთვის გაცილებით იაფია.

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

თუ firewall-ისთვის ufw-ს იყენებ, მიუთითე fail2ban მასზე, რომ ორმა ხელსაწყომ ერთმანეთის კონკურენტი წესები არ ჩაწეროს:

[DEFAULT]banaction = ufw

სხვაგვარად fail2ban საკუთარ chain-ებს ufw-ს chain-ებამდე ამატებს, რაც მუშაობს, მაგრამ ორ ადგილას გტოვებს საძებნად, როცა მისამართი მოულოდნელად დაბლოკილია. Firewall-ის დანარჩენი ამბავი ufw firewall-ის გზამკვლევშია.

დამტკიცება, რომ მუშაობს#

გაუტესტავი fail2ban-ის install დამამშვიდებელი ნივთია. ოთხი შემოწმება, თანმიმდევრობით, და თითოეული სხვა კითხვას პასუხობს.

$ fail2ban-client status                     # which jails are running$ fail2ban-client status sshd                # counters and current bans$ fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf$ iptables -S | grep f2b                     # the rules that exist right now$ nft list ruleset | grep -i f2b             # on nftables systems

fail2ban-client status sshd ბეჭდავს ამჟამად ჩავარდნილებს, ჯამურად ჩავარდნილებს, ამჟამად დაბანილებს, ჯამურად დაბანილებს და დაბანილი მისამართების სიას. თუ ჯამური ჩავარდნები იზრდება, ხოლო ჯამური ban-ები ნულზე რჩება, filter ემთხვევა და რიცხვები ძალიან თავისუფალია. თუ ჯამური ჩავარდნები ნულზე ჩარჩა, ხოლო journalctl -u ssh მცდელობებს აშკარად აჩვენებს, filter ლოგს საერთოდ არ ემთხვევა, რაც თითქმის ყოველთვის არასწორი backend-ია ან არასწორი logpath.

fail2ban-regex არის ხელსაწყო, რომელიც საკითხს წყვეტს. მიუთითე მას რეალური ლოგი და filter ფაილი და ის გეტყვის, რამდენი ხაზი დაემთხვა, რამდენი იგნორირდა და რამდენის გარჩევა ვერ შეძლო. დაამატე --print-all-missed გამოტოვებული ხაზების სანახავად, რითიც გაიგებ, რომ შენი ლოგის ფორმატს აქვს დროის ნიშნული, რომელსაც ის არ ცნობს.

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

$ fail2ban-client set sshd unbanip 203.0.113.9$ fail2ban-client unban 203.0.113.9        # every jail at once$ fail2ban-client unban --all              # clear everything

რას ვერ გააკეთებს fail2ban შენთვის#

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

• განაწილებული მცდელობები გადის. Botnet-ი ათი ათასი მისამართით, თითო სამ მცდელობას რომ აკეთებს, არც ერთ მისამართზე maxretry-ს არასოდეს აღწევს. Fail2ban შექმნილია ერთი დაჟინებული scanner-ისთვის, რაც ტრაფიკის უმეტესობაა, მაგრამ ის მოთმინებიანი თავდამსხმელის წინააღმდეგ დაცვა არ არის.
• არაფერს აკეთებს volumetric flood-ების წინააღმდეგ. პაკეტები მაინც აღწევს, მაინც ხარჯავს შენს uplink-ს და მაინც უჯდება kernel-ს სამუშაო. ფილტრაცია შენს მანქანამდე უნდა მოხდეს, და DDoS თავდასხმები თამაშის სერვერებზე ახსნილი აღწერს, რა შეიძლება და რა არა.
• Docker პორტებს მას გვერდით ავლით აქვეყნებს. ეს დიდია. Container, გაშვებული -p 5432:5432-ით, მიიღწევა DOCKER-USER და FORWARD chain-ებით, ხოლო fail2ban-ის ნაგულისხმევი წესები INPUT-შია, ამიტომ ban container-ში მყოფ არაფერზე მოქმედებს. ან მიაბი container localhost-ს -p 127.0.0.1:5432:5432-ით, ან უთხარი action-ს ჩაწეროს სწორ chain-ში banaction = iptables-allports[chain=DOCKER-USER]-ით. Docker VDS-ზე ამ გაფრთხილების დანარჩენ ნაწილს შეიცავს.
• სუსტ პაროლს ვერ უშველის. ხუთი მცდელობა ბევრია, თუ პაროლი admin123-ია. Fail2ban გამოცნობის ფასს ზრდის; ის ამ ფასს ისე არ ზრდის, რომ ნამდვილად ცუდი საიდუმლოს წინააღმდეგ მნიშვნელობა ჰქონდეს.
• ის პაროლების გამორთვის შემცვლელი არ არის. PasswordAuthentication no-ით და key-only წვდომით, brute force, რომელსაც ბლოკავს, უკვე ჩავარდნილი იყო. ეს მაინც ღირს ლოგის ხმაურისა და CPU-ს გამო, მაგრამ ოპერაციების რიგთან პატიოსანი იყავი.

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

ყოველდღიური მუშაობა#

jail.local-ის ნებისმიერი ცვლილების შემდეგ restart-ის ნაცვლად reload გააკეთე, რომ არსებული ban-ები გადარჩეს:

$ fail2ban-client reload          # all jails$ fail2ban-client reload sshd     # one jail$ fail2ban-client get sshd bantime$ fail2ban-client set sshd banip 198.51.100.7$ journalctl -u fail2ban -n 50 --no-pager

Ban-ები ინახება პატარა SQLite ბაზაში /var/lib/fail2ban/fail2ban.sqlite3-ზე, ამიტომ სერვისის restart-საც და მანქანის გადატვირთვასაც გადაურჩება. იქვეა increment-ის ისტორიაც, რის გამოც განმეორებით დამრღვევი გადატვირთვებს შორისაც ინარჩუნებს მზარდ ban-ს.

თვეში ერთხელ შეხედე fail2ban-client status sshd-ს და შენი ავთენტიფიკაციის ლოგის ზომას. უეცარი ცვლილება ნებისმიერი მიმართულებით ინფორმაციაა: ლოგი, რომელიც გაჩუმდა, ჩვეულებრივ ნიშნავს, რომ rsyslog გაჩერდა ან jail გაფუჭდა და არა იმას, რომ ინტერნეტი თავაზიანი გახდა. იმ ჩვევას, გადაწყვიტო, რომელი ლოგები შეინახო და რამდენ ხანს, აღწერს ლოგები, რომლებიც ღირს შენახვა, ხოლო მათი სწრაფად წასაკითხი ბრძანებებია Linux ბრძანებები სერვერის ადმინებისთვის.

მართულ RE:NODE გეგმაზე fail2ban-ს არ აყენებ, რადგან არ არსებობს host shell, რომელზეც დააყენებდი. ეკვივალენტური დაცვა ჩაშენებულია: პანელი login-ზე captcha-სა და rate limit-ებს სვამს, პაროლის ჰეშებს bcrypt-ით ინახავს, გთავაზობს ორფაქტორიანს authenticator კოდებითა და ერთჯერადი recovery კოდებით, ინახავს სესიების სიას, საიდანაც შეგიძლია გამოხვიდე, და საშუალებას გაძლევს API გასაღებები მისამართით შეზღუდო. Upstream ფილტრაცია აშკარა volumetric flood-ებს node-მდე მისვლამდე აგდებს. VDS-ზე ეს ყველაფერი შენ უნდა აწყო, და fail2ban ერთი აგურია.

FAQ#

ანელებს fail2ban სერვერს?

შესამჩნევად არა. ეს არის Python პროცესი, რომელიც ლოგის ხაზებს კითხულობს, ჩვეულებრივ რამდენიმე ათეულ მეგაბაიტ მეხსიერებას და თითქმის არანაირ CPU-ს იყენებს. თავად ban-ები firewall წესებია, რომელთაც kernel მიკროწამებში აფასებს. ერთადერთი შემთხვევა, სადაც ეს საერთოდ ჩანს, არის jail უზარმაზარი ban სიით და ძალიან მოკლე findtime-ით დატვირთულ web ლოგზე.

რატომ აჩვენებს ჩემი sshd jail ნულ ჩავარდნას?

თითქმის ყოველთვის ლოგის წყაროა. შეამოწმე, არსებობს თუ არა /var/log/auth.log; rsyslog-ის გარეშე image-ებზე არ არსებობს და jail-ში backend = systemd გჭირდება. დაადასტურე fail2ban-regex-ით რეალურ ლოგზე, რომელიც ზუსტად გეტყვის, რამდენი ხაზი დაემთხვა.

დამბანავს, თუ პაროლს შევცდები?

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

საკმარისია fail2ban მარტო?

არა. ეს ერთი შრეა key-only SSH-ის, default-deny firewall-ის, ახალი პაკეტებისა და არაპრივილეგირებული სერვისის მომხმარებლების თავზე. ის ხმაურს აშორებს და ზარმაც თავდასხმებს აჩერებს. ყოველი სერიოზული კონტროლი სხვაგანაა და პირველი საათი ახალ VDS-ზე მათ თანმიმდევრობით ჩამოთვლის.

შეუძლია თამაშის სერვერის პორტის დაცვა?

მხოლოდ თუ თამაში ჩავარდნილი მცდელობების გასაშიფრ ლოგს წერს, რასაც უმეტესობა არ აკეთებს, და მხოლოდ კავშირზე დაფუძნებული ბოროტად გამოყენებისთვის და არა flood-ებისთვის. მისამართით ban-ი მოთამაშეებისთვის ცუდი არჩევანიცაა, რადგან ისინი მისამართებს იზიარებენ და იცვლიან. მოთამაშეებისთვის გამოიყენე თამაშის საკუთარი ban სია და RCON, ხოლო fail2ban დატოვე ადმინისტრაციული ინტერფეისებისთვის.

როგორ ვნახო ყველა ამჟამად დაბანილი მისამართი?

fail2ban-client status <jail> ბეჭდავს სიას ერთი jail-ისთვის. ახალი ვერსიებს აქვთ fail2ban-client banned-იც, რომელიც ყველა jail-ის სიას ერთდროულად ბეჭდავს. იმის სანახავად, რას ახორციელებს kernel რეალურად, iptables -S | grep f2b ან nft list ruleset.