Odoo 19 Community: Web RBL – შავი სია საკუთარ ვებსაიტებზე თავდასხმის ტრაფიკისთვის

წყაროს კოდი: github.com/Alex0176/odoo-web-rbl — AGPL-3, თავისუფლად გამოყენებადი.

ვინც Odoo-ს სერვერს ინტერნეტში მართავს, სტუმრებს იღებს. არა ხანდახან, არამედ შეუწყვეტლად. ჩვენს ხუთ ვებსაიტზე ჩვიდმეტი დღის განმავლობაში 731 297 მოთხოვნა ჩავიწერეთ და გავაანალიზეთ. მათგან 110 511 არ იყო სტუმარი, არამედ ავტომატიზებული ძიება დაუცველობების, წვდომის მონაცემებისა და კონფიგურაციის ფაილების შესახებ.

ეს პოსტი აღწერს Web RBL-ს, ღია წყაროს მოდულს Odoo 19 Community-ისთვის, რომელიც ამ ტრაფიკს ამოიცნობს, აფასებს, აღრიცხავს და უარყოფს — და რომელიც შავ სიას როგორც RBL-სიას აქვეყნებს, ანუ იმ ფორმატით, რომელსაც Firewall-ები და Reverse Proxy-ები პირდაპირ კითხულობენ. ყველა რიცხვი რეალური ექსპლუატაციიდანაა.

რას შეძლებს მოდული — ფუნქციების მიმოხილვა

ფუნქცია	რას აკეთებს	მიწოდება
შაბლონების ამოცნობა	ამოიცნობს ზონდირებას გზისა და გაფართოების მიხედვით: .env, .git, კონფიგურაციის ფაილები, Cloud-გასაღებები, CI/CD ასაწყობი ინსტრუქციები, WordPress, PHP, Path Traversal, მონაცემთა ბაზის მმართველი, GraphQL, ბრძანების შესრულება /api/fs/exec-ით და მსგავსი ინტერფეისებით	დაბლოკვა
სამი საფეხური თითო შაბლონზე	დაბლოკვა, დათვლა ან შეტყობინება — თითო შაბლონზე გადართვადი, კოდის გარეშე	თითო შაბლონზე
ზღვრები	ერთი და იმავე შაბლონის რამდენი დამთხვევა, სანამ დაიბლოკება; შესვლებისთვის ათი	10 შესვლისას
შესვლის დაცვა	წარუმატებელი შესვლები ფორმით და XML-RPC/JSON-RPC-ით, წარუმატებელი სესიის შემოწმებები, წვდომა მონაცემთა ბაზის მმართველზე — მონაცემთა ბაზაში და არა ოპერატიულ მეხსიერებაში	ჩართულია
ბოტების ამოცნობა შესვლისას	ვინც ათი წარუმატებელი მცდელობის შემდეგ მოლოდინის შეტყობინებას უგულებელყოფს და განაგრძობს კაკუნს, მაშინვე იბლოკება	დაბლოკვა
ქცევის ამოცნობა	მისამართები, რომლებიც ხუთ წუთში ოც არარსებულ გვერდს და ძლივს ერთ არსებულ გვერდს ქმნიან — ანუ ხვდებიან და არ კითხულობენ	შეტყობინება
შეფასება 0–100	რამდენად დარწმუნებულია, რომ მისამართის უკან თავდამსხმელი დგას? შაბლონის სიმძიმის, განსხვავებული შაბლონების რაოდენობის, მნიშვნელოვანი დღეების, დაზარალებული დომენებისა და დამთხვევათა რაოდენობის მიხედვით — დასაბუთებით მარტივი ტექსტით	ჩართულია
შესვლის დაბლოკვა შეფასების მიხედვით	დასარეგულირებელი შეფასებიდან შესვლა აკრძალულია, ვებსაიტი კი კითხვადი რჩება	40-დან
საეჭვო მოპარული წვდომის მონაცემები	საეჭვო მისამართიდან წარმატებული შესვლა დაფიქსირდება და სურვილის შემთხვევაში ამოცანად დაინიშნება — თითო მისამართზე დღეში ერთხელ	ჩართულია
საფრთხეების სიები	Tor-ის გამომავალი კვანძები, Spamhaus DROP, FireHOL Level 1, blocklist.de წინასწარ არის გამართული; ნებისმიერი სხვა RBL სია მისამართით ემატება, ყოველდღიური შედარება, თითოეულ სიას საკუთარი დონე აქვს	შეტყობინება
შესვლაზე წვდომა დახურულია	მეოთხე დონე სიებისა და ქვეყნებისთვის: ვებგვერდი იკითხება, შესვლის ფორმა და ინტერფეისები დახურულია — Tor-ის შესაფერისი პასუხი	არჩევითი
წარმოშობის ქვეყანა	ქვეყანა თითოეული დაფიქსირებისა და მისამართისთვის GeoLite2-ის მეშვეობით; მოდული მონაცემთა ბაზას უფასო სალიცენზიო გასაღებით თავად განაახლებს	ჩვენება
ქვეყნების წესები	დაბლოკვა, შესვლაზე წვდომის დახურვა, შეტყობინება ან პირდაპირ დაშვება — თითოეული ქვეყნისთვის, შეგნებულად ნაგულისხმევი მნიშვნელობის გარეშე	არცერთი
არასწორი კონფიგურაციები	QNAP, Synology, Exchange-Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV ამოიცნობა, არასდროს იბლოკება და დასკვნითა და შესაბამისი დომენის მითითებით სამუშაო სიაში ექცევა	შეტყობინება
თითო ბილეთი თითო მისამართზე	დასკვნიდან სურვილისამებრ იქმნება ბილეთი — ზუსტად ერთი თითო მისამართზე, დახურული ბილეთი ორმაგდება კი არა, ხელახლა იხსნება	გამორთულია
სავალდებულო გვერდები და მკრეფავები	კანონიკური იმპრესუმის გზა ყოველთვის ხელმისაწვდომია; უცხო დაწერილობების მანქანური გადარჩევა ამოიცნობა და სურვილის შემთხვევაში იბლოკება	შეტყობინება
თეთრი სია	მისამართები და ქსელები, რომლებიც არასდროს იბლოკება; ყოველდღიურად ივსება ბრანდმაუერიდან (VPN-ის მეორე მხარეები) და Googlebot-ისა და Bingbot-ის გამოქვეყნებული მისამართების დიაპაზონებიდან	ჩართულია
კლიენტის მინიჭება	კლიენტის ქსელიდან მიღებული დაფიქსირება მას ენიჭება — თეთრი სიიდან, არასდროს ხელით გამოცნობით	ჩართულია
დომენი და იდენტიფიკატორი თითო დაფიქსირებაზე	რომელ ვებგვერდს მიმართეს, რომელი User-Agent-ით — ორივე აკლია წვდომის ჟურნალს	ჩართულია
ანალიზი	დიაგრამა და პივოტი ყველა დაფიქსირებაზე: შაბლონის, დღის, დომენის, ქვეყნისა და მისამართის მიხედვით	ჩართულია
სატყუარა	ზონდები იღებენ გამოგონილ პასუხებს კანარის მნიშვნელობით; ვინც მას მოგვიანებით გამოითხოვს, ის წაიკითხა	გამორთულია
RBL-ის მიწოდება	ბლოკირების სია წმინდა მისამართების სიის ან JSON-ის სახით, ცალკე, ტოკენით დაცულ მისამართზე — HAProxy-ისთვის, OPNsense-ისთვის და ნებისმიერი ბრანდმაუერისთვის, რომელიც URL-სიებს კითხულობს	ჩართულია

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

ანალიზი: დაფიქსირებები შაბლონის მიხედვით შვიდი დღის განმავლობაში. ყველაზე მაღალი სვეტი .env ფაილების ძიებაა.

RBL სიები: ბლოკირების მიწოდების სტანდარტიზებული გზა

RBL ნიშნავს Real-time Blackhole List. ტერმინი ფოსტის სამყაროდან მოდის, სადაც Spamhaus და სხვები ოთხმოცდაათიანი წლებიდან აქვეყნებენ მავნე გამგზავნი მისამართების სიებს. პრინციპი უკიდურესად მარტივია და სწორედ ამიტომ ასე გავრცელებული: ერთი მისამართი თითო სტრიქონზე, HTTP-ით ხელმისაწვდომი, რეგულარულად ხელახლა ჩატვირთვადი. არანაირი ფორმატი, რომლის ანალიზიც ჯერ უნდა მოხდეს, არანაირი ინტერფეისი, რომლისთვისაც ხელსაწყო დაგჭირდებათ.

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

• OPNsense და pfSense — URL Table Alias: მისამართების სიის HTTP-ით ჩატვირთვა, ბრანდმაუერის წესებში ალიასად გამოყენება, განახლება საათობრივი ან დღიური რიტმით
• HAProxy — ACL-ფაილები და Maps: src -f sperrliste.txt http-request deny წესში, ხელახლა ჩასატვირთი გაშვების API-ით გადატვირთვის გარეშე
• nginx — geo მოდული ჩართული მისამართების ფაილით, ან deny დირექტივები გენერირებული include ფაილიდან
• Fortinet FortiGate — External Block List ანუ Threat Feed: ერთი URL, საიდანაც ბრანდმაუერი იღებს IP სიას და იყენებს პოლიტიკებში
• Palo Alto Networks — External Dynamic List (EDL): იგივე პრინციპი, უსაფრთხოების პოლიტიკებში ცალკე ობიექტის ტიპად
• Check Point — Custom Intelligence Feeds და IP Block Lists URL-ის მეშვეობით
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds საკუთარი სიების წყაროებით
• Sophos Firewall — Third-Party Threat Feeds: URL-დან მიღებული მისამართების სიები ბლოკირების წესების წყაროდ
• Juniper SRX — Dynamic Address Entries ფიდებიდან
• MikroTik RouterOS — Address Lists, სკრიპტითა და fetch-ით URL-დან შევსებული
• CrowdSec — საკუთარი სიები, როგორც წყარო bouncer-ებისთვის ყველა მხარდაჭერილ სისტემაზე

სწორედ ამ ფორმატით აწვდის Web RBL თავის ბლოკირების სიას. ბრანდმაუერი პაკეტებს უარყოფს, სანამ ისინი ვებსერვერამდე მიაღწევდნენ — და მათთან ერთად ამავე მისამართის ყველა სხვა მცდელობასაც, მაგალითად ფოსტის სერვერზე ან VPN გეითვეიზე.

ორივე მიმართულებით, მაგრამ სწორ ადგილას

გზა საპირისპირო მიმართულებითაც მუშაობს: Web RBL-ში შეიძლება ნებისმიერი RBL სიის ჩაწერა — ერთი URL, ერთი დონე, და მზადაა. Tor-ის გამომავალი კვანძები, Spamhaus DROP, FireHOL და blocklist.de წინასწარ არის გამართული, სხვები სამი დაწკაპუნებით ემატება. მოდული თითოეულ სიას მისამართების დიაპაზონებად შლის და თითოეულ მოთხოვნას მათთან ამოწმებს, რამდენიმე მიკროწამში.

და მაინც: უფრო გონივრულია, უცხო სიები ბრანდმაუერზე მანამდე გამოვიყენოთ. სამი მიზეზის გამო. ბრანდმაუერი ხედავს ყველა სერვისს, არა მხოლოდ HTTP-ს — Spamhaus-ის სიიდან მისამართი ფოსტის სერვერთანაც და VPN-თანაც უნდა დაბლოკილიყოს. ის პაკეტების დონეზე უარყოფს, სანამ კავშირი საერთოდ დამყარდება, და ამგვარად აპლიკაციის სერვერს არაფერი უჯდება. და ის ადგილია, სადაც ასეთი სიები ისედაც იწარმოება; აპლიკაციაში მეორე ასლი მეორე ადგილია, რომელიც შეიძლება მოძველდეს.

მაშ, რისთვის გამოდგება სიები მოდულში: იმისთვის, რისი კეთებაც ბრანდმაუერს არ შეუძლია. ის შესვლის ფორმას არ იცნობს. Web RBL-ს შეუძლია Tor-ის სიიდან მისამართს შესვლაზე წვდომა უარყოს და ვებგვერდი მაინც მიაწოდოს — ვისაც ანონიმურად წაკითხვა სურს, შეუძლია; ვისაც ანონიმურად პაროლების გადარჩევა სურს, არა. და მას შეუძლია სიაში მყოფი მისამართიდან წარმატებული შესვლა საეჭვო შემთხვევად შეატყობინოს. ორივეს სია სწორედ იმ ადგილას სჭირდება, სადაც შესვლა ხდება.

შეფასება და არა ინტუიცია

მისამართი, რომელმაც ერთხელ /wp-login.php მოითხოვა, სულ სხვაა, ვიდრე ის, რომელმაც ორი დღის განმავლობაში ხუთი განსხვავებული შაბლონით სამ დომენზე გაიარა. Web RBL ამას 0-დან 100-მდე შეფასებად გარდაქმნის — იმისგან, რაც თავად ნახა, უცხო სერვისისა და გარეთ გაგზავნილი მოთხოვნის გარეშე.

ერთი ჩანაწერი: 99 დაფიქსირება, შეფასება 84 და დასაბუთება მარტივი ტექსტით — ყველაზე მძიმე შაბლონი, ხუთი განსხვავებული სერიოზული შაბლონი, ორი საეჭვო დღე, ოცზე მეტი დაფიქსირება.

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

ბლოკირების სია, გაფილტრული 40-დან დაწყებული შეფასებით: დაფიქსირებების რაოდენობა, საეჭვო დღეები, ზემოქმედების ქვეშ მყოფი დომენები და თითოეული მისამართის ბოლო გზა.

რას იცავს Web RBL — დაცვის ეფექტი დეტალურად

1. წვდომის მონაცემები აღმოუჩენელი რჩება

გაზომილი ყველაზე დიდი თავდასხმის კლასი Odoo-ში ხარვეზებს არ ეძებს, არამედ დარჩენილ საიდუმლოებებს. ჩვიდმეტი დღის განმავლობაში:

• 57.721 მოთხოვნა .env ფაილებზე — იქ მონაცემთა ბაზის პაროლები, API გასაღებები და სესიის საიდუმლოებებია
• 5.535 მოთხოვნა კონფიგურაციის ფაილებზე
• 4.388 მოთხოვნა ღრუბლის წვდომის მონაცემებზე: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 მოთხოვნა .git დირექტორიებზე — ვინც ერთ-ერთს იპოვის, სრულ საწყის კოდს ისტორიასთან ერთად ჩამოტვირთავს
• 1.907 მოთხოვნა აგების ინსტრუქციებზე, როგორიცაა .github/workflows/deploy.yml ან .gitlab-ci.yml, სადაც რეესტრები და გასაღებების სახელებია მითითებული

გადამწყვეტი აქ მოთხოვნების რაოდენობა არ არის, არამედ განსხვავებული მისამართების რაოდენობა: /credentials.json მოვიდა 98 მისამართიდან, /.git-credentials — 92-დან. ეს არ არის ერთი სკანერი, არამედ სტანდარტული რეპერტუარი, რომელიც მთელ მსოფლიოში ერთდროულად მუშაობს.

2. შესვლის მცდელობები ცარიელში მიდის — სამუდამოდ

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

Web RBL იმავე ადგილებში ერთვება, მაგრამ მონაცემთა ბაზაში წერს. ამგვარად:

• მდგომარეობა გადაურჩება ყოველ გადატვირთვას და მოქმედებს ყველა სამუშაო პროცესზე
• აღირიცხება ორივე გზა: შესვლის ფორმა /web/login და ინტერფეისები /xmlrpc/2/common და /jsonrpc
• აღირიცხება ისეთი მცდელობებიც, რომლებიც პაროლის შემოწმებამდე არასდროს აღწევს — მაგალითად, შესვლები ვალიდური სესიის ნიშნის გარეშე
• მონაცემთა ბაზის მმართველთან წარუმატებელი წვდომაც ითვლება; ეს ყველაზე მძიმე შესვლის მცდელობაა

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

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

3. თავდასხმა სერვერს აღარაფერი უჯდება

ისეთ გზაზე ზონდი, როგორიცაა /@fs/../../.env, მოდულამდე ძვირი ჯდებოდა: Odoo ეძებს შეცდომის გვერდს, რენდერავს, მისამართის აგებისას წერტილოვან სეგმენტებზე წაიბორძიკებს და შედეგად შეცდომის გვერდის შეცდომის გვერდზეც ვერ ახერხებს. ორი სტეკის ჟურნალი თითო ზონდზე. გაიზომა 28.401 ასეთი შეცდომა ჩვიდმეტ დღეში, დამატებით 9.467 თანმდევი შეცდომა.

Web RBL ir.http._match-ში ერთვება, ანუ მარშრუტის პოვნამდე. პასუხი ყალიბის გარეშე, ბლოკირების შემოწმებას მიღმა მონაცემთა ბაზასთან წვდომის გარეშე და ჟურნალის სტრიქონის გარეშე გაიცემა. შემოწმება თეთრ სიასთან, საფრთხეების სიებთან და ქვეყნების წესებთან ქეშიდან სრულდება დახარისხებულ მისამართების დიაპაზონებზე — რამდენიმე მიკროწამში, ოცდაათ ათასზე მეტი დიაპაზონის შემთხვევაშიც.

