как узнать http сервер

Как узнать http сервер

Добрый день, уважаемые читатели, иногда бывают такие ситуации, что вам понравился сайт, он очень быстро открывается и вы хотели бы понять на каком веб сервере он организован. Для реализации данной задачи, вам не потребуется ничего кроме браузера, я использую для этих целей Google Crome, но вы можете использовать любой, удобный для вас. Особенно данная информация подойдет для начинающих веб мастеров.

Режим разработчика

Для выполнения нашей задачи мы будем пользоваться режимом разработки, который присутствует в каждом браузере. Например в Google Chrome он вызывается нажатием на клавишу F12. Я его недавно использовал, когда делал переход с php 5 на php 7. Выбираете любой сайт и нажимаете F12. Выбираем пункт Network > Headers. Затем находим нужную страницу. Щелкнув по ней у вас откроется дополнительное окно в котором есть поле X-Powered By. В данном случае сайт работает на PHP 5.2.17.

Вот вам пример IIS сервера, он называется ASP.NET.

Еще мне нравится использовать сервис http://checkmy.ru/ он так же позволяет вбив в адресную строку, получить информацию о веб сервисе. Как видите, тут да же показывается версия IIS.

Как определить CMS сайта

Если он не показывает движок, то сайт разработан на самописной CMS. Вот вам пример Joomla.

Так же можно определить движок и через код, для этого откройте любой сайт и нажмите сочетание клавиш CTRL+U, у вас откроется текстовая страница, с кодом данного сайта. Элементарным поиском можно проверить наличие слов, например Joomla.

Если говорить про WordPress, то там вы сможете так же найти его упоминание, хотя большинство вебмастеров убирают упоминания о версии и движке, но если вы хоть немного знакомы со структурой WordPress, то с легкостью сможете его определить. Поищите такую конструкцию в ссылках wp-content/ это сто процентов каталог WordPress.

Если вы знаете еще какие либо способы пишите в комментариях.

Источник

Как узнать какой сервер на хостинге Apache или Nginx

Существует несколько простых способов выяснить, какой веб-сервер установлен на вашем хостинге. В их основе лежит просмотр заголовков HTTP-запроса посредством различных сервисов или вручную. Чаще всего поиски данной информации заканчиваются тем, что пользователь сталкивается с такими вариантами ответа: Nginx или Apache – одни из самых популярных и хорошо зарекомендовавших себя проектов, предоставляющих в совокупности до 50% веб-трафика, который гонится на сайт.

Следовательно, в этом материале мы разберем упомянутые веб-сервера. Данное руководство будет полезно всем пользователям, которые сталкиваются с этим вопросом впервые.

Важно! Радикальных различий между Nginx и Apache не существует, но все-таки приходится говорить об отличительной обработке соединений.

Вернемся к тому, как узнать тип веб-сервера на хостинге, и какие сервисы станут наилучшими помощниками для этих целей.

Определяем руками, просмотр HTTP заголовков

В этом варианте будем использовать сам браузер и инструменты разработчика CTRL+ SHIFT +I.

В качестве браузере, рассмотрим на примере Google Chrome.

Шаг 1. В браузере Google Chrome открываем сайт, у которого требуется узнать веб-сервер.

Шаг 3. Заходим на вкладку network (сеть), затем перезагружаем сайт.

В столбце «Name» находим название сайта, в моем случае это vseprolinux.ru.

Кликаем левой кнопкой мыши.

В появившемся окне справа в headers ищем слово «server».

Это и есть веб-сервер, который используется на сайте.

Bertal

Предлагаем вашему вниманию еще один надежный сервис, посредством которого можно посмотреть HTTP-заголовки веб-файлов различных форматов. Чтобы воспользоваться инструментов, пользователю необходимо перейти по ссылке. Если размер интернет-страницы Несколько интересных фактов о популярных веб-серверах

Заключение

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

Источник

Статья Пентест веб приложений: определение веб-сервера, изучение robots.txt, определение приложений на веб-сервере.

Представленные выше серверы являются самыми популярными на 2019 год. Все остальные вместе взятые веб-серверы, названия которых исчисляются десятками, используются менее чем в 1% веб-приложений.
Актуальную статистику можно посмотреть тут.

