для чего используется механизм acl

Что такое ACL и как его настраивать

В этой статье речь пойдёт об списках аксес листах (списки листов доступа, ACL, NACL, access lists, access control list — все эти слова — синонимы, пусть вас не пугает их разнообразие). Далее в статье, для краткости я буду пользоваться термином ACL.

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

Итак, ACL (access control list) — это строго говоря, механизм для выбора из всего потока трафика какой-то части, по заданным критериям. Например, через маршрутизатор проходит множество пакетов, и вот такой ACL выбирает из множества только те пакеты, которые идут из подсети 192.168.1.0/24:

Что дальше делать с этим трафиком — пока неизвестно. Например, трафик, попавший под ACL может заворачиваться в VPN тоннель, или, подвергаться трансляции адресов (NAT). В курсе CCNA рассматривается два способа использования ACL: основной — это фильтрация трафика, второй — использование ACL при настройке NAT. Важно следующее: не имеет значения, где и для каких целей мы будем использовать ACL, правила написания ACL от этого не меняются. Кроме того, если мы только создали ACL, то он пока ни на что не влияет. ACL — это просто несколько неработающих строчек в конфиге, пока мы его не применим, например, на интерфейс, для фильтрации трафика.

Типы ACL

ACL-и бывают двух видов: стандартные и расширенные. Стандартные позволяют отфильтровывать трафик только по одному критерию: адрес отправителя, в CCNA рассматривается конкретно только ip адрес отправителя. Согласитесь, сильно много не нафильтруешь по такому признаку. Можно, например, поставить на выходе из нашей сети такой ACL:

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

Расширенный ACL позволяет фильтровать трафик по большому количеству параметров:

Возможности расширенных ACL богаче стандартных, кроме того, они могут расширяться дополнительными технологиями:

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

Порядок просмотра ACL

Итак, что из себя представляет ACL и как трафик проверяется на соответствтие?

ACL — это набор правил. Каждое правило состоит из действия (permit, deny) и критерия (для стандартных ACL — ip адрес отправителя, для расширенных — множество критериев). Рассмотрим такой пример стандартного нумерованного ACL:

Этот ACL запрещает доступ для всей сети 192.168.1.0/24 кроме хоста 192.168.1.1 и разрешает доступ для всех остальных сетей. Как проверяется трафик на соответствие ACL? Построчно. То есть, приходит, например, пакет с адреса 192.168.2.2 на роутер, а на том интерфейсе через который он пришел стоит на вход указанный выше ACL, вот построчно Ip адрес отправителя сверяется с данным ACL, что важно — до первого совпадения. Как только пакет совпадёт с какой-то из строк, сработает действие (permit — пропустить пакет либо deny — уничтожить пакет) и дальше никаких проверок по оставшимся строчкам проводиться не будет. Если все строчки пройдены, а пакет так и не попал ни под одно из правил, то он по умолчанию уничтожается. В нашем случае, в примере выше любой пакет подходит под третью строчку, так как там вместо адреса стоит слово «any», означающее, что любой адрес подойдёт. Таким образом, приведённый ACL можно читать так:

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

То по нашему же предыдущему алгоритму, обходился бы он так:

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

Применение ACL

ACL применяется для разных целей, но основная цель, для которой он используется в CCNA — фильтрация трафика на интерфейсе. Для этого надо сначала создать стандартный или расширенный ACL. Если ACL именованный, то у него есть имя, которое мы и укажем на интерфейсе, если нумерованный — то номер. Чтобы сделать это, заходим на интерфейс и пишем команду ip access-group, например, так:

В этом примере мы применили ACL с именем MY_ACLS_NAME наинтерфейсе Fa0/0 на весь входящий трафик (о чем говорит слово in) если бы мы неписали out — то фильтровался бы исходящий трафик.

Люди часто путаются с направлениями. Например, есть сеть, подключенная к маршрутизатору и стоит задача запретить входящий в эту сеть трафик. Так вот, в данном случае этот входящий трафик фильтруется применением ACL на out, то есть на выход. Всё просто, чтобы не запутаться, надо представить себя на месте маршрутизатора. Понятно, что если трафик входит в какую-то сеть, то он при том выходит из маршрутизатора и с точки зрения роутера, такой трафик исходящий.

Вообще, на один интерфейс можно навесить более одного ACL, но при условии, что у них будет отличаться направление, либо, протокол (есть ведь ещё IPX ACL AppleTalk ACL). Впрочем, для CCNA это не имеет значения, так как в нём речь идёт только об IP ACL. Таким образом, если ограничиваться только IP, то на каждый интерфейс можно навесить не более двух ACL: один на in, второй — на out.

Где лучше применять ACL? Вопрос, на самом деле, не тривиальный и студенты без должного опыта часто дают на него неправильный ответ. Рассмотрим пример: Дана топология, надо запретить доступ с компьютера в сеть ноутбука двумя способами по очереди (сначала с помощью стандартного, затем с помощью расширенного ACL).