4. ბრანდმაუერი თავდამსხმელს გამოაგდებს, სანამ ის მოვა

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

სამი დონე: დაბლოკვა, დათვლა, შეტყობინება

ცარიელში მოსული ყოველი მოთხოვნა თავდასხმა არ არის. Web RBL ამიტომ სამ დონეს არჩევს, და დონე თითოეული შაბლონისთვის შეიძლება შეიცვალოს კოდის შეხების გარეშე.

დონე	გამომწვევი მოთხოვნა	შედეგი მისამართისთვის
დაბლოკვა	უარყოფილია	დაბლოკილია 24 საათით, სამი საეჭვო დღის შემდეგ სამუდამოდ
დათვლა	გადის	მხოლოდ აღირიცხება, ბლოკირების გარეშე
შეტყობინება	გადის	აღირიცხება დასკვნის ტექსტით, არასდროს იბლოკება

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

რომელი თავდასხმები ამოიცნობა

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

თავდასხმის კლასი	მოთხოვნები	მისამართები
.env მოპოვება	57.721	223
PHP ზონდები	12.237	256
გზის გადაკვეთა (path traversal) ღირებული სამიზნით	10.046	64
კონფიგურაციის ფაილები	5.535	114
ღრუბლის წვდომის გასაღებები	4.388	152
WordPress ზონდები	3.366	385
.git მოპოვება	2.811	255
Odoo-ს დაზვერვა (მონაცემთა ბაზის მმართველი, ვერსიის მოთხოვნა)	2.500	213
AI ხელსაწყოთა ჯაჭვები და ბრძანებების შესრულება (/mcp, /api/fs/exec)	2.450	74
აგების ინსტრუქციები (CI/CD)	1.907	88
GraphQL endpoint-ები	1.878	71

აღსანიშნავია ყველაზე ახალი კლასი. /api/fs/exec მოითხოვეს 369-ჯერ 54 განსხვავებული მისამართიდან — ეს წაკითხვის წვდომა კი არა, ბრძანებების შესრულების მცდელობაა. ასეთი სამიზნეები ორი წლის წინ არ არსებობდა; ისინი ახალი AI ხელსაწყოებისა და ამოცანების რიგების ინტერფეისებიდან მოდის. ვინც თავის დაცვას მხოლოდ WordPress-ზე და PHP-ზე ამყარებს, ამას ვერ ხედავს. შეფასებაში ეს კლასი შესაბამისად მძიმედ ითვლება.

საფრთხეების სიები და წარმოშობის ქვეყანა

ოთხი სია, 32.851 მისამართების დიაპაზონი, ყველა „მხოლოდ შეტყობინებაზე“. ყოველი დამატებითი სია ერთი მისამართი და ერთი დონეა.

უცხო სია არის მტკიცება, რომელსაც სხვა ადამიანი ადგენს, ჩვენთვის უცნობი მიზეზებით, ისეთ ტრაფიკზე, რომელიც ჩვენ არასდროს გვინახავს. ის შეიძლება არასწორი იყოს, მოძველებული ან სხვა მიზნისთვის განკუთვნილი: blocklist.de ძირითადად აგროვებს მისამართებს, რომლებმაც სხვაგან SSH შესვლები გადაარჩიეს, და ეს ვებსერვერზე ცოტას ამბობს. ამიტომ Web RBL უცხო სიებს საკუთარი ბლოკირების სიისგან განცალკევებით ინახავს, და ამიტომაა ნაგულისხმევი შეტყობინება. და საკუთარი თეთრი სია ყოველთვის იმარჯვებს: კლიენტი, რომელსაც ვიცნობთ, მესამე პირის შეფასებაზე მძიმეა.

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

ქვეყნების წესები ცარიელი მიწოდდება, და ხედი ამბობს, რატომ.

არასწორი კონფიგურაციების შეტყობინება დაბლოკვის ნაცვლად

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

• 1.367 მიმართვა QNAP NAS-ის ვებ ინტერფეისზე — სინქრონიზაციის კლიენტი, რომლის სამიზნეც აღარ ემთხვევა. ერთი ერთადერთი კავშირი 962-ჯერ დააკაკუნა.
• 65 Autodiscover მოთხოვნა — Outlook, რომელიც ვებდომენს თავისი Exchange-ის დომენად თვლის

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

