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.
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.
Feljegyzés
Az alkalmazásszabályokat a rendszer mindig a hálózati szabályok után dolgozza fel, amelyek a DNST-szabályok után lesznek feldolgozva, függetlenül a szabálygyűjteményi csoporttól vagy a szabálygyűjtemény prioritásától és a szabályzatörökléstől.
Í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 (200), amely a következő szabálygyűjteményeket tartalmazza: ChNetRC1, ChAppRC1.
A ChildRCG2 egy szabálygyűjtemény-csoport, amely a következő szabálygyűjteményeket tartalmazza: ChNetRC2, ChAppRC2, ChDNATRC3.
A következő táblázat szerint:
| Név | Típus | Prioritás | Szabályok | Öröklődés forrása |
|---|---|---|---|---|
| BaseRCG1 | Szabálygyűjteményi csoport | 200 | 8 | Szülőházirend |
| DNATRC1 | DNAT-szabálygyűjtemény | 600 | 7 | Szülőházirend |
| DNATRC3 | DNAT-szabálygyűjtemény | 610 | 3 | Szülőházirend |
| NetworkRC1 | Hálózati szabálygyűjtemény | 800 | 0 | Szülőházirend |
| BaseRCG2 | Szabálygyűjteményi csoport | 300 | 3 | Szülőházirend |
| AppRC2 | Alkalmazásszabály-gyűjtemény | 1200 | 2 | Szülőházirend |
| NetworkRC2 | Hálózati szabálygyűjtemény | 1300 | 0 | Szülőházirend |
| ChildRCG1 | Szabálygyűjteményi csoport | 300 | 5 | - |
| ChNetRC1 | Hálózati szabálygyűjtemény | 700 | 3 | - |
| ChAppRC1 | Alkalmazásszabály-gyűjtemény | 900 | 2 | - |
| ChildRCG2 | Szabálygyűjteményi csoport | 650 | 9 | - |
| ChNetRC2 | Hálózati szabálygyűjtemény | 1100 | 2 | - |
| ChAppRC2 | Alkalmazásszabály-gyűjtemény | 2000. | 7 | - |
| ChDNATRC3 | DNAT-szabálygyűjtemény | 3000 | 2 | - |
Kezdeti feldolgozás:
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 (200- 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ó a szabálygyűjtemény-csoportokon belül:
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-eltávolítások 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.
Feljegyzés
A HTTP- és HTTPS-protokollok (TLS-ellenőrzéssel) mindig az Azure Firewall töltik ki az eredeti forrás IP-címével egyenlő XFF (X-Forwarded-For) fejlécet.
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.
Feljegyzés
Hálózati szabályok konfigurálhatók TCP, UDP, ICMP vagy Bármely IP protokollhoz. Bármely IP-protokoll tartalmazza az Internet Assigned Numbers Authority (IANA) Protokollszámok dokumentumban meghatározott összes IP-protokollt. Ha egy célport explicit módon van konfigurálva, akkor a szabály tcp+UDP-szabályra lesz lefordítva. 2020. november 9-e előtt a TCP, az UDP vagy az ICMP protokollt kell érteni. Lehetséges tehát, hogy a dátum előtt konfigurált egy szabályt a Protocol = Any és a célportok = '*' beállítással. Ha nem kívánja engedélyezni a jelenleg definiált IP-protokollokat, módosítsa a szabályt a kívánt protokoll(ok) explicit konfigurálásához (TCP, UDP vagy ICMP).
Bejövő kapcsolat
DNAT-szabályok és hálózati szabályok
A bejövő internetkapcsolat a célhálózati címfordítás (DNAT) konfigurálásával engedélyezhető az Azure Firewall DNST-sel való bejövő forgalom szűrése az Azure Portal használatával című cikkben leírtak szerint. 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 Csatlakozás egyező hálózati szabály miatt engedélyezett.
Hálózati szabály
- Művelet: Engedélyezés
| név | Protokoll | Forrás típusa | Forrás | Céltípus | Célcím | Célportok |
|---|---|---|---|---|---|---|
| Webes engedélyezés | TCP | IP-cím | * | IP-cím | * | 80 443 |
Alkalmazásszabály
- Művelet: Megtagadás
| név | Forrás típusa | Forrás | Protokoll:Port | Cél teljes tartománynevek |
|---|---|---|---|---|
| Deny-google | IP-cím | * | http:80,https:443 | google.com |
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
| név | Protokoll | Forrás típusa | Forrás | Céltípus | Célcím | Célportok |
|---|---|---|---|---|---|---|
| SSH engedélyezése | TCP | IP-cím | * | IP-cím | * | 22 |
Hálózati szabálygyűjtemény 2
- Név: Megtagadási gyűjtemény
- Prioritás: 100
- Művelet: Megtagadás
| név | Protokoll | Forrás típusa | Forrás | Céltípus | Célcím | Célportok |
|---|---|---|---|---|---|---|
| Deny-SSH | TCP | IP-cím | * | IP-cím | * | 22 |
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. Ha ezt a megtagadási szabályt hozza létre, megszakítja a háromirányú kézfogást a kezdeti engedélyezési szabályból a VNet-A-ből a VNet-B hálózatba.