Az Azure Firewall-szabályok konfigurálása

Az Azure Firewallon nat-szabályokat, hálózati szabályokat és alkalmazásszabályokat konfigurálhat klasszikus szabályokkal vagy tűzfalszabályzatokkal. Az Azure Firewall alapértelmezés szerint minden forgalmat tilt, hacsak a manuálisan konfigurált szabályok nem engedélyezik azt. A szabályok megszűnnek, ezért a szabályfeldolgozás egyezéskor leáll.

Szabályfeldolgozás klasszikus szabályokkal

A szabálygyűjtemények feldolgozása prioritási sorrendben a szabálytípusnak megfelelően történik, kisebb számokkal pedig 100 és 65 000 között. A szabálygyűjtemények neve csak betűkkel, számokkal, aláhúzásjelekkel, pontokkal vagy kötőjelekkel rendelkezhet. Betűvel vagy számmal kell kezdődnie, és betűvel, számmal vagy aláhúzásjellel kell végződnie. A név hossza legfeljebb 80 karakter lehet.

Érdemes először 100 lépésben (100, 200, 300 stb.) elhelyezni a szabálygyűjtemény prioritási számát, hogy szükség esetén több szabálygyűjteményt is felvehet.

Szabályfeldolgozás tűzfalszabályzat használatával

A tűzfalszabályzattal a szabályok szabálygyűjteményeken és szabálygyűjtemény-csoportokon belül vannak rendszerezve. A szabálygyűjtemény-csoportok nulla vagy több szabálygyűjteményt tartalmaznak. A szabálygyűjtemények nat, hálózat vagy alkalmazások típusúak. Egyetlen szabálycsoporton belül több szabálygyűjtemény-típust is meghatározhat. Egy szabálygyűjteményben nulla vagy több szabály definiálható. A szabálygyűjtemény szabályainak azonos típusúnak kell lenniük (NAT, Hálózat vagy Alkalmazás).

A szabályok feldolgozása a szabálygyűjteménycsoport prioritása és a szabálygyűjtemény prioritása alapján történik. A prioritás bármely 100 (legmagasabb prioritás) és 65 000 (legalacsonyabb prioritás) közötti szám. A rendszer először a legmagasabb prioritású szabálygyűjtemény-csoportokat dolgozza fel. Egy szabálygyűjteménycsoporton belül a rendszer először a legmagasabb prioritású (legalacsonyabb számú) szabálygyűjteményeket dolgozza fel.

Ha egy tűzfalszabályzat szülőházirendtől öröklődik, a szülőszabályzat szabálycsoportjai mindig elsőbbséget élveznek a gyermekházirend prioritásától függetlenül.

Összefoglalva tehát:

A szülőházirend mindig elsőbbséget élvez.

1. A szabálygyűjtemény-csoportok feldolgozása prioritási sorrendben történik.
2. A szabálygyűjtemények feldolgozása prioritási sorrendben történik.
3. DNST-szabályok, majd hálózati szabályok, majd alkalmazásszabályok feldolgozása.

Íme egy példaszabályzat:

Feltételezve, hogy a BaseRCG1 egy szabálygyűjteménycsoport prioritása (200), amely a következő szabálygyűjteményeket tartalmazza: DNATRC1, DNATRC3, NetworkRC1.
A BaseRCG2 egy szabálygyűjteménycsoport prioritása (300), amely a következő szabálygyűjteményeket tartalmazza: AppRC2, NetworkRC2.
A ChildRCG1 egy szabálygyűjteménycsoport prioritása (300), amely a következő szabálygyűjteményeket tartalmazza: ChNetRC1, ChAppRC1.
A ChildRCG2 egy szabálycsoport prioritása (650), amely a következő szabálygyűjteményeket tartalmazza: ChNetRC2, ChAppRC2, ChDNATRC3.

A következő táblázat szerint:

A DNAT-szabályok kezdeti iterációja:

A folyamat a legalacsonyabb számmal rendelkező szabálygyűjteményi csoport (RCG) vizsgálatával kezdődik, amely a BaseRCG1, amelynek prioritása 200. Ebben a csoportban megkeresi a DNAT-szabálygyűjteményeket, és a prioritásoknak megfelelően értékeli őket. Ebben az esetben a rendszer a DNATRC1 (600- os prioritás) és a DNATRC3 (610.prioritás) alapján találja meg és dolgozza fel.
Ezután a következő RCG-be, a BaseRCG2-be (300- prioritás) kerül, de nem talál DNST-szabálygyűjteményt.
Ezt követően a ChildRCG1 (300. prioritás) felé halad, szintén DNST-szabálygyűjtemény nélkül.
Végül ellenőrzi a ChildRCG2 -t (650-ös prioritás), és megkeresi a ChDNATRC3 szabálygyűjteményt (3000 prioritás).

Iteráció hálózati szabályokhoz:

A BaseRCG1-be visszatérve az iteráció folytatódik, ezúttal a HÁLÓZATI szabályok esetében. Csak a NetworkRC1 (800- prioritás) található.
Ezután a BaseRCG2-be kerül, ahol a NetworkRC2 (prioritás: 1300) található.
A ChildRCG1-be lépve a ChNetRC1 (700-as prioritás) hálózati szabályként lesz felderítve.
Végül a ChildRCG2-ben a ChNetRC2 -t (1100-as prioritás) találja hálózati szabálygyűjteményként.

Végleges iteráció az ALKALMAZÁSszabályokhoz:

A BaseRCG1-be visszatérve a folyamat iterál az APPLICATION-szabályokhoz, de egyik sem található.
A BaseRCG2-ben az AppRC2 -t (1200-as prioritás) azonosítja alkalmazásszabályként.
A ChildRCG1-ben a ChAppRC1 (900-as prioritás) az APPLICATION szabály.
Végül a ChildRCG2-ben a ChAppRC2 -t (2000-as prioritás) találja alkalmazásszabályként.

Összefoglalva a szabályfeldolgozási sorrend a következő: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

Ez a folyamat magában foglalja a szabálygyűjteményi csoportok prioritás szerinti elemzését, valamint az egyes csoportokon belül a szabályok sorrendjét az egyes szabálytípusok (DNAT, NETWORK és APPLICATION) prioritása szerint.

Ezért először az összes DNST-szabályt az összes szabálygyűjteményi csoportból feldolgozzuk, a szabálygyűjteményi csoportokat prioritási sorrend szerint elemezzük, és a DNST-szabályokat az egyes szabálygyűjteményi csoportokon belül prioritási sorrend szerint rendezjük. Ezután ugyanez a folyamat a hálózati szabályok, végül pedig az alkalmazásszabályok esetében.

A tűzfalszabály-készletekkel kapcsolatos további információkért tekintse meg az Azure Firewall Policy-szabálykészleteket.

Fenyegetések felderítése

Ha engedélyezi a fenyegetésintelligencia-alapú szűrést, ezek a szabályok a legmagasabb prioritást élvezik, és mindig az elsőként dolgozzák fel őket (a hálózati és alkalmazásszabályok előtt). A fenyegetésintelligencia-szűrés megtagadhatja a forgalmat a konfigurált szabályok feldolgozása előtt. További információ: Azure Firewall fenyegetésintelligencia-alapú szűrés.

IDPS

Ha az IDPS riasztási módban van konfigurálva, az IDPS-motor párhuzamosan működik a szabályfeldolgozási logikával, és riasztásokat hoz létre a bejövő és kimenő folyamatok megfelelő aláírásaira vonatkozóan. Az IDPS-aláírások egyezése esetén a rendszer tűzfalnaplókban naplózza a riasztásokat. Mivel azonban az IDPS-motor a szabályfeldolgozó motorral párhuzamosan működik, az alkalmazás-/hálózati szabályok által megtagadott vagy engedélyezett forgalom továbbra is létrehozhat egy újabb naplóbejegyzést.

Ha az IDPS riasztási és megtagadási módban van konfigurálva, az IDPS-motor a szabályfeldolgozó motor után inline és aktiválva lesz. Ezért mindkét motor riasztásokat generál, és blokkolhatja az egyező folyamatokat. 

Az IDPS által végrehajtott munkamenet-elvetések némán blokkolják az áramlást. Ezért a rendszer nem küld RST-t TCP-szinten. Mivel az IDPS a forgalmat mindig a hálózati/alkalmazásszabály egyeztetése (Engedélyezés/Megtagadás) után ellenőrzi, és naplókban jelöli meg, előfordulhat, hogy egy másik Drop-üzenet is naplózható, ahol az IDPS úgy dönt, hogy egy aláírás-egyezés miatt megtagadja a munkamenetet.

Ha a TLS-ellenőrzés engedélyezve van, a rendszer a titkosítatlan és a titkosított forgalmat is megvizsgálja. 

Kimenő kapcsolat

Hálózati szabályok és alkalmazások szabályai

Ha hálózati szabályokat és alkalmazásszabályokat konfigurál, akkor a rendszer prioritási sorrendben alkalmazza a hálózati szabályokat az alkalmazásszabályok előtt. A szabályok megszűnnek. Ha tehát egyezést talál egy hálózati szabályban, a rendszer nem dolgoz fel más szabályokat. Ha konfigurálva van, az IDPS minden bejárt forgalomon megtörténik, és az aláírások egyeztetése után az IDPS riasztást vagy/és letilthatja a gyanús forgalmat.

Az alkalmazásszabályok ezután prioritási sorrendben értékelik ki a csomagot, ha nincs hálózati szabályegyeztetés, és ha a protokoll HTTP, HTTPS vagy MSSQL.

HTTP esetén az Azure Firewall a gazdagép fejlécének megfelelően egyező alkalmazásszabályt keres. HTTPS esetén az Azure Firewall csak az SNI-nek megfelelő alkalmazásszabályt keres.

A HTTP és a TLS által vizsgált HTTPS-esetekben a tűzfal figyelmen kívül hagyja a csomag cél IP-címét, és a gazdagép fejlécéből a DNS által feloldott IP-címet használja. A tűzfal várhatóan lekéri a portszámot a gazdagép fejlécében, ellenkező esetben a standard 80-es portot feltételezi. Ha a tényleges TCP-port és a gazdagép fejlécében lévő port között eltérés van, a forgalom csökken. A DNS-feloldás az Azure DNS-sel vagy egyéni DNS-sel történik, ha a tűzfalon van konfigurálva. 

Ha egy alkalmazásszabály TLS-ellenőrzést tartalmaz, a tűzfalszabályok motorja feldolgozzák az SNI-t, a gazdagépfejlécet és a szabálynak megfelelő URL-címet.

Ha továbbra sem található egyezés az alkalmazásszabályok között, a rendszer kiértékeli a csomagot az infrastruktúraszabály-gyűjtemény alapján. Ha még mindig nincs egyezés, akkor a rendszer alapértelmezés szerint megtagadja a csomagot.

Bejövő kapcsolat

DNAT-szabályok és hálózati szabályok

A bejövő internet- vagy intranetes (előzetes verziójú) kapcsolat a célhálózati címfordítás (DNAT) konfigurálásával engedélyezhető a bejövő internetes vagy intranetes forgalom szűrése az Azure Firewall DNST-sel az Azure Portal használatával. A hálózati szabályok előtt a NAT-szabályok elsőbbséget élveznek. Ha talál egyezést, a forgalom a DNAT-szabálynak megfelelően lesz lefordítva, és a tűzfal engedélyezi. A forgalmat tehát nem kell más hálózati szabályok további feldolgozásával feldolgozni. Biztonsági okokból az ajánlott módszer egy adott internetes forrás hozzáadása a DNST hálózathoz való hozzáférésének engedélyezéséhez és a helyettesítő karakterek használatának elkerüléséhez.

A rendszer nem alkalmazza az alkalmazásszabályokat a bejövő kapcsolatokra. Ha tehát a bejövő HTTP/S forgalmat szeretné szűrni, akkor a webalkalmazási tűzfalat (WAF) kell használnia. További információ: Mi az Az Azure Web Application Firewall?

Példák

Az alábbi példák néhány szabálykombináció eredményeit mutatják be.

1. példa

A google.com egyező hálózati szabály miatt engedélyezett a kapcsolat.

Hálózati szabály

• Művelet: Engedélyezés

Alkalmazásszabály

• Művelet: Megtagadás

Eredmény

A google.com való kapcsolat azért engedélyezett, mert a csomag megfelel az Allow-web hálózati szabálynak. A szabályfeldolgozás ezen a ponton leáll.

2. példa

A rendszer megtagadja az SSH-forgalmat, mert egy magasabb prioritású megtagadási hálózati szabálygyűjtemény blokkolja azt.

Hálózati szabálygyűjtemény 1

• Név: Engedélyezési gyűjtemény
• Prioritás: 200
• Művelet: Engedélyezés

Hálózati szabálygyűjtemény 2

• Név: Megtagadási gyűjtemény
• Prioritás: 100
• Művelet: Megtagadás

Eredmény

A rendszer megtagadja az SSH-kapcsolatokat, mert egy magasabb prioritású hálózati szabálygyűjtemény blokkolja azt. A szabályfeldolgozás ezen a ponton leáll.

Szabálymódosítások

Ha módosít egy szabályt, hogy megtagadja a korábban engedélyezett forgalmat, a rendszer elveti a vonatkozó meglévő munkameneteket.

Háromirányú kézfogás viselkedése

Állapotalapú szolgáltatásként az Azure Firewall háromirányú TCP-kézfogást hajt végre az engedélyezett forgalomhoz egy forrástól a célig. Például: VNet-A–VNet-B.

A VNet-A és VNet-B közötti engedélyezési szabály létrehozása nem jelenti azt, hogy a VNet-B-ből a VNet-A-ba tartó újonnan kezdeményezett kapcsolatok engedélyezve lesznek.

Ennek eredményeképpen nincs szükség explicit megtagadási szabály létrehozására a VNet-B és a VNet-A között.

Következő lépések

• További információ az Azure Firewall NAT-viselkedéséről
• Megtudhatja, hogyan helyezhet üzembe és konfigurálhat Azure Firewallt
• További információ az Azure hálózati biztonságáról