Access Control List
Last updated
Last updated
Итак, что мы имеем сказать по спискам доступа? Вообще-то тема относительно простая и только ленивыми из курса 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 рекомендуется ставить как можно ближе к получателю (чтобы не порезать больше, чем нужно), а расширенные- ближе к отправителю (чтобы как можно раньше дропнуть нежелательный трафик).
До сих пор мы без объяснения давали странный параметр вида 0.0.255.255, подозрительно напоминающий маску подсети. Немного сложная для понимания, но именно она — обратная маска — используется для определения хостов, которые подпадут под правило. Чтобы понять что такое обратная маска, вы должны знать, что такое обычная.Начнём с самого простого примера.
Обычная сеть на 256 адресов: 172.16.5.0/24, например. Что означает эта запись? А означает она ровно следующее
IP-адрес. Десятичная запись
172
16
5
0
IP-адрес. Двоичная запись
10101100
00010000
00000101
00000000
Маска подсети. Двоичная запись
11111111
11111111
11111111
00000000
Маска подсети. Десятичная запись
255
255
255
0
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. Распишем это так:
IP-адрес. Десятичная запись
172
16
2
4
IP-адрес. Двоичная запись
10101100
00010000
00000010
00000100
Маска подсети. Двоичная запись
11111111
11111111
11111111
11111100
Маска подсети. Десятичная запись
255
255
255
252
Как видите, для этой подсети могут меняться только последние два бита. Последний октет может принимать следующие 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 нулей и две единицы:
Обратная маска. Двоичная запись
00000000
00000000
00000000
00000011
Обратная маска. Десятичная запись
0
0
0
3
Соответственно параметр в access-листе будет выглядеть так: …. 172.16.2.4 0.0.0.3 Позже, когда вы съедите собаку на просчётах масок и обратных масок, вы запомните самые употребляемые цифры, количество хостов в той или иной маске, поймёте, что в описанных ситуациях последний октет обратной маски получается вычитанием из 255 цифры последнего октета обычной маски (255-252=3) и т.д. А пока нужно много трудиться и считать)
Но на самом деле обратная маска — это несколько более богатый инструмент, здесь вы можете объединять адреса внутри одной подсети или даже объединять подсети, но самое главное отличие, вы можете чередовать нули и единицы. Это позволяет вам, например, отфильтровать определённый узел (или группу) в нескольких подсетях одной строкой.
Дано: сеть 172.16.16.0/24 Надо: отфильтровать первые 64 адреса (172.16.16.0-172.16.16.63) Решение: 172.16.16.0 0.0.0.63
Дано: сети 172.16.16.0/24 и 172.16.17.0/24 Надо: отфильтровать адреса из обеих сетей Решение: 172.16.16.0 0.0.1.255
Дано: Сети 172.16.0.0-172.16.255.0 Надо: отфильтровать хост с адресом 4 из всех подсетей Решение: 172.16.0.4 0.0.255.0
Признаться ни разу в жизни не приходилось встречаться с последним сценарием применения. Это какие-то жутко специфические должны быть задачи. Более подробно об обратных масках можно прочитать тут: http://habrahabr.ru/post/131712/
Гипотетическая сеть:
1) На маршрутизаторе RT1 на интерфейсе FE0/1 на вход у нас разрешено всё, кроме ICMP.
2) На маршрутизаторе RT2 на интерфейсе FE0/1 на выход запрещены SSH и TELNET
1) Правила, действующие на исходящий трафик (out) не будут фильтровать трафик самого устройства. То есть, если нужно запретить самой циске доступ куда-либо, то вам придётся на этом интерфейсе фильтровать входящий трафик (ответный оттуда, куда надо запретить доступ).
2) C ACL надо быть аккуратнее. При небольшой ошибке в правиле, неправильном порядке настройки или вообще плохо продуманном списке вы можете остаться без доступа к устройству. Например, вы хотите закрыть доступ куда угодно для сети 172.16.6.0/24, кроме своего адреса 172.16.6.61 и задаёте правила так:
Как только вы примените ACL на интерфейс, вы сразу потеряете доступ к маршрутизатору, потому что вы попадаете под первое правило и второе даже не проверяется. Вторая неприятная ситуация, которая может с вами приключиться: под ACL попадёт трафик, который не должен был попасть. Вообразите такую ситуацию: у нас в серверной есть FTP-сервер в пассивном режиме. Для доступа к нему вы открыли 21-й порт в ACL Servers-out. После первичного установления соединения FTP-сервер сообщает клиенту порт, по которому он готов передавать/принимать файлы, например, 1523-й. Клиент пытается установить TCP-соединение на этот порт, но натыкается на ACL Servers-out, где такого разрешения нету — так и кончается сказка про успешный трансфер. В нашем примере выше, где мы настраивали доступ на файловый сервер, мы открыли доступ только по 20 и 21-му, потому что для примера этого достаточно. В реальной жизни придётся повозиться. Немного примеров конфигурации ACL для распространенных случаев.
3) Из 2-го пункта вытекает очень похожая и интересная проблема. Вздумалось вам, например повесить на интерфейс в интернет такие вот ACL:
Казалось бы: хосту с адресом 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)
Тесты кликабельны 1) Пинг с компьютера ПК1 на Сервер1 2) TELNET с компьютера ПК1 на Сервер1 3) SSH с компьютера ПК1 на Сервер2 4) Пинг с Сервера2 на ПК1
