Cloudflare-ის უკან დამალული ყალბი სასტუმროების საიტების აღმოჩენა: ტექნიკური მეთოდები

ასობით ყალბი სასტუმროს საიტის ანალიზისას ჩვენს წინაშე წარმოდგენილი სურათი ძალიან ნათელი იყო: ამ საიტების ოთხმოც პროცენტზე მეტი Cloudflare CDN-ის (Content Delivery Network) უკან იყო განთავსებული. ეს არჩევანი შემთხვევითი არ არის; Cloudflare მალავს რეალური სერვერის IP მისამართს, რაც მნიშვნელოვნად ართულებს takedown (წაშლის) პროცესებს.

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

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

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

როდესაც საიტი Cloudflare-ის პროქსის უკან იმალება, გარედან განხორციელებული ნებისმიერი DNS მოთხოვნა მხოლოდ Cloudflare-ის IP მისამართებს აჩვენებს. რეალური სერვერის IP არ ჩანს. ეს ართულებს როგორც წაშლის მოთხოვნებს, ისე ჰოსტინგ კომპანიის იდენტიფიცირებას.

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

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

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

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

ამის ტექნიკური მიზეზი შემდეგია: SMTP (ელ.ფოსტის) ტრაფიკი Cloudflare-ის პროქსის მეშვეობით ვერ გადამისამართდება. "mail.yalbisaite.com" ან "smtp.yalbisaite.com"-ის მსგავსი ქვედომენები პირდაპირ ფოსტის სერვერთან უნდა იყოს დაკავშირებული. როდესაც ამ ქვედომენზე DNS მოთხოვნა კეთდება, რეალური IP მისამართი პირდაპირ ჩანს.

ჩვენს მიერ აღმოჩენილ ერთ-ერთ შემთხვევაში, მთავარი დომენი სრულად Cloudflare-ის დაცვის ქვეშ იყო, ხოლო "info." ქვედომენი პირდაპირ მიუთითებდა აღმოსავლეთ ევროპაში მდებარე სერვერზე. იმავე სერვერზე 17 სხვადასხვა ყალბი ჯავშნის საიტი იყო განთავსებული.

ქვედომენების სკანირებისთვის გამოიყენება ისეთი ინსტრუმენტები, როგორიცაა Sublist3r, Amass და Subfinder. ეს ინსტრუმენტები ამოწმებენ დომენისთვის გავრცელებულ ქვედომენების სახელებს და ადგენენ, რომელი მათგანი მიუთითებს რეალურ IP-ზე.

• mail., smtp., imap., pop., mx., webmail. (ელ.ფოსტის ინფრასტრუქტურა)
• ftp., sftp. (ფაილების გადაცემა)
• cpanel., whm., plesk., direct-admin. (ჰოსტინგის პანელები)
• api., backend., admin., portal. (აპლიკაციის ფენები)
• dev., staging., test., beta. (განვითარების გარემოები)

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

SecurityTrails და ViewDNS.info-ს მსგავსი პასიური DNS მონაცემთა ბაზები ინახავენ დომენის მიერ წარსულში გამოყენებულ IP მისამართებსა და nameserver-ის ჩანაწერებს. ამ არქივების დათვალიერებისას, შეიძლება გამოჩნდეს Cloudflare-ზე გადასვლამდე გამოყენებული რეალური სერვერის IP.

ჩვენი ერთ-ერთი კლიენტის გამოცდილებით, მას შემდეგ, რაც გვაცნობეს, რომ ყალბი საიტი Cloudflare-ზე გადავიდა, მხოლოდ სამი დღე იყო გასული. SecurityTrails-ში ჩატარებულმა ძიებამ გამოავლინა გადასვლამდე გამოყენებული ორი სხვადასხვა IP მისამართი. ამ IP-ებიდან ერთი კვლავ აქტიურად ემსახურებოდა რამდენიმე ყალბ საიტს.

