Iis поиск веб узла (findweb)


Как открыть доступ из интернета к сайту на локальном IIS?

Собственно вопрос: Как открыть доступ из интернета к сайту на локальном IIS

в приложении зашит лаунч на порту 5801, локально доступен по localhost:5801. как открыть доступ из интернета? обязательно ли нужен стаический айпи?

не разбираюсь в администрировании, если можно — объясните пошагово.

01.02.2020, 15:09

Доступ к сайту на IIS в гостевой ОС из Основной
Добрый день! Не уверен что пишу туда куда надо, но вариантов больше не вижу. В общем есть.

Настройка домашнего веб-сервера (доступ к сайту с интернета)
Всем привет ! Цель: доступ к сайту из инета. Разворачиваю на домашнем компьютере. Ubuntu 16.04.

Открыть доступ к IIS за шлюзом
Здравствуйте. Ситуация такая: Имеется машинка-шлюз. Windows Server 2008 R2. На ней крутится IIS.

Доступ к локальном сайту из вне
Не знаю как понятнее объяснить. Что имеем в теории Есть в локальной сети сайт. Соответственно он.

Как открыть доступ к сайту?
Заблокировал доступ к и-нету следующим образом: в протоколе и-нета TCP/IP, в разделе.

13.05.2020, 11:27 2

Если версия IIS 7.5)))
1. Заходите Пуск — Администрирование — Диспетчер служб ИИС.
2. Нажимаете на сайт ПКМ и выбираете «Изменить привязки»
3. Далее жмете кнопку «добавить»
4. Тип оставляете «http» ip-адрес — здесь вбиваете ваш статический айпи адрес выделенный провайдером.
Порт 80. Имя узла — доменное имя купленное у вашего провайдера.
5. Жмем Ок — и еще раз ОК.
6. Заходим в интерфейс модема. Там находим виртуальные серверы. Добавить новый.
7. Где имя пишем Ваше доменное имя (например www.example.ru).
8. Интерфейс ipoe_0_67_1 (у меня такой стоит). Протокол TCP. Внешний и внутренний порт 80. И внутренний ip-адрес — адрес прописанный модему (не статичный ip-адрес выданный провайдером, а айпишник модема).
9. Сохраняемся. Заходим с другого компа по вашему адресу (например www.example.ru) и прыгаем от радости если все получилось. По крайней мере у меня так заработало. Надеюсь кому то поможет.

Добавлено через 34 секунды
Ответ не для автора, а для тех кто ищет ответ) Так как тема старенькая.

13.05.2020, 11:27

Как открыть доступ к одному сайту в IE 8.0
Помогите пожалуйста открыть доступ в Internet explorer 8.0, только для одного сайта.

Как открыть доступ к сайту из локальной сети?
хотелось бы спросить по такому вопросу: есть сайт, находится на виртуальном хостинге. есть.

Как открыть доступ только к одному сайту в internet explorer 8.0
Помогите пожалуйста открыть доступ в Internet explorer 8.0, только для одного сайта.

Iis поиск веб узла (findweb)

Обновлен: Ноябрь 2007

Локальный веб-узел IIS — это веб-приложение IIS на компьютере. Visual Web Developer сообщается с веб-узлом с помощью протокола HTTP.

Создание или открытие локального веб-узла IIS полезно в следующих ситуациях:

Необходимо протестировать работу веб-узла с помощью служб IIS. В этом случае обеспечивается приближенная к реальности имитация выполнения узла на рабочем сервере. Такой подход дает определенные преимущества по сравнению с использованием веб-узлов на базе файловой системы, которые выполняются на сервере разработки ASP.NET, поскольку разрешение путей реализуется так же, как и на рабочем сервере.

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

Локальный компьютер также является веб-сервером.

Для создания локального веб-узла IIS необходимо следующее:

На компьютере должны быть установлены и выполняться службы IIS версии не ранее 5.0.

На компьютере должна быть установлена платформа .NET Framework версии 2.0.

В IIS должен быть включен ASP.NET версии 2.0. Дополнительные сведения см. в разделе «Включение ASP.NET» документации по продуктам IIS.

Необходимо войти в систему с правами администратора. Это необходимо по той причине, что для работы с метабазой IIS (в которой хранится информация о приложениях IIS) необходимы права администратора.

Для открытия существующего локального веб-узла IIS должны быть соблюдены как приведенные выше, так и следующие условия:

Открываемый узел должен быть настроен как IIS-приложение. Дополнительные сведения см. в разделе «Создание виртуальных каталогов в IIS 6.0» документации по продуктам IIS.

Узел должен быть настроен для использования ASP.NET версии 2.0. Если это условие не соблюдено, то при открытии узла Visual Web Developer предложит перенастроить узел для использования ASP.NET 2.0. Это отличается от случая, когда ASP.NET 2.0 установлен на удаленном компьютере. Существует вероятность, что ASP.NET 2.0 установлен на удаленном компьютере, а узел для открытия по-прежнему сопоставляется с более ранней версией ASP.NET.

