Обект NAT конфигурация на ASA 9

Списъците за контрол на достъпа (накратко Списъци за достъп или Списъци за контрол на достъп) е методът, чрез който защитната стена на ASA определя дали да разреши или откаже трафик. По подразбиране трафикът от интерфейса с най-ниска защита към интерфейса с най-висока защита е отказан. Това поведение може да се промени чрез използване на ACL, приложен към интерфейса с най-ниска защита. ASA също така по подразбиране позволява трафик от интерфейса с най-висока защита към интерфейса с най-ниска защита. Това поведение може също да се промени с помощта на ACL. Параметърът "ниво на защита" (ниво на защита) е число от 0 до 100, което ви позволява да сравните 2 интерфейса и да определите кой е по-защитен. Параметърът се използва качествено, а не количествено, т.е. важно е само отношението "повече-по-малко".

По правило нивото на сигурност на интерфейсите се избира така, че да съответства възможно най-близо на логическата топология на мрежата. Самата топология е зона за сигурност и правилата за взаимодействие между тях. Класическата схема е да се присвоят различни нива на сигурност на различни интерфейси.

ТопологияТопологията се състои от три мрежови сегмента, към които са свързани ASA интерфейси. Мрежовият сегмент на ISP е свързан към интерфейса G0/0 и е наименуван външно с ниво на сигурност 0.

ниво

Вътрешната мрежа е свързана към g0/1 и означена вътре с ниво на защита 100. DMZ сегментът, хостващ уеб сървъра, е свързан с g0/2 и означен с dmz с ниво на защита 50.

Динамичен обект NAT

За да конфигурирате този тип NAT, трябва да създадете мрежов обект, представляващ вътрешната подмрежа,както и обект, който представлява DMZ подмрежата. Във всеки от тези обекти конфигурирайте динамично NAT правило, което ще изпълнява PAT на тези клиенти, докато трафикът пътува от техните интерфейси към външния интерфейс.

Ако погледнете текущата конфигурация в този момент (покажи изпълнение), ще видите, че дефиницията на мрежов обект е разделена на две части.

Пример какво НЕ трябва да правите:

В този случай долният ред в NAT правилото ще замени горния ред. Необходимо е да се направят два различни обекта (съдържащи една и съща мрежа) за всяко правило. Тоест така:

Статичен обект NAT

Тази фраза изглежда малко странна. "ще установи връзка от TCP порт 80 (WWW)", защото уеб трафикът е предназначен за TCP порт 80.

Важно е да се разбере, че тези NAT правила са двупосочни по природа. В резултат на това можете да перифразирате това изречение, като просто обърнете формулировката. Това ще има много повече смисъл:

Нека изпълним командатапокажи xlate.

Да кажем, че не искаме да осветяваме порт 80 на външния интерфейс, но искаме да използваме друг порт, например TCP 8081, за да го преведем в TCP порт 80 при достъп от Интернет. Тук всичко е също толкова просто, трябва да го посочите като втори аргумент на услугата в правилото NAT

Сега, ако се опитаме да направим телнет от нашия хост 10.0.0.100 към рутер 150.1.2.2, връзката ще бъде установена и ASA ще запише следното съобщение в журнала

Ако "капацитетът" на обектите е еднакъв (имат еднакъв брой хостове), тогава ще се извърши превод едно към едно. Например, можете да преведете цялата подмрежа в друга подмрежа или можете да направите идентификационен NAT - да преведете мрежата в себе си в някаква посока.

Помислете за този пример:

Акоще изпълнимshow xlate, ще видим тази картина

сигурност

И накрая, ще покажем една много важна команда, която показва местоположението на NAT правилата в паметта и реда, в който се обработват. Те саshow natиshow nat detail. Нека да разгледаме последния вариант:

обект

ACLs

След като NAT правилата са написани, трябва да разрешим преминаването на необходимия трафик, като използваме листове за достъп. Първо, нека си припомним поведението по подразбиране на ASA

  • трафикът от интерфейс с по-ниска сигурност към интерфейс с по-висока сигурност е отказан
  • разрешен е трафик от интерфейс с по-висока сигурност към интерфейс с по-ниска сигурност.
По този начин, без изрични списъци за достъп, следният трафик ще премине безпрепятствено:

  • Хостовете отвътре (ниво на защита 100) могат да се свързват с хостове в dmz мрежата (ниво на сигурност 50)
  • Хостовете отвътре (ниво на защита 100) могат да се свързват с хостове от външната мрежа (ниво на сигурност 0)
  • Хостовете на dmz (ниво на защита 50) могат да се свързват с хостове във външната мрежа (ниво на сигурност 0)
Връщащият трафик на тези установени връзки винаги е разрешен и ACL не се проверява. Следният трафик обаче ще бъде отказан.

Мрежовите обекти DMZ_WEBHOST и INSIDE_ADHOST, които декларирахме за NAT, също могат да се използват в списък за достъп.

Пристанището е отворено. Свързан с ASA

Получената ASA конфигурация ще изглежда така:

Решение под разреза:

Ето една по-сложна конструкция: В първия ред разрешаваме всеки DNS трафик (UDP 53) от dmz към странатасървър 10.0.0.100. Вторият ред деактивира IP трафика от dmz към мрежа 10.0.0.0/24. По този начин целият трафик от DMZ към вътрешността е забранен, с изключение на DNS за хост 10.0.0.100. Последният ред позволява целия друг трафик. Ако не е посочено, тогава IP трафикът от dmz към Интернет ще бъде забранен, въпреки че нивото на защита на dmz е по-високо от нивото на защита отвън.

Факт е, че чрез прилагане на ACL на интерфейса, ние отменяме поведението по подразбиране и всеки ACL има косвен deny ip any any в края, така че трафикът от dmz навън ще бъде забранен, ако не е изрично разрешен.