mindig is érdekelt ez a téma, és még vas meg a kellő elszántság is meglenne rá, hogy nekiessek, de annyira de annyira nincs rá szükségem 
most az OpenWRT megoldja ennek nagy részét (bár a tűzfal-konfigolós részből mindenképp fogok lopni 
)
a cikk viszont abszolút hasznos, ha egyszer szükségem lenne erre, mostmár tudom honnan induljak ki 
Pont a napokban akartam tűzfal tesztet csinálni, hogy mit mutat az elementary os.
De a wigwam féle teszt oldal nem megyen.
Már leszoktam róla de régen még win en a comodo tűzfalat nagyon szerettem.
Hiányzott is linux on kérdezés és szabályalkotás. Igaz így is csupasznak érzem magam de elvileg van tűzfala a linux nak de, hogy mik a szabályok fogalmam sincs vagy, hogy mennyire lehetek védett? 
A cikket elolvasva nekem valami szoftveres, és megfelelő gui val rendelkező tűzfal kellene.
[ Szerkesztve ]
A vi helyett lehetne használni a 'nano'-t. Ha valamiért lehet gyűlölni a linuxot az a fos 'vi' miatt lehet.
Persze ez csak a saját személyes véleményem.
A nano debian alatt alapból fenn van.
[ Szerkesztve ]
+1 a nano-ra. Vi-től nekem is áll a szőr a hátamon
Cikkhez: Jó kis olvasmány volt, nagyon régóta tervben van, csak valahogy mindenre marad időm ezen kívül, de így, hogy összeszedted, kezdetnek lehet beleugrok, kis finomításokra mindig van idő .
szasztok
egy kis "trollkodás":
ezt az egészet miért nem célszerű inkább egy routerre telepíteni pl openwrt alá?
mik a pro és kontra pontok egy extra pc mellett?
amúgy grat a cikkhez, nem kevés meló
Ha van bármi más tennivalója, mint netmegosztás, pl: torrent, akkor bizony már kevés lesz a router. nasként is funkcionálhat pl.
Tetszett az írás, köszönjük
Pont annyira szájbarágós, amennyinek kell lennie, így aki picit is konyít a Linuxhoz, egész jó iránymutatást kaphat. 
Csak apróságokba kötnék bele.
Server, homepage, software, hardware: ezekre mind van magyar szó (szerver, weboldal/honlap, szoftver, hardver). És nem azért, mert nem tudok angolul, hanem egész egyszerűen nem "eszek egy apple-t" hanem "eszek egy almát", mivel magyarul írok. És tényleg nem kötekedésből írom ezt, viszont nagyon sok helyen így látom (annak ellenére, hogy a nyelvi ellenőrzők rendre kijavítanák a magyar szavakra).
A "ha valaki wifit szeretne...." részhez:
A probléma megoldható egy AP módra képes Wifi adapterrel és a hostapd csomaggal. Évek óta használok erre egy Atheros chipsetes kártyát a tűzfal PC-ben, és teljesen bevált.
A cikket elolvasva nekem valami szoftveres, és megfelelő gui val rendelkező tűzfal kellene.
Rengeteg ilyen létezik, pl:
http://openwall.com/
http://www.smoothwall.org/
http://www.zentyal.org/
Én is azt gondolom, hogy hasznosabb lett volna ezt a koncepciót az Openwrt oldaláról megközelíteni. Könnyebben elérhető, olcsóbb és lényegesen kevesebbet fogyaszt, mint egy akármilyen PC, ráadásul a legtöbb háznál amúgy is kell egy router. Persze sok mindent át lehet emelni, de azok, akiknek szükségük van ilyen információra, talán nembiztos, hogy olyan könnyen megtaláljá az átfedéseket.
Egyébként van a cikkben egy komoly pontatlanság, ahol azt állítod, hogy egy interfésszel nem, vagy nem jól fog működni. Ez nem igaz, egyszerűen virtuális interfészeket kell létrehozni és működni fog bármilyen internet kapcsolattal rendesen, hacsak bele nem fut az egy fizikai interfész által képzett korlátba.
Dchard
[ Szerkesztve ]
Az első cikkem, a korrektor remek munkát végzett! ( volt dolga ) Neki is köszönöm!
Köszönet mindenkinek a hozzászólásokért!
Egy két dologra válaszolnék.
VI vs VIM - megszokás kérdése, mindenki azt használ amit szeret
router hardvernek - gyengébb. Egy vasra sokminden mást is rá lehet bízni ahogy azt előttem Vladi is emléítette.
Igen, léteznek szép grafikus, web adminisztrált megoldások. Az olyan mint amikor "zacskós levest" eszel, nem tudod mi van benne, ezt te építed magadnak, tudod miből csináltad.
Igen VLAN-nal meg lehet oldani egy csatolón. De minek ?! 2000 Ft egy Gbe kártya.
A "v. 2.0" már hasznosítani fogja a VLAN-ok adta előnyöket. 100%-osan szeparált vendég háló. Viszont komolyabb switch is fog kelleni hozzá. Éppen dolgozom az ügyön.
Viszont visszakanyarodva kérdeznék mielőtt hülyeséget írok.
VLAN "alatt" van pppoe?
Csak néhány gondolat a cikkhez:
* A 'saját tűzfal készítés élményén' kívül sajnos ennek manapság nem sok értelme van... miért:
- Mert már sok professzionális, kész, működő megoldás létezik, amiket nagyon könnyű telepíteni, és üzemeltetni. A tűzfal lényege pedig nem a barkácsolás.
- Sajnos azt kell mondjam, hogy otthoni környezetben manapság már ez a fajta tűzfalazás (csomagszűrő + proxy) elavult, és nagyjából semmire nem jó. Ez manapság arra való, hogy a klienseket elszeparáljuk a szerverektől, nyomtatóktól, egyéb hálózatoktól... erre pedig leginkább céges környezetben van szükség.
Miért?
Mert a https, és http forglamat kiengeded, hiszen a júzerek netezni szeretnének...
Ezen a kettőn pedig BÁRMILYEN forgalom képes működni. És a bármilyent szó szerint kell érteni. Mamapság bártmit be lehet csomagolni http (vagy annakk látszó) protokollba, amit a proxy simán átenged...
a https kiengedése pedig maga a paradicsom (a 'gonosz' forgalmak szempontjából), mert azzal még a proxy sem tud/akar semmit kezdeni, 'csak átengedi' így pedig már http-be sem kell csomagolni, bármit lehet forgalmazni kifelé...
És ha ez a bármi pl egy VPN, ssh, vagy hasonló, akkor tulajdonképpen akarva vagy akaratlanul beengedtél idegeneket a hálózatodba, amibe a tűzfalad nem fog (mert nem is tud) beleszólni!
* A cikkben vázolt tűzfalszabályok nagy rész teljesen felesleges, pl: loc-loc irányú forgalmak.
Ezek ugyanis el sem fognak jutni a tűzfalig, mert ugyan abban a natworkben vannak, így direktben egymással kommunikálnak. Ilyen szempontból erősen félrevezető is a cikk ezen része, hiszen a kevésbé hozzáértők azt hihetik, hogy egy tűzfal képes megakadályozni/korlátozni azonos hálózatban lévő gépek közötti forgalmat. De valójában ez nem igaz!
Manapság nem attól kell parázni (értsd védeni a hálózatodat) hogy valaki direktben eléri a desktop gépedet. Ezellen ugyanis egy 'szappantartó' is véd, ha minden forgalamt maszkol kifelé (MASQUERADE)
Otthoni felhasználás esetén a valós probléma az, ami a felhasználók gépére kerül, és onnan KIFELÉ kommunikál. (és így gyorsan részese is lehet egy botnetnek pl)
Márpedig oda az esetek 99.98%-ban úgy kerül valami hogy a júzer le - (vagy épp fel) tölti. Akarva, vagy akaratlanul az mindegy. Ezellen pedig egy ilyen jellegű tűzfal sajnos NEM VÉD.
* Hálózattervezés szempontjából pedig egy kliensekből állló hálózatot védettnek nyilvánítani elég nagy tévedés. Pont ez a hálózat az, AMITŐL a többit védeni KELL!
(ezzel az utóbbi ténnyel sajnos sok magát nagyra tartó cég sincs tisztában)
PS:
Remélem ezzel senkinek nem törtem le a lelkesedését...
Igazad van, sokmindenben nem véd, a userek és a böngészők hülyeségeitől pláne , és a squid se üdvözítő, de mégse felesleges egy otthoni tűzfal proxy, jókat lehet vele játszani 
.
Én például örömmel tapasztaltam, hogy a Squid képes ipv6-ipv4 "tunellingre", vagy nem is tudom mi a jó szó.
A következőt csináltam:
Squid telepít, freenet6 kliens telepít. Létrejött egy ipv6-os interfész. Egy kis squid bütykölés után a helyi hálózaton lévő ipv4-es címmel rendelkező gépek simán tudtak böngészni ipv6-os oldalakat, teszteltem a google ipv6 tesztelőjével, csak ipv6-os dns nevekkel és ipv6-os ip címekkel is. Lényegében a legegyszerübb módja az ipv6-os átállásnak. Az volt a legszebb, a tűzfallal és routinggal nem nagyon kellet bajlódni (érdemes azért kívülről tiltani, belül elég talán annyi ,hogy csak a szükséges szolgáltatások legyenek telepítve). Le lehet tiltani az ip forwardot, mert lényegében mi történik? A squid az egyik interfészen kommunikál a külvilággal, másikon a belső hálózattal. nem kell itt semmit forwardolni. A legtöbb szolgáltatás ma már működik squid-en keresztűl, és bár tapasztalatom nincs tán még a torrentezés is megoldható.
A következő amivel lehet még mókolni: proxy autokonfiguráció (dns és/vagy dhcp által), esetleg transzparens proxy, ami bonyolultabb pl https esetén se triviális.
[ Szerkesztve ]
Pedig a vi nem is a Linux találmánya, hanem a Unixé... Nem mellesleg nem adnám semmiféle egyéb szerkesztőért.
Az íráshoz: igaz, hogy egy portscan elég gyorsan lefut, de ha defaulton hagyod pl. az ssh szervert, akkor a script-kiddie-k is megtalálnak, első körben legalább őket érdemes elhajtani a búsba.
Ezenkívül a shorewallt sem értem, számomra sokkal átláthatatlanabbnak tűnik, mint egy iptables konfig. De ez az én problémám
[ Szerkesztve ]
kés a szívemben
Nyilván a legjobb biztonásgi fokozat az, ha nem fizetsz elő internet szolgáltatásra és kiforrasztod a hálózati csatlakozót az alaplapról.
A második ha képzett vagy. Nem kattintasz minden csillivilli tündibündi csillámpónira
Sokadiknak azért jó egy ilyen megoldás.
Nem is az hogy felesleges, csak pl PC alapon egy kicsit költséges és túlméretes még CF kártyáról is. Mondjuk egy Raspberry Pi-n (igaz azon csak egy Ethernet port van, de ettől lenne még izgibb ) nem is olyan hülyeség ilyennel bajlódni, vagy pl, ha már megy egy szerver folyamatosan, akkor virtuális gépben. Úgy is divat lesz lassan a hálózatvirtualizálás is.
[ Szerkesztve ]
Kifelé nincs ssh 
Skiddie lenyomja a torkomon a portscan-t én meg nézem a logban az i++ portszámot a forrás ip-ről.
Támadás nem csak kívülről érkezhet, hanem belülről is, mi több, ez a leggyakoribb - ezért nem csak, hogy high portra tenném az ssh-t, hanem a root logint is tiltanám.
Internet felé néző ssh-m van otthon, 22-es porton dőltek befelé a userid+passwd párosok. Felraktam magasra, megszűnt.
[ Szerkesztve ]
Tökéletesen igazad van!
Belülről nem félek "támadástól" . Balgaság tudom.
Ha lenne kifelé elérés, valószínüleg magas port lenne és PermitRootLogin no .
+dyndns +vpn
De az elérés semmiképp sem magára a tűzfalra lenne, inkább portforward egy gépre(akár virtuális) mögötte... De ez már megint túlmutat egy otthoni rendszeren
Köszi a cikket!
Szerintem hiány pótló!
Lesz egy két dolog, amit használni fogok belőle.
Használt már valaki ilyen célra raspberry pi-t?
Hüyeség, ahhoz kevés rajta az RJ45
[ Szerkesztve ]
Ne legyen kés a szívedben... 
Tanulni mindig jó és hasznos... csak az baj, amikor 'rosszat tanul' valaki...
Csak ezért szóltam hozzá egyátalán.
Egyébként én is ilyennekkel kezdtem pályafutásomat (10+ éve majd tűzfalakkal foglalkoztam 'nagyban' is sok évig... (jelenleg még nagyobban, de ez már nem feltétlenül a jó irány) de mégis egy openwrt-s ruoterem van otthon, mert az pont oda való.
[ Szerkesztve ]
És? Ha wifi routernek használjuk akkor bedugunk egy WiFi donglét LAN oldalnak, de létezik USB-s Ethernet adapter vagy lehet VLAN-al is szórakozgatni (nem W!!!LAN)
Az mál túl elborult lenne GPIO-ra építeni egy hálókareszt (meg lehet a sebessége is gyér lenne, de asszem rádiós szenzorokhoz van vevőegység), de a többi nem hülyeség.
[ Szerkesztve ]
Az USB -> Ethernet adapter még a 100Mbps sebességet se éri el. Az usb-s wifi is elég lassú (különösen, hogy egy ágon van az ethernettel). Egy openwrt-s router olcsóbb és annyival nem lassabb (cpu teljesítményben).
Netosztáshoz vidékre jó lenne a Rasb Pi is De ilyen értelemben a pc-s otthoni router is hülyeség, mert az meg már túlzás. A Rasb Pi legalább nem fogyaszt sokat és az is jó móka. Amúgy meg lehet prociban nem sokkal gyengusabb egy ócó router, viszont memóriában veri a PI azokat, azért 256 mega egy otthoni routerbe már több mint jó.
[ Szerkesztve ]
Jó írás, de én pl. nem feccölném ebbe az időt (persze tanulásra / gyakorlásra tök jó), amikor van egy sokkal jobb megoldás otthonra nem átlagfelhasználónak, valamint kisvállalatoknak: a legjobban kezelhető (webadminról és SSH-val is elérhető) véleményem szerint némi kutakodás után a pfSense, ami egy FreeBSD alapú (így pf alapú a csomagszűrő is), csomagokkal (szolgáltatásokkal) bővíthető router OS, ráadásul van neki embedded rendszerekre optimalizált NanoBSD image-e, így futtathatjuk pendrive-ról, memkártyáról kvázi read-only módban (a RAM-ba, ramdiskre logol!)
Átlag usernek elég a SOHO router, advanced user meg OpenWRT-s routert vesz otthonra.
Nem rég raktam össze ebből a HW-ből egy ilyet és tökéletesen stabil a pfSense NanoBSD-s verzióval:
integrált CPU-s lap 2 NIC-el
4 GB RAM
4 GB-os CF kártya CF->IDE átalakítóval
miniITX ház táppal
ez a lap jobb lett volna az erősebb CPU miatt, de pont nem volt kapható
Fut rajta a pf+pfBlocker, Squid, reverse proxy funkcióval, OpenVPN szerver, SSH. A fő cél reverse proxy funkciót ellátó tűzfal építése volt (mögötte LAN-on van webszerver), nem találtam ennél jobb HW+SW alternatívát ár/érték arányban.
Még HDD RAID1 sem kell, a "garantáltan" 5 éven belül elromló desktop HDD-ket száműzhetjük ( nem beszélve arról, hogy 2 db. HDD kb. 25K, 1 éles+1 tarcsi CF kártya 10K), elég a konfigot lementeni egy biztos helyre minden módosítás után, ami 1 db. xml alapú fájl, mert a CF kártya halála esetén a tarcsi CF kártyára felteszed a rendszert, rátöltöd a szűz rendszerre a konfig XML-t, reboot után lehúzza a kellő csomagokat, az XML alapján bekonfigolja őket, és ennyi.
Esetleg nem akarsz erről egy kis cikket összedobni (ha lehet jó szájbarágósan), főleg az XML alapú reconfig érdekelne, de mivel nem nagyon értek (még) az egészhez, így a többi dolog is hasznos lenne. Bár ahogy látom a pfSense oldala elég részletes. 
[ Szerkesztve ]
"VLAN "alatt" van pppoe?"
Olyannyira, hogy PPPoE-hez még VLAN sem feltétlenül kell. Ha van egy switch, akkor beledugod a DSL modemet/ONT-t meg a klienseket. A tűzfalon ugye lesz egy PPP interfész meg a lan. Mivel a PPPoE eth rétegben megy, nem fogják egymást zavarni, a két interfész között meg már csinálhatod is a tűzfal szabályokat. Szóval VLAN-is csak kábelnethez vagy tisztán IP rétegben működő hálózathoz kell, PPPoE-hez (DSL, Optika, Digi) nem.
Dchard
Így még nem is gondoltam ebbe bele, nem is hülye ötlet
Majd jönnek a többiek, akik szerint az
A másik előnye, hogy egy csomó YT tutorial ill. dokumentáció és fórum is elérhető, onnan "mindent" össze lehet szedni nem túl sok hozzáértéssel is.
Az XML alapú reconfig olyan egyszerű, ahogy írtam. Úgy néz ki, hogy a beállított, jó rendszeredről lemented a config XML-t (webadminon keresztül, külön "Backup" menüpont van erre), és ha feltelepíted egy új adathordozóra a rendszert, és behívod a webadmint, akkor importálni tudod a config XML-t. Importálás után a gép rebootol, a pfSense induláskor netről leszedi az importált XML konfig alapján a működéshez kellő csomagokat (amiket feltelepítettél, persze ha egyáltalán...) és a szolgáltatásokat is bekonfigolja az import XML alapján. Még egy lapcsere esetén sem kell emiatt újra konfigolni a rendszert, elég a config import után a nem egyező hardver miatti beállításokat megejteni (pl. NIC-ek konfigja).
Köszi az infókat. Így leírva már tényleg egyszerű az XML-ezés, azt hittem lesz benne pár csavar.
Viccből kiengedtem a default ssh portot. Belaggolt a cucc .
Viszont a net felé néző oldalra megfelelhet au USB-háló csatoló, hacsak nem júpíszís 100+Mbites neted van. A legtöbbeknek meg sajna nincs.
A pi-n az a baj, hogy a procin csak egy usb van, és van egy beépített hub ami szét osztja (az ethernet egy szintén beépített usb -> ethernet), szóval valószínűleg még a 20Mbps hez is kevés lesz a sávszél oda vissza.
Hmm 20 Mbit, de szép is lenne
Most pl 5 van.
[ Szerkesztve ]
Grat! Nagyon jó cikk, részletesen, szépen leírva minden, hasznos jó! Biztosan nagyon jó lehet egy ilyen cucc, egyszer majd nekiállok mert izgat a dolog
Addig is mentem a cikket mert nagyon egyben van, köszi még egyszer
Sziasztok!
Már egy ideje gondolkodok egy linux átjárón a következők miatt:
[link]
Szerintetek ez linuxban előfordulhat?
kösz!
[ Szerkesztve ]
