Материал: lab1

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 рекомендуется ставить как можно ближе к получателю (чтобы не порезать больше, чем нужно), а расширенные- ближе к отправителю (чтобы как можно раньше дропнуть нежелательный трафик).

Практика

Давайте сразу к практике. Что бы нам такого наограничивать в нашей маленькой сети “Лифт ми Ап”? а) WEB-сервер. Разрешить доступ всем по порту TCP 80 (протокол HTTP). Для того устройства, с которого будет производиться управление (у нас же есть админ) нужно открыть telnet и ftp, но ему мы дадим полный доступ. Всем остальным отбой. б) Файловый сервер. На него у нас должны попадать резиденты Лифт ми Ап по портам для общих папок, а все остальные по FTP. в) Почтовый сервер. Тут у нас запущены SMTP и POP3, то есть порты TCP 25 и 110. Так же для админа открываем доступ на управление. Других блокируем. г) Для будущего DNS-сервера нужно открыть порт UDP 53 д) В сеть серверов разрешить ICMP-сообщения е) Поскольку сеть Other у нас для всех беспартийных, кто не вошёл в ФЭО, ПТО и Бухгалтерию, то мы их всех ограничим, а некоторым только дадим доступ (в числе них мы и админ) ё) В сеть управления нужно пускать опять же только админа, ну и конечно себя любимого. ж) Не будем строить препоны общению между собой сотрудников отделов.

А) Доступ на 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

msk-arbat-gw1(config)# ip access-list extended Servers-out msk-arbat-gw1(config-ext-nacl)# remark WEB msk-arbat-gw1(config-ext-nacl)# permit tcp any host 172.16.0.2 eq 80

Разрешаем (permit) TCP-трафик от любого узла (any) на хост (host — именно один адрес) 172.16.0.2, адресованный на 80-й порт. Пробуем повесить этот список доступа на интерфейс FE0/0.3:

msk-arbat-gw1(config)# int fa0/0.3 msk-arbat-gw1(config-subif)# ip access-group Servers-out out

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

msk-arbat-gw1(config)# ip access-list extended Servers-out msk-arbat-gw1(config-ext-nacl)# permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp msk-arbat-gw1(config-ext-nacl)# permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet

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

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

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

msk-arbat-gw1(config)# ip access-list extended Servers-out msk-arbat-gw1(config-ext-nacl)# permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445 msk-arbat-gw1(config-ext-nacl)# permit tcp any host 172.16.0.3 range 20 21

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

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

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

msk-arbat-gw1(config)# ip access-list extended Servers-out msk-arbat-gw1(config-ext-nacl)#permit tcp any host 172.16.0.4 eq pop3 msk-arbat-gw1(config-ext-nacl)#permit tcp any host 172.16.0.4 eq smtp

г) DNS-сервер

msk-arbat-gw1(config)# ip access-list extended Servers-out msk-arbat-gw1(config-ext-nacl)# permit udp 172.16.0.0 0.0.255.255 host 172.16.0.5 eq 53

д) ICMP

Осталось исправить ситуацию с пингом. Ничего страшного нет в том, чтобы добавить правила в конец списка, но как-то эстетически приятнее будет увидеть их вначале. Используем несложный чит для этого. Для это можно воспользоваться текстовым редактором, например. Скопируйте туда из show run кусок про ACL и добавьте следующие строки: no ip access-list extended Servers-out ip access-list extended Servers-out permit icmp any any remark WEB permit tcp any host 172.16.0.2 eq www permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet remark FILE permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445 permit tcp any host 172.16.0.3 range 20 21 remark MAIL permit tcp any host 172.16.0.4 eq pop3 permit tcp any host 172.16.0.4 eq smtp remark DNS permit udp 172.16.0.0 0.0.255.255 host 172.16.0.5 eq 53 Первой строкой мы удаляем существующий список, далее создаём его заново и перечисляем все новые правила в нужном нам порядке. Командой в третьей строке мы разрешили проход всех ICMP-пакетов от любых хостов на любые хосты. Далее просто копируем всё скопом и вставляем в консоль. Интерфейс интерпретирует каждую строку как отдельную команду и выполняет её. Таким образом, мы заменили старый список новым. Проверяем, что пинг есть: Прекрасно. Данный “чит” хорош для первоначальной конфигурации или если вы точно понимаете, что делаете. На рабочей сети, когда вы настраиваете удалённо ACL, вы рискуете остаться без доступа на настраиваемую железку.

Чтобы вставить правило в начало или в любое другое нужное место, вы можете прибегнуть к такому приёму: ip access-list extended Servers-out 1 permit icmp any any Каждое правило в списке пронумеровано с определённым шагом и если перед словом permit/deny вы поставите число, то правило будет добавлено не в конец, а в нужное вам место. К сожалению, такая фича не работает в РТ. Если будет вдруг необходимо (заняты все подряд идущие числа между правилами) вы всегда можете перенумеровать правила (в этом примере назначается номер первого правила 10(первое число) и инкремент 10): ip access-list resequence Servers-out 10 10

В итоге Access List на серверную сеть будет выглядеть так: ip access-list extended Servers-out permit icmp any any remark WEB permit tcp any host 172.16.0.2 eq www permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet remark FILE permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445 permit tcp any host 172.16.0.3 range 20 21 remark MAIL permit tcp any host 172.16.0.4 eq pop3 permit tcp any host 172.16.0.4 eq smtp remark DNS permit udp 172.16.0.0 0.0.255.255 host 172.16.0.5 eq 53 Сейчас наш админ имеет доступ только на WEB-сервер. Откройте ему полный доступ на всю сеть. Это первое домашнее задание.