Как взять сетевую инфраструктуру под свой контроль. Глава третья. Сетевая безопасность. Часть третья

Эта статья является пятой в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.

Эта часть будет посвящена Campus (Office) & Remote access VPN сегментам.

Может показаться, что дизайн офисной сети – это просто.

Действительно, берем L2/L3 коммутаторы, соединяем их между собой. Далее, производим элементарную настройку виланов, шлюзов по умолчанию, поднимаем простой роутинг, подключаем WiFi контроллеры, точки доступа, устанавливаем и настраиваем ASA для удаленного доступа, радуемся, что все заработало. В принципе, как я уже писал в одной из предыдущих статей этого цикла, спроектировать и настроить офисную сеть, чтобы «как-то работало», может почти каждый студент, прослушавший (и усвоивший) два семестра курса по телекому.

Но чем больше вы узнаете, тем менее простой начинает казаться эта задача. Лично для меня эта тема, тема дизайна офисной сети, совсем не кажется простой, и в этой статье я постараюсь объяснить почему.

Если коротко, то нужно учитывать довольно много факторов. Часто эти факторы находятся в противоречии друг с другом и приходится искать разумный компромисс.
Вот эта неопределенность и является основной сложностью. Так, говоря про безопасность, мы имеем треугольник с тремя вершинами: безопасность, удобство для сотрудников, цена решения.
И каждый раз приходится искать компромисс между этими тремя.

Архитектура

В качестве примера архитектуры для этих двух сегментов я, как и в предыдущих статьях, рекомендую Cisco SAFE модель: Enterprise Campus, Enterprise Internet Edge.

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

Не призывая вас использовать именно Cisco решения, я все же считаю полезно внимательно изучить этот дизайн.

Данная статья, как обычно, ни в коей мере не претендуя на полноту, является скорее дополнением к данной информации.

В конце статьи, мы проанализируем дизайн Cisco SAFE для офиса с точки зрения концепций, изложенных здесь.

Общие принципы

Дизайн офисной сети, конечно, должен удовлетворять общим требованиям, которые рассматривались здесь в главе «Критерии оценки качества дизайна». Помимо цены и безопасности, которые мы намерены обсудить в этой статье, остаются еще три критерия, которые мы должны учитывать при проектировании (или при внесении изменений):

• масштабируемость (scalability)
• удобство в управлении (managability)
• доступность (availability)

Многое из того, что обсуждалось для дата-центров также является справедливым и для офиса.

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

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

И это только одна сторона проблемы (а точнее одна вершина треугольника). На другой стороне — удобство пользователя и цена применяемых решений.

Давайте начнем с рассмотрения того, что пользователь ожидает от современной офисной сети.

Удобства

Вот как на мой взгляд выглядят «сетевые удобства» для пользователя офиса:

• Мобильность
• Возможность пользоваться всем спектром привычных устройств и операционных систем
• Легкий доступ ко всем необходимым ресурсам компании
• Доступность интернет ресурсов, в том числе и различных облачных сервисов
• «Быстрая работа» сети

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

Давайте рассмотрим чуть подробней каждый из этих аспектов.

Мобильность

Речь идет о возможности работать и пользоваться всеми необходимыми ресурсами компании из любой точки мира (конечно, где доступен интернет).

В полной мере это относится и к офису. Это удобно, когда из любой точки офиса вы имеете возможность продолжать работать, например, получать почту, вести общение в корпоративном мессенджере, быть доступным для видео звонка, … Таким образом, это позволяет вам, с одной стороны, решать некоторые вопросы через «живое» общение (например, участвовать в митингах), а с другой — быть всегда онлайн, держать руку на пульсе и быстро решать некоторые срочные высокоприоритетные задачи. Это очень удобно и, действительно, улучшает качество коммуникаций.

Это достигается правильным дизайном WiFi сети.

Замечание

Здесь обычно возникает вопрос, а достаточно ли использовать только WiFi? Значит ли это, что можно отказаться от использования Ethernet портов в офисе? Если речь идет только о пользователях, а не о серверах, которые, все же разумно подключать обычным Ethernet портом, то в общем виде ответ: да, можно ограничиться только WiFi. Но есть нюансы.

Есть важные группы пользователей, к которым требуется отдельный подход. Это, конечно же, администраторы. В принципе, WiFi подключение является менее надежным (с точки зрения потери трафика) и менее скоростным, чем обычный Ethernet порт. Это может быть существенно для администраторов. К тому же у сетевых администраторов, например, в принципе может быть своя выделенная Ethernet сеть для out-of-band подключения.

