Настройка Cisco ASA: интерфейсы, NAT и фильтрация

Смотрите, по настройке ASA. Интерфейс который будет GigabitEthernet 0/0, он будет смотреть на роутер. Это будет outside интерфейс, у него будет давайте единичку, потом роутер настроим по- другому. У него будет 10.1.номер_комплекта.1, то есть у меня будет 10.1.1.1, будет 10.1.2.1, 10.1.3.1 и так далее. Интерфейс GigabitEthernet 0/1 смотрит на наш Windows, это будет у нас интерфейс inside. Пока давайте настроим пару интерфейсов. Есть ещё management интерфейс, но мы его трогать не будем. На самом деле нам хватит этих двух. Management интерфейс — это выделенный интерфейс, у вас в том числе и

виртуальный. Мы работаем с виртуальной ASA на нашем стенде. Можно и нужно именно этот интерфейс использовать для управления, хотя никто не запрещает нам использовать любой из интерфейсов для управления ASA. Давайте потихонечку всё это дело настраивать, сейчас будем смотреть как всё это работает. Во-первых, первоначальные действия которые нам нужно сделать — это просто назвать нашу ASA. Режим enable по умолчанию не требует никакого пароля, он просто пустой. Пароль набираем и входим в привилегированный режим. Поехали конфигурировать. conf t, и здесь нас просят: хотите ли вы отправлять сообщения об ошибках? Нет, конечно, не хотим, нам сейчас не до этого. Тот же самый hostname, давайте назовём красиво: у меня будет ASA1, у вас будет как-то по-другому. Давайте настраивать наши интерфейсы. Напоминаю, у нас 0/0 — outside, 0/1 — inside.

Давайте начнём с outside. Как всё это дело настраивается: interface GigabitEthernet 0/0. Практически ничего нового. Сразу же лучше назвать именно интерфейс, а потом делать все остальные настройки, чтобы не забыть про это. Есть команда nameif, которая задаёт имя нашего интерфейса. Я привык всё писать большими буквами, чтобы нигде не запутаться — все эти сущности, которые я задаю. У меня он будет называться OUTSIDE. Обратите внимание, что ASA сразу нам отправила сообщение, что security level, вот этот самый уровень безопасности, для интерфейса outside установлен в ноль. Установлен именно 0 по умолчанию. У вас есть зарезервированные имена inside и outside, она для них знает уже какой уровень

безопасности ставить. Назвали inside — он поставит другой, назвали outside — будет нулевой. Собственно, мы к этому и стремимся: outside — снаружи к нам ничего не придёт. IP-адреса, которые мы с вами делаем, я ещё раз сверю со схемкой: 10.1.1.0, у вас там будет другой — 10.1.1.1, масочку задаём. И нам достаточно сказать no shutdown. После этого интерфейс у нас должен работать в поднятом состоянии. Как всё это проверять? Наша любимая команда show ip interface brief здесь работать не будет, а немножечко по-другому выглядит. У нас она show interface ip brief — вот такая команда. Я её запоминал в своё время не знаю очень-очень долго и постоянно путался. Просто запомните, что interface ip. Здесь у ASA очень много команд. В роутере мы привыкли, что ip что-то

такое набирать — ip route. Здесь немножечко по-другому команды выглядят. Дальше второй интерфейс настраиваем: interface GigabitEthernet 0/1. Он у нас будет называться nameif INSIDE, и сразу же ASA по заранее определённому имени интерфейса нам поставила по умолчанию уровень безопасности 100. Это очень удобно. Дальше no shutdown сказать — и всё, этого достаточно для настройки парочки. А IP-адрес-то забыл! IP-адрес у нас здесь будет 10.2.номер_комплекта.1 — 10.2.1.1. Этого достаточно. Всякие команды типа ping 10.2.1.1 — на роутерах надо

было писать do ping всё время постоянно, а здесь просто это работает. В принципе, набрав команду в любом контексте, она будет обработана. ASA будет вот таким образом: сначала она будет проверять в контексте интерфейса, если команда ping. Если нет, она будет дальше выше на контекст выпрыгивать и смотреть там. Если в контексте настройки такой команды нет, она потом уже будет в exec-режиме её искать. По какой схеме топологии работаем? У нас одна топология, у нас нет management интерфейса здесь. У меня два интерфейса на разных адресах. Я не роутер пинговал, я сам себя пинговал.

По поводу show ip route — здесь половина команд, которые в роутере у нас были show ip, здесь практически ничего не будет работать. У нас будет просто без ip. Тот же show ip route здесь превращается в show route. По поводу роутинга: в наш курс не входят никакие вещи с роутингом, но как пример, как задаётся у ASA маршрут по умолчанию — сейчас, секундочку, пожалуйста. Сейчас запись продолжим. show route — я сказал по поводу именно имён интерфейсов. Во-первых, надо будет не лишним как посмотреть: show run interface g0/0. Вот здесь у нас будет настроен, главное чтобы он

был настроен. Смотрите, тот же самый роутинг, например: простейшее задание статического маршрута здесь будет не ip route, а просто route. Ему нужно всегда указывать имя интерфейса. Здесь роутинг задаётся не как на классических роутерах, просто ip route такая-то сеть через такой-то шлюз мы идём, а здесь нужно именно указать, через какой интерфейс мы будем идти. Та же самая настройка default gateway будет у нас выглядеть именно вот так: route outside 0 0 0 0 0 0 0 0 через наш роутер 10.1.1.2. Вот таким образом указываются все маршруты, нужно обязательно указать интерфейс, и интерфейс указывается по имени. В таблице маршрутизации мы будем с вами всегда видеть имя интерфейса, поэтому с самого начала, когда будете настраивать ASA, обязательно задавайте имена интерфейсов.

Почему он не видит, в какой интерфейс отправить? Здесь нет — просто так работает ASA, просто вот такая концепция, что мы указываем интерфейс. У меня пингуется ASA и роутер, смотрите, пожалуйста. Народ, IP-адреса тоже скажите, no shutdown сделать на роутере. А у нас на роутере настроена 10.1.0.1. Сделайте, кстати, чтобы пинговался внешний интерфейс роутера — у роутера два интерфейса: один, который на ASA смотрит, и 10.1.0.0, который смотрит туда, где мы OSPF настраивали,

туда, во внешний мир. Чтобы ASA пинговала внешний интерфейс роутера, здесь нужно задать маршрут по умолчанию. Давайте ещё раз покажу, как у нас маршрут по умолчанию пишется: route outside — это имя нашего интерфейса — 0.0.0.0 0.0.0.0, наша любимая, и 10.1.1.2. Это у меня, у вас будет 10.1.2.2, 10.1.3.2, 10.1.4.2. Чтобы в таблице маршрутизации появился маршрут по умолчанию. Таблица маршрутизации здесь выглядит так же, как на роутере — она простая и понятная, со всеми теми же подсказками в виде буковок. Продолжаем с ASA. Мы настроили наши

интерфейсы, определили имена интерфейсов — штука важная, настроили статический маршрут, по минимуму, совсем по минимуму. Давайте я быстренько покажу, каким образом у нас настраивается management plane, каким образом административный доступ мы получаем. Смотрите, пользователи на ASA — мы сейчас про RADIUS не будем говорить, просто про локальную аутентификацию. Пользователи у нас создаются похожим образом: username admin password. Смотрите, здесь слова secret как такового нет, потому что на ASA все пароли будут зашифрованы. Password — наш любимый, мучиться мы не будем. И уровень привилегий — уровень привилегий здесь точно так же, как в IOS, от 0 до 15. Для того чтобы у нас ASDM,

вот этот самый, работал, ему нужен пользователь с уровнем привилегий 15. Теперь аутентификация, авторизация настраивается тоже похожим образом, тоже есть подсистема AAA. Аутентификация — дальше мы указываем, для какой подсистемы нужна аутентификация. ASDM у нас работает по HTTP-протоколу, мы ему говорим: http console. Здесь имеется в виду именно административный доступ по HTTP, он называется http console, либо ssh console ещё будет. И список методов у нас будет LOCAL. То же самое с аутентификацией для SSH, например: ssh console LOCAL. LOCAL он большими буквами хочет. HTTP здесь уже подразумевается, что это будет HTTPS. Теперь включается у нас HTTP-сервер: enable.

HTTP-сервер у нас заработал. И на ASA необходимо обязательно указать, с каких адресов можно получать административный доступ. В роутере похожий механизм есть — это когда мы вешаем access list на VTY. Здесь намного проще: мы просто говорим, что http — вот сюда мы даём доступ из сети 10.2.1.0, сейчас ещё раз проверю по топологии, 10.2.1.0 у меня будет, по маске /24, и ещё раз указываем интерфейс, опять имя интерфейса — всё время будет это именно интерфейс. То же самое, например, для SSH: 10.2.1.0, разрешаем из этой сети через интерфейс inside, либо management интерфейс, если будет использоваться. После этого мы можем попробовать этим

самым ASDM подключиться. Вообще ASA содержит — я не скажу, с какой версии это началось, — но образ ASDM у неё есть на диске. На 10.2.1.1 сейчас заодно проверим аутентификацию. Я не знаю, насколько это быстро будет работать. Смотрите, ASDM: когда мы первый раз заходим на ASA по HTTPS, нам предлагают запустить инсталлятор, который выполнен в виде Java-апплета. Он сам скачивается, определяет операционную систему компьютера, который запрашивает,

сам скачивается и устанавливается. Сейчас я проверю, заработал ли у нас административный доступ. Пользователь работает, он начал скачивать launcher, и мы его можем запустить, установить. Здесь у нас установлен ASDM. Напоминаю, что пользователь здесь нужен с 15-м уровнем привилегий. Другого пользователя он не пускает, к сожалению. Несколько слов про ASDM стоит сказать. ASDM — это графический интерфейс для управления Cisco ASA. У ASDM есть много полезных штук, но нас сейчас, наверно, будет интересовать, во-первых, что в нём можно сконфигурировать. У него есть dashboard, который показывает

какие-то основные вещи: наши интерфейсы, загрузку процессора. Есть такой же dashboard по firewall, который показывает по трафику какие-то вещи. Сейчас у нас ничего не покажет, естественно. По мониторингу есть некоторые вещи, можно посмотреть, тут же, например, ARP-таблицу. По конфигурации — конфигурация довольно развесистая. ASDM чем задалбывает — постоянно своими предлагаемыми визардами. Есть сейчас я выключу. Букмарки тоже выключу. Визардами — есть некоторое количество визардов, то есть таких помощников по конфигурированию, где можно в VPN и

всякое настроить, вообще стартовую конфигурацию с нуля настроить. Мы сейчас не будем разбирать. Интересно нам будет, как настраиваются интерфейсы, концепция зон, которая появилась в ASA с самого начала. Роутинг: если так посмотреть, то ASA умеет и OSPF, и RIP, и EIGRP, BGP, и OSPF — много чего умеет. По firewall, по возможностям firewall — здесь удобно очень настраивать, как мы уже обмолвились, правила NAT, потому что сейчас про NAT у нас будет небольшой разговор. На ASA здесь немножечко другие концепции, не как на роутере. Они с непривычки кажутся неудобными, но потом, когда понимаешь, как это устроено,

прикольно именно с NAT работать. Здесь же у нас и правила ACL будут задаваться, и фильтрации. На самом деле запутаться в этом просто. Плюс есть ещё конфигурирование VPN — то, что в жизни используется. Здесь удобно с VPN работать. Всякие подсказки, и, наверное, сервисные функции всяческие — удобно там делать. Хорошо, когда есть какое-то графическое представление. С другой стороны, не всё удобно настраивать именно так. Некоторые вещи в консоли, те же самые интерфейсы, настраивать быстрее — в консоли забить три строчки, чем ткнуть сюда, потом ткнуть сюда, потом сюда и

забивать всё сюда. Не очень удобно. Давайте тогда сейчас я пока это закрою и буду дальше вам просто рассказывать те вещи, которые нам нужно в рамках курса ещё про неё знать. Ещё раз проговорим: ASDM на самом деле совершенно не сложно установить. Надо всего лишь сконфигурировать интерфейс, разрешить доступ по HTTPS, не забыть создать пользователя, потому что без созданного пользователя 15-го уровня ничего не получится, и запустить инсталлер, зайдя на ASA по HTTPS. Больше там ничего сложного нет. Давайте про NAT чуть-чуть поговорим с вами. После курса по Cisco вы должны уже знать, что такое NAT. Если кто-то забыл, скажите мне, пожалуйста, и я всё проговорю. Мы точно все помним про NAT, или не

помним? В принципе здесь про NAT небольшая напоминалочка. Мы сейчас не будем разбирать, что такое inside local, inside global, тем более что здесь эти адреса не так и будут называться. Сейчас мы про них не будем совсем уж всё повторять. У нас есть три основных сценария NAT — также как и вообще, их три, независимо от реализации: роутер это, ASA или iptables. У нас есть статическая трансляция — это когда один к одному, может быть с изменением порта ещё, когда нам нужно обеспечить доступ к внутренним каким-то ресурсам

из интернета, например. Есть динамическая трансляция — это один ко многим, когда мы берём пул адресов, не просто один адрес, а какую-то пачку адресов, и внутренние наши внутренние адреса, внутренние компьютеры мы будем транслировать на адреса из этого пула. У нас получается, что одновременно будет работать столько адресов, сколько есть в этом пуле. Например, если у нас 10 компьютеров во внутренней сети и 5 адресов всего в пуле, то такая трансляция будет немножко неудобна тем, что только пять компьютеров смогут одновременно работать. Это та же самая трансляция один к одному, но динамическая уже. И dynamic PAT — port address translation, которым все мы пользуемся в жизни

каждый день. Ещё он называется NAT overload — когда трансляция много к одному: несколько внутренних адресов транслируются в один адрес либо в несколько, в пачку адресов внешних, и это будет осуществляться подменой портов. Перегрузка порта здесь имеется в виду замена порта. Будем рисовать, но если хотите. Андрей, вы не помните уже, как NAT работает? Как можно несколько внутренних адресов выпустить через один внешний адрес? Только перебивкой портов. Это будет называться перегрузка портов, port overload называется. Есть ещё policy NAT — трансляция по каким-то критериям, которые мы задаём, например, в access list. Policy NAT — здесь сценариев можно придумать очень много, и разные устройства будут понимать это по-разному,

в основном используется ограничение по access list. Как работает NAT на ASA? Смотрите, я уже сказал, что концепция чуть-чуть другая. Эта концепция появилась, по-моему, с 8.3 или с 8.4 версии ASA, и сейчас и в курсах, и на экзамене, может быть, и везде будут уже про это разговор. Есть такая сущность, как object. В ASA всё представлено в виде объектов. У нас есть network object — это либо адрес хоста, либо адрес сети, либо диапазон адресов, и к этому объекту мы применяем уже правило NAT. В принципе это логично, потому что NAT — это

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

переходим ещё к следующей секции. Запоминайте. Эти три секции называются: первая секция, где сначала будет выполняться обработка, она у нас называется Manual NAT — мы вручную в этой секции определяем правила, которые будут с самого начала обрабатываться. Используется она не так часто, как другие. Основные правила будут у нас определяться во второй секции, она будет называться Auto NAT, либо Object NAT. В ней как раз будут определяться все правила, которые применяются к этим самым объектам. И ещё третья секция, она называется Manual NAT After Auto — то есть если мы не смогли определить какие-то правила в объектном NAT, и нам ещё что-то надо руками

дописать, у нас есть ещё одна возможность определить какие-то правила, которые после Auto NAT отработают. Если пакет не подпадает ни под одно из этих правил трансляции, он просто передаётся в неизменном виде, также как на роутере. Если помните, мы отбирали для NAT с помощью access list конкретный пакет. Если не подпал под этот access list, пакет будет обрабатываться в неизменном виде. Дальше, на картинке в ASDM — сейчас настройку будем делать, я покажу в ASDM, как выглядят эти три секции. Мы будем сейчас только касаться именно объектного NAT. Как он вообще конфигурируется? Здесь конфигурация NAT она в разы проще. На роутере помните: надо определить интерфейс, ip nat inside,

ip nat outside. Почему две строки? На роутере не две строки, гораздо больше. Сколько действий, кто помнит, сколько действий нужно на роутере сделать, чтобы NAT заработал? Нужно три действия. Сначала интерфейсы разметить, потом нужно написать access list, чтобы отобрать пакеты для трансляции, и третье — это написать собственно правило NAT. Смотрите, как здесь конфигурируется NAT. Нужно для NAT во-первых создать этот самый объект сетевой, где мы опишем, к чему будут применяться правила NAT. Здесь мы будем NAT-ить конкретную подсеть. Мы создадим этот объект сетевой INSIDE_NET, определим подсеть с маской, какой-то description можно написать, и прямо внутри этого объекта мы говорим, что

NAT нужно делать. NAT — определяем интерфейсы, опять все интерфейсы определяются по именам. В ASA нельзя нигде сказать GigabitEthernet 0/0 — всё время нужно по именам эти интерфейсы называть. Указываем, откуда NAT-ить и куда NAT-ить, и говорим дальше: dynamic interface — то есть динамический NAT на адрес интерфейса, как мы с вами на роутере настраивали — до overload интерфейса. Здесь то же самое. Скобки в конфиге — у вас не видно, что это скобки, но именно так, в скобках, пишется. Просмотр правил NAT: у нас существует команда show nat, которая будет как раз показывать эту самую таблицу с правилами и

будет говорить, что эти правила у нас относятся к секции 1, к секции 2 и к секции 3. Ещё раз покажу, что у нас есть три секции. Секция 2, где как раз объектный NAT, которым мы над объектами будем оперировать, и две секции ручного NAT, который до — первая секция Manual, и после объектного NAT. Мы можем разместить эти правила в трёх секциях. Что ещё? Как вручную делать статический NAT, когда, например, веб-сервер надо разместить? Точно так же создаётся объект. Сначала все создания всех этих объектов, конечно, вымораживают полностью, потому что всё делается через объекты, потом начинаешь с ума сходить с этими объектами, но со временем привыкаешь. Мы посмотрим ещё с вами одну концепцию, где опять же будут эти объекты, когда будем про access list сложные говорить. Потом всё это будет нормально. То же самое: создаётся объект с именем INSIDE_WEB_SERVER,

задаётся адрес хоста — здесь у нас host, и точно так же правило NAT будем писать уже внутри объекта. Все эти команды запоминать не обязательно, надо просто помнить, что в правилах NAT обязательно надо указывать интерфейсы: inside, outside. Дальше тип NAT — static interface, и если мы говорим про статический NAT, можно ещё добавить параметры, где будем указывать service tcp — то, что мы будем именно транслировать для конкретных портов, 80 80. Всё, больше для настройки ничего не надо. То, что мы делаем NAT объектами, также попадает в секцию 2, в Auto NAT. Policy — здесь можно посмотреть счётчики, которые будут у нас

увеличиваться. И нужно ещё запомнить такую команду, как show xlate. На роутере show ip nat translations, чтобы посмотреть именно трансляции, которые в данный момент работают. Здесь у нас команда show xlate. Я её в своё время не смог запомнить с первого раза, всё время искал, где же команда, чтобы трансляции посмотреть. xlate — вот такая команда. Давайте попробуем всё это дело на стенде, на роутерах, как всё это настраивается, и потом пойдём дальше. Давайте быстро подготовимся. У нас на коммутаторе пусть так и остаётся 1 VLAN, всё будет в нём. Просто создадим интерфейсик, где зададим IP-адрес из внутренней сети: 10.2.номер_комплекта.0, пусть будет 10.2.1.100 — без разницы какой.

No shutdown. Попробуем пропинговать внутренний интерфейс нашей ASA. Заработало. Сейчас ещё нам нужно настроить маршрут по умолчанию 10.2.1.1. Тоже у нас. Всё прекрасно. Роутер у меня настроен, я могу пинговать ASA изнутри. Чтобы пропинговать, например, loopback на своём маршрутизаторе — у вас тоже есть loopback-и: 2.2.2.2, 5.5.5.5 — почему бы нет, можно с ними работать.

Если я попытаюсь пропинговать сейчас loopback на маршрутизаторе, то мы увидим, что маршрутизатор пытается отправить с этого loopback-а ответные пакеты на адрес 10.2.1.100. У нас тут ещё и OSPF, и EIGRP. Сеть 10.2.1.0 мой маршрутизатор не знает, и он не знает, куда отправить. Соответственно, мы можем либо прописать обратный маршрут на маршрутизаторе, либо использовать NAT, чтобы маршрутизатор думал, что его пингует не кто-то там внутри, а пингует сама ASA. Давайте заниматься NAT на ASA.

Связность у нас какая-никакая по IP есть, потому что switch, который за ASA, пингует маршрутизатор. ASA у нас стоит с той стороны, и настроены интерфейсы. Давайте смотреть, как у нас работает NAT. Успеваете за ходом мысли? Давайте вкратце: как настраивается NAT — я уже говорил, что нужно сначала создать этот самый объект, с которым потом мы будем каким-то образом играться и к нему уже применять правила NAT. Объект создаётся в этом случае очень просто: мы говорим object network. Обратите внимание, ещё есть object service — это будет чуть подальше, когда будем про access list говорить. А сейчас у нас сетевой объект: object network, и назовём его INSIDE_NET, будет как на слайдах. Дальше

мы говорим, что это за объект — это будет либо host, либо subnet, либо какой-то range. Мы говорим, что это будет subnet. Subnet у нас будет 10.2.номер_комплекта.0, то есть 10.2.1.0 у меня, с маской /24. К сожалению, здесь нельзя указать просто длину маски, приходится в таком виде забивать. Description можно какой-нибудь написать, если нам это интересно. И самое интересное — когда мы правила NAT будем определять внутри самого объекта. Кирилл говорит, что NAT из какого-то момента тоже стало возможно объекты создавать. Кирилл, их стало возможно создавать, я думаю, уже очень давно. И этим

Надо пользоваться, мы сейчас тоже проект немножко прервём и дальше своим будем говорить. На самом деле очень старая штука, которая работала чуть ли не в 12.4 какой-то там, короче, древние просто. Не на всех платформах, но давно. Так, подсеть-объект мы определили, и дальше просто мы говорим волшебные слова, что мы хотим делать с NAT, и обязательно указывать интерфейсы — откуда и куда, а дальше тип NAT — либо статический, либо динамический. В этом случае нам нужен динамический NAT. И откуда мы будем брать адреса для подмены — внешние адреса: либо будем использовать пул, либо просто с интерфейса брать, либо можно из другого объекта — там уже слишком сложно, это у нас тут «сисиный детский сад»,

поэтому просто возьмём внешние адреса с интерфейса. Всё, этого достаточно. Если посмотреть show NAT — обратите внимание, эти команды show я набираю прямо там, где конфигурировал, это очень удобно — то мы видим, что у нас одно правило NAT создалось: из интерфейса inside в интерфейс outside, dynamic, inside NAT на интерфейс. В принципе всё, этого достаточно. Теперь если посмотреть show xlate — тот самый, где показывает трансляцию — у нас пока ничего нет. И если со свича попробовать сделать пинг, то ничего. Смотрите, NAT работал. Show xlate у нас показывает, что ICMP — у нас создалась трансляция из inside вот с такого-то адреса, вот с таким-то

адресом, и тайм-аут поставился 30 секунд для ICMP-сессии. И роутер уже пытается отправить пакеты на адрес 10.1.1.1 — это на внешний адрес ASA. В принципе, правило NAT работает. Единственное, что нам нужно добавить — инспекцию. Смотрите, что такое инспекция — спрашивает Андрей. Помните, я говорил в пятницу, когда мы про firewall и общую вводную тему брали? Инспекция в данном случае — это когда firewall будет следить за состоянием протокола и будет сам автоматически разрешать обратный трафик. Вот в этом контексте инспекция — когда он будет инспектировать трафик и ответные действия разрешать. В данном случае ASA вообще по умолчанию TCP и UDP трафик она уже инспектирует. Просто

