Топология сети, включая множество сервисов
Я знаю, что это еще один вопрос о том, как настроить сеть, но я надеюсь, что вам еще не надоели такие вопросы.
Сайт также является офисом, поэтому он включает в себя Windows DC, Windows Ad, Exchange, SQL, общий доступ к файлам, серверы приложений для разработки и другие шт.
В дополнение к офисным (внутренним) вещам существуют как тестовые, так и рабочие среды, состоящие из стека веб-сервер-приложение-сервер-sql. Существует также служба FTP, открытая для общественности.
Я полагаю:
dmz1 - веб-сервер - край обмена - ftp
dmz2 - сервер приложений - sql для сервера приложений
внутренняя - dc и ad - exchange hub and transport - внутренний файлообменник - sql для внутреннего использования - серверы приложений для внутреннего использования - шт
public -> dmz1, только web, ftp и smtp public -> dmz2 невозможен public -> внутренний невозможен
dmz1 -> dmz2 возможен с веб-серверов на серверы приложений с использованием http или ajp. dmz1 -> internal возможен только для обмена, в противном случае это невозможно
dmz2 -> внутренняя невозможна
Это звучит нормально? Любые другие рекомендации? Он будет настроен с использованием MS ISA или Jupiter SSG. Спасибо.
3 ответа
Итак, вот мои 2 цента. Вы, кажется, находитесь на правильном пути с сегментации сети. Вот несколько мыслей.
Где будут сидеть ваши IDS? Если у вас есть 2 демилитаризованных зоны и внутренняя зона, то мне показалось бы, что вы хотите использовать датчики IDS перед каждой из этих зон. Однако тогда вам необходимо разрешить трафик от ваших датчиков IDS в DMZ во внутреннюю зону.
И пока я на этом, как вы предоставляете услуги DNS для устройств в DMZ.
Еще одна мысль, которая может быть очень подозрительной и надежно блокировать ваш публичный FTP-сервер.
С общей точки зрения, похоже, что вы провели тщательную проверку всей вашей сети. Вот некоторые вещи, которые я бы порекомендовал вам иметь в виду:
- Отточите правила вашего брандмауэра очень осторожно. Как вы уже заявили, ваш DMZ2 недоступен из общедоступной или частной сети. Замечательно! Вы также заявили, что только определенные серверы могут получить доступ к определенным другим серверам. Это даже лучше! Убедитесь, что только ваш сервер приложений может получить доступ к вашему SQL-серверу и даже только на тех портах, которые вам нужны. Отточите каждый доступ к узлу до самого атомного уровня!
- Соберите журналы доступа со всех ваших устройств и следите за их событиями. Возможно, использовать Splunk? Даже просто системный журнал. Убедитесь, что данные доступа и трафика хранятся в течение длительного времени. Проверьте, кто имеет доступ к вашим устройствам, когда и почему.
- Включите анализ сети на ваших устройствах, если это возможно.NETflow / sFlow. Соберите данные и используйте программное обеспечение, которое способно отображать их осмысленно. Анализируйте, какие типы данных поступают в вашу сеть и из нее. Если ничто не удивляет вас в трафике, который вы видите, вы не выглядите достаточно усердно.
- Вам также следует настроить отдельные программные брандмауэры для каждой из этих машин, чтобы, если, возможно, ваши аппаратные брандмауэры были скомпрометированы и / или введено ошибочное правило, программные брандмауэры также блокировали трафик, который вам не нужен.
- Документируйте до тех пор, пока у вас не начнут кровоточить кончики пальцев, слезы на глазах и вы захотите нанести телесные повреждения человеку, который изобрел вики и хранилища документов для контроля. Тогда документируйте еще немного. Вы входите в лабиринт извилистых проходов всех одинаково. Вы должны быть настолько ОКР со своей документацией, что вам понадобятся палитры тофранила, сброшенные вам в воздух (пациенты с ОКР будут знать, что такое тофранил;)). Если кто-то в вашей команде не документирует должным образом в такой сложной сетевой среде, пометьте его.
- Вы также можете рассмотреть возможность шифрования потоков данных, где это возможно. Что касается вашего веб-уровня, возможно, стоит подумать о шифровании потоков с помощью IPSEC. Это может быть немного излишним, я признаю.
Конечная цель состоит не только в том, чтобы сузить поверхность атаки, но и в том, чтобы отслеживать трафик, который пытается коснуться как недоступных, так и доступных поверхностей. Это немного похоже на то, чтобы убедиться, что в банке есть все лучшие замки, сейфы и мантрапы, но потом никогда не следить за оборудованием, чтобы узнать, не пытается ли кто-нибудь совершить ограбление. Предположим, что при достаточном количестве времени без присмотра каждый может сделать что угодно.
Ваш веб и сервер базы данных похожи на золотые флаконы с нитро глицерином. Предположим, что все хотят их для своей выгоды, а также хотят взорвать ваше лицо с ними в процессе. Действительно, любое публичное устройство есть.
Вы на правильном пути! Отличная работа в сегментации вашей сети. Ты на голову выше своих сверстников. Теперь постарайтесь стоять на голову выше нормы.
Да, это еще один из тех вопросов. Вы не очень точно описали свои потребности / цели. Ответ заключается в вашем ответе на такие вопросы, как (но не ограничиваясь):
Сколько пользователей?
Какие услуги вам необходимо предоставить этим пользователям?
Какие услуги вам необходимо предоставить внешнему миру?
Каковы бизнес-цели / требования для внедрения ИТ-инфраструктуры?
Что требуется DRP\BCP?
И т. Д.
Ваш вопрос в его нынешней форме похож на вопрос:
Я испекаю пирог. У меня есть несколько яблок, и я думаю об использовании муки и сахара. Как вы думаете?