[kroozo]

még kicsit beszélek/kérdezgetek itt.

Mostanság sokat gondolkodtam azon, hogy igazából a tapasztalatom szerint bevett gyakorlatnak számító RELATED. ESTABLISHED csomagok válogatás nélküli beengedése nem biztos hogy  a legjobb ötlet. Fõként akkor, ha vannak untusted userek is a boxon, de megfelelõen paranoid ember lévén egyébként is. Ugyanis ez ugye gyakorlatilag bármely felépített kapcsolathoz tartozó csomagot átengedi. Magyarul, ha valamilyen oknál kifolyólag vala(ki|mi) tud kreálni egy csatornát kifele, akkor áradhat befele szépen minden mint az állat. (ezér emeltem ki a megbízhatatlan usert, de ugye paranoidok vagyunk, ami adminok esetében egészséges tulajdonság, és feltételezzük h bármi lehet )
Ez alapvetõen két megvalósításban való változtatást kíván tõlünk követel tõlünk ( a tûzfalon):
1) Szûrés az output láncban
2) A REL, EST csomagokat nem általánosságban kellene alkalmazni, hanem mondjuk bizonyos esetekben mint plussz! szûrési feltételt megvalósítani, mondjuk egy külön láncban.

És a RELATED csomagokat még így is zûrösnek érzem. Egy ftp_contrackot pl szerintem át lehet verni, és ACTIVE módú DATA nyitással kedvünkre kijuthatunk valahonnan. (vagy most késõ van és keverek ) Bár persze, ha ftpt át akartunk eleve engedni, akkor azt már elég fölös másra használni

Szóval, nagy hülyeségeket gondolok, vagy van ennek valami realitásalapja szerintetek?

[Mono]

Idézet: kroozo - Dátum: 2005. jan. 9., vasárnap - 2:06

még kicsit beszélek/kérdezgetek itt.

...

Nos, szerintem van ráció abban, amit mondasz, de mennyire gondolom rosszul, hogy ez leginkább azon protokollok használata esetén válik veszélyessé, amelyek más csatornákat nyitnak maguk mellé, pl. ftp Egy mezei SMTP, IMAP, stb. szolgáltatásokat futtató szerveren szerintem nem veszélyes az iptables ilyen jellegû használata.

[kroozo]

Idézet: Mono - Dátum: 2005. jan. 10., hétfõ - 10:22

Nos, szerintem van ráció abban, amit mondasz, de mennyire gondolom rosszul, hogy ez leginkább azon protokollok használata esetén válik veszélyessé, amelyek más csatornákat nyitnak maguk mellé, pl. ftp Egy mezei SMTP, IMAP, stb. szolgáltatásokat futtató szerveren szerintem nem veszélyes az iptables ilyen jellegû használata.

háát, ja végül is igen... de majd egyszer nekiállok komolyabban is gondolkodni ezügyben...

[diab303]

Idézet: kroozo - Dátum: 2005. jan. 9., vasárnap - 1:36

bele se merek gondolni egy olyan samba.confba ami anon lusernek megengedi az írást... brrrr.

te ugye otthon is mindenhova harom jelszoval lepsz be?

[kroozo]

Idézet: diab303 - Dátum: 2005. jan. 14., péntek - 0:24

te ugye otthon is mindenhova harom jelszoval lepsz be?

nem. de nem szeretem, ha anon user írni tud. és, igen használok jelszavakat. és igen, ha nem használnék, már megnyomták volna az otthoni gépemet néhányszor. és nem használok sambát 

[Friczy]

Idézet: kroozo - Dátum: 2005. jan. 9., vasárnap - 2:06

még kicsit beszélek/kérdezgetek itt.

Mostanság sokat gondolkodtam azon, hogy igazából a tapasztalatom szerint bevett gyakorlatnak számító RELATED. ESTABLISHED csomagok válogatás nélküli beengedése nem biztos hogy  a legjobb ötlet. Fõként akkor, ha vannak untusted userek is a boxon, de megfelelõen paranoid ember lévén egyébként is. Ugyanis ez ugye gyakorlatilag bármely felépített kapcsolathoz tartozó csomagot átengedi. Magyarul, ha valamilyen oknál kifolyólag vala(ki|mi) tud kreálni egy csatornát kifele, akkor áradhat befele szépen minden mint az állat. (ezér emeltem ki a megbízhatatlan usert, de ugye paranoidok vagyunk, ami adminok esetében egészséges tulajdonság, és feltételezzük h bármi lehet )
Ez alapvetõen két megvalósításban való változtatást kíván tõlünk követel tõlünk ( a tûzfalon):
1) Szûrés az output láncban
2) A REL, EST csomagokat nem általánosságban kellene alkalmazni, hanem mondjuk bizonyos esetekben mint plussz! szûrési feltételt megvalósítani, mondjuk egy külön láncban.

És a RELATED csomagokat még így is zûrösnek érzem. Egy ftp_contrackot pl szerintem át lehet verni, és ACTIVE módú DATA nyitással kedvünkre kijuthatunk valahonnan. (vagy most késõ van és keverek ) Bár persze, ha ftpt át akartunk eleve engedni, akkor azt már elég fölös másra használni

Szóval, nagy hülyeségeket gondolok, vagy van ennek valami realitásalapja szerintetek?

Mindenkinek a paranoia-szintjétõl függ, hogy mit enged, és mit nem. Az ESTABLISHED mindenképpen hasznos dolog, amíg ez nem volt (lásd egyszerû csomagszûrõ, ipchains), addig rosszabb esetben megengedték a nem protected portokra a csatlakozást (brrr), jobb esetben kiegészítették ezt a szabályt azzal, hogy mindezt csak a !-syn állapotú csomagokra engedték meg. Ennél a megoldásnál az ESTABLISHED mindenképpen jobb.

A RELATED-rõl: egyrészt játszhatsz azzal, hogy pl. csak az icmp-re engeded meg a RELATED-et, és már kiszûrtél egy rakás protokolt, amit esetleg nem szeretnél, ha használnának (pl. aktív ftp, irc DCC, stb), persze erre szintén elegáns megoldás, hogy csak a megfelelõ ip_conntrack_xxx és ip_nat_xxx modult töltöd be, és a RELATED marad globális.

Az output láncban szûrés roppant rázós, különálló tûzfalon értelmét sem nagyon látom, mert a forgalom nagy része átmenõ, és nem is kerül OUTPUT-ra, itt a szûrés a FORWARD-on van nagyrészt.

Tudomásul kell venni, hogy minden tûzfalnak megvannak a maga képességi korlátai, az SPF-eknek kb. ennyi. Valóban volt egy flame vagy három éve arról, hogy az SPF-ek a data csatorna nyitásával hogyan verhetõk át egy kis csomag-fragmentáció segítségével, azóta ezt valamelyest kivédték. Tény, hogy nagyobb biztonság érhetõ el a csomagszûrõ helyett proxy alapú tûzfalak használatával, de mint mindennek, ennek is ára van. Ingyenes proxy tûzfal kevés van, vagy relatíve keveset tud, a pénzesek sokba kerülnek, és a beállításuk messze bonyolultabb, mint egy csomagszûrpé, nem beszélve a hardware-igényrõl.

[kroozo]

Idézet: Friczy - Dátum: 2005. jan. 17., hétfõ - 10:23

Mindenkinek a paranoia-szintjétõl függ, hogy mit enged, és mit nem. Az ESTABLISHED mindenképpen hasznos dolog, amíg ez nem volt (lásd egyszerû csomagszûrõ, ipchains), addig rosszabb esetben megengedték a nem protected portokra a csatlakozást (brrr), jobb esetben kiegészítették ezt a szabályt azzal, hogy mindezt csak a !-syn állapotú csomagokra engedték meg. Ennél a megoldásnál az ESTABLISHED mindenképpen jobb.

A RELATED-rõl: egyrészt játszhatsz azzal, hogy pl. csak az icmp-re engeded meg a RELATED-et, és már kiszûrtél egy rakás protokolt, amit esetleg nem szeretnél, ha használnának (pl. aktív ftp, irc DCC, stb), persze erre szintén elegáns megoldás, hogy csak a megfelelõ ip_conntrack_xxx és ip_nat_xxx modult töltöd be, és a RELATED marad globális.

Az output láncban szûrés roppant rázós, különálló tûzfalon értelmét sem nagyon látom, mert a forgalom nagy része átmenõ, és nem is kerül OUTPUT-ra, itt a szûrés a FORWARD-on van nagyrészt.

Tudomásul kell venni, hogy minden tûzfalnak megvannak a maga képességi korlátai, az SPF-eknek kb. ennyi. Valóban volt egy flame vagy három éve arról, hogy az SPF-ek a data csatorna nyitásával hogyan verhetõk át egy kis csomag-fragmentáció segítségével, azóta ezt valamelyest kivédték. Tény, hogy nagyobb biztonság érhetõ el a csomagszûrõ helyett proxy alapú tûzfalak használatával, de mint mindennek, ennek is ára van. Ingyenes proxy tûzfal kevés van, vagy relatíve keveset tud, a pénzesek sokba kerülnek, és a beállításuk messze bonyolultabb, mint egy csomagszûrpé, nem beszélve a hardware-igényrõl.

Teljesen igazad van, egyetértünk. A multheti fárasztó és paranoid volt számomra. (Dehát végülis ez ebben a szakmában pozitív dolog ) (Ráadásul az eszmefuttatásomban bakiztam is egy méterest az ESTABLISHED kapcsán)

Output láncot meg természetesen nem forwardos, hanem szolgáltatós gépre értettem.... Anno vettem át gépet másik fószertõl, az ipchains-> iptables migrációt kb egy find-replaccel oldották meg. Cs nem vették figyelembe, hogy utóbbi esetben a forwardolt csomagok nem az outputon mennek ki..... Kicsit elhûltem, mikor megláttam....

[Eperkutyus]

Bocs, hogy beleszólok, a proxy-s tûzfal miben más, mint a csomagszûrõs ?

Van nekem mondjuk egy linux gépem, ami az adsl-t megosztja.

Csomagszûrõs tûzfal a web forgalmat szûrné csomagonként, így van ? A FORWARD-ban.

Én ehelyett olyat csináltam, hogy a web forgalmat tiltottam, és Squid-et állítottam be a proxy-n. Így aztán amelyik böngészõ nem használja a squid-et, az bukta, se ki, se be.

Na, ilyesmi lenne a különbség, vagy ennél sokkal komolyabb ?

(Most az elméletrõl beszélek tehát)

[Mono]

Idézet: Eperkutyus - Dátum: 2005. jan. 18., kedd - 13:11

Bocs, hogy beleszólok, a proxy-s tûzfal miben más, mint a csomagszûrõs ?

...

(Most az elméletrõl beszélek tehát)

Majd jönnek nálam okosabbak és elmesélik

Amit én tudok ezekrõl, hogy a proxy-s tûzfalra "megérkeznek" a csomagok, majd a szabályoktól függõen vagy újak "generálódnak" (és folytatják az útjukat), vagy nem (és elvesznek).
A csomagszûrõsön ugyanaz a csomag megy tovább, ha átjut a szabályokon, mint ami bejön - elvileg, mert lehet NAT, meg egyéb finomságok.

Egyébiránt nagyon ajánlom a témával komolyabban foglalkozni vágyók számára a NIIF elõadásának videóját (350 és 210MB): http://vod.niif.hu/ipszilon1/
És a hozzá kapcsolódó PDF fájlt: http://www.ipszilon....zfal-kadlec.pdf

[Eperkutyus]

Várom õket

[Friczy]

Idézet: Eperkutyus - Dátum: 2005. jan. 18., kedd - 13:11

Bocs, hogy beleszólok, a proxy-s tûzfal miben más, mint a csomagszûrõs ?

Van nekem mondjuk egy linux gépem, ami az adsl-t megosztja.

Csomagszûrõs tûzfal a web forgalmat szûrné csomagonként, így van ? A FORWARD-ban.

Én ehelyett olyat csináltam, hogy a web forgalmat tiltottam, és Squid-et állítottam be a proxy-n. Így aztán amelyik böngészõ nem használja a squid-et, az bukta, se ki, se be.

Na, ilyesmi lenne a különbség, vagy ennél sokkal komolyabb ?

(Most az elméletrõl beszélek tehát)

A csomagszûrõ esetén a csomag beérkezik a gépre, végigfut a szabályokon, és vagy továbbmegy (változtatás nélkül, illetve a fejrészben lehet bizonyos változtatás - pl. a NAT-hoz ip cím vagy port változtatás kell), vagy nem. A csomag adattartalma sosem változik, és maga a csomag mindig az eredeti forrástól a célgépig utazik.

Proxy esetében (az egyszerûség kedvéért maradjunk TCP-nél) a kliens kezdeményezésére a tûzfal felépíti a TCP sessiont, és ha a forgalmat legálisnak találja, akkor felépít egy másik TCP sessiont a tûzfaltól a célgépig, és csak az adattartalmat tölti át az egyik sessionból a másikba. Közben persze részletesebb, protokollspecifikus elemzést, változtatást is tud végezni. Mivel ilyen esetben az összes kifelé menõ csomag a tûzfalon generálódik, és a bejövõ csomag a tûzfalon ér véget, a csomagszinten elkövetett trükkök (vagy akár forgalomelemzések) hatástalanok.

A Squid jó példa a proxyra, de azt nem árt tudni, hogy a Squid fõ funkciója nem a biztonság, hanem a cache, így senki ne gondolja, hogy egy Squiddal alkalmazásszintû tûzfalat lehet csinálni.

[Eperkutyus]

Idézet: Friczy - Dátum: 2005. jan. 18., kedd - 14:49

A csomagszûrõ esetén a csomag beérkezik a gépre, végigfut a szabályokon, és vagy továbbmegy (változtatás nélkül, illetve a fejrészben lehet bizonyos változtatás - pl. a NAT-hoz ip cím vagy port változtatás kell), vagy nem. A csomag adattartalma sosem változik, és maga a csomag mindig az eredeti forrástól a célgépig utazik.

Proxy esetében (az egyszerûség kedvéért maradjunk TCP-nél) a kliens kezdeményezésére a tûzfal felépíti a TCP sessiont, és ha a forgalmat legálisnak találja, akkor felépít egy másik TCP sessiont a tûzfaltól a célgépig, és csak az adattartalmat tölti át az egyik sessionból a másikba. Közben persze részletesebb, protokollspecifikus elemzést, változtatást is tud végezni. Mivel ilyen esetben az összes kifelé menõ csomag a tûzfalon generálódik, és a bejövõ csomag a tûzfalon ér véget, a csomagszinten elkövetett trükkök (vagy akár forgalomelemzések) hatástalanok.

A Squid jó példa a proxyra, de azt nem árt tudni, hogy a Squid fõ funkciója nem a biztonság, hanem a cache, így senki ne gondolja, hogy egy Squiddal alkalmazásszintû tûzfalat lehet csinálni.

Wow ez tök érdekes

Linuxon megy a dolog?

[Mono]

Idézet: Eperkutyus - Dátum: 2005. jan. 18., kedd - 16:08

Linuxon megy a dolog?

Leginkább ott megy

[Eperkutyus]

Idézet: Mono - Dátum: 2005. jan. 18., kedd - 15:12

Leginkább ott megy

Állat.

Nézek háutut

[Mono]

Idézet: Eperkutyus - Dátum: 2005. jan. 18., kedd - 16:36

Állat.

Nézek háutut

Szerintem skubizd meg azt a videót, amire linkeltem fentebb....

[Friczy]

Idézet: Eperkutyus - Dátum: 2005. jan. 18., kedd - 16:08

Wow ez tök érdekes

Linuxon megy a dolog?

Ha idõt akarsz rászánni, akkor szerezz be egy gépet viszonylag sok memóriával (persze home használatra nem kell egetverõ, IMHO 128-256 elég lesz), és egy most már átlagosnak számító processzorral (mondjuk azért legalább500 MHz legyen ), szerezz egy kis Debian tapasztalatot (mert az jó ), és látogass el a http://www.balabit.hu site-ra. Ott található a Zorp lakóhelye, amely kereskedelmi software, de van GPL-es változata is (többé-kevésbé megegyezik a kereskedelmivel, csak nincs hozzá annyi proxy, és nincs hozzá support - bár ez így nem teljesen igaz - valamint nincs hozzá GUI-s beállító cucc)

Levelezõlistát találsz a site-on, ott elég készségesen válaszolnak a fejlesztõk a kérdésekre - magyarul -, kiinduló doksikat is lehet találni itt, illetve a Mag által üzemeltetett http://zorp-unoff.sourceforge.net/ site-on.

Ha el akarsz mélyedni a (alkalmazásszintû) tûzfalak világában, akkor ennél jobbat nem nagyon találsz tanulásra (mellesleg ha kiismered, akkor profi munkára is az egyik legjobb). Hozzáteszem, a kereskedelmi változat supportja messze átlagon felüli - ennyi dicséret talán nem minõsül reklámnak. Ha mégis, akkor egy mod szóljon.

[Mono]

Uraim!

A múltkorjában egyeztetett tûzfal konfigommal lenne egy kis gondom, segítsetek légyszi, ha tudtok!
Következõ a felállás:
Van két Debian Sarge-t futtató gép, belsõ hálón, fix IP-kel, egyik egy "mezei" linux, a másik egy levelezõ szerver is.
A "sima" linuxon nincs, a levelezõ szerveren pedig fut Iptables, a lentebbi beállításokkal.
Internetet "hardveres" router csinál a belsõ háló számára, amin a levelezéshez szükséges portok forwardolva vannak a mail szerver IP címére.

Minden megy is rendesen, most jutottam el odáig, hogy kicsit jobban kidolgozzam az e-mailek archiválást. Ennek tar.gz-s eredményét automatizálva szeretném a "mezei" linuxos gépre FTP-vel átmásolni úgy, hogy a mail szerver küldje, azaz uploadolja a "sima" linuxos gépre, melyen ProFTP szerver fut és jelenleg nincs is rajta tûzfal.


A mail szerver iptables konfigja (gép bootoláskor van lefuttatva):

#!/bin/bash
iptables -F
ifdown eth0
ifup eth0
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
iptables -A INPUT -p tcp -m tcp -m multiport --dports 20,21,22,25,80,143,443,993 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT -m limit --limit 2/second --limit-burst 5
iptables -A INPUT -p tcp --dports 113 -j REJECT
iptables -P INPUT DROP

"Sima" FTP parancsot használok a mail szerveren, minden egyes ftp parancs (login, könyvtárváltás, stb.) egy örökkévalóságnak tûnik (100MBit belsõ háló), 200kByte adatot 20 perc alatt sem sikerült feltöltenem az FTP szerverre. (Létrejön a fájl, 0 hosszal, ftp parancs futtatása folyamatban van végig, nem ad vissza hibát, v. promtot).
Ha a mail szerveren kikapcsolom a tûzfalat, akkor villámgyorsan megy minden úgy, ahogy az a "nagy könyvben meg van írva".

Kérdésem az lenne tehát, mit kellene még módosítanom a fentebbi tûzfalszkripten ahhoz, hogy az ftp is szépen menjen vele :confused: Gyanítom, hogy itt lehet valami probléma, hiszen iptables nélkül gyönyörûen megy.

Még egy "extra" kérdésem lenne, az iptables -F utasítás tudtommal teljesen üríti, "kikapcsolja" az aktuális tûzfal beállításokat. Nekem ez annyit tesz, hogy semmiféle kapcsolatot nem tudok folytatni, sem újat kezdeményezni, holott az iptables -L szerint tényleg üres Sem az eredetileg tiltott portok, sem az eredetileg nyitott portokon nem lehet kommunikálni az iptables -F kiadása után a géppel :confused: Ha az egész gépet újraindítom úgy, hogy nincs iptables birizgálva, nem adok meg szabályokat, akkor minden megy rendben, ftp is, iptables -L ugyanazt mutatja, mint amikor a -F kapcsolóval törlöm az addigi beállításokat.
Ez mitõl lehet
Két, telejesen független vason, is ugyanezt produkálja, mindkettõ Sarge Debian.

[kroozo]

Idézet: Mono - Dátum: 2005. febr. 15., kedd - 14:29

Uraim!
Minden megy is rendesen, most jutottam el odáig, hogy kicsit jobban kidolgozzam az e-mailek archiválást. Ennek tar.gz-s eredményét automatizálva szeretném a "mezei" linuxos gépre FTP-vel átmásolni úgy, hogy a mail szerver küldje, azaz uploadolja a "sima" linuxos gépre, melyen ProFTP szerver fut és jelenleg nincs is rajta tûzfal.

A mail szerver iptables konfigja (gép bootoláskor van lefuttatva):

#!/bin/bash
iptables -F
ifdown eth0
ifup eth0
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
iptables -A INPUT -p tcp -m tcp -m multiport --dports 20,21,22,25,80,143,443,993 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT -m limit --limit 2/second --limit-burst 5
iptables -A INPUT -p tcp --dports 113 -j REJECT
iptables -P INPUT DROP

"Sima" FTP parancsot használok a mail szerveren, minden egyes ftp parancs (login, könyvtárváltás, stb.) egy örökkévalóságnak tûnik (100MBit belsõ háló), 200kByte adatot 20 perc alatt sem sikerült feltöltenem az FTP szerverre. (Létrejön a fájl, 0 hosszal, ftp parancs futtatása folyamatban van végig, nem ad vissza hibát, v. promtot).
Ha a mail szerveren kikapcsolom a tûzfalat, akkor villámgyorsan megy minden úgy, ahogy az a "nagy könyvben meg van írva".

Kérdésem az lenne tehát, mit kellene még módosítanom a fentebbi tûzfalszkripten ahhoz, hogy az ftp is szépen menjen vele :confused: Gyanítom, hogy itt lehet valami probléma, hiszen iptables nélkül gyönyörûen megy.

Tippelnék: modprobe ip_conntrack_ftp Ha sír hogy nincs, akkor sajna le kell fordítanod.

Idézet: Mono - Dátum: 2005. febr. 15., kedd - 14:29

Még egy "extra" kérdésem lenne, az iptables -F utasítás tudtommal teljesen üríti, "kikapcsolja" az aktuális tûzfal beállításokat. Nekem ez annyit tesz, hogy semmiféle kapcsolatot nem tudok folytatni, sem újat kezdeményezni, holott az iptables -L szerint tényleg üres Sem az eredetileg tiltott portok, sem az eredetileg nyitott portokon nem lehet kommunikálni az iptables -F kiadása után a géppel :confused: Ha az egész gépet újraindítom úgy, hogy nincs iptables birizgálva, nem adok meg szabályokat, akkor minden megy rendben, ftp is, iptables -L ugyanazt mutatja, mint amikor a -F kapcsolóval törlöm az addigi beállításokat.
Ez mitõl lehet
Két, telejesen független vason, is ugyanezt produkálja, mindkettõ Sarge Debian.

Egész konkrétan a -F törli a szabályokat. Amit viszont nem töröl az a default policy-ja a láncokanak, és valószínûleg neked így vannak (bár látom az utsó szabályod is DROP). Ha a -L nem olyat mond hogy default policy ACCEPT, akkor ez a hiba.

[Mono]

Idézet: kroozo - Dátum: 2005. febr. 15., kedd - 22:08

Tippelnék: modprobe ip_conntrack_ftp Ha sír hogy nincs, akkor sajna le kell fordítanod.

Nagyon jól tippeltél! - köszi a segítséget, mûködik a dolog.
Default policy-t megnézem majd, ha a gép mellett leszek, azt így remote-ba nem merem nyaggatni, mert eddig a -F kapcsoló után kizárt az SSH-ból is, mint minden másból

[Mono]

Nos, kipróbáltam, teljesen jól mûködik, köszönöm még egyszer!

Az iptables -F kitöröl mindent, de a default policy DROP az INPUT-ra, ezért volt a kizárás.