CT log-ებში არა მხოლოდ დომენის სახელით, არამედ ზოგჯერ IP-ზე დაფუძნებული ძიებაც შეიძლება. ზოგიერთი სერვერი საკუთარი პირდაპირი IP მისამართებისთვისაც იღებს SSL სერტიფიკატს.

IP მისამართის აღმოჩენის შემდეგ crt.sh-ში შეიძლება მოიძიოთ ამ IP-სთან დაკავშირებული სერტიფიკატების ჩანაწერები. ამ ძიებამ შეიძლება გამოავლინოს იმავე ინფრასტრუქტურაზე არსებული სხვა ყალბი საიტები.

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

Certificate Transparency log-ების შესახებ მეტი ინფორმაციისთვის, გირჩევთ, გაეცნოთ ჩვენს სტატიას Certificate Transparency Log-ის მონიტორინგი.

Shodan არის საძიებო სისტემა, რომელიც მუდმივად სკანირებს ინტერნეტთან დაკავშირებულ მოწყობილობებსა და სერვერებს. როდესაც IP მისამართი Shodan-ში იძებნება, შეიძლება გამოჩნდეს ამ სერვერზე მომუშავე პროგრამული უზრუნველყოფის ვერსიები, ღია პორტები, სერვისის სათაურები (HTTP response headers) და ბანერის ინფორმაცია.

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

• სერვერის კუთვნილი ჰოსტინგ კომპანიის დადგენა (ASN ინფორმაცია)
• იმავე სერვერზე განთავსებული სხვა საიტების აღმოჩენა
• სერვერის პროგრამულ უზრუნველყოფაში ცნობილი უსაფრთხოების ხარვეზების აღნიშვნა (takedown განცხადებებში დამხმარე მტკიცებულებად)

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

ზოგიერთი ვებ სერვერი, არასწორი კონფიგურაციის გამო, "/server-status" ან "/server-info"-ს მსგავს ენდფოინთებზე დეტალურ სერვერის ინფორმაციას ავრცელებს. ამ ხარვეზის მქონე სერვერებზე, შეიძლება ჩამოთვლილი იყოს ამ სერვერის მიერ გამოყენებული ყველა ვირტუალური ჰოსტის (virtual host) სახელი.

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

ასეთი ხარვეზების აღმოსაჩენად არ არის საჭირო თითოეული URL-ის ხელით შემოწმება. ავტომატურ ინსტრუმენტებს შეუძლიათ ამ ენდფოინთების სწრაფად დასკანერება.

რეალურ IP მისამართამდე მიღწევა takedown პროცესს აკონკრეტებს:

პირდაპირი საჩივარი ჰოსტინგ კომპანიასთან: IP-ის კუთვნილი ჰოსტინგ კომპანია შეიძლება დადგინდეს ASN ძიებით (bgp.he.net ან ipinfo.io-ს მსგავსი ინსტრუმენტებით). ჰოსტინგ კომპანიის abuse ელ.ფოსტის მისამართზე შეიძლება გაიგზავნოს DMCA შეტყობინება ან ბოროტად გამოყენების საჩივარი.

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

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

ყველა ვებ სერვერი HTTP პასუხებში სხვადასხვა სათაურის (header) ინფორმაციას აგზავნის. ამ სათაურებს შორის შეიძლება იყოს სერვერის პროგრამული უზრუნველყოფის, სამუშაო გარემოს ან ჰოსტინგის ინფრასტრუქტურის შესახებ მინიშნებები.

განსაკუთრებით საყურადღებო სათაურები:

• Server: Apache, Nginx, LiteSpeed-ის მსგავსი სერვერის პროგრამული უზრუნველყოფა; ზოგჯერ ვერსიის ინფორმაციასაც შეიცავს
• X-Powered-By: PHP ვერსია, ASP.NET ვერსიის მსგავსი სამუშაო გარემოს ინფორმაცია
• CF-Cache-Status: Cloudflare-ის ქეშის სტატუსი — ამოწმებს, ნამდვილად Cloudflare-ის უკან არის თუ არა საიტი
• Set-Cookie: ზოგიერთი ჰოსტინგ პლატფორმა cookie-ს სათაურში საკუთარ კვალს ტოვებს (cPanel, Plesk და ა.შ.)

ამ სათაურების შესამოწმებლად შეიძლება გამოყენებულ იქნას ბრაუზერის დეველოპერის ინსტრუმენტები (F12 → Network ჩანართი). ასევე შესაძლებელია curl ბრძანების გამოყენებით სათაურების ნედლი ფორმატით ნახვა.

ჩვენი ერთ-ერთი კლიენტის გამოცდილებით, "X-Powered-By: PHP/7.4" და სპეციალური session cookie-ს ფორმატმა შესაძლებელი გახადა ჰოსტინგის პროვაიდერის იდენტიფიცირება. ეს კომბინაცია კონკრეტული ჰოსტინგ კომპანიის თითის ანაბეჭდს ატარებდა და პირდაპირ ამ კომპანიასთან abuse შეტყობინების გაგზავნა გახდა შესაძლებელი.

ყალბი სასტუმროების საიტები რეალობის აღქმის შესაქმნელად ზოგჯერ ფუნქციურ ელ.ფოსტის მისამართებსაც იყენებენ. "[email protected]"-ის მსგავსი ელ.ფოსტის მისამართებიანი საკონტაქტო გვერდები ყალბ საიტს ლეგიტიმურ იერს აძლევს.

ამ ელ.ფოსტის მისამართის MX (Mail Exchange) ჩანაწერის ძიებამ შეიძლება გამოავლინოს ფოსტის სერვერის IP მისამართი. MXToolbox-ით ან dig ბრძანებით შესრულებული MX ძიება აჩვენებს, სად არის გადამისამართებული ფოსტის ტრაფიკი. ფოსტის სერვერი უმეტესად Cloudflare-ის პროქსის უკან არ არის და რეალურ IP მისამართს ამხელს.

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

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

1. DNS ისტორიის ძიება (SecurityTrails): არსებობს თუ არა Cloudflare-მდე IP?
2. ქვედომენის სკანირება: mail., smtp., ftp., admin.-ის მსგავსი ქვედომენები პირდაპირ IP-ზე მიუთითებენ?
3. MX ჩანაწერის ძიება: სად მიდის ფოსტის სერვერის IP?
4. CT log-ის კვლევა: არსებობს თუ არა ნაპოვნი IP-სთვის სხვა სერტიფიკატების ჩანაწერები? შეიძლება თუ არა იმავე ოპერატორის სხვა საიტების აღმოჩენა?
5. Shodan-ის სკანირება: IP-ზე მომუშავე პროგრამული უზრუნველყოფისა და ინფრასტრუქტურის ინფორმაცია
6. HTTP header-ის ანალიზი: ჰოსტინგ პლატფორმის მინიშნებები

ამ ნაკადის ერთ ყალბ საიტზე გამოყენებისას, საშუალოდ 45-90 წუთს ვხარჯავთ; თუმცა, შედეგები უმეტესად არა მხოლოდ ამ საიტთან, არამედ მთელ ყალბ ოპერაციასთან დაკავშირებით სრულყოფილ ინფორმაციას გვაწვდის.

ხშირად დასმული კითხვა: რატომ აგრძელებს Cloudflare ამ ყალბი საიტებისთვის მომსახურების გაწევას?

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

Abuse შეტყობინებების განხილვისას, Cloudflare ეძებს:

• კონკრეტულ ფიშინგის მტკიცებულებას (გადახდის ფორმა, ყალბი ჯავშნის ეკრანი და ა.შ.)
• ბრენდის დარღვევის დოკუმენტს (სავაჭრო ნიშნის რეგისტრაცია ან ბრენდის მფლობელობის ნათელი მტკიცებულება)
• დაზარალებულთა განცხადებებს (მომხმარებელთა საჩივრები, რომლებიც ადასტურებენ დაზარალებას)