мы сейчас взяли новую, свежеиспечённую ASA, и она TCP и UDP трафик по умолчанию уже инспектирует. Если мы telnet'ом сейчас пойдём — кстати, без всяких дополнительных телодвижений — если... Блин, это роутер, извиняюсь. С коммутатора пойти telnet'ом на роутер. А у нас как тут настроена... Ладно, сейчас просто мысль закончу. Она по умолчанию разрешена, а вот ICMP трафик она запрещает по умолчанию — инспекция ICMP трафика отключена. Для этого надо прямо говорить конкретно, что ICMP трафик тоже нужно инспектировать. Вот это и есть инспекция. Так что пинг не работал с самого начала здесь, потому что была отключена инспекция. Я добавил. Мы сейчас лучше не будем заморачиваться тем, что я сделал, мы позже ещё будем говорить про это и увидим, как эта инспекция работает. Так, давайте на

паузу маленькую я поставлю. Давайте под запись расскажу ещё про SDM пару слов. Я перепутал его с Cisco Configuration Professional. Вот тому нужен был точно 15 уровень, и он без 15 уровня не заводился. В SDM можно не только 15 уровень, и будет работать, но соответственно с теми привилегиями, которые есть у пользователя. По поводу demo mode мы разобрались — demo mode он не везде работает. Я думаю, что если покопаться на сайте Cisco, то там можно найти образ, в котором demo mode включён. Вероятно, это вообще даже в виде отдельного дистрибутива. Так, давайте теперь немножко поговорим про управление доступом на Cisco ASA. Здесь будет имеется в виду доступ сетевой, не административный. Про административный пару слов сказали. Про наши любимые access-листы — про роутерные access-листы мы всё

уже знаем, там ничего сложного нет для нас. В ASA access-листы будут чуть-чуть другие, это надо сейчас про различия поговорить. Access-листы запрещают или разрешают транзит пакета, основываясь на сессии. Самое главное — access-листы могут быть применены на интерфейсе, как в роутере, или глобально. Здесь в ASA есть такой прикол, что мы можем взять access-лист и применить глобально — он будет работать для всего трафика, который проходит через ASA. У нас дальше будет небольшой пример. Порядок правил в access-листе имеет значение, точно так же как в роутерных access-листах. Точно также в конце access-листа будет содержаться неявный запрет — deny all — всего трафика. Важно понимать, что в ASA access-листы пишутся с нормальными масками, с привычными нам сетевыми масками, не wildcard,

не обратные маски. Здесь нельзя составить access-лист, чтобы, например, фильтровать пакеты, основываясь на битах только в третьем октете, например, или какой-то один байтик брать в расчёт, либо чётное- нечётное — все эти игры с wildcard-масками здесь, к сожалению, недоступны. Только обычные сетевые маски, и такая прямолинейная фильтрация — то, что подразумевается под сетями, то здесь и фильтруется. Дальше, какие бывают access-листы. Бывают стандартные access-листы — не запутайтесь: стандартный access-лист на роутере проверяет IP-адрес источника, здесь проверяется IP-адрес назначения. Расширенные access-листы проверяют IP-адреса источника, назначения, протокол, номера

портов — привычный нам расширенный access-лист. Бывают access-листы EtherType — это всё, что не относится к IP. И есть ещё webtype access-листы — webtype это для работы с SSL VPN с clientless VPN. Конечно, это выходит за рамки нашего курса, но мы чуть-чуть про него скажем в дальнейшем — что бывает такой тип VPN, и там есть специальные access-листы, которые мы можем использовать в этих типах подключения. Как конфигурируются access-листы. По умолчанию, когда у нас нет ни одного access-листа на интерфейсе, мы уже говорили, что все inbound-сессии запрещены — от интерфейса с меньшим уровнем безопасности к интерфейсу с большим уровнем безопасности inbound-сессии запрещены. Исходящий трафик — outbound- сессии — они все разрешены. Access-лист, так же как на роутере, применяется к интерфейсу в конкретном

определённом направлении — либо in, либо out. Здесь ничего нового для вас нет. Access-листы, которые применяются глобально — я уже сказал про глобальные access-листы — они применяются сразу ко всем интерфейсам в направлении in. Вообще out access-листы, в направлении от интерфейса, в ASA очень редко применяются. Нормальная практика — вот последняя строчка тут на слайде — что общая практика применения access-листов в направлении in. Глобальные access-листы будут работать только в направлении in, сразу на всех интерфейсах. Эти глобальные access-листы будут проверяться после тех access-листов, после их правил, которые у нас на интерфейсе. Мы понимаем: сначала какая-то конкретика будет проверяться — то, что прямо на интерфейсе жёстко написали, а потом, если пакет не

подпадает под это, он будет проверяться ещё по глобальным access-листам. Важно помнить, что правило применяется к адресам до их трансляции. Когда у вас будет ASA, если с ней ещё работаете — правила, какие IP-адреса вы будете писать — это все адреса до их подмены, до NAT. Вот это очень важный момент. Теперь по поводу сессий между интерфейсами с одинаковым уровнем безопасности — здесь запутаться в принципе можно тоже. Сейчас на интерфейсе два access-листа висеть может? Нет. На интерфейсе мы можем только один access-лист повесить, так же как на роутере — не должно быть неоднозначности. Интерфейсный access-лист — Роман правильно сказал — один на in, один на out. Если

интерфейсный не сработал, потом уже глобальный применяется. Но нельзя сказать, Андрей, что на интерфейсе два access-листа — нет, он один там. На самом деле, кто будет экзамен сдавать — таких вопросов очень много: можно ли применить два access-листа на интерфейс. Надо просто понимать, что неоднозначные какие-то решения, как применение двух access-листов, их просто не бывает. Инженеры тоже не дураки, которые софт пишут. Так, нельзя — не сработает. Это значит, что не подпал ни под одно условие. Либо не попал ни под одно условие, и всё. Но его можно убрать — неявный deny — почему нет. Дальше, давайте так, про сессии с интерфейсами — важная штука. Смотрите,

бывает такая ситуация, что у нас есть два интерфейса с одинаковым уровнем безопасности — там inside1, inside2, у них уровень безопасности 100 и 100. Раньше, в старых версиях, между такими интерфейсами трафик был разрешён. Начиная с какого-то момента — я точно не скажу, но наверное с версии 8.4, она такая была революционная, в которой поломали дофига всего — начиная, по-моему, с этой версии, могу ошибаться, трафик между равнозначными интерфейсами по умолчанию запрещён. Так что имейте в виду, потому что это опять же ошибка, которая бывает на ASA: когда вроде всё настраивают, берут два интерфейса, у них 100 и 100, одинаковый уровень безопасности, между ними не ходит ничего, и access-листы никакие не применены —

начинается траблшутинг. А потом надо вспоминать, что у нас новая ASA, и здесь по умолчанию запрещено. Есть такая команда на ASA: same-security-traffic permit inter-interface — да, всё правильно Роман написал. Эта команда разрешает в новых версиях ASA трафик между равнозначными интерфейсами. Про TCP, UDP и ICMP я уже сказал, что TCP и UDP у нас обратный трафик разрешается автоматически. Для ICMP — для таких однонаправленных протоколов — нужно разрешать явно трафик в двух направлениях. Как у нас пишутся access-листы — если хотите, в консоли можно попробовать, если хотите, я буду просто на слайде показывать. Можете на своих ASA в консоли всё это набивать. Я думаю, что большого смысла нет прямо делать отдельную лабораторную работу на это. Access-листы

в основном расширенные используются, поэтому будем с расширенными смотреть. Очень просто, они в принципе на роутерные похожи. Тоже так же есть команда access-list, без вот этого префикса ip. Когда на роутере мы всё, что связано с IP-протоколом, начинаем с префикса ip — нет, здесь не ip route, а просто route, не ip access-list, а просто access-list. Access-лист именованный. IPv6 также пишется. Сейчас могу ошибиться, но в этой конструкции можно описать адреса IPv6 — она их понимает. Можно написать здесь и IPv4-адрес, и IPv6. Все те же самые макросы, которые у нас на роутере работают — host или any — они будут работать. Стандартный access-лист

срабатывает — здесь имеется в виду destination, адрес назначения. На роутере стандартный access-лист, вы же помните, берётся только адрес источника, а на ASA — наоборот. Вот это два таких основных различия. Стандартный access-лист применять — не знаю, я вообще очень редко его применяю, хотя где-то без него не обойтись. Именно для фильтрации на интерфейсе я думаю, что расширенный имеет смысл больше применять. Так, как пишутся access-листы, что здесь ещё интересного сказать. Да, здесь не хватает — тут ошибка в слайде, надо её будет поправить следующий раз — тут 255, у нас просто 255.55. Что ещё по поводу команды show access-list — show access-list она будет работать

так же, как на роутере: будет показывать развёрнутые access-листы, будет hit count — здесь имеется в виду, сколько попаданий было под этот access-лист. Здесь не match написано, а hit count — Роман правильно сказал. Дальше, обратите внимание, что слово extended необязательно — мы здесь написали без слова extended, просто permit tcp, просто permit — и пошли дальше. ASA сама развернёт это, поймёт это как расширенный access-лист. Чтобы стандартный access-лист писать, там надо говорить, что это именно стандартный access-лист. Понимаете — без указания по умолчанию здесь access-листы расширенные. Здесь нет нумерованных access-листов, но я уже про это говорил. Вообще использовать

нумерованные access-листы — это плохая практика. Лучше все объекты пусть будут у нас с понятными названиями, ничего страшного — лишние два слова в конфигурации написать. После того как мы создали access-лист, мы должны применить его на интерфейсе — понятно, что просто так он не заработает. Как они применяются: не на интерфейсе — не пытайтесь, как на роутере, зайти на интерфейс и повесить туда access-лист. Access-листы применяются в глобальной конфигурации, когда мы говорим access-group, говорим название нашего access-листа, направление и потом на каком интерфейсе. В принципе логика здесь несложная, она такая же, как на роутере, просто это делается немножко не в том порядке — синтаксис у ASA. Show interface ip brief немножечко не в том порядке будет поставлен, на самом деле всё то же самое. И глобальные

access-листы — мы написали access-лист permit management, для менеджмента разрешили трафик на 23-й, на 22-й порт — telnet, SSH. Эти access-листы, чтобы не применять на каждом интерфейсе, мы можем просто сказать access-group, название нашего access-листа и сказать global. В таком случае они будут применены глобально, сразу для всех интерфейсов в направлении in. Мы уже говорили, что направление out вообще не очень хорошо использовать. Посмотреть — в том же show run они уже будут показаны, где они применены. Дальше, про object-group давайте чуть поговорим. На CCNA такой темы не должно быть, но, если только Иннокентий вам не добавил эту тему в курс. Или вы знаете про object-group — наверное, не было. Про object-group: смотрите, object-group

есть и на ASA, есть и на роутере. В них тоже ничего сложного нет, но это классная вещь — они позволяют значительно упростить, сократить длинные, громоздкие access-листы. Сейчас у нас на следующем слайде будет пример, и там я постарался нарисовать всё это очень доступно и понятно. Они нужны только для того, чтобы удобно писать access-листы. Потом эти access-листы разворачиваются в длинные неудобные access-листы, и роутер или ASA будет обрабатывать их как эти длинные access-листы. Object-group — это просто для упрощения конфигурирования. В группы мы можем объединять хосты, сети или сервисы. С группами объектов мы чуть-чуть познакомились — я вам объяснил, что такое сетевая группа: в правилах NAT мы можем использовать, и эту же группу можно использовать при конфигурировании

access-листов. Бывают сетевые группы, куда мы объединяем хосты, сети или диапазоны адресов. Либо бывают сервисные группы. Сервисы — это связка протокол плюс номер порта. Сервисы это у нас, например, TCP 80 — сразу понятно, про что идёт речь — или TCP 443. Сейчас будет пример на следующем слайде, всё будет понятно. Смотрите, как всё это работает. У нас есть вот такой длинный... Блин, извиняюсь, слайд переключился. Длинный, неудобный access-лист. Бывает такая штука, что у нас есть в нашем примере два сервера — веб-сервер есть и почтовый сервер есть. И к этим двум серверам надо обеспечить доступ от конкретной группы хостов. Чтобы не расписывать вот такую конструкцию — сначала у

нас веб-сервер, дайте я выделю — у нас веб-сервер запущен на хосте 172.30.8.1. Сначала надо к нему все хосты разрешить — 10.0.2.3, 10.0.4.1, 10.0.1.15. Потом к этому веб-серверу разрешить все те же самые хосты. А потом у нас на двух этих серверах ещё и почта работает, и потом прописывать ещё раз и ещё раз. Короче, получается вот такая длинная простыня. В некоторых случаях эта простыня может быть очень длинной. Например, у меня на работе есть стенд тоже тестовый, где лаба — роутеры и коммутаторы. Мы когда к CCIE готовились с Михаилом — я Михаилу давал доступ к этому стенду, и мне нужно было прописать в access-листе для каждого порта. У меня консольный сервер стоит

на работе, и для каждого порта этого консольного сервера надо было прописать IP-адрес Михаила, которому я предоставлял доступ. И у нас была группа, где мы вместе к CCIE готовились — надо было там для каждого человека прописать 16 этих строчек в access-листе. На самом деле там access-лист получался такой внушительный. Всё это дело можно переделать, переработать и привести к более удобночитаемому виду. Можно взять все хосты — пачечку сгруппировать, взять веб-серверов их адреса, mail-серверов и сервисы, которым мы предоставляем доступ. У нас получилось четыре таких группы — раз, два, три, четыре — а потом записать всю эту конструкцию в две строчки. Всего лишь две строчки. А IMAP куда делся? А он здесь был. IMAP...

Миш, ты о чём? Я чего-то не понял. А, здесь у нас, извиняюсь, просто опечатка в слайде. Но здесь имелось в виду, что по TCP SMTP, конечно. Извиняюсь, это хорошая поправка, это просто опечатка в слайде. Смотрите, мы определили объектную группу для сервисов — сервис www и сервис SMTP. Определили объектную группу для хостов — source-хосты, которым нужно давать доступ. И определили объектную группу для веб-серверов и для mail-серверов. И записали всё в две строчки: разрешить этой группе сервис www — мы пишем permit, и здесь

мы просто пишем уже не permit tcp и потом где-то номера портов, а просто разрешить вот эту группу сервисов, к ним доступ от этой группы к вот этой группе. Всё. Улавливайте смысл вот такой группировки. Интересно, если нам определить для TCP и UDP отдельно — но мы можем. Смотрите, если в принципе можно всё это в одну группу объединить. Порядок немножко непривычный, но это очень удобно. Надо просто взять большой какой-то access-лист, как в этом примере, у нас пусть ещё будет UDP по SMTP — это можно в третью группу выделить, и тогда придётся давать ещё к одной

группе — там третья строчка. Либо можно взять все эти сервисы, объединить в одну группу. Но если мы смотрим, у нас получается серверы одинаковые будут — просто надо грамотно группировать. Здесь ничего сложного нет, надо сесть. TCP — мы будем упоминать в конфигурации этой группы. Здесь просто нет конфига для группы, сейчас будет. Это не просто порты — здесь сервис, как на вот этом слайде, это связка протокол плюс номер порта. Это просто сейчас пример. Давайте конфигурацию — смотрите, конфигурация, как всё это пишется. Хотите, на ASA попробуем? Но я думаю, давайте на ASA покажу в консольке. Или на роутере — без разницы. У нас тут разговор про ASA идёт, поэтому давайте ASA смотреть. Роман, нет, экономии

TCAM, к сожалению, здесь нет никакой экономии. Сейчас я объясню почему. Я уже говорил, что эта концепция object-group используется только для конфигурирования. К сожалению, здесь не получится схалтурить, чтобы сэкономить место в TCAM, никаким образом. Потому что всё равно потом всё это развернётся в нормальный access-лист. Давайте сейчас я покажу конфигурацию. Например, создадим группу сначала для хостов — object-group network — которым мы разрешаем доступ. Object-group network «наши клиенты», source хосты. И скажем, можно description написать. Внутри группы пишем — опять же, в ASA

немножечко получается, можно использовать здесь другие объекты. Сейчас не запутайтесь. Смотрите, в ASA всё представлено в современной версии как вот эти сетевые объекты. NAT мы с вами делали — сеть тоже представлена как объект, хост представлен как объект. Поэтому мы группируем тоже объекты: мы говорим network-object и там пишем host 10.0.2.3, потом у нас второй хост будет 10.0.4.1 и хост ещё будет 10.0.1.15. Это я со слайда повторяю. Дальше давайте ещё — получается объекты в объектах, немножечко можно запутаться. Теперь группу, где мы объединим наши серверы:

object-group network web-servers. И здесь мы будем network-object host 172.30.80.1, 30.12.5 — например. Дальше, так, где экран? Юрий спрашивает, какой экран — все видят мою консоль? Так, дальше. Хосты, с которых мы разрешили доступ — source — написали. Веб-серверы написали. Давайте ещё добавим почтовые

серверы: object-group network mail-servers. Почтовые серверы сюда же напишем. И на роутерах немножко проще — мы дальше будем с вами роутер конфигурировать, там можно не эти network- object, а просто как обычный access-лист: host такой-то или сеть такая-то — там проще. Так, network- object host, почтовые серверы: 20.1.1.2 и ещё добавим 30.6.2. Теперь по поводу сервисов, как они описываются — то же самое object-group, только здесь мы говорим service, и пусть будет у нас сервис SMTP. И здесь мы будем говорить service-object — это тоже всё в виде объектов представлено, сначала выбешивает ужасно — и говорим, что это TCP и destination у нас будет 25 порт. SMTP, прошу прощения, 25 порт. И сделаем ещё

object-group service для веб-серверов — www. Здесь мы скажем TCP и destination у нас можно писать www, можно писать 80 — так же, как на роутере, когда порты мы указываем: SSH, telnet — можно писать и в числовом выражении, можно писать прямо название сервиса. Дальше, show object-group — теперь посмотреть получившуюся конфигурацию. Мы увидим, что у нас есть объектная группа для хостов — для исходящих адресов, объектная группа для веб-серверов — именно хосты для серверов — и сервисные object-группы, куда мы описали наши сервисы. Мы можем создать одну сервисную группу и написать туда сразу несколько сервисов. Например, допишем ещё destination у нас 443. Он стоит

443. Получается, у нас мы объединили сервисы, которые относятся к вебу — www, HTTP, HTTPS — 80, 443 порт — в одну группу, чтобы потом их использовать в access-листе. Дальше, группы мы посоздавали. И как пишется access-лист — сначала это с непривычки, конечно, неудобно, потому что надо говорить: access-list, назовём его permit-int-servers — внутренние серверы — и говорим permit object-group, надо сказать протокол или в нашем случае сервисы — разрешим. И потом откуда и куда. И говорим опять же — не как мы писали в access-листе: сначала адрес источника, потом адрес

назначения, — здесь пишем объектную группу источников и группу назначений. Так и говорим: object-group, разрешаем доступ к сервисам www. Так, это я неправильно что-то написал. Invalid host. Будем траблшутить сейчас. Блин, всё правильно. Правильно — object service. Сейчас, прошу прощения. Почему? Так, object-group, мы разрешаем от object-group...

Всё, неправильно, сейчас ещё раз. Нет, он object-group, он называется... Здесь правильно. А, всё правильно, здесь к объектной группе. Всё правильно — здесь к объектной группе, а всё — я здесь сервис вместо веб-серверов написал. Вот так получилось. Конечно, сначала я

раньше вообще путался постоянно. Постоянно надо говорить object-group. Когда нужно отредактировать объект — на самом деле редактирование здесь проще: можно просто из объектной группы удалить, и в access-листе тоже всё это изменится. Всё правильно. Так, и добавим ещё сюда для почты разрешения. Какие мы там написали сервисы — SMTP. Object-group от наших source-хостов к объектной группе mail-servers. Смотрите, я забил в принципе всего лишь две строчки, но уже применил все эти объектные группы. А теперь

если посмотреть show run access-list — у нас в show run всё это выглядит... Мы в show run видим всего лишь две строчки: первая строчка, вторая строчка. В show run это выглядит именно так, как мы с вами забили. Теперь если посмотреть, как на самом деле выглядит access-лист — show access-list permit-int-servers — то он развернётся вот в такую конструкцию. Почему я сказал, что никакое место в TCAM у нас не экономится — ничего. Это просто удобство и экономия конфигурации. Потом всё это разворачивается вот в такую штуку — 18 строк. Адская, да. И потом у нас

говорится, что access-лист permit — первые линии — там extended permit tcp host такой-то, хосту такому-то, по 80 порту. Всё как было до того, как мы всё это красиво облагородили, всё переработали — но всё равно развернётся в результате вот в такую конструкцию. Нет, Кирилл, в конфигурации — сейчас поясню, Миш, секунду — в конфигурации будет храниться именно только две строчки, короткие. В show run будет храниться именно короткие, а на самом деле он будет разворачиваться потом в эту штуку. Он каждый раз в памяти будет разворачивать: когда у нас роутер читает свои настройки или ASA — в памяти

всё это будет разворачиваться. Народ, в реальном оборудовании тоже так можно делать, попробуем попозже чуть-чуть. Это очень удобно, это появилось тоже сто лет назад. Так, поменять какой-нибудь IP-адрес — например, хост. Сейчас посмотрим ещё раз show access-list — наш длинный. Так, 10.0.4.1, 10.0.1.15 у нас было, 10.0.2.3. Сейчас мы просто удалим 10.0.1.15. Смотрите, я просто удалил, изменил

эту объектную группу — взял удалил из неё один хост: network-object host 10.0.1.15. Всё, и он у нас из этого access-листа тоже удалился, его здесь нет. Любое изменение в object-group — можем сейчас добавить сюда хост, и он у нас отразится в этом access-листе. Было 18 строчек, теперь 12 строчек в access-листе. Да, конечно, так бы тоже, Миш, произошло, если бы access-лист был применён. ASA смотрит изменения в такой конфигурации и сразу применяет, не надо ничего специально. На роутере надо исключать — в смысле, исключать... На роутере не подхватывается изменение в object-группе? Ты про это? Тогда не понял, про что Андрей

говорит. Странно, что на CCNA про object-group не говорят. Да, странно, потому что концепция довольно простая. Но я, когда читал CCNA, всегда рассказывал, потому что нужно тоже упомянуть — это очень экономит время и силы на конфигурации. Так что пользуйтесь этим механизмом. А на роутере не даёт внести изменения в object-группу? Я не уверен, надо проверять, возможно. Надо проверить, я правда не уверен. Так, давайте с object-group мы на этом закончим. Сейчас я вернусь к слайдам. Самое главное помните, что это только для экономии нашего времени при конфигурации. Ну и потом удобно, когда какая-то развесистая конфигурация. Мы сейчас перейдём к развесистым

конфигурациям — например, firewall на роутере. Там приходится их использовать сплошь и рядом — объектные группы. Если бы просто access-листами оперировать, там умереть можно. Так, под запись покажу слайды — то, что я сейчас в консоли показывал — в текущей конфигурации как всё это видно, и как на самом деле выглядит access-лист. Дальше, access-лист — прошу прощения — он разворачиваться будет. Сначала линия 1 — обратите внимание, просто здесь в консоли не показал: он пишет, что линия 1 в access-листе, и вот он её разворачивает, пишет «линия 1», а потом «линия 2» — вот во что развернулась линия 2 в access-листе. Было две линии, стало 12 линий — на примере вот на этом слайде. Давайте теперь поговорим про опять всякие

