Для нормальной работы сайта необходимо разрешить JavaScript, включая скрипты с доменов googlesyndication.com и doubleclick.net для отображения системы поиска по сайту и прочих сервисов Google.

Способы обхода Cloudflare защиты чтобы узнать реальный IP-адрес

bypass cloudflare to get real ipCloudflare является одной из популярных CDN сервисов, который также используется как обратный прокси для сайта, в результате чего реальный IP-адрес сайта неизвестен ибо скрыт за прокси-серверами Cloudflare.

Кто скрывает свои сайты за Cloudflare

Публика использующая обратный прокси для сайта от Cloudflare, в моём понимании, делится на три категории - это люди желающие защитить свой сайт от атак, правозащитники, и, мошенники скрывающиеся по понятным причинам.

В первом случае Cloudflare "защищает" не столько как от атак, как от самих пользователей выдавая при малейших подозрениях страницу с reCaptch-ей, а для некоторых категорий пользователей reCaptch-а является непреодолимой преградой - дополнительные материалы о reCaptch-е можно найти под меткой "Каптча" в конце статьи. Кроме того, поскольку Cloudflare является CDN севисом и "раскидывает" контент "защищаемого" сайта по серверам с разным географическим расположением, то число регулярных обращений к контенту сайта возростает со стороны самой CDN. Получается, что одно лечим, другое калечим.

Мошенники же за Cloudflare прячут своего реального хостинг-провайдера дабы уберечь как его так и себя от гневных мессаг на "abuse-mailbox:". Можно писать на "abuse-mailbox:" и в Cloudflare, но это намного затянет закрытие мошеннического сайта, а сам мошенник за это время сможет получить максимальный профит от своей деятельности.

О том, что предпринимается для защиты оригинального хоста сайта можно почитать в размещённой на blog.cloudflare.com статье DDoS Prevention: Protecting The Origin


Как выяснить реальный IP-адрес сайта скрытого за Cloudflare

Ни один из перечисленных ниже методов не гарантирует 100% верный результат.

При переходе на Cloudflare автоматически создаётся поддомен DIRECT.TARGET.HOST и если админ полнейшая лошара и не удалил его, то "пропинговав" или "пролукупив" его мы получим реальный ИП, а иначе читаем дальше и не унывая продолжаем долбить вражеский домен...

Метод 1: Публичные сервисы

Метод заключается в поиске информации о домене на различных сайтах сбора статистики.

Таких сервисов шо грязи и все их перечислить не реально. Метод практически бесполезный для доменов типа *.ru, *.ua, так как на многих даже предупреждается, что запросы только для доменов в зонах *.com, *.org, *.net ...

Метод 2: Анализ DNS записей MX и SPF

Получить назначенные домену MX и SPF записи можно командами:

$ nslookup -type=mx TARGET.HOST
$ nslookup -type=txt TARGET.HOST

Подсказка!

"nslookup-ить" всегда нужно сам домен TARGET.HOST, а не его поддомены типа WWW.TARGET.HOST

Некоторые "продвинутые" маскировщики могут использовать сторонние SMTP типа sendpulse.com и пр., а потому в подобных случаях данный метод окажется бесполезным если только админ не забыл удалить из SPF ИП своего реального сервера.

Ещё как вариант можно опросить ДНС-сервера доменного регистратора, ведь обычно при переключении ДНС-серверов на Cloudflare записи на ДНС-серверах доменного регистратора не удаляются, - сделать это можно командой: nslookup TARGET.HOST TARGET.NS Обнаружить ДНС регистратора можно выполнив whois REGISTRAR.HOST либо whois по домену зарегистрированного у того же регистратора - регистратор может предлагать ДНС на различных доменах не обязательно совпадающие с доменом регистратора REGISTRAR.HOST.

Метод 3: Использование разного рода сканеров

Например websploit

$ sudo apt-get install websploit
 
