Cisco IOS ACLs

    Всем доброго дня!

    В этой статье я бы хотел поговорить про возможности Cisco IOS Access Control Lists (ACLs). Тема многим из вас должна быть знакомой, поэтому мне хочется обобщить информацию по разным типам ACLs. Я кратко пробегусь по основам, а затем поговорим про специальные типы ACLs: time-based (на основе времени), reflexive (отражающие), dynamic (динамические). Итак, начнем…

    Основы: Вспомнить все…


    Быстренько пробежимся по основным понятиям, синтаксису, чтобы потом проще можно было перейти к более интересным вещам. ACL’ы на роутерах Cisco позволяют решать две группы задач:

    • фильтрация трафика;
    • классификация трафика.

    Эта статья посвящена в основном фильтрации, т.е. использованию ACL в качестве firewall. Классификация позволяет вам отобрать пакеты, для последующей обработки. Например, шифровать только определенный трафик при создании VPN, применять политики качества обслуживания, транслировать только определенные адреса и т.д.

    ACL’ы можно отнести к брандмауэрам пакетной фильтрации (packet filtering firewall). Т.е. они позволяют выполнять фильтрацию пакетов по пяти параметрам:

    • IP адрес источника
    • IP адрес назначения
    • Протокол, инкапсулированный в IP-пакет
    • Порт источника
    • Порт назначения

    ACL’ы делятся на 2 типа:

    • Стандартные (Standard)
    • Расширенные (Extended)

    Стандартные ACL’ы позволяют фильтровать трафик по одному единственному критерию – IP адрес источника. Расширенные ACL’ы фильтруют по всем пяти перечисленным параметрам.

    ACL состоит из набора правил. В каждом правиле вы определяете параметры фильтрации (адреса, порты и т.д.) и действие, выполняемое над пакетом, если он соответствует всем критериям правила. Действий два: разрешить (permit) и запретить (deny). При разрешении пакет обрабатывается дальше, при запрете – сбрасывается. Правила проверяются последовательно, пока не будет найдено то, которому соответствует пакет. Над пакетом выполняется действие (permit/deny) и дальнейшая проверка правил прекращается. В конце любого ACL неявно находится правило, запрещающее весь трафик. Т.е. используется ограничивающий (restrictive) контроль доступа: запрещено все, что явно не разрешено.

    Синтаксис

    Два способа создания ACL:

    • «Старый» синтаксис. Для идентификации ACL используются номера. За стандартными ACL закреплены номера 1-99 и 1300-1999, за расширенными – 100-199 и 2000-2699.
    • Синтаксис именованных ACL. Для идентификации используется имя, выбранное администратором.

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

    Приведу несколько примеров стандартных ACL:

    access-list 1 permit 192.168.1.0 0.0.0.255
    !
    access-list 2 permit any
    !
    access-list 3 permit host 10.1.1.1
    !
    access-list 4 permit 10.1.1.0 0.0.0.15
    access-list 4 permit 192.168.0.0 0.0.31.255
    

    Первый ACL (1) разрешает трафик из сети 192.168.1.0/24. Второй (2) ACL разрешает весь трафик. Третий (3) разрешает трафик от хоста 10.1.1.1. И последний четвертый, в первой строке разрешает трафик от хостов 10.1.1.0 – 10.1.1.15, во второй строке разрешает трафик из сетей 192.168.0.0 – 192.168.31.0. Обращаю внимание, что здесь приведены примеры четырех разных ACL’а, а не 5 правил одного ACL.

    И несколько расширенных ACL:

    access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 80
    access-list 101 permit udp host 1.1.1.1 eq 500 host 2.2.2.2 eq 555
    access-list 102 permit icmp any any echo
    access-list 103 permit ip any any
    

    ACL 100 разрешает TCP-трафик из сети 10.1.1.0/24 в любые сети, порт назначения 80. Т.е. разрешаем веб-серфинг из локальной сети. ACL 101 разрешает UDP трафик с хоста 1.1.1.1, порт 500 на хост 2.2.2.2, порт 555. ACL 102 разрешает «пинги» откуда угодно, куда угодно. И, наконец, последний ACL 103 разрешает весь трафик.

    Аналогичные стандартные и расширенные ACL’ы, но уже с использованием нового синтаксиса:

    ip access-list standard LIST1
     permit 192.168.1.0 0.0.0.255
    !
    ip access-list standard LIST2
     permit any
    !
    ip access-list standard LIST3
     permit host 10.1.1.1
    !
    ip access-list standard LIST1
     permit 10.1.1.0 0.0.0.15
     permit 192.168.0.0 0.0.31.255
    !
    ip access-list extended LIST100
     permit tcp 10.1.1.0 0.0.0.255 any eq 80
    !
    ip access-list extended LIST101
     permit udp host 1.1.1.1 eq 500 host 2.2.2.2 eq 555
    !
    ip access-list extended LIST102
     permit icmp any any echo
    !
    ip access-list extended LIST103
     permit ip any any
    

    Редактирование ACL стало намного удобнее, начиная я IOS 12.3,. Если вы дадите команду:

    show access-list
    

    Вы увидите список ACL’ов и их содержимое:

    R0(config-ext-nacl)#do sh access-li
    Standard IP access list LIST1
       <b> 10</b> permit 192.168.1.0, wildcard bits 0.0.0.255
       <b> 20</b> permit 10.1.1.0, wildcard bits 0.0.0.15
       <b> 30</b> permit 192.168.0.0, wildcard bits 0.0.31.255
    Standard IP access list LIST2
        10 permit any
    Standard IP access list LIST3
        10 permit 10.1.1.1
    Extended IP access list LIST100
        10 permit tcp 10.1.1.0 0.0.0.255 any eq www
    Extended IP access list LIST101
        10 permit udp host 1.1.1.1 eq isakmp host 2.2.2.2 eq 555
    Extended IP access list LIST102
        10 permit icmp any any echo
    Extended IP access list LIST103
        10 permit ip any any
    

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

    ip access-list standard LIST1
     25 permit …
    

    Причем не играет роли, как вы создавали ACL – с помощью старого синтаксиса или по-новому, просто вместо имени ACL укажите его номер. Добавление и удаление строк выполняется абсолютно аналогично.

    Для удаления строк используется команда no с указанием номера строки:

    ip access-list standard LIST103
     no 25 
    

    Вы можете выполнить перенумерацию строк:

    ip access-list resequence LIST103 10 50
    

    В приведенном выше примере, для ACL с именем LIST103 будет выполнена перенумерация и номер первой строки будет 10, а последующие строки нумеруются с шагом 50. Т.е. 10, 60, 110, 160 …

    И, наконец, после создания ACL его необходимо будет применить в соответствии с вашими целями и задачами. То что, касается фильтрации, то ACL применяется на интерфейсе. При применении надо будет указать направление фильтрации: in (вход) – трафик приходит с провода на интерфейс роутера, out (выход) – трафик с интерфейса уходит на провод. В примере, ACL применяется для фильтрации входящего трафика:

    interface fa0/0
     ip access-group LIST103 in
    

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

    Time-based ACLs


    Начнем с ACLs, в которых вы можете использовать время, как дополнительный критерий, по которому будет фильтроваться или классифицироваться трафик. К примеру, в рабочее время веб-серфинг запрещен, а в обеденное время и после работы – пожалуйста. Что требуется для создания time-based ACL? Все очень просто:

    1. Создать один или несколько «календарей» — временных диапазонов;
    2. Использовать эти «календари» в правилах расширенных ACL.

    Для создания «календаря» используется команда time-range, в которой указывается произвольное имя, присваиваемое календарю. На это имя вы будете впоследствии ссылаться в правилах ваших ACL. В примере я создаю «календарь» с именем WORK_DAYS:

    time-range WORK_DAYS
     absolute start 00:00 01 January 2012 end 23:59 31 December 2012
     periodic weekdays 9:00 to 18:00
     periodic ?
      Friday     Friday
      Monday     Monday
      Saturday   Saturday
      Sunday     Sunday
      Thursday   Thursday
      Tuesday    Tuesday
      Wednesday  Wednesday
      daily      Every day of the week
      weekdays   Monday thru Friday
      weekend    Saturday and Sunday
    

    В режиме конфигурирования «календаря» вы определяете временные диапазоны. Два типа диапазонов:

    • Абсолютный (указываются конкретные даты и время).
    • Периодический (указываются дни недели, рабочие или выходные дни, но без привязки к конкретной дате).

    В приведенном выше примере создаются два временных интервала: абсолютный (определяет время с 00:00 01 Января 2012 года по 23:59 31 декабря 2012 года) и относительный (определяет дни с понедельника по пятницу, с 9:00 по 18:00). Для периодических интервалов, как видите, вы можете использовать названия дней недели, daily – ежедневно, weekdays – рабочие дни, weekend – выходные.
    Для просмотра созданных «календарей» дайте команду show time-tange:

    R0#sh time-range
    time-range entry: WORK_DAYS <b>(active)</b>
       absolute start 00:00 01 January 2012 end 23:59 31 December 2012
    

    Слово active рядом с названием «календаря» говорит о том, что он активен, т.е. время «календаря» соответствует сейчас текущему времени на роутере.

    Теперь давайте используем наш «календарь» в правилах ACL:

    ip access-list extended TIME_BASED_ACL
    permit tcp 10.0.0.0 0.255.255.255 any eq www <b>time-range WORK_DAYS</b>
    permit tcp 10.0.0.0 0.255.255.255 any eq ftp-data <b>time-range ANOTHER_RANGE</b>
    

    Как видите, вы можете использовать разные «календари» для разных правил одного ACL’а. «Календари» вы можете использовать только в расширенных ACL.

    Reflexive ACL


    Отражающие или зеркальные ACL позволяют несколько расширить возможности фильтрации. По сути, они превращают ACL из packet filtering в stateful inspection брандмауэр. Т.е. теперь роутер будет отслеживать состояние сессий, инициированных из внутренней сети компании, и создавать соответствующие возвратные правила.

    image

    Поясню на примере типичной ситуации. Есть внутренняя сеть 192.168.1.0/24. Разрешаем доступ из этой сети в интернет (http) – «зеленый» ACL. Т.е. с помощью этого ACL мы определяем политики выхода из внутренней сети во внешнюю сеть. С помощью второго, «красного» ACL мы защищаем внутреннюю сеть от вторжений извне. Но необходимо разрешить ответы на сессии, инициированные из внутренней сети, поэтому разрешаем возвратный трафик. Вроде бы все логично: разрешили запросы туда, разрешили ответы оттуда. Но при такой конфигурации, мы сильно раскрываем внутреннюю сеть. Любой TCP пакет с 80 порта беспрепятственно попадает во внутреннюю сеть. Добро пожаловать, атакам типа SYN Flood и прочим. Данная проблема легко решается с помощью stateful inspection firewall (CBAC или IOS Firewall), но что делать, если ваша редакция IOS не поддерживает этот функционал? На помощь приходят зеркальные ACL.

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

    image

    Посмотрите пример. Для определенных правил в «зеленом» ACL мы используем параметр reflect и указываем имя временного ACL (в примере, MIRROR), куда будут отражаться правила. В «красном» ACL мы проверяем временный зеркальный ACL: команда evaluate. Можете рассматривать эту команду, как возможность проверить один ACL внутри другого, т.е. команда будет заменена набором правил из временного ACL.

    Пока не открыты сессии из внутренней сети, зеркальный ACL пустой, не содержит никаких правил:

    Extended IP access list EXTERNAL
        10 evaluate MIRROR
        20 deny ip any any log
    Extended IP access list INTERNAL
        10 permit ip any any reflect MIRROR (2 matches)
    Reflexive IP access list MIRROR
    

    Но как только будут открываться сессии, зеркальный ACL начнет заполняться:

    R1#sh access-li
    Extended IP access list EXTERNAL
        10 evaluate MIRROR
        20 deny ip any any log (5 matches)
    Extended IP access list INTERNAL
        10 permit ip any any reflect MIRROR (36 matches)
    Reflexive IP access list MIRROR
         permit icmp host 2.2.2.2 host 192.168.1.1  (19 matches) (time left 289)
         permit tcp host 192.168.2.1 eq telnet host 192.168.1.1 eq 62609 (30 matches) (time left 286)
         permit ospf host 224.0.0.5  host 192.168.1.1  (6 matches) (time left 297)
    


    В примере из внутренней сети с адреса 192.168.1.1 был запущен пинг на адрес 2.2.2.2, затем открыто telnet-соединение с внутреннего адреса 192.168.1.1 на внешний адрес 192.168.2.1. На примере telnet-соединения хорошо видна выполненная последовательность действий:

    1. Внутренний хост инициирует соединение с адреса 192.168.1.1 и случайно выбранного порта 62609 на адрес внешнего хоста 192.168.2.1, порт 23 (telnet).
    2. Пакеты проверяются INTERNAL ACL, разрешены строкой: 10 permit ip any any reflect MIRROR
    3. Отражаются в MIRROR ACL: permit tcp host 192.168.2.1 eq telnet host 192.168.1.1 eq 62609
    4. Ответы извне проверяются EXTERNAL ACL, содержащим ссылку на MIRROR ACL: evaluate MIRROR.

    Возвратный трафик в итоге разрешен. Если бы произошла попытка отрыть любое соединение до внутренней сети извне, то оно было бы запрещено: deny ip any any log.

    В общем, легким движением руки ACL почти превратился в stateful inspection firewall.

    Dynamic (Lock-and-Key) ACLs


    Следующая категория ACL – динамические. В основном, эти ACL используются для удаленных подключений к сети компании, но можете и использовать их тогда, когда подключение к различным ресурсам требует предварительной аутентификации. Представьте, что администраторам требуется постоянные подключения к сети компании, но подключаться они будут из разных мест, с разных IP-адресов. Идея динамических ACL, состоит в том, что человек должен сначала пройти аутентификацию и только в случае успеха будет применен ACL, разрешающий доступ к ресурсам сети. Алгоритм следующий:

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

    Что требуется для конфигурации динамических ACL:

    • Создать расширенный ACL, разрешающий telnet или SSH подключения к роутеру. Эти протоколы будут использоваться для подключения к роутеру.
    • Определить параметры аутентификации. Поддерживается локальная аутентификация, AAA, пароль на vty портах.
    • Настроить параметры динамического ACL.

    Давайте все разберем на следующем примере:

    image

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

    ip access-list extended TELNET-IN						
     permit tcp any host 1.1.1.1 eq telnet										(1)
     dynamic DYNAMIC-ACL-NAME permit tcp any host 192.168.1.1 eq www		(4)
     deny ip any any
    !
    int s0/0
     description CONNECTED TO EXTERNAL NETWORK
     ip address 1.1.1.1 255.255.255.0
     ip access-group TELNET-IN in
    

    Следующим шагом настраиваем аутентификацию. Я буду использовать локальную аутентификацию, поэтому создаю пользователя root и включаю локальную аутентификацию на vty портах:

    username root secret USERS_PASSWORD						(2)
    !
    line vty 0 4
     login local													(2)
     autocommand access-enable host timeout 10					(3)	
    

    Команда autocommand access-enable активирует аутентификацию и включает записи динамического ACL. Параметр host является опциональным. При его использовании any в качестве IP-адреса источника в динамическом ACL будут заменены на адрес, с которого пользователь подключается. Параметр timeout определяет период бездействия в минутах для данной сессии, по умолчанию — бесконечен.

    Как будет происходить процесс получения доступа в приведенном примере:

    • Пользователь открывает telnet подключение к роутеру на адрес 1.1.1.1. Разрешено правилом расширенного ACL (1).
    • Фаза локальной аутентификации (2).
    • В случае успешной аутентификации, автоматически выполняется команда access-enable (3), активирующая правила динамического ACL (4). Telnet соединение закрывается.
    • Пользователь получает доступ в соответствии с правилами динамического ACL.


    Заключение


    Как видите ACL в Cisco IOS обладают очень интересными возможностями, учитывая, что это базовый функционал фактически любого IOS. Очень многое конечно осталось за кадром: ACL и QoS, rate limits. И тем более, такие темы как CBAC, Zone-based Firewall и д.р. Спасибо за прочтение.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 33

      0
      Возможно я не прав, ибо с цисками только начинаю общаться, но точно ли высказывание «во второй строке разрешает трафик из сетей 192.168.1.0 – 192.168.31.0. » В аксес листе же от 192.168.0.0 или так и должно быть?
        0
        Очевидно, что в статье опечатка.
          0
          Опечатался, конечно 0.0 — 31.0, спасибо, обновил статью.
        0
        А вообще, очень познавательно. Спасибо за статью. Странно, что минусуют. Для меня, как для начинающего цисковода и пользователя ACL это интересно.
        0
        Идея динамический ACLов полезна, чтобы добавить второй фактор авторизации без VPN-а, например для удаленный пользователей которые ходят в терминал. Но вот реализация что-то мне не очень нравится. У DFL-ов она сделана отдельным специальным способом (то есть даже если там ввести админские логин и пароль, то конфигурировать роутер не даст), через http(s), и позволяет применять разные динамические политики в зависимости от того, кто авторизовался. Объяснить простому пользователю про телнет, да еще и выставлять интерфейс конфигурации роутера на всеобщее обозрение — плохая идея.
        Возможно конечно такое и на циске можно сделать, надо порыться. Но в том виде в котором динамические ACL-ы приведены в статье, они сильно менее полезны чем таковые в реализации NetDefend от (прости господи) D-Link-а.
          0
          a) Речь идет про базовый функционал
          b) Можно использовать для подключения ssh (плюс подключаться на альтернативый порт). Интерфейс не совсем выставляется.
          c) Для аутентификации (и последующей авторизации) можно использовать внешние TACACS или RADIUS.
            0
            Да то все понятно. Для таких целей вообще хорошо бы VPN использовать и не париться.
            Но согласитесь, авторизация по http(s) в два клика все равно всяко удобнее, чем RADIUS, особенно если вам нужно всего пяток таких пользователей пустить.

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

              В IOS изначально нет никаких пользователей.
                0
                Извиняюсь за резкость. Идея: человек подключается, аутентифицируется – потом доступ к ресурсу. Не к роутеру, а сквозь него. Т.е. роутер выступает посредником между пользователем и ресурсом. Про доступ к роутеру речь вообще не идет.
                  0
                  Смысл поста понятен более чем полностью. Вопрос не в этом.
                  Для того, чтобы авторизоваться, пользователь должен подключится к роутеру по telnet/ssh. то есть попасть в стандартный vty.

                  Когда пользователь подключается с логином и паролем (неважно каким) что он видит? Стандартное приглашение на ввод, типа ciscoGATE>?
                  Если да, то введя логин и пароль пользователя с 15 уровнем привилегий, я спокойно смогу сказать en, потом conf t и конфигурировать роутер.
                  Если при подключении так маршрутизатор активирует ACL, и сразу отключает сессию, то как тогда войти в локальный vty для конфигурации устройства (иногда есть потребность иметь такую возможность)?
                    0
                    Да, видит приглашение, но после успешной аутентификации Autocommand срабатывает автоматически и соединение закрывается, затем применяется ACL. Роли не играет, кто вы: аутентификация > закрыть подключение > применить динамический ACL. Доступа к роутеру нет.
                  0
                  Но пользователей и ssh доступ иногда некоторые извращенцы еще используют и для конфигурирования устройства. :)
                    0
                    Это уже сложнее :) Постараюсь сделать пост про router security, т.е. как сам роутер защищать.
                    Можно например профили аутентификации сделать, разделить тех кто «сквозь» и тех, кто на роутер.
                      0
                      Почему извращенцы? :)
                        0
                        Шелдон? :)
                          0
                          Сарказм после сарказма?)
                            0
                            Святое дело.
                              0
                              У меня чуть мировоззрение не повернулось.
                              Видимо 7 часов в JunOS убило мое «сарказмопонимание» :)
                      0
                      А в качестве сервера аутентификации можно использовать AD (при наличии Cisco ACS) или любой RADIUS.
                0
                Хехе, похоже на укороченную скомпонованную статью из официального руководства cisco к CCNA. Готовитесь или только что сдали? ;)
                  0
                  Посмотрел на профиль. Ок. Вопрос отпадает.
                    0
                    Вы правы, недавно сдал ) теперь могу читать курсы ))
                  0
                  Кроме log есть еще log-input, когда асл один на многих интерфейсах, что бы понимать, на каком интерфейсе правило сработало. Еще можно метить произвольным текстом

                  WORD User defined cookie (max of 64 char)

                  Облегчает парсинг, что бы регекспом не выбирать по сложному условию на коллекторе логов (а правило может быть достаточно широким), можно искать по ключевому слову, которым метится строка правила.
                    0
                    Reflexive:
                    + почти даром
                    — формируется огромный ACL: представьте маленькую контору с 10-ю работниками
                      0
                      Вы точно мне ответили? Я, если честно, не понял о чем речь. Я о удобных фенечках логгирования, вы о рефлексив.
                    0
                    Достаточно хорший обзор. Сегодня только персматривал главу по acl в книге Юсуфа Баиджи, все примерно то же — так что весьма хорошо охвачено. Established еще стоит упомянуть.
                    Cbac и inspect на самом деле гораздо интереснее — без них роутер в общем то совершенно stateless, и довольно дыряв. Reflexive acl делают похожую работу, но совершенно на другом уровне — они не будут проверять принадлежность пакета к сессии, это совсем не то же самое что statefull firewall. Опять же они удваивают работу. Established вообще только на SYN смотрят.
                    Кто сталкивался с фаирволами может ожидать от IOS acl примерно такой же функциональности, но они stateless сами по себе. Фаирволы же как правило stateful на 3-4 уровне по умолчанию. Inspect сбивает с толку тем, что он похож и по сути и есть level 7 фаирвол, но для полноценного L3/L4 он тоже фактически необходим.
                      0
                      CBAC естественно лучше. Но требует лицензирования.
                        0
                        В одной очень не маленькой сети одного очень не маленького холдинга на inspect так обожглись, что больше не страдают этой фигней. Оно красиво… в теории. Раз прикладной протокол «порвало» этим инспектом, два, три… на четвертый это людям надоело.
                          0
                          Обожглись на фирволе и решили что без него лучше? :) я вам так скажу, из роутера фаирвол вообще паршивый. Для бранчей годится, но не больше. Без inspect это вообще не фаирвол, а роутер с мерлевой повязкой на входе который может дропать отдельные пакеты вслепую. Прикладной уровень надо осторожно трогать, там все гораздо сложнее и гораздо менее формализовано, на то он и прикладной. Тут речь больше о stateful фаирволах 3-4 уровня где cbac делает из роутера маленький универсальный и более-менее надежный фаирвольчик.
                          Smart defense чекпоинтовский тоже лажает, хотя он в 100 раз злее и умнее того что может простой роутер.
                            0
                            Не надо самому приписывать собеседнику нечто, а потом это высмеивать. Обожглись не на файрволе, а на попытке «сделать из роутера маленький универсальный файрвольчик». Для этого есть другие решения. Тоже, кстать, не идеальные. Косячит в той или иной степени все, что пытается лезть в ent-to-end протоколы, будь это хоть L7, хоть L4. Опорному роутеру это делать вообще ни к чему, если только по бедности. И на счет марлевой повязки — ерунда. Надо разделять задачи. L3 ACL прекрасно справляются со своими. А то, что льется через открытые в них «дыры» все сложней и сложней подвергать нормальной инспекции. Тренд корпоративный последнего времени — размытие периметра, везде ssl тунели и подобное (+ необходимость учитывать контекст более сложный, чем время суток), защита смещается на уровень хоста, чем бы он не являлся, обычным компом или мобильным девайсом. Что не отменяет необходимость классических L3 ACL как первого рубежа защиты.

                            net-geek.org/dbg/2008/08/dont-fuck-with-tcp.html
                              0
                              Господа, у Cisco есть ASA. Хотите нормальный fw, берите ее. Роутер для начальной базовой фильтрации. Сразу и грубо отсекаем все ненужное.

                              Не стоит это сравнивать со специализированными security-решениями.

                      Only users with full accounts can post comments. Log in, please.