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
