Зачем нужны списки контроля доступа
Перейти к содержимому

Зачем нужны списки контроля доступа

  • автор:

Access Control List — списки контроля доступа

Итак, пришло время задуматься о безопасности вашей сети. В частности о назначении прав на каталоги и файлы для пользователей и групп. Стандартные права в операционных системах Unix не так гибки, как хотелось бы. К сожалению они годятся для использования в простых схемах сети. Например, ситуацию когда к одному и тому же каталогу нужно, чтобы несколько групп пользователей имели разные права доступа, не реализовать с использованием стандартных прав.

Для реализации сложных структур прав доступа используются расширенные права — ACL (Access control list — cписки контроля доступа). Списки контроля доступом ( ACL ) дают большую гибкость, чем стандартный набор полномочий «пользователь/группа/остальные». ACL доступны в коммерческих Unix-системах, таких как IRIX или Solaris (и в Windows NT) в течение нескольких лет. В настоящее время, благодаря проекту TrustedBSD, ACL доступны в FreeBSD 5.0 и выше, а также в Linux. Возможность использования ACL позволяет администратору получить преимущество от использования более интеллектуальной модели безопасности.

Предполагается, что Вы уже знакомы со стандартными правами систем Unix. Если это не так, очень рекомендую сначала изучить документацию по ним. От того, насколько хорошо вы понимаете управление стандартными правами Unix, будет зависеть понимание материала этой статьи.

Устоявшиеся истины:

Каждый пользователь входит в минимум одну группу. Группа, присваиваемая пользователю при его создании, называется основной. Все остальные группы в которые будет включен пользователь, будут являться дополнительными. 1)

Группа пользователей может содержать некоторое количество пользователей, но не может содержать или включаться в другие группы.

Группа может быть пустой, т.е. не содержать в себе ни одного пользователя.

Чтобы добавить пользователя в ту, или иную группу, достаточно отредактировать файл /etc/group:

Хоть редактирование системных файлов вручную — самый быстрый способ их изменения, необходимо быть очень внимательным редактируя их. Используйте для редактирования файла /etc/group утилиту usermod, обязательно создавайте резервную копию редактируемого файла для возможности отката.

Примечание прислал Лихоманенко Артем 2013/04/23 15:55

syslog:x:103: klog:x:104: scanner:x:105:hplip,allexserv nvram:x:106: fuse:x:107:allexserv

Видно, что в листинге выше в группу scanner входят пользователи hplip и allexserv. Чтобы добавить в эту группу еще пользователей, просто перечислите их символьные имена через запятую.

Синтаксис файла прост:

имя_группы:пароль:GID:список_пользователей

Итак, основная мысль статьи — это использование расширенных прав ACL . 2)

Включение ACL в системе

С какой-то там версии Ubuntu, поддержка ACL уже включена и поддерживается ядром. 3) Но как бы то ни было, по умолчанию, в системе, ACL не активированы. Для того, чтобы операционная система начала учитывать списки контроля, необходимо ей об этом сказать. Для этого потребуется отредактировать файл /etc/fstab и указать в нем, на каких разделах HDD следует учитывать ACL права. Проверить, поддерживает ли тот или иной раздел винчестера ACL , можно попытавшись установить эти самые ACL , командой setfacl:

/root > setfacl -m u:allexserv:rw-,g:root:rw- qqq setfacl: qqq: Operation not supported

Operation not supported — операция не поддерживается — бодро рапортует вам система! Это признак того, что ACL на этом разделе винчестера, где лежит файл qqq не активированы. Что ж, давайте отредактируем /etc/fstab и приведем его в должный вид:

# /etc/fstab: static file system information. # #      proc /proc proc defaults 0 0 # /dev/sda1 UUID=1b09f304-1772-4a87-bc1c-ee8c6170ef1e / ext3 relatime,errors=remount-ro 0 1 # /dev/sda5 UUID=95b26917-535e-46ac-8d72-443d46184bb5 /media/Profil ext3 grpquota,acl,suid,dev,usrquota,relatime,exec 0 2 # /dev/sda6 UUID=759a8adb-ed01-4d4f-b173-9005ad165368 /media/Work ext3 grpquota,acl,suid,dev,usrquota,relatime,exec 0 2 # /dev/sda7 UUID=f90b3fb0-e515-4b4e-8a1b-dfe7ed269a10 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0 /media/Work/test /export/test bind bind 0