фреймворки. Я пару слов заикнулся, сказал про MQC — Modular QoS Framework. На самом деле Cisco одну и ту же вещь называет по-разному, в зависимости от того, где она используется. Концепция не меняется. Есть такой так называемый фреймворк, с помощью которого можно конфигурировать разные вещи. Просто в зависимости от того, где это будет конфигурироваться, Cisco меняет название. Я уже рассказал, что есть такой механизм конфигурации, когда мы будем оперировать сущностями, не какими-то строками как в access-листе, а именно сущностями. Сейчас мы про них поговорим. Этот самый Modular Policy Framework упорядочивает работу с фильтрацией — конфигурация фильтрации становится такая иерархически

выстроенная, правильная. Сейчас мы научимся это делать. Позволяет применять независимые правила для потоков трафика с очень высокой степенью детализации. Да, действительно, на каких курсах рассказывают QoS — перебивает меня Олег, хорошее замечание. QoS рассказывают на провайдерском курсе — всё-таки на CCNP Service Provider. Там про QoS такой жирный кусок, и очень интересный, очень объёмный. Здесь мы вообще на CCNA про QoS нигде не говорится. Может быть, на CCNA Service Provider — я не занимался CCNA Service Provider, даже не представляю. Но, по-моему, вряд ли. Может быть, кто-то знает, где про QoS ещё рассказывается на уровне CCNA — не знаю. Cisco книжка — Миша сейчас рекламирует

книжку от Cisco, классная книга, всем советую почитать. Потом в чатик название кинем. Дальше, про вот этот самый фреймворк. Это не access-листы, с access-листами это не имеет ничего общего. Но эта штука может работать вместе с access-листами. Access-листы — это такой предварительный, грубый способ фильтрации, который сначала будет применяться на интерфейсе — такой очень грубый, а потом будет работать тот самый MPF — правило, которое написано с помощью этого фреймворка. Здесь он будет реализовываться с помощью трёх компонентов: class-map, policy-map и service-policy. Мы с вами про это ещё будем говорить. Сначала мы должны определить типы трафика — это тот самый class-map, то есть сказать,

что мы будем фильтровать, что нам нужно отобрать. Потом мы будем писать policy-map — это действие: что же мы будем делать с этим отобранным трафиком. И service-policy — где мы будем связывать всё это воедино. По умолчанию в Cisco ASA есть уже такая политика, которая будет применяться ко всему входящему трафику. Мы говорили про то, что есть глобальные access-листы — здесь тоже будет глобальная политика. На самом деле этот фреймворк — это основа именно файерволов Cisco ASA. Классическая ASA будет именно работать с этим самым фреймворком. Надо помнить, что эта глобальная policy-map она только одна. Ну и плюс на каждый интерфейс тоже можно повесить. Как конфигурируется — я думаю, что на ASA нет смысла конфигурировать, мы будем

конфигурировать похожую вещь на роутере, потому что на роутере просто прикольнее — там будет ещё одна концепция, чтобы вас совсем запутать и вам стало грустно под конец учебного дня. Лучше на роутере это делать, там будет ещё интереснее. Ещё раз повторю: задача конфигурирования этого MPF-фреймворка, вообще файервола на ASA — надо сначала определить классы трафика, у нас есть для этого инструмент class-map. Потом определить какие-то действия над этими классами — это у нас второй компонент, policy-map. И потом назначить этот Policy map на интерфейс либо глобально. MQC — что это такое? MQC — наверное, Андрей, на самом деле, как говорил один тренер, нет такой аббревиатуры из трёх букв или из четырёх букв, которая бы не была

зарегистрирована торговой маркой фирмы Cisco. Поэтому я ненавижу эти цисковские аббревиатуры, они реально одну сущность, этот фреймворк, называют миллионом имён. На самом деле всё одно и то же. Он в QoS используется, то же самое, там тоже сначала class map определяется, потом policy map, и понятно, что там действия другие — там будут действия именно по ограничению полосы, но другие. Здесь будут действия по фильтрации, но на самом деле одно и то же: class map, policy map, service policy — вот такой фреймворк. Он несложный, но эти аббревиатуры — это просто вымораживает, особенно когда на экзаменах начинают спрашивать про эти аббревиатуры — всё, тушите свет, сливай воду, кошмар. Давайте тогда сейчас мы сделаем небольшой перерыв, время у нас всего ничего, полдесятого. И сейчас будем говорить про роутеры. Собственно, идея фаервола, которая была сначала на ASA, она в какой-то момент

оказалась перенесена на Cisco IOS, на роутеры. Я считаю, это очень классно, потому что до какого-то времени на роутерах был довольно негибкий фаервол — был обычный старый CBAC, там инспекцию можно задать, но там мало было возможностей. В какой-то момент инженеры Cisco этот фреймворк перенесли на роутер, назвали его zone-based firewall. Как этот фреймворк называется на роутерах, мы сейчас тоже посмотрим. Я не помню аббревиатуру, по-моему, она там тоже другая. Я не стараюсь запоминать аббревиатуры, меня это бесит ужасно, и я не считаю, что это нужно нормальному инженеру — помнить все аббревиатуры. Достаточно понять, о чём идёт речь. CBAC — это раньше было, это старый способ, старый тип фаервола. CBAC уже на курсах ни на каких не рассматривается — ну

чего рассматривать, две команды. А ZBF мы сейчас будем ковырять. Давайте уйдём на перерыв небольшой, и про zone-based firewall поговорим, который я очень люблю. Окей, давайте разбираться, теперь будем говорить про zone-based firewall. Как я уже сказал, та концепция, которая изначально появилась на Cisco ASA, была перенесена на роутер. Первое — позволяет сгруппировать физические и виртуальные интерфейсы в зоны. Про понятие зон мы с вами уже немало сказали. Здесь будет та же концепция, когда мы обозначаем какие-то зоны и говорим, что этот интерфейс у нас будет смотреть в зону inside, эти два интерфейса

будут смотреть в зону outside, эти два интерфейса — в DMZ-зону, а ещё у нас есть виртуальные интерфейсы, например туннельные, к нашим каким-то подсетям. Это наши подсети, этих туннельных интерфейсов может быть 20, 30, не знаю, 100. И все эти интерфейсы будут тоже входить в зону inside. Нам не нужно будет применять все правила на каждом интерфейсе — представляете, это умереть можно: на каждом туннельном интерфейсе писать правила и потом применять их туда, умереть можно. Поэтому мы просто включаем интерфейс в нужную зону, а потом мы будем применять именно правила к трафику, который пересекает эти зоны. Это очень удобно. Мы можем легко модифицировать принадлежность интерфейса к зоне либо новый интерфейс, который создали, туннельный интерфейс,

поместить уже в конкретную зону, и для него будут применяться уже правила для трафика между зонами. Дальше теперь немножко поговорим про концепцию пары зон. Я сказал, что зона — это набор сетей, которые доступны через определённые интерфейсы. Надо понимать, что интерфейс может принадлежать только к одной зоне. Это естественно — один интерфейс не может смотреть у нас в зону inside и в зону outside. Я имею в виду здесь логические интерфейсы. Например, если у нас работает так любимый «роутер на палочке», где один физический интерфейс, но по сути у него есть сабинтерфейсы, то здесь мы будем говорить именно про сабинтерфейс, про логический интерфейс. Дальше, есть специальная зона — зона self. Она обозначает именно трафик control plane, то что идёт к самому роутеру. Например, OSPF какой-то, который

направлен к самому роутеру, или протоколы управления — хотя management plane это не control, но тоже будет всё направлено к самому роутеру. То есть трафик, который идёт на сам роутер, нетранзитный, он будет всегда попадать в зону self. Следующая концепция — на рисуночке очень хорошо показано, какие интерфейсы куда смотрят. Следующая концепция — это пары зон, zone pairs, так называемые. Зоны группируются в пары. Мы говорим, что у нас есть пара зон, и в ней, в этой паре, есть трафик, который идёт из зоны 1 в зону 2. Именно с этими парами мы будем работать. Политики, которые мы потом напишем, мы будем применять не к зоне — как можно применить к зоне? У нас смотрит один интерфейс наверх в зону 1, мы же не

можем применить на нём какую-то политику — а именно к трафику, который идёт из одной зоны к другой. Соответственно, здесь направление политик мы уже не указываем. Мы сказали, что zone pair, пара зон такая-то — это трафик, который идёт из зоны 1 в зону 2. То есть в самой сущности эта пара она уже говорит, откуда и куда идёт трафик. Не нужно больше никакое направление указывать. И потом к этой паре мы применили политику. Это понятная штука, я думаю, что понятно объяснил. Если кто-то чего-то не понимает — переспрашивайте, я с радостью ещё всё уточню. Дальше, мы сказали, что у нас, например, давайте я напишу в чатик. Есть зона inside, зона outside.

Да, Андрей, надо предопределять все пары зон. У нас есть зона inside, зона outside. Первая пара — это будет трафик из inside в outside. Вторая пара — это трафик, который будет идти из outside в inside. И к этим парам мы уже будем применять политики. Они односторонние. Zone pairs — это именно односторонняя штука. Мы сказали, что у нас есть такая пара, она называется inside-to-outside, и в ней трафик, который идёт из inside в outside. Всё, применяются политики к этой паре. А ответный трафик понятно будет разрешаться — инспекция будет работать. Но именно инициатор трафика отсюда сюда будет посылать пакеты.

Можно направление назвать. Да, было бы понятнее, если бы направление. Андрей говорит: не одно, так другое, геморрой. Это не геморрой, это на самом деле простая и понятная концепция. Давайте дальше по поводу этих зон и пар говорить. Дальше мы приступаем к такой вещи, которая называется C3PL — Cisco Common Classification Policy Language. На самом деле это всё та же самая штука, которая у нас была на ASA и называлась Modular Policy Framework, которая есть в QoS и называется MQC Framework. И так, Андрей, это не «немного напоминает» — это всё то же самое. Я сказал, что одна и та же вещь в зависимости от контекста у Cisco называется разными именами. Все эти аббревиатуры, которые любит Cisco...

Запомните, пожалуйста, это название: C3PL — Cisco Common Classification Policy Language. Может быть, на экзамене будут спрашивать, на экзамене любят аббревиатуры всякие спрашивать. Это всё то же самое — концепция, где мы будем работать с тремя сущностями: классифицируем трафик — class map, потом определяем какие-то действия — policy map, и потом применяем уже политику — service policy. В отличие от ASA, service policy будет активировать наши политики именно для пары зон. В ASA на интерфейсе надо применять, а здесь — для пары зон. Здесь немножечко это удобнее, не надо для каждого интерфейса заморачиваться, я уже привёл пример. Давайте смотреть, как всё это конфигурируется.

Но сначала — что это такое. Здесь очень важные вещи, поэтому лучше разжевать их поподробнее. Во-первых, что такое class maps. Class map — это метод классификации трафика. Самый простой метод классификации трафика, который вы знаете, — это access-листы. Здесь немножечко будет концепция пошире, здесь будет больше возможностей, чем просто access-листы. Мы можем использовать, кстати, и простые access-листы в этой конструкции. Мы можем использовать обнаружение протокола по поведению, мы можем указывать какие-то вещи для конкретных протоколов, мы можем — там очень много вариантов классификации, там можно очень гранулярно определить и отделить конкретный трафик. Вплоть до того,

что пакеты протокола SIP, который содержит ошибки, — их обрабатывать уже как-то отдельно. Даже вот таким образом class map — очень мощный инструмент. Если говорить не только про критерии, а как он будет работать — смотрите, class map может реализовывать логику «и» либо логику «или». Это очень похоже на route map, там тоже можно задавать «и» или «или». Хотя нет, не похоже, ничего. Давайте про route map не будем говорить, это потом. Мы можем сказать: либо все наши критерии должны подпадать в class map. Да, Андрей, я перепутал с policy map, прошу прощения. Route map — это там нет такого. Здесь мы можем говорить: либо все критерии

подпадут, которые мы укажем, либо по какому-то одному критерию. Например, мы можем сказать — видите на картинке: совпадение 1, совпадение 2, совпадение 3 и так далее. Мы можем сказать, что трафик от хоста такого-то к хосту такому-то — access-лист прям здесь задать, и второе совпадение, например, порт номер 80. Мы можем сказать match all — это значит, должны все критерии у нас сработать, то есть «и»: трафик от хоста такого-то к хосту такому-то, и ещё если этот трафик идёт на 80-й порт — только тогда этот class map сработает. Либо сказать другую логику — match any, то есть либо трафик, который идёт между этими двумя конкретными хостами, либо трафик, который идёт на 80-й порт, неважно какие хосты. Здесь в class map можно реализовать

логику двух видов — понимаете, либо так, либо так. Смотрим дальше. Про policy map — здесь немножечко более замороченная вещь, хотя не такая замороченная. Смотрите, мы определили классы, а дальше policy map — это вещь, похожая на route map где-то в чём-то. Это тоже как написано на таком псевдоязыке — программу можно это так рассматривать. Мы для каждого класса можем применять какие-то действия. Мы сказали, что трафик, который подпадёт под этот класс, — к нему применять действия. Как роутинг, смотрите: подпадёт под этот класс — к нему применять какие-то действия. Не подпал — следующий проверяем. Если подпал под этот class map — будем другие действия применять. И так далее. Policy map

могут быть довольно-таки развесистые, очень развёрнутые. Какие можно применять действия — это inspect, permit, drop и log. Inspect означает, что для трафика, который был определён в class map, нужно разрешить ответный трафик. Если мы написали inspect — мы, например, написали в class map весь трафик, который идёт на 80-й порт, web traffic, и сказали, что для этого class map надо применять действие inspect. После этого наш firewall будет смотреть: подпал web traffic, кто-то ломится на 80-й порт, значит, надо его разрешить и плюс разрешить ответный трафик — мы в таблицу состояния запишем. Роутер в свою табличку состояния запишет: сейчас у меня прошёл пакетик от этого хоста к

этому хосту, протокол такой-то, и порты такие-то использовались. И потом, когда пойдёт ответный трафик, например, второй пакет TCP ответный, то роутер его уже разрешит. Это действие inspect. Мы говорили про инспектирование — вот это именно оно. Либо, в случае с протоколом FTP, который мы немножечко разбирали с вами, — там это будет инспекция на уровне протокола, на уровне приложения. Он будет — firewall будет смотреть уже внутрь самих пакетиков, что же там написано в управляющем трафике FTP, и открывать нужные порты. Вот эта инспекция. Permit — это просто одностороннее действие, это просто разрешить прохождение пакета. Написано в class map: трафик на порт номер 80, весь трафик — для всего

этого трафика мы просто будем пропускать в одну сторону пакеты. То, что там ответка пойдёт, нас это вообще никаким образом не интересует — у нас написано permit, не inspect, это разные вещи. Если просто запермитить, то понятно, что TCP никакое не установит соединение, ничего не срастётся. Permit — нет, Андрей, не разрешает обратный трафик. Мы сейчас говорим не про какой-то там IOS, мы говорим про конкретную технологию — zone-based firewall. В этом фаерволе если сказали permit, то будет просто permit, просто в одну сторону пакетики разрешат. Это удобно для какого-то трафика, для которого не требуется ответа. Например, syslog, UDP, 514-й порт. Мы с вами про это говорили, что там ответный трафик не нужен. Железка льёт какие-то логи куда-то — и всё. И мы их разрешаем в одну сторону, syslog-сервер собирает у себя, и всё, всё прекрасно. Мы просто запермитили этот трафик. Например, если говорить про DMZ, демилитаризованную

зону, то очень часто бывает так, что syslog-сервер стоит внутри нашей сети, в inside-зоне, и от серверов, которые в DMZ — у нас крутятся там почтовый, веб-серверы, FTP или ещё что-то — мы разрешаем трафик к syslog-серверу, именно UDP, именно 514-й порт, совершенно осознанно, и просто действие permit. Наш firewall будет пропускать этот трафик, но обратно ничего. Действие drop — это действие просто дропать трафик, мы сбрасываем пакеты. Действие log — оно будет применяться вместе с drop, чтобы ещё логировать. Теперь, действия к классам будут применяться в том порядке, в каком они были указаны в конфигурации. Мы в конфигурации прям должны очень жёстко прописывать порядок этих

действий, порядок наших class map, порядок сравнения. Здесь так же, как в access-листе — само собой ничего не распределится по местам: первое, второе, третье место. Дальше, весь неклассифицированный трафик, который не подпадает ни под один класс, — есть специальный класс default. Мы можем этих class map написать сколько угодно. Если не попадёт никуда наш трафик — здесь мы, например, написали трафик 80-й порт, здесь почтовый трафик, 25-й, 110-й, 143-й — не подпадёт никуда — у нас ещё есть класс default, куда трафик попадёт точно. И действие по умолчанию для этого класса default — drop. Всё. У нас выбор

небольшой: либо обработать этот трафик, который был отобран class map, либо firewall сам о нём позаботится. А позаботится он просто — drop. Всё, потому что он попал в class default, и всё, drop. В принципе мы можем сказать для класса default другое действие, переопределить, но не нужно так делать. Пусть класс default он так и останется классом по умолчанию, который дропается. Сами понимаете, что гораздо — правильно Миша сказал — гораздо эффективнее работает политика, что всё, что не разрешено явно, то должно быть запрещено. Это нормально, когда так работает firewall. И иногда некоторые идут от обратного — они всё разрешают, а потом запрещают какие-то конкретные вещи. Но я не считаю, что это правильно с точки зрения безопасности. Опять же, вспоминаем принцип минимальной привилегии — эти принципы безопасности, которые мы в первые дни курса

рассматривали, они должны работать. Дальше, давайте дальше смотреть. Ещё раз действия в policy map. Мы проговорили, что inspect следит за состоянием сессии — разрешить межзонный трафик протоколов, инспекция которых поддерживается в ZBF. В ZBF поддерживается огромное количество протоколов. В принципе ZBF умеет работать — я не знаю, с чем он не умеет работать, хотя может быть с какими-то совсем экзотическими протоколами. ZBF не умеет — что такое «поддерживается в ZBF или не поддерживается»? Это когда firewall умеет правильно обрабатывать. Можно TCP правильно обрабатывать, почему нет —

разрешать обратный трафик: на пакет SYN разрешать уже SYN-ACK. Когда можно работать с TCP просто по номерам портов. Но какие-то уже более сложные протоколы, где внутри на уровне приложения передаётся информация о портах, — там, конечно, ZBF должен уметь с ними работать. Но скажем так, он умеет работать в принципе. Совсем если не умеет inspect — два permit в каждую сторону. Если не умеет вдруг инспектить какой-то протокол, ничего, конечно, не остаётся, как permit в одну сторону написать и permit с другой стороны. Если это уж совсем не получается — может быть, можно просто обойтись инспекцией TCP или UDP. Необязательно же инспектить всё на уровне приложения, не надо, как правило, вообще. Pass — то же самое, что и permit.

Как правило, вообще, как делается: инспекцию разрешают просто TCP и UDP — общая инспекция. И уже для каких-то специфических протоколов, например SIP или например FTP — что-то такое специфическое, где в теле протокола уже будут идти команды, где будут указываться порты, — тогда добавляются отдельные инспекции для этих протоколов. Pass мы поговорили. Разрешить межзонный трафик протоколов, инспекция которых не поддерживается, — то есть совсем не поддерживается, тогда только pass делать, permit. Drop мы поговорили, тут всё понятно. Log — ещё раз повторяю, это просто журналирование пакетов, будет лог записываться. Пакеты определённого класса, только совместно с drop. С permit log вообще не надо использовать, никогда, даже в access-листах

не надо permit что-то и потом делать log, потому что логировать нужно только запрещённый трафик. Хороший трафик логировать — у вас никакого syslog-сервера на это не хватит. Может быть, есть какие-то исключения, с целью потом установить правильность — как в качестве дебага можно использовать, но всё время логировать нормальный трафик я бы не стал, скажем так. Миша правильно говорит — CEF, трафик. В этот просто свитчинг попадёт. Давайте дальше. Вот это табличка, она будет — давайте просто запоминать. Я её проговорю, и

если кто-то будет сдавать экзамен, скорее всего, вас это спросят: как будет обрабатываться трафик между интерфейсами. Дело в чём. Бывает — интерфейс принадлежит зоне, и другой интерфейс тоже — здесь вообще всё понятно, пара зон создана, это всё будет работать как надо. Но если интерфейс не принадлежит зоне или пара зон не создана — тут уже будет путаница. Давайте проговорим. Прям по строчкам. Если оба интерфейса не принадлежат ни к какой зоне — ZBF не будет работать. ZBF работает только в случае, когда у нас существуют зоны. Если просто так трафик ходит между интерфейсами — к чему там применять firewall, как применить? Policy, service policy вешается на зоны, на пары зон, так что никак. Если хотя бы

один из интерфейсов тоже не принадлежит к зоне, ZBF тоже будет блокировать трафик. Смотрите, здесь очень важный момент: когда настраиваете firewall ZBF, нужно, когда вы написали все правила, все policy map, service policy, сначала создать зоны, поместить в них интерфейсы, потом создать пару из этих зон, и только потом на неё навесить service policy. По-другому у нас всё будет дропаться. Должно быть в этом случае всё настроено. Если интерфейсы принадлежат к одной и той же зоне, мы уже говорили, то между ними трафик пропускается. Если два интерфейса — например, интерфейс inside, наш внутренний, и какой-то туннельный интерфейс — принадлежат к зоне inside, то всё, никаких проблем, трафик между ними пропускается.

Если у нас что-то не сконфигурировано — я объясняю просто простыми вещами — если что-то не сконфигурировано, например, мы пару зон ещё не определили, интерфейсы уже настроили, пару зон ещё не настроили — тоже всё дропится. Если мы настроили интерфейсы, в зоны определили, пару зон настроили, но ещё политику никакую не определили — тоже всё дропится. Только когда мы всё настроили, тогда будет политика работать. Так что логика — давайте ещё раз логику определим такую общую, на экзамене если будет эта тема. Ещё раз, общая логика: только тогда, когда мы всё настроили — создали зоны, поместили туда интерфейсы, сделали пару зон, сделали политику, применили service policy — только тогда эта политика будет работать, только тогда у нас firewall заработает в полную силу. Во всех остальных случаях будет drop, когда

что-то не донастроили — будет drop. Единственное исключение — когда два интерфейса в одной зоне, там понятно, там будет pass. Либо когда интерфейсы просто вне зон, сами по себе, не в какой зоне — тогда ZBF просто не будет работать, трафик тоже будет соответственно пропускаться, или там могут быть access-листы у вас какие-то. Эта логика понятна более-менее? Ну, легко — не легко, а если на экзамене спросят, что будет, если у вас всё настроено, но пару зон забыли создать, — ответ просто: drop. Пока что-то не настроено — drop. Всё. Исключение: либо когда интерфейсы в одной зоне, либо когда интерфейсы вообще вне зон, просто сами по себе — тогда будет ходить трафик. В остальных случаях, пока не настроено, не достроено — всё, крах. Давайте продолжать. Порядок конфигурирования — всё C3PL. Сначала определяем зоны. Я немножко неправильно

сказал порядок — интерфейсы в последнюю очередь. Сначала определили зоны, потом пары зон, потом мы классы трафика определили, политики уже на основании этих классов, потом применяем всё к паре, а в последний момент уже туда интерфейсы будем запихивать. Для дебага нужно выкидывать, Миша спрашивает, интерфейс из зоны, чтобы посмотреть, влияет ZBF или нет? Для какого дебага? Смотря — тогда будет drop. Если просто посмотреть, как работает на интерфейсе, можно выкинуть из зоны, хорошая идея. Если там посмотреть — но можно просто из зоны, если хочется посмотреть, как на интерфейсе работает что-то, можно log поставить. Можно, да, можно просто выкинуть из зоны и тогда два интерфейса посмотреть — между ними ходит трафик. Потом раз —

в зоны их опять поместить, не ходит — и уже разбираться с логами ZBF самого. Хорошая идея. Начать с Excel — хорошая идея. Я предлагаю сделать какой-нибудь суперлаб, у нас всё время есть, и попробовать разобраться с этим именно на примерах. Давайте — на слайде было сказано про Excel. Действительно, Excel — хорошая вещь. Сейчас объясню почему. Любое мощное конфигурирование должно у нас начинаться с мощного планирования и проектирования. Чтобы разобраться с конфигурированием ZBF, лучше сначала обратиться к простым таблицам и всё это дело нарисовать наглядно. Я в своё время через это проходил — я пытался сконфигурировать ZBF

у себя на предприятии, и запутался очень быстро в конфигурации. Действительно быстро я там начал писать конфигурацию, потом — короче, сложно было. Сначала не осилил, честно признаюсь. И в блокноте потом стал разбивать по кускам кода — тоже как-то не зашло. Потом плюнул на всё, открыл Excel и просто в нём всё нарисовал. Это несложно. Итак, давайте возьмём простой пример. У нас будут две зоны: зона inside и зона outside. Трафик у нас — давайте два типа возьмём трафика. Например, веб-трафик — ну так, примеры из жизни: пользователям нужно ходить на внешние серверы, плюс нужно дать доступ на внешние веб-серверы, плюс надо пользователям дать доступ на внешние почтовые серверы. И

ещё что-нибудь придумаем. Итак, как мы будем в Excel прямо рисовать. Для начала мы будем использовать class map. А ещё у нас будут какие-нибудь пользователи-суперадминистраторы, которым нужно разрешить вообще весь трафик — и торренты качать, и порнуху смотреть. У нас только Layer 7 пока нет на стенде — какая разница, мы можем настроить что угодно. Пока давайте так. Ещё раз всё проговариваем. У нас есть такая сущность, как class map. Нам нужно определить эти class map. Поехали. Сначала разберёмся с веб-трафиком. Прям так и назовём: class map web — вот так будет называться class map web. Теперь давайте расписывать. Class map у нас будет иметь логику match any. Это важно, то есть либо трафик, который подпадёт под 80-й порт, либо трафик

HTTPS, который подпадёт под 443-й порт. И здесь мы можем написать такую штуку: смотрите, мы можем сказать — как написать подпадение трафика. В принципе можно access-лист написать, в котором мы напишем permit any any порт 80. Но гораздо удобнее сразу определять протоколы. Мы можем сказать, что match protocol — по-моему, он пишется вот так: www. Дальше, второй — 443-й порт, я не уверен, что можно написать match protocol. Нет, у него по match protocol 443 — сейчас, я подумаю. Ну, либо

access-лист включить, так как он не умеет 443-й порт. Давайте access-лист ещё напишу. Хорошо, здесь match protocol мы сказали. Давайте ещё 443 сюда же запихнём. Мы запишем access-лист — прямо так напишем: пока всё очень схематично. Access-лист extended HTTPS, я люблю так всё писать. Permit TCP any any eq 443. Я думаю, это все понимают. Access-листы я буду выделять каким-нибудь зелёненьким, а это я буду выделять каким-нибудь жёлтеньким — это тоже важно.

Дальше, сейчас подождите, сейчас я просто хочу, чтобы красиво было всё и очень наглядно. Дальше, во второй строчке я буду писать уже не match protocol, так как 443 нас не позволяет указать как протокол, а я напишу немножечко по-другому — я напишу match access-group HTTPS. Вот таким образом, сейчас я здесь поставлю какую-нибудь красивую стрелочку, чтобы вам было понятно. Окей. Мы здесь можем ссылаться на какой-то access-лист. Мы написали первый class map, в котором

сказали, что если у нас либо протокол будет www, 80-й порт, либо у нас access-лист подпадёт — всё, значит, этот class map сработал. Пишем второй class map — class map будет называться mail, весь почтовый трафик. То же самое — match any. Давайте даже покруче сделаем — match all. Создадим ещё access-лист. Access-лист — можно стандартный. Если стандартный — назовём его access-лист site. Мы здесь напишем про нашу внутреннюю сеть: permit 10.2.1.0. Вот такой будет у нас хитрый access-лист, который будет иметь в виду нашу внутреннюю сеть. И здесь мы скажем: match access-group site. Дальше — match protocol SMTP,

match protocol IMAP, и, например, match protocol POP3. По-моему, все эти протоколы умеет. Этот access-лист — сейчас давайте тоже стрелочку нарисуем, мне понравилось стрелочки рисовать. Вот таким образом. Match all — да, будет ошибкой. Прошу прощения. Смотрите, как сделать. Если мы хотим сделать здесь match all, нам надо соблюсти условия для этой сети и для этой пачки протоколов. Можем выкрутиться, конечно, можем. Мы можем создать вложенный class map. Можем, конечно,

какие проблемы. Мы возьмём, создадим другой class map — mail-protocols. Я же вам не сказал, что class map можно вкладывать один в другой. Конечно, можно — это очень легко и весело. И здесь скажем: match class-map mail- protocols. Это красиво стрелочку поставим, чтобы было понятно. Без этих стрелочек, без такого наглядного представления просто так сконфигурировать, конечно, не получится. Зато здесь всё понятно: этот у нас — либо это подпало, либо это подпало в этот class map. У нас — да, здесь match any. Спасибо, Андрей сказал.

А здесь у нас должно подпасть первое условие — access-лист, и второе условие — один из этих протоколов. Нравится? Уже. Давайте дальше. И третье — давайте разрешим пользователям, которым супер-админ, вообще разрешим на самом деле вообще всё. Мы создадим третий class map, назовём super-users. И скажем match access-group — access-лист super-users. Запись идёт, и этот class map у нас будет ссылаться на access-лист. Пусть будет стандартный: super-users — permit 10.2.1, не знаю, какой-нибудь

там подсеточку им. Без разницы. Не будем сейчас заморачиваться очень сильно. Зачем permit host? У нас же целая подсеть юзеров, не один хост. Итого, с class map мы разобрались. Тут же вроде всё просто и понятно, правда, ничего такого сверхъестественного нет. Мы определили три class map, они прекрасно работают. Пока ещё мы не знаем, как всё это работает, но работать будет. Теперь давайте писать следующую вещь — это мы ещё конфигурацию не стали писать. Дальше — а ещё знаете, как можно сделать ещё круче? Если там заморочиться — если здесь будет несколько, это CPU загрузит, я не могу сказать, насколько это CPU загрузит, правда, но

Нет, не особо сильно грузит. Все эти классификации потом скомпилируются в очень простые сущности, и я не могу сказать, что такая развесистая конфигурация будет как-то грузиться. А знаете, как бывает — бывает ещё вот так: у нас здесь несколько подсетей, в которых сидят суперюзеры. Вот у нас, как пример просто, куда мы можем дальше пойти в нашей конфигурации — догадались, конечно — object group. А здесь мы можем ещё написать object group «super users» и сказать object group network, вот так вот написать.

Ещё так, я извиняюсь, вот. И здесь уже сказать host network, там такая-то, там 10.220... Потом, сейчас давайте для красоты всё сделаю красиво: .04, .05, .06, .0. Потом в этот access list вот так делаем и говорим permit object group «super users». Вот такую конструкцию мы с вами делаем — это будет ещё прикольнее. Так, видно или слишком мелко получается? Нет, нормально. У нас с вами получается уровней

абстракции здесь уже в принципе дофига, и конфигурация получается такая уже непростая. С другой стороны, место в конфигурации будет сокращаться. В принципе это не так сложно, главное сначала — вот я сделал в Excel — нарисовать. Я вас призываю к тому же: если будете планировать и как-то проектировать правила файрвола, не поленитесь, нарисуйте прямо вот так. Что такое match-объекты? Вот здесь match — нет, либо access-листы можно матчить, либо протоколы, либо access group, либо другие class map, либо протоколы. Но есть ещё там protocol violation, нарушения протоколов, но это не будем разбирать. Дальше — всё с

первой сущностью class map мы разобрались. Теперь давайте... прошу прощения, не service map, а policy map. Будем писать policy map. Policy map у нас будет одна. Можно также сделать несколько, делать вложенные, но лучше сделать одну policy map на каждое направление трафика. Можно в принципе сделать несколько, хотя я не знаю, нужно ли делать несколько policy map — нет, не нужно. Окей, создаём policy map. Policy map у нас будет называться простым и понятным именем: inside-to- outside. Я призываю вас всё называть очень понятными именами. И здесь мы в policy map будем говорить: всё,

что касается класса web — L7_web — и определяем для него действия, мы будем инспектировать. Всё, что касается класса почтового — L7_mail — мы тоже будем инспектировать. И всё, что касается класса L7_super_users, прошу прощения, мы пусть будет permit. Pass — в конфигурации пишется pass, хотя говорят и permit, и pass. У нас получилась вот такая структура, где мы с вами будем работать с классами, и для каждого класса мы написали какое-то действие. Для какого-то класса мы сказали, что нужно делать inspect, а для какого-то класса мы просто сказали pass — всё просто пропустить.

Это получилась вторая сущность, которую нам нужно настроить. А дальше мы с вами уже создадим пару зон. И последняя сущность — это у нас будет service policy. Service policy здесь писать не надо, потому что это просто команда, которая применяет нашу политику, наш policy map, к парам зон. Давайте теперь в консоль — в консоли будем сверяться со всем, что мы тут наконфигурировали, и будем делать нашу конфигурацию, сверяться с тем, что мы спроектировали. Здесь это не всё, что я хотел вам рассказать, здесь мы будем уже конкретику смотреть. Но смотрите, сначала

конфигурировать нужно в том порядке, в котором мы написали с вами в нашем проекте, в нашей таблице Excel, чтобы не запутаться. Сначала сконфигурировать все подчинённые объекты, а потом уже на них ссылаться. Если мы сейчас начнём конфигурировать class map и скажем ссылаться на access list — нет, не будет ругаться, не должно, хотя можно проверить. Давайте, как всё дело у нас настраивается и конфигурируется. Поехали — сначала class map. Будем делать class map. Обратите внимание на такую ремарку: в конфигурации нам надо всегда говорить class map type inspect.

Type inspect — это говорит, что именно этот class map предназначен для файрвола, потому что есть ещё class map другого характера, например, которые для QoS применяются. Вот видите, тут есть class map и для QoS, например. Type inspect нам говорит, что мы сейчас конфигурируем именно файрвольный class map, чтобы система, оболочка командная, она будет уже подсовывать вам вопросики только нужные и параметры этого class map. Окей, class map type inspect, назовём его, как он у нас назывался — L7_web. И погнали: match protocol.

Вот тут протоколов, сами видите, фигища. WWW, HTTP/S/2 — он нам так говорит, потому что потому что инспекция WWW у нас здесь не работает. Очень интересно. Сейчас, может быть, это я запутался и он правда не умеет. Всё, это порт. А так он HTTP/S умеет. Но в принципе всё. Миш, спасибо. Это HTTP, и у нас там был access-листом он написан. Это HTTPS. Окей, do show class map, посмотрите. Match any — сейчас

по умолчанию будет подставляться match-all. Мы не указали match-any просто потому, что хотелось проверить — по умолчанию будет match-all. Поэтому давайте этот class map перепишем быстренько. Почему-то Ctrl+A в консоли работает через раз, я не знаю почему. Так, match-any, L7_web. Do show class map. Вот, здесь надо всё время говорить type inspect, type inspect, type inspect — когда файр- вольные все команды, у них везде параметр type inspect. Дальше пишем class map — это у нас почтовые протоколы, но мы их для конкретной подсети описали. Сначала лучше сделать access list стандартный, который у нас есть, а потом уже на него ссылаться,

