Match user by group from AD in ASA VPN

Группа в каталоге называется ASA_VPN. Все пользователи, находящиеся в этой группе должны проходить авторизацию на ASA при подключении AnyConnect VPN. 

На tunnel-group нужно повесть политику запрещающую доступ т.к. пользователи, не входящие в группу ASA_VPN попадут на политику tunnel-group или, в случае если для tuneel-group не установлена политика явно, попадут в политику "по умолчанию". Тем пользователям, которые находятся в ASA_VPN будет динамически присвоена политика CorpUsers (настроено в ldap attribute-map).

ldap attribute-map DOMAINNAME_DC
  map-name  memberOf Group-Policy
  map-value memberOf CN=ASA_VPN,OU=INET,OU=Service,OU=Users,OU=DOMAINNAME,DC=DOMAINNAME,DC=local CorpUsers

aaa-server LDAP_SRV_GRP (CORE) host 192.168.244.5
 ldap-base-dn OU=Users,OU=DOMAINNAME,DC=DOMAINNAME,DC=local
 ldap-attribute-map DOMAINNAME_DC

group-policy NOACCESS internal
group-policy NOACCESS attributes
 vpn-simultaneous-logins 0

group-policy CorpUsers attributes
 vpn-simultaneous-logins 3

tunnel-group Corp general-attributes
 default-group-policy NOACCESS  

ASA Site-to-Site IPsec dual-ISP redundancy

Есть два офиса. В одном (главном) два аплика, в другом - один. В офисах стоят ASA 5505. Между ними IPSec Site-toSite tunnel. При падении основного канала нужно, чтобы туннель автоматически поднимался через резервный.

Схема в GNS3

На sw1 не обращайте внимания, он выведен в реальную сеть для управления фаерволами. Трафик идет через маршрутизаторы.

Dual ISP enterprise (branch) cisco router, firewall (ASA)

Классическая задача для предприятий и малого бизнеса - настройка маршрутизатора с двумя каналами в интернет без использования динамических протоколов маршрутизации. Очень много информации на эту тему есть в сети. Решил и я сделать заметку.

Нужно дать пользователям интернет и опубликовать какой-либо сервис (например, RDP) наружу.

Основные затыки происходят тут:
- динамическая смена маршрута 0.0.0.0 0.0.0.0;
- настройка NAT для двух внешних интерфейсов;
- доступность опубликованного сервиса сразу через оба ISP.

Есть хороший пост на хабре - По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP и на сайте этого же автора более полная дока, с рассмотренным вариантом использования сразу двух ISP - Сергей Фёдоров "Подключение к 2 ISP с настройкой трекинговой маршрутизации и NAT.

Вот дока 2008 года с сайта cisco - http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/100658-ios-nat-load-balancing-2isp.html.

Итак, нам нужно использовать IP SLA для решения первого пункта, ROUTE-MAP для решения второго и третьего.

Использую эти документы, я собрал схему в GNS3. В моем случае опубликован был сервис telnet. На внешних адресах (172.16.X.X) он светился в порту 10023, внутри шел на 192.168.1.2:23.

ASA. Резервирование IPSec туннелей, RA VPN.

Итак, с чего бы начать повествование… Пожалуй, начну с того, как все было раньше и как развивалось. Я пришел в компанию-интегратор около двух лет назад. До этого в течении пяти лет я трудился у операторов ШПД и мобилников. Там я занимался магистральной сетью. Здесь же пришлось перейти на другой уровень - сетей предприятия. Если операторские сети характеризуются большим трафиком и кучей маршрутов, то сети предприятий - это интеллектуальные услуги с небольшим трафиком. Везде своя специфики, разные устройства.

Любой интегратор - контора проектная, где прибыль приносят исключительно проекты. Когда специалист занимается настройкой или проектированием по какому-либо проекту, оплата его труда идет из бюджета этого проекта. В компании есть внешние проекты - проекты, которые приносят деньги, и есть внутренние - такие как “Поддержка внутренней сетевой инфраструктуры” и т.д. Внутренние тоже требуют затрат труда, но руководители проектов не любят тратить бюджет вутренний, да и специалисты не любят внутренние проекты из-за того, что по ним час труда стоит меньше (эдакая мотивация заниматься внешними коммерческими проектами). Из вышесказанного можно сделать вывод, что внутренняя структура ИТ находится на уровне “чтобы работало”, но с минимальными затратами.

Когда я пришел в фирму, внутренняя сеть представляла собой классический пример SOHO (даже не SMB). Единственное, что отличало  её от домашней сети - наличие нескольких VLAN (DMZ, WLAN, LAN). На периметре стояла одинокая ASA 5505 с единственным каналом в интернет. На этой железке был поднят сервис Remote Access VPN на Cisco Anyconnect с авторизацией через LDAP. Нужно заметить, что был реализован и доступ через Clientless SSL VPN со всеми его фичами такими как split-tunnel, java-приложения (rdp, vnc, telnet/ssh).

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

  На ASA я реализовал автоматическое переключение с использованием IP SLA и Track. Пингуем гугловский публичный днс через основной канал. Если пинги не проходят, убираем статический маршрут “по-умолчанию” с наибольшей метрикой (по срабатывани. track). Остается маршрут постоянный с большей метрикой. Резервирование интернета есть.

 Прошло некоторое время, и у фирмы появился офис в другом городе. Вся инфраструктуара находится, соответственно, в основном офисе. Появилась новая задача - подключить офис к существующим ресурсам с минимальными затратами. Так появилась ещё одно ASA и IPSec site-to-site туннель. И всё шло хорошо до первого падения основного канала. Туннель не резервируется. На ASA основного офиса нет возможности построить два туннеля через разные интерфейсы на один IP адрес т.к. маршрут наружу для удаленного хоста идет только через один интерфейс. В момент падения туннели приходилось переделывать руками.

 Так получилось, что у меня оказалась одна свободная ASA 5505. Я решил задействовать её, переместив на нее резервный канал в интернет. В виду минимальных расходов на собственную инфраструктуру в ядре нашей сети нет коммутатора L3, поэтому пока не реализовано резервирования “шлюза по-умолчанию”, в связи с чем я решил включить вторую ASA в первую (ASA не поддерживает ни один из FHRP). При начилчии коммутатора L3 в ядре резервирование “шлюза по-умолчанию” делается на динамическом протоколе маршрутизации.

 Начальная схема:

ASA troubleshooting

Для диагностики конфигурации в АСА можно использовать следующие команды:
 - show conn [detail]
 - show xlate

EDGE-5512X/sec/act# show local-host ?

  Hostname or A.B.C.D     Show local host information corresponding to this ip
                          address
  Hostname or X:X:X:X::X  Show local host information corresponding to an IPV6
                          address
  all                     To show connections including to-the-box and
                          from-the-box
  brief                   Enter this keyword for brief information
  connection              Show local host information  based on the number of
                          connections
  detail                  Enter this keyword for detailed information
  |                       Output modifiers
Продолжение следует.

ASA URL Filtering

Оригинал тут - https://supportforums.cisco.com/docs/DOC-1268

Introduction

One of the ASA features is url filtering. It can be used to block or allow users from going to certain urls/websites. This article aims to educate the user on how to use this feature. After reading it carefully someone should be able to take full advantage of url filtering and use it for his needs.

In this article we will either block or allow domains in urls and words in the uri. Of course the ASA can match on other things too. They can be found in the ASA configuration guides. From now and onwards we will allow or block the cisco.com domain. In other words, any user browsing to any page that is behind cisco.com will be subject to url filtering. Such pages would be www.cisco.com/index.html or cisco.com/exampledir/page.html. Also, we will allow or block "/test/" in the uri. In other words, any page path that contains "/test/" will be url filtered. Examples are www.examplesite.com/exampledir/test/page.html or www.anyurl.com/test/examplepage.jsp or www.anything.com/onedir/seconddir/test

The mechanism used to apply url filtering is Modular Policy Framework (MPF). We will create regular expressions (regex) that will be matched in class-maps of type http. These class-maps will be used in policy-maps to define the drop action. Then the policy-maps will be applied with an http inspection in another policy-map that will be applied to an interface. In that way the http inspection action will be applied to the traffic that hits an interface.

NOTE: Though, we need to highlight that for Enterprise URL Filtering, customers should be steered toward using WebSense or N2H2 integration with the ASA. Such web filtering engines can provide much more robust filtering based on classes of sites. URL filtering directly on the ASA using regex, should be used only sparsely when broad classifications can be applied, with limited regex patterns. The ASA will not scale being used in an enterprise with large regex matches and large volumes of HTTP traffic.

Block specific urls

