[idoru]

Az alaphelyzet az, hogy egy Debian tûzfal mögött van három win-es gép. Az egyiken egy filecserélõ progi van ami elég agresszív és ha töltenek a géprõl akkor az egész sávszélességet elfoglalja, lehetetlen netezni mellette. Ha lenne ötleteket arra, hogy hogyan tudnám egy kicsit megzabolázni (sávszûkítés, vagy tiltás) légyszi véssétek ide. Elõre is köszi.

[Sipi-]

Fájlcserélõ program: dc? Abból van korlátos is

Egyébként pedig azthiszem QoS kell a sávszélesség szabályozásához. Vagy pedig valahogy belövöd a limit taggal, hogy hany csomagot fogadjon el maximum a tûzfal egységnyi idõ alatt.

[idoru]

idézet:

---

Ezt írta Sipi-:
Fájlcserélõ program: dc? Abból van korlátos is

Egyébként pedig azthiszem QoS kell a sávszélesség szabályozásához. Vagy pedig valahogy belövöd a limit taggal, hogy hany csomagot fogadjon el maximum a tûzfal egységnyi idõ alatt.[/quote]

igen dc-rõl van szó, de én ahhoz nem igazán konyítok az az öcsém reszortja. A limit tag nekem is eszembe jutott. Nincs valami ötleted az értékekre?

[Sipi-]

idézet:

---

Ezt írta idoru:
igen dc-rõl van szó, de én ahhoz nem igazán konyítok az az öcsém reszortja. A limit tag nekem is eszembe jutott. Nincs valami ötleted az értékekre?[/quote]Értékekre nincs ötletem...
Itt egy korlátos dc: [url="http://"http://bcdc.webhop.org/"]http://bcdc.webhop.org/[/url] Rakassd ezt fel öcsédhez átmeneti megoldásként. A korlátot meg majd leszedi amikor nem netezik senki.

[idoru]

idézet:

---

Ezt írta Sipi-:
Értékekre nincs ötletem...
Itt egy korlátos dc: [url="http://"http://bcdc.webhop.org/"]http://bcdc.webhop.org/[/url] Rakassd ezt fel öcsédhez átmeneti megoldásként. A korlátot meg majd leszedi amikor nem netezik senki.[/quote]

köszi, megprobálom.

[leslie]

Az iptables manjaban a limit szoban keress ra.

Mukodik, anno probaltam.

[idoru]

idézet:

---

Ezt írta leslie:
Az iptables manjaban a limit szoban keress ra.

Mukodik, anno probaltam. [/quote]

Igazándiból próbálkoztam már, de nem igazán jött össze. Ha lenne egy tuti tipp azt megköszönném.

[Alen]

A legjobb megoldas tenyleg a limites DC... A legdurvabb az iptables/limit paros... A legelegansabb meg a QoS, amihez ezek kellenek a kernelbe:

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=y
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_CSZ is not set
CONFIG_NET_SCH_PRIO=y
# CONFIG_NET_SCH_RED is not set
CONFIG_NET_SCH_SFQ=y
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=y
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_INGRESS is not set
CONFIG_NET_QOS=y
# CONFIG_NET_ESTIMATOR is not set
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_POLICE is not set

...aztan meg apt-get install shaper, es innentol az /etc/shaper-be lehet mindenfele szabalyokat irkalni...lekorlatozhatod egybol az egesz gepet, vagy ha van turelmed kinyomozni melyik portokat hasznalja a DC, akkor egyenkent, azokat...

Teljes IP tiltasa:

DEVICE=eth1,100Mbit,10Mbit
RATE=55Kbit
WEIGHT=128kbit
PRIO=5
RULE=192.168.1.0/24,

Portok tiltasa:

DEVICE=eth0,100Mbit,10Mbit
RATE=55Kbit
WEIGHT=1kbit
PRIO=5
RULE=:1214,
RULE=:41000,
RULE=:41001,
RULE=:41002,
RULE=:41003,
RULE=:41004,
RULE=:41005,
RULE=:41006,
RULE=:41007,
[.........]

Stbstb... az /etc/init.d/shaper scriptben egesz hasznalhato dokumentacio van a lehetosegekrol...

[idoru]

idézet:

---

Ezt írta Alen:
A legjobb megoldas tenyleg a limites DC... A legdurvabb az iptables/limit paros... A legelegansabb meg a QoS, amihez ezek kellenek a kernelbe:...[/quote]

KÖszi a kimeritõ választ. Szerintem is a legkönnyebb a limites dc. Már rá is szabadítottam az öcsémet. Azért próbálkoztam a iptables/limit-tel is. Bár csak keveset tudtam tesztelni, de a "-limit 200/s --limit-burst 1" közelítõleg jónak néz ki. A shaper-rel kapcsolatban: sajnos a dc, úgy vettem észre, hogy passzív módban abszolút véletlenszerû portokat használ. De ha lehetne egy bizonyos IP-re is szabályt írni az kircsó lenne, mert tényleg ez lenne a legszebb megoldás szerintem is.

[Mono]

Picit felhoznám ezt a topikot, következõ dolgot szeretném megvalóítani: van egy szerver, belsõ hálón, belsõ fix IP címmel, egy hálókártyával. Fut rajta néhány olyan szolgáltatás, melyet el kellene érni hálózaton, ill. néhány, melyet nem.
Azt szeretném iptables-szel megvalósítani, hogy minden szerver felé irányuló kérés tiltva legyen, azon portok kivételével, melyekre szükségem van. Alapvetõen mail szerverrõl lenne szó, tehát 25 (SMTP), 993 (IMAP-SSL), 443 (https) lennének azon szolgáltatások, melyeket engedélyezni akarok. Nyilván van még egy-két port, melyet engedélyeznem kellene, pl. - ha jól gondolom - 53-as (DNS).
További gondom az a protokoll. Ha nézem pl. az imap-ssl-t, akkor az 993-as port, tcp és udp is megadva. Kell-e az udp mindenképpen, vagy elég csak a tcp? Kell-e DNS esetében az 53-as portot is kinyitnom? Elviekben az belülrõl irányulna kifelé kérés szinten, ekkor is meg kell adnom azt, hogy az 53-as portot kinyitom? - mert ez esetben egy, a mail szerveren futó bind-ot (DNS Cache miatt telepítem csak) használhatná boldog-boldogtalan mint DNS szerver, nem?

A következõt adagoltam be az iptables-nek, gondolom nem igazán jó, de kicsit homályos még a dolog, emellett nem igazán mûködött úgy, ahogy szerettem volna. Nem tudtam az általam kinyitott portok egyikére sem telnetelni (pl. SMTP) kintrõl, ill. bentrõl sem tudtam kifelé web-ezni. Mi a gond, vagy mi kellhet még ehhez?

iptables -A INPUT -p tcp -m tcp -m multiport -d 192.168.1.1 -j ACCEPT --dports 22,25,443,993

iptables -A INPUT ! -s 127.0.0.1 -d 192.168.1.1 -i eth0 -j REJECT --reject-with icmp-port-unreachable

Segítsetek már légyszi abban, mik kellenének még a mellett, vagy mi lenne a helyes szabály, melyet meg kellene adjak.
Tehát egy gép, melyet kintrõl (itt már a LAN is annak számít) kellene védeni, alapból minden befelé irányuló portot tiltani, azok kivételével, melyeket én akarok, hogy elérhetõ legyen (plusz még a szükséges(ek), ha van(nak) ilyen(ek)), valamint belülrõl (tehát a szerverrõl) kifelé irányuló kérések menjenek (azaz pl. lehessen WEB-ezni a szerverrõl), az operációs rendszer Debian Sarge.

Elõre is köszi!

Szerkesztette: Mono 2005. 01. 05. 18:04 -kor

[Yv@n]

Net felõl hogyan éred el a gépet?

53as porttal sok gondod nem lehet, szûrd hogy csak a belsõ tartományból fogadjon kéréseket.

[Friczy]

Idézet: Mono - Dátum: 2005. jan. 5., szerda - 17:58

Picit felhoznám ezt a topikot, következõ dolgot szeretném megvalóítani: van egy szerver, belsõ hálón, belsõ fix IP címmel, egy hálókártyával. Fut rajta néhány olyan szolgáltatás, melyet el kellene érni hálózaton, ill. néhány, melyet nem.
Azt szeretném iptables-szel megvalósítani, hogy minden szerver felé irányuló kérés tiltva legyen, azon portok kivételével, melyekre szükségem van. Alapvetõen mail szerverrõl lenne szó, tehát 25 (SMTP), 993 (IMAP-SSL), 443 (https) lennének azon szolgáltatások, melyeket engedélyezni akarok. Nyilván van még egy-két port, melyet engedélyeznem kellene, pl. - ha jól gondolom - 53-as (DNS).
További gondom az a protokoll. Ha nézem pl. az imap-ssl-t, akkor az 993-as port, tcp és udp is megadva. Kell-e az udp mindenképpen, vagy elég csak a tcp? Kell-e DNS esetében az 53-as portot is kinyitnom? Elviekben az belülrõl irányulna kifelé kérés szinten, ekkor is meg kell adnom azt, hogy az 53-as portot kinyitom? - mert ez esetben egy, a mail szerveren futó bind-ot (DNS Cache miatt telepítem csak) használhatná boldog-boldogtalan mint DNS szerver, nem?

A következõt adagoltam be az iptables-nek, gondolom nem igazán jó, de kicsit homályos még a dolog, emellett nem igazán mûködött úgy, ahogy szerettem volna. Nem tudtam az általam kinyitott portok egyikére sem telnetelni (pl. SMTP) kintrõl, ill. bentrõl sem tudtam kifelé web-ezni. Mi a gond, vagy mi kellhet még ehhez?

iptables -A INPUT -p tcp -m tcp -m multiport -d 192.168.1.1 -j ACCEPT --dports 22,25,443,993

iptables -A INPUT ! -s 127.0.0.1 -d 192.168.1.1 -i eth0 -j REJECT --reject-with icmp-port-unreachable

Segítsetek már légyszi abban, mik kellenének még a mellett, vagy mi lenne a helyes szabály, melyet meg kellene adjak.
Tehát egy gép, melyet kintrõl (itt már a LAN is annak számít) kellene védeni, alapból minden befelé irányuló portot tiltani, azok kivételével, melyeket én akarok, hogy elérhetõ legyen (plusz még a szükséges(ek), ha van(nak) ilyen(ek)), valamint belülrõl (tehát a szerverrõl) kifelé irányuló kérések menjenek (azaz pl. lehessen WEB-ezni a szerverrõl), az operációs rendszer Debian Sarge.

Elõre is köszi!

Ha jól értem, itt csak az adott serveren lévõ beállítás a kérdéses, az internet felõli kérések forwardolása (és a NAT) nem. Ezzel tehát nem foglalkozom.

Az, hogy még a bentrõl indított dolgok sem mûkodtek (pl. web), amiatt lehet, hogy egyszerûen a válaszcsomagokat is kiszûröd, ha csak annyi van az tûzfalkonfigban, amennyit itt leírtál. Ki lehet használni, hogy az iptables elég intelligens, és tud csomagállapotot kezelni.

Ebbõl a szemopontból roppant hasznos az

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

parancs, ezzel megengeded, hogy pl. a kifelé menõ kapcsolat (pl. a web) válaszai is bejöjjenek. Sõt, mivel a conntrack nem csak a tcp kapcsolatokat kezeli jól, a server által indított dns kérések válaszai is automatikusan megérkeznek ezáltal (persze ha ez a server önmagában DNS server is, akkor az 53-as portot is engedélyezni kell, de ha csak mind DNS kliens, akkor nem).

Bizonyos icmp csomagokat is be kell engedned (pl. destination unrachable), ezek egyszerûen szükségesek a normális mûködéshez. Ha nem akarsz foglalkozni azzal, hogy mik ezek (és szerintem nem érdemes túl sokat tökölni vele ), akkor bízd ezt az iptables-re, a netfilter fejlesztõi tudják, mit csinálnak Az alábbi parancs:

iptables -A INPUT -m state --state RELATED -j ACCEPT

megoldja, hogy a kapcsolathoz tartozó egyéb válaszok is bejussanak a gépre.

Ezen kívül már csak azokat kell engedélyezni, amit ténylegesen akarsz, tehát az a bizonyos mulitiport-os iptables parancs jónak tûnik.

Bocs, ha néhány triviális dolgot is leírtam, de a kérdésbõl nem derült ki, hogy milyen szinten kéred a választ. Mindenesetre így más is tanulhat belõle, aki nem merne kérdezni

[Mono]

Idézet: Yv@n - Dátum: 2005. jan. 5., szerda - 19:35

Net felõl hogyan éred el a gépet?

A szóban forgó gép belsõ hálón csücsül, egyenrangú minden hálózati géppel (nincs DMZ), a belsõ háló és az internet között pedig egy hardveres router van, külsõ fix IP-vel. Ezen a szükséges portok forwardolva vannak (NAT) a gép felé.

Idézet

53as porttal sok gondod nem lehet, szûrd hogy csak a belsõ tartományból fogadjon kéréseket.

Értem, ez is egy megoldás, köszönöm!

[Mono]

Friczy!

A tõled most már megszokott, tartalmas választ nagyon köszönöm!

Idézet

Ha jól értem, itt csak az adott serveren lévõ beállítás a kérdéses, az internet felõli kérések forwardolása (és a NAT) nem. Ezzel tehát nem foglalkozom.

Így van, igen. Egy gép, egy hálókártya, csak a gépre bejutást kellene korlátozni, minden befelé irányuló kérést tiltani azok kivételével, melyeket én engedélyezek. E mellett bentrõl kifelé jó lenne, ha továbbra is mûködne minden.

Idézet

Az, hogy még a bentrõl indított dolgok sem mûkodtek (pl. web), amiatt lehet, hogy egyszerûen a válaszcsomagokat is kiszûröd, ha csak annyi van az tûzfalkonfigban, amennyit itt leírtál. Ki lehet használni, hogy az iptables elég intelligens, és tud csomagállapotot kezelni.


Ebbõl a szemopontból roppant hasznos az

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

parancs, ezzel megengeded, hogy pl. a kifelé menõ kapcsolat (pl. a web) válaszai is bejöjjenek. Sõt, mivel a conntrack nem csak a tcp kapcsolatokat kezeli jól, a server által indított dns kérések válaszai is automatikusan megérkeznek ezáltal (persze ha ez a server önmagában DNS server is, akkor az 53-as portot is engedélyezni kell, de ha csak mind DNS kliens, akkor nem).

Bizonyos icmp csomagokat is be kell engedned (pl. destination unrachable), ezek egyszerûen szükségesek a normális mûködéshez. Ha nem akarsz foglalkozni azzal, hogy mik ezek (és szerintem nem érdemes túl sokat tökölni vele ), akkor bízd ezt az iptables-re, a netfilter fejlesztõi tudják, mit csinálnak. Az alábbi parancs:

iptables -A INPUT -m state --state RELATED -j ACCEPT

megoldja, hogy a kapcsolathoz tartozó egyéb válaszok is bejussanak a gépre.

Ezen kívül már csak azokat kell engedélyezni, amit ténylegesen akarsz, tehát az a bizonyos mulitiport-os iptables parancs jónak tûnik.

Bocs, ha néhány triviális dolgot is leírtam, de a kérdésbõl nem derült ki, hogy milyen szinten kéred a választ. Mindenesetre így más is tanulhat belõle, aki nem merne kérdezni

Közben sokat (? ) fejlõdtem már ezzel kapcsolatban, mióta feltettem ezt a kérdést.
Az alábbi iptables sorokat adagoltam be ahhoz, hogy:
- minden tcp portot tiltsak, melyek befelé irányulnak
- kivétel legyen most a 22-es tcp port, az ssh
- bentrõl kifelé irányuló kéréseknek ne szabjon gátat az iptables

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 22 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT -m limit --limit 2/second --limit-burst 5
iptables -A INPUT -j DROP

Ez látszólag mûködget, de - itt most nagyon nem leszek képben - olyasvalamit hallottam, hogy a ping-en kívül "élnek" más icmp csomagok is, azaz más dolgokra is használatosak az icmp csomagok, mint pingelésre. Hallottam olyat, hogy egyes SMTP szerverek, ill. routerek is használják az icmp csomagokat. Gondolom nem pingelnek, hanem valami más, de icmp csomagokat küldözgetnek. Erre a fentebbi írásod alapján akkor ez a sor megoldást kínál, így nem kell attól tartanom, hogy egy SMTP kapcsolódáskor, ha valaki icmp-t is szeretne tõlem, nem kapja meg?

Idézet

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Továbbá nagyon nem vagyok tisztába még ezekkel az icmp csomagokkal, "mire való"-ságukkal, biztonságilag követek-e el nagy hibát, ha úgy gondolom, hogy az összes icmp csomagot engedélyezem, szûrni csak udp és tcp-re szûrök
Megoldható-e ez ez a két sor helyett:

Idézet

iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT -m limit --limit 2/second --limit-burst 5

Ezzel:

Idézet

iptables -A INPUT -p icmp --icmp-type any -j ACCEPT

Továbbá szeretném az 53-as udp-n kívül minden udp port tiltását befelé, ezt akkor megtehetem a tcp-hez hasonlóan így: ?

Idézet

iptables -A INPUT -p udp -j REJECT

A "végsõ" konfig valami ilyesmi lenne a mostani elképzeléseim, tudásom alapján:

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 22 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p udp -j REJECT
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
iptables -A INPUT -j DROP

Jó ez így?
Vagy mit kellene módosítanom, ahhoz, hogy teljesítse a fenti kívánalmakat ?

Továbbá lenne még egy kérdésem, ami csak részben tartozik ide. Ha megnézem akár a /etc/services fájlt, akár interneten keresgélek olyasmi után, ahol listaszerûen felsorolják a portok neveit, hozzá tartozó számokkal, legtöbb esetben szerepel tcp-re és udp-re is, azaz pl. az SMTP, vagy POP3 így néz ki ezeken a listákon:

25   SMTP   tcp
25   SMTP   udp
110 POP3    tcp
110 POP3    udp

Namost eddigi tudásom szerint ezek közül mindkét port tcp port, mármint tcp-n keresztül kapcsolódnak a kliens programok, ill. más smtp szerverek is ezen portokhoz. Miért van udp? Kell-e mindenképpen az udp? Miben csorbulhat a dolog, ha azt "mondom", hogy minden udp-t tiltok, az 53-ason kívül? Azaz tiltom a 25-ös udp-t, tiltom a 110-es udp-t, de mindkettõbõl marad a tcp. Lesz-e akkor mûkdõképes, "teljes értékû" levelezõ szerverem ?

(Sorry, hogy ilyen mogorvának tûnök, de ekkora hozzászóláshoz már kevés a felhasználható szmájli.)

[Friczy]

Idézet: Mono - Dátum: 2005. jan. 6., csütörtök - 14:45

Továbbá nagyon nem vagyok tisztába még ezekkel az icmp csomagokkal, "mire való"-ságukkal, biztonságilag követek-e el nagy hibát, ha úgy gondolom, hogy az összes icmp csomagot engedélyezem, szûrni csak udp és tcp-re szûrök
Megoldható-e ez ez a két sor helyett:


Ezzel:



Továbbá szeretném az 53-as udp-n kívül minden udp port tiltását befelé, ezt akkor megtehetem a tcp-hez hasonlóan így: ?



A "végsõ" konfig valami ilyesmi lenne a mostani elképzeléseim, tudásom alapján:

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 22 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p udp -j REJECT
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
iptables -A INPUT -j DROP

Jó ez így?
Vagy mit kellene módosítanom, ahhoz, hogy teljesítse a fenti kívánalmakat ?

Továbbá lenne még egy kérdésem, ami csak részben tartozik ide. Ha megnézem akár a /etc/services fájlt, akár interneten keresgélek olyasmi után, ahol listaszerûen felsorolják a portok neveit, hozzá tartozó számokkal, legtöbb esetben szerepel tcp-re és udp-re is, azaz pl. az SMTP, vagy POP3 így néz ki ezeken a listákon:

25   SMTP   tcp
25   SMTP   udp
110 POP3    tcp
110 POP3    udp

Namost eddigi tudásom szerint ezek közül mindkét port tcp port, mármint tcp-n keresztül kapcsolódnak a kliens programok, ill. más smtp szerverek is ezen portokhoz. Miért van udp? Kell-e mindenképpen az udp? Miben csorbulhat a dolog, ha azt "mondom", hogy minden udp-t tiltok, az 53-ason kívül? Azaz tiltom a 25-ös udp-t, tiltom a 110-es udp-t, de mindkettõbõl marad a tcp. Lesz-e akkor mûkdõképes, "teljes értékû" levelezõ szerverem ?

(Sorry, hogy ilyen mogorvának tûnök, de ekkora hozzászóláshoz már kevés a felhasználható szmájli.)

Idézet

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 22 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT -m limit --limit 2/second --limit-burst 5
iptables -A INPUT -j DROP

Ebbõl elvileg a

iptables -A INPUT -p tcp -j REJECT

sor felesleges, majd késõbb visszatérek rá. Bajt persze nem csinál.

Hasonlóképpen a

iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

sor is, mert ezt az ESTABLISHED,RELATED állapotszabály amúgy is be fogja engedni. Az echo-request korlátozása nem rossz ötlet.

Idézet

Ez látszólag mûködget, de - itt most nagyon nem leszek képben - olyasvalamit hallottam, hogy a ping-en kívül "élnek" más icmp csomagok is, azaz más dolgokra is használatosak az icmp csomagok, mint pingelésre. Hallottam olyat, hogy egyes SMTP szerverek, ill. routerek is használják az icmp csomagokat.

Az icmp (Internet Control Message Protocol) elég sokféle dolog jelzésére, különféle forgalomvezérlésekre használatos. Pl. ha kapcsoódni akarsz valahova, de a gép nem elérhetõ, akkor feltehetõleg vissza fogsz kapni egy icmp-destination-unreachable csomagot. De icmp-vel vezérelhetõ pl. az is, ha a router szól a gépnek, hogy ezt a csomagot ne felé, hanem más irányba kell küldeni, és még elég sok létezik. Viszont - ahogy írtam - a RELATED engedélyezése erre megoldást ad.

Idézet

Gondolom nem pingelnek, hanem valami más, de icmp csomagokat küldözgetnek. Erre a fentebbi írásod alapján akkor ez a sor megoldást kínál, így nem kell attól tartanom, hogy egy SMTP kapcsolódáskor, ha valaki icmp-t is szeretne tõlem, nem kapja meg?

Pontosabban nem arról van szó, hogy tõled valaki icmp-t szeretne, hanem hogy neked icmp üzenetet küld, amely egy általad korábban kezdeményezett csomaghoz kapcsolódik. A te géped bármikor tud küldeni icmp csomagot, ha valamiért kellene, mert az output láncban nem szûrsz.

Idézet

Továbbá nagyon nem vagyok tisztába még ezekkel az icmp csomagokkal, "mire való"-ságukkal, biztonságilag követek-e el nagy hibát, ha úgy gondolom, hogy az összes icmp csomagot engedélyezem, szûrni csak udp és tcp-re szûrök
Megoldható-e ez ez a két sor helyett:

Megoldható, hogy az összes icmp-t beengeded, de erre nincs szükség. Mint írtam, a RELATED engedélyezi azokat, amelyek valóban a jogos forgalomhoz kellenek, a pinget engedélyezted, más meg nem igazán szükséges.

Idézet

Továbbá szeretném az 53-as udp-n kívül minden udp port tiltását befelé, ezt akkor megtehetem a tcp-hez hasonlóan így: ?

iptables -A INPUT -p udp -j REJECT

Megoldható, de igazából felesleges, mindjárt kitérek rá (ahogy a tcp-nél is írtam a REJECT szabályodra.) Bajt nem csinál persze.

Idézet

Ha megnézem akár a /etc/services fájlt, .... (tcp ill udp egyes portokra) ...

A services file illetve a port listák nem minden esetben mérvadóak. Sok esetben - akár biztonság kedvéért, akár lustaságból - lefoglalják az adott protokollra a tcp-t és udp-t, de nem használják ki. Az smtp, pop3 egyértelmûen csak tcp-t használnak (ez a megfelelõ rfc-bõl derül ki, de hacsak nem akarsz túl sok idõt ráfordítani ezek olvasgatására, pillanatnyilag hidd el nekem
Viszont pl. a dns adott esetben használhatja a tcp-t is, ezt nem árt azoknak tudni, akik dns servert üzemeltetnek. Ha klienst használsz (fõleg, ha csak Linuxos klienst), akkor ezzel többnyire nem kell foglalkoznod.

Nézzük a végsõ (?) konfigot:

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 22 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p udp -j REJECT
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
iptables -A INPUT -j DROP

Mint írtam, az összes icmp engedélyezésénél elegánsabb, ha ráhagyod a dolgot az iptablesre, és te csak az icmp-echo-requestet engedélyezed (mondjuk a korlátozásoddal, tehát ebbõl a szempontból az elõbbi konfig jobban tetszett.) Az icm-echo-reply-t viszont felesleges külön engedélyezni, mert az normál esetben csak egy echo-requestre jöhet válaszként (vagyis amikor te pingelsz másik gépet), így ez gyakorlatilag az ESTABLISHED állapotban lekezelõdik.

Ha te csak DNS kliens vagy, akkor felesleges az udp 53 engedélyezése is, kifelé ki tud menni a kérés, a válasz pedig megint csak be tud jönni, mert az ESTABLISHED állapot lekezeli. (Ne tévesszen meg, hogy az UDP kapcsolat nélküli protokoll, az iptables nem ebbõl a szempontból tekint felépítettnek egy kapcsolatot) udp 53 engedélyezése csak akkor kell, ha te DNS servert is szeretnél mûködtetni, vagy DNS cache-t a belsõ háló többi gépe számára. (ez esetben viszont elképzelhetõ, hogy a tcp 53-at is engedni kell, láttam már olyat, hogy windowsos kliens egyetlen cím lekéréséhez is tcp-n kezdeményezte a dns kérést, ami ugyan hülyeség és pazarlás, de ez nem érdekelte).

Na akkor térjünk rá arra, hogy miért mondtam feleslegesnek az

ptables -A INPUT -p tcp -j REJECT
iptables -A INPUT -p udp -j REJECT

sorokat. Azért, mert a lánc utolsó szabálya igy iptables -A INPUT -j DROP, vagyis minden olyan csomagot eldob, amely eddig nem futott valamilyen szabályra rá. Emiatt felesleges külön REJECT.

Még egy megjegyzés, a REJECT és DROP különbségére. A DROP a csomagot eldobja mindenféle visszajelzés nélkül, a REJECT pedig visszaküld egy jelzést (icmp), hogy a gép (vagy a port) nem érhetõ el. Ez azt eredményezi, hogy REJECT esetén a kezdeményezõ oldal azonnal értesül arról, hogy nem fogadta valaki a csomagot, míg DROP esetén nem. A mi szempontunkból szinte mindegy, de a kezdeményezõ szempontjából nem, mert DROP esetén várnia kell. Emiatt általában a DROP szabályt szokták jobban szeretni tûzfalon, mert pl. egy portscan sokkal tovább tart a potenciális támadónak. Viszont van egy port (tcp 113 - ident), amit ez esetben is érdemes REJECT-re küldeni. Sok service mûködik úgy, hogy amikor kezdeményezés érkezik hozzá, akkor visszaküld egy kérést az ident portra, amibõl ki tudja találni, hogy mely felhasználó kezdeményezte a kapcsolatot. Ez ugyan nem kívánatos, ezért ezt vissza is szokás utasátani (meg amúgy sem fut okvetlenül az ident daemon), viszont ha a 113-as portra érkezõ kérést DROP-oljuk, akkor a kért service a timeout lejártáig várni fog, és csak utána jön rá, hogy tõlünk bizony identet nem kap, és csak akkor enged be. (kicsit idejétmúlt viselkedés, de van ilyen) Ha viszont REJECT van, akkor nincs ez a várakozási idõ. (irc-zõk sokszor tapasztalhatják, hogy a server elég sokára engedi õket be, ennek ez az oka).

Tehát én úgy zárnám az iptables szabályaimat:

iptables -A INPUT -p tcp --dport 113 -j REJECT
iptables -A INPUT -j DROP

Huh, ez megint hosszó lett, sorry

[Mono]

Friczy! Nem idézlek be, mert az már nagyon hosszú lenne De nagyon-nagyon köszönöm!
Rettentõ sokat segítettél ezzel, azt kell mondjam, hogy amit eddig nem, vagy nem igazán láttam tisztán, az már sokkal világosabb számomra!
Nos, akkor ennek tükrében a következõ lenne a "végleges" konfig, "áldásod" adod rá?

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 22 -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 --dport 113 -j REJECT 
iptables -A INPUT -j DROP 

Ajánlásodra kivettem az 53-as portot is, mivel elsõdleges körben nem szeretnék DNS szervert, mail szerver lenne majd, bár ezzel a tudással, amit itt szereztem ez már minden linuxos gépre mehet, természetesen a megfelelõ portok nyitogatásával. Mivel levelezne, nyilván neki kell DNS hozzáférés, de csak kliens szinten, mivel kifelé minden mehet, ESTABLISHED miatt képes megjönni a DNS válasz is, akkor ne tovább, nem nyitok 53-as portot

Ezzel részben kapcsolatos dolog miatt küldtem egy privit!   

Szerkesztette: Mono 2005. 01. 06. 17:08 -kor

[diab303]

apro kiegeszites.. mindegyik demont aminek nem kell kifele latszania konfigurald be hogy csak a belso interfacen figyeljen, igy meg veletlenul sem lehet kintrol elerni
pl egy gateway/tuzfal linuxon szokott egy caching DNS server futni ami a belso halonak ad dns-t, beirod a /etc/bind/named.conf (vagy named.options) -ba az options { } koze, hogy (ha pl 192.168.1.101 a belso ip cime)

        listen-on {
                192.168.1.101;
                127.0.0.1;
        };

[Mono]

Idézet: diab303 - Dátum: 2005. jan. 7., péntek - 1:35

apro kiegeszites.. mindegyik demont aminek nem kell kifele latszania konfigurald be hogy csak a belso interfacen figyeljen, igy meg veletlenul sem lehet kintrol elerni
pl egy gateway/tuzfal linuxon szokott egy caching DNS server futni ami a belso halonak ad dns-t, beirod a /etc/bind/named.conf (vagy named.options) -ba az options { } koze, hogy (ha pl 192.168.1.101 a belso ip cime)

        listen-on {
                192.168.1.101;
                127.0.0.1;
        };

Igen, köszi, ez jó ötlet, gondoltam már erre is. Alapvetõen most is így van a dolog, csak van egy pár olyan szolgáltatás, amirõl nem sok fogalmam van, de kintrõl tuti nem kellene látszódnia.

[diab303]

Idézet

Igen, köszi, ez jó ötlet, gondoltam már erre is. Alapvetõen most is így van a dolog, csak van egy pár olyan szolgáltatás, amirõl nem sok fogalmam van, de kintrõl tuti nem kellene látszódnia.

egyszer kb 2 eve debianeknal megvaltozott valami a samba configban es egyszeruen az (akkor mar) hibasnak velt interface megadast/limitet figyelmen kivul hagyta, es szepen kisharelte jelszo nelkul a filejaimat a net fele is. egett is a pofam mikor valaki szolt miatta (ugy hogy krealt egy beszedes nevu konyvtarat a share gyokerebe..).
ugyhogy kell az az iptables

[kroozo]

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

egyszer kb 2 eve debianeknal megvaltozott valami a samba configban es egyszeruen az (akkor mar) hibasnak velt interface megadast/limitet figyelmen kivul hagyta, es szepen kisharelte jelszo nelkul a filejaimat a net fele is. egett is a pofam mikor valaki szolt miatta (ugy hogy krealt egy beszedes nevu konyvtarat a share gyokerebe..).
ugyhogy kell az az iptables

hmm, na igen, természetesen senki nem vitatja, hogy szükség van a tûzfalra (naná) meg rengeteg mindent el lehet vele intézni (lásd a fenti hosszú és tartalmas beszélgetést (bw Friczy, ennyit gépelni )), de alapvetõen azért illik a szolgáltatásainkat eleve úgy beállítani, hogy tûzfal nélkül is csak onnan látszanak ahonnan muszáj, és csak annak legyenek exploit nélkül is elérhetõek, akinek kell (bele se merek gondolni egy olyan samba.confba ami anon lusernek megengedi az írást... brrrr. ). Ez szerintem egy igen jó és hasznos gyakorlat, ha másért nem, mint egy második védelmi vonal..... Jah igen, és ki is kell próbálni....

Meg egyébként is, az egy másik rendszer, ami -többek között- kbelsõ szerkezetének hibáit egyre erõszakosabb határvédelmi megoldásokkal próbálja megoldani. (nem akarok ujjal mutogatni az SP2-re :Ð)