სექტორის ექსპერტები აღნიშნავენ, რომ მაღალი ხარისხის დოკუმენტაციის მქონე შეტყობინებების შემთხვევაში, Cloudflare-ის მომსახურების შეწყვეტის გადაწყვეტილება 3-7 დღეში მოდის. სუსტი ან ბუნდოვანი დოკუმენტაციის მქონე შეტყობინებების შემთხვევაში, პროცესი შეიძლება გაგრძელდეს ან უშედეგოდ დასრულდეს.

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

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

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

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

რეალური IP-ის აღმოჩენის ეტაპზე DNS ისტორიის კვლევის გარდა, CT log-ის მონიტორინგიც ძლიერი დამატებითი ტექნიკაა. ამ სახელმძღვანელოში შეგიძლიათ გაიგოთ, როგორ აკონტროლოთ თქვენი სასტუმროს სახელზე გაცემული ყველა SSL სერტიფიკატი Certificate Transparency log-ების მეშვეობით. დამატებით, SecurityTrails და Shodan პლატფორმები IP-ის აღმოჩენაში ხშირად გამოყენებული უფასო რესურსებია.

კანონიერია თუ არა Cloudflare-ის უკან დამალული საიტის აღმოჩენა? დიახ. პასიური DNS ძიება, CT log-ის კვლევა და არქივის სკანირება სრულიად კანონიერი ტექნიკებია. ეს მეთოდები საჯაროდ ხელმისაწვდომ მონაცემებს იყენებს. სისტემაში უნებართვო პირდაპირი წვდომა ან თავდასხმის ხასიათის ქმედებები არ არის კანონიერი; თუმცა, ამ სახელმძღვანელოში აღწერილი მეთოდები ამ კატეგორიაში არ შედის.

რომელია Cloudflare-ის გვერდის ავლის ყველაზე სწრაფი მეთოდი? DNS ისტორიის კვლევა (SecurityTrails, PassiveDNS) და CT log-ის ძიება (crt.sh) უმეტეს შემთხვევაში რამდენიმე წუთში იძლევა შედეგს. საიტის სპეციფიკური ქვედომენები ან ძველი ელ.ფოსტის სათაურებიც შეიძლება სწრაფად უზრუნველყონ IP-ის აღმოჩენა. ზუსტი თანმიმდევრობა არ არსებობს, მაგრამ ამ ორი მეთოდის ერთად გამოყენება წარმატების მაჩვენებელს მნიშვნელოვნად ზრდის.

რა ინფორმაციას გვაწვდის Shodan-ი? Shodan-ი სკანირებს ღია პორტებს და ჩამოთვლის კონკრეტულ IP მისამართზე მომუშავე სერვისებსა და ბანერის ინფორმაციას. ის აჩვენებს, რომელ ქვეყანაშია IP, რომელ ჰოსტინგ პროვაიდერს იყენებს და ღია ვებ სერვისებს. ეს ინფორმაცია ჰოსტინგ პროვაიდერისთვის Abuse შეტყობინების მომზადებისას კონკრეტული ტექნიკური მტკიცებულების ფუნქციას ასრულებს.

შეიძლება თუ არა takedown-ის დაწყება რეალური IP-ის გარეშე? დიახ. მაშინაც კი, თუ რეალური IP უცნობია, შეიძლება გაკეთდეს ICANN-ის საჩივარი დომენის რეგისტრატორთან და ფიშინგის შეტყობინება Cloudflare-თან. თუმცა, ჰოსტინგ პროვაიდერთან პირდაპირი განცხადების გასაკეთებლად და უფრო სწრაფი შედეგის მისაღებად, IP-ის აღმოჩენა მნიშვნელოვან უპირატესობას იძლევა. დომენის დონეზე takedown-ი და რეალური IP-ის მქონე სერვერის დახურვა ერთმანეთის შემავსებელი ორი სტრატეგიაა.

გამოიყენეთ RuuSafe-ის ავტომატური სკანირების ინსტრუმენტი თქვენი სასტუმროს ყალბი საიტების Cloudflare-ის უკან დამალული რეალური ინფრასტრუქტურის აღმოსაჩენად. პირველი სკანირება უფასოა და რამდენიმე წუთში იძლევა შედეგს.