Udostępnij za pośrednictwem

Konfigurowanie reguł usługi Azure Firewall

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. Reguły kończą działanie, więc przetwarzanie reguł zatrzymuje się na dopasowaniu.

Przetwarzanie reguł przy użyciu reguł klasycznych

Kolekcje reguł są przetwarzane zgodnie z typem reguły w kolejności priorytetu, od najmniejszych do największych w zakresie 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 na początku rozmieścić numery priorytetów zbiorów reguł w przedziałach co 100 (100, 200, 300 itd.), aby w razie potrzeby móc dodać więcej takich zbiorów.

Przetwarzanie reguł za pomocą polityki 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ł to typy NAT, sieć lub aplikacje. 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 (NAT, 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.

Tak więc, aby podsumować:

Zasady nadrzędne zawsze mają pierwszeństwo.

  1. Grupy kolekcji reguł są przetwarzane w kolejności priorytetów.
  2. Kolekcje reguł są przetwarzane w kolejności priorytetów.
  3. Reguły DNAT, a następnie reguły sieciowe, a następnie reguły aplikacji są przetwarzane.

Oto przykładowe zasady:

Zakładając, że BaseRCG1 jest priorytetem grupy kolekcji reguł (200), która zawiera kolekcje reguł: DNATRC1, DNATRC3, NetworkRC1.
BaseRCG2 to priorytet grupy kolekcji reguł (300), który zawiera kolekcje reguł: AppRC2, NetworkRC2.
ChildRCG1 to grupa kolekcji reguł z priorytetem (300), która zawiera kolekcje reguł: ChNetRC1, ChAppRC1.
ChildRCG2 to priorytet grupy kolekcji reguł (650), który zawiera 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 Polityka główna
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 1 100 2 -
ChAppRC2 Kolekcja reguł aplikacji 2000 7 -
ChDNATRC3 Kolekcja reguł DNAT 3000 2 -

Początkowa iteracja reguł DNAT:

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ą znajdowane i przetwarzane odpowiednio.
Następnie przechodzi do następnego RCG, BaseRCG2 (priorytet 300), ale nie znajduje kolekcji reguł DNAT.
Następnie przechodzi do ChildRCG1 (priorytet 300), również bez kolekcji reguł DNAT.
Na koniec sprawdza ChildRCG2 (priorytet 650) i znajduje kolekcję reguł ChDNATRC3 (priorytet 3000).

Iteracja reguł sieci:

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łę NETWORK.
Na koniec w childRCG2 znajduje ChNetRC2 (priorytet 1100) jako kolekcję reguł SIECI.

Ostateczna iteracja reguł aplikacji:

Wracając do BaseRCG1, proces iteruje przez reguły APLIKACJI, ale żadna nie została znaleziona.
W baseRCG2 identyfikuje appRC2 (priorytet 1200) jako regułę APPLICATION.
W ChildRCG1 ChAppRC1 (priorytet 900) znajduje się 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ł usługi Azure Firewall, zobacz Zestawy reguł usługi Azure Firewall.

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.

System Wykrywania i Zapobiegania Włamaniom (IDPS)

Po skonfigurowaniu systemu wykrywania i zapobiegania włamaniom w trybie ostrzegania, silnik IDPS działa równolegle z logiką przetwarzania reguł i generuje alerty o pasujących sygnaturach zarówno dla przepływów przychodzących, jak i wychodzących. Gdy nastąpi dopasowanie sygnatury IDPS, w dziennikach zapory rejestrowany jest alert. 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 IDPS w trybie 'Alert i Odmowa' aparat IDPS jest wbudowany i aktywowany po silniku przetwarzania reguł. W związku z tym oba silniki generują alerty i mogą blokować pasujące przepływy. 

Przerywanie sesji wykonywane przez IDPS blokuje przepływ bezgłośnie. Dlatego nie jest wysyłany RST na poziomie TCP. Ponieważ IDPS inspektuje ruch zawsze po dopasowaniu reguły sieci/aplikacji (Zezwól/Odmów) i oznaczeniu w dziennikach, inny komunikat Drop może być rejestrowany, gdzie IDPS decyduje się odmówić sesji z powodu dopasowania sygnatury.

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

Niejawna obsługa ruchu powrotnego (stanowy protokół TCP/UDP)

Użytkownik może skonfigurować reguły zapory tak, aby zezwalały na ruch tylko w jednym kierunku. Na przykład usługa Azure Firewall może zezwalać na połączenia inicjowane z sieci lokalnej do sieci wirtualnej platformy Azure, jednocześnie wymagając zablokowania nowych połączeń inicjowanych z sieci wirtualnej platformy Azure do środowiska lokalnego . Aby wymusić te zasady, użytkownik może dodać jawną regułę Odmowy dla ruchu z sieci wirtualnej platformy Azure do sieci lokalnej .

Usługa Azure Firewall obsługuje tę konfigurację. Usługa Azure Firewall to śledzący stan i ruch powrotny dla ustanowionego połączenia TCP/UDP (na przykład pakiety SYN-ACK/ACK dla połączenia zainicjowanego ze środowiska lokalnego) są dozwolone nawet wtedy, gdy jawna reguła odmowy istnieje w odwrotnym kierunku. Jawna reguła odmowy nadal blokuje nowe połączenia inicjowane z sieci wirtualnej platformy Azure do środowiska lokalnego.

Łą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 ulegają zakończeniu. W związku z tym, jeśli dopasowanie zostanie znalezione w regule sieciowej, żadne inne reguły nie są przetwarzane. Jeśli skonfigurowano, system IDPS jest stosowany do całego przesyłanego ruchu i po dopasowaniu sygnatury system IDPS może ostrzegać 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 analizowanych protokołów HTTP, jak i HTTPS z użyciem TLS, zapora ignoruje docelowy adres IP pakietu i używa adresu IP rozpoznanego przez DNS z nagłówka Host. Zapora oczekuje, że numer portu zostanie podany w nagłówku Host, w przeciwnym razie zakłada standardowy port 80. Jeśli występuje niezgodność portów między rzeczywistym portem TCP a portem w nagłówku hosta, ruch zostaje odrzucony. 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, mechanizm przetwarzania reguł zapory analizuje SNI, nagłówek hosta oraz adres URL zgodnie 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.

Kolekcja reguł infrastruktury

Usługa Azure Firewall zawiera wbudowany zbiór reguł dla infrastrukturalnych FQDN, które są domyślnie dozwolone. Te nazwy FQDN są specyficzne dla platformy i nie można ich używać do innych celów. Kolekcja reguł infrastruktury jest przetwarzana po regułach aplikacji i przed ostateczną regułą odmowy dla wszystkich.

W kolekcji wbudowanych reguł infrastruktury znajdują się następujące usługi:

  • Dostęp obliczeniowy do repozytorium obrazów Platform Image Repository PIR
  • Dostęp do magazynu stanu dysków zarządzanych
  • Diagnostyka i rejestrowanie platformy Azure (MDS)

Nadpisywanie zbioru reguł infrastruktury

Tę wbudowaną kolekcję reguł infrastruktury można zastąpić, tworząc kolekcję reguł aplikacji odrzucających wszystko, która jest przetwarzana jako ostatnia. Będzie ona zawsze przetwarzana przed kolekcją reguł infrastruktury. Wszystkie elementy, które nie są w kolekcji reguł infrastruktury, są domyślnie odrzucane.

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. Możliwe, że przed tą datą skonfigurowałeś regułę z Protocol = Any i 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

Połączenia przychodzące z Internetem lub intranetem można włączyć, konfigurując translację adresów sieciowych docelowego (DNAT), zgodnie z opisem w temacie Filtrowanie przychodzącego ruchu internetowego lub intranetowego za pomocą reguł DNAT w usłudze Azure Firewall przy użyciu portalu Azure. Reguły NAT są stosowane priorytetowo przed regułami sieci. W przypadku znalezienia dopasowania, ruch sieciowy 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 z google.com jest dozwolone z powodu zgodnej reguły sieciowej.

Reguła sieci

  • Akcja: Zezwalaj
nazwa Protokół Typ źródła Źródło Typ docelowy Adres docelowy Porty docelowe
Zezwalaj na działanie w sieci Web TCP adres IP * adres IP * 80 443

Reguła aplikacji

  • Akcja: Odmów
nazwa Typ źródła Ź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 kolekcjonowanie
  • Priorytet: 200
  • Akcja: Zezwalaj
nazwa Protokół Typ źródła Ź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
nazwa Protokół Typ źródła Ź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łę, aby zablokować ruch, który wcześniej był dozwolony, wszystkie powiązane istniejące sesje zostaną zakończone.

Zachowanie trójetapowego uzgadniania

Jako usługa śledząca stany, Azure Firewall wykonuje trójkierunkowe uzgadnianie TCP dla dozwolonego ruchu, od źródła do celu. Na przykład VNet-A do VNet-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.

Następne kroki

  • Last updated on