Практика
Давайте сразу к практике. Что бы нам такого наограничивать в нашей маленькой сети “Лифт ми Ап”?
WEB-сервер. Разрешить доступ всем по порту TCP 80 (протокол HTTP). Для того устройства, с которого будет производиться управление (у нас же есть админ) нужно открыть telnet и ftp, но ему мы дадим полный доступ. Всем остальным отбой
Файловый сервер. На него у нас должны попадать резиденты Лифт ми Ап по портам для общих папок, а все остальные по FTP.
Почтовый сервер. Тут у нас запущены SMTP и POP3, то есть порты TCP 25 и 110. Так же для админа открываем доступ на управление. Других блокируем
Для будущего DNS-сервера нужно открыть порт UDP 53
В сеть серверов разрешить ICMP-сообщения
Поскольку сеть Other у нас для всех беспартийных, кто не вошёл в ФЭО, ПТО и Бухгалтерию, то мы их всех ограничим, а некоторым только дадим доступ (в числе них мы и админ)
В сеть управления нужно пускать опять же только админа, ну и конечно себя любимого
Не будем строить препоны общению между собой сотрудников отделов
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
Разрешаем (permit) TCP-трафик от любого узла (any) на хост (host — именно один адрес) 172.16.0.2, адресованный на 80-й порт. Пробуем повесить этот список доступа на интерфейс FE0/0.3:
И так с любого другого узла?
Дело в том, что после всех правил в цисковских ACL в конце дописывается неявное deny ip any any (implicit deny). Что для нас это означает? Любой пакет, выходящий с интерфейса и не отвечающий ни одному правилу из ACL, подпадает под implicit deny и отбрасывается. То есть хоть пинг, хоть фтп, хоть что угодно здесь уже не пройдёт.
Идём дальше: надо дать полный доступ компьютеру, с которого будет производиться управление. Это будет компьютер нашего админа с адресом 172.16.6.66 из сети Other. Каждое новое правило добавляется автоматически в конец списка, если он уже существует:
То есть 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) Более никаких ограничений
Готово
Last updated
