Access Lists в общем случае могут использоваться для разных целей.
Наиболее часто их используют для фильтрации трафика, что мы и рассмотрим в этом материале.

Как мы уже знаем в ASA разрешается или запрещается Initial Flow Traffic.
При этом по умолчанию ASA всегда пропускает Initial Flow Traffic из зоны с более высоким Security Level в зону с более низким Security Level.
Поскольку этот трафик был разрешен (или инспектирован Inspected), сессия, к которой принадлежит данный первый пакет, помещается в Session Table.
Дальше начинает работать другой важный принцип, а именно - Statefull Packet Filtering.

Statefull Packet Filtering позволяет работать не с конкретными пакетами, а с сессией, т.е. если был разрешён Initial Flow Traffic, то разрешаются и Reply Traffic из этой же сессии, разрешается поток всей это сессии в целом. Т.е. все последующие пакеты той же сессии более не не проверяются в ACL.

В нашем случае по умолчанию разрешается трафик:
inside > outside
inside > dmz
dmz > outside

Также, по умолчанию запрещён трафик между интерфейсами с одинаковыми Security Levels

Для того, чтобы разрешить трафик из зоны с низким Security Level в зону с более высоким Security Level, необходимо использование ACL.
ACL позволяют делать исключения по поведении ASA по умолчанию, или другими словами Access Lists позволяют менять правила по умолчанию обработки Initial Flow Traffic.

Например, для того чтобы опубликовать сервер по http:

object network dmz_server_global
 host 62.105.149.237
object network dmz_server_real
 host 192.168.253.10
!
object network dmz_server_real
 nat (dmz,any) static dmz_server_global
!
access-list outside_access_in extended permit tcp any object dmz_server_real eq www
access-group outside_access_in in interface outside

В этом примере обратите внимание, что ACL выставлен именно на IP адрес dmz_server_real, т.е. на адрес который реально висит на сервере.

Хотя ACL можно накладывать на интерфейс в направлениях inbound и outbound, в подавляющем большинстве случаев ACL накладывают как inbound.

Access list может содержать одну или более строк или Access Entries.
Каждая строка может либо permit либо deny.
Обработка строки идет по принципу Top-Down Until Hit. Т.е. в случае совпадения дальнейшая обработка прекращается. Если ни одно из правил не совпало,в конце стоит дефолтная и невидимая Implicit deny.

Access lists бывают следующих типов:

• Standard ACL - работает только с Source IP
• Extended ACL - работает со всеми параметрами пакетов (source, destination, ports). Наиболее часто используется.
• Global ACL

Итак созданный нами ACL выглядит в ASDM следующим образом:

Как видно на скриншоте, на интерфейсах inside, dmz висят правила по умолчанию или неявные правила (implicit rules), - эти правила как раз и задают поведение ASA по умолчанию.

Проверка

asa1# show running-config access-list 
access-list outside_access_in extended permit tcp any object dmz_server_real eq www

asa1# show access-list                
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list outside_access_in; 1 elements; name hash: 0x6892a938
access-list outside_access_in line 1 extended permit tcp any object dmz_server_real eq www (hitcnt=0) 0x3172a2b2 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.10 eq www (hitcnt=69) 0x3172a2b2 

Object Groups for ACLs

Object Groups позволяют группировать вместе такие объекты как: hosts, networks, ports и т.д.
Существует 6 типов object groups:

• Network - совместное использование нескольких хостов или подсетей
• Service - группирование нескольких портов TCP или UDP
• Protocol
• ICMP-type
• User - создаёт Local User Groups, которая используется в Identity Firewall feature
• Security - используется в Cisco TrustSec

В данном примере применены Network Object Groups, а также Service Object Groups.

object network srv1
 host 192.168.253.10
object network srv2
 host 192.168.253.11
object-group network dmz_servers_inside
 network-object object srv1
 network-object object srv2
object-group service dmz_services_og tcp
 port-object eq ftp
 port-object eq ftp-data
 port-object eq www
 port-object eq https
access-list outside_access_in extended permit tcp any object-group dmz_servers_inside object-group dmz_services_og 

Object Groups только лишь облегчают управление в случае работы с несколькими серверами. Но с точки зрения ASA создаются отдельные правила.

asa1# show running-config access-list 
access-list outside_access_in extended permit tcp any object-group dmz_servers_inside object-group dmz_services_og 

asa1# show access-list                
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list outside_access_in; 8 elements; name hash: 0x6892a938
access-list outside_access_in line 1 extended permit tcp any object-group dmz_servers_inside object-group dmz_services_og 0x942b07d4 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.10 eq ftp (hitcnt=0) 0x87f8d6f3 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.10 eq ftp-data (hitcnt=0) 0x1754559f 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.10 eq www (hitcnt=2) 0xb20a6a7e 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.10 eq https (hitcnt=0) 0x2473f53d 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.11 eq ftp (hitcnt=0) 0xb61e4612 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.11 eq ftp-data (hitcnt=0) 0x6f6ed642 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.11 eq www (hitcnt=0) 0x2aa65534 
  access-list outside_access_in line 1 extended permit tcp any host 192.168.253.11 eq https (hitcnt=0) 0x9029fb35 

Как видно куча строк идёт от Line1 access-lists, т.е. от одной строки.

Контроль состояния сессий

Рассмотрим следующий конфиг:

object network outside_address
 host 62.105.149.236
object network dmz_server1_local
 host 192.168.253.10
object network dmz_server2_local
 host 192.168.253.11
object network dmz_server1_global
 host 62.105.149.237
object network dmz_server2_global
 host 62.105.149.238
!
object network inside_2
 nat (inside,outside) dynamic outside_address
object network dmz_server1_local
 nat (dmz,any) static dmz_server1_global
object network dmz_server2_local
 nat (dmz,any) static dmz_server2_global
!
access-list outside_access_in extended permit tcp any object dmz_server1_local eq www 
access-list outside_access_in extended permit tcp any object dmz_server2_local eq www 
!
access-group outside_access_in in interface outside

При этом сервера с адресом 192.168.253.11 реально не существует.
Понятно, что если пойти снаружи на адрес 62.105.149.238, то ничего не откроется.

asa1# show conn 
4 in use, 193 most used
TCP outside 195.112.100.134:10260 dmz 192.168.253.11:80, idle 0:00:02, bytes 0, flags SaAB
TCP outside 195.112.100.134:10259 dmz 192.168.253.11:80, idle 0:00:02, bytes 0, flags SaAB

asa1# show conn detail 
4 in use, 193 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
       B - initial SYN from outside, b - TCP state-bypass or nailed, C - CTIQBE media,
       D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,
       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
       i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
       k - Skinny media, M - SMTP data, m - SIP media, n - GUP
       O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,
       q - SQL*Net data, R - outside acknowledged FIN,
       R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,
       V - VPN orphan, W - WAAS,
       X - inspected by service module
TCP outside:195.112.100.134/10262 dmz:192.168.253.11/80,
    flags SaAB, idle 2s, uptime 2s, timeout 30s, bytes 0
TCP outside:195.112.100.134/10261 dmz:192.168.253.11/80,
    flags SaAB, idle 2s, uptime 2s, timeout 30s, bytes 0

С помощью этих команд можно просматривать состояние траслируемых сессий.
У данной ссессии флаги: SaAB
S - awaiting inside SYN
a - awaiting outside ACK to SYN
A - awaiting inside ACK to SYN
B - initial SYN from outside

Данные записи говорят, что клиент снаружи с адресом 195.112.100.134 отправил SYN request на сервер DMZ 192.168.253.11, и теперь ждет ответа.
Но ответа как мы знаем он не дождётся.

Данные записи позволяют судить о том, как происходит трансляция. Поэтому они в принципе не появятся, если у нас нерпвильно настроен NAT или ACL.

Public Server

Как мы теперь знаем, для публикации сервера наружу мы должны сделать две вещи:
- Настроить NAT
- Настроить ACL

Public Server это приблуда, которая позволяет автоматом выполнить обе эти операции.
Configuration > Firewall > Public Servers

Реально команды будут теми же:

      object network dmz_server1_local
        nat (dmz,outside) static dmz_server1_global 
      access-list outside_access line 1 extended permit tcp any object dmz_server1_local eq http 
      access-group outside_access in interface outside

Global ACL

Global ACL появилась после версии 8.3.
Это ACL, который не эплаится на конкретный интерфейс и может работать со всеми интерфейсами.
Global ACL логически эплаится как inbount к каждому интерфейсу.
Если мы настроим Global ACL, то он всегда будет обрабатываться вслед за обработкой "обычных" ACL.
Global ACL всегда обрабатывается в конце, если в обычных ACL не было найдено ни одного "Match".

object network dmz_server1_local
 host 192.168.253.10
!
access-list global_access extended permit tcp any object dmz_server1_local eq www
access-group global_access global

Забавно, что при добавлении Global ACL, автоматически исчезают все implicit rules, и для доступа изнутри наружу придётся делать правила вручную.

Packet tracer