Подумайте над этим немного. Здравый смысл и рекомендация от cisco подталкивают нас к следующему правилу: «Стандартный ACL приходится размещать максимально близко к получателю трафика». Действительно, ведь с помощью стандартного ACL мы можем смотреть только на адрес отправителя и не знаем, куда именно этот трафик идёт. Поэтом, если мы разместим запрещающий доступ с Ip адреса компьютера список, например, на R1 на вход на Fa0/0, то мы сможем запретить или разрешить только весь трафик с компьютера сразу, то есть во все сети, а не только в сеть ноутбука. Поэтому, придётся ставить такой ACL максимально близко к получателю трафика, а именно, на R4 на выход из интерфейса Fa0/1. Если пакет дошел до сюда и собирается выйти через Fa0/1, значит он точно собирается в сеть ноутбука. Теперь с помощью стандартного ACL мы можем отсечь трафик, идущий от компьютера.

Если мы хотим использовать расширенный ACL, то мы, в принципе, можем его поставить где угодно, но разумнее всего его ставить максимально близко к отправителю трафика, то есть, в нашем примере, на Fa0/0 на R1 на вход. Действительно, если мы можем смотреть в расширенном ACL-е адрес получателя, то давайте сделаем это максимально быстро и если пакет идёт из компьютера в сеть ноутбука, то уничтожим его сразу же на входе в Fa0/0, чтобы дальше не нагружать сеть передачей этого пакета.

Таким образом, у нас есть небольшое правило, которое может упростить жизнь: «Стандартный ACL ставится максимально близко к получателю трафика, расширенный — максимально близко к источнику трафика». Правило не всегда супер эффективно, иногда надо и голову включать, но для начала оно неплохо работает. Лучше всего выбирать место изначально по этому правилу, а затем подумать над тем, откуда трафик идёт и как можно улучшить размещение ACL.

ACL можно применять не только для фильтрации трафика, но и для ограничения адресов, с которых можно подключиться к роутеру по telnet или ssh. Эта полезная функция описывается в отдельной статье «Ограничение доступа к маршрутизатору по telnet или ssh с помощью ACL»

Источник

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.

Источник

Списки управления доступом

Список управления доступом на уровне пользователей (DACL) определяет доверенные лица, которым разрешен или запрещен доступ к защищаемому объекту. Когда процесс пытается получить доступ к защищаемому объекту, система проверяет ACE в списке DACL объекта, чтобы определить, следует ли предоставить доступ к нему. Если у объекта нет DACL, система предоставляет полный доступ для всех. Если DACL объекта не имеет записей ACE, система отклоняет все попытки доступа к объекту, так как список DACL не разрешает права доступа. Система проверяет ACE по порядку, пока не обнаружит один или несколько записей ACE, которые разрешают все запрошенные права доступа, или пока не будут отклонены все запрошенные права доступа. Дополнительные сведения см. в статье Управление доступом к объекту в DACL. Сведения о том, как правильно создать список DACL, см. в разделе Создание списка DACL.

Системный список управления доступом (SACL) позволяет администраторам регистрировать попытки доступа к защищенному объекту. Каждый элемент ACE указывает типы попыток доступа с помощью указанного доверенного лица, которое приводит к тому, что система создает запись в журнале событий безопасности. Элемент управления доступом в списке SACL может создавать записи аудита при неудачной попытке доступа, при успешном или в обоих случаях. Дополнительные сведения о SACL см. в разделе Создание аудита и право доступа к SACL.

Не пытайтесь работать непосредственно с содержимым ACL. Чтобы обеспечить семантическую правильность списков ACL, используйте соответствующие функции для создания ACL и управления ими. Дополнительные сведения см. в разделе Получение сведений из ACL и Создание или изменение списка управления доступом.

Списки ACL также обеспечивают управление доступом к объектам службы Microsoft Active Directory Directory. Active Directory интерфейсов служб (ADSI) включают подпрограммы для создания и изменения содержимого этих списков ACL. Дополнительные сведения см. в разделе Управление доступом к Active Directory объектам.

Источник

Для чего используется механизм acl

Сети для самых маленьких. Часть пятая. ACL и NAT

Продолжаем развитие нашей маленькой уютной сети Лифт ми Ап. Мы уже обсудили вопросы маршрутизации и стабильности, и теперь, наконец, выросли для подключения к Интернету. Довольно заточения в рамках нашей корпоративной среды!
Но с развитием появляются и новые проблемы.
Сначала вирус парализовал веб-сервер, потом кто-то притаранил червя, который распространился в сети, заняв часть полосы пропускания. А ещё какой-то злодей повадился подбирать пароли на ssh к серверу.
А представляете, что начнётся, когда мы подключимся к Интернету?!
Итак, сегодня:
1) учимся настраивать различные списки контроля доступа (Access Control List)
2) пытаемся понять разницу между ограничением входящего и исходящего трафика
3) разбираемся с тем, как работает NAT, его плюсы, минусы и возможности
4) на практике организуем подключение к Интернету через NAT и увеличим безопасность сети, используя списки доступа.