$ websploit
 
 --=[WebSploit Advanced MITM Framework
 +---**---==[Version :3.0.0
 +---**---==[Codename :Katana
 +---**---==[Available Modules : 20
 --=[Update Date : [r3.0.0-000 20.9.2014]
 
 
wsf > show modules
 
Web Modules Description
------------------- ---------------------
web/apache_users Scan Directory Of Apache Users
web/dir_scanner Directory Scanner
web/wmap Information Gathering From Victim Web Using (Metasploit Wmap)
web/pma PHPMyAdmin Login Page Scanner
web/cloudflare_resolver CloudFlare Resolver
 
 
Network Modules Description
------------------- ---------------------
network/arp_dos ARP Cache Denial Of Service Attack
network/mfod Middle Finger Of Doom Attack
network/mitm Man In The Middle Attack
network/mlitm Man Left In The Middle Attack
network/webkiller TCP Kill Attack
network/fakeupdate Fake Update Attack Using DNS Spoof
network/arp_poisoner Arp Poisoner
 
 
Exploit Modules Description
------------------- ---------------------
exploit/autopwn Metasploit Autopwn Service
exploit/browser_autopwn Metasploit Browser Autopwn Service
exploit/java_applet Java Applet Attack (Using HTML)
 
 
Wireless / Bluetooth Modules Description
------------------- ---------------------
wifi/wifi_jammer Wifi Jammer
wifi/wifi_dos Wifi Dos Attack
wifi/wifi_honeypot Wireless Honeypot(Fake AP)
wifi/mass_deauth Mass Deauthentication Attack
bluetooth/bluetooth_pod Bluetooth Ping Of Death Attack
 
 
wsf > use web/cloudflare_resolver
wsf:CloudFlare Resolver > show options
 
Options Value RQ Description
--------- -------------- ---- --------------
Target google.com yes Target Address
wsf:CloudFlare Resolver > set Target TARGET.HOST
TARGET => TARGET.HOST
wsf:CloudFlare Resolver > run
[-------------------------]
[+] Default IP Address : 104.20.35.24
[-------------------------]
[+] mail.TARGET.HOST : xx.xx.xxx.xx
[-] webmail.TARGET.HOST : N/A
[-] email.TARGET.HOST : N/A
[-] direct-connect-mail.TARGET.HOST : N/A
[-] direct.TARGET.HOST : N/A
[-] direct-connect.TARGET.HOST : N/A
...

Примерно того же результата можно достичь выполнив # nmap --script dns-brute -sn TARGET.HOST

Дополнительно из этой же серии можно потыкать:

Проверка IP-адреса на принадлежность его к исследуемому сайту

Значит, если мы обнаружили ИП не принадлежащие Cloudflare, то это ещё совсем не означает, хоть один из них является реальным ИП адресом сайта, который мы хотим рассекретить.

Первое, что можно сделать - это выполнить nslookup ИП адреса дабы проверить наличие обратной PTR записи, например

$ nslookup 78.41.200.153
Server: 127.0.0.1
Address: 127.0.0.1#53
 
Non-authoritative answer:
153.200.41.78.in-addr.arpa name = mx94.smtp-pulse.com.

Из ответа понятно, что ИП принадлежит стороннему smtp-серверу. Окончательно же убедится в реальности ИП адреса можно сопосавив его исследуемому домену в файле hosts:

# vi /etc/hosts
127.0.0.1    localhost
TARGET.IP    TARGET.HOST

После чего открыть TARGET.HOST в браузере, а если нет доступа к редактированию /etc/hosts, то можно использовать "Burp Suite Community Edition" при помощи которого профильтровать запросы веб-браузера в сеть подменяя все заголовки "Host: TARGET.IP" на "Host: TARGET.HOST" в браузере при этом открывая сам ИП по HTTP или HTTPS протоколу соответственно, - но перед этим не лишним будет убедится в наличии открытых самих портов 80/443.

Рекомендуемый контент



Добавить комментарий


Защитный код
Обновить

Рейтинг@Mail.ru 2 megabytes