отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

Защита локальных серверов

Добрый день! Появился вопрос по построению защищенной сети. На рисунке представлена топология сети. Cisco ASA осуществляет подключение к сети Интернет (NAT), защищает DMZ зону и предоставляет удаленный доступ (RA VPN).

В качестве уровня распределения/ядра выступает стэк коммутаторов 3750-х. К стэку подключаются локальные сервера. Vlan-ы серверов маршрутизируются на 3750-х.

Вопрос: как защищать локальные сервера и разграничить доступ для локальных пользователей? На сколько корректно прописывать access list-ы на коммутаторах ядра? Можно было бы приземлить вланы серверов на ASA, но тогда снизится производительность сети... Или же необходимо установить еще один МЭ для локальных серверов?

Заранее спасибо.

network

1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

Утвержденные решения

Официальные рекомендации -

Официальные рекомендации - разумеется, фильтрация на ASA либо по SGT.

 

Но дизайн сети - вопрос индивидуальный. Если вам нужна лишь самая базовая фильтрация пакетов на уровне портов/протоколов; ASA станет узким местом в случае пропускания трафика через нее; нет серьезного management overhead от такой архитектуры и нет страха по поводу любых взглядов в сторону ядра, чтобы не упало (в случае стека - я бы на вашем месте боялся) - не вижу причин, почему бы и не сделать VLAN ACLи. Разумеется, если не делать глупостей вроде ACL logging, то никаких штрафов производительности не будет, да и глючить оно в теории от такого не должно, функционал этот один из самых базовых.

 

Можно делать ACLи на портах подключения серверов, но этот подход куда тяжелее в сопровождении. Зато можно не трогать ядро.

5 ОТВЕТ.

Почему бы и нет? Поместите

Почему бы и нет? Поместите ACL на int vlan серверов. Это будет не стейтфульная фильтрация как на ASA, и не будет возможности разграничивать доступ именно на уровне пользователей (только по IP адресам), но прикрыть те порты, которые пользователям заведомо не нужны, вполне можно.

New Member

Это понятно, что так можно

Это понятно, что так можно сделать. Но на сколько это корректно, списки доступа на коммутаторах ядра. Может есть какие-то рекомендации по данной теме.

Официальные рекомендации -

Официальные рекомендации - разумеется, фильтрация на ASA либо по SGT.

 

Но дизайн сети - вопрос индивидуальный. Если вам нужна лишь самая базовая фильтрация пакетов на уровне портов/протоколов; ASA станет узким местом в случае пропускания трафика через нее; нет серьезного management overhead от такой архитектуры и нет страха по поводу любых взглядов в сторону ядра, чтобы не упало (в случае стека - я бы на вашем месте боялся) - не вижу причин, почему бы и не сделать VLAN ACLи. Разумеется, если не делать глупостей вроде ACL logging, то никаких штрафов производительности не будет, да и глючить оно в теории от такого не должно, функционал этот один из самых базовых.

 

Можно делать ACLи на портах подключения серверов, но этот подход куда тяжелее в сопровождении. Зато можно не трогать ядро.

New Member

Спасибо за ответ! Хоть кто-то

Спасибо за ответ! Хоть кто-то на этом сайте отвечает)

Почему вы говорите что я должен бояться в случае стека? У меня все коммутаторы подключаются к стеку по EtherChannel, при этом в PortChannel входят порты с разных коммутаторов стека.

Сценарий отказа "один из

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

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

59
Просмотры
0
Полезный материал
5
Ответы