fail2ban՝ brute-force հարձակվողների ban ըստ log-երի

01Գաղափարը՝ անվտանգության աշխատակից, որը կարդում է հյուրերի գրքույկը

Պատկերացրու ակումբի անվտանգության աշխատակցի, որը մի քանի վայրկյանը մեկ ստուգում է գրանցամատյանը։ Եթե նույն մարդը տասը րոպեում հինգ անգամ սխալ գաղտնաբառ է փորձել, նրան մեկ ժամով մուտքը մերժվում է։ Դա fail2ban-ն է։ Տեխնիկապես այն Python daemon է, որը հետևում է log ֆայլերին կամ systemd journal-ին, յուրաքանչյուր նոր տող համեմատում է regular expression-ների հետ, հաշվում է համընկնումները ըստ IP հասցեի, և երբ շեմը հատվում է, գործարկում է action, սովորաբար ավելացնելով firewall կանոն (nftables, iptables կամ ufw), որը դեն է նետում հարձակվողի packet-ները։ Ban-ի ժամանակից հետո այն հեռացնում է կանոնը։ Սա կոչվում է log-based intrusion prevention․ այն ինքը traffic-ը չի զննում, այլ արձագանքում է նրան, ինչ քո ծառայություններն արդեն log են անում։ Դա այն դարձնում է թեթև և ծառայությունից անկախ․ ցանկացած բան, որը ձախողումները log է անում IP-ով, կարելի է պաշտպանել։

02Jail-եր, filter-ներ և action-ներ