Packet tracer - это замечательная приблуда, позволяющая симулировать любой трафик и понять пройдёт этот трафик или нет.
Эта тулза способна подсказать, пропустят ли наши ACL или правильно ли настроен NAT.

packet-tracer input outside tcp 8.8.8.8 60000 62.105.149.237 80

ping tcp

Данный тип пинга позволяет проверить доступность от имени любого узла, например:
ping tcp inside 195.112.100.134 80 source 192.168.2.13 12345

Logging and Debugging

Logging and Debugging - мощные инструменты для траблшутинга и мониторинга ASA.
Функционал logging базируется на syslog.

В syslog существует разные severity levels от 0 до 7 - чем больше тем подробнее.
Каждое сообщение лога имеет свой уровень severity и выставляя уровень мы определяем уровень подробностей, который мы получим на выходе.

! Включение logging
logging enable
!
! logging buffer - это то что мы увидим в логе если дадим команду show logging
logging buffer-size 16386
logging buffered warnings
!
! monitor - это то что будет послаться внутрь сессий telnet или ssh
logging monitor debugging
!
! asdm - задаёт уровень логгинга в ASDM
logging asdm informational
!
! Включим выставление времени в логах
logging timestamp

Для того, чтобы логи повалились в сессию SSH следует дать команду:

terminal monitor

Отключение какого то типа сообщения:

no logging message 302021

Проверка:

show running-config logging 
show logging

Итак, logging вываливает сообщения системы нужного уровня в нужное место.

Помимо logging есть ещё debug.
debug позволяет повысить уровень подробностей для определённого процесса.

debug icmp trace
show debug
no debug all

Packet Capture

Packet Capture - это возможность ASA сохранить дамп пакетов, идущих через Firewall, для дальнейшего анализа.

capture CAP1 interface outside real-time

capture CAP1 interface outside
show capture
show capture CAP1

capture CAP1 interface outside real-time match ip host 195.112.100.134 any

access-list capture_acl extended permit ip host 195.112.100.134 any4
capture CAP2 access-list capture_acl interface outside real-time

Можно также скачать файл capture:

capture CAP1 interface outside match ip host 195.112.100.134 any

• https://192.168.2.7/capture/CAP1 - возвратит содержимое capture
• https://192.168.2.7/capture/CAP1/pcap - загрузит файл pcap, который можно открыть через wireshark

ASA и ICMP

Как мы уже обсуждали, ASA является Statefull Firewall.
Когда мы идем наружу по протоколам TCP/UDP, этот трафик распознаётся как Session. Поэтому в ACL проверяется лишь первый пакет, далее трафик данной сессии в обоих направлениях пропускается без проверок.
По умолчанию трафик ICMP не распознаётся как Session, поэтому ответный трафик не прибегает обратно, т.к. блокируется ACL на outside.
Отсюда есть несколько решений:

• Разрешить ICMP на интерфейсе Outside.
• Добавить команду:
  

  policy-map global_policy
   class inspection_default
    inspect icmp 

• Либо дать команду:
  

  fixup protocol icmp

  что по сути является тем же.

Рекомендации

• Поскольку ACL работает по принципу Top-Down Until Hit, вначале ACL следует ставить более специфичные строки, а в конце более общие.
• Рекомендуется применять ACL в направлении Inbound и ко всем интерфейсам.
• В конце ACL рекомендуется ставить явное правило deny any any log critical.
  А лог настроить так:

  logging enable
  logging buffer-size 16386
  logging monitor critical
  logging buffered informational
  logging asdm informational

  Таким образом запрещенные пакеты будут попадать в лог.

• Чтобы не заморачиваться разрешите инспектирование трафика ICMP:
  

  fixup protocol icmp

• Полезные команды для дебага соединенний:
  

  show conn address 172.16.100.187 detail
  show conn address 195.112.100.134 detail
  show xlate global 46.28.95.139 gport 80

  Здесь 172.16.100.187 - внутренний адрес сервера, опубликованного через внешний 46.28.95.139 по порту 80
  195.112.100.134 - внешний клиент

ВАЖНО

В заключение несколько важных моментов насчет ACL:

• Для Outbound Traffic (Higher to Lower Security Levels) в качестве источника мы ставим в ACL actual real address.
• Для Inbound Traffic (Lower to Higher Security Levels) в качестве destination address:
  • ASA versions prior to 8.3 - translated Mapped IP address, т.е. внешний адрес
  • ASA Version 8.3 and later - Всегда используем Real IP address
• ACL всегда проверяются перед выполнением трансляции NAT.