Access Control List

Итак, что мы имеем сказать по спискам доступа? Вообще-то тема относительно простая и только ленивыми из курса CCNA не скопипащена. Но не разрывать же нам наше удивительное повествование из-за каких то предрассудков?
Каково предназначение списков доступа? Казалось бы, совершенно очевидный ответ — для ограничения доступа: кому-то что-то запретить, например. Вообще — это верно, но понимать нужно в более широком смысле: речь не только о безопасности. То есть, изначально, вероятно, так оно и было, отсюда permit и deny при настройке. Но на самом деле ACL — это универсальный и мощный механизм фильтрации. С их помощью можно определить на кого навешивать определённые политики, а на кого нет, кто будет участвовать в неких процессах, а кто нет, кого ограничиваем в скорость до 56k, а кого до 56M.
Чтобы было чуть-чуть понятнее, приведём простой пример. Опираясь на списки доступа, работает Policy-Based Routing (PBR). Можно сделать здесь так, чтобы пакеты приходящие из сети 192.168.1.0/24 отправлялись на next-hop 10.0.1.1, а из сети 192.168.2.0/24 на 10.0.2.1 (заметим, что обычная маршрутизация опирается на адрес назначения пакета и автоматически все пакеты отправляются на один next-hop): В конце статьи пример настройки PBR и ограничения скорости на основе ACL.

Виды ACL

Ладно, забудем на время эту лирику.
Вообще говоря, списки доступа бывают разными:

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

Входящий и исходящий трафик

Для почину давайте-ка разберёмся с одной вещью. Что понимать под входящим и исходящим трафиком? Это нам в будущем понадобится. Входящий трафик — этот тот, который приходит на интерфейс извне. Исходящий — тот, который отправляется с интерфейса вовне. Список доступа вы можете применить либо на входящий трафик, тогда неугодные пакеты не будут даже попадать на маршрутизатор и соответственно, дальше в сеть, либо на исходящий, тогда пакеты приходят на маршрутизатор, обрабатываются им, доходят до целевого интерфейса и только на нём дропятся.
Стандартный список доступа проверяет только адрес отправителя. Расширенный- адрес отправителя, адрес получателя, а также порт. Стандартные ACL рекомендуется ставить как можно ближе к получателю (чтобы не порезать больше, чем нужно), а расширенные- ближе к отправителю (чтобы как можно раньше дропнуть нежелательный трафик).

Практика

Давайте сразу к практике. Что бы нам такого наограничивать в нашей маленькой сети “Лифт ми Ап”?

1) Доступ на WEB-сервер

Тут у нас работает политика запрещено всё, что не разрешено. Поэтому нам сейчас надо кое-что открыть, а всё остальное закрыть.
Поскольку мы защищаем сеть серверов, то и лист будем вешать на интерфейс, идущий в сторону них то есть, на FE0/0.3 Вопрос только на in или на out нам нужно это делать? Если мы не хотим пускать пакеты в сторону серверов, которые уже оказались на маршрутизаторе, то это будет исходящий трафик. То есть адреса назначения (destination) у нас будут в сети серверов (из них мы будем выбирать на какой именно сервер идёт трафик), а адреса источников (source) могут быть любыми — как из нашей корпоративной сети, так и из интернета. Ещё одно замечание: поскольку фильтровать мы будем в том числе по адресу назначения (на WEB-сервер одни правила, на почтовый — другие), то список контроля доступа нам понадобится расширенный (extended), только он позволяет делать это.
Правила в списке доступа проверяются по порядку сверху вниз до первого совпадения. Как только одно из правил сработало, независимо от того permit это или deny, проверка прекращается и обработка трафика происходит на основе сработавшего правила.
То есть если мы хотим защитить WEB-сервер, то в первую очередь нам нужно дать разрешение, потому что, если мы в первой же строке настроим deny ip any any — то оно всегда будет срабатывать и трафик не будет ходить вообще. Any — это специальное слово, которое означает адрес сети и обратную маску 0.0.0.0 0.0.0.0 и означает, что под правило подпадают абсолютно все узлы из любых сетей. Другое специальное слово — host — оно означает маску 255.255.255.255 — то есть именно один единственный указанный адрес.
Итак, первое правило: разрешить доступ всем по порту 80

Проверяем с любого из наших подключенных компьютеров: Как видите страничка открывается, но что там у нас с пингом? И так с любого другого узла?
Дело в том, что после всех правил в цисковских ACL в конце дописывается неявное deny ip any any (implicit deny). Что для нас это означает? Любой пакет, выходящий с интерфейса и не отвечающий ни одному правилу из ACL, подпадает под implicit deny и отбрасывается. То есть хоть пинг, хоть фтп, хоть что угодно здесь уже не пройдёт.
Идём дальше: надо дать полный доступ компьютеру, с которого будет производиться управление. Это будет компьютер нашего админа с адресом 172.16.6.66 из сети Other.
Каждое новое правило добавляется автоматически в конец списка, если он уже существует:

Вот и всё. Проверяем с нужного узла (поскольку серверами в РТ не поддерживается телнет, проверяем на FTP): То есть FTP-сообщение пришло на маршрутизатор и должно уйти с интерфейса FE0/0.3. Маршрутизатор проверяет и видит, что пакет подходит под добавленное нами правило и пропускает его.
А с постороннего узла пакет FTP не попадает ни под одно из правил, кроме неявного deny ip any any и отбрасывается.

2) Доступ на файловый сервер

Тут бы надо в первую очередь определиться с тем, кто будет “резидентом”, кому нужно дать доступ. Конечно, это те, кто имеет адрес из сети 172.16.0.0/16 — только им и дадим доступ. Теперь с общими папками. В большинстве современных систем уже используется для этого протокол SMB, которому нужен порт TCP 445. На более старых версиях использовался NetBios, который кормился аж через три порта: UDP 137 и 138 и TCP 139. Договорившись с нашим админом, настроим 445 порт (правда проверить в рамках РТ, конечно, не получится). Но кроме этого, нам понадобятся порты для FTP — 20, 21, причём не только для внутренних хостов, но и для соединений из интернета:

Тут мы повторно применили конструкцию range 20 21 — для того, чтобы в одной строке задать несколько портов. Для FTP, вообще говоря, недостаточно только 21-го порта. Дело в том, что если вы откроете только его, то авторизация у вас будет проходить, а передача файлов нет.
0.0.255.255 — обратная маска (wildcard mask). О том, что это такое, поговорим чуточку позже

3) Доступ на почтовый сервер

Продолжаем нарабатывать практику — теперь с почтовым сервером. В рамках того же списка доступа добавляем новые нужные нам записи.
Вместо номеров портов для широкораспространённых протоколов можно указывать их имена:

4) DNS-сервер

5) ICMP

Осталось исправить ситуацию с пингом. Ничего страшного нет в том, чтобы добавить правила в конец списка, но как-то эстетически приятнее будет увидеть их вначале.
Используем несложный чит для этого. Для это можно воспользоваться текстовым редактором, например. Скопируйте туда из show run кусок про ACL и добавьте следующие строки:

Первой строкой мы удаляем существующий список, далее создаём его заново и перечисляем все новые правила в нужном нам порядке. Командой в третьей строке мы разрешили проход всех ICMP-пакетов от любых хостов на любые хосты.
Далее просто копируем всё скопом и вставляем в консоль. Интерфейс интерпретирует каждую строку как отдельную команду и выполняет её. Таким образом, мы заменили старый список новым. Проверяем, что пинг есть: Прекрасно.
Данный “чит” хорош для первоначальной конфигурации или если вы точно понимаете, что делаете. На рабочей сети, когда вы настраиваете удалённо ACL, вы рискуете остаться без доступа на настраиваемую железку.

Чтобы вставить правило в начало или в любое другое нужное место, вы можете прибегнуть к такому приёму:

Каждое правило в списке пронумеровано с определённым шагом и если перед словом permit/deny вы поставите число, то правило будет добавлено не в конец, а в нужное вам место. К сожалению, такая фича не работает в РТ.
Если будет вдруг необходимо (заняты все подряд идущие числа между правилами) вы всегда можете перенумеровать правила (в этом примере назначается номер первого правила 10(первое число) и инкремент 10):

В итоге Access List на серверную сеть будет выглядеть так:

Сейчас наш админ имеет доступ только на WEB-сервер. Откройте ему полный доступ на всю сеть. Это первое домашнее задание.

6) Права пользователей из сети Other

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

Тут мы не могли сначала запретить всем, а потом разрешить избранным, потому что абсолютно все пакеты попадали бы под правило deny ip any any и permit не срабатывал бы вообще. Применяем на интерфейс. На этот раз на вход:

то есть все IP-пакеты от хоста с адресом 172.16.6.61 или 172.16.6.66 разрешено передавать куда бы они ни были предназначены. Почему мы тут используем тоже расширенный список доступа? Ведь, казалось бы, мы проверяем только адрес отправителя. Потому что админу мы дали полный доступ, а вот гостю компании “Лифт ми Ап”, например, который попадёт в эту же сеть совсем ни к чему доступ куда-либо, кроме как в Интернет.

7) Сеть управления

Ничего сложного. Правило будет выглядеть так:

Данный ACL применяем на out на интерфейс FE 0/0.2:

8) Более никаких ограничений

Маска и обратная маска

До сих пор мы без объяснения давали странный параметр вида 0.0.255.255, подозрительно напоминающий маску подсети.
Немного сложная для понимания, но именно она — обратная маска — используется для определения хостов, которые подпадут под правило.
Чтобы понять что такое обратная маска, вы должны знать, что такое обычная.Начнём с самого простого примера.
Обычная сеть на 256 адресов: 172.16.5.0/24, например. Что означает эта запись?
А означает она ровно следующее