При создании веб-узла Visual Web Developer выполняет все необходимые задачи, чтобы этот веб-узел функционировал как приложение IIS. Visual Web Developer создает одну или несколько папок для веб-узла в корневом каталоге документов для IIS (например в \inetpub\wwwroot). После создания папок Visual Web Developer создает файлы для выбранного шаблона веб-узла.

Приложение IIS можно создать как вложенную папку в любой существующей папке IIS.

При создании или открытии локального веб-узла IIS Visual Web Developer создает проект для управления его файлами. В проекте хранится минимальный объем данных, в том числе параметры запуска приложения и сведения о доступных отладчиках. Данные проекта хранятся отдельно для каждого пользователя. Дополнительные сведения см. в разделе Проекты и решения веб-узлов .

По умолчанию при запуске локального веб-узла IIS для выполнения проверки Visual Web Developer вызывает обозреватель и запускает веб-узел с использованием имени сервера localhost . Например, если создан веб-узел ExampleSite , то при его проверке в Visual Web Developer обозреватель будет запрашивать тестовую страницу по этому URL-адресу:

Независимо от того, указывает ли этот путь на папку в корне IIS или на другое расположение, IIS разрешает имя приложения и обслуживает страницы из этой папки.

Обычно локальные веб-узлы IIS используются только для разработки, так что разработчики могут создавать и тестировать веб-страницы ASP.NET на своих собственных компьютерах. В большинстве случаев необходимо разворачивать файлы из файловой системы веб-узла на рабочий сервер с IIS.

Можно разворачивать эти файлы из локального веб-узла IIS с помощью средства Copy Web и служебной программы Publish Web, которые имеются в Visual Web Developer. Дополнительные сведения см. в разделе Общие сведения о развертывании ASP.NET .

Примечание.

Служебная программа Publish Web недоступна в экспресс-выпуске Visual Web Developer.

IIS 7.0: краткая инструкция для системного администратора. Часть 1 – пpoверка результатов установки.

Продолжаем говорить об процедуре установки веб сервера под управлением IIS 7.0 на Windows Server 2008, которая была рассмотрена в предыдущем посте.

Теперь перейдем к проверке результатов установки IIS 7.0. Самый простой вариант проверить, работает ли веб сервер, особенно – находясь за локальной консолью, это обратиться из любого веб-браузера по адресу http://localhost/. Далее, проверить с локальной и удаленной машины по IP-адресу.

При установке IIS 7.0 создается веб сайт по умолчанию, сконфигурированный на ответ при любом URL-запросе, поступившем на порт 80 любого сетевого интерфейса сервера, на котором установлен IIS 7.0. Т.е. запрос браузера типа http://localhost/ должен быть обработан как запрос к веб сайту по умолчанию. Содержимое сайта по умолчанию представляет собой 2 файла – iisstart.htm и welcome.png (который отображается в iisstart.htm), которые и будут открыты клиентом. Поэтому результат обращения к localhost будет иметь следующий вид:

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

1. Основным инструментом управления IIS 7.0 является консоль Internet Information Services (IIS) Manager, которая устанавливается по умолчанию, вместе с ролью Web Server в Windows Server 2008 (IIS Management Console, раздел Management Tools при установки модулей). После соответствующей установки консоль управления IIS 7.0 можно найти, как дочернюю запись внутри раздела Web Server (IIS) в разделе ролей Server Manager, либо как пункт в разделе Administrative Tools меню Start, либо выполнив команду inetmgr (в командной строке или через пункт Run того же меню Start).

2. При старте консоль Internet Information Services (IIS) Manager открывается с «домашней страницей», на которой в виде панелей находится информация о том, к каким веб серверам и веб сайтам подключался пользователь консоли до этого (если консоль только установлена вместе с ролью Web Server (IIS), то в консоле присутствует запись только о локальном веб сервере), также присутствуют ссылки для выбора подключения к другим серверам, веб сайтам, веб приложениям и папкам, а также ссылки на внешние ресурсы, посвященные IIS.

3. Кроме того, на домашней странице присутствует панель новостей, которые подгружаются как новостная RSS-лента с сайта www.iis.net, если администратор нажимает на ссылку Enable IIS News. Новости, кстати, очень полезные, рекомендуется включать и использовать эту информацию в повседневной работе.

4. При подключении к какому либо веб серверу IIS 7.0 консоль Internet Information Services (IIS) Manager представляет его конфигурацию, как логическую структуру – уровень самого веб сервера, чьи настройки являются глобальными и распространяются по умолчанию на все веб сайты, пулы приложений и, сообственно, веб сайты со своими настройками. Эта конфигурационная иерархия, в виде разворачивающегося дерева, начинающегося с узла с именем (или IP) веб сервера, отображается в левой панели консоли Internet Information Services (IIS) Manager.

5. Если выбрать какой-то узел в дереве конфигурации, то в центральной панель консоли Internet Information Services (IIS) Manager будут отображены в виде отдельных иконок все параметры (а также – модули или списки), соответствующие конфигурации выбранного узла, а в правой панели – набор контекстных задач и операций, которые администратор (или пользователь) может выполнить над данным узлом.

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

7. В правой панели при выборе узла веб сайта отображаются все операции, возможные для выполнения непосредственно с веб сервером (службами IIS в целом) в данном конексте – перезапуск, останов, запуск, переход к пулам приложений и сайтам.

8. Убеждаемся, что пулы приложений (Application Pools) сконфигурированы. Пулы приложений будут рассмотрены позже. Пулы являются дочерним узлом в дереве конфигурации для узла веб сайта. При установке по умолчанию создается только один пул – DefaultAppPool, в котором регистрируется одно приложение – сконфигурированный по умолчанию веб сайт, работу которого мы уже проверили. См. снимок экрана.

9. Ниже узла пулов приложений в дереве конфигурации находится узел веб сайтов (Sites), при выборе которого отображается список работающих на данном веб сервере веб сайтов. По умолчанию создается один веб сайт под названием Default Web Site с внутренним номером (ID) равным 1, «привязанный» на 80 порт всех IP-адресах всех сетевых интерфейсов к любому URL в запросе, и использующий в качестве домашнего каталога своего контента каталог с путем %SystemDrive%\inetpub\wwwroot (что при установленном Windows Server 2008 на диск C: соответствует C: \inetpub\wwwroot).

10. При выборе в левой панели консоли узла веб сайта (Default Web Site), также, как и в случае с выбором узла веб сервера, в центральной панели отображаются иконки для доступа к параметрам конфигурации различных модулей, на этот раз – конкретного веб сайта. Убеждаемся, что также, как и в случае со всем веб сервером, все необходимые модули представлены в центральной панели.

11. В правой панели консоли, аналогично панели для всего веб сервера, отображаются контекстные команды, правда, на этот раз их список серьезно расширен – старт/стоп/перезапуск процесса веб сайта, просмотр его базовых и расширенных настроек (а не параметров модулей), настройки привязки (адрес, порт, доменное имя – по сочетанию которых будет отвечать на запросы данный веб сайт) и т.п.

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

12. Выберите узел веб сервера в дереве конфигурации в левой панели консоли Internet Information Services (IIS) Manager. В центральной панели кликните на иконку Modules. В центральной панели откроется следующий полный список установленных по умолчанию модулей, представляющий из себя перечень .dll файлов.

13. Чтобы убедиться, что веб сервер будет работать только со статическими файлами (по умолчанию) или только с нужными вам расширениями – выберите снова узел веб сервера и в центральной панели кликните на иконку Handler Mappings. Откроется список «привязки» расширений вызываемых на веб сайте пользователем файлов и привязанных к данным расширениям модулям, выполняющим обработку данного вызова. Обратите внимание, что по умолчанию все файлы привязаны к модулю обработки статических файлов (т.е. запрос какого либо скриптового или исполнимого файла из домашнего каталога веб сайта не будет приводить к его исполнению на сервере, а лишь к передаче данного файла пользователю), а также к модулям документа по умолчанию и просмотра каталога. С этими модулями мы познакомимся позже.

14. И, наконец, для того, чтобы убедиться в безопасности веб сайта – проверьте параметры его аутентификации. Для этого выбираем иконку Authentication в той же центральной панели. По умолчанию никаких модулей аутентификации веб сервер (и веб сайты) не поддерживает. Т.е. все подключения для него анонимны. В чем безопасность? Это значит, что пользователям будет доступен только то содержимое домашних каталогов сайтов – файлы и подкаталоги – которые имеют NTFS разрешения для чтения «всем» (Everyone). В случае, если таких разрешений файл не имеет, пользователю будет отказано в доступе с соответствующей ошибкой 401. Если же пользователь попробует каким-то образом аутентифицироваться в процессе HTTP запроса на сервере – то поскольку никаких модулей аутентификации, кроме анонимного, на веб сервере не установлено – он снова получит соответствующую ошибку 401.

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

Итак, сервер установлен и его работоспособность проверена. Теперь достаточно поместить какой либо статический контент (файлы HTML, изображения, документы и файлы для выгрузки пользователями) в домашний каталог его сайта по умолчанию (напоминаю, что это в большинстве случаев C:\inetpub\wwwroot) – и веб сайт под управлением IIS 7.0 начнет работать. Ну, и конечно, для внешних сайтов – не забыть прописать их A-record в вашей доменной зоне на публичном DNS сервере.

В следующей части – установка IIS 7.0 в режиме командной строки, особенности работы IIS 7.0 на Server Core.

Улучшение безопасности IIS

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

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

На рынке существуют различные продукты, которые, как утверждается, могут сделать ваш сервер более защищенным, но не ограждают от всех возможных видов атак. Существует весьма распространенное заблуждение о том, что безопасность веб-сайта можно улучшить посредством ревизии исходного кода. Это не всегда соответствует действительности. Помимо написания безопасного кода, сайт, созданный средствами ASP.NET, следует также надежно защитить со стороны IIS-сервера. В этой статье будут различные аспекты безопасности IIS, чтобы оградить ваш сайт от незаконного проникновения.

Для того чтобы защитить IIS, специалист по безопасности должен обладать глубокими познаниями технологии .NET и, в особенности, ASP.NET, поскольку в подавляющем большинстве на IIS крутятся сайты, использующие эти технологии. Кроме того, весьма желательно понимать весь процесс разработки и развертывания веб-сервера, включая написание кода (в контексте конфигурирования сайта на ASP.NET).

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

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


По сути, IIS представляет собой набор различных WWW-служб, обрабатывающих запросы, которые поступают на различные TCP/IP порты (например, за 80-м портом обычно закреплен протокол HTTP). Перед тем как до ASP.NET дойдут запросы, происходит верификация (аутентификация, авторизация и т. д.) в соответствии с настройками IIS. В IIS есть различные возможности (см. рисунок ниже) для ограничения доступа и запрета некоторых типов запросов.

Рисунок 1: Средства безопасности в IIS

Регулирование прав доступа

IIS позволяет выборочно запрещать или разрешать доступ к файлам, папкам, сайту или серверу. Системный администратор может определять, какой удаленный компьютер может подключаться к IIS, а какой нет. В отношении каждого IP-адреса или DNS-имени можно настроить отдельные ограничительные правила. Допустим, если в коде на ASP.NET есть уязвимость, то, по сути, злоумышленник имеет неограниченный доступ к веб-сайту. Однако если выставить запрет на доступ со стороны IIS, появится следующее сообщение ‘Forbidden: IP address of the client has been rejected (403.6)’ или ‘DNS name of the client is rejected (403.8)’. Соответствующий HTTP-статус будет отражен в журнале. В связи с ограничением прав существуют два термина, касающиеся настройки IIS: IP Restriction и Domain Restriction.

Запрет на соединение предпочтительнее конфигурировать на как можно более низком уровне в модели OSI.

Чтобы сконфигурировать политику относительно DNS для разрешения доступ всем, кроме специально указанных адресов, кликните на ‘Edit Feature Settings’. Появится окно ‘IP Address and Domain Restrictions’.

Рисунок 2: Запрет на доступ определенным клиентам

Затем вы можете создать правила для определенных хостов или подсетей. Чтобы создать правило, разрешающее доступ для конкретного клиента или подсети, кликните на “Allow Entry” и укажите отдельный IP-адрес или диапазон IP-адресов.

Рисунок 3: Разрешение на доступ определенным хостам

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

Рисунок 4: Добавление нового MIME type

IIS позволяет настраивать наборы правил для разрешения и запрета определенных типов запросов. Фильтрация позволяет пропускать запросы для определенного пространства имен и жестко интегрирована в систему журналирования событий. Запросы могут фильтроваться по параметрам HTTP-заголовка, расширениям файлов, размеру запроса и подстроке, входящей в URL.

При фильтрации по параметрам HTTP-заголовка в секции «verbs», например, можно разрешить только GET- или POST-запросы. Следующий набор XML-тегов как раз позволяет отфильтровать HTTP-заголовок по типу запроса (необходимо добавить этот код в конфигурационный файл):

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

Запрос также может быть отклонен при превышении определенного размера запроса.

И последний пример, в котором запросы фильтруются на основе подстрок (в данном случае – «. .»), входящих в URL.

Настройка пула приложений

Когда необходимо получить информацию из внешнего источника, может возникнуть конфликт, поскольку довольно сложно разделить между собой пулы веб-приложений. Иначе говоря, код, запущенный внутри одного пула, будет влиять на работоспособность другого пула. Чтобы в некоторой степени предотвратить этот конфликт, в IIS предусмотрена настройка пула приложений. Каждый пул приложений имеет свой конфигурационный файл, которых хранится в папке %systemdriver\inetpub\temp\appPools, и дополнительный идентификатор безопасности (SID), инжектируемый в соответствующий процесс w3wp.exe. Соответственно, каждый конфигурационный файл пула закреплен за своим SID’ом через права доступа.

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

Рисунок 5: Добавление пула приложений

Используя ISAPI, разработчики часто пишут дополнительные модули, чтобы расширить функционал сервера во время запроса определенного типа файла. Например, сайты на PHP могут работать на IIS-сервере при помощи расширения PHP ISAPI. Соответственно, сайты на ASP.NET (или файлы .aspx) по умолчанию привязаны к расширению ASP.NET ISAPI. Когда клиент запрашивает файл с расширением .aspx, дальнейшая обработка происходит через расширение IIS ISAPI, которое уже определяет, какие дополнительные действия должны быть предприняты.