ამოიცნობა QNAP, Synology, Exchange-Autodiscover, ActiveSync და ასევე WebDAV, CalDAV და CardDAV კლიენტები. შაბლონები ასახელებენ ზუსტ ფაილების სახელებსა და დირექტორიებს, არასდროს მხოლოდ გაფართოებებს: იმავე /cgi-bin/ დირექტორიაში უწყინარი სინქრონიზაციის გამოძახებები კლასიკური ზონდების გვერდითაა, როგორიცაა printenv.pl.

თეთრი სია: მისამართები, რომლებიც არასდროს იბლოკება

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

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

ივსება ყოველდღიურად ორი წყაროდან: თავად ბრანდმაუერიდან ყველა VPN-ის მეორე მხარით, რათა ახლად გამართული გვირაბი იმაზე არ იყოს დამოკიდებული, რომ ვინმეს ბლოკირების სია ახსოვდეს — და Google-ისა და Microsoft-ის გამოქვეყნებული მისამართების დიაპაზონებიდან მათი კრაულერებისთვის. მხოლოდ ასე შეიძლება ნამდვილი Googlebot-ის გარჩევა სკანერისგან, რომელიც თავს ასე უწოდებს. საძიებო სისტემები არასდროს უნდა დაიბლოკოს; ვინც მათ გამორიცხავს, საკუთარ გვერდს ინდექსაციიდან უკან დაბრუნების გარეშე იღებს.

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

თუ თეთრი სიის ჩანაწერს კლიენტი უკავშირდება, მისი ქსელიდან ყოველი დაფიქსირება მას ენიჭება. არასწორ კონფიგურაციას ამგვარად მაშინვე ჰყავს საკონტაქტო პირი, ისე რომ ვინმეს მისამართების ძებნა არ დასჭირდეს.

სავალდებულო მონაცემები და ავტომატიზებული მონაცემთა მკრეფავები

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

ავსტრიაში Google-ის შრიფტების ჩართვის გამო გამოგზავნილი საპრეტენზიო წერილების ტალღისას ჟურნალებმა აჩვენა, რომ წერილები ერთეული ვიზიტებიდან არ მოდიოდა, არამედ ავტომატიზებული მასობრივი დარტყმიდან: სხვადასხვა, ერთმანეთთან დაუკავშირებელი ჰოსტები მილიწამების ინტერვალით.

Web RBL ამას გამონაკლისის ნაცვლად დაქვეითებით წყვეტს. კანონიკური გზა /impressum არცერთ შაბლონს არ ემთხვევა და ყოველთვის ხელმისაწვდომი რჩება. უცხო დაწერილობები, როგორიცაა /impressum.php — რომელიც Odoo-ს გვერდზე არ შეიძლება არსებობდეს — გადაიცემა შეტყობინებით, და ვისაც მანქანური მოსავლის აღების გაგრძელება არ სურს, ერთ პარამეტრს ცვლის. sitemap და robots გამონაკლისია და პრინციპულად არ იბლოკება: ისინი არ შეიცავენ პერსონალურ მონაცემს და მათი მიღება ყოველი საძიებო კრაულერის ამოცანაა.

დომენი და იდენტიფიკატორი: რაც წვდომის ჟურნალს აკლია

werkzeug-ის წვდომის ჟურნალი არც მიმართულ ჰოსტს წერს და არც გამომძახებლის იდენტიფიკატორს. Odoo, რა თქმა უნდა, ორივეს იღებს — ჰოსტის გარეშე ის რამდენიმე ვებგვერდის შემთხვევაში სწორს ვერც აირჩევდა. მაგრამ შემდეგ მის წაკითხვას ვეღარ შევძლებთ.

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

რამდენს წყვეტს იდენტიფიკატორი, აჩვენა ჩვენს ერთ-ერთ ვებგვერდზე ანალიზმა: მთელი ტრაფიკის სამოცდაათ პროცენტზე მეტი ერთ გამომძახებელზე მოდიოდა, ასზე მეტ მისამართზე გადანაწილებით. იდენტიფიკატორის გარეშე ეს განაწილებულ სკრეიპერს დაემსგავსებოდა. ეს იყო GPTBot, OpenAI-ის კრაულერი — ის განუწყვეტლივ ითხოვდა robots.txt-ს და სრულიად სწორად იქცეოდა.