fail2ban-ը կառուցված է երեք մասից։ Filter-ը (filter.d/*.conf) regular expression-ների հավաքածու է, որոնք ճանաչում են ձախողումը log տողում և <HOST> tag-ով բռնում են host-ը։ Action-ը (action.d/*.conf) ասում է, թե ինչ անել ban-ի և unban-ի ժամանակ՝ firewall կանոններ, Cloudflare API call, email։ Jail-ը միավորում է դրանք՝ որ log-ը կարդալ, որ filter-ն ու action-ն օգտագործել և շեմերը։ Շեմերը երեք թիվ են։ maxretry-ն այն է, թե քանի ձախողում է trigger անում ban։ findtime-ը այն պատուհանն է, որի ընթացքում այդ ձախողումները պետք է տեղի ունենան։ bantime-ը այն է, թե որքան է տևում ban-ը։ bantime.increment-ով կրկնվող խախտողները ամեն անգամ ավելի երկար ban են ստանում։ Recidive jail-ը գնում է ավելի հեռու․ այն հետևում է fail2ban-ի սեփական log-ին և օրերով ban է անում այն IP-ները, որոնք անընդհատ ban են ստանում։ Երբեք մի խմբագրիր jail.conf-ը, որը թարմացումները վերագրում են․ կարգավորումներդ դիր jail.local-ում կամ jail.d/*.local-ում։

• maxretry = 5, findtime = 10m, bantime = 1h-ը խելամիտ սկզբնակետ է։
• ignoreip-ը թույլ չի տալիս, որ քո գրասենյակի կամ VPN-ի հասցեները երբևէ ban ստանան։
• Ubuntu 24.04-ում և ավելի նորերում sshd jail-ը կարդում է systemd journal-ը (backend = systemd), ոչ թե /var/log/auth.log-ը։

03Գործնական jail.local SSH-ի և nginx-ի համար

Այս կոնֆիգուրացիան պաշտպանում է SSH-ը և nginx-ի տարածված դեպքերը՝ օգտագործելով fail2ban-ի հետ եկող filter-ները։ nginx-http-auth-ը բռնում է ձախողված basic-auth login-ները, nginx-botsearch-ը բռնում է bot-երին, որոնք պահանջում են հայտնի exploit ճանապարհներ, որոնք վերադարձնում են 404, իսկ nginx-limit-req-ը ban է անում client-ներին, որոնք անընդհատ հարվածում են nginx-ի rate limit-ին (աշխատում է միայն այն դեպքում, եթե կարգավորել ես limit_req)։ Recidive-ը մշակում է համառ հարձակվողներին։ Ubuntu-ում տեղադրիր apt install fail2ban-ով․ փաթեթն արդեն միացնում է sshd jail-ը jail.d/defaults-debian.conf-ի միջոցով nftables action-ով։ Խմբագրելուց հետո գործարկիր fail2ban-client reload և ստուգիր status-ը։ Եթե օգտագործում ես ufw և նախընտրում ես ban-երը տեսնել ufw status-ում, փոխարենը սահմանիր banaction = ufw։

1# /etc/fail2ban/jail.local
2[DEFAULT]
3bantime  = 1h
4findtime = 10m
5maxretry = 5
6bantime.increment = true
7ignoreip = 127.0.0.1/8 ::1 203.0.113.10
8 
9[sshd]
10enabled  = true
11backend  = systemd
12maxretry = 3
13 
14[nginx-http-auth]
15enabled = true
16[nginx-botsearch]
17enabled = true
18[recidive]
19enabled  = true
20bantime  = 1w
21findtime = 1d

04Սեփական filter-ի գրում

Կարող ես պաշտպանել ցանկացած բան, որը log է անում ձախողումները։ Տարածված օրինակ՝ Laravel կամ Next.js կայք, որը անընդհատ ստուգվում է WordPress login էջերի և արտահոսած .env ֆայլերի համար։ Այդ request-ները երբեք օրինական չեն ոչ WordPress կայքի վրա, ուստի դրանցից մի քանիսը ուժեղ ազդանշան են։ Ստորև filter-ը համընկնում է այդպիսի request-ների հետ nginx-ի access log-ում (լռելյայն combined ձևաչափ, որտեղ client-ի IP-ն առաջին դաշտն է)։ Նոր filter-ը միացնելուց առաջ միշտ ստուգիր այն fail2ban-regex-ով իրական log-ի վրա․ այն ցույց է տալիս, թե քանի տող համընկավ, և բռնում է regex-ի սխալներ, որոնք ոչ ոքի ban չէին անի կամ բոլորին ban կանեին։ Եթե կայքը Cloudflare-ի կամ այլ proxy-ի հետևում է, նախ կարգավորիր nginx-ի real_ip մոդուլը, այլապես log-ը պարունակում է proxy-ի IP-ն, և դու ban կանես proxy-ն։

1# /etc/fail2ban/filter.d/nginx-probe.conf
2[Definition]
3failregex = ^<HOST> -.*"(GET|POST|HEAD) /(wp-login\.php|xmlrpc\.php|\.env|\.git/)
4ignoreregex =
5 
6# /etc/fail2ban/jail.d/nginx-probe.local
7[nginx-probe]
8enabled  = true
9port     = http,https
10logpath  = /var/log/nginx/access.log
11maxretry = 2
12bantime  = 1d
13 
14# Test before enabling
15sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-probe.conf

05Ստուգում, unban և debug

fail2ban-client-ը կառավարման գործիքն է։ status-ը ցույց է տալիս ակտիվ jail-երը, status-ը jail-ի անվամբ ցույց է տալիս ընթացիկ ձախողումները և ban արված IP-ները, իսկ set jail unbanip-ը հեռացնում է ban-ը (օրինակ՝ երբ գործընկերը չափազանց հաճախ սխալ է մուտքագրել իր գաղտնաբառը)։ fail2ban-ի log-ը՝ /var/log/fail2ban.log-ը, գրանցում է յուրաքանչյուր ban և unban jail-ի անվամբ, և դա առաջին տեղն է նայելու, երբ ինչ-որ մեկն ասում է, որ իր մուտքն արգելափակված է։ Եթե jail-ը երբեք ոչինչ ban չի անում, ստուգիր երեք բան․ jail-ն իսկապես միացված է (status-ը ցուցակում է այն), այն կարդում է ճիշտ աղբյուրը (log path կամ systemd backend), և filter-ն իսկապես համընկնում է տողերի հետ (fail2ban-regex)։ Եթե այն ban է անում, բայց traffic-ը դեռ գալիս է, action-ը կարող է չհամապատասխանել քո firewall-ին, կամ traffic-ը գալիս է proxy-ի միջով, որի IP-ն հարձակվողինը չէ։

1sudo fail2ban-client status                 # list active jails
2sudo fail2ban-client status sshd            # failures and banned IPs for one jail
3sudo fail2ban-client banned                 # all banned IPs, per jail
4sudo fail2ban-client set sshd unbanip 203.0.113.10
5sudo fail2ban-client unban 203.0.113.10     # remove from every jail
6sudo fail2ban-client reload                 # apply config changes
7sudo tail -f /var/log/fail2ban.log
8sudo nft list ruleset | grep -A3 f2b        # see the firewall rules it created

06Սահմանափակումներ, և fail2ban ընդդեմ CrowdSec-ի

fail2ban-ը հարձակումները տեսնում է միայն այն բանից հետո, երբ դրանք հայտնվում են log-ում, և յուրաքանչյուր IP-ն գնահատում է առանձին։ Հազարավոր հասցեներից բաշխված հարձակումը, որտեղ յուրաքանչյուրը փորձում է մեկ կամ երկու անգամ, երբեք չի հատում շեմը։ Այն ոչինչ չի անում քո հավելվածի խոցելիությունների դեմ, և սերվերի firewall-ում ban-ը չի օգնում, երբ traffic-ը գալիս է CDN proxy-ի միջով, որովհետև միացումը գալիս է CDN-ից․ այնտեղ քեզ պետք է action, որը արգելափակում է edge-ում (fail2ban-ը գալիս է Cloudflare action-ներով), կամ CDN-ի սեփական WAF կանոնները։ Այնպես որ դիտարկիր այն որպես աղմուկի նվազեցում իրական վերահսկողությունների վրա՝ միայն SSH key-եր, default-deny firewall, rate limit-եր nginx-ում և առջևում Cloudflare-ի նման WAF։ CrowdSec-ը ժամանակակից այլընտրանքն է․ այն log-երը parse է անում նմանատիպ ձևով, բայց հայտնաբերումն առանձնացնում է արգելափակումից (bouncer-ներ firewall-ի, nginx-ի կամ Cloudflare-ի համար) և ազդանշանները կիսում է իր համայնքի հետ, այնպես որ ուրիշների վրա հարձակվող IP-ն կարող է արգելափակվել, մինչև կհասնի քեզ։ Այն ավելի հզոր է՝ ավելի շատ շարժվող մասերով և online բաղադրիչով։

07Engine-ի ներսում. backend-ներ, ամսաթվեր և ban database

Յուրաքանչյուր jail ունի backend, որը մատակարարում է log-ի նոր տողերը։ systemd-ն ուղիղ կարդում է journal-ը և ֆիլտրում ըստ unit-ի, ինչը ժամանակակից Ubuntu-ին պետք է SSH-ի համար։ Պարզ ֆայլերի համար auto-ն փորձում է pyinotify և հետ է ընկնում polling-ի։ Յուրաքանչյուր տող պետք է պարունակի timestamp, որը fail2ban-ը ճանաչում է. այն օգտագործում է log-ի ժամանակը, ոչ թե տողը կարդալու ժամանակը, որոշելու համար, թե արդյոք ձախողումն ընկնում է findtime-ի մեջ։ Սխալ datepattern-ը կամ timezone-ի անհամապատասխանությունը ձախողումները հին են ցույց տալիս, և jail-ը լուռ երբեք չի ban անում։ Ban-երը պահվում են SQLite database-ում՝ /var/lib/fail2ban/fail2ban.sqlite3, ուստի վերականգնվում են restart-ից կամ reboot-ից հետո։ dbpurgeage-ը, լռելյայն մեկ օր, որոշում է, թե որքան ժամանակ է պահվում ban-երի պատմությունը։ Սա կարևոր է recidive-ի և incremental ban-երի համար. եթե ձեր recidive findtime-ը մեկ շաբաթ է, իսկ պատմությունը մաքրվում է մեկ օրից, կրկնվող խախտողները երբեք չեն ճանաչվում։ fail2ban.local-ում dbpurgeage-ը բարձրացրեք ձեր ամենաերկար findtime-ից ավելի։

1# /etc/fail2ban/fail2ban.local
2[Definition]
3dbpurgeage = 8d      # must be longer than recidive findtime
4 
5# Check which date format and lines a filter matches
6sudo fail2ban-regex systemd-journal sshd
7sudo fail2ban-regex --print-all-missed /var/log/nginx/access.log nginx-probe

08Incremental ban-եր. կրկնվող խախտողների պատժում

Ֆիքսված մեկժամյա ban-ը bot-ին սովորեցնում է վերադառնալ վաթսունմեկ րոպեից։ bantime.increment-ով fail2ban-ը ստուգում է, թե որքան հաճախ է հասցեն նախկինում ban արվել, և բազմապատկում է ban-ը։ Լռելյայն բանաձևն այն ամեն անգամ կրկնապատկում է (ban time-ը բազմապատկած երկուսի ban count աստիճանով), ուստի 1h-ը դառնում է 2h, 4h, 8h և այլն. bantime.multipliers-ը թույլ է տալիս փոխարենը տալ բացահայտ հաջորդականություն։ bantime.maxtime-ը սահմանափակում է աճը, որպեսզի սխալը իրական օգտատիրոջը ամիսներով դուրս չթողնի, իսկ bantime.rndtime-ը ավելացնում է պատահական հավելում, որպեսզի bot-երը չկարողանան ճշգրիտ հաշվարկել unban-ի պահը։ bantime.overalljails = true-ն հաշվում է նախորդ ban-երը բոլոր jail-երից, ոչ միայն ընթացիկից. հասցեն, որը երեկ ստուգում էր nginx-ը, այսօր ստանում է ավելի երկար SSH ban։ Մշտական պատմության հետ միասին սա հաճախ առանձին recidive jail-ը դարձնում է ավելորդ, թեև երկուսն էլ պահելը վնաս չունի։

1# /etc/fail2ban/jail.local
2[DEFAULT]
3bantime  = 1h
4bantime.increment   = true
5bantime.factor      = 1
6bantime.maxtime     = 1w
7bantime.rndtime     = 10m
8bantime.overalljails = true
9# alternative to the formula:
10# bantime.multipliers = 1 2 4 8 16 32 64

09Action-ներ մասշտաբում. nftables set-եր, IPv6 և edge

Հին iptables action-ները յուրաքանչյուր ban արված հասցեի համար ավելացնում էին մեկ կանոն, և յուրաքանչյուր փաթեթ անցնում էր այդ ցուցակով, ինչը հազարավոր ban-երի դեպքում դանդաղում է։ Debian-ի և Ubuntu-ի օգտագործած nftables action-ները հասցեները դնում են set-ի մեջ inet f2b-table-ի ներսում, ինչը hash lookup է՝ անկախ չափից, և մեկ աղյուսակում ընդգրկում է IPv4-ը և IPv6-ը։ allports տարբերակը արգելափակում է բոլոր port-երը, ինչն օգտակար է recidive-ի համար, իսկ multiport-ը արգելափակում է միայն jail-ի port-երը։ IPv6-ը մտածել է պահանջում. fail2ban-ը ban է անում առանձին հասցեներ, բայց մեկ հարձակվողը կարող է վերահսկել ամբողջ /64 և պարզապես փոխել հասցեները։ Սա ևս մեկ պատճառ է, որ իրական պաշտպանությունը մնան rate limit-ները և միայն key-երով SSH-ը։ Cloudflare-ի հետևում HTTP-ի համար cloudflare-token action-ը Cloudflare API-ի միջոցով scope արված token-ով ստեղծում է zone access rule, ուստի արգելափակումը տեղի է ունենում edge-ում, որտեղ տրաֆիկն իրականում հասնում է։ Համատեղեք այն լոկալ action-ի հետ, որպեսզի SSH-ը և ուղիղ origin-ին ուղղված հարցումները դեռ արգելափակվեն սերվերում։

1# See the nftables sets fail2ban maintains
2sudo nft list table inet f2b-table
3 
4# jail.d/nginx-probe.local: block locally and at Cloudflare
5[nginx-probe]
6action = %(action_)s
7         cloudflare-token[cfzone="your_zone_id", cftoken="your_scoped_token"]

10Ֆիլտրեր, որոնք հնարավոր չէ չարաշահել

Ֆիլտրը չվստահված տեքստը վերածում է firewall կանոնների, ուստի այն անվտանգության սահման է։ Log-երը հաճախ պարունակում են հարձակվողի վերահսկած դաշտեր. username, URL, User-Agent։ Եթե regex-ը anchor արված չէ, հարձակվողը կարող է զոհի IP հասցեն դնել այդպիսի դաշտի մեջ և ստիպել ձեզ ban անել այդ զոհին, օրինակ՝ ձեր payment provider-ին կամ մոնիթորինգի ծառայությանը։ Log injection-ի այս ռիսկի պատճառով է, որ առաքվող ֆիլտրերը anchor են արվում տողի ֆիքսված կառուցվածքի վրա և <HOST>-ը capture են անում միայն այնտեղ, որտեղ ծառայությունն ինքն է գրում client-ի հասցեն։ Custom ֆիլտրերի կանոններ. anchor արեք ^-ով և համընկեք log-ի ճշգրիտ ձևաչափին, host-ը capture արեք այն դաշտից, որը վերահսկում է ձեր սերվերը, pattern-ը պահեք կոնկրետ մեկ ձախողման իմաստի համար և խուսափեք nested greedy wildcard-ներից, որոնք դանդաղ են երկար տողերում։ Հայտնի լավ տրաֆիկի, օրինակ՝ health check-երի համար օգտագործեք ignoreregex։ Միացնելուց առաջ թեստավորեք fail2ban-regex-ով մեկ շաբաթվա իրական log-երի վրա և նայեք և՛ համընկած, և՛ բաց թողնված տողերին։