В IIS можно запретить или разрешить те или иные расширения ISAPI. Если расширение запрещено, при запросе файла соответствующего типа в лог заносится статус 404.2, поскольку злоумышленник может удаленно внедрить и выполнить вредоносный код. После добавления новых расширений в дальнейшем необходимо провести аудит безопасности сервера. Чтобы добавить расширение, укажите имя фильтра и путь к библиотеке DLL.

Рисунок 6: Добавление нового расширения

Хакеры часто проводят DOS-атаки, отправляя на сервер огромные запросы, что в свою очередь может сказаться на размере логов. При помощи логов, например, можно выявить факты неправомерного доступа. В ОС Windows имеет встроенная функция записи в журнал важной информации: время авторизации, попытки подбора пароля и т. д., что является одним из признаков атаки. Для каждого сайта можно настроить систему фиксации событий в формате W3C.

Рисунок 7: Настройка логов

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

Настройка страниц ошибок

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

Рисунок 8: Неудачный пример страницы с ошибкой

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

В IIS есть возможность выдачи различных страниц с ошибками для конечных пользователей, администраторов и разработчиков.

Рисунок 9: Настройка страниц ошибок

Даже после грамотной настройки IIS не следует забывать о безопасности приложений. В последнее время много внимания уделяется уязвимостям в веб-приложениях: SQL-инъекциям, межсайтовому скриптингу, воспроизведению сессий (session replay), RFI и многим другим. С каждым днем злоумышленники становятся все более изощренными. Таким образом, свои позиции следует защищать со всех фронтов.

В статье мы рассмотрели способы защиты приложения посредством грамотной конфигурации IIS, включая ограничение доступа по IP-адресу, настройку MIME-Type, фильтрацию запросов, настройку пула приложений, ISAPI и страниц ошибок. Таким образом, на данный момент у вас должно появиться более полное понимание относительно безопасности в целом и в частности относительно настроек, повышающих безопасность IIS.

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Iis поиск веб узла (findweb)

Суть такова: мне нужно чтобы пользователи могли открывать ограниченное количество приложений через веб браузер. Есть сервер, на нем Windows server 2012 standart. IIS роль и службы все кто-то уже добавил, но там ни каких пользовательских изменений. Я выбрал самый простой вариант развертывания удаленных рабочих столов — по средству установления сессий. Далее все по видео с инета) Но! На всех видео, когда открываешь управление IIS, там присутствует каталог rdWeb. Юзер заходит ведь в браузере на www.domain.com/rdweb А нету этого каталога!

1) Куда подевался?

2) Переустановка службы IIS может решить проблему (вдруг rdweb удален руками не добрыми)?

3) Как решить проблему?))

(Я чайник, но при необходимости могу ответить более подробно и привести умные слова и приложить скриншоты)

Настройка веб-сервера IIS, часть 1

Internet Information Services (IIS) это набор интернет-серверов от компании Microsoft. Основным компонентом IIS является веб-сервер, хотя этим дело не ограничивается. Последняя восьмая версия IIS поставляется со всеми редакциями Windows Server 2012 R2.

Несмотря на проприетарность IIS, доля этого набора сервисов на рынке постепенно увеличивается. В интернете можно отыскать множество сакральных споров, что же всё таки лучше — IIS, Apache или, скажем, Nginx. Не будем им уподобляться, просто скажем в каких случаях в основном используется IIS.

Самый удобный вариант использования IIS — когда всё ваше рабочее окружение (и серверная его часть тоже) работает на Windows. В таком случае Вы можете получить от IIS ряд удобных «плюшек» для работы в домене. В конце концов, ведь IIS это еще и FTP-сервер, и почтовый сервер. Интерфейс IIS довольно нагляден, что вообще свойственно Windows-среде. Ну и, конечно, IIS пригодится вам, если вы используете MS SQL.

Для включения IIS в Windows Server 2012 R2 зайдите в Диспетчер серверов.

В Диспетчере серверов найдите пункт «Добавить роли и компоненты».

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

Убедитесь, что у Вас включен CGI.

После этого в разделе Администрирование у Вас появится Диспетчер служб IIS.

Вы можете так же включить IIS в Windows 7 Профессиональная и Максимальная, а также в Windows 8. Для этого перейдите в Панель управления → Программы → Включение или отключение компонентов Windows.

Диспетчер служб представляет собой графический интерфейс управления Вашими серверами.

Справа перечислены сервера и сайты. По умолчанию на системном разделе создается папка inetpub, в которой находятся папки ftproot и wwwroot для FTP-серверов и веб-сайтов соответственно.

Установка PHP на IIS

Для установки PHP перейдите по ссылке и скачайте ZIP-архив с версией Non Thread Safe. Обозначение VC11 возле версии обозначает, что для её компиляции необходим Visual C++ Redistributable for Visual Studio 2012. Для старых версий, маркированных как VC9, требуется Visual C++ Redistributable for Visual Studio 2008 SP1.

Директорию для распаковки ZIP-архива можно выбрать по своему усмотрению. После извлечения архива создайте копию файла php.ini-production под именем php.ini в той же папке.

Файл php.ini содержит правила исполнения PHP и работы с окружением, в котором он исполняется. Есть ряд обязательных параметров, которые должны быть прописаны. Ниже список этих параметров.

extension_dir = [путь к директории расширений] — этот параметр отвечает за расположение расширений PHP. Например, C:\php\ext.

extension = xxxxx.dll — для каждого подключаемого расширения необходимо прописать такую директиву. Такие расширения будут подгружаться при старте PHP.

log_errors = On — включение лога ошибок.

error_log = [путь к файлу лога ошибок] — собственно, тут всё понятно.

cgi.force_redirect = 0 — отключение механизма защиты директорий, под IIS данный параметр должен принимать именно такое значение во избежание ошибок ядра PHP в Windows.

cgi.fix_pathinfo = 1 — включение поддержки PATH_INFO согласно спецификации CGI. IIS FastCGI использует эту настройку.

fastcgi.impersonate = 1 — включение идентификации маркеров безопасности вызывающего клиента.

fastcgi.logging = 0 — логи FastCGI в IIS необходимо отключить.

Далее в свойствах системы необходимо откорректировать переменные среды. В Windows Server 2012 R2 необходимо зайти в Панель управления, выбрать пункт Система, там Дополнительные параметры системы. На вкладке Дополнительно внизу находится кнопка Переменные среды.

Среди системных переменных находим переменную Path и в поле Значение переменной дописываем путь к каталогу PHP. В моем примере это C:\php.

Теперь нам необходимо указать в IIS как же обрабатывать php-файлы. Для этого заходим в пункт сопоставление обработчиков.

На панели действия щелкните по пункту Добавить сопоставление модуля и заполните в соответствии с тем, что видите на рисунке.

В поле исполняемого файла прописываете тот путь, куда был разархивирован PHP.

Проверим работу PHP. Для этого создаем файл index.php со следующим содержимым:

Если всё сделано правильно, то, набрав в адресной строке браузера http://localhost/index.php, Вы увидите следующую милую картинку:


Во второй части статьи поговорим о MySQL и phpMyAdmin.

Проверить ссылку (URL)

Иногда чтобы заразиться, достаточно попасть на вредоносный или мошеннический сайт, особенно если у вас нет антивирусной защиты, Даже легитимные интернет-ресурсы могут быть взломаны злоумышленниками. А еще есть сайты, при посещении которых с компьютера ничего страшного не случится, а вот зайдя на него со смартфона, вы будете тайно перенаправлены на сайт с неприятным «сюрпризом». С помощью взломанных сайтов злоумышленники могут распространять различные вредоносные программы, самыми «популярными» из которых являются различные модификации Android.SmsSend. Потери жертвы зависят от того, троянец какого семейства внедрится в мобильное ваше устройство, — т. е. от его вредоносного заряда. Подробности об этом явлении читайте в нашей новости.

Еcли сайт вызывает подозрение, проверьте его через эту форму до того, как нажимать на неизвестную ссылку.

Добавьте форму онлайн-проверки файлов и ссылок (URL) в код своего сайта, и любой его посетитель сможет бесплатно пользоваться этим сервисом.

Как получить доступ к моему веб-сайту (IIS) из Интернета?

Я установил IIS. Я перешел на мой сайт в IIS, используя ссылку «Обзор *: 80 (http)» в IIS. Это переход на http://localhost . Эта ссылка будет работать только на моей машине.

Меня не волнует изменение моего IP-адреса (я собираюсь показывать мой сайт в течение нескольких часов каждый раз, а затем, чтобы обновить его и повторно отправить ссылку по мере необходимости).

Как сделать свой сайт доступным в Интернете? Какой url следует использовать http://82.11.220.212 (где 82.11.220.212 — это IP моего компьютера)? Нужно ли отключать брандмауэры/добавлять исключения для моего модема/маршрутизатора?

Вы должны убедиться, что ваш провайдер широкополосного доступа предоставил вам статический IP-адрес (за это иногда взимается дополнительная плата). В противном случае вам будет присвоен новый IP-адрес при каждом подключении к Интернету.

Если ваш модем ISP сначала подключен к маршрутизатору, а затем к компьютеру, вы должны войти в настройки своего маршрутизатора и перенаправить входящие HTTP-запросы. Обычно это делается путем установки правила пересылки входящих TCP-соединений на порт 80. Вам необходимо переслать эти подключения на порт 80 на вашем компьютере. Если вы также хотите поддерживать https, вам нужно переслать порт 443.

Да, на самом деле вы можете. Если вы напрямую подключены к Интернету (это означает, что маршрутизатор в середине не делает NAT), вы можете просто использовать свой общедоступный IP-адрес и убедиться, что правила брандмауэра разрешают этот трафик.

Если вы находитесь за маршрутизатором, вам, вероятно, придется писать правила пересылки на ваш компьютер в вашей локальной сети. Кроме того, если вы не хотите беспокоиться о IP-адресах, вы можете использовать No-IP и т.д.

Iis поиск веб узла (findweb)

Программа Fiddler — это прокси, позволяющий просматривать все клиентские HTTP запросы и отслеживать трафик между локальным ПК и удаленным сервером/сервисом.

Она отлично работает, например, при отладке клиентской части сайта, позволяет просматривать внешние запросы, параметры и данные форм и куки (cookies).

Но при работе с веб-сервисами (web services), когда, например, нужно отследить по какому URL адресу сервис осуществил запрос, без дополнительной настройки программы Fiddler данного действия не увидеть. Это возможно, если сайт работает через инструмент Cassini, но в случае с IIS — Fiddler не покажет необходимую информацию о трафике сервиса.

Причина кроется в учетных записях, от имени которых работают IIS и Fiddler. Они оба запускаются под администратором. А вот приложения (сайты, сервисы) под управлением IIS работают уже из-под учетной записи «Network Service». Если бы можно было запустить Fiddler под Network Service, проблема была бы решена, но к сожалению, это невозможно.

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

Сделаем следующие шаги:

1) Добавим пользователя, обладающего правами администратора, в группу IIS_IUSRS (для IIS 7 и младше) или в группу IIS_WPG (для IIS 6 и старше) (группа обладает правами сетевой службы).

Для этого переходим:

Computer Management -> Local Users and Groups -> Groups -> IIS_IUSRS/IIS_WPG и добавляем в группу администратора.

2) Теперь необходимо настроить пул веб-приложения (Application Pool) для его запуска под учетной записью администратора.

Здесь может быть два варианта. Если для сайта, который нужно отслеживать, выделен отдельный пул, то настройку можно производить конкретно для него. Либо создать новый пул специально для подобных процедур и затем при необходимости привязывать его к нужным приложениям.

Итак, заходим в IIS, в списке пулов (Application Pools) выбираем нужный пул и переходим в его расширенные настройки (Advanced Settings):

В настройках пула в параметре Identity выбираем Custom account и по нажатию на Set — прописываем учетные данные администратора (логин и два раза пароль):

При необходимости связываем пул приложения (Application Pool) с веб-приложением. Для этого переходим в расширенные настройки нужного сайта/приложения и указываем пул:

Теперь можно запускать Fiddler, стартовать сайт/сервис и программа будет отслеживать все его запросы.

Установка CentOS 7 на виртуальную машину Hyper-V второго поколения (Generation 2)

Улучшение безопасности IIS

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

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

На рынке существуют различные продукты, которые, как утверждается, могут сделать ваш сервер более защищенным, но не ограждают от всех возможных видов атак. Существует весьма распространенное заблуждение о том, что безопасность веб-сайта можно улучшить посредством ревизии исходного кода. Это не всегда соответствует действительности. Помимо написания безопасного кода, сайт, созданный средствами ASP.NET, следует также надежно защитить со стороны IIS-сервера. В этой статье будут различные аспекты безопасности IIS, чтобы оградить ваш сайт от незаконного проникновения.

Для того чтобы защитить IIS, специалист по безопасности должен обладать глубокими познаниями технологии .NET и, в особенности, ASP.NET, поскольку в подавляющем большинстве на IIS крутятся сайты, использующие эти технологии. Кроме того, весьма желательно понимать весь процесс разработки и развертывания веб-сервера, включая написание кода (в контексте конфигурирования сайта на ASP.NET).

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

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

По сути, IIS представляет собой набор различных WWW-служб, обрабатывающих запросы, которые поступают на различные TCP/IP порты (например, за 80-м портом обычно закреплен протокол HTTP). Перед тем как до ASP.NET дойдут запросы, происходит верификация (аутентификация, авторизация и т. д.) в соответствии с настройками IIS. В IIS есть различные возможности (см. рисунок ниже) для ограничения доступа и запрета некоторых типов запросов.

Рисунок 1: Средства безопасности в IIS

Регулирование прав доступа

IIS позволяет выборочно запрещать или разрешать доступ к файлам, папкам, сайту или серверу. Системный администратор может определять, какой удаленный компьютер может подключаться к IIS, а какой нет. В отношении каждого IP-адреса или DNS-имени можно настроить отдельные ограничительные правила. Допустим, если в коде на ASP.NET есть уязвимость, то, по сути, злоумышленник имеет неограниченный доступ к веб-сайту. Однако если выставить запрет на доступ со стороны IIS, появится следующее сообщение ‘Forbidden: IP address of the client has been rejected (403.6)’ или ‘DNS name of the client is rejected (403.8)’. Соответствующий HTTP-статус будет отражен в журнале. В связи с ограничением прав существуют два термина, касающиеся настройки IIS: IP Restriction и Domain Restriction.

Запрет на соединение предпочтительнее конфигурировать на как можно более низком уровне в модели OSI.

Чтобы сконфигурировать политику относительно DNS для разрешения доступ всем, кроме специально указанных адресов, кликните на ‘Edit Feature Settings’. Появится окно ‘IP Address and Domain Restrictions’.

Рисунок 2: Запрет на доступ определенным клиентам

Затем вы можете создать правила для определенных хостов или подсетей. Чтобы создать правило, разрешающее доступ для конкретного клиента или подсети, кликните на “Allow Entry” и укажите отдельный IP-адрес или диапазон IP-адресов.

Рисунок 3: Разрешение на доступ определенным хостам

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

Рисунок 4: Добавление нового MIME type

IIS позволяет настраивать наборы правил для разрешения и запрета определенных типов запросов. Фильтрация позволяет пропускать запросы для определенного пространства имен и жестко интегрирована в систему журналирования событий. Запросы могут фильтроваться по параметрам HTTP-заголовка, расширениям файлов, размеру запроса и подстроке, входящей в URL.

При фильтрации по параметрам HTTP-заголовка в секции «verbs», например, можно разрешить только GET- или POST-запросы. Следующий набор XML-тегов как раз позволяет отфильтровать HTTP-заголовок по типу запроса (необходимо добавить этот код в конфигурационный файл):

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

Запрос также может быть отклонен при превышении определенного размера запроса.

И последний пример, в котором запросы фильтруются на основе подстрок (в данном случае – «. .»), входящих в URL.

Настройка пула приложений

Когда необходимо получить информацию из внешнего источника, может возникнуть конфликт, поскольку довольно сложно разделить между собой пулы веб-приложений. Иначе говоря, код, запущенный внутри одного пула, будет влиять на работоспособность другого пула. Чтобы в некоторой степени предотвратить этот конфликт, в IIS предусмотрена настройка пула приложений. Каждый пул приложений имеет свой конфигурационный файл, которых хранится в папке %systemdriver\inetpub\temp\appPools, и дополнительный идентификатор безопасности (SID), инжектируемый в соответствующий процесс w3wp.exe. Соответственно, каждый конфигурационный файл пула закреплен за своим SID’ом через права доступа.

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

Рисунок 5: Добавление пула приложений

Используя ISAPI, разработчики часто пишут дополнительные модули, чтобы расширить функционал сервера во время запроса определенного типа файла. Например, сайты на PHP могут работать на IIS-сервере при помощи расширения PHP ISAPI. Соответственно, сайты на ASP.NET (или файлы .aspx) по умолчанию привязаны к расширению ASP.NET ISAPI. Когда клиент запрашивает файл с расширением .aspx, дальнейшая обработка происходит через расширение IIS ISAPI, которое уже определяет, какие дополнительные действия должны быть предприняты.

В IIS можно запретить или разрешить те или иные расширения ISAPI. Если расширение запрещено, при запросе файла соответствующего типа в лог заносится статус 404.2, поскольку злоумышленник может удаленно внедрить и выполнить вредоносный код. После добавления новых расширений в дальнейшем необходимо провести аудит безопасности сервера. Чтобы добавить расширение, укажите имя фильтра и путь к библиотеке DLL.

Рисунок 6: Добавление нового расширения

Хакеры часто проводят DOS-атаки, отправляя на сервер огромные запросы, что в свою очередь может сказаться на размере логов. При помощи логов, например, можно выявить факты неправомерного доступа. В ОС Windows имеет встроенная функция записи в журнал важной информации: время авторизации, попытки подбора пароля и т. д., что является одним из признаков атаки. Для каждого сайта можно настроить систему фиксации событий в формате W3C.

Рисунок 7: Настройка логов

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

Настройка страниц ошибок

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

Рисунок 8: Неудачный пример страницы с ошибкой

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

В IIS есть возможность выдачи различных страниц с ошибками для конечных пользователей, администраторов и разработчиков.

Рисунок 9: Настройка страниц ошибок

Даже после грамотной настройки IIS не следует забывать о безопасности приложений. В последнее время много внимания уделяется уязвимостям в веб-приложениях: SQL-инъекциям, межсайтовому скриптингу, воспроизведению сессий (session replay), RFI и многим другим. С каждым днем злоумышленники становятся все более изощренными. Таким образом, свои позиции следует защищать со всех фронтов.

В статье мы рассмотрели способы защиты приложения посредством грамотной конфигурации IIS, включая ограничение доступа по IP-адресу, настройку MIME-Type, фильтрацию запросов, настройку пула приложений, ISAPI и страниц ошибок. Таким образом, на данный момент у вас должно появиться более полное понимание относительно безопасности в целом и в частности относительно настроек, повышающих безопасность IIS.

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Илон Маск рекомендует:  Использование php
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Примечание.