უსაფრთხოების ასპექტები დეტალურად

1. პროქსის ამოცნობა — საერთოდ ყველაზე სახიფათო ადგილი

თუ Odoo reverse proxy-ს უკან მუშაობს და proxy_mode არასწორადაა დაყენებული, მოდული ყოველ მოთხოვნაზე ერთსა და იმავე მისამართს ხედავს: პროქსის მისამართს. მაშინ ბლოკირება ყველა ვიზიტორს ერთდროულად გამორიცხავდა.

ამიტომ Web RBL ყოველ ბლოკირებამდე ამოწმებს, საიმედოა თუ არა მისამართის განსაზღვრა. ის მოითხოვს proxy_mode-ს გადამისამართების სათაურთან ერთად, არ მუშაობს, თუ გადამისამართება proxy_mode-ის გარეშე მოდის, და ასევე უარს ამბობს ერთზე მეტი შუალედური პროქსის შემთხვევაში. ეჭვის შემთხვევაში არ იბლოკება.

2. საკუთარი ქსელები არასდროს

კერძო მისამართების დიაპაზონები, loopback, link-local და CGNAT მყარად გამორიცხულია. ისინი არავითარ შემთხვევაში არ შეიძლება სიაში მოხვდნენ, ხელითაც კი. იგივე ეხება უცხო სიებს: კერძო და რეზერვირებული დიაპაზონები, ასევე აბსურდულად დიდი ქსელები წაკითხვისას გაუქმდება.

3. საკუთარმა შეცდომამ ვებგვერდი თან არ უნდა წაიღოს

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

4. დაკვირვება ბლოკირებამდე

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

5. ვიწრო შაბლონები ფართო ქსელების ნაცვლად

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

6. ხელით გაცემული დაშვება ძალაში რჩება

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

7. სია დაცულია, მაგრამ საიდუმლო არ არის

Endpoint მოითხოვს ტოკენს და ვალიდური ტოკენის გარეშე პასუხობს 404-ით და არა 403-ით — მისამართის არსებობა ამგვარად საერთოდ არ დასტურდება. შედარება მუდმივ დროში სრულდება. თავად სია არაფერ კონფიდენციალურს არ შეიცავს: ის მისამართებისგან შედგება, რომლებმაც თავისით დაგვიკაკუნეს.

8. არანაირი საიდუმლო აღრიცხვაში

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

9. სატყუარა არაფერ გამოსადეგს არ ამჟღავნებს

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

რას ვერ აკეთებს მოდული

ის ბრანდმაუერს და Web Application Firewall-ს არ ცვლის. ის ცნობს ცნობილ გამოძიების შაბლონებს გზებში, წარუმატებელ შესვლებს და საეჭვო ქცევას — არა თავდასხმებს ფორმებზე, არა პარამეტრებში შეჭრის მცდელობებს.

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

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

ხელმისაწვდომობა

Web RBL AGPL-3-ით საჯაროდ არის ხელმისაწვდომი და ჩვენთან პროდუქციულად მუშაობს ხუთ ვებგვერდზე:

github.com/Alex0176/odoo-web-rbl

მოდული საჭიროებს Odoo 19 Community-ს და base-სა და web-ის გარდა დამოკიდებულებები არ აქვს. ბილეთების სისტემასთან დაკავშირება არჩევითია და რაიმე კონკრეტულ ბილეთების სისტემას არ საჭიროებს; ასეთის გარეშე უბრალოდ არაფერი ხდება. წარმოშობის ქვეყანას MaxMind-ის უფასო GeoLite2 მონაცემთა ბაზა სჭირდება; თუ ის არ არის, ველი ცარიელი რჩება და ყველაფერი დანარჩენი უცვლელად მუშაობს.

დამატებით: როგორ ჯდება Web RBL სრულ უსაფრთხოების არქიტექტურაში -- ბრანდმაუერთან, ორფაქტორიან ავთენტიფიკაციასთან და უფლებებთან ერთად, ეტაპობრივი ინსტრუქციით: Odoo 19 უსაფრთხოების არქიტექტურის სწორად შეხამება.

კითხვებს, შენიშვნებსა და შეცდომების შესახებ ანგარიშებს სიამოვნებით მივიღებთ — უპირატესად GitHub-ზე Issue-ს სახით.