Возможно, в вашей компании найдутся и другие группы/отделы, для которых эти факторы также важны.

Есть еще один важный момент – телефония. Возможно, по каким-либо причинам вы не хотите пользоваться Wireless VoIP и хотите использовать IP телефоны со обычным Ethernet подключением.

В общем, в тех компаниях в которых работал я, обычно была возможность как WiFi подключения, так и Ethernet портом.

Хотелось бы, чтобы мобильность не ограничивалась только офисом.

Для обеспечения возможности работы из дома (или любого другого места с доступным интернетом) используется VPN подключение. При этом, желательно, чтобы сотрудники не чувствовали разницу между работой из дома и удаленной работой, что предполагает наличие тех же доступов. Как это организовать мы будем обсуждать чуть позже в главе «Единая централизованная система аутентификации и авторизации».

Замечание

Скорее всего, вам не удастся полностью предоставить то же качество сервисов для удаленной работы, какие вы имеете в офисе. Давайте предположим, что в качестве VPN шлюза вы используете Cisco ASA 5520. В соответствии с data sheet это устройство способно «переварить» лишь 225 Мбит VPN трафика. То есть, конечно, с точки зрения пропускной способности подключение по VPN сильно отличается от работы из офиса. Также если, по каким-то причинам, задержка, потери, джиттер (например, вы хотите пользоваться офисной IP телефонией) для ваших сетевых сервисов являются существенными, вы также не получите того же качества, как если бы вы находились в офисе. Поэтому, говоря о мобильности, мы должны помнить о возможных ограничениях.

Легкий доступ ко всем ресурсам компании

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

Замечание 1

Удобство доступа — это не только о том, сколько раз вам приходится вводить пароль. Если, например, в соответствии с вашей политикой безопасности, для подключения из офиса к дата-центру вы должны сначала подключиться к VPN шлюзу, и при этом вы теряете доступы к офисным ресурсам, то это тоже очень и очень неудобно.

Замечание 2

Существуют сервисы (например, доступ к сетевому оборудованию), где мы обычно имеем свои выделенные AAA сервера и это норма, когда в этом случае приходится аутентифицироваться несколько раз.

Доступность интернет ресурсов

Интернет — это не только развлечение, но также и набор сервисов, который может быть весьма полезен для работы. Есть еще и чисто психологические факторы. Современный человек через интернет многими виртуальными ниточками связан с другими людьми, и, на мой взгляд, нет ничего плохого, если он продолжает чувствовать эту связь даже во время работы.

С точки зрения потери времени, нет ничего страшного, если у сотрудника, например, запущен скайп, и он потратит 5 минут на общение с близким человеком при необходимости.

Значит ли это, что интернет всегда должен быть доступен, значит ли это, что сотрудникам можно открывать доступ ко всем ресурсам и никак не контролировать их?

Нет не значит, конечно. Уровень открытости интернета может быть разным для разных компаний – от полной закрытости до полной открытости. Способы контроля за трафиком мы обсудим позже в разделах, посвященным средствам защиты.

Возможность пользоваться всем спектром привычных устройств

Удобно, когда вы, например, имеете возможность продолжать пользоваться всеми привычными вам средствами коммуникации и на работе. Нет сложности технически реализовать это. Для этого нужен WiFi и гостевой вилан.

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

Пример

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

«Быстрая работа» сети

Скорость передачи данных технически складывается из многих факторов. И скорость вашего порта подключения обычно не самый важный из них. Не всегда медленная работа приложения связана с сетевыми проблемами, но нас сейчас интересует только сетевая часть. Наиболее частая проблема «замедления» работы локальной сети связана с потерей пакетов. Это обычно происходит при наличии эффекта «бутылочного горлышка» или при L1 (OSI) проблемах. Реже, при некоторых дизайнах, (например, когда в качестве шлюзов по умолчанию в ваших подсетях выступает фаервол и, таким образом, весь трафик идет через него), может не хватать производительности оборудования.

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

Пример

Предположим, вы используете в качестве коммутаторов уровня доступа коммутаторы с 1 гигабитными портами. Между собой они соединены через Etherchannel 2 x 10 гигабит. В качестве шлюза по умолчанию вы используете фаервол с гигабитными портами, для подключения которого к L2 сети офиса вы используете 2 гигабитных порта, объединенными в Etherchannel.

Данная архитектура достаточно удобна с точки зрения функциональности, т.к. весь трафик проходит через фаервол, и вы можете комфортно управлять политиками доступа, и применять сложные алгоритмы контроля трафика и предотвращения возможных атак (см. дальше), но с точки зрения пропускной способности и производительности этот дизайн, конечно, имеет потенциальные проблемы. Так, например, 2 хоста, качающие данные (со скоростью порта в 1 гигабит) могут полностью загрузить 2 гигабитное подключение к фаерволу, и таким образом привести к деградации сервиса для всего офисного сегмента.

Мы рассмотрели одну вершину треугольника, теперь давайте рассмотрим, какими средствами мы можем обеспечить безопасность.

Средства защиты

Итак, конечно, обычно, наше желание (а точнее, желание нашего руководства) — это достичь невозможного, а именно, предоставить максимальное удобство при максимальной защищенности и минимальной цене.

Давайте рассмотрим, какие у нас есть методы для предоставления защиты.

Для офиса я бы выделил следующие:

• zero trust подход в дизайне
• высокий уровень защиты
• network visibility
• единая централизованная система аутентификации и авторизации
• проверка хоста (host checking)

Далее остановимся чуть подробнее на каждом из этих аспектов.

Zero Trust

IT мир меняется очень быстро. Буквально за последние 10 лет появление новых технологий и продуктов привели к серьезному пересмотру концепций безопасности. Еще десять лет назад с точки зрения безопасности мы сегментировали сеть на trust, dmz и untrust зоны, и применялась так называемая «защита по периметру», где было 2 линии обороны: untrust -> dmz и dmz -> trust. Также защита обычно ограничивалась списками доступа на основе L3/L4 (OSI) заголовков (IP, TCP/UDP порты, TCP флаги). Все, что касалось более высоких уровней, в том числе и L7, отдавалось на откуп ОС и продуктам защиты, устанавливаемых на конечных хостах.

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

• remote access VPN пользователей
• различные личные гаджеты, принесенные ноутбуки, подключаемые через офисный WiFi
• другие (branch) офисы
• интеграцию с облачной инфраструктурой

Как выглядит Zero Trust подход на практике?

В идеале, разрешен должен быть только тот трафик, который требуется и, если уж мы говорим об идеале, то контроль должен быть не только на уровне L3/L4, но на уровне приложения.

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

При контроле же трафика на маршрутизаторе или L3 коммутаторе (использование стандартных ACL) вы сталкиваетесь с другими проблемами:

• это только L3/L4 фильтрация. Ничто не мешает злоумышленнику использовать разрешенные порты (например, TCP 80) для своего приложения (не http)
• сложный менеджмент ACL (трудно анализировать ACL)
• это не statefull фаервол, то есть вам нужно явно разрешать реверсный трафик
• в случае коммутаторов вы обычно довольно жестко ограничены размером TCAM, что в случае применения подхода «разрешать только то, что нужно» может быстро стать проблемой

Замечание

Говоря про реверсный трафик, мы должны помнить, что у нас есть следующая возможность (Cisco)

permit tcp any any established

Но надо понимать, что эта строчка равносильна двум строчкам:
permit tcp any any ack
permit tcp any any rst

Что означает, что даже если не было изначального TCP сегмента с SYN флагом (то есть TCP сессия даже не начинала устанавливаться) этот ACL пропустит пакет с флагом ACK, чем злоумышленник может воспользоваться для передачи данных.

То есть эта строчка ни в коей мере не превращает ваш роутер или L3 коммутатор в statefull фаервол.

Высокий уровень защиты

В статье в разделе, посвященном дата-центрам, мы рассматривали следующие способы защиты.

• stateful firewalling (по умолчанию)
• ddos/dos protection
• application firewalling
• threat prevention (antivirus, anti-spyware, and vulnerability)
• URL filtering
• data filtering (content filtering)
• file blocking (file types blocking)

В случае офиса ситуация похожая, но приоритеты немного другие. Доступность офиса (availabilty) обычно не так критична, как в случае дата-центра, в то время как вероятность «внутреннего» вредоносного трафика на порядки выше.
Поэтому следующие методы защиты для данного сегмента становятся критичными:

• application firewalling
• threat prevention (anti-virus, anti-spyware, and vulnerability)
• URL filtering
• data filtering (content filtering)
• file blocking (file types blocking)

Хотя все эти методы защиты, за исключением application firewalling, традиционно решались и продолжают решаться на конечных хостах (например, установкой антивирусных программ) и с помощью proxy, современные NGFW также предоставляют эти сервисы.

Вендоры security оборудования стремятся к созданию комплексной защиты, поэтому наряду с защитой на локальной коробке, предлагаются различные облачные технологии и клиентский софт для хостов (end point protection/ EPP). Так, например, из Магического Квадранта Гартнера (Gartner Magic Quadrant) за 2018 год мы видим, что Palo Alto и Cisco имеют свои EPP (PA: Traps, Cisco: AMP), но находятся далеко не в лидерах.

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

• в данном случае появляется единая точка применения методов защиты, что улучшает visibility (см. следующую тему).
• если в вашей сети оказалось незащищенное устройство, то оно все равно попадает под «зонтик» защиты фаервола
• используя защиты на фаерволе совместно с защитой на конечных хостах, мы увеличиваем вероятность обнаружения вредоносного трафика. Например, использование threat prevention на локальных хостах и на фаерволе увеличивает вероятность обнаружения (при условии, конечно, что в основе этих решений лежат разные программные продукты)

Замечание

Если, например, в качестве антивируса как на фаерволе, так и на конечных хостах вы используете Касперский, то это, понятно, не сильно увеличит ваши шансы предотвратить вирусную атаку в вашей сети.

Network visibility

Основная идея проста – «видеть», что происходит в вашей сети, как в реальном времени, так и исторические данные.

Я бы разделил это «видение» на две группы:

Группа первая: то что обычно предоставляет вам ваша система мониторинга.

• загрузка оборудования
• загрузка каналов
• использование памяти
• использование дисков
• изменение таблицы маршрутизации
• состояние линков
• доступность оборудования (или хостов)
• …

Группа вторая: информация, связанная с безопасностью.

• различного рода статистика (например, по приложениям, по посещаемости URL, какие виды данных скачивались, данные по пользователям)
• что было заблокировано политиками безопасности и по какой причине, а именно
  • запрещенное приложение
  • запрещено на основе ip/protocol/port/flags/zones
  • threat prevention
  • url filtering
  • data filtering
  • file blocking
  • …
• статистика по DOS/DDOS атакам
• неудачные попытки идентификации и авторизации
• статистика по всем вышеперечисленным событиям нарушения политик безопасности
• …

В данной главе, посвященной безопасности, нас интересует именно вторая часть.

Некоторые современные фаерволы (из моей практики Palo Alto) предоставляют хороший уровень visibility. Но, конечно, трафик, который вас интересует должен идти через этот фаервол (в этом случае у вас есть возможность блокировки трафика) или зеркалироваться на фаервол (используется только для мониторинга и анализа), и у вас должны быть лицензии, позволяющие включить все эти сервисы.

Есть, конечно, и альтернативный путь, ну а точнее традиционный путь, например,

• статистику по сессиям можно собирать через netflow и потом использовать специальные утилиты для анализа информации и визуализации данных
• threat prevention – специальные программы (anti-virus, anti-spyware, firewall) на конечных хостах
• URL filtering, data filtering, file blocking – на proxy
• также можно анализировать tcpdump с помощью, например, snort

Можно совместить эти два подхода, дополняя недостающие функции или дублируя их для повышения вероятности обнаружения атаки.

Какой подход выбрать?
Сильно зависит от квалификации и предпочтений вашей команды.
И там, и там есть плюсы и минусы.

Единая централизованная система аутентификации и авторизации

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

Пример

• Вы разбили всех сотрудников на группы. Вы решили предоставлять доступы по группам
• Внутри офиса вы контролируете доступы на офисном фаерволе
• Трафик из офиса в дата-центр вы контролируете на фаерволе дата-центра
• В качестве VPN шлюза вы используете Cisco ASA и для контроля трафика, входящего в вашу сеть от уделенных клиентов, вы применяете локальные (на ASA) ACL

Теперь, предположим, вас просят добавить дополнительный доступ определенному сотруднику. При этом вас просят добавить доступ только ему и больше никому из его группы.

Для этого мы должны создать отдельную группу для этого сотрудника, то есть

• на ASA создать отдельный IP пул для этого сотрудника
• добавить новый ACL на ASA и привязать его к этому удаленному клиенту
• создать новые security policy на офисном и дата-центр фаерволах

Хорошо, если это событие редкое. Но в моей практике была ситуация, когда сотрудники участвовали в разных проектах, и этот набор проектов для некоторых из них менялся довольно часто, и это было не 1 -2 человека, а десятки. Конечно, здесь нужно было что-то менять.

Это было решено следующим способом.

Мы решили, что единственным источником истины, определяющим все возможные доступы сотрудника будет LDAP. Мы создали всевозможные группы, которые определяют наборы доступов и каждого пользователя мы привязывали к одной или нескольким группам.

Так, например, предположим, что были группы

• guest (доступ в Интернет)
• common access (доступы к общим ресурсам: почта, база знаний, …)
• accounting
• project 1
• project 2
• data base administrator
• linux administrator
• …

И если кто-то из сотрудников был задействован, как в проекте 1, так и в проекте 2, и ему требовались доступы необходимые для работы в этих проектах, то этот сотрудник привязывался к соответственно к группам:

• guest
• common access
• project 1
• project 2

Как же теперь эту информацию превратить в доступы на сетевом оборудовании?

Cisco ASA Dynamic Access Policy (DAP) (см. www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/108000-dap-deploy-guide.html) решение как раз подходит для этой задачи.

Если коротко о нашей реализации, то в процессе идентификации/авторизации ASA получает от LDAP набор групп, соответствующих данному пользователю и «собирает» из нескольких локальных ACL (каждый из которых соответствует группе) динамический ACL со всеми необходимыми доступами, что полностью соответствует нашим пожеланиям.

Но это ведь только для VPN подключений. Чтобы сделать ситуацию одинаковой как для сотрудников, подключенных через VPN, так и для находящихся в офисе был сделан следующий шаг.

При подключении из офиса, пользователи при помощи протокола 802.1x попадали либо в гостевой вилан (для гостей), или в вилан с общими доступами (для сотрудников компании). Далее, для получения специфичных доступов (например, к проектам в дата-центре) сотрудники должны были подключаться по VPN.

Для подключения из офиса и из дома применялись разные туннельные группы на ASA. Это необходимо для того, чтобы для подключившихся из офиса трафик к общим ресурсам (используемым всеми сотрудниками, таким как почта, файловые сервера, тикетная система, dns, …) ходил не через ASA, а через локальную сеть. Таким образом, мы не загружали ASA лишним трафиком, в том числе и высокоинтенсивным.

Таким образом, задача была решена.
Мы получили

• одинаковый набор доступов, как для подключений из офиса, так и для удаленного подключения
• отсутствие деградации сервиса при работе из офиса, связанного с передачей высокоинтенсивного трафика через ASA

В чем еще преимущество данного подхода?
В администрировании доступов. Доступы легко изменяются, в одном месте.
Например, если сотрудник покинул компанию, то вы просто удаляете его из LDAP, и он автоматически теряет все доступы.

Проверка хоста (host checking)

При возможности удаленного подключения мы получаем риск допустить в сеть не только сотрудника компании, но также и весь вредоносный софт, который с немалой вероятностью присутствует на его компьютере (например, домашнем), и более того, через этот софт мы, возможно, открываем доступ в нашу сеть злоумышленнику, использующему данный хост как прокси.

Разумно для хоста, подключаемого удаленно, применять те же требования к безопасности, что и к хосту, находящемся в офисе.

Это в том числе предполагает и «правильную» версию ОС, anti-virus, anti-spyware, и firewall software и обновлений. Обычно, эта возможность существует на VPN шлюзе (для ASA смотри, например, здесь).

Также разумно применить те же методы анализа и блокировки трафика (см «Высокий уровень защиты»), что в соответствии с вашей политикой безопасности применяется к офисному трафику.

Разумно исходить из предположения, что теперь ваша офисная сеть не ограничивается офисным зданием и хостами, находящимися в нем.

Пример

Хороший прием – снабдить каждого сотрудника, которому требуется удаленный доступ, хорошим, удобным ноутбуком и потребовать работать, как в офисе, так и из дома только с него.

Это не только повышает уровень безопасности вашей сети, но также действительно удобно и обычно воспринимается сотрудниками положительно (если это действительно хороший и удобный ноутбук).

О чувстве меры и балансе

В принципе, это разговор о третьей вершине нашего треугольника — о цене.
Давайте рассмотрим гипотетический пример.

Пример

У вас офис на 200 человек. Вы решили сделать его максимально удобным и максимально безопасным.

Поэтому весь трафик вы решили пропускать через фаервол и таким образом для всех подсетей офиса фаервол является шлюзом по умолчанию. Кроме security софта, установленного на каждый конечный хост (anti-virus,  anti-spyware, and firewall software), вы также решили применить все возможные методы защиты на фаерволе.