IP-адрес — это параметр длиною 32 бита, поделенный на 4 части, который вы привыкли видеть в десятичной форме.
Маска подсети также имеет длину 32 бита — она фактически шаблон, трафарет, по которому определяется принадлежность адреса подсети. Там, где в маске стоят единицы, значение меняться не может, то есть часть 172.16.5 совершенно неизменна и она будет одинакова для всех хостов этой подсети, а вот та, где нули — варьируется.
То есть во взятом нами примере 172.16.5.0/24 — это адрес сети, а хосты будут 172.16.5.1-172.16.5.254 (последний 255 — широковещательный), потому что 00000001 — это 1, а 11111110 — 254 (речь о последнем октете адреса). /24 означает, что длина маски 24 бита, то есть у нас идёт 24 единицы — неизменная часть и 8 нулей.
Другой случай, когда маска у нас, например, 30 бит, а не 24.
К примеру 172.16.2.4/30. Распишем это так:

Как видите, для этой подсети могут меняться только последние два бита. Последний октет может принимать следующие 4 значения:
00000100 — адрес подсети (4 в десятичной системе)
00000101 — адрес узла (5)
00000110 — адрес узла (6)
00000111 — широковещательный (7)
Всё, что за пределами этого — уже другая подсеть
То есть теперь вам должно быть чуть-чуть понятно, что маска подсети — это последовательность 32-х бит, где сначала идут единицы, означающие адрес подсети, потом идут нули, означающие адрес хоста. При этом чередоваться нули и единицы в маске не могут чередоваться. То есть маска 11111111.11100000.11110111.00000000 невозможна
А что же такое обратная маска (wildcard)?
Для подавляющего большинства админов и некоторых инженеров — это не более, чем инверсия обычной маски. То есть нули вначале задают адрес части, которая должна совпадать обязательно, а единицы наоборот свободную часть.
То есть на взятом нами первом примере, если вы хотите отфильтровать все хосты из подсети 172.16.5.0/24, то вы зададите правило в Access-листе:
…. 172.16.5.0 0.0.0.255
Потому что обратная маска будет выглядеть так:
00000000.00000000.00000000.11111111
Во втором примере с сетью 172.16.2.4/30 обратная маска будет выглядеть так: 30 нулей и две единицы:

Соответственно параметр в access-листе будет выглядеть так:
…. 172.16.2.4 0.0.0.3
Позже, когда вы съедите собаку на просчётах масок и обратных масок, вы запомните самые употребляемые цифры, количество хостов в той или иной маске, поймёте, что в описанных ситуациях последний октет обратной маски получается вычитанием из 255 цифры последнего октета обычной маски (255-252=3) и т.д. А пока нужно много трудиться и считать)
Но на самом деле обратная маска — это несколько более богатый инструмент, здесь вы можете объединять адреса внутри одной подсети или даже объединять подсети, но самое главное отличие, вы можете чередовать нули и единицы. Это позволяет вам, например, отфильтровать определённый узел (или группу) в нескольких подсетях одной строкой.

Пример 1

Дано: сеть 172.16.16.0/24
Надо: отфильтровать первые 64 адреса (172.16.16.0-172.16.16.63)
Решение: 172.16.16.0 0.0.0.63

Пример 2

Дано: сети 172.16.16.0/24 и 172.16.17.0/24
Надо: отфильтровать адреса из обеих сетей
Решение: 172.16.16.0 0.0.1.255

Пример 3

Дано: Сети 172.16.0.0-172.16.255.0
Надо: отфильтровать хост с адресом 4 из всех подсетей
Решение: 172.16.0.4 0.0.255.0
Признаться ни разу в жизни не приходилось встречаться с последним сценарием применения. Это какие-то жутко специфические должны быть задачи.
Более подробно об обратных масках можно прочитать тут: http://habrahabr.ru/post/131712/

Работа ACL в картинках

Гипотетическая сеть: 1) На маршрутизаторе RT1 на интерфейсе FE0/1 на вход у нас разрешено всё, кроме ICMP. 2) На маршрутизаторе RT2 на интерфейсе FE0/1 на выход запрещены SSH и TELNET Тесты
кликабельны
1) Пинг с компьютера ПК1 на Сервер1

2) TELNET с компьютера ПК1 на Сервер1

3) SSH с компьютера ПК1 на Сервер2

4) Пинг с Сервера2 на ПК1

Дополнения

1) Правила, действующие на исходящий трафик (out) не будут фильтровать трафик самого устройства. То есть, если нужно запретить самой циске доступ куда-либо, то вам придётся на этом интерфейсе фильтровать входящий трафик (ответный оттуда, куда надо запретить доступ).
2) C ACL надо быть аккуратнее. При небольшой ошибке в правиле, неправильном порядке настройки или вообще плохо продуманном списке вы можете остаться без доступа к устройству.
Например, вы хотите закрыть доступ куда угодно для сети 172.16.6.0/24, кроме своего адреса 172.16.6.61 и задаёте правила так:

Казалось бы: хосту с адресом 1.1.1.1 разрешён доступ по 80-му порту на сервер 2.2.2.2 (первое правило). И обратно от сервера 2.2.2.2 разрешены соединения внутрь.
Но нюанс тут в том, что компьютер 1.1.1.1 устанавливает соединение НА 80-й порт, но С какого-то другого, например, 1054, то есть ответный пакет от сервера приходит на сокет 1.1.1.1:1054, не подпадает под правило в ACL на IN и отбрасывается ввиду неявного deny ip any any.
Чтобы избежать такой ситуации, и не открывать всем пучком порты, можно прибегнуть к такой хитрости в ACL на in:

Подробности такого решения в одной из следующих статей.
4) Говоря про современный мир, нельзя обойти такой инструмент, как объектные группы (Object-group).
Допустим, надо составить ACL, выпускающий три определенных адреса в интернет по трем одинаковым портам c перспективой расширения количества адресов и портов. Как это выглядит без знания объектных групп:

При увеличении количества параметров сопровождать такой ACL становится всё труднее и труднее, легко ошибиться при настройке.
Зато, если обратиться к объектным группам, то это приобретает следующий вид:

на первый взгляд несколько угрожающе выглядит, но если разобраться, то это очень удобно.
4) Очень полезную для траблшутинга информацию можно получить из вывода команды show ip access-lists %имя ACL%. Кроме собственно списка правил указанного ACL, эта команда показывает количество совпадений по каждому правилу.

А дописав в конце любого правила log, мы сможем получать сообщения о каждом совпадении в консоль. (последнее не работает в PT)

Network Address Translation — механизм в хозяйстве совершенно необходимый уже с 1994-го года. Много сессий об него сломано и пакетов потеряно. Нужен он чаще всего для подключения вашей локальной сети к Интернету. Дело в том, что теоретически существует 255*255*255*255=4 228 250 625. 4 миллиарда адресов. Даже если бы у каждого жителя планеты был всего один компьютер, адресов бы уже не хватало. А тут разве что утюги к Интернету не подключаются. Умные люди сообразили это ещё в начале 90-х и как временное решение предложили разделить пространство адресов на публичные (белые) и приватные (частные, серые).
К последним относятся три диапазона:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Их вы свободно можете использовать в своей частной сети, и поэтому, разумеется, они будут повторяться. Как же быть с уникальностью? Кому будет отвечать WEB-сервер, которому пришёл запрос с обратным адресом 192.168.1.1? Ростелекому? Компании Татнефть? Или вашему комнатному Длинку? В большом интернете никто ничего не знает о приватных сетях — они не маршрутизируются.
Тут и выходит на сцену NAT. По большому счёту, это обман, подстава. На натирующем устройстве ваш приватный адрес, грубо говоря, просто подменяется на белый адрес, который и будет фигурировать далее в пакете, пока он путешествует до WEB-сервера. А вот белые адреса очень даже хорошо маршрутизируются, и пакет точно вернётся обратно на натирующее устройство.
Но как оно в свою очередь поймёт, что с ним делать дальше? Вот с этим и разберёмся.

Типы NAT

Статический

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

Что происходит: 1) Узел 172.16.6.5 обращается WEB-серверу. Он отправляет IP-пакет, где в качестве адреса получателя стоит 192.0.2.2, а отправителя 172.16.6.5. 2) По корпоративной сети пакет доставляется к шлюзу 172.16.6.1, где и настроен NAT 3) Согласно настроенной команде, маршрутизатор снимает текущий заголовок IP и меняет его на новый, где в качестве адреса отправителя уже фигурирует белый адрес 198.51.100.2. 4) По большому Интернету обновлённый пакет достигает сервера 192.0.2.2. 5) Тот видит, что ответ надо слать на 198.51.100.2 И подготавливает ответный IP-пакет. В качестве адреса отправителя собственно адрес сервера 192.0.2.2, адрес назначения — 198.51.100.2 6) Пакет обратно летит через Интернет, причём не факт, что тем же путём.
7) На натирующем устройстве указано, что все запросы на адрес 198.51.100.2 нужно перенаправлять на 172.16.6.5. Маршрутизатор снова раздевает спрятанный внутри TCP-сегмент и задаёт новый IP-заголовок (адрес отправителя не меняется, адрес назначения 172.16.6.5). 8) По внутренней сети пакет возвращается инициатору, которому даже и невдомёк, какие чудеса с ним творились на границе.
И так будет с каждым.
При этом если соединение инициируется из Интернета, пакеты автоматически, проходя через натирующее устройство, попадают на внутренний хост.
Такой подход бывает полезным, когда у вас есть сервер внутри вашей сети, к которому необходим полный доступ извне. Разумеется, этот вариант вы не можете использовать, если хотите триста хостов выпустить в Интернет через один адрес. Такой вариант NAT’а никак не поможет сохранить белые IP-адреса, но тем не менее он бывает полезен.

Динамический

У вас есть пул белых адресов, например, провайдер выделил вам сеть 198.51.100.0/28 c 16-ю адресами. Два из них (первый и последний) — адрес сети и широковещательный, ещё два адреса назначаются на оборудование для обеспечения маршрутизации. 12 оставшихся адресов вы можете использовать для NAT’а и выпускать через них своих пользователей.
Ситуация похожа на статический NAT — один приватный адрес транслируется на один внешний, — но теперь внешний не чётко зафиксирован, а будет выбираться динамически из заданного диапазона. Настраивается он так:

Задали пул (диапазон) публичных адресов, из которого будет выбираться адрес для натирования

Задаём список доступа, который пропускает все пакеты с адресом источника 172.16.6.х, где х варьируется 0-255.

Этой командой мы стыкуем созданный ACL и пул.
Этот вариант тоже не универсальный, своих 300 пользователей вы так же не сможете выпустить всех в Интернет, если у вас нет 300 внешних адресов. Как только белые адреса исчерпаются, никто новый уже не сможет получить доступ в Интернет. При этом те пользователи, что уже успели отхватить себе внешний адрес, будут работать. Скинуть все текущие трансляции и освободить внешний адреса вам поможет команда clear ip nat translation *
Помимо динамического выделения внешних адресов, этот динамически NAT отличается от статического тем, что без отдельной настройки проброса портов уже невозможно внешнее соединение на один из адресов пула.

Many-to-One

Следующий тип имеет несколько названий: NAT Overload, Port Address Translation (PAT), IP Masquerading, Many-to-One NAT.
Последнее название говорит само за себя — через один внешний адрес выходит в мир много приватных. Это позволяет решить проблему с нехваткой внешних адресов и выпустить в мир всех желающих. Тут надо бы дать пояснение, как это работает. Как два приватных адреса транслируются в один можно представить, но как маршрутизатор понимает кому нужно переслать пакет, вернувшийся из Интернета на этот адрес?
Всё очень просто:
Предположим, что от двух хостов из внутренней сети приходят пакеты на натирующее устройство. Оба с запросом к WEB-серверу 192.0.2.2.
Данные от хостов выглядят так:

Маршрутизатор расчехляет IP-пакет от первого хоста, извлекает из него TCP-сегмент, распечатывает его и узнаёт, с какого порта устанавливается соединение. У него есть внешний адрес 198.51.100.2, на который будет меняться адрес из внутренней сети.
Далее он выбирает свободный порт, например, 11874. И что он делает дальше? Все данные уровня приложений он упаковывает в новый TCP сегмент, где в качестве порта назначения по-прежнему остаётся 80 (именно на него ждёт коннектов WEB-сервер), а порт отправителя меняется с 23761 на 11874. Этот TCP-сегмент инкапсулируется в новый IP-пакет, где меняется IP-адрес отправителя с 172.16.6.5 на 198.51.100.2.
То же самое происходит для пакета от второго хоста, только выбирается следующий свободный порт, например 11875. “Свободный” означает, что он ещё не занят другими такими соединениями. Данные, которые отправляются в интернет, теперь буду выглядеть так.

В свою NAT-таблицу он заносит данные отправителей и получателей

Для WEB-сервера — это два совершенно разных запроса, которые он должен обработать каждый индивидуально. После этого он отсылает ответ, который выглядит так:

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

И теперь пакеты доставляется по внутренней сети компьютерам-инициаторам, которым и невдомёк даже, что где-то с их данными так жёстко обошлись на границе.
Каждое ваше обращение — это отдельное соединение. То есть попытались вы открыть WEB-страницу — это протокол HTTP, использующий порт 80. Для этого ваш компьютер должен установить TCP-сессию с удалённым сервером. Такая сессия (TCP или UDP) определяется двумя сокетами: локальный IP-адрес: локальный порт и удалённый IP-адрес: удалённый порт. В обычной ситуации у вас устанавливается одно соединение компьютер-сервер, в случае же NATа соединения будет как бы два:, маршрутизатор-сервер и компьютер думает, что у него есть сессия компьютер-сервер.
Настройка отличается совершенно незначительно: добавочным словом overload:

При этом, разумеется, сохраняется возможность настроить пул адресов:

Перенаправление портов

Иначе говорят ещё проброс портов или mapping.
Когда мы только начали говорить про NAT, трансляция у нас была один-в-один и все запросы, приходящие извне автоматически перенаправлялись на внутренний хост. Таким образом можно было бы выставить сервер наружу в Интернет.
Но если у вас нет такой возможности — вы ограничены в белых адресах, или не хотите выставлять всем пучком портов его наружу, что делать?
Вы можете указать, что все запросы, приходящие на конкретный белый адрес и конкретный порт маршрутизатора, должны быть перенаправлены на нужный порт нужного внутреннего адреса.

Применение данной команды означает, что TCP-запрос, пришедший из интернета на адрес 198.51.100.2 по порту 80, будет перенаправлен на внутренний адрес 172.16.0.2 на тот же 80-й порт. Разумеется, вы можете пробрасывать и UDP и делать перенаправление с одного порта на другой. Это, например, может оказаться полезным, если у вас есть два компьютера, к которым нужен доступ по RDP извне. RDP использует порт 3389. Один и тот же порт вы не можете пробросить на разные хосты (при использовании одного внешнего адреса). Поэтому вы можете сделать так:

Тогда, чтобы попасть на компьютер 172.16.6.61 вы запускаете RDP-сессию на порт 198.51.100.2:3389, а на 172.16.6.66 — 198.51.100.2:3398. Маршрутизатор сам раскидает всё, куда надо.
Кстати, эта команда — частный случай самой первой: ip nat inside source static 172.16.6.66 198.51.100.2. Только в этом случае речь идёт о пробросе всего трафика, а в наших примерах — конкретных портов протокола TCP.
Вот так в общих чертах фунциклирует NAT. Про его особенности, плюсы/минусы написано куча статей, но не отметить их нельзя.

Слабости и силости NAT

— В первую очередь NAT позволяет сэкономить публичные IP-адреса. Собственно для этого он и был создан. Через один адрес, теоретически можно выпустить больше 65000 серых адресов (по количеству портов).
— Во-вторых, PAT и динамический NAT является в какой-то степени файрволом, препятствуя внешним соединениям доходить до конечных компьютеров, на которых может не оказаться своего файрвола и антивируса. Дело в том, что если извне на натирующее устройство приходит пакет, который тут не ожидается или не разрешён, он просто отбрасывается.
Чтобы пакет был пропущен и обработан, должны выполниться следующие условия:
1) В NAT-таблице должна быть запись для этого внешнего адреса, указанного как адрес отправителя в пакете
И
2) Порт отправителя в пакете должен совпадать с портом для этого белого адреса в записи
И
3) Порт назначения в пакете, совпадает с портом в записи.
ИЛИ
Настроен проброс портов.
Но не нужно рассматривать NAT именно как файрвол — это не более, чем дополнительная его плюшка.
— В-третьих, NAT скрывает от посторонних глаз внутреннюю структуру вашей сети — при трассировке маршрута извне вы не увидите ничего далее натирующего устройства.

Практика NAT

Чего от нас требует реальность?
1) Сеть управления не имеет доступа в интернет вообще
2) Хосты из сети ПТО имеют доступ только к профильным сайтам, например, Linkmeup.ru
3) Милым дамам из бухгалтерии нужно вырубить окно в мир клиент-банков.
4) ФЭО не выпускать никуда, за исключением финансового директора
5) В сети Other наш компьютер и компьютер админа — им дадим полный доступ в интернет. Всем остальным можно открывать по письменному запросу.
6) Не забудем про филиалы в Питере и в Кемерово. Для простоты настроим полный доступ для эникиев из этих подсетей.
7) С серверами отдельная песня. Для них мы настроим перенаправление портов. Всё, что нам нужно:
а) WEB-сервер должен быть доступен по 80-му порту
б) Почтовый сервер по 25-му и 110-му
в) Файловый сервер доступен из мира по FTP.
8) Компьютеры админа и наш должны быть доступны из Интернета по RDP. Вообще-то это неправильный путь — для удалённого подключения нужно использовать VPN-подключение и уже будучи в локальной сети использовать RDP, но это тема отдельной совсем другой статьи.
Сначала подготовим тестовую площадку:
Подключение к Интернету будет организовано через существующий линк, который предоставляет провайдер.
Он уходит в сеть провайдера. Напоминаем, что всё в этом облаке — это абстрактная сеть, которая на деле может состоять из десятков маршрутизаторов и сотен коммутаторов. Но нам нужно нечто управляемое и предсказуемое, поэтому водружаем сюда ещё маршрутизатор. С одной стороны в него линк из коммутатора, с другой сервера в Интернете.
Сервера нам понадобятся следующие:
1. Два клиент-банка для бухгалтеров (sperbank.ru, mmm-bank.ru)
2. Linkmeup.ru для ПТОшников
3. яндекс (yandex.ru) Для такого подключения мы поднимем ещё один влан на msk-arbat-gw1. Его номер, разумеется, согласуется с провайдером. Пусть это будет VLAN 6
Предположим, провайдер предоставляет нам подсеть 198.51.100.0/28. Первые два адреса используются для организации линка (198.51.100.1 и 198.51.100.2), а оставшиеся мы используем, как пул для NAT’a. Впрочем, никто совершенно нам не мешает использовать и адрес 198.51.100.2 для пула. Так и сделаем: пул: 198.51.100.2-198.51.100.14
Для простоты предположим, что публичные сервера у нас находятся в одной подсети:
192.0.2.0/24.
Как настроить линк и адреса вы вполне уже в курсе.
Поскольку у нас только один маршрутизатор в сети провайдера, и все сети подключены непосредственно к нему, то необходимости настраивать маршрутизацию нету.
А вот наш msk-arbat-gw1 должен знать куда отправлять пакеты в Интернет, поэтому нам нужен маршрут по умолчанию:

Теперь по порядку
Во первых настроим пул адресов

Теперь собираем ACL:

1) Сеть управления

не имеет доступа в интернет вообще
Готово

Источник