В тех разделах винчестера, в которых указан дополнительный параметр acl команды mountgrpquota,acl,suid — списки контроля будут поддерживаться в полном объеме. В моем случае поддержка ACL активирована на разделах /dev/sda5 и /dev/sda6.

После редактирования файла, лучше не мучаться и перезагрузить сервер, хотя, как утверждается в некоторых статьях, достаточно размонтировать раздел и смонтировать его вновь (такой номер у меня почему-то не прошел).

После вышеописанной операции, ACL на соответствующих разделах готовы к работе.

Утилиты ACL

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

Существуют два типа ACL :

ACL для доступа;
ACL по умолчанию.

ACL для доступа — это список управления доступом для заданного файла или каталога. Проще говоря — это сами права на объект, которые будут контролировать доступ к этому объекту.

ACL по умолчанию — может быть связан только с каталогом, и, если файл в этом каталоге не имеет ACL для доступа, он использует правила, определённые в ACL по умолчанию, связанном с каталогом. ACL по умолчанию являются необязательными. ACL по умолчанию также можно сравнить с наследованием прав в, простите, Windows NT.

Управления ACL списками осуществляется всего лишь двумя командами: 4)

setfacl — используется для назначения, модификации и удаления ACL прав.
getfacl — используется для просмотра установленных ACL .

Несколько слов о взаимодействии других команд (такие как копирование, перемещение, архивирование и т.п.) с правами ACL . Вот выдержка из статьи:

К сожалению, большинство Unix-утилит все еще не поддерживает ACL . Например, tar не архивирует и не восстанавливает ACL , в FreeBSD NFS также игнорирует их. Ни формат файлов в утилите tar, ни протокол NFS нет ни намека на возможность использования ACL . Тем не менее, архивы полного раздела UFS1, сделанные с помощью tar или dump, восстанавливают каталог .attribute, и утилита dump в FreeBSD модифицирована для «понимания» UFS2 (включающую ACL ). Каталог-скелет archivers/star поддерживает ACL . Вы даже можете работать с архивами, созданными в Linux и FreeBSD С помощью star и предохраняющей расширенные атрибуты (включающие и ACL ).

Но не все так грустно! Перевод статьи был написан в 2006 году (к сожалению до оригинала я так и не добрался). В другой же статье, более поздней, сказано:

Ядро Red Hat Enterprise Linux 4 обеспечивает поддержку ACL для файловой системы ext3 и экспортируемых файловых систем NFS. Списки ACL также работают в файловых системах ext3, доступных через Samba. … Команды cp и mv копируют и перемещают все списки ACL , связанные с файлами и каталогами.

Хоть большинство стандартных команд, призванных производить операции над файлами, уже поддерживают ACL то, например, команды архивирования tar и dump ACL не архивируют. Для архивации данных с установленными ACL используется программа star. В кратце ее рассмотрим позже. Замечу, что для NFS ACL поддерживаются уже по умолчанию. Вообще, успешное использование ACL зависит от поддержки ACL файловой системой и поддержки ACL операционной системой на клиентской машине.

Итак, рассмотрим синтаксис и параметры getfacl и setfacl.

Утилита getfacl

О getfacl сильно и говорить нечего. Она выводит листинг ACL прав для указанных объектов.

getfacl * — отобразит права ACL для всех объектов в текущем каталоге;
getfacl sobaka.txt — отобразить ACL для файла sobaka.txt;
getfacl kartosh* — отобразит ACL для всех файлов в текущем каталоге, которые начинаются на kartosh;

getfacl -R * — отобразит ACL для всех объектов (включая подкаталоги и их содержимое) текущего каталога.

Чтобы посмотреть, установлены ли ACL на объектах, достаточно воспользоваться командой ls -l:

# Символ "+" в конце списка стандартных прав сообщает о наличии установленных прав ACL: root@sytserver:/media/Work/test# ls -l итого 28 drwxrwxrwt 2 root root 4096 2009-07-24 21:20 allex -rwxr-x---+ 1 root root 19 2009-07-25 14:45 qwert

Теперь рассмотрим, что же отобразит команда getfacl:

root@sytserver:/media/Work/test# getfacl qwert # file: qwert # owner: root # group: root user::rwx user:child:rw- group::r-- mask::rw- other::---

