Я слежу за интранетом в нашем офисе под управлением Mac OS X Server 10.5.8. У нас есть несколько приложений, работающих в интрасети - Bugzilla, TWiki, несколько домашних приложений и несколько статических страниц. (Не используйте инструменты совместной работы OS X - мы использовали TWiki до того, как они стали доступны.)
Настроен один хост, и все приложения работают под ним - http://intranet/bugzilla, http://intranet/twiki, и т.д.
Я только что прочитал главу в документации Apache о виртуальных именованных хостах и очень хочу их попробовать. Если я прав, я получу URL типа http://bugzilla/, http://twiki/, и т.д.? Я знаю, что мне также нужно управлять зоной DNS, чтобы добавлять эти имена в качестве псевдонимов.
Преимущества, которые я вижу, состоят в том, что это упростит перемещение приложения на другой физический хост, если в этом возникнет необходимость. У нас есть разработчик, настроенный для нашего общедоступного веб-сайта, поэтому наличие там виртуального именованного хоста упрощает тестирование.
С другой стороны, мне также нужно управлять настройками DNS, тогда как с одним хостом нужно беспокоиться только об одном имени.
Что здесь за мудрость? Это хороший способ продолжить?
Есть ли другие преимущества и недостатки, которыми кто-то хотел бы поделиться, прежде чем я совершу прыжок. Или не.
Ура.
Для интрасети с конфиденциальными данными вы хотите не только включить виртуальные именованные хосты, но и убедиться, что сайт по умолчанию указывает на фиктивный сайт, в котором указано, к кому следует обращаться, чтобы сообщить о неправильной конфигурации.
Вот часть текста, который я показываю на своей странице по умолчанию:
Почему это происходит вместо того, чтобы видеть сайт по умолчанию?
Для защиты от очень опасной целевой атаки. Предположим, что кто-то пытается проникнуть в нашу систему? Даже если это маловероятно для некоторых из нас, это хорошая практика - предполагать, что кто-то может быть, и выработать привычку защищаться от этого.
Ключевые моменты для этого:
Получить веб-хостинг, позволяющий использовать любые зарегистрированные вами домены, несложно. Это касается всех, включая злоумышленников. DNS-хостинг доступен с интерфейсами "укажи и щелкни". Любому злоумышленнику, о котором стоит беспокоиться, потребуется минимальное количество времени, чтобы хотя бы узнать о сопоставлении имени хоста и IP-адреса. JavaScript широко распространен. Фреймы тоже. Как и ошибки XSS в браузерах. Злоумышленник использует фреймы. Верхний фрейм загружается с www.evil.example.net. Один из дочерних фреймов загружается с сайта жертвы.evil.example.net. Для некоторых браузеров родительский фрейм сможет использовать JavaScript для управления дочерним фреймом, потому что оба находятся в одном домене, верно? Ну и что? Злоумышленник контролирует DNS для evil.example.net, поэтому он может указать «жертву» на любой IP-адрес, который пожелает. Включая один из наших IP-адресов, даже если адрес находится в пространстве RFC 1918.
Чистый результат: если сервер отвечает контентом, когда ему заданы неизвестные имена хостов, то злоумышленник может сделать что угодно с любыми веб-страницами с помощью JavaScript; все, что им нужно, - это веб-хостинг и управление DNS, а также чтобы кого-то подтолкнули к посещению их сайта с помощью браузера с поддержкой фреймов, в котором включен JavaScript (это все основные браузеры, а также большинство второстепенных).
Теоретически в наши дни браузеры научились защищаться от этого с помощью осторожного применения политик одинакового происхождения. На практике потоку дыр в безопасности браузера не видно конца для каждого веб-браузера, реализующего механизм сценариев, который допускает эти ошибки межсайтового скриптинга (XSS) на стороне браузера. Так довольно часто и без предварительного предупреждения упомянутые ранее «некоторые» браузеры внезапно становятся «многими» или даже «большинством».
Поскольку вся атака может быть нейтрализована на веб-серверах, которые содержат защищаемый контент, не беспокоясь о статусе исправления каждого клиентского браузера или наличии ошибок, не раскрываемых публично, и поскольку исправление обычно является простым и легким, все В идеале веб-серверы должны быть осторожны и отвечать только на те имена хостов, о которых они явно знают. Этот идеал не всегда может быть осуществим, но для типичных веб-серверов это так.
После того, как вы его настроите, VHosts определенно станет проще в управлении, особенно с точки зрения конфигурации. Вы можете настроить конфигурацию для одного виртуального хоста и не беспокоиться о том, что это повлияет на другие ваши сайты.
Если вы настроите запись DNS с подстановочными знаками, например * .intranet, вам не придется беспокоиться о поддержке нескольких DNS-имен.
Если вы используете SSL (если вы по какой-либо причине передаете пароли через веб-формы, я, конечно, на это надеюсь), вам потребуется развернуть несколько сертификатов SSL, по одному для каждого виртуального хоста. Однако это можно свести к минимуму, если вы используете групповой сертификат, который вы можете приобрести или создать самостоятельно.
Я думаю, что это часто вопрос эстетики.
Лично я бы разделил вещи по виртуальному хосту: http: //bugzilla.intranet, http: //twiki.intranetи т. д. Это дает вам возможности для более простого перемещения вещей на другие хосты в будущем, но вы всегда можете сделать это постфактум, используя перенаправления в Apache. Виртуальные хосты также позволяют более плотно разделять структуры каталогов, что добавляет маленький повышенная безопасность веб-сервера (что может не представлять для вас такой большой проблемы в настройках интрасети).
Кроме того, во время тестирования проще ограничить доступ к Vhosts, чем к простому подкаталогу в каталоге основного сайта. Опять же, это можно сделать и другим способом, используя простые правила .htaccess, но я предпочитаю как можно чаще разделять вещи логически (если не физически).
Во-первых, я не думаю, что вам стоит сильно беспокоиться об этом выборе. Если позже вы обнаружите, что решили "ошибаться", не должно быть особых проблем, измените структуру и установите несколько автоматических перенаправлений http.
Я бы определенно выбрал отдельные VirtualHosts. По крайней мере, из-за дополнительных параметров, которые он дает мне, когда дело доходит до конфигурации, журналов и т. Д.
Тем не менее, я полагаю, что все сводится к анализу затрат и выгод. Сколько работы вам нужно также по управлению DNS? Стоит ли эта «стоимость» дополнительной свободы, которую дает вам VirtualHost? Постороннему человеку трудно дать вам ответ на эту часть уравнения.