Часто firewall представляется неким черным ящиком который просто фильтрует проходящие пакеты. Данная заметка поможет понять, что именно происходит при фильтрации и в какой последовательности.Что происходит с пакетом попадающим внутрь PIX/ASA firewall, по каким параметрам принимается решение пропускать пакет дальше или нет?
Прежде всего, замечу, что минимальными требованиями к пакету являются:
- настроенная трансляция адресов между интерфейсами. Конечно, это требование можно отключить с помощью команды no nat-control, однако поведение по умолчанию именно такое;
- политика доступа (access-list) разрешающая доступ.
Минимальные условия это конечно здорово, но жизнь была бы слишком скучна, правда? :)
Попробуем разобраться, что происходит на каждом шаге. К сожалению я не нашел подобной информации на сайте производителя. Зато под рукой оказалась замечательная книга “Cisco ASA PIX and FWSM Handbook” из которой и почерпнута это информация.
1. Initial Checking
Базовые проверки на целостность пакета, допустимые опции и прочее. Именно на этом этапе проводится проверка Reverse Path Forwarding про которую я уже рассказывал.
Отмечу, что RPF будет полноценно работать только в случае спуфинга адресов между интерфейсами. В классическом случае outside – ASA – inside спуфинг на outside интерфейсе определить он не сможет.
2. Xlate lookup (outbound)
Именно сейчас проверяется одно из минимальных условий – трансляция адресов между интерфейсами. Совершенно неважно будет это статическая трансляция one to one или динамическая с применением overload.
Сначала firewall попытается найти уже существующую трансляцию (можно посмотреть по show xlate), в случае неудачи пытается создать, если конечно политика это предусматривает.
Этот шаг происходит на разных этапах в случае входящего/исходящего соединения. Проверка осуществляется на втором шаге в случае исходящего соединения. Этому есть логичное объясниение – адрес источника будет переписан и именно он должен фигурировать в дальнейших проверках (acl).
Повторюсь. Это поведение можно выключить используя no nat-control. Однако, до версии прошивки 7.1 этого сделать было нельзя.
Также именно здесь firewall проверяет такие параметры как:
- лимиты на количество активных соединений;
- лимиты на количество полу-открытых соединений (embryonic);
- таймауты на соединение.
3. Connection lookup
Поскольку firewall у нас “умный” и знает, что такое stateful фильтрация, ему необходимо когда-то проверять состояние соединения. Почему бы не на этом этапе? :)
Литературы по stateful фильтрации достаточно, описывать еще раз не буду.
4. ACL lookup
Именно на этом этапе происходит что-то знакомое. Как видно из названия проверяется политика доступа – поиск соответствующего access-list
По умолчанию никаких acl не применено. Трафик разрешен с более безопасного интерфейса на менее безопасный. Уровень безопасности определяется значением security level.
5. Xlate lookup (inbound)
Происходит та же проверка, что и на шаге 2. Но только для входящего трафика.
6. Uauth lookup
В случае если firewall используется как cut-through authentication proxy на этом шаге проверяются логин/пароль пользователя для его аутентификации.
Если это не первое соединение инициируемое пользователем проверяется таймер аутентификации.
7. Inspection
На последнем шаге осуществляется инспекция протокола. Конкретные действия выполняемые в этом случае очень сильно зависят от инспектируемого протокола.
Про самые интересные постараюсь рассказать в следующих заметках.
Автор: Misha Volodko
Источник: techoover.blogspot.com