чтобы — сами понимаете — надо сначала делать подчинённые объекты. IP access list standard site, и дальше пишем permit — какой у нас там был — 10.2.10.0 /24 маски хватит. Do show access list — вот он у нас появился. И дальше пишем class map. Class map type inspect. Вот здесь у нас match-all. Смотрите, если я сейчас — сейчас начнём запутываться уже в конфигурации, потому что я сразу стал конфигурировать этот, не сконфигурировав подчинённый class map. Он сейчас должен ругнуться. Match-all, L7_mail. И здесь мы будем говорить match access group name «site»,

inside. И match — у нас здесь, смотрите, подчинённый есть class map — match class map L7_mail_protocols. Нет, не ругнулся. Service policy будет ругаться, если не будет подчинённый, а здесь не ругается. Теперь быстренько описываем почтовые протоколы. Вы уже запутались, наверное, я думаю, что у вас уже мозг дымится от этих class map. Class map type inspect match-any L7_mail_protocols. Но в принципе просто, когда нарисована уже такая картинка, конечно просто. И мы здесь говорим match protocol SMTP, протокол SMTP, протокол POP3, протокол IMAP. Дальше — это мы сконфигурировали, это мы с

вами сконфигурировали второй class map. Отбор трафика WWW мы сделали, отбор трафика почтового мы сделали, притом с условием, что ещё должна подпасть конкретная сетка. И суперюзеры — давайте для краткости не будем, потому что время уже дофига. Я думаю, что здесь понятна идея сама, и вы сами можете попробовать. Теперь policy map — вторая сущность, это policy map. Посмотрим: do show class map type inspect — вот они, class map, и у нас три class map. Так, вот в чём прикол: class map, который L7_mail — вот он — мы делали, я указал ему не существующий на тот момент другой class map, и он его не подхватил.

Он не ругнулся, но не подхватил. Поэтому мы ещё раз скажем: class map type inspect match-all L7_mail, и скажем match class map L7_mail_protocols. Вот, теперь он подхватил. Вот этот class map у нас ссылается на вот этот большой. Почему здесь match-any? Нет, здесь как раз был прикол в том, что в этом class map мы хотим, чтобы и под access list подпало, и под один из почтовых протоколов. Так что match-all здесь у нас — всё правильно. Сейчас дальше давайте, Excel я скину. На записи, я думаю,

что там посмотрите, всё будет видно, как я рисовал. Главное логику понять. Всё, class map мы создали, трафик отбирать мы теперь можем вроде, правила такие не очень сложные. Теперь создаём policy map — собственно, саму обработку вот этих классов трафика. И говорим: policy map — здесь тоже надо всё время говорить type inspect, потому что если не сказать type inspect, то policy map она тоже бывает для QoS и так далее. Policy map type inspect, назовём её PM_inside- to-outside. И здесь уже будем говорить, для какого класса что мы с вами делаем. Говорим: class — в policy map мы говорим class L7_web. И теперь что мы с ним можем делать? Вот смотрите: drop,

inspect, pass, либо можно policy — это уже другую policy map применить, то есть здесь тоже можно вкладывать одно в другое. Нет, мы просто говорим, что этот класс трафика мы будем инспектировать — пропускать в одну сторону и ждать ответного трафика, и пропускать в другую сторону. Дальше для второго класса говорим: теперь для класса почтового трафика L7_mail мы скажем тоже inspect. Готово. Теперь если мы посмотрим, что у нас получилось: do show policy map type inspect — вот она у нас, политика, которая называется inside-to-outside, в которой мы сказали, что этот класс мы инспектируем, этот класс мы тоже инспектируем. Всё, политика создана. Что надо сделать дальше? А дальше нужно создать те самые зоны и

пару зон, и применить к ним политику. Давайте создавать эти самые зоны. Как это делается — мы просто говорим: zone security, будет называться зона inside. Я везде добавляю, если видите, вот эту первую строчку — первую букву. Окей, там такое-то, вот так. Мне нравится. Дальше мы создаём zone security outside. Всё, две зоны по двум сторонам роутера у нас создано. Теперь мы помним, что интерфейсы мы помещаем в самую последнюю очередь. Теперь надо создать как раз вот эту пару зон. Мы говорим команда zone-pair security. Zone security, zone-pair security —

вот в ZBF то, что нас относится к ZBF — команды type inspect просто запомните. И security мы везде, на самом деле, zone-pair просто так ничего не даст, надо писать security. Zone-pair security, назовём её ZBF_inside- to-outside. Я длинные имена люблю — понятные, зато понятно, что это за пара зон, откуда идёт трафик и куда. И дальше говорим, что source, то есть зона, из которой пойдёт трафик, — у нас зона inside. Здесь, кстати, подставляется прикольно. Destination этого трафика — зона outside. Всё. Можно посмотреть: do show zone security — нам покажут, какие у нас зоны есть. Обратите внимание, есть zone self — это та зона, где у нас

обозначен весь трафик, который идёт к роутеру. Что я забыл сделать? Да, наверное, ничего не забыл сделать. Давайте дальше. Zone-pair мы создали, и последнее, почти последнее, что нам надо сделать — применить вот эту самую политику, наш policy map, применить к вот этой паре. Сейчас если do show zone-pair security — вот у нас есть такая команда show zone-pair security, она показывает созданные пары зон и собственно откуда, куда, и говорит, что service policy не сконфигурирована, то есть на этой паре у нас ещё никакая политика не висит. Политика применяется очень просто: service-policy, опять все эти type inspect, и говорим, как у нас называется политика — я уже забыл, как я назвал политику — PM_inside-to-outside. Сейчас он немножечко задумается. Теперь

если мы посмотрим на наши зоны: show zone-pair security — то нам покажет, что у нас есть пара зон, source такой-то, destination такой-то, и что применена вот такая политика на этой паре. Последнее, что нам нужно сделать — это поместить интерфейсы в зоны, после чего всё заработает. Это делается на самом интерфейсе. Так, у нас, судя по топологии, GigabitEthernet 0/1 — это будет outside, а GigabitEthernet 0/0 — inside. Пусть так будет. Interface GigabitEthernet 0/1, и говорим, что этот интерфейс относится — zone-member security — этот интерфейс относится к зоне outside. Правильно, 0/1 — outside. А interface GigabitEthernet 0/0 относится к зоне inside. Всё, на

этом конфигурация firewall закончена. Полезные команды, которые надо вам показать. Во-первых, ещё раз вспоминаем вот эти все сущности: class map и policy map. Class map — отбираем трафик, policy map — это политика, что делать с этим трафиком. Show class map type inspect — посмотреть классы, по которым отбираем трафик. Show policy map type inspect — это посмотреть политику, что мы будем делать с трафиком. Обратите внимание: последняя строчка — class-default drop. Всё, что не попало в эти два класса — вот сейчас при прохождении трафика из зоны inside в зону outside, если какой-то трафик под эти два класса не попал, то

он попадает в class-default и дропится. Эти два класса определённых мы делаем inspect. Я уже сказал, что inspect — хватит, повторяюсь. Если что-то нужно поменять — да, всё на лету меняется. Если нам нужно добавить в class map mail какой-то ещё почтовый протокол, например IMAPS, SSMTP — он по- моему разрешает добавлять — можно просто отредактировать class map, больше ничего делать не надо. Если что-то надо поменять в политике, например для class map mail сделать pass вместо inspect, то тоже можно. Давайте поменяем. Policy map, type inspect, длинное название —

PM_inside-to-outside, class L7_mail, pass. Вот, смотрите, здесь он сейчас скажет, что для этого класса уже было сконфигурировано действие inspect. Сначала надо сказать no inspect, и потом сказать pass. Всё. Теперь если посмотреть политику — show policy map type inspect — то у нас на лету всё поменялось. Здесь в принципе не нужно интерфейсы изымать из зоны или снимать политику с пары зон — не надо, это всё применяется сразу. Это конечно удобно. Вот ZBF, я ещё раз повторюсь, мне нравится эта штука, я фанат ZBF. Очень гранулярно, очень гибко, и всё в реальном времени. Надо подредактировать class map — взяли, подредактировали. Надо сделать инспекцию для какого-то нового протокола, который

там появился у нас — поставили какой-то, не знаю, SQL-сервер, который должен быть снаружи доступен или ещё откуда-нибудь — взяли, добавили новый class map, описали трафик этого SQL-сервера, и в policy map добавили ещё одну строчку, что класс такой-то, SQL, и его надо инспектировать, например. И после этого файрвол будет уже этот class map с новой строчкой точно так же обрабатывать, и трафик будет работать. Ещё полезные команды, пока не забыл: show zone security — просто покажет наши зоны. Обратите внимание, он покажет, какие зоны есть и какие интерфейсы в какие зоны у нас были помещены, если вдруг забыли, как там наконфигурировано. Есть такая show zone-pair security — показывает, какие пары зон у нас созданы и какая политика, какой policy map к ним применён. Не путайте команду service-policy и policy map. Policy map —

именно для описания нашей политики, для описания действий, а service-policy — это просто команда, которая применяет нашу политику к паре зон. Мы точно так же можем написать вторую zone-pair, например outside-to-inside, в другую сторону трафик, и на неё вешать уже свою политику. Вот таким образом. На страже ещё есть замечательные команды, которые помогают: show policy firewall — здесь можно посмотреть сессии. Прямо сейчас у нас нет никакого такого трафика, но вот команда очень прекрасная: show policy firewall sessions — она показывает все открытые сессии, которые в данный момент есть. Show policy firewall config — показывает в наглядном, почти в наглядном виде всю нашу конфигурацию: show policy firewall config — и зоны всё покажет, и zone-pair

покажет, и что к ним применено, какие class map, какой action. Покопайте show policy firewall — там полезные. Show policy firewall... честно скажу, не помню — по-моему, он показывает вообще логи, если у нас есть логи, либо которые мы ему заказали вместе с действием drop, либо которые он сам пишет. Policy firewall на самом деле в лог генерирует много всяких сообщений, даже если его не просить. Логи — там ошибки протокола будет записывать, либо ошибки TCP, иногда бывает что-то такое, он будет тоже в лог это сыпать. Там логи такие хорошие, я посмотрю у себя на роутерах, что же это. Он говорит, так... Ну и, пожалуй, на сегодня всё.

Вы скажите, пожалуйста, ещё остались какие-то пробелы? Вот zone-based firewall — логи, они все вообще кучу — он использует syslog, обычный syslog. Zone-based firewall пишет стандартный syslog. В принципе здесь ничего сложного нет, надо просто — весь секрет zone-based firewall — вот в таблице Excel. Вот и всё. Я не думаю, что вам ещё на каких-то Cisco-курсах будут Excel показывать, так что в этом отношении наш курс отличается от других. Но это так, себя похвалил. Так что рисуйте всё всегда на бумажке, в Excel — как угодно. Просто сначала проектирование вот с графическим отображением, а потом уже набивка конфигурации. Потому что если бы я сейчас вам стал показывать тупо вот этот конфиг,

вы понимаете, что ничего бы у нас не получилось, и мы бы делали с вами там до утра, я бы сам запутался. Здесь есть в чём запутаться, и всё время в голове надо держать, когда конфигурируешь, вот когда есть такие подчинения, структура подчинённости. Вот есть такая структура подчинённости, и всё время надо в голове держать. А свои боевые таблицы Excel я не буду показывать, у меня вот где я проектировал своё, но вот если какая-то система чуть посерьёзнее, там такое... Да нет, вы сами составите. Хорошие идеи вообще. Даже если вы не собираетесь конфигурировать zone-based firewall, хорошая идея просто составить такую таблицу хотя бы для того, чтобы понимать, какой трафик у вас есть в сети. Если вы никогда не заморачивались тем, чтобы понять, чего там есть — хотя есть автоматические всякие

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