permit any что это
Что попадает в deny ip any any?
Большинство реализаций списков доступа подразумевает под собой поведение «всё что не разрешено, то запрещено». Разумный подход, с учётом того, что при проектировании мы заранее ожидаем тот или иной тип трафика в определённом направлении: если у нас подключен абонент или пиринговый партнёр, значит данных с других IP на этом интерфейсе быть не должно, а если у нас подключен Интернет, откуда там взяться частным адресам? А может зря всё это? Может и нет никакого паразитного трафика и безусловный запрет в ACL это только перевод ресурсов. Ведь клиентам оператор сам выдаёт адреса, а пиринговые партнёры и апстрим провайдеры братья связисты, которые должны понимать всю сложность и щекотливость ситуации. К сожалению, это совсем не так.
Участники круглого стола посвящённому DDoS, прошедшего на YaC2013 очень сетовали на то, что при всех существующих рекомендациях никто не старается заниматься безопасностью своих сетей. То есть начинать надо в первую очередь с себя (с операторов связи), как минимум бороться с IP-спуфингом.
От чего же защищает deny ip any any можно посмотреть далее, просто примеры из журналов мониторинга.
Наша сеть это провайдер с абонентами, пиринг партнёрами и аплинками:
Сначала первый интерфейс (один из) int1 в сторону абонентов, и простой список доступа на вход:
Разрешили ICMP, уже установленные соединения и трафик только из подключенной части абонентской сети. Смотрим что попалось.
Deny any со стороны абонентов
1. Множество публичных адресов источника, и один публичный адрес назначения. Никакие из адресов нам не принадлежат:
В данном случае адрес назначения входит в блок принадлежащий министерству обороны Великобритании. Казалось бы, вот тут проявление сетевой солидарности — с миру по нитке и не надо никаких анти-DDoS средств. Но на самом деле это всего лишь вышедший из под контроля Hamachi со своими нелегальными глобальными IP адресами, когда трафик идёт не через туннель, а через общее маршрутизируемое пространство, то есть Великобритании, таки, достаётся.
2. Источник – серверы имён, в основном реальные:
В адресах назначения нет адресов принадлежащих нашей сети. Но так как серверы реальные, то можно предположить, что в каком-то случае может раскрываться внутренняя структура адресации, подключенного в данный момент или ранее подключенного у абонента провайдера.
3. Множество публичных адресов источника (иногда адреса из абонентской сети) и один адрес назначения в абонентской сети:
Интересно, что источником данного трафика является узел, именно с тем адресом, который указан в качестве назначения.
4. Близкое по форме с предыдущим вариантом, но в качестве адреса назначения выступает частный адрес не принадлежащий ни одному из известному узлу в сети:
Здесь также как и в предыдущем случае, узел источник трафика имеет на интерфейсе одним из адресов указанный в качестве адреса назначения. Вот эти два случая остались для меня загадкой — кто, как и зачем?
5. Один частный адрес источника и множество публичных адресов назначения (иногда адреса из абонентской сети):
Наверное самое объяснимое. В следствии того что адрес постоянен, то он либо настроен вторым на основном интерфейсе, либо на другом устройстве в сети абонента, или используется одним из приложений.
Вышеперечисленные варианты встречаются во многих местах являются самыми массовыми, остальное лишь единичные случаи.
6. Источник — публичный адрес сети провайдера:
7. Назначение — публичный адрес сети провайдера:
Данные случаи стоит пояснить, поскольку все абоненты находятся за NAT и имеют частную адресацию, появление в сети в качестве источника публичного адреса провайдера, ровно как и адреса назначения это совсем не обычно.
8. «Странные» даже в этом контексте, адреса и протоколы:
Большинство из того что удалось исследовать и как-то объяснить не относится к каким-то преднамеренным или злонамеренным действиям, часто это ошибки конфигурации, в основном автоматической, при подключении второго провайдера (обычно 3G модемов), использовании различных туннельных программ (как Hamachi, в первом случае) или P2P клиентов.
Deny any со стороны пиринг партнёра
Стоит обратить внимание на соотношение количества совпадений deny и permit правил по отношению к предыдущему ACL. Непонятных вещей происходит меньше, примерно, 1 deny на 200000 permit, в предыдущем примере это отношение 1 к 5000, что говорит нам о наличии контролируемой сетевой структуре, которая присутствует у нашего партнёра и которая не присутствует у наших абонентов. Но и в этом случае всё равно что-то просачивается.
1. Правила 50,60,70 — доступ с частных адресов не принадлежащих ни нам, ни пиринг партнёру, к нашим публичным адресам:
Событий не много, но можно предположить что данный случай чем-то перекликается с 5 вариантом в предыдущем разделе.
2. А вот deny ip any any показало, внезапно, ожидаемые события — попытки доступа к интерфейсному адресу 192.0.2.2 с публичных адресов не принадлежащих пиринг партнёру:
Адрес является глобально маршрутизируемым, а в желающих испытать на прочность безопасность сети недостатка не было никогда. Справедливости ради, надо отметить что подобные случаи происходят и во внутренней сети, но они отсекаются другим механизмом защиты, поэтому этого не было заметно в примерах выше.
Deny any со стороны Интернета
Сразу обращает на себя внимание большее разнообразие исходных адресов в том числе и 0.0.0.0 и 255.255.255.255. В остальном же имеем почти тоже самое что и с пиринг партнёром.
1. Частный адрес из публично маршрутизируемого пространства на публичный адрес провайдера:
2. Тоже что и первый случай, но в качестве источника публичный адрес из нашей сети:
3. Доступ к стыковочному адресу маршрутизатора, тоже что и в случае с пиринг партнёром:
В этот раз порты SSH и SIP.
Вот пожалуй и всё. Коренное отличие работы с внешними подключениями это отсутствие попыток доступа не к нашим адресам. Все пакеты приходили куда надо, правда не всегда с тех адресов которые были бы уместны в данной ситуации. Также, в относительном измерении, из внешних сетей откровенной ерунды прилетает сильно меньше, чем от собственных абонентов. То есть, наличие в сети администратора решает почти все проблемы.
Конечно не являясь специалистом сетевой безопасности, я не всегда понимаю что означает та или иная строчка попавшая под запрет, но вроде ничего откровенно злонамеренного не попалось, как я уже говорил выше в основном ошибки конфигурации. В любом случае — будьте бдительны, защищайтесь сами от внешних, а в первую очередь от внутренних угроз, чтобы всем нам было спокойнее.
ACL: списки контроля доступа в Cisco IOS
Сегодня я расскажу вам о том, как отфильтровать трафик в сети с помощью списков контроля доступа. Рассмотрим как они работают соответственно, что собой представляют, для чего предназначены. Позже я покажу как они настраиваются в Cisco IOS и выложу архив с лабораторными работами для закрепления ваших знаний.
Введение
ACL (Access Control List) — это набор текстовых выражений, которые что-то разрешают, либо что-то запрещают. Обычно ACL разрешает или запрещает IP-пакеты, но помимо всего прочего он может заглядывать внутрь IP-пакета, просматривать тип пакета, TCP и UDP порты. Также ACL существует для различных сетевых протоколов (IP, IPX, AppleTalk и так далее). В основном применение списков доступа рассматривают с точки зрения пакетной фильтрации, то есть пакетная фильтрация необходима в тех ситуациях, когда у вас стоит оборудование на границе Интернет и вашей частной сети и нужно отфильтровать ненужный трафик.
Вы размещаете ACL на входящем направлении и блокируете избыточные виды трафика.
Теория
Сам же ACL представляет собой набор текстовых выражений, в которых написано permit (разрешить) либо deny (запретить), и обработка ведется строго в том порядке в котором заданы выражения. Соответственно когда пакет попадает на интерфейс он проверяется на первое условие, если первое условие совпадает с пакетом, дальнейшая его обработка прекращается. Пакет либо перейдет дальше, либо уничтожится.
Ещё раз, если пакет совпал с условием, дальше он не обрабатывается. Если первое условие не совпало, идет обработка второго условия, если оно совпало, обработка прекращается, если нет, идет обработка третьего условия и так дальше пока не проверятся все условия, если никакое из условий не совпадает, пакет просто уничтожается. Помните, в каждом конце списка стоит неявный deny any (запретить весь трафик). Будьте очень внимательны с этими правилами, которые я выделил, потому что очень часто происходят ошибки при конфигурации.
Виды ACL
Динамический (Dynamic ACL)
Позволяет сделать следующее, например у вас есть маршрутизатор, который подключен к какому-то серверу и нам нужно закрыть доступ к нему из внешнего мира, но в тоже время есть несколько человек, которые могут подключаться к серверу.
Мы настраиваем динамический список доступа, прикрепляем его на входящем направлении, а дальше людям, которым нужно подключиться, подключаться через Telnet к данному устройству, в результате динамический ACL открывает проход к серверу, и уже человек может зайти скажем через HTTP попасть на сервер. По умолчанию через 10 минут этот проход закрывается и пользователь вынужден ещё раз выполнить Telnet чтобы подключиться к устройству.
Рефлексивный (Reflexive ACL)
Здесь ситуация немножко отличается, когда узел в локальной сети отправляет TCP запрос в Интернет, у нас должен быть открытый проход, чтобы пришел TCP ответ для установки соединения. Если прохода не будет — мы не сможем установить соединение, и вот этим проходом могут воспользоваться злоумышленники, например проникнуть в сеть. Рефлексивные ACL работают таким образом, блокируется полностью доступ (deny any) но формируется ещё один специальный ACL, который может читать параметры пользовательских сессий, которые сгенерированны из локальной сети и для них открывать проход в deny any, в результате получается что из Интернета не смогут установить соединение. А на сессии сгенерированны из локальной сети будут приходить ответы.
Ограничение по времени (Time-based ACL)
Обычный ACL, но с ограничением по времени, вы можете ввести специальное расписание, которое активирует ту или иную запись списка доступа. И сделать такой фокус, например пишем список доступа, в котором запрещаем HTTP-доступ в течении рабочего дня и вешаем его на интерфейс маршрутизатора, то есть, сотрудники предприятия пришли на работу, им закрывается HTTP-доступ, рабочий день закончился, HTTP-доступ открывается,
пожалуйста, если хотите — сидите в Интернете.
Настройка
Стандартный список доступа
Расширенный список доступа
Прикрепляем к интерфейсу
Именованные списки доступа
Ограничение доступа к маршрутизатору
R(config)#line vty 0 4 — переходим в режим настройки виртуальных линий.
R(config-line)#password
R(config-line)#login
R(config-line)#access-class 21 in — настраиваем логин и пароль, а также закрепляем список доступа с разрешенными IP-адресами.
Динамические списки доступа
R3(config)#username Student password 0 cisco — создаем пользователей для подключения через Telnet.
R3(config)#access-list 101 permit tcp any host 10.2.2.2 eq telnet
R3(config)#access-list 101 dynamic testlist timeout 15 permit ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255 — разрешаем подключаться к серверу по Telnet всем узлам.
R3(config)#interface serial 0/0/1
R3(config-if)#ip access-group 101 in — закрепляем 101 ACL за интерфейсом в входящем направлении.
R3(config)#line vty 0 4
R3(config-line)#login local
R3(config-line)#autocommand access-enable host timeout 5 — как только пользователь аутентифицируеться, сеть 192.168.30.0 будет доступна, через 5 минут бездействия сеанс закроется.
Рефлексивные списки доступа
R2(config)#ip access-list extended OUTBOUNDFILTERS
R2(config-ext-nacl)#permit tcp 192.168.0.0 0.0.255.255 any reflect TCPTRAFFIC
R2(config-ext-nacl)#permit icmp 192.168.0.0 0.0.255.255 any reflect ICMPTRAFFIC — заставляем маршрутизатор отслеживать трафик, который инициировался изнутри.
R2(config)#ip access-list extended INBOUNDFILTERS
R2(config-ext-nacl)#evaluate TCPTRAFFIC
R2(config-ext-nacl)#evaluate ICMPTRAFFIC — создаем входящую политику, которая требует, чтобы маршрутизатор проверял входящий трафик, чтобы видеть инициировался ли изнутри и связываем TCPTRAFFIC к INBOUNDFILTERS.
R2(config)#interface serial 0/1/0
R2(config-if)#ip access-group INBOUNDFILTERS in
R2(config-if)#ip access-group OUTBOUNDFILTERS out — применяем входящий и исходящий ACL на интерфейс.
Ограничение по времени
R1(config)#time-range EVERYOTHERDAY
R1(config-time-range)#periodic Monday Wednesday Friday 8:00 to 17:00 — создаем список времени, в котором добавляем дни недели и время.
R1(config)#access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq telnet time-range EVERYOTHERDAY — применяем time-range к ACL.
R1(config)#interface s0/0/0
R1(config-if)#ip access-group 101 out — закрепляем ACL за интерфейсом.
Поиск проблем
R#show access-lists
R#show access-lists — смотрим все списки доступа на маршрутизаторе.
Пример
Router#show access-lists
Extended IP access list nick
permit ip host 172.168.1.1 host 10.0.0.5
deny ip any any (16 match(es))
Standard IP access list nick5
permit 172.16.0.0 0.0.255.255
Мы видим что у нас есть два ACL (стандартный и расширенный) под названиями nick и nick5. Первый список разрешает хосту 172.16.1.1 обращаться по IP (это значит что разрешены все протоколы работающие поверх IP) к хосту 10.0.0.5. Весь остальной трафик запрещен показывает команда deny ip any any. Рядом с этим условием в нашем примере пишет (16 match(es)). Это показывает что 16 пакетов попали под это условие.
Второй ACL разрешает проходить трафик от любого источника в сети 172.16.0.0/16.
Практика
Я собрал лабораторные работы для Packet Tracer с 5 главы курса CCNA 4 по теме ACL. Если у вас есть желание закрепить знания на практике, пожалуйста — ссылка, зеркало — FTP. Размер — 865.14 KB.
Cisco IOS ACLs
В этой статье я бы хотел поговорить про возможности Cisco IOS Access Control Lists (ACLs). Тема многим из вас должна быть знакомой, поэтому мне хочется обобщить информацию по разным типам ACLs. Я кратко пробегусь по основам, а затем поговорим про специальные типы ACLs: time-based (на основе времени), reflexive (отражающие), dynamic (динамические). Итак, начнем…
Основы: Вспомнить все…
Быстренько пробежимся по основным понятиям, синтаксису, чтобы потом проще можно было перейти к более интересным вещам. ACL’ы на роутерах Cisco позволяют решать две группы задач:
ACL’ы можно отнести к брандмауэрам пакетной фильтрации (packet filtering firewall). Т.е. они позволяют выполнять фильтрацию пакетов по пяти параметрам:
ACL состоит из набора правил. В каждом правиле вы определяете параметры фильтрации (адреса, порты и т.д.) и действие, выполняемое над пакетом, если он соответствует всем критериям правила. Действий два: разрешить (permit) и запретить (deny). При разрешении пакет обрабатывается дальше, при запрете – сбрасывается. Правила проверяются последовательно, пока не будет найдено то, которому соответствует пакет. Над пакетом выполняется действие (permit/deny) и дальнейшая проверка правил прекращается. В конце любого ACL неявно находится правило, запрещающее весь трафик. Т.е. используется ограничивающий (restrictive) контроль доступа: запрещено все, что явно не разрешено.
Синтаксис
Два способа создания ACL:
Приведу несколько примеров стандартных ACL:
Первый 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:
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’ы, но уже с использованием нового синтаксиса:
Редактирование ACL стало намного удобнее, начиная я IOS 12.3,. Если вы дадите команду:
Вы увидите список ACL’ов и их содержимое:
Обратите внимание, что строки ACL пронумерованы. Для добавления новых строк в определенную позицию, войдите в режим редактирования нужного ACL и перед вводом нового правила укажите номер строки:
Причем не играет роли, как вы создавали ACL – с помощью старого синтаксиса или по-новому, просто вместо имени ACL укажите его номер. Добавление и удаление строк выполняется абсолютно аналогично.
Для удаления строк используется команда no с указанием номера строки:
Вы можете выполнить перенумерацию строк:
В приведенном выше примере, для ACL с именем LIST103 будет выполнена перенумерация и номер первой строки будет 10, а последующие строки нумеруются с шагом 50. Т.е. 10, 60, 110, 160 …
И, наконец, после создания ACL его необходимо будет применить в соответствии с вашими целями и задачами. То что, касается фильтрации, то ACL применяется на интерфейсе. При применении надо будет указать направление фильтрации: in (вход) – трафик приходит с провода на интерфейс роутера, out (выход) – трафик с интерфейса уходит на провод. В примере, ACL применяется для фильтрации входящего трафика:
Все это, я надеюсь, известные вещи. Если есть какие-то вопросы, задавайте, я постараюсь ответить. Если вопросов наберется много, то можно будет сделать отдельный пост. Теперь давайте посмотрим на дополнительные возможности, которыми обладают ACL на роутерах Cisco.
Time-based ACLs
Начнем с ACLs, в которых вы можете использовать время, как дополнительный критерий, по которому будет фильтроваться или классифицироваться трафик. К примеру, в рабочее время веб-серфинг запрещен, а в обеденное время и после работы – пожалуйста. Что требуется для создания time-based ACL? Все очень просто:
В режиме конфигурирования «календаря» вы определяете временные диапазоны. Два типа диапазонов:
Слово active рядом с названием «календаря» говорит о том, что он активен, т.е. время «календаря» соответствует сейчас текущему времени на роутере.
Теперь давайте используем наш «календарь» в правилах ACL:
Как видите, вы можете использовать разные «календари» для разных правил одного ACL’а. «Календари» вы можете использовать только в расширенных ACL.
Reflexive ACL
Отражающие или зеркальные ACL позволяют несколько расширить возможности фильтрации. По сути, они превращают ACL из packet filtering в stateful inspection брандмауэр. Т.е. теперь роутер будет отслеживать состояние сессий, инициированных из внутренней сети компании, и создавать соответствующие возвратные правила.
Поясню на примере типичной ситуации. Есть внутренняя сеть 192.168.1.0/24. Разрешаем доступ из этой сети в интернет (http) – «зеленый» ACL. Т.е. с помощью этого ACL мы определяем политики выхода из внутренней сети во внешнюю сеть. С помощью второго, «красного» ACL мы защищаем внутреннюю сеть от вторжений извне. Но необходимо разрешить ответы на сессии, инициированные из внутренней сети, поэтому разрешаем возвратный трафик. Вроде бы все логично: разрешили запросы туда, разрешили ответы оттуда. Но при такой конфигурации, мы сильно раскрываем внутреннюю сеть. Любой TCP пакет с 80 порта беспрепятственно попадает во внутреннюю сеть. Добро пожаловать, атакам типа SYN Flood и прочим. Данная проблема легко решается с помощью stateful inspection firewall (CBAC или IOS Firewall), но что делать, если ваша редакция IOS не поддерживает этот функционал? На помощь приходят зеркальные ACL.
Идея состоит в том, что теперь из одного ACL (обычно, «зеленый» — внутренний), пакеты прошедшие проверку будет зеркалироваться или отражаться в правила специального временного ACL, который в свою очередь будет проверяться внешним («красным») ACL.
Посмотрите пример. Для определенных правил в «зеленом» ACL мы используем параметр reflect и указываем имя временного ACL (в примере, MIRROR), куда будут отражаться правила. В «красном» ACL мы проверяем временный зеркальный ACL: команда evaluate. Можете рассматривать эту команду, как возможность проверить один ACL внутри другого, т.е. команда будет заменена набором правил из временного ACL.
Пока не открыты сессии из внутренней сети, зеркальный ACL пустой, не содержит никаких правил:
Но как только будут открываться сессии, зеркальный ACL начнет заполняться:
В примере из внутренней сети с адреса 192.168.1.1 был запущен пинг на адрес 2.2.2.2, затем открыто telnet-соединение с внутреннего адреса 192.168.1.1 на внешний адрес 192.168.2.1. На примере telnet-соединения хорошо видна выполненная последовательность действий:
В общем, легким движением руки ACL почти превратился в stateful inspection firewall.
Dynamic (Lock-and-Key) ACLs
Следующая категория ACL – динамические. В основном, эти ACL используются для удаленных подключений к сети компании, но можете и использовать их тогда, когда подключение к различным ресурсам требует предварительной аутентификации. Представьте, что администраторам требуется постоянные подключения к сети компании, но подключаться они будут из разных мест, с разных IP-адресов. Идея динамических ACL, состоит в том, что человек должен сначала пройти аутентификацию и только в случае успеха будет применен ACL, разрешающий доступ к ресурсам сети. Алгоритм следующий:
Что требуется для конфигурации динамических ACL:
Пользователю требуется подключение к серверу 192.168.1.1 на порт 80 во внутренней сети. Адреса, с которых будет происходить подключение, нам не известны. Первым делом, создаем расширенный ACL, разрешающий telnet подключения к роутеру (адрес 1.1.1.1) и содержащий записи динамического ACL, затем применяем его на нужный интерфейс:
Следующим шагом настраиваем аутентификацию. Я буду использовать локальную аутентификацию, поэтому создаю пользователя root и включаю локальную аутентификацию на vty портах:
Команда autocommand access-enable активирует аутентификацию и включает записи динамического ACL. Параметр host является опциональным. При его использовании any в качестве IP-адреса источника в динамическом ACL будут заменены на адрес, с которого пользователь подключается. Параметр timeout определяет период бездействия в минутах для данной сессии, по умолчанию — бесконечен.
Как будет происходить процесс получения доступа в приведенном примере:
Списки управления транзитным доступом: фильтрация граничного уровня
Параметры загрузки
Содержание
Введение
Данный документ содержит указания и рекомендуемые методы развертывания для фильтрации транзитного и граничного трафика на точках входа в сеть. Списки управления транзитным доступом (ACL) используются для увеличения безопасности сети, разрешая только требуемый трафик в сети.
Фильтры передачи
Обычная настройка
В большинстве граничных сетевых сред, таких как точки выхода в корпоративные Интернет-сети, фильтрация входа должна использоваться для перемещения трафика от незарегистрированных пользователей на границу сети. В некоторых развертываниях поставщиков услуг такая форма фильтрации трафика граничного уровня или транзитного трафика также может эффективно использоваться для ограничения входящего и исходящего транзитного трафика с помощью специально разрешенных протоколов. Основной темой этого документа является модель развертывания сети предприятия.
На рисунке изображена схема типичного Интернет-соединения предприятия. Два граничных маршрутизатора – IR1 и IR2 – обеспечивают прямой доступ к Интернету. Помимо этих маршрутизаторов, два брандмауэра (на этой схеме Cisco PIX) обеспечивают проверку трафика «потоком» и доступ как к внутренней сети, так и к демилитаризованной зоне (DMZ). DMZ включает в себя внешние услуги, такие как DNS и Интернет; это единственная сеть, доступная непосредственно при коллективном доступе в Интернет. Прямой Интернет-доступ к внутренней сети должен отсутствовать, в то время как для исходящего трафика внутренней сети должна быть возможность выхода на Интернет-сайты.
Граничные маршрутизаторы должны быть настроены таким образом, чтобы обеспечивать первый уровень безопасности с помощью списков ACL для входящего трафика. Списки ACL допускают в DMZ только специально разрешенный трафик, а также открывают пользователям внутренней сети, имеющим выход в Интернет, доступ к ответному трафику. Весь незарегистрированный трафик должен быть отправлен во входящие интерфейсы.
Разделы списков ACL для транзитного трафика
Как правило список управления транзитным доступом состоит из четырех разделов.
Специальный адрес и анти-спуфинговые записи, которые запрещают незаконным источникам и пакетам с адресами отправителей, принадлежащими вашей сети, доступ в сеть с внешнего источника.
Примечание. RFC 1918 
определяет зарезервированное адресное пространство, которому не могут принадлежать адреса источников в Интернете. RFC 3330 определяет адреса для специального пользования, которым может потребоваться фильтрация. RFC 2827 предоставляет анти-спуфинговые рекомендации.
Четко определенный ответный трафик для внутреннего подключения к Интернету
Четко определенный внешний трафик, предназначенный для защиты внутренних адресов
Явный оператор deny
Примечание. Кроме этого, все списки ACL содержат неявный оператор deny, Cisco рекомендует использовать явный оператор deny, например, deny ip any any. На большинстве платформ такие операторы выполняют расчет числа запрещенных пакетов, которые могут быть отображены с помощью команды show access-list.
Создание списка ACL для транзитного трафика
Первым этапом в создании списка ACL для транзитного трафика является определение протоколов, требуемых в пределах ваших сетей. Кроме того, каждый узел имеет специфические требования, которые широко применяются и подразумевают использование разрешенных протоколов и приложений. Например, если сегмент DMZ обеспечивает связь с общедоступным веб-сервером, требуется TCP из Интернета на адрес(а) сервера DMZ в порт 80. Таким же образом, при внутреннем соединении с Интернетом требуется, чтобы ACL разрешил установленный ответный график TCP, имеющий установленный бит подтверждения (ACK).
Определение требуемых протоколов
Разработка данного списка протоколов может быть весьма сложной задачей, но существует ряд методик для определения требуемого трафика.
Просмотрите настройки локальной политики безопасности/стратегии обслуживания.
Политика локальных сетевых узлов должна помогать в предоставлении базы разрешенных и запрещенных служб.
Проведите проверку конфигурации брандмауэра.
Текущие конфигурации брандмаура должны содержать явный оператор permit для разрешенных служб. В большинстве случаев возможно преобразовывать эти конфигурации в формат списка ACL и использовать их для создания большого числа записей ACL.
Примечание. Как правило, брандмауэр с контролем состояния соединений не имеет определенных правил для авторизированного соединения возвратного трафика. Поскольку списки управления доступом (ACL) к маршрутизатору не изменяют свое состояние, ответный трафик должен быть явно разрешен.
Те приложения, которые расположены в DMZ или используются внутри, могут помочь определить требования фильтрации. Просмотрите требования к приложениям для получения необходимой информации о структуре фильтра.
Использование списка ACL в формате классификации.
Список ACL в формате классификации состоит из операторов permit для различных протоколов, которые могут быть предназначены для внутренней сети. (См. Приложение A для списка наиболее часто используемых протоколов и приложений.) Используйте команду show access-list для отображения числа записей управления доступом (ACE) для определения требуемых протоколов. Изучите все сомнительные и неожиданные результаты перед созданием явного оператора permit для непредусмотренных протоколов.
Использование функции коммутации Netflow.
Netflow – это функция коммутации, которая в активированном состоянии предоставляет подробную информацию о технологическом процессе. Если функция Netflow активирована на ваших граничных маршрутизаторах, команда show ip cache flow выдает список протоколов, зарегистрированных с помощью функции Netflow. Функция Netflow не определяет все протоколы, поэтому эта методика должна применяться совместно с остальными.
Определение недопустимого трафика
Помимо направленной защиты список ACL для транзитного трафика также должен обеспечивать оперативную защиту от определенных типов недопустимых видов трафика в Интернете.
Пространство Deny RFC 1918.
Пакеты Deny, адрес источника которых входит в пространство адресов специального пользования, определяемых в RFC 3330.
Использование анти-спуфинговых фильтров в соответствии с RFC 2827; ваше адресное пространство не должно быть источником пакетов, расположенных за пределами автономной системы (AS).
Остальные типы рассматриваемых трафиков включают в себя:
Внешние протоколы и IP-адреса, необходимые для связи с граничным маршрутизатором
ICMP из IP-адресов поставщиков услуг
IPSec VPN, если граничный маршрутизатор используется в качестве граничного устройства
Четко определенный ответный трафик для внутреннего соединения с Интернетом
Специальные виды трафика ICMP (протокола управляющих сообщений Интернета)
Ответы на запрос системы исходящих имен доступа (DNS)
Установленный протокол TCP
Ответный трафик пользовательского протокола данных (UDP)
Информационные соединения FTP
Информационные соединения TFTP
Четко определенный внешний трафик, предназначенный для защиты внутренних адресов
Ассоциация межсетевой безопасности и протокол управления ключами (ISAKMP)
Просмотр трансляции сетевых адресов (протокол NAT)
Собственный механизм инкапсуляции
Инкапсуляция защищенной полезной нагрузки (протокол ESP)
Протокол аутентификации заголовка (AH)
HTTP для веб-серверов
Протокол безопасных соединений (SSL) для веб-серверов
FTP для FTP-серверов
Входящие информационные соединения FTP
Входящие пассивные информационные соединения FTP (pasv)
Простой протокол передачи почты (SMTP)
Другие приложения и серверы
Входящий запрос DNS
Зонный перенос входящего DNS
Применение ACL
Вновь созданный список ACL следует применять к входящему трафику для интерфейсов со стороны Интернета в граничных маршрутизаторах. В примере, приведенном в разделе Обычная установка, ACL применяется в интерфейсах Интернет-сетей на IR1 и IR2.
Более подробную информацию см. в разделе указания к применению и пример развертывания.
Пример ACL
Данный список доступа обеспечивает простой и в тоже время вполне реальный пример обычных записей, требуемых в списке ACL для транзитного трафика. Эти базовые списки ACL необходимо сопоставлять с элементами локальных конфигураций, характерных для каждого из узлов.
Примечание. Не забывайте об этих советах при использовании списка ACL для транзитного трафика
Ключевое слово log может быть использовано для получения дополнительной информации об источниках и назначениях для данного протокола. Кроме того, данное ключевое слово предоставляет подробное объяснение использования списка управления доступом, успешный выход к записям в списке ACL, который использует ключевое слово log для повышения коэффициента использования CPU. Влияние регистрации на производительность системы зависит от платформы.
Сообщения о недоступности ICMP генерируются для пакетов, которые в административном порядке запрещены списком ACL. Это может повлиять на производительность маршрутизатора и канала. Используйте команду no ip unreachables для отключения сообщений IP-недоступности в интерфейсе, где развернут транзитный (граничный) список ACL.
Этот ACL может быть внутренне развернут с помощью всех операторов permit для проверки того, что законный бизнес-трафика не отклоняется. Как только законный бизнес-трафик определен и рассчитан, могут быть настроены специальные элементы deny.
Списки ACL и фрагментированные пакеты
Списки ACL имеют ключевое слово fragments, которое активирует специальный режим обработки фрагментированных пакетов. В общем случае, на неначальные фрагменты, совпадающие с операторами уровня 3 (протокол, адрес источника и адрес назначения) – независимо от информации уровня 4 в списке управления доступом – оказывают влияние оператор permit или deny совпадающих записей. Обратите внимание на то, что использование ключевого слова fragments может привести к большей степени структурированности запрещенных или разрешенных неначальных фрагментов.
Фильтрация фрагментов добавляет дополнительный уровень защиты от атаки DoS (отказ от обслуживания), которая использует только неначальные фрагменты (когда FO > 0). Использование оператора deny для неначальных фрагментов в начале ACL закрывает доступ в маршрутизатор всем неначальным фрагментам. В редких случаях допустимая операция может потребовать фрагментации и, таким образом, будет отфильтрована при наличии в списке ACL оператора deny fragment. К условиям, вызывающим фрагментацию, можно отнести использование аутентификации цифровых сертификатов для ISAKMP, а также просмотр IPSec NAT.
В качестве примера рассмотрим неполный список ACL.
Добавление этих записей в начало списка управления доступом закрывает доступ в сеть всем неначальным фрагментам, в то время как нефрагментированные пакеты или исходные фрагменты передаются в следующие строки списка ACL (оператор deny fragment на них не действует). Предыдущий фрагмент списка ACL также способствует классификации атаки, поскольку каждый протокол – UDP, TCP и ICMP – увеличивает отдельные счетчики в ACL.
Поскольку большинство атак основано на волновом распространении фрагментированных пакетов, фильтрация входящих фрагментов во внутреннюю сеть обеспечивает дополнительные защитные меры и помогает удостовериться в том, что атака не может внедриться во фрагмент простым совпадением правил уровня 3 в списке ACL.
Более подробно параметры рассмотрены в документе Списки управления доступом и IP-фрагменты.
Оценка риска
Когда вы разворачиваете защиту транзитного трафика ACL, рассматривается две ключевые зоны риска.
Проверьте правильность размещения соответствующих операторов permit/deny. Для эффективного функционирования списка ACL необходимо разрешить все требуемые протоколы.
Производительность списка ACL изменяется в зависимости от платформы. Прежде чем развернуть списки ACL, изучите технические характеристики имеющегося оборудования.
Компания Cisco рекомендует перед развертыванием протестировать устройство в лаборатории.
Приложения
Часто используемые протоколы и приложения
Имена портов TCP
Имена портов UDP
Этот список имен портов UDP может применяться вместо номеров портов при задании конфигураций списка ACL в ПО Cisco IOS. Справочная информация по этим протоколам находится в RFC текущего назначенного номера. Номера портов, соответствующих данным протоколам, могут также быть определены во время настройки списка ACL при вводе ? вместо номера порта.
Указания к развертыванию
Компания Cisco рекомендует традиционные методы развертывания. Необходимо иметь четкое представление о требуемых протоколах для того, чтобы развернуть списки ACL для транзитного трафика. В настоящем руководстве описан традиционный метод развертывания защитных списков ACL с использованием итеративного метода.
Идентификация используемых в сети протоколов с помощью списка ACL в формате классификации.
Разверните список ACL, который разрешает все известные протоколы, используемые в сети. Это список ACL, предназначенный для обнаружения (или классификации) должен иметь адрес источника any и назначение IP-адреса или полную Интернет-маршрутизированную IP-подсеть. Задайте конфигурацию последней записи, которая разрешает ip any any log, для идентификации дополнительных протоколов, которые требуется разрешить.
Цель – определить все требуемые протоколы, используемые в сети. Используйте регистрацию данных для определения элементов, которые могут быть связаны с маршрутизатором.
Примечание. Кроме того, ключевое слово log обеспечивает подробное объяснение использования списка ACL, успешный выход к записям в списке ACL, при этом использование данного ключевого слова может привести к большому числу записей в журнале и более высокому коэффициенту использования ЦП маршрутизатора. Используйте ключевое слово log для коротких периодов времени или для упрощения классифицирования трафика.
Обратите внимание, что существует риск атаки на сеть, поскольку действующий список ACL состоит целиком из всех операторов permit. Выполните процесс классификации как можно быстрее, чтобы обеспечить соответствующее управление доступом.
Просмотр идентифицированных пакетов и начало фильтрации доступа во внутреннюю сеть.
После определения и просмотра пакетов, отфильтрованных списком ACL на первом этапе, обновите ACL классификации для вычисления новых определенных протоколов и IP-адресов. Добавьте анти-спуфинговые записи в список ACL. В соответствии с указаниями, в ACL классификации замените отдельные записи deny на операторы permit. Вы можете использовать команду show access-list для контроля отдельных записей deny и числа случаев выполнения функции. Это предоставляет информацию о запрещенных попытках доступа в сеть без включенных записей регистрации ACL. Последняя строка в списке ACL должна иметь вид deny ip any any. Снова число случаев выполнения функции для этой последней записи может предоставить информацию о запрещенных попытках доступа.
Контроль и обновление списка ACL.
Просмотрите заполненный список ACL для того, чтобы проверить, что новые введенные требуемые протоколы добавлены в соответствии со списком управления. Контроль списка управления доступом также дает возможность получить информацию о запрещенных попытках доступа в сеть, что в свою очередь приводит к получению сведений о предстоящей атаке.
Пример развертывания
В данном примере представлен список управления транзитным доступом, защищающий сеть, основанную на данной адресации.
IP-адрес маршрутизатора ISP – 10.1.1.1.
IP-адрес граничного маршрутизатора Интернета – 10.1.1.2.
Сеть с Интернет-маршрутизацией – 192.168.201.0 255.255.255.0.
Головной узел VPN – 192.168.201.100.
Сервер FTP – 192.168.201.102.
Сервер SMTP – 192.168.201.103.
Первичный сервер DNS – 192.168.201.104.
Вторичный сервер DNS – 172.16.201.50.
Список ACL транзитной защиты создан на основе данной информации. Список ACL открывает доступ одноранговых узлов eBGP в маршрутизатор ISP, предоставляет анти-спуфинговые фильтры, предоставляет специальный ответный и входной трафики и отклоняет все остальные виды трафика явным образом.