Итак, продолжаем разбираться с ACL. На сей раз, у нас расширенные ACL. Топологию возьмём от предыдущей статьи, надеюсь, вы её изучили досконально. Если это не так, то очень рекомендую прочесть, чтобы материалы этой статьи были более понятными.
Прежде всего начну с того, что такое расширенные ACL. Расширенные ACL позволяют помимо адреса источника указать протокол, адрес назначения и порты. А так же особые параметры определённого протокола. Лучше всего учиться на примерах, поэтому сформируем новую задачу, усложнив предыдущую. Кстати, кому-то может интересно будет после этого заняться вопросами распределения трафика по приоритетам, советую вот QoS Classification and Marking хорошую статью, правда на английском. Ну а пока, вернемся к нашей задаче:
Задача.
- Разрешить echo-запросы с узлов сети 192.168.0.0/24 на сервер.
- С сервера – запретить echo-запросы во внутреннюю сеть.
- Разрешить WEB-доступ на сервер с узла 192.168.0.11.
- Разрешить FTP доступ с узла 192.168.0.13 на сервер.
Комплексная задача. Решать её будем тоже комплексно. Прежде всего разберу синтаксис применения расширенного ACL.
Параметры расширенного ACL
<номер от 100 до 199> <действие permit, deny> <протокол> <источник> <порт> <назначение> <порт> <опции>
Номера портов указываются только у протоколов TCP / UDP, разумеется. Так же могу иметь место приставочки eq (номер порта равный указанному), gt / lt (номер порта больше/меньше указанного), neq (номер порта не равен указанному), range (диапазон портов).
Именованные ACL
Кстати, списки доступа можно не только нумеровать, но и именовать! Возможно этот способ покажется вам более удобным. В этот раз сделаем именно так. Эти команды выполняются в контексте глобального конфигурирования и синтаксис выглядит так:
Router(config)#ip access-list extended <имя>
Итак, начинаем формировать правила.
- Разрешаем пинги с сети 192.168.0.0/24 на сервер. Итак, echo-запросы – это протокол ICMP, в качестве адреса источника выберем нашу подсеть, адресом назначения – адрес сервера, тип сообщения – на входящем интерфейсе echo, на выходе – echo-reply.
Router(config)#ip access-list extended INT_INRouter(config)#int fa0/0Ну как-то так. Теперь, если проверить пинги – легко заметить, что всё отлично работает. Тут, правда нас ждёт один сюрприз, который всплывёт чуть позже. Пока не буду раскрывать. Кто догадался – молодец!
Router(config-if)#ip access-group INT_IN in
- С сервера – запрещаем все echo-запросы во внутреннюю сеть (192.168.0.0/24). Определяем новый именованный список, INT_OUT и вешаем его на интерфейс, ближайший к серверу.
Router(config)#ip access-list extended INT_OUT
Router(config-ext-nacl)#deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo
Router(config-ext-nacl)#exit
Router(config)#int fa0/1
Router(config-if)#ip access-group INT_OUT in
Поясняю, что мы сделали. Создали расширенный список доступа с именем INT_OUT, в нём запретили протокол icmp с типом echo с хоста 10.0.0.100 на подсеть 192.168.0.0/24 и применили на вход интерфейса fa0/1, т.е. ближайший к серверу. Пробуем послать ping с сервера.
SERVER>ping 192.168.0.11
Pinging 192.168.0.11 with 32 bytes of data:
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Ping statistics for 192.168.0.11:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
Ну, вроде сработало как надо. Для тех, кто не знает, как посылать пинги – кликаем на интересующем нас узле, например сервере. Переходим на вкладку Desktop (Рабочий стол), там Command Prompt (Командная строка).А теперь, обещанный прикол. Попробуйте послать ping с хоста, как в первом пункте.PC>ping 10.0.0.100
Pinging 10.0.0.100 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.Вот тебе раз. Только что же всё работало! Почему перестало? Это обещанный сюрприз. Объясняю, в чём проблема. Да, первое правило никуда не делось. Оно действительно разрешает отправку echo запроса на узел сервера. Но где разрешение на прохождение echo-ответов? Его нет! Запрос посылаем, а ответ принять не можем! Почему же всё работало раньше? Тогда у нас не было ACL на интерфейсе fa0/1. А раз нет ACL, то всё разрешено. Придётся создавать правило на разрешение приёма icmp-ответов.
В список INT_OUT добавим
Router(config-ext-nacl)#permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-replyТо же добавим и в список INT_IN.
Router(config-ext-nacl)#permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-replyВот теперь не придраться. Всё проходит великолепно!
- Разрешаем WEB-доступ на сервер с узла *.11.Поступаем аналогично! Тут, правда, нужно немного знать, как происходят обращения по протоколам 4-го уровня (TCP, UDP). Клиентский порт выбирается произвольным > 1024, а серверный – соответствующий службе. Для WEB – это 80 порт (протокол http).А что по поводу WEB-сервера? По умолчанию, на сервере уже установлена WEB-служба, можно посмотреть в настройках узла. Обратите внимание, чтобы стояла галочка.
А подключиться к серверу можно выбрав ярлык “Веб браузер” на “Рабочем столе” любого узла. Конечно же сейчас доступа не будет. Поскольку у нас на интерфейсах маршрутизатора висят ACL-ы, и в них нет разрешающих правил для доступа. Чтож, давайте создадим.В список доступа INT_IN (который на интерфейсе fa0/0) добавим правило:Router(config-ext-nacl)#permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq 80То есть мы разрешаем протокол TCP с нашего узла (порт произвольный, > 1024) на адрес сервера, порт HTTP.И, разумеется, обратное правило, в список INT_OUT (который на интерфейсе fa0/1):
Router(config-ext-nacl)#permit tcp host 10.0.0.100 eq 80 host 192.168.0.11 establishedТо есть разрешаем TCP с порта 80 сервера на хост *.11, и соединение уже должно быть установлено! Можно вместо established указать так же gt 1024, работать будет так же хорошо. Но смысл немного иной.
В комментах ответьте, что будет более безопасным?
- Разрешаем FTP-доступ с узла *.13 на сервер.Тоже абсолютно ничего сложного!Разбираем, как происходит взаимодействие по протоколу FTP. В будущем, я планирую посвятить целый цикл статей работе разных протоколов, поскольку это очень полезно при создании точных (снайперских) правил ACL. Ну а пока:Действия сервера и клиента:+ Клиент пытается установить связь и посылает пакет (в котором находится указание, что будет вестись работа в пассивном режиме) на 21 порт сервера со своего порта X (X > 1024, свободный порт)+ Сервер посылает ответ и сообщает номер своего порта для образования канала данных Y (Y > 1024) на порт клиента X, извлечённого из заголовка TCP-пакета.+ Клиент инициирует связь для передачи данных по порту X+1 на порт сервера Y (взятого из заголовка предыдущей транзакции). Как-то так. Немного сложно звучит, но нужно только разобраться!В список INT_IN добавляем правила:
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 eq 21
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 gt 1024А в список INT_OUT добавляем правила:
permit tcp host 10.0.0.100 eq ftp host 192.168.0.13 gt 1024
permit tcp host 10.0.0.100 gt 1024 host 192.168.0.13 gt 1024Проверяем из командной строки, командой ftp 10.0.0.100, где авторизуемся по учётным данным cisco:cisco (взято из настроек сервера), там вводим команду dir и увидим, что данные как и команды – передаются успешно.
Вот примерно и всё, что касается расширенных список доступа.
Итак, посмотрим наши правила:
Router#sh access
Extended IP access list INT_IN
permit icmp 192.168.0.0 0.0.0.255 host 10.0.0.100 echo (17 match(es))
permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply
permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq www (36 match(es))
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 eq ftp (40 match(es))
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 gt 1024 (4 match(es))
Extended IP access list INT_OUT
deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo (4 match(es))
permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply (4 match(es))
permit tcp host 10.0.0.100 eq www host 192.168.0.11 established (3 match(es))
permit tcp host 10.0.0.100 eq ftp host 192.168.0.13 gt 1024 (16 match(es))
permit tcp host 10.0.0.100 gt 1024 host 192.168.0.13 gt 1024 (3 match(es))
Comments: