Sziasztok!
Csak elméleti szinten kíváncsiskodok h. ki hogy szervezi az IP ACL-jeit. Igazából rossz és jó megoldás nincs szerintem, inkább az a kérdés h. hogy logikus. Szóval ebben kérném segítségeteket, véleményeteket.
Kifejtem. Tételezzük fel, van egy 3 VLAN-os hálózatom, ahol egy L3 switch a router a hálózatok között. Nyilván nem szeretném h. minden elérjen mindent, ezt ACL-ekkel remekül lehet szabályozni. Igaz h. nem stateful firewall, de az legyen a hostok úri hóbortja a szegmentációs réteg alatt.
Ki hogyan definiálja az acl groupokat, benne az acleket? Pl. vlan1 ingress 'allow-10-10-10-x' vagy esetleg 'allow-web' szemantika alapján? Tehát inkább szolgáltatás? Vagy inkább forrás network/cím alapján készítünk groupokat?
Nyilvánvalóan ugyanez a kérdés az egress-re is érvényes, de maradjunk annyiban az egyszerűség kedvéért h. most csak ingress és IP filtert kezelünk.
Köszi a válaszokat!
- 438 megtekintés
Hozzászólások
Sehogy. Nálam a vlanok közt olyan eszköz van, ami tud rendes stateful szűrést.
Az pedig, hogy IP-re range-re, és/vagy portra ilyesmire szűrsz, mindig a feladattól függ.
- A hozzászóláshoz be kell jelentkezni
Igen, ez az optimális, bár nyilván ez is nézőpont kérdése, mert jobb L3 switcheken az ACL wirespeed. Itt inkább arra gondoltam h. ha nincs stateful firewall, hanem csak a belső vlan szegmentációt egy L3 switchel csinálod, akkor hogy néz ki egy ACL lista pl, ki mire esküszik.
Azért lássuk be, elég szépen el tud szabadulni az ACL pokol, ha következetlenül csak csapdosod hozzá a szabályokat.
Inkább arra a problémakörre gondolok h. logikailag pl. egy acl groupba raknék egy source networköt, annak a szabályai lennének abban a csoportban. De van mondjuk 4-5 network és van olyan szolgáltatásom ami mindegyik számára elérhető kell legyen. Így bár logikus(nak tűnik), de mégis redundáns az ACL-em.
Ugyanakkor ha meg azt csinálom h. pl. 'allow-http', akkor abban meg a http-re vonatkozó szabályaim lesznek redundánsak a többi network source miatt.
Az érdekelne h. kinek melyik megközelítés jött be jobban.
- A hozzászóláshoz be kell jelentkezni
Szerintem ez nem wirespeed-nem wirespeed kérdése, hanem security és menedzselhetőség.
ACL esetén definiálod a visszafelé menő forgalmat is egy másik ACL-ben? Akkor a szerver vlan(ok) ACL(jei) tartalmazzák nagyjából az össezs többi ACL fordítottját, szóval ACL esetén az "ACL pokol elszabadulása" by design...
Ahol ACL-t kellett használni (tűzfalak mellett, nem helyett), ott egy-egy szolgáltatásnak volt dedikált szekciója, ami egy kommenttel kezdődött. Ekkor meg előjön az, hogy van-e overlap a köülönböző szolgáltatások (portok) között, ...
- A hozzászóláshoz be kell jelentkezni
fixme, de az ingress és egress ACL használata nem kötelező. Egy VLAN interfészen ingress szűrsz, attól még a válasz kimegy ha nincs egress filtering. Ha van egress filtering, akkor az történik amit te írtál, mindent inverz módon engedni kell egress ruleokban is.
Tűzfalak helyett nem is használsz ACL-t, de alapvető szegmentációra tökéletes egy belső hálózaton szerintem.
A kérdés inkább elméleti (ha ez van, akkor mi az a fajta gyakorlat, ami bevált, hogy minimalizálja az ember a káoszt)
- A hozzászóláshoz be kell jelentkezni
nem kötelező egyik sem, de ha minden vlan-interfészen van ingress, akkor a válasz a szerver-vlan ingress-ACL-ében lesz ledefiniálva. Szerintem a szolgáltatásonkénti bontás jó, de az ACL-alapú megoldás gány lesz mindenféle módon.
Sima LAN-on user-szegmensek közt vszleg any-any-permit kellene (pl. Teams hívás 2 résztvevő esetében direktben megy), a szervereket meg védd tűzfallal!
- A hozzászóláshoz be kell jelentkezni
A szerverek védelme tűzfallal evidens. Még OUTPUT szabályok is vannak az elképzelt konfigurációban, ahogy azt illik (pl. DNS-re stb.)
Itt nem határvédelemről beszélünk és extrém security-ről, hanem inkább arról h. a hálózat szegmentálást még megfűszerezi az ember egy kis "védelemmel", hogy aminek nem kell az lehetőleg ne érkezzen be egy VLAN-ba, amit a fenti példában egy L3 switch routeol.
Kicsit kifejtve a rétegeket az elképzelt hálózatban (csak h. tiszta legyen):
- 1. L3 edge routing (edge, ide jön a net, minden alatta lévő eszköznek ez a réteg a default gw)
- 1/b. Csak h. mindenki megnyugodjon, ide tehetünk egy alkalmazástűzfalat / L7 filtert
- 2. L3 inter vlan routing / aggregacio (itt futnak össze a VLAN-ok, de belül route-olna is a belső vlanok között)
- 3. L2 access switching (erről a topicban szó sem volt)
A 2-es szintről beszélünk és kizárólag arról. Tehát h. egy L2 porton lóg-e szerver v. gizike lóg rajta, az nem releváns.
- A hozzászóláshoz be kell jelentkezni
Azt kell megnézni, hogy mit tud az eszközöd hardverből kezelni, az ingress vagy az egress ACL-t.
- A hozzászóláshoz be kell jelentkezni
Mindkettőt. De nem erre vonatkozik a topic alapvetően. Inkább csak elméleti jelleggel, amolyan "ki hogyan valósítaná meg".
- A hozzászóláshoz be kell jelentkezni
ki hogy szervezi az IP ACL-jeit.
switcheken?! sehogy!
Legfőképpen mert a switch nem biztosnági eszköz, aztán pedig mert ezeket általában teljesen külön - nem security - csapat manageli.
a switch a csinálja csak a feladatát, szigoruan L2 szinten.
L3 és felette pedig a tűzfalazás egy 'rendes' tűzfal dolga.
szerintem.
- A hozzászóláshoz be kell jelentkezni
Aha. Tehat aki kifundalta az L3 switchet ami meg BGP-t is tud, darabja csilliardokert az disznek tette bele ezeket a funkciokat es fejlesztett kulon evekig h jo legyen.
bocs, de ezt nem tartom tul szakmainak.
ezen felul amit irsz, az sem valid, mert te kb campus switchrol beszelsz. Igen, lehet azt rendszergazda manageli. De o nem nyul hozza az aggregacios switchekhez.
- A hozzászóláshoz be kell jelentkezni
nézd, biztosan mindenki másképp csinála, és az IT nak is rengeteg területe van.
Te azt kérdezted ki hogy csinálja. Én elmodtam.
Meggyőzni semmiről senkit nem akarok, mindeki azt és úgy csinál amit akar - de az meg az én véleményemet nem befojásolja:
Én IT security-val foglalkozom több mint 20 éve. De a switch az mindenhol 'csak' switch maradt.
Persze, lehet egybegyúrni egy routerrel is, és akkor már L3 switch nek is hívhatod :)
lehet bele ACL-eket is tenni, de ettől még nem lesz tűzfal. - még akkor sem, ha a marketingesek annak hívják, és/vagy annak adják el ;)
A netwok az általában csak egy alap réteg, ami támogathatja a biztonság növelését sokminden módon, de amint hálózati szeparáció a cél, vagy ACL-ek - tehát hogy hitelt érdemlően kontolláld ki merre mit csinálhat - onnantől kell 'rendes' tűzfal, proxy, és/vagy alkalmazás szintű megoldások. Ehhez persze elengedhatetlen egy megfelelően tervezett és kivitelezett hálózati toplógia is - amit a switchek és routerek biztosítanak.
szerintem.
- A hozzászóláshoz be kell jelentkezni
Én sem akarlak meggyőzni semmiről és nézőpont kérdése is valahol, szóval teljesen igazad van, ez is egy szemlélet.
Ugyanakkor azt szerintem nem lehet figyelmen kívül hagyni h. manapság már annyira vékony az átmenet egy switch és "buta" router között, pláne software defined alapokon, hogy ezek a funkciók össze tudnak mosódni.
Azt egy pillanatig sem állítottam h. az egyetlen védelmi vonal egy L3 switch lenne a hálózatban és természetesen az nem is lenne egészséges. Ugyanakkor az okosabb aggregációs switchek már routeolnak is, így alap dolgokat szerintem ott lehet és érdemes is szűrni, mert viszonylag közel vannak a forráshoz (ez inkább egress oldalon igaz) és alap dolgokat nagyon hatékonyan tudnak megtenni (lehet vitázni h. wirespeed v. nem wirespeed :))
Szóval az h. egy switch csak egy switch már nem áll meg a lábán az én nézőpontom szerint. De azt nem állítottam h. egy application firewallt ki lehet vele váltani. Sőt, azt sem h. egy stateful firewallt ki lehetne.
- A hozzászóláshoz be kell jelentkezni