Názory k článku Firewall IPFW ve FreeBSD praktickým pohledem
-
Děkuji za velmi zajímavý článek. Ale přiznávám, že mě překvapuje, že IPFW někdo dneska používá. Já znám tři adminy, kteří provozují komplet sítě jen na FreeBSD (dva jsou provideři), jeden má storage, ale už je to dlouho, snad šest let, co přešli na PF.
S tím souvisí moje otázka, Ano FreeBSD má tři firewally, ovšem IPF je z hlediska vývoje a komunity mrtvý, ten už opouští i NetBSD, Jak je to s IPFW z hlediska rozšířenosti, má opravdu IPFW aktivní development? Používá se ve FreeBSD komunitě hodně?
Pak mám ještě jednu poznámku, v Linuxu už se taky nazývají síťová rozhraní podle chipu, minimálně na RedHatu 7 tomu tak je.
-
Vyvoj az tolik nesleduji, v release notes si vyhledejte ipfw a uvidite, ze se neco kolem deje. Na druhou stranu - jake zmeny byste u fungujiciho firewallu ocekaval? Myslim, ze kolem iptables taky uz moc zmen nebude. Je to proste funkcni vec a spise bych ocekaval jen opravy chyb.
Dle meho bylo posledni velkou zmenou odstraneni kernel option ipfirewall_forward. To byla pomerne pouzivana vec, ale musela se kompilovat, protoze v generic kernelu nebyla. K tomu doslo ve FreeBSD 10. -
daemon (neregistrovaný)
Já bych to maličko poopravil - ve FreeBSD se síťová rozhraní nejmenují podle čipu (takové tvrzení je lehce zavádějící), ale podle jména příslušného device driveru. Mohou tam být rozhraní, která neexistují v podobě fyzického čipu, např. typu "link aggregation", "port bonding", "port channel", podle toho, jak tomu kdo říká. Prostě LACP. Driver tohoto se jmenuje lagg, takže příslušný interface pak bude lagg0, lagg1 ... Podobně to bude v případě VLAN driveru vlan - vlan0, vlan1 ...
-
Diky za upozorneni. To je tak, kdyz se neco pise rychle a neoveri. Ale dovolim si opravit i vas. Proste LACP asi taky neni uplne spravny vyraz. LACP je protokol, ktery se muze (ale i nemusi) pro vyjednavani link agregace pouzit. Muzete mit klidne statickou link agregaci bez lacp a take bude pojmenovana laggX.
-
PolyCajt (neregistrovaný)
Za článek díky. Pokud totiž člověk není zrovna fajnšmekr, tak nedává moc smysl dá(va)t stovky, tisíce a více dolarů za krabičky děravé jak řešeto s přibalenými dírami jako CVE-2016-1329 (Nexus), CVE-2014-3393 (ASA), CVE-2015-6323 (ISE), CVE-2015-6336 (Aironet), CVE-2012-4088 (UCS)
Přičemž nepomůže, když se ty samé peníze utratí jinde, např. u Juniper: CVE-2015-7755, CVE-2015-7756 (ScreenOS), nebo Fortinet: CVE-2014-2216 (FortiOS) atd.
Nechci slevu zadarmo. No nekup to!
-
Lukáš MalýZlatý podporovatelDík za pěkný článek, budu se těšit na dalsi. Jakožto dlouholety uživatel FreeBSD na serverech používám PF. Ale věřím že může mít někdo potřebu používat IPFW. Ta možnost záměny tu je.
-
Petr Urban (neregistrovaný)
S IPF jsem se setkal poprve cca před 10. lety na HPUX .. Používá se ve většině komerčních UNIX systémech Solaris , AIX, atd. Za mě tenkrát bylo příjemné , že na pochopení to bylo o něco jednoduší než iptables. Článek mi připadá jako takový základní rozdíl mezi IPTABLES a IPF ..
-
Matúš (neregistrovaný)
Môj najväčší problém s ipfw bol v tom, že jeho "nat" funkcie pôsobia dojmom, ako keby šlo len o nejaký provizórny "quick fix" a nie o jednu z primárnych funkcií firewallu. V starších verziach to dokonca vôbec nebolo súčasťou ipfw, ale riešilo sa to cez externý user-space proces/daemon "natd".
V porovnaní s ostatnými funkciami je pre nat v "man ipfw" aj v súčasnosti len minimum dokumentácie a dokonca sa mi nepodarilo nájsť ani len takú základnú vec, ako je príkaz na zobrazenie aktuálneho obsahu "natovacej tabuľky". Ak niekto viete, ako sa to dá spraviť, napíšte prosím.
Preto som nakoniec skončil pri používaní pf, v spojení s nástrojmi ako "pftop" mi to príde ako oveľa viac "mature" alternatíva.
-
zadny ipfwtop neznam a myslim, ze neexistuje. Puvodni nat (ipdivert) opravdu bezel v userlandu, ale odhadem uz to bude skoro deset let, co funguje kernelovy NAT.
Stary i novy nat pouzivaji ale stejny zapis, takze prechod nebyl problem.Na webu jsem zahledl ukazku kodu na vypis nat tabulky. Az bude chvile, zkusim se na to podivat.