Lets assume that we want to block some specific websites. For example we want to block specific anything under cisco.com and uris that contain "/test/". We will create the regexes and match them in a class-map. Note that if ANY regex is matched then the class-map will actually be met. Then in the policy-map block-url-policy whatever meets the class-map (cisco.com OR uri containing "/test/") is reset. The rest are allowed (not cisco.com and not uri containing "/test/"). The policy-map block-url-policy is used for http inspection in another policy-map (global_policy) and applied with a service-policy.

 
regex blockex1 "/test/"
regex blockex2 "cisco\.com"

class-map type inspect http match-any block-url-class
 match request uri regex blockex1
 match request header host regex blockex2

policy-map type inspect http block-url-policy
 parameters
 class block-url-class
  drop-connection log
policy-map global_policy
 class inspection_default
  inspect http block-url-policy

service-policy global_policy global

Настройка cluster Active/Standby на ASA

В кластер ASA можно собирать при наличии на каждой лицензии Security Plus. Для обмена репликациями я выделил отдельный физический интерфейс и назначить ему IP адреса. Адреса должны быть в одной подсети. Изначально Standby узел объявляет себя активным если она не получил несколько ответов от IP интерфейса, которым асы связаны между собой (где ходит репликация). Мне нужно сделать так, чтобы резервный узел включался и в том случае, если падает интерфейс Inside. Для этого на этом интерфейсе нужно прописать дополнительную конфу. Выделяем /29 сеть, даем один адрес узлу перед асой (в моем случае это L3 коммутатор), в конфиге главной асы прописываем на интерфейсе адрес, и обозначаем адрес второго узла для того, чтобы аса мониторила этот интерфейс. После этого нужно включить непосредственно сам мониторинг.

Итак, всё просто. Сначала настраиваем главный (Active) узел.

ciscoasa# conf t
ciscoasa(config)#interface GigabitEthernet0/0.30
ciscoasa(config)#vlan 30
ciscoasa(config)#nameif Inside
ciscoasa(config)#security-level 100
ciscoasa(config)#ip address 10.6.100.25 255.255.255.248 standby 10.6.100.26
ciscoasa(config)#exit
ciscoasa(config)#failover lan unit primary
ciscoasa(config)#failover lan interface failoverlink GigabitEthernet0/5
ciscoasa(config)#failover polltime unit msec 500 holdtime 2
ciscoasa(config)#failover replication http
ciscoasa(config)#failover link failoverlink GigabitEthernet0/5
ciscoasa(config)#failover interface ip failoverlink 10.6.100.41 255.255.255.252 standby 10.6.100.42
ciscoasa(config)#monitor-interface Inside

Cisco ASA Policer

Шейпер на АСА можно применить только для default-class, полисеры же применяются к любым классам.

Для пользователя 192.168.11.11 режем скорость вверх и вниз на 100000 bits per second.
Политику применяем на интерфейс Inside.

access-list user1_wifi-inet_to_user extended permit ip any host 192.168.11.11
access-list user1_wifi_user_to_inet extended permit ip host 192.168.11.11 any
!
class-map user1_inet_to_user
 match access-list user1_wifi-inet_to_user
!
!
class-map user1_user_to_inet
 match access-list user1_wifi_user_to_inet
!
!
policy-map PolicyMap_Inside
 class user1_inet_to_user
  police output 100000
 class user1_user_to_inet
  police input 100000
!
!
! 
service-policy PolicyMap_Inside interface inside

Чтобы убрать политику с интерфейса:

no service-policy PolicyMap_Inside interface inside.

Для теста скорости, рекомендую использовать утилиту ipref.

По теме:
http://serverfault.com/questions/322621/qos-on-cisco-asa-5505-by-vlan-subnet/322803#322803
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_qos.html#wp1171819
http://www.icefortress.ru/?p=53

Увидеть ASA через tracert

По началу не мог понять, куда же АСА прячется из трассы. Вот оно как.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml#asatrace

Make the Firewall Show Up in a Traceroute in ASA/PIX

ciscoasa(config)#class-map class-default
ciscoasa(config)#match any


!--- This class-map exists by default.


ciscoasa(config)#policy-map global_policy


!--- This Policy-map exists by default.


ciscoasa(config-pmap)#class class-default


!--- Add another class-map to this policy.


ciscoasa(config-pmap-c)#set connection decrement-ttl


!--- Decrement the IP TTL field for packets traversing the firewall.
!--- By default, the TTL is not decrement hiding (somewhat) the firewall.