Эта информация может быть получена путем отправки определенных команд на веб-сервер и анализа ответов от него, поскольку разные версии серверов могут по-разному реагировать на эти команды. Обратите внимание, что для точной идентификации веб-сервера обычно требуется отправить несколько разных команд, поскольку разные версии могут одинаково реагировать на одну и ту же команду. Редко разные версии реагируют одинаково на все команды HTTP. Таким образом, отправляя несколько разных команд, тестер может строить более точные предположения.

Рассмотрим следующий HTTP-запрос:

Как видим, в заголовке Server указан Apache.

Запрос-ответ на другой сервер:

На этот раз заголовок Server отдает больше информации. Видим, что версия Apache 2.4.12 и операционная система FreeBSD.

Обратите внимание, что на сервер LiteSpeed кроме заголовка Server явно указывает заголовок X-Litespeed-Cache-Control.

Google Web Server (gws)

Однако, данный способ помогает не всегда. У админа сервера есть возможность изменить значение заголовка Server, не показывать его вообще и другими способами скрыть версию веб-сервера. К примеру мы можем получить такой ответ:

Тут поставщика сервера по заголовку определить невозможно.

Более совершенные методы основаны на различных особенностях поведения веб-серверов. Например, каждому веб-серверу свойственно устанавливать свой порядок HTTP-заголовков в ответе.
Еще раз посмотрите на все примеры, приведенные выше. В примере с nginx заголовок Server является первым, и расположен перед заголовком Date. В примере c Apache заголовок Server располагается вторым по порядку, после заголовка Date, точно так, как в примере, где сервер мы не смогли определить. И точно так, как в примере с Netscape-Enterprise/6.0. Пример Netscape-Enterprise/3.5-For-NetWare по порядку заголовков похож на nginx/1.12.2.

Так реагирует Apache:

Посмотрите, как по разному реагирует один и тот же сервер на неправильный и правильный запросы:

Так отреагировал на неверный запрос наш неизвестный зверь Unknown-Webserver. От него приходят два ответа:

Реакция LiteSpeed на несуществующую версию протокола HTTP/3.0):

На несуществующий протокол JUNK/1.0 LiteSpeed ответит иначе:

Анализируя полученную информацию, сравнивая ее с известными ответами различных серверов, пентестер строит и уточняет свои предположения.

Не обязательно использовать Netcat. Править HTTP-запросы и смотреть ответы сервера можно средствами браузера:

Сервер codeby.net спрятан за cloudflare.

Само собой, что для получения тех же самых результатов существуют автоматизированные инструменты.
Например whatweb, который по умолчанию предустановлен в Kali:

Если вы по какой-то причине не хотите напрямую связываться с целевым сервером, можете использовать онлайн-сервисы, к примеру 2ip.ru:

Бывает, что ни один из рассмотренных способов не принес нужного результата. В таком случае вам могут помочь страницы об ошибках в веб-приложении, которые в себе могут раскрывать информацию о сервере.

Они могут быть такими (Tengine/2.0.0):

и даже такими (Apache/2.4.18):

На последнем скрине видим, что раскрывается не только информация о версии сервера, но так же мы узнали версию используемого фреймворка и путь до корня веб-сервера.

Файл robots.txt используется для того, что бы поисковые роботы и сканеры знали, какие веб-страницы можно индексировать, а какие нет.
Для примера файл robots.txt Google.com:

Такой файл имеется в большинстве веб-приложений и иногда может содержать в себе важную для тестера информацию, например, пути к административным интерфейсам. Кроме того, иногда в robots.txt указаны расширения файлов, которые нельзя (или можно) индексировать, что указывает на возможность наличия таких файлов на сервере.

Определение веб-приложений на сервере.

На следующем шаге нам необходимо выяснить, какие конкретно приложения размещены на веб-сервере. Многие веб-приложения имеют уязвимости, которые давно стали достоянием общественности, и которые можно использовать для получения удаленного доступа к серверу и другим приложениям, размещенным на том же сервере. Кроме того, некоторые приложения, которые предназначены для «внутреннего использования», часто плохо сконфигурированы и редко обновляются.

Например, имеется коммерческий сайт, на первый взгляд вполне «ухожен», да еще и IT-направленности. На домене аж четвертого уровня находим веб-приложение, написанное на языке Perl, расположенное на том же самом сервере, что и целевой сайт. Похоже, что админ чувствовал себя в безопасности, располагая на данном веб-сервере такое приложение, так как оно не планировалось для использования широким кругом лиц.
Хочется предупредить таких админов — это ложное чуство безопасности, по-другому называемое Security through obscurity.

Найденное приложение оказалось уязвимым к Ditectory Traversal и Local File Include. На скриншоте видно подключение файла /etc/passwd и вывод его содержимого в браузер:

В прилжении были найдены и другие уязвимости. Например можно просматривать некоторые директории и файлы этого приложения через браузер:

Обратите внимание на файл «password»:

C этим паролем заходим в админку, а в админке есть возможность заливать произвольные файлы на сервер (в том числе исполняемые):

Оцените важность этапа разведки в тестировании на этом примере.

Как искать веб-приложения на сервере?
Для начала рассмотрим точки, где они могут находиться.

1. Неочевидные URL.
Очевидной точкой входа для веб-приложения является Example Domain. Но хотя это самая распространенная ситуация, ничто не заставляет приложение запускаться именно со слэша «/».
Например, одно и то же доменное имя может быть связано с тремя веб-приложениями, такими как:
http://www.example.com/url1,
http://www.example.com/url2,
http://www.example.com/url3.

2. Нестандартные порты.
Хотя веб-приложения обычно работают на портах 80 (http) и 443 (https), это вовсе не обязательно. Фактически, веб-приложения могут работать на любых TCP-портах и на них можно ссылаться, указав номер порта следующим образом: http://www.example.com:20000/

3. Виртуальные хосты.
DNS позволяет связать один ip-адрес с несколькими доменными именами.
Например, IP-адрес 192.168.1.100 может быть связан с именами www.example.com, helpdesk.example.com, webmail.example.com. Не обязательно, чтобы все имена принадлежали одному домену example.com. Такой подход используется в виртуальном хостинге, который позволяет множеству сайтов располагаться на одном веб-сервере.

Теперь рассмотрим способы поиска приложений.

На самом деле не существует способа точно определить все веб-приложения на сервере. Например url1 в адресе http://www.example.com/url1 может быть непредсказуемым и вы никогда о нем не узнаете. Однако существует ряд методов, которые можно использовать для получения допольнительной информации.
К примеру, если веб-сервер неправильно сконфигурирован и позволяет листинг директорий прямо в браузере, как в примере ниже:

в этом примере каждая директория является входом в самостоятельное веб-приложение.

Так же могут помочь поисковые системы. Укажите в поисковом запросе поиск по сайту:

Можно выполнить поиск вручную или по словарю с помощью сканеров по вероятным адресам для почты, административной панели, старой версии сайта и т.д. Пример для поиска почтового сервиса:
https://www.example.com/webmail, https://webmail.example.com/ или https://mail.example.com/

Учтите обратную систуацию — веб-приложения с одним доменом, но разными поддоменами, могут располагаться на разных серверах.

Для поиска приложений на нестандартных портах воспользуйтесь сканером nmap:

Тут на портах 8000 и 8080 распологаются http-службы.
При переходе по адресу в браузере на порту 8000 сервер запрашивает http-get-авторизацию, а на порту 8080 какой-то сайт.

Желательно сканировать весь диапозон портов.

Другие примеры. На порту 20000 расположилась веб-почта, а на порту 8080 phpMyAdmin:

В следующем примере показано, как идентифицировать серверы имен для yandex.ru с помощью команды host:

Теперь мы попробуем запросить записи для yandex.ru на одном из его серверов DNS, и если нам повезет, сервер нам вернет этот список записей:

Можно попробовать выполнить обратный DNS-запрос. Отправляем IP, получаем имя:

Тоже самое в nslookup:

Вы можете воспользоваться онлайн сервисами, такими, как 2ip.ru или ipinfo.io. Часто подобные службы возвращают частично разные или неполные данные, поэтому лучше использовать несколько таких сервисов.

Как только вы определили все веб-приложения, не спешите их взламывать. Создайте список найденных приложений, вы к нему еще вернетесь. Определите, какие приложения принадлежат одному владельцу, а какие разным; Используются те же технологии, что и на целевом сайте, или другие; Находятся ли приложения с одинаковым доменом на одном и том же сервере, или на разных.

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

Источник

7 способов определить хостера сайта

Периодически перед многими из вебмастеров возникает задача определить хостера, у которого живет тот или иной сайт. Мотивация для этого бывает самая разная, как простое любопытство, так и желание поселиться по соседству на хорошем и стабильном хостинге или наоборот не вляпаться в такое соседство. В этом посте я приведу несколько известных мне методов с их достоинствами и недостатками. Вполне возможно, что он неполон, поэтому дополнения всячески приветствуются.
Так же «на берегу» оговорюсь: все упомянутые ниже сайты и хостеры упомянуты исключительно как наглядные примеры, и ни в коем случае не в качестве рекламы или, упаси господи, антирекламы. Выбор оных был сделан так же практически случайно — где какие методы у меня в свое время срабатывали, то и привожу.

Способы я перечисляю в порядке убывания точности и, к сожалению, в порядке возрастания вероятности срабатывания.

1. NS-сервера

Плюсы

Минусы

2. Ошибка 403/404

Не могу сказать, что большинство, но немало серьезных хостеров страницы ошибок веб-сервера по умолчанию делают с информацией о себе, а многие их клиенты забывают/ленятся их переопределить. Поэтому в первую очередь стоит попытаться вызвать такую ошибку и посмотреть, что получится. Бывает так, что CMS на сайте при помощи mod_rewrite перехватывает запросы к несуществующим файлам и отдает в ответ свою 404-ю ошибку. Это можно попробовать обойти, вызвав ошибку 403 путем обращения к какталогу без индексного файла. Им может быть папка с картинками/шаблонами, папка для загруженных файлов, кэша движка, системная папка типа includes и т. п. Небольшой хинт — иногда на странице ошибки есть email вебмастера и часто из него можно узнать домен сайта хостера.

Пример

Сайт: sloger.net
Cтраница с 404 ошибкой.
Результат: Хостер Hostgator

Плюсы

Минусы

3. Виртуалхост по умолчанию.

Здесь ситуация во многом аналогична предыдущей — крупные хостеры как правило на виртуалхост по умолчанию ставят свои заглушки, мелкие часто этим пренебрегают и виртуалхостом по умолчанию как правило становится либо первый сайт первого их клиента, либо стандартная заглушка от панели управления (особенно часто это наблюдается в случае с cpanel). Кстати, при первом раскладе есть приятный частный случай, состоящий в том, что иногда первым сайтом первого клиента становится сайт самого хостера и поэтому прием все же дает желаемый результат.
Самый надежный способ попасть на виртуалхост по умолчанию — это обратиться к веб-серверу по IP.

Пример

Плюсы

Минусы

4. Reverse DNS Lookup

Не вдаваясь в подробности скажу, что для любого IP адреса можно с помощью PTR записи в DNS-зоне можно задать «домен по умолчанию“ (не совсем точный термин, но не в этом суть). При этом подавляющее большинство хостеров присваивают своим серверам домены по умолчанию, содержащие в себе имя домена хостера, т. е. что-то вроде server-name.hoster-name.com.
Самый простой вариант узнать это доменное имя по умолчанию — при помощи всем родного ping’a (альтернативно — команды host, dig и nslookup под Linux’ом, аналоги под виндой должны быть, но я про них ничего не знаю).

Пример

PING cisnet.ru (78.108.81.180) 56 (84) bytes of data.
64 bytes from timur.majordomo.ru (78.108.81.180): icmp_seq=1 ttl=55 time=102 ms

Результат: Хостер — majordomo.ru

Плюсы

Минусы

5. Traceroute

Этот способ тесно связан с предыдущим, поскольку тоже подразумевает использование Reverse DNS Lookup, только на этот раз мы будем смотреть домены и для узлов на пути к интересующему нас узлу. Смысл в этом прост — по доменам последних узлов в трейсе мы с большой вероятностью угадаем хостера или датацентр, в котором размещен интересующий нас сайт. Очевидно, что этот способ поможет нам в случае если испытуемый сидит на VPS или выделенном сервере.

Пример

traceroute to phpbbguru.net (88.198.45.197), 30 hops max, 60 byte packets
/* Пропущен неинтересный нам кусок */
6 87.226.228.149 (87.226.228.149) 126.004 ms 103.010 ms 103.147 ms
7 xe-2–2–0.frkt-ar2.intl.ip.rostelecom.ru (87.226.133.150) 115.394 ms 115.575 ms xe-1–0–0.frkt-ar2.intl.ip.rostelecom.ru (87.226.133.110) 137.887 ms
8 decix-gw.hetzner.de (80.81.192.164) 120.920 ms 137.137 ms 137.343 ms
9 hos-bb1.juniper1.rz6.hetzner.de (213.239.240.238) 115.458 ms hos-bb1.juniper2.rz6.hetzner.de (213.239.240.239) 118.008 ms 118.280 ms
10 hos-tr4.ex3k41.rz6.hetzner.de (213.239.252.180) 118.562 ms hos-tr2.ex3k41.rz6.hetzner.de (213.239.229.180) 137.399 ms hos-tr3.ex3k41.rz6.hetzner.de (213.239.252.52) 115.269 ms
11 static.88–198–45–197.clients.your-server.de (88.198.45.197) 136.016 ms 137.170 ms 132.209 ms

Плюсы

Минусы

6. Whois

Вот и добрались до Whois’a, великого и ужасного. В базе данных Whois хранятся не только данные о доменах, но и данные о владельцах диапазонов и отдельных IP-адресов. Соответственно, на основе информации мы можем попытаться установить компанию-владельца хостинга или датацентра.

Пример

whois 83.222.4.124% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See www.ripe.net/db/support/db-terms-conditions.pdf

% Note: This output has been filtered.
% To receive output for a database update, use the «-B» flag.

% Information related to ‘83.222.4.0 — 83.222.5.255’

inetnum: 83.222.4.0 — 83.222.5.255
netname: MASTERHOST-COLOCATION
descr: Masterhost is a hosting and technical support organization.
country: RU
admin-c: MHST-RIPE
tech-c: MHST-RIPE
status: ASSIGNED PA
mnt-by: MASTERHOST-MNT
source: RIPE # Filtered

% Information related to ‘83.222.0.0/19AS25532’

Вывод: сайт живет на собственном сервере, размещенном у Мастерхоста.

Плюсы

Минусы

7. Сигнатура SMTP сервера

небольшой хак — телнет на 25 порт, в большинстве случаев на нём висит почтовый сервис который сразу выдаст хостнейм сервера.

На примере ваших сайтов:

# telnet cisnet.ru 25
Trying 78.108.81.180…
Connected to cisnet.ru.
Escape character is ‘^]’.
220 timur.majordomo.ru ESMTP Exim 4.69 Sat, 17 Apr 2010 22:20:47 +0400

# telnet phpbbguru.net 25
Trying 88.198.45.197…
Connected to phpbbguru.net.
Escape character is ‘^]’.
220 sds.fastvps.ru ESMTP Exim 4.69 Sat, 17 Apr 2010 22:23:25 +0400

Вместо telnet можно использовать netcat:
$ netcat cisnet.ru 25
220 timur.majordomo.ru ESMTP Exim 4.69 Sun, 18 Apr 2010 12:21:21 +0400
^C

Дополнительные сервисы, предложенные хабраобщественностью

Мораль

Практически в любом случае свое любопытство мы сумеем удовлетворить, вопрос лишь в том, насколько точно. А мораль для хостеров — не ленитесь обеспечить себе дополнительный канал притока клиентов, но в то же время не перегните палку, чтобы не распугать клиентов нынешних.

UDP. Перенес в Хостинг.
UPD2. Добавил еще два сервиса, предложенных в комментах.
UPD3, 30 мая. Неожиданно обнаружил этот топик в черновиках. Вернул на место.

PS. Если вы знаете еще способы — пишите, а я добавлю в список.

Источник