Из примера видно, что без использования ACL , пользователь child не получил бы права к файлу qwert, т.к. не входит в группу root и не является владельцем файла. Права ACL , в данном случае, предоставили ему права на чтение и запись этого файла. Давайте подробнее разберем листинг getfacl:

# file: qwert - Имя файла # owner: root - Владелец файла (основные права Unix) # group: root - Группа файла (основные права Unix) user::rwx - Права для владельца файла (основные права Unix) user:child:rw- - Права ACL для пользователя child group::r-- - Права для группы файла (основные права Unix) mask::rw- - Эффективная маска other::--- - Права для пользователя "все остальные"

Что касается ключей getfacl, то есть пара из них которые стоит рассмотреть, но рассматривать их будем тогда, когда будем изучать setfacl.

Утилита setfacl

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

Списки ACL можно задать:

На уровне пользователей — назначаются ACL конкретным пользователям;
На уровне групп — назначаются ACL конкретным группам;
С помощью маски эффективных прав — ограничение максимальных прав для пользователей и/или групп;
Для пользователей, не включённых в группу данного файла — это т.н. пользователь «Все остальные»;

Рассмотрим простой синтаксис setfacl:

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

Часто используемые ключи:

--set или --set file*
-m или -M file*
-x или -X file*

* — При использовании -M, — -set, -X — разрешения будут браться из указанного файла file, который должен быть заранее подготовлен в формате вывода ACL разрешений командой getfacl. Подготовить файл можно либо вручную, в формате вывода getfacl, либо использовать команду getfacl -R file > file_out. Где file это файл(ы) или каталог(и) с которых нужно снять ACL , а file_out — текстовый файл куда запишутся снятые ACL права.

Часто используемые опции:

Опция Описание
-b — Удаляет все ACL права с объекта, сохраняя основные права;
-k — Удаляет с объекта ACL по умолчанию. Если таковых на объекте нет,
предупреждение об этом выдаваться не будет;
-d — Устанавливает ACL по умолчанию на объект.
–restore=file — Восстанавливает ACL права на объекты из ранее созданного файла с правами. 5)
-R — Рекурсивное назначение (удаление) прав, тобишь пройтись по всем подкаталогам.

Формирование списка правил:

setfacl -m u:allexserv:rw myfile.odt

— назначает пользователю allexserv права на чтение и запись.

setfacl -m g:children:r myfile.odt

— назначает группе children права на чтение.

setfacl -m m:rx myfile.odt

— устанавливает фактические максимальные права на чтение и выполнение.

setfacl -m o: myfile.odt

— убирает все права (отсутствие прав).

* — Сами правила для пользователя или группы. Могут принимать значения ( r ), ( x ), ( w ), или сочетания друг с другом.

Примеры использования

Рассмотрим различные примеры использования назначения, модификации и удаления ACL . Выше мы уже выводили листинг, при помощи команды getfacl для файла qwert, на котором уже установлены ACL для пользователя child:

root@sytserver:/media/Work/test# getfacl qwert # file: qwert # owner: root # group: root user::rwx user:child:rw- group::r-- mask::rw- other::---

Теперь давайте добавим к этому файлу еще пользователя allexserv:

root@sytserver:/media/Work/test# setfacl -m u:allexserv:rwx qwert root@sytserver:/media/Work/test# getfacl qwert # file: qwert # owner: root # group: root user::rwx user:allexserv:rwx user:child:rw- group::r-- mask::rwx other::---

Обратите внимание как изменилась эффективная маска. Все ACL права сложились: у пользователя child rw- и у пользователя allexserv rwx. Но маска вовсе не разрешает пользователю child иметь право на выполнение (x) файла qwert. Посмотрите, что произойдет если принудительно изменить эффективную маску:

root@sytserver:/media/Work/test# setfacl -m m:r qwert root@sytserver:/media/Work/test# getfacl qwert # file: qwert # owner: root # group: root user::rwx user:allexserv:rwx #effective:r-- user:child:rw- #effective:r-- group::r-- mask::r-- other::---

Теоретически, в данном случае пользователь child не может удалить файл (про allexserv ничего не говорю, т.к. он входит в группу root у меня). Но проведя тест, пользователь child все-таки удалил файл, правда перед удалением система спросила:

child@sytserver:/media/Work/test$ rm qwert rm: удалить защищенный от записи обычный файл `qwert'?

В то же время попробовал отредактировать файл qwert под пользователем child и попытался записать изменения. Система в записи отказала. Здесь стоит отметить, что удаление файла регламентируется правами на каталог в коем расположен этот файл. Причина такого поведения именно в этом.

Теперь давайте удалим с файла qwert права ACL для пользователя allexserv:

root@sytserver:/media/Work/test# setfacl -x u:allexserv qwert root@sytserver:/media/Work/test# getfacl qwert # file: qwert # owner: root # group: root user::rwx user:child:rw- #effective:r-- group::r-- mask::r-- other::---

Чтобы удалить все ACL права с файла можно воспользоваться командой: setfacl -b qwert

Очевидно, что таким макаром можно назначать и удалять ACL права для пользователей и групп на файлы и каталоги.

Давайте еще рассмотрим т.н. наследованность прав. Если не задано иное, то все объекты создаваемые в каталоге у которого есть ACL , не наследуют права ACL c каталога в котором они создаются. Но иногда возникают ситуации, когда необходимо, чтобы все объекты создаваемые внутри каталога наследовали его ACL права. Это называются ACL по умолчанию.

Задача: создадим каталог Proverka и назначим ему владельца child и группу children (разумеется, пользователь и группа должны существовать в системе). Установим ACL права для пользователя allexserv и пользователя mysql. Установим ACL по умолчанию на каталог Proverka так, чтобы создаваемым объектам внутри него также назначались ACL .

Создаем каталог, устанавливаем права и владельца:

root@sytserver:/media/Work/test# mkdir Proverka root@sytserver:/media/Work/test# chmod 700 Proverka root@sytserver:/media/Work/test# chown child:children Proverka root@sytserver:/media/Work/test# ls -l итого 24 drwxrwxrwt 2 root root 4096 2009-07-24 21:20 allex drwx------ 2 child children 4096 2009-07-25 23:36 Proverka

Назначаем ACL права сразу для двух пользователей, перечислив их через запятую:

root@sytserver:/media/Work/test# setfacl -m u:allexserv:rwx,u:mysql:rwx Proverka root@sytserver:/media/Work/test# getfacl Proverka # file: Proverka # owner: child # group: children user::rwx user:mysql:rwx user:allexserv:rwx group::--- mask::rwx other::---

Теперь назначим ACL по умолчанию. При назначении ACL по умолчанию, также требуется в обязательном порядке указывать и основные права в виде u::rwx,g::-,o::- где uuser — владелец, ggroup — группа, oother — все остальные:

root@sytserver:/media/Work/test# setfacl -d -m u::rwx,g::-,o::-,u:allexserv:rwx,u:mysql:rwx Proverka root@sytserver:/media/Work/test# getfacl Proverka # file: Proverka # owner: child # group: children user::rwx user:mysql:rwx user:allexserv:rwx group::--- mask::rwx other::--- default:user::rwx default:user:mysql:rwx default:user:allexserv:rwx default:group::--- default:mask::rwx default:other::---

Видно, что появились строки начинающиеся с default. Это и есть права по умолчанию, которые будут принимать все создаваемые внутри объекты. Проверим, создав пустой файл myfile.txt и подкаталог MyKatalog в каталоге Proverka:

root@sytserver:/media/Work/test/Proverka# touch myfile.txt root@sytserver:/media/Work/test/Proverka# mkdir MyKatalog root@sytserver:/media/Work/test/Proverka# getfacl * # file: myfile.txt # owner: root # group: root user::rw- user:mysql:rwx #effective:rw- user:allexserv:rwx #effective:rw- group::--- mask::rw- other::--- # file: MyKatalog # owner: root # group: root user::rwx user:mysql:rwx user:allexserv:rwx group::--- mask::rwx other::--- default:user::rwx default:user:mysql:rwx default:user:allexserv:rwx default:group::--- default:mask::rwx default:other::---

Обратите внимание, что каталог MyKatalog не только приобрел ACL , но и также приобрел и ACL по умолчанию. Т.е. те объекты, которые будут создаваться в подкаталоге MyKatalog тоже будут наследовать ACL по умолчанию.

Удалить права по умолчанию можно: setfacl -k Proverka.

Если нужно также удалить права по умолчанию и в подкаталогах, то добавьте ключ -R (рекурсия): setfacl -R -k /media/Work/test/Proverka .

Здесь мы оперировали двумя пользователями. Но ничто не мешает вам оперировать также целыми группами пользователей.

Автоматические операции

Любой администратор стремится к оптимизации. Понятно, что назначить вручную 100 объектам одни и те же права — нудное занятие и нецелесообразное. Есть некоторые фишечки, которые могут облегчить подобные задачи.

Копирование ACL прав с одного объекта на другой.

Снять ACL c одного объекта
Записать их на другой

В документации приведен следующий пример:

getfacl file1 | setfacl --set-file=- file2

Где, file1 — объект с которого снимаем ACL командой getfacl, а далее устанавливаем ACL командой setfacl на объект file2. Обратите внимание на запись — -set-file=- в конце указан символ «-», который берет информацию от команды getfacl (со стандартного вывода).

Справедлива будет также такая запись:

getfacl file1 | setfacl -M- file2

В этом случае права на file2 не заменяются как при использовании — -set, а добавляются к уже существующим правам ACL .

Копирование прав ACL каталога в права по умолчанию этого же каталога
getfacl --access dir | setfacl -d -M- dir

В этом примере getfacl получает все права которые вы установили на каталог dir и устанавливает их на этот же каталог dir делая их правами по умолчанию. Очень удобно. Обратите внимание на ключ — -access у команды getfacl. При вызове getfacl без параметров, она отображает все права ACL , включая права по умолчанию. Здесь же, ключ — -access заставляет getfacl показать только права ACL на каталог, а права по умолчанию (если таковые имеются у каталога) — скрыть. Обратный ключ — это ключ -d:

getfacl -d Proverka

— заставит getfacl показать только права по умолчанию, а права ACL на сам каталог — скрыть. Кстати, в нашем примере, с каталогом Proverka, на который мы назначали права по умолчанию, чтобы не писать строку:

setfacl -d -m u::rwx,g::-,o::-,u:allexserv:rwx,u:mysql:rwx Proverka

можно было бы воспользоваться именно этой фишечкой, как то так:

getfacl --access Proverka | setfacl -d -M- Proverka

Результат был бы тот же.

Вот и все, а вообще, не поленитесь почитать man getfacl, очень занимательно!

Операции над объектами c ACL

В заключении хочу еще раз обратить внимание на операции с обектами у которых установлены ACL , такие как копирование, перемещение, архивирование. Выше мы уже упоминали о них. Некоторые замечания:

При перемещении (mv) никаких дополнительных параметров ненужно;
При копировании (cp), необходимо использовать ключ -p, в противном случае ACL права будут потеряны;
Внимание.
По умолчанию графический интерфейс при копировании не учитывает ACL права!
При архивировании или распаковке вместо tar используйте утилиту star.

Утилиту star нужно будет установить из репозиториев: apt-get install star

Вот некоторые часто используемые опции star:

Опция Описание
-c Создаёт файл архива
-n Отключает извлечение файлов, используется в сочетании с -x для просмотра списка извлекаемых файлов.
-r Заменяет файлы в архиве. Файлы записываются в конец архива, заменяя любые файлы с тем же путём и именем.
-t Выводит содержимое файла архива.
-u Обновляет файл архива. Файлы записываются в конец архива, если их ещё не было в архиве или если они новее, чем файлы с тем же именем в архиве. 7)
-x Извлекает файлы из архива. Если используется с ключом -U и файл в архиве старее, чем соответствующий файл в файловой системе, такой файл не извлекается.
-help Выводит наиболее важные параметры.
-xhelp Выводит менее важные параметры.
-/ Оставляет ведущую косую черту в имени файла при извлечении файлов из архива. По умолчанию она убирается.
-acl При создании архива или извлечении файлов, архивирует или восстанавливает все ACL , связанные с файлами или каталогами.

Пример для архивирования утилитой star с сжатием:

star -czv -Hexustar -acl -f /tmp/homedir.tgz /media/Profil/home

Пример для разархивирования в текущий каталог:

star -xv -Hexustar -acl -f homedir.tgz

Вот собственно и все, что я хотел рассказать про ACL . Применяйте логику и смекалку и все будет хорошо.

Наличие дополнительных групп может также облегчить написание правил монтирования ресурсов при входе в систему, например, с использованием модуля pam_mount. Почитать можно здесь.

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

Обратите внимание, что в других операционных системах Unix, например, FreeBSD 5.0 и выше, потребуются некоторые дополнительные действия по включению ACL . Также, возможно, вам потребуется установить пакет acl, использовав следующую команду: sudo apt-get install acl.

Помимо консольных команд, есть также графическая оболочка для установки ACL прав. Приблуда называется eiciel, ее описание можно найти, например, здесь. По-моему, по умолчанию приблуда не ставится в системе, так что ставить ее придется из репозиториев. Ввиду того, что эта статья ориентирована на системных администраторов, рассмотрения графической утилиты здесь не состоится.

Полезно для отката разрешений. Разумеется, необходимо сначала сделать резервную копию разрешений в текстовый файл file. Сделать можно либо вручную, в формате вывода getfacl, либо использовать команду getfacl -R file > file_out. Где file это файл(ы) или каталоги с которых нужно снять ACL , а file_out — текстовый файл куда запишутся снятые ACL права.

Маска — это объединение всех разрешений группы-владельца и всех записей пользователей и групп. Маска задает максимальные права доступа для всех пользователей, за исключением хозяина и групп. Установка маски представляет собой самый быстрый путь изменить фактические (эффективные) права доступа всех пользователей и групп. Например, маска (r — -) показывает, что пользователи и группы не могут иметь больших прав, чем просто чтение, даже если им назначены права доступа на чтение и запись. Например, если на файл koshka назначили ACL пользователю allexserv c правами (r w x), а эффективную маску выставили в (r x), то пользователь лишается права (w), не смотря на то, что по ACL он имеет это право.

Этот параметр работает только если архив представляет собой файл или незаблокированную ленту, которую можно стирать.

  • Сайт
  • Об Ubuntu
  • Скачать Ubuntu
  • Семейство Ubuntu
  • Новости
  • Форум
  • Помощь
  • Правила
  • Документация
  • Пользовательская документация
  • Официальная документация
  • Семейство Ubuntu
  • Материалы для загрузки
  • Совместимость с оборудованием
  • RSS лента
  • Сообщество
  • Наши проекты
  • Местные сообщества
  • Перевод Ubuntu
  • Тестирование
  • RSS лента

© 2018 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.

Что такое 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:

access-list 1 permit 192.168.1.0

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

Типы ACL

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

access-list 1 permit host 192.168.10.50 access-list 1 permit host 192.168.10.53 access-list 1 permit host 192.168.10.60

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

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

  1. Адрес отправителя
  2. Адрес получателя
  3. TCP/UDP порт отправителя
  4. TCP/UDP порт получателя
  5. Протоколу, завёрнутому в ip (отфильтровать только tcp, только udp, только icmp, только gre и т.п.)
  6. Типу трафика для данного протокола (например, для icmp отфильтровать только icmp-reply).
  7. Отделить TCP трафик, идущий в рамках установленной TCP сессии от TCP сегментов, которые только устанавливают соединение. Подробнее об этом можно прочитать в статье «Что делает established в ACL»
  8. И др.

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

  • Dynamic ACL — ACL, в котором некоторые строчки до поры до времени не работают, но когда администратор подключается к маршрутизатору по telnet-у, эти строчки включаются, то есть администратор может оставить для себя «дыру» в безопасности для отладки или выхода в сеть.
  • Reflexive ACL — зеркальные списки контроля доступа, позволяют запоминать, кто обращался из нашей сети наружу (с каких адресов, с каких портов, на какие адреса, на какие порты) и автоматически формировать зеркальный ACL, который будет пропускать обратный трафик извне вовнутрь только в том случае, если изнутри было обращение к данному ресурсу. Подробнее об этом можно прочесть в статье «Reflexive ACL — настройка и пример работы зеркальных списков контроля доступа»
  • TimeBased ACL, как видно из названия, это ACL, у которых некоторые строчки срабатывают только в какое-то время. Например, с помощью таких ACL легко настроить, чтобы в офисе доступ в интернет был только в рабочее время.

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

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

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

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

access-list 1 permit host 192.168.1.1 access-list 1 deny 192.168.1.0 access-list 1 permit any

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

  • Если пакет пришёл с адреса 192.168.1.1, то его надо сразу же пропустить и не делать больше никаких проверок в этом ACL;
  • В противном случае, если пакет пришел из сети 192.168.1.0 (кроме адреса 192.168.1.1, с которым мы уже разобрались строчкой выше), то пакет надо уничтожить и опять же, на этом закончить просмотр ACL, не переходить к следующему шагу;
  • Если пакет не попал под первые два правила. То есть он не с адреса 192.168.1.1, да и вообще, не из сети 192.168.1.0, то он всегда попадает под правило permit any, то есть, пакет надо пропустить дальше — пусть идёт.

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

access-list 1 permit any access-list 1 deny 192.168.1.0 access-list 1 permit host 192.168.1.1

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

  • Проверяем первую строчку, если пакет из любой сети (any) то его надо пропустить и просмотр дальше прекратить.

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

Применение ACL

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

R1# R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interface FastEthernet0/0 R1(config-if)#ip access-group MY_ACLS_NAME in

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

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

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

Где лучше применять ACL? Вопрос, на самом деле, не тривиальный и студенты без должного опыта часто дают на него неправильный ответ. Рассмотрим пример: Дана топология, надо запретить доступ с компьютера в сеть ноутбука двумя способами по очереди (сначала с помощью стандартного, затем с помощью расширенного 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 на входящем направлении и блокируете избыточные виды трафика.

Теория

image

Функционал ACL состоит в классификации трафика, нужно его проверить сначала, а потом что-то с ним сделать в зависимости от того, куда ACL применяется. ACL применяется везде, например:

  • На интерфейсе: пакетная фильтрация
  • На линии Telnet: ограничения доступа к маршрутизатору
  • VPN: какой трафик нужно шифровать
  • QoS: какой трафик обрабатывать приоритетнее
  • NAT: какие адреса транслировать

Для применения ACL для всех этих компонентов нужно понять как они работают. И мы в первую очередь будем касаться пакетной фильтрации. Применительно к пакетной фильтрации, ACL размещаются на интерфейсах, сами они создаются независимо, а уже потом они прикручиваются к интерфейсу. Как только вы его прикрутили к интерфейсу маршрутизатор начинает просматривать трафик. Маршрутизатор рассматривает трафик как входящий и исходящий. Тот трафик, который входит в маршрутизатор называется входящим, тот который из него выходит — исходящий. Соответственно ACL размещаются на входящем или на исходящем направлении.

Из вашей частной сети приходит пакет на интерфейс маршрутизатора fa0/1, маршрутизатор проверяет есть ли ACL на интерфейсе или нет, если он есть, то дальше обработка ведется по правилам списка доступа строго в том порядке, в котором записаны выражения, если список доступа разрешает проходить пакету, то в данном случае маршрутизатор отправляет пакет провайдеру через интерфейс fa0/0, если список доступа не разрешает проходить пакету, пакет уничтожается. Если списка доступа нет — пакет пролетает без всяких ограничений. Перед тем как отправить пакет провайдеру, маршрутизатор ещё проверяет интерфейс fa0/0 на наличие исходящего ACL. Дело в том, что ACL может быть прикреплен на интерфейсе как входящий или исходящий. К примеру у нас есть ACL с правилом запретить всем узлам в Интернете посылать в нашу сеть пакеты.
Так на какой интерфейс прикрепить данную ACL? Если мы прикрепим ACL на интерфейс fa0/1 как исходящий, это будет не совсем верно, хотя и ACL работать будет. На маршрутизатор приходит эхо-запрос для какого-то узла в частной сети, он проверяет на интерфейсе fa0/0 есть ли ACL, его нет, дальше проверяет интерфейс fa0/1, на данном интерфейсе есть ACL, он настроен как исходящий, всё верно пакет не проникает в сеть, а уничтожается маршрутизатором. Но если мы прикрепим ACL за интерфейсом fa0/0 как входящий, то пакет будет уничтожатся сразу как пришел на маршрутизатор. Последнее решение является правильным, так как маршрутизатор меньше нагружает свои вычислительные ресурсы. Расширенные ACL нужно размещать как можно ближе к источнику, стандартные же как можно ближе к получателю. Это нужно для того, чтобы не гонять пакеты по всей сети зря.

Сам же ACL представляет собой набор текстовых выражений, в которых написано permit (разрешить) либо deny (запретить), и обработка ведется строго в том порядке в котором заданы выражения. Соответственно когда пакет попадает на интерфейс он проверяется на первое условие, если первое условие совпадает с пакетом, дальнейшая его обработка прекращается. Пакет либо перейдет дальше, либо уничтожится.
Ещё раз, если пакет совпал с условием, дальше он не обрабатывается. Если первое условие не совпало, идет обработка второго условия, если оно совпало, обработка прекращается, если нет, идет обработка третьего условия и так дальше пока не проверятся все условия, если никакое из условий не совпадает, пакет просто уничтожается. Помните, в каждом конце списка стоит неявный deny any (запретить весь трафик). Будьте очень внимательны с этими правилами, которые я выделил, потому что очень часто происходят ошибки при конфигурации.

  • Стандартные (Standard): могут проверять только адреса источников
  • Расширенные (Extended): могут проверять адреса источников, а также адреса получателей, в случае IP ещё тип протокола и TCP/UDP порты
  • Стандартные: от 1 до 99
  • Расширенные: от 100 до 199
Виды 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-доступ открывается,
пожалуйста, если хотите — сидите в Интернете.

Настройка
  • Обработка ведется строго в том порядке, в котором записаны условия
  • Если пакет совпал с условием, дальше он не обрабатывается
  • В конце каждого списка доступа стоит неявный deny any (запретить всё)
  • Расширенные ACL нужно размещать как можно ближе к источнику, стандартные же как можно ближе к получателю
  • Нельзя разместить более 1 списка доступа на интерфейс, на протокол, на направление
  • ACL не действует на трафик, сгенерированный самим маршрутизатором
  • Для фильтрации адресов используется WildCard маска
Стандартный список доступа
  • permit: разрешить
  • deny: запретить
  • remark: комментарий о списке доступа
  • address: запрещаем или разрешаем сеть
  • any: разрешаем или запрещаем всё
  • host: разрешаем или запрещаем хосту
  • source-wildcard: WildCard маска сети
  • log: включаем логгирование пакеты проходящие через данную запись ACL
Расширенный список доступа
  • protocol source: какой протокол будем разрешать или закрывать (ICMP, TCP, UDP, IP, OSPF и т.д)
  • deny: запретить
  • operator:
    A.B.C.D — адрес получателя
    any — любой конечный хост
    eq — только пакеты на этом порте
    gt — только пакеты с большим номером порта
    host — единственный конечный хост
    lt — только пакеты с более низким номером порта
    neq — только пакеты не на данном номере порта
    range — диапазон портов
  • port: номер порта (TCP или UDP), можно указать имя
  • established: разрешаем прохождение TCP-сегментов, которые являются частью уже созданной TCP-сессии
Прикрепляем к интерфейсу
  • in: входящее направление
  • out: исходящее направление
Именованные списки доступа
  • standard: стандартный ACL
  • extended: расширенный ACL
  • default: установить команду в значение по умолчанию
Ограничение доступа к маршрутизатору

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.

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

Объектное хранилище S3 позволяет управлять доступом к бакетам и объектам с помощью списков контроля доступа ACL (Access control list). ACL определяет, каким учетным записям или группам хранилища предоставляется доступ к ресурсам, а также тип этого доступа. При получении запроса к ресурсу объектное хранилище S3 проверяет соответствующий ACL, чтобы убедиться, что запрашивающая сторона имеет необходимые разрешения.

Для каждого нового объекта или бакета в хранилище создается пустой ACL. По умолчанию создаваемый бакет и объект максимально ограничены в доступе — только владелец бакета / объекта может иметь доступ к нему и работать с ним. ACL позволяет изменить это поведение.

Управлять ACL может только пользователь с соответствующими правами (например, владелец бакета). Загрузить ACL и получить список существующих ACL можно только через S3 API.

Виды разрешений ACL

В таблице ниже перечислены все доступные ACL с указанием уровней доступа к объекту или бакету.

Как влияет на бакет

Как влияет на объект

Разрешение на чтение всех объектов в бакете

Разрешение на чтение объектов и его метаданных

Разрешение создавать новые объекты в бакете Владельцу бакета и объекта разрешает удаление или перезапись этих объектов.

Разрешение на чтение ACL бакета

Разрешение на чтение ACL объекта

Разрешение на запись ACL для бакета

Разрешение на запись ACL для объекта

Разрешения READ , WRITE , READ_ACP и WRITE_ACP для бакета

Разрешения READ , READ_ACP и WRITE_ACP для объекта

Если в ACL указать доступ WRITE , но при этом не указать READ , то хранилище ответит с кодом 501 Not Implemented .

Пример ACL

В этом примере ACL для бакета определяет владельца ресурса и набор разрешений:

  access-key-name    access-key-name  FULL_CONTROL    

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *