Kedvenc tűzfal (distro)?

Titkosítás, biztonság, privát szféra

pfSense
12% (42 szavazat)
RouterOS
7% (24 szavazat)
saját megszokott Linux disztró + iptables stb.
42% (144 szavazat)
IPFire
1% (2 szavazat)
IPCop
2% (7 szavazat)
Endian
3% (9 szavazat)
ClearOS
1% (2 szavazat)
Zentyal
3% (9 szavazat)
Sophos UTM
1% (4 szavazat)
Sphirewall
0% (0 szavazat)
Smoothwall
1% (2 szavazat)
Untangle
0% (1 szavazat)
Vyatta
1% (2 szavazat)
OpenWRT
12% (41 szavazat)
Tomato
4% (13 szavazat)
m0n0wall
1% (3 szavazat)
Egyéb, leírom
10% (34 szavazat)
Összes szavazat: 339

( STP | 2013. 12. 28., szo – 17:04 )

Vyatta helyett lehetne Vyatta/EdgeOS.
Vagy külön EdgeOS is. Ha már a Vyatta lényegében bezárásra került.

( ncc1701 | 2013. 12. 28., szo – 17:50 )

Megszokott aktuális stabil debian + iptables.

( psychic | 2013. 12. 28., szo – 17:54 )

"saját megszokott Linux disztró + iptables stb.", az előre gyártott megoldásokkal az a bajom, hogy általában nem lehet annyira testre szabni őket, hogy az összes igényt kielégítse.
Alapból ubuntu vagy debian szerver + iptables + a varázslat: ipset :)
Ezt az egészet megfejelem egy saját webes felülettel, amin az egyszerűbb műveleteket könnyen el tudom végezni.

Ha valaki igazán ismeri a dolgot szerintem annak tök8 hogy ír egy sor iptablest vagy összekattingat valamit egy felületen.
A nagy cumik akkor jönnek amikor olyat szeretnél a limitàlt cuccal amit nem tud, vagy reszelni kell olyankor viszont egy hozzáértő simán belenyúl a natúr iptablesbe ,a patkolt limitált disztribbe meg örül mire megtalálja amit szeretne....,és koránt sem biztos hogy megtudja oldani.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

De pont azt mondja, hogy amikor a nem annyira hozzáértő kerül oda (van olyan környezet bőven, ahol ez előfordul, vagy esetszerűen, vagy azért, mert eleve ez az elvárás), akkor az könnye elvérzik egy hozzáértő által összepakolt scripten. Egyébként meg tapasztalataim szerint, aki képes értelmes iptablest csinálni, az képes ezt egy GUIn is megugrani (tudom, kivéve, ha gui nem támogatja, amit akar, de szerintem azért ez nem olyan sűrű eset)

( PtY | 2013. 12. 29., v – 12:13 )

Bár szavaztam, de azért leírom.
A pfSense nem véletlenől áll az első helyen, szerintem is a legjobb a cél-appliance-ek között. Ellenben csak olyan helyre, ahol csak tűzfal kell, meg vpn endpoint, esetleg failover/laod balanced WAN.
Ha ennél több kell, akkor inkább Endian a kényelmesebben konfigurálható proxy-k és plusz szolgáltatások miatt.
Tudom, hogy a pfSense pluginelhető, de korántsem olyan kényelmesen és sokrétűen konfigurálható a web és/vagy smtp proxy-ja, mint az Endiannak.
Fő szempont az is, hogy gyakran a telepített/beállított rendszert át kell adni másnak, aki majd üzemelteti/reszelgeti, és egy Endiant fényévekkel könnyebb így átadni, mint egy pfSense-t.
--
PtY - www.onlinedemo.hu

Mivel _tűzfal_ distro volt a kérdés, így a proxy és egyéb fícsörök nem igazán relevánsak. (Vagy ha igen, akkor karácsonyfa.)

De ha már anekdotázunk, akkor Prox3.0/KVM alatt ne nagyon állítsátok át a pfSense hálózati interfész(eke)t VirtIO net-re, mert kb 1/1000 részére zuhant az átvitel az E1000-hez képest. (Legalábbis tegnap ezzel ßhoptam.)

Jó, de az is tűzfal distro :) Tehát releváns. Viszont vannak a tűzfal szolgáltatáson túl más igények, amik megszabhatják, hogy a tűzfal disztrók közül melyiket érdemes választani. Úgyhogy akkor karácsonyfa ;)

Prox/KVM tekintetben meg ha 100Mbit kell, akkor rtl, ha Gbit, akkor e1000. És más virtualizációs környezetben is e1000 legyen az vmWare, Xen, HyperV vagy más, ami tud ilyet adni.

Nem véletlen, hogy az e1000-es drivere 2002 (ha jól tévedek) óta változatlan. Csöppet stabil és megbízható.
--
PtY - www.onlinedemo.hu

„Őszintén ajánlják a tűzfalak futtatását (pc) virtualizált környezetben?”
Alapesetben? Nem.
De nálam az volt a feladat, hogy több, különböző VLAN-ban lévő VM-et kellett kívülről (S2S és RW) OpenVPN-en keresztül elérni, különböző szabályrendszer alapján. Ma már nem pfSense-el indulnék neki.

A "tűzfal distro" avagy UTM?
Vajon a postfix az "plugin"?

Izlés kérdése, hogy egy proxy az már UTM-e (a Zorp vajon mi?) vagy hogy tűzfal alatt még mindig azt értjük-e, hogy valami tud kulkászni az IP headerben?

Őszintén ajánlják a tűzfalak futtatását (pc) virtualizált környezetben?
Aztán ezekről jól el lehet vitatkozgatni! :))

Ó hogyne. Az aktuális buzzword a "software defined networking", mindenki erre megy most. Van a cisconak is valamije, ha jól tudom, a juniper tolja a Firefly hostot, ami direkt a vmwareben futó izékhez van, lassan jönnek majd a vfireflynak nevezett vackukkal (legalábbis remélem), ami virtuális SRX tulajdonképp, az SSL VPN és a nagy közös tűzfal policy control (UAC) dobozaik már most is vannak virtuálisan. De ott pl a vyatta, meg a fentiek közül rengeteg, amit javallanak virtuálisan is.

Ezzel együtt imho leginkább a klasszikus nagyok még ott tartanak, hogy amit eddig fizikai dobozon adtak, most virtuálisan is kezdik tenni, az igazi fasza integráció a virtualizációs réteggel /meg annak managementjével/ még várat magára. Bár töredelmesen bevallom, az openstacket még nem néztem annyira meg, de első bliccre switchinget tud csak leginkább..-

Köszi a tündéri választ! Miközben abszolút nem vagyok hálózati szakemeber, éppen az ilyen jelenségekre próbáltam a kérdésekkel felhívni a figyelmet.

PtY: Tudom, hogy a pfSense pluginelhető, de korántsem olyan kényelmesen és sokrétűen konfigurálható a web és/vagy smtp proxy-ja, mint az Endiannak.

Mert a pfSense tartalmaz némi plugint, de leginkább egy php-ben megírt kezelő felület. A "smtp proxy plugin" nincs is benne, "csak" postfix, ami teljes kiépítésében abszolút UTM jellegű dolgokat tud. Tehát nem degradálnám csak pluginelhetőnek.
A m0n0wall mondjuk tűzfal (a pfSense öregapja), míg hozzá képest a pfSense tekinthető UTM-nek. Ugyanakkor pl. a zynos-ben (P335) lehet definiálni nem csak IP, hanem "hardware" ethernet filtert is, ami ugye << mint layer 7. Pedig ez a szerkezet messze van az UTM-ségtől. Szóval nagy itt a káosz!
A "software defined networking" számomra annyit tesz, hogy tipikusan "felhúzok még egy vm-et" alapesetben hol a tűzfal? Erre próbálnak központi megoldást találni vhost szinten magas szintű kezelőfelülettel. Ez igaz lehet az openstackre is. Bár erről egy régebbi Motorola rendszer jut az eszembe. Úgy néz ki ott tartunk, hogy nem csak az összes zenént szerezték már meg, hanem a nevek is elfogytak! :)))
Nem ide tartozik, de külön állatfaj a windows tűzfal, amit inkább layer 8-9 szintűnek lehetne nevezni. :) Míg a tűzfal primitív algoritmusa a "befelé senki", addig a windows esetén a "hibás beállítások és vírusok nem ki" algoritmus a jellemző. És a csak linuxhoz értők ezt igen nehezen fogják fel. :)

"Mert a pfSense tartalmaz némi plugint, de leginkább egy php-ben megírt kezelő felület"

Ja, ne már! A pfSense egy appliance, aminek a management felülete php. Nem a php kód maga a disztró, az csak annak az egyik része. Mögötte van még jópár script.

smtp proxy meg van benne. Spamszűrő, vírusszűrő - szerintem teljes mértékben kimeríti az smtp proxy fogalmát, még akkor is, ha az csak egy postfix mögé/elé aggatott frontend/backend szolgáltatás.

Hogy VM szinten hol a tűzfal, az attól függ, hogy hogyan néz ki a fizikai és a virtuális interface réteg. Ha egy adott fizikai if mögött csak egyetlen virtuális if van, és az törénetesen épp a tűzfal külső lába, akkor elég jól meghatározható, hogy hol van a tűzfal. Ha az adott fizikai vonalon több IP vagy több IP tartomány van, akkor tűzfalból is lehet több az adott fizikai if mögött - nyilván itt már lehetnek érdekes helyzetek, de fizikai eszközök esetében sem történik más, ha egyetlen kábelen kapsz több IP-t vagy több tartományt.
--
PtY - www.onlinedemo.hu

Grat!
Bár ugyanezeket írtam, sikeresen lefordítottad: appliance.
A disztró meg az a sok varázslatos script - úgy hívják freeBSD 8.3. Néhány init szkript és alapértelmezett konfiguráció módosítva. Két féle - embedded és pc platformra kihegyezett - kernellel lényegében két disztró. A többi meg javarészt php és nem csak a webes része. Itt belekukkanthatsz.

Azt nem állítottam, hogy nincs benne smtp proxy. Helyette így kell olvasni: A postfix MTA nem csak egy kis pluginocska, hanem nagyágyú. Korábban arra utaltam költői kérdéseimmel, hogy az ebben a hozzászólásodban lekicsinyelt smtp proxy "pluginocska" nem is plugin, hanem egy robosztus MTA. Mint ilyet, nehéz konfigurálni. Viszont mindent tud.

A hol a tűzfal? kérdés - már ha sikerül értelmezni a mondatot - a VM-et meggondolatlanul alkalmazó, megfontolatlan szakember költői kérdése. Mármint a mondat második magyarázó részében. Ravasz dolog ez a magyar nyelv!

Hát, akkor kaptál választ a költői kérdésedre :)

Egyébként ja, az SDN valóban kb ennyi, hiszen a többi ki van már találva, és az nem akarják újra, jó a meglévő ethernet köré épülő cucc (hálistennek), de ennek azért van értelme. Persze lényegesen új sosincs a nap alatt, folyamatosan megy körbe a szakma :)