Konfigurowanie reguł usługi Azure Firewall

  • Artykuł

Reguły nat, reguły sieci i reguły aplikacji w usłudze Azure Firewall można skonfigurować przy użyciu reguł klasycznych lub zasad zapory. Azure Firewall domyślnie odrzuca cały ruch, dopóki reguły nie zostaną ręcznie skonfigurowane tak, aby zezwalały na ruch.

Przetwarzanie reguł przy użyciu reguł klasycznych

Kolekcje reguł są przetwarzane zgodnie z typem reguły w kolejności priorytetu, mniejsze liczby do wyższych liczb z zakresu od 100 do 65 000. Nazwa kolekcji reguł może zawierać tylko litery, cyfry, podkreślenia, kropki lub łączniki. Musi zaczynać się literą lub cyfrą i kończyć literą, cyfrą lub podkreśleniami. Maksymalna długość nazwy to 80 znaków.

Najlepiej początkowo zwolnić numery priorytetów kolekcji reguł w 100 przyrostach (100, 200, 300 itd.), aby w razie potrzeby dodać więcej kolekcji reguł.

Przetwarzanie reguł przy użyciu zasad zapory

W przypadku zasad zapory reguły są zorganizowane wewnątrz kolekcji reguł i grup kolekcji reguł. Grupy kolekcji reguł zawierają zero lub więcej kolekcji reguł. Kolekcje reguł są typami TRANSLATOR adresów sieciowych, sieci lub aplikacji. W ramach jednej grupy reguł można zdefiniować wiele typów kolekcji reguł. W kolekcji reguł można zdefiniować zero lub więcej reguł. Reguły w kolekcji reguł muszą być tego samego typu (TRANSLATOR adresów sieciowych, sieci lub aplikacji).

Reguły są przetwarzane na podstawie priorytetu grupy kolekcji reguł i priorytetu kolekcji reguł. Priorytet to dowolna liczba z zakresu od 100 (najwyższy priorytet) do 65 000 (najniższy priorytet). Grupy kolekcji reguł o najwyższym priorytcie są najpierw przetwarzane. W grupie kolekcji reguł najpierw są przetwarzane kolekcje reguł o najwyższym priorytcie (najniższym numerze).

Jeśli zasady zapory są dziedziczone z zasad nadrzędnych, grupy kolekcji reguł w zasadach nadrzędnych zawsze mają pierwszeństwo niezależnie od priorytetu zasad podrzędnych.

Uwaga

Reguły aplikacji są zawsze przetwarzane po regułach sieci, które są przetwarzane po regułach DNAT niezależnie od grupy kolekcji reguł lub priorytetu kolekcji reguł i dziedziczenia zasad.

Oto przykładowe zasady:

Zakładając, że BaseRCG1 jest priorytetem grupy kolekcji reguł (200), który zawiera kolekcje reguł: DNATRC1, DNATRC3,NetworkRC1.
BaseRCG2 to priorytet grupy kolekcji reguł (300), który zawiera kolekcje reguł: AppRC2, NetworkRC2.
ChildRCG1 to priorytet grupy kolekcji reguł (200), który zawiera kolekcje reguł: ChNetRC1, ChAppRC1.
ChildRCG2 to grupa kolekcji reguł zawierająca kolekcje reguł: ChNetRC2, ChAppRC2,ChDNATRC3.

Zgodnie z poniższą tabelą:

Nazwisko Typ Priorytet Reguły Odziedziczone po
BaseRCG1 Grupa kolekcji reguł 200 8 Zasady nadrzędne
DNATRC1 Kolekcja reguł DNAT 600 7 Zasady nadrzędne
DNATRC3 Kolekcja reguł DNAT 610 3 Zasady nadrzędne
NetworkRC1 Kolekcja reguł sieciowych 800 1 Zasady nadrzędne
BaseRCG2 Grupa kolekcji reguł 300 3 Zasady nadrzędne
AppRC2 Kolekcja reguł aplikacji 1200 2 Zasady nadrzędne
NetworkRC2 Kolekcja reguł sieciowych 1300 1 Zasady nadrzędne
ChildRCG1 Grupa kolekcji reguł 300 5 -
ChNetRC1 Kolekcja reguł sieciowych 700 3 -
ChAppRC1 Kolekcja reguł aplikacji 900 2 -
ChildRCG2 Grupa kolekcji reguł 650 9 -
ChNetRC2 Kolekcja reguł sieciowych 1100 2 -
ChAppRC2 Kolekcja reguł aplikacji 2000 7 -
ChDNATRC3 Kolekcja reguł DNAT 3000 2 -

Przetwarzanie początkowe:

Proces rozpoczyna się od zbadania grupy kolekcji reguł (RCG) o najniższej liczbie, która jest BaseRCG1 z priorytetem 200. W tej grupie wyszukuje kolekcje reguł DNAT i ocenia je zgodnie z ich priorytetami. W tym przypadku DNATRC1 (priorytet 600) i DNATRC3 (priorytet 610) są odpowiednio przetwarzane i przetwarzane.
Następnie przechodzi do następnego RCG, BaseRCG2 (priorytet 200), ale nie znajduje kolekcji reguł DNAT.
Następnie przechodzi do childRCG1 (priorytet 300), również bez kolekcji reguł DNAT.
Na koniec sprawdza wartość ChildRCG2 (priorytet 650) i znajduje kolekcję reguł ChDNATRC3 (priorytet 3000).

Iteracja w grupach kolekcji reguł:

Wracając do baseRCG1, iteracja jest kontynuowana, tym razem dla reguł SIECI. Znaleziono tylko networkRC1 (priorytet 800).
Następnie zostanie przeniesiona do baseRCG2, gdzie znajduje się networkRC2 (priorytet 1300).
Przechodząc do childRCG1, odnajduje ChNetRC1 (priorytet 700) jako regułę SIECI.
Na koniec w childRCG2 znajduje ChNetRC2 (priorytet 1100) jako kolekcję reguł SIECI.

Ostateczna iteracja reguł aplikacji:

Wracając do baseRCG1, proces iteruje reguły APLIKACJI, ale żaden nie zostanie znaleziony.
W baseRCG2 identyfikuje appRC2 (priorytet 1200) jako regułę APPLICATION.
W childRCG1 ChAppRC1 (priorytet 900) jest znaleziony jako reguła APLIKACJI.
Na koniec w childRCG2 lokalizuje ChAppRC2 (priorytet 2000) jako regułę APPLICATION.

Podsumowując, sekwencja przetwarzania reguł jest następująca: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

Ten proces obejmuje analizowanie grup kolekcji reguł według priorytetu i w każdej grupie, porządkowanie reguł zgodnie z ich priorytetami dla każdego typu reguły (DNAT, NETWORK i APPLICATION).

Najpierw wszystkie reguły DNAT są przetwarzane ze wszystkich grup kolekcji reguł, analizując grupy kolekcji reguł według kolejności priorytetu i porządkowania reguł DNAT w każdej grupie kolekcji reguł według kolejności priorytetu. Następnie ten sam proces dla reguł SIECI, a na koniec dla reguł APLIKACJI.

Aby uzyskać więcej informacji na temat zestawów reguł zasad zapory, zobacz Zestawy reguł usługi Azure Firewall Policy.

Analiza zagrożeń

Jeśli włączysz filtrowanie oparte na analizie zagrożeń, te reguły mają najwyższy priorytet i są zawsze przetwarzane jako pierwsze (przed regułami sieci i aplikacji). Filtrowanie analizy zagrożeń może blokować ruch przed przetworzeniem wszystkich skonfigurowanych reguł. Aby uzyskać więcej informacji, zobacz Filtrowanie oparte na analizie zagrożeń w usłudze Azure Firewall.

IDPS

Po skonfigurowaniu dostawcy tożsamości w trybie alertu aparat IDPS działa równolegle z logiką przetwarzania reguł i generuje alerty dotyczące pasujących podpisów zarówno dla przepływów przychodzących, jak i wychodzących. W przypadku dopasowania podpisu IDPS alert jest rejestrowany w dziennikach zapory. Jednak ponieważ aparat IDPS działa równolegle z aparatem przetwarzania reguł, ruch blokowany lub dozwolony przez reguły aplikacji/sieci może nadal generować kolejny wpis dziennika.

Po skonfigurowaniu dostawcy tożsamości w trybie alertu i odmowy aparat IDPS jest wbudowany i aktywowany po aucie przetwarzania reguł. W związku z tym oba aparaty generują alerty i mogą blokować pasujące przepływy. 

Przerywanie sesji przez dostawcę tożsamości blokuje przepływ w trybie dyskretnym. Dlatego nie jest wysyłany RST na poziomie TCP. Ponieważ usługa IDPS sprawdza ruch zawsze po dopasowaniu reguły sieci/aplikacji (Zezwalaj/Odmów) i oznaczonych w dziennikach, w dziennikach może być rejestrowany inny komunikat drop , w którym dostawcy tożsamości zdecydują się odmówić sesji z powodu dopasowania podpisu.

Po włączeniu inspekcji protokołu TLS jest sprawdzany zarówno niezaszyfrowany, jak i zaszyfrowany ruch. 

Łączność wychodząca

Reguły sieci i reguły aplikacji

Jeśli skonfigurujesz reguły sieci i reguły aplikacji, reguły sieci są stosowane w kolejności priorytetu przed regułami aplikacji. Reguły kończą się. W związku z tym, jeśli dopasowanie zostanie znalezione w regule sieciowej, żadne inne reguły nie są przetwarzane. W przypadku skonfigurowania dostawcy tożsamości są wykonywane na wszystkich ruchach przechodzących i po dopasowaniu podpisu, dostawcy tożsamości mogą powiadamiać lub/i blokować podejrzany ruch.

Reguły aplikacji oceniają pakiet w kolejności priorytetu, jeśli nie ma dopasowania reguły sieciowej, a jeśli protokół to HTTP, HTTPS lub MSSQL.

W przypadku protokołu HTTP usługa Azure Firewall wyszukuje dopasowanie reguły aplikacji zgodnie z nagłówkiem Host. W przypadku protokołu HTTPS usługa Azure Firewall wyszukuje dopasowanie reguły aplikacji zgodnie tylko z interfejsem SNI.

Zarówno w przypadku protokołu HTTP, jak i TLS sprawdzane protokoły HTTPS, zapora ignoruje docelowy adres IP pakietu i używa rozpoznanego adresu IP DNS z nagłówka Host. Zapora oczekuje, że numer portu w nagłówku hosta, w przeciwnym razie zakłada standardowy port 80. Jeśli istnieje niezgodność portów między rzeczywistym portem TCP a portem w nagłówku hosta, ruch zostanie porzucony. Rozpoznawanie nazw DNS odbywa się przez usługę Azure DNS lub niestandardową usługę DNS, jeśli została skonfigurowana w zaporze. 

Uwaga

Protokoły HTTP i HTTPS (z inspekcją protokołu TLS) są zawsze wypełniane przez usługę Azure Firewall z nagłówkiem XFF (X-Forwarded-For) równym oryginalnemu źródłowemu adresowi IP. 

Gdy reguła aplikacji zawiera inspekcję protokołu TLS, aparat reguł zapory przetwarza SNI, nagłówek hosta, a także adres URL zgodny z regułą.

Jeśli nadal nie znaleziono dopasowania w regułach aplikacji, pakiet jest oceniany względem kolekcji reguł infrastruktury. Jeśli nadal nie ma dopasowania, pakiet zostanie domyślnie odrzucony.

Uwaga

Reguły sieci można skonfigurować dla protokołu TCP, UDP, ICMP lub dowolnego protokołu IP. Każdy protokół IP zawiera wszystkie protokoły IP zdefiniowane w dokumencie Numery protokołów przypisanych do Internetu (IANA). Jeśli port docelowy jest jawnie skonfigurowany, reguła jest tłumaczona na regułę TCP+UDP. Przed 9 listopada 2020 r. dowolne oznaczało TCP, UDP lub ICMP. Dlatego można skonfigurować regułę przed tą datą z wartością Protocol = Any, a porty docelowe = "*". Jeśli nie zamierzasz zezwalać na używanie żadnego protokołu IP zgodnie z aktualnie zdefiniowaną definicją, zmodyfikuj regułę, aby jawnie skonfigurować żądane protokoły (TCP, UDP lub ICMP).

Łączność przychodząca

Reguły DNAT i reguły sieci

Łączność przychodzącą z Internetem można włączyć, konfigurując translowanie docelowych adresów sieciowych (DNAT), zgodnie z opisem w temacie Filtrowanie ruchu przychodzącego za pomocą DNAT usługi Azure Firewall przy użyciu witryny Azure Portal. Reguły NAT są stosowane priorytetowo przed regułami sieci. W przypadku znalezienia dopasowania ruch jest tłumaczony zgodnie z regułą DNAT i dozwolony przez zaporę. W związku z tym ruch nie podlega dalszemu przetwarzaniu przez inne reguły sieciowe. Ze względów bezpieczeństwa zalecane jest dodanie określonego źródła internetowego w celu umożliwienia dostępu DNAT do sieci i uniknięcia korzystania z symboli wieloznacznych.

Reguły aplikacji nie są stosowane dla połączeń przychodzących. Dlatego jeśli chcesz filtrować przychodzący ruch HTTP/S, należy użyć zapory aplikacji internetowej (WAF). Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Web Application Firewall?

Przykłady

W poniższych przykładach przedstawiono wyniki niektórych z tych kombinacji reguł.

Przykład 1

Połączenie do google.com jest dozwolona ze względu na zgodną regułę sieci.

Reguła sieci

  • Akcja: Zezwalaj
name Protokół Source type Źródło Typ docelowy Adres docelowy Porty docelowe
Zezwalaj na sieć Web TCP Adres IP * Adres IP * 80 443

Reguła aplikacji

  • Akcja: Odmów
name Source type Źródło Protokół:port Docelowe nazwy FQDN
Deny-google Adres IP * http:80,https:443 google.com

Wynik

Połączenie z google.com jest dozwolone, ponieważ pakiet jest zgodny z regułą zezwalania na sieć internetową . Przetwarzanie reguł zatrzymuje się w tym momencie.

Przykład 2

Ruch SSH jest blokowany, ponieważ kolekcja reguł sieci o wyższym priorytcie Odmawiaj blokuje go.

Kolekcja reguł sieciowych 1

  • Nazwa: Zezwalaj na zbieranie
  • Priorytet: 200
  • Akcja: Zezwalaj
name Protokół Source type Źródło Typ docelowy Adres docelowy Porty docelowe
Zezwalaj na protokół SSH TCP Adres IP * Adres IP * 22

Kolekcja reguł sieci 2

  • Nazwa: Deny-collection
  • Priorytet: 100
  • Akcja: Odmów
name Protokół Source type Źródło Typ docelowy Adres docelowy Porty docelowe
Odmowa protokołu SSH TCP Adres IP * Adres IP * 22

Wynik

Połączenia SSH są odrzucane, ponieważ kolekcja reguł sieci o wyższym priorytcie blokuje je. Przetwarzanie reguł zatrzymuje się w tym momencie.

Zmiany reguły

Jeśli zmienisz regułę na odmowę wcześniej dozwolonego ruchu, wszystkie odpowiednie istniejące sesje zostaną porzucone.

Zachowanie trójkierunkowe uzgadniania

Jako usługa stanowa usługa Azure Firewall wykonuje trójkierunkowe uzgadnianie tcp dla dozwolonego ruchu z źródła do miejsca docelowego. Na przykład sieć wirtualna-A do sieci wirtualnej-B.

Utworzenie reguły zezwalania na ruch z sieci wirtualnej A do sieci wirtualnej B nie oznacza, że nowe połączenia inicjowane z sieci wirtualnej B do sieci wirtualnej A są dozwolone.

W związku z tym nie ma potrzeby tworzenia jawnej reguły odmowy z sieci wirtualnej-B do sieci wirtualnej-A. Jeśli tworzysz tę regułę odmowy, przerywasz uzgadnianie trzykierunkowe z początkowej reguły zezwalania z sieci wirtualnej-A do sieci wirtualnej-B.

Następne kroki