Для обеспечения высокой скорости подключения (все для удобства) в качестве коммутаторов доступа вы выбрали коммутаторы с 10-гигабитными портами доступа, в качестве фаерволов — высокопроизводительные NGFW фаерволы, например, Palo Alto серии 7K (c 40 гигабитными портами), естественно со всеми включенными лицензиями и, естественно, High Availability пару.

Также, конечно, для работы с этой линейкой оборудования нам нужны хотя бы парочка высококвалифицированных security инженеров.

Далее, каждому сотруднику вы решили выдать по хорошему ноутбуку.

Итого, порядка 10 миллионов долларов на внедрение, сотни тысяч долларов (думаю ближе к миллиону) на ежегодную поддержку и зарплаты инженерам.

Офис, 200 человек…
Удобно? Наверно, да.

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

Утрирован ли этот пример? Следующая глава даст ответ на этот вопрос.

Если в вашей сети, вы не видите чего-то из перечисленного выше, то это норма.
Для каждого конкретного случая вам нужно найти свой разумный компромисс между удобством, ценой и безопасностью. Часто даже не требуется NGFW в вашем офисе, не требуется L7 защита на фаерволе. Достаточно обеспечить хороший уровень visibility и оповещений, и это может быть сделано с использование open source продуктов, например. Да, ваша реакция на атаку не будет мгновенной, но главное, что вы ее увидите, и при наличии правильных процессов в вашем отделе сумеете быстро нейтрализовать ее.

И, напомню, что по замыслу цикла этих статей, вы не занимаетесь проектированием сети, вы лишь пытаетесь улучшить то, что вам досталось.

Анализ SAFE архитектуры офиса

Обратите внимание на этот красный квадрат, которым я выделил место на схеме из SAFE Secure Campus Architecture Guide, которое я бы хотел здесь обсудить.

Это одно из ключевых мест архитектуры и одна из самых важных неопределенностей.

Замечание

Я никогда не настраивал и не работал с FirePower (из линейки фаерволов Cisco — только с ASA), поэтому я буду рассматривать его, как любой другой фаервол, например, как Juniper SRX или Palo Alto, предполагая, что у него есть те же возможности.

Из обычных конструкций я вижу только 4 возможных варианта использования фаервола при таком подключении:

• шлюзом по умолчанию для каждой подсети является коммутатор, при этом фаервол находится в transparent моде (то есть весь трафик идет через него, но он не образует L3 хоп)
• шлюзом по умолчанию для каждой подсети являются саб-интерфейсы фаервола (или SVI интерфейсы), коммутатор играет роль L2
• на коммутаторе используются разные VRF, и трафик между VRF идет через фаервол, трафик внутри одного VRF контролируется ACL на коммутаторе
• весь трафик зеркалируется на фаервол для анализа и мониторинга, трафик через него не идет

Замечание 1

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

Замечание2

Еще есть возможность использования PBR (архитектура service chain), но пока это, хотя и красивое на мой взгляд решение, является скорее экзотикой, поэтому я не рассматриваю его здесь.

Из описания потоков в документе мы видим, что все же трафик идет через фаервол, то есть, в соответствии с дизайном Cisco четвертый вариант отпадает.

Давайте рассмотрим сначала первые два варианта.
При этих вариантах весь трафик идет через фаервол.

Теперь смотрим data sheet, смотрим Cisco GPL и видим, что если мы хотим суммарную полосу пропускания для нашего офиса иметь хотя бы в районе 10 — 20 гигабит, то мы должны покупать 4K версию.

Замечание

Когда я говорю про суммарную полосу я имею ввиду трафик между подсетями (а не внутри одного вилана).

Из GPL мы видим, что для HA Bundle с Threat Defense цена в зависимости от модели (4110 — 4150) варьируется от ~0,5 — 2,5 млн. долларов.

То есть наш дизайн начинает напоминать предыдущий пример.

Значит ли это, что этот дизайн неверный?
Нет, не значит. Cisco предоставляет вам максимально возможную защиту на основе линейки продуктов, которую она имеет. Но это не значит, что это «маст-ду» для вас.

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

Например, не весь трафик пускать через фаервол, и в этом случае 3-ий вариант мне кажется довольно симпатичным, или (см. предыдущий раздел), возможно, вам не нужна «Threat Defense» или вообще не нужен фаервол в этом сегменте сети, и вам достаточно ограничиться пассивным мониторингом с использованием платных (не дорогих) или open source решений, или фаервол нужен, но другого вендора.

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

Источник: habr.com