Я думаю, что это довольно сложный вопрос, надеюсь, кто-нибудь с опытом может мне помочь. Глубокий вдох, вот и мы:
Мы небольшой, но растущий веб-сайт, который хочет добавить еще один сервер, поэтому у нас будет два: один сервер веб-приложений и один сервер базы данных.
Мы также ищем аппаратный брандмауэр.
Все стандартные вещи.
Наши серверы размещены хостинговой компанией (natch) на одном из своих объектов. У нас нет собственной коробки, мы просто арендуем стеллаж у компании, которая имеет ее. Когда мы получим наш брандмауэр и дополнительный сервер, мы арендуем еще пару полок.
Думаю, довольно прямолинейно.
Теперь все становится немного сложнее: нам нужен прямой доступ к обоим серверам (например, для доступа к удаленному рабочему столу, доступа к серверу SQL, доступа к FTP и т. Д.).
У нас есть единственный IP-адрес для веб-сайта, и, хотя наше соединение проходит через маршрутизатор, прежде чем достигнет нашего сервера, у нас нет доступа к нему. Если я попытаюсь перейти к нашему шлюзу по умолчанию, я ничего не получу.
Как лучше всего добавить брандмауэр в нашу текущую конфигурацию? Мы надеялись, что сможем дешево получить что-то вроде Firebox X1000 на eBay и принять запрос для: www.ourdomain.com и перенаправить его на сервер A (например, 192.168.0.10) и запрос для server.ourdomain.com и перешлите его на сервер B (например, 192.168.0.11).
Есть ли в этом смысл? Мы идем по неправильному пути? Существует ли вообще такой межсетевой экран корпоративного уровня? (В качестве asidE: 2000 одновременных сеансов - это максимум, который мы видели на сайте до сих пор, но, очевидно, было бы хорошо, если бы нужно было расти.)
Спасибо за любую помощь, я совершенно сбит с толку, и люди из Watchguard и Juniper, хотя и невероятно полезны, не могут успокоить меня.
Обновить: Благодаря Zoredache и Джеспер Мортенсен за самый простой и полезный ответ на мой вопрос. Теперь я гораздо больше понимаю весь этот процесс (очевидно, что для аппаратного межсетевого экрана нет простого способа сделать то, что я хотел - и мой первоначальный запрос действительно не имеет смысла, теперь я понимаю больше о слоях - да).
В конечном итоге мы решили использовать третий сервер в качестве межсетевого экрана, а не выделенный межсетевой экран с аппаратным обеспечением. Причина этого в основном в том, что это обойдется нам намного дешевле и будет выполнять ту же работу. Мы уже планировали создать третий сервер для сбора нашей собственной аналитики, и мы ожидаем, что это будет довольно легкая работа (они запускаются на клиенте, а затем регистрируются в SQL), поэтому для нас имеет смысл переместить его на «перед» нашей конфигурации и использовать ее также как брандмауэр.
Мы также, вероятно, настроим на нем VPN, чтобы мы могли таким образом администрировать сервер веб-приложений и сервер БД, а не напрямую подключаться к ним.
Это означает, что нам не нужно покупать бытовой межсетевой экран или арендовать дополнительную стойку.
Единственное различие между рекомендациями и нашим решением состоит в том, что вместо этого мы будем использовать Windows Server 2008, потому что а) я знаю об этом и б) мы получаем его бесплатно через наш пакет BizSpark.
Еще раз спасибо!
PS - У кого-нибудь есть советы по спецификациям этого нового брандмауэра / VPN / (легкого) SQL-сервера? (Быстрый процессор и большой объем оперативной памяти кажутся мне разумными ... но что я знаю? :)
Конечно, это имеет смысл и будет довольно легко сделать с брандмауэром на базе Linux. Просто настройте Linux-сервер с одним интерфейсом с общедоступным адресом, а второй - с частным адресом.
Затем настройте обратный прокси, например Кальмар. Squid или любой другой обратный прокси-сервер, который вы выберете, может пересылать http-запросы во внутренние системы на основе заголовка хоста.
Вы можете использовать VPN для брандмауэра Linux, чтобы получить доступ к большинству других сервисов. Я не думаю, что было бы хорошей идеей напрямую подключать ваш SQL-сервер к Интернету. Если вам необходимо получить доступ к некоторым службам, вы также можете использовать NAT для перенаправления выбранного вами порта на порт внутренней системы.
Добро пожаловать на этот сайт, Джанго Р. :-)
Вы ловко собираете факты, но очевидно, что IP-сеть не является вашим основным набором навыков - может быть, нанять ближайшего консультанта будет хорошей идеей? Это не сложно, но в зависимости от требований вашего центра обработки данных (DC) решение может принимать разные направления ...
У нас нет собственного ящика, [...] Когда мы получим наш брандмауэр и дополнительный сервер, мы арендуем еще пару полок.
Эмм, какая это модель - размещение вашего собственного оборудования или управляемая служба (DC предоставляет оборудование и частично или полностью системное администрирование)? Если это управляемая служба, пусть DC справится с этим обычным образом, чтобы ваше решение было «знакомо» специалистам DC.
Как лучше всего добавить брандмауэр в нашу текущую конфигурацию?
Один из распространенных подходов:
Таким образом, ваши серверы с выходом в Интернет имеют общедоступные IP-адреса, что упрощает устранение неполадок, позволяет легко осуществлять удаленный мониторинг и в целом просто приятно. И ваши серверы баз данных не имеют общедоступных IP-адресов, что добавляет уровень косвенности, то есть помогает с точки зрения обеспечения безопасности.
Firebox X1000 дешево с eBay и принимает запрос: www.ourdomain.com и перенаправляет его на сервер A (например, 192.168.0.10), а запрос для server.ourdomain.com и перенаправляет его на сервер B (например, 192.168.0.11). ).
Не легко. Ваш брандмауэр работает на уровне 3; у него нет доступа к HTTP (уровень 7), поэтому "www." и «сервер». имена хостов ему не известны. Статический NAT можно выполнять только для IP-адресов и номеров портов. Вы можете назначить несколько IP-адресов внешнему интерфейсу межсетевого экрана или использовать разные номера портов, но это, IMHO, громоздкое решение.
Кроме того, если ваши веб-серверы находятся на внутренних IP-адресах, вы всегда будете видеть брандмауэр как исходный IP-адрес запроса, то есть журналы веб-серверов имеют меньшее значение.
Вы можете использовать балансировщик нагрузки (устройство уровня 7) заранее, и иметь прямой трафик на основе имен HTTP-серверов. В этом сценарии исходный IP-адрес добавляется к HTTP-запросу в виде HTTP-заголовка X-FORWARDED-FOR, и ваши веб-серверы и веб-приложения должны искать этот заголовок, если им нужен исходный IP-адрес. Сервер Linux со встроенным программным брандмауэром и HTTP-сервер, например nginx был бы отличным и недорогим решением. Но спросите себя, есть ли у вас предыдущий опыт быстрой настройки такого сервера и поддержания его в хорошем состоянии ...
Я не писал столько, сколько другие, но сделал почти то, что вам нужно, для моей последней компании.
У нас был брандмауэр Fortigate, и мы настроили его для приема внешних подключений на различные адреса, которые затем перенаправлялись внутри на разные хосты. Т.е. siteA.domain.com переходит на сервер A, siteB.domain.com переходит на сервер B.
Это было не так сложно настроить, и у нас было автоматическое переключение сервисов между сайтами.
Сложность в том, чтобы определить ограничения топологии вашей хостинговой компании, а также другие ваши требования к производительности, то есть какая пропускная способность у вашего сайта? Может, вам понадобится гигабитная пропускная способность?
По сути, вы говорите о том, чтобы изменить IP-адреса ваших выделенных серверов на частный диапазон, к которому вы не можете маршрутизировать (192.168.0.10 и 11 соответственно), а затем настроить их на другой размещенный сервер с несколькими общедоступными IP-адресами, которые выполняют переадресацию портов. . Таким образом, серверы A и B будут обмениваться данными на своем локальном коммутаторе через подсеть 192.x, и весь входящий интернет-трафик будет проходить через маршрутизатор / брандмауэр C. Вы должны выполнять NAT от маршрутизатора C к A и B соответственно, и ваш веб-сайт будет разрешаться как обычно. на один из IP-адресов на C. Это базовая настройка, и топка, вероятно, справится с этим нормально, хотя я думаю, что вам будет лучше с сервером на базе Linux для маршрутизации или пакетным решением, таким как Vyatta.
Ключевым моментом является проверка с вашей службой хостинга, потому что они могут не допускать этого, и если они этого не сделают, тогда ваши варианты могут быть ограничены брандмауэром на основе хоста или каким-либо другим относительно небезопасным решением. У вашего хостинг-провайдера также могут быть разные настройки для людей, которые хотят управлять своей собственной маршрутизацией и брандмауэром, это стоит уточнить у них.
Вы не упомянули, какое поведение брандмауэра вам нужно. Вы также не упомянули, какой трафик вы получаете на серверах. Итак, обо всем по порядку ...
Итак, помимо веб-сайтов, что еще происходит с серверами по отношению к сети? Кому и для чего нужен доступ к серверам? (т.е. вам нужен доступ по FTP, доступ по Telnet, доступ по SSH ...?)
Вы хотите / нужны только ограничения по портам? Например, если вы используете только порты 80/443 и SSH (порт 22) (без telnet, без FTP), то вы можете заблокировать доступ на всех портах, кроме этих. Добавьте электронную почту, и вам нужно открыть больше портов.
Вам нужна проверка пакетов с отслеживанием состояния? Если вы просто устанавливаете брандмауэр на указанные выше 3 порта и у вас нет почтового сервера, то, вероятно, у вас его нет. Но - если у вас есть пользователи на серверах (ой!) Или на почтовом сервере, тогда у вас будут гораздо более серьезные проблемы с брандмауэром, включая белые списки, черные списки, проверку пакетов с отслеживанием состояния, средства проверки на вирусы и т. Д.
Если все, что вам нужно, это блокировка всех портов, кроме трех ключевых портов (80/443/22), то, вероятно, будет достаточно одного сервера, на котором работает OpenBSD (намного, НАМНОГО БЕЗОПАСЕН, ЧЕМ ЛЮБОЙ LINUX BOX, IMO), на котором работает PF. Поместите веб-серверы на их собственные «немаршрутизируемые» статические IP-адреса и пусть PF окна OpenBSD маршрутизирует трафик по мере необходимости. Легко, дешево и просто.
Если вам нужен «полноценный» межсетевой экран с проверкой пакетов с полным отслеживанием состояния, фильтрацией электронной почты и спама и т. Д., То я рекомендую вам приобрести что-то более крупное от SonicWall.
Привет,
-Р