Назад | Перейти на главную страницу

топология сети, включающая множество сервисов

Я знаю, что это еще один вопрос, как настроить сеть, но я надеюсь, что вам еще не надоели такие вопросы.

Сайт также является офисом, поэтому он включает в себя windows dc, windows ad, exchange, sql, совместное использование файлов, серверы приложений для разработки и другие ПК.

Помимо офисных (внутренних) вещей, существуют как тестовая, так и производственная среда, состоящая из стека веб-сервер-приложение-сервер-sql. Существует также общедоступный ftp-сервис.

Я полагаю:

dmz1 - веб-сервер - Exchange Edge - ftp

dmz2 - сервер приложений - sql для сервера приложений

внутренний - постоянный ток и реклама - концентратор обмена и транспорт - внутренний обмен файлами - sql для внутреннего использования - серверы приложений для внутреннего использования - ПК

общедоступный -> dmz1, только веб, ftp и smtp общедоступный -> dmz2 невозможно общедоступный -> внутренний невозможно

dmz1 -> dmz2 возможен с веб-серверов на серверы приложений с использованием http или ajp dmz1 -> internal возможен только для обмена, в противном случае невозможно

dmz2 -> внутреннее невозможно

Это нормально? Есть другие рекомендации? Он будет настроен с использованием MS ISA или Jupiter SSG. Спасибо.

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

  • Очень тщательно оттачивайте правила брандмауэра. Как вы уже сказали, ваша DMZ2 недоступна из общедоступной или частной сети. Замечательно! Вы также заявили, что только определенные серверы могут получить доступ к некоторым другим серверам. Это даже лучше! Убедитесь, что только ваш сервер приложений может получить доступ к вашему SQL-серверу и даже в этом случае только на тех портах, которые вам нужны. Оттачивайте доступ к каждому узлу до самого атомарного уровня!
  • Собирайте журналы доступа со всех своих устройств и отслеживайте их на предмет событий. Возможно, использовать Splunk? Даже просто системный журнал. Убедитесь, что данные о доступе и трафике хранятся в долгосрочной перспективе. Узнайте, кто, когда и почему получает доступ к вашим устройствам.
  • Если возможно, включите сетевой анализ на своих устройствах. Netflow / sFlow. Собирайте данные и используйте программное обеспечение, способное отображать их значимым образом. Проанализируйте, какие типы данных поступают в вашу сеть, внутри и из нее. Если вас ничего не удивляет в посещаемости, которую вы видите, значит, вы недостаточно пристально смотрите.
  • Вы также должны отточить отдельные программные брандмауэры для каждой из этих машин, чтобы, если, возможно, ваши аппаратные брандмауэры скомпрометированы и / или введено ошибочное правило, программные брандмауэры также блокируют трафик, который вам не нужен.
  • Документируйте, пока у вас не потечет кровь из кончиков пальцев, не закроет глаза слезы, и вы не захотите нанести телесные повреждения человеку, который изобрел вики и хранилища контроля документов. Затем запишите еще немного. Вы попадаете в лабиринт извилистых коридоров. Вам нужно будет иметь такое ОКР с вашей документацией, что вам понадобятся палитры тофранила, капающего вам воздухом (пациенты с ОКР будут знать, что такое Тофранил .;)). Если кто-то из вашей команды не документирует должным образом в такой сложной сетевой среде, взорвите их.
  • Вы также можете рассмотреть возможность шифрования потоков данных, где это возможно. Что касается вашего веб-уровня, возможно, рассмотрите возможность шифрования потоков с помощью IPSEC. Я признаю, что это может быть немного излишним.

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

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

Вы на правильном пути! Отличная работа по сегментации вашей сети. Вы на голову выше своих сверстников. Теперь попробуй встать головой и плечи выше нормы.

Итак, вот мои 2 цента. Похоже, вы на правильном пути с сегментацией сети. Вот несколько мыслей.

Где будет сидеть ваша IDS? ЕСЛИ у вас есть 2 DMZ и внутренняя зона, то мне кажется, что вам нужны датчики IDS перед каждой из этих зон. Однако затем вам нужно разрешить трафик от ваших датчиков IDS в DMZ во внутреннюю зону.

И пока я занимаюсь этим, как вы предоставляете службы DNS для устройств в DMZ?

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

Да, это еще один из тех вопросов. Вы не очень конкретно описали свои потребности / цели. Ответ заключается в вашем ответе на такие вопросы, как (но не ограничиваясь ими):

Сколько пользователей?

Какие услуги вам нужно предоставить этим пользователям?

Какие услуги вам нужно предоставить внешнему миру?

Каковы бизнес-цели / требования для внедрения ИТ-инфраструктуры?

Что требует DRP \ BCP?

Et. И т. Д.

Ваш вопрос в его нынешней форме похож на вопрос:

Я пеку пирог. У меня есть яблоки, я подумываю использовать муку и сахар. Что вы думаете?