Doplnkové nastavenia firewallu

linux_server.jpg V pred­chád­za­jú­cej čas­ti sme vy­tvo­ri­li nás­troj na ov­lá­da­nie prís­tu­pu k inter­ne­tu za po­mo­ci pra­vi­diel fi­rewal­lu. Ten­to­raz fi­rewall eš­te troc­hu vy­la­dí­me a zmie­ni­me sa o tom, ako za­bez­pe­čiť čin­nosť niek­to­rých slu­žieb a prog­ra­mov.

Úpra­va fi­rewal­lu na čin­nosť niek­to­rých slu­žieb
Mô­že sa stať, že pri spus­te­ní náš­ho fi­rewal­lu ne­bu­dú ko­rek­tne fun­go­vať niek­to­ré služ­by, prí­pad­ne prog­ra­my. To pre­to, že fi­rewall svo­ji­mi pra­vid­la­mi za­blo­ku­je niek­to­ré pa­ke­ty, kto­ré ko­mu­ni­ku­jú s tý­mi­to prog­ra­ma­mi hlav­ne po­mo­cou ur­či­tých slu­žieb. Te­raz opí­še­me niek­to­ré prob­lé­my a naz­na­čí­me, ako ich rie­šiť. Uni­ver­zál­ne rie­še­nie neexis­tu­je, pre­to­že zá­vi­sí od ďal­ších pra­vi­diel, kto­ré sme nas­ta­vi­li. Nap­riek to­mu tu naz­na­če­né rie­še­nia nás mô­žu do­viesť ku klad­ným vý­sled­kom.

Úpra­va na spo­lup­rá­cu so Sam­bou
V zá­vis­los­ti od nas­ta­ve­ných pra­vi­diel sa mô­že stať, že pri spus­te­ní náš­ho fi­rewal­lu ne­bu­de ko­rek­tne fun­go­vať sys­tém Sam­by, te­da po­čí­ta­če s ope­rač­ným sys­té­mom MS Win­dows sa ne­bu­dú môcť pri­po­jiť na Sam­ba server bež­iaci na li­nuxovom server­i, kde exis­tu­je fi­rewall. Pre­to skús­me do sek­cie vstup­ných pra­vi­diel za­pí­sať to­to pra­vid­lo:

  	ip­tab­les -A IN­PUT -s "$INTER­NAL_NETWORK/$INTER­NAL_MASK" -i 	"$INTER­NAL_IN­TER­FA­CE" 	-d "$INTER­NAL_BROAD­CAST" -j lo­cal;

(Auto­rom tej­to myš­lien­ky je pán Pe­ter Ples­ník.)

Úpra­va na po­uží­va­nie po­što­vých nás­tro­jov
Ak na li­nuxovom server­i, kto­rý slú­ži zá­ro­veň ako fi­rewall, po­uží­va­me aj po­što­vý sys­tém, nap­rík­lad na bá­ze Po­stfixu a prog­ra­mu fet­chmail (vy­svet­le­né v pred­chád­za­jú­cich čas­tiach toh­to se­riá­lu), mô­že sa stať, že prog­ram fet­chmail nie je schop­ný preb­rať po­štu z von­kaj­šej schrán­ky, prí­pad­ne ju ne­do­ká­že od­ov­zdať prog­ra­mu Po­stfix. Ak fet­chmail nez­vlád­ne preb­ra­tie po­šty zvon­ka (čo, sa­moz­rej­me, uvi­dí­me vte­dy, ak ho spus­tí­me s pa­ra­met­rom -v), je to pre­to, že je za­blo­ko­va­ný po­rt 110 (po­p3) ale­bo 143 (imap), prí­pad­ne ich „se­cu­re“ va­rian­ty po­p3s a imaps. Mu­sí­me ich po­vo­liť v de­fi­nič­nej čas­ti fi­rewal­lu. Ak sa fet­chmail do­ká­že spo­jiť s po­što­vou schrán­kou niek­de u po­sky­to­va­te­ľa v inter­ne­te, do­kon­ca vi­dí po­štu, ale ne­do­ká­že ju preb­rať, je to pre­to, že sa ne­mô­že pri pre­be­ra­ní spo­jiť s prog­ra­mom Po­stfix na vnú­tor­nom po­rte 25 (SMTP). Vte­dy mu­sí­me vo fi­rewal­le po­vo­liť vstup pa­ke­tov na roz­hra­ní loop­back. To vy­ko­ná­me pra­vid­lom:

ip­tab­les -A IN­PUT -i lo -j AC­CEPT

a pre is­to­tu eš­te pra­vid­lom

  	ip­tab­les -A IN­PUT -i lo -m sta­te --sta­te NEW -j AC­CEPT

Po­tom už bu­de fet­chmail ko­mu­ni­ko­vať s Po­stfixom a poš­ta bu­de fun­go­vať správ­ne.

Úpra­va na po­uží­va­nie proxy server­a
V prí­pa­de, že po­uží­va­me proxy server Squid a chce­me zá­ro­veň po­uží­vať fi­rewall, mu­sí­me po­vo­liť, aby ko­mu­ni­ká­cia, kto­rá chce pris­tu­po­vať na po­rt 80, čo je štan­dar­dne po­rt WWW strá­nok, bo­la pres­me­ro­va­ná na po­rt 3128, kde na­čú­va proxy server Squid. Vte­dy pri­dá­me pra­vid­lo

ip­tab­les -t nat -A PRE­ROU­TING -p tcp --dport 80 -i $INTER­NAL_IN­TER­FA­CE -j 	RE­DI­RECT --to-po­rt 	3128

Tre­ba mať na zre­te­li, že proxy server Squid mu­sí byť na­kon­fi­gu­ro­va­ný ako tran­spa­rent­ný proxy server. To do­siah­ne­me tak, že do kon­fi­gu­rač­né­ho sú­bo­ru Squidu v /etc/squid/squid.conf vlo­ží­me riad­ky s kon­fi­gu­rač­ný­mi prí­kaz­mi:

  httpd_ac­cel_host vir­tual
    httpd_ac­cel_port 80
    httpd_ac­cel_with_proxy on
    httpd_ac­cel_uses_host_hea­der on

 

Úpra­va na po­uží­va­nie ICQ
Ak v na­šej sie­ti chce­me po­uží­vať prog­ram ICQ, ten má­va prob­lé­my pri ko­mu­ni­ká­cii cez fi­rewall. Keď­že ICQ je schop­né ko­mu­ni­ko­vať pria­mo cez po­rty 4000 až 4100, tie po­vo­lí­me vo fi­rewal­le tak, že vlo­ží­me to­to pra­vid­lo:

ip­tab­les -A FORWARD -p tcp -s 0/0 -d $INTER­NAL_NETWORK/$INTER­NAL_MASK --dport 	4000:4100 -j AC­CEPT";

Tes­to­va­nie jed­not­li­vých nas­ta­ve­ní
Pri tvor­be pra­vi­diel fi­rewal­lu sa veľ­mi čas­to stá­va, že zá­klad­né nas­ta­ve­nie fun­gu­je, ale po pri­da­ní ur­či­tých dopl­ňu­jú­cich pra­vi­diel pres­ta­nú fun­go­vať niek­to­ré služ­by li­nuxové­ho server­a. Je to da­né spô­so­bom vy­hod­no­co­va­nia jed­not­li­vých pra­vi­diel vo fi­rewal­le. Aby sme sa to­mu vy­hli, prí­pad­ne správ­ne vy­rie­ši­li da­ný prob­lém, uve­die­me ur­či­té zá­sa­dy pri od­la­ďo­va­ní jed­not­li­vých prob­lé­mov. V pr­vom ra­de tre­ba už v za­čiat­ku dob­re navr­hnúť zá­kla­dy fi­rewal­lu. Tre­ba si ur­čiť, čo bu­de a ne­bu­de po­vo­le­né, aké služ­by bu­dú či ne­bu­dú dos­tup­né z inter­ne­tu ale­bo z lo­kál­nej sie­te. Maj­me na pa­mä­ti, že aké­koľ­vek „do­ráb­ky“ po spre­vád­zko­va­ní fi­rewal­lu spô­so­bu­jú prob­lé­my v tom, že ov­plyv­ňu­jú jed­not­li­vé pra­vid­lá. Pa­mä­tá­me si, že pra­vid­lá sa vy­hod­no­cu­jú po­stup­ne, a ak sa náj­de zho­da v po­dmien­ke, vy­ko­ná sa ak­cia pra­vid­la. Z to­ho vy­plý­va, že na po­ra­dí ulo­že­nia jed­not­li­vých pra­vi­diel zá­le­ží! Ne­mô­že­me dopl­ňu­jú­ce pra­vid­lo za­pí­sať, kam chce­me! Ak už sme po­sta­ve­ní pred si­tuáciu, že sa pra­vid­lo mu­sí pri­dať, dob­re si pre­mys­li­me, kam ho pri­dá­me! Účel­ný je sche­ma­tic­ký nák­res fi­rewal­lu s pra­vid­la­mi na pa­pier vrá­ta­ne po­zná­mok. Po­tom jed­no­duc­hšie za­na­ly­zu­je­me, kam kto­ré no­vé pra­vid­lo pat­rí! Na pa­pie­ri sa čí­ta po­dstat­ne lep­šie ako na ob­ra­zov­ke, pre­to­že nas­le­du­jú­ce pra­vid­lá na ob­ra­zov­ke ne­vi­dí­me, a pre­to ich mô­že­me ľah­šie preh­liad­nuť. Ak pri­dá­me no­vé pra­vid­lo, po­zna­me­ná­me si ho na pa­pier, ale zá­ro­veň po­dob­nú po­znám­ku za­pí­še­me aj to sú­bo­ru fi­rewal­lu! Dob­rý zvyk je za­pí­sať do ko­men­tá­ra nie­len po­znám­ky, ale aj dá­tum zme­ny, prí­pad­ne zdroj, z kto­ré­ho sme čer­pa­li pri da­nej úp­ra­ve. Sa­moz­rej­mé je reš­tar­to­va­nie fi­rewal­lu po akej­koľ­vek zme­ne je­ho pra­vi­diel, aby sa zme­ny pre­ja­vi­li a my sme ich moh­li otes­to­vať.

Pra­vid­lá do fi­rewal­lu pri­dá­va­me po jed­nom a po jed­nom ich aj od­la­ďu­je­me. Až keď sme si úpl­ne is­tí, že da­né pra­vid­lo s da­nou služ­bou fun­gu­je, od­skú­ša­me os­tat­né služ­by li­nuxové­ho server­a. (Ne­raz sa stá­va, že jed­nu služ­bu po­vo­lí­me a pri jej od­la­ďo­va­ní inú služ­bu za­blo­ku­je­me.) Čas­to sa dos­ta­ne­me do si­tuácie, keď ne­vie­me roz­hod­núť, či da­ná služ­ba ne­fun­gu­je pre fi­rewall ale­bo iné nas­ta­ve­nie, ne­sú­vi­sia­ce s fi­rewallom (nap­rík­lad poš­ta). Pre­to naj­prv fi­rewall vy­pne­me, nas­ta­ví­me po­što­vý server, riad­ne od­skú­ša­me a za­pne­me fi­rewall. Ak služ­ba fun­gu­je, má­me vy­hra­né. Ak nie, po­kú­si­me sa od­had­núť, kto­ré pra­vid­lo fi­rewal­lu spô­so­bi­lo za­blo­ko­va­nie služ­by (v tom­to prí­pa­de po­šty). Ak to ne­do­ká­že­me od­had­núť, vy­pne­me fi­rewall a za­pí­na­me jed­not­li­vé pra­vid­lá krok za kro­kom. To mô­že­me uro­biť tak, že jed­not­li­vé pra­vid­lá fi­rewal­lu za­dá­va­me ruč­ne z kon­zo­ly ale­bo v kon­fi­gu­rač­nom sú­bo­re všet­ky pra­vid­lá „za­re­mu­je­me“ zna­kom # a po­stup­ne ich po­vo­ľu­je­me. Keď zis­tí­me, kto­ré pra­vid­lo spô­so­bu­je blo­ko­va­nie, up­ra­ví­me ho ale­bo vy­tvo­rí­me no­vé pra­vid­lo, kto­ré bu­de tvo­riť vý­nim­ku pre to blo­ku­jú­ce. Po­stu­pom ča­su si vy­tvo­rí­me ur­či­tý cit, že bu­de­me schop­ní od­had­núť rie­še­nie veľ­mi sko­ro a po­mer­ne efek­tív­ne. Aj tu pla­tí, že po od­la­de­ní vý­nim­ky vy­skú­ša­me nie­len da­nú služ­bu, ale aj os­tat­né služ­by a prog­ra­my li­nuxové­ho server­a.

Nie­ke­dy sú však pra­vid­lá fi­rewal­lu už ta­ké kom­pli­ko­va­né, že ne­mož­no us­po­ko­jiť všet­ky na­še po­žia­dav­ky na li­nuxový server zá­ro­veň s fi­rewallom. Vte­dy je veľ­mi vhod­né od­de­liť úlo­hu fi­rewal­lu na sa­mos­tat­ný po­čí­tač a os­tat­né služ­by na dru­hý po­čí­tač, scho­va­ný za fi­rewallom, ale dos­tup­ný z inter­ne­tu. Vte­dy ho­vo­rí­me o de­mi­li­ta­ri­zo­va­nej zó­ne. Ale o tom na­bu­dú­ce.

Ďal­šie čas­ti >>

Zdroj: Infoware 4/2009



Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

Li­nux prak­tic­ky ako server úvod
Linux ako server je pomerne zložitá technológia. Jej výhodou je určitá modularita, keď sa nemusí nastaviť celý server naraz, ale postupne. čítať »
 
Syn­chro­ni­zá­cia ča­su v Li­nuxe
V predchádzajúcich dvoch častiach sme si ukázali, že Linux a všeobecne open source softvér sa nenachádza iba v serveroch a počítačových sieťach, ale aj v iných zariadeniach bežnej domácej potreby a v oblasti hobby. čítať »
 
Za­ria­de­nia za­lo­že­né na Li­nuxe
V predchádzajúcej časti sme si spomenuli definície nie - ktorých pojmov z oblasti nášho záujmu, teda Linuxu. Vysvetlili sme si, čo je to Open Source, Public Domain, proprietárny softvér a GNU GPL. Tentoraz ukážeme, ako sa tieto pojmy využívajú v praxi. čítať »
 
Po­jmy z ob­las­ti
Tentoraz na chvíľu trochu odbočíme od bezpečnosti Linuxu a jeho siete. V tejto neštandardnej časti seriálu sa mu budeme venovať len okrajovo. čítať »
 
Bez­peč­nosť bez­drô­to­vých sie­tí II.
V predchádzajúcej časti sme sa začali zaoberať bezpečnosťou bezdrôtových sietí. Poukázali sme na rôzne faktory zneužitia siete, podstatu rizika a vysvetlili sme základné prvky bezpečnosti. čítať »
 
Bez­peč­nosť bez­drô­to­vých sie­tí I.
V predchádzajúcich častiach sme sa venovali bezpečnosti linuxového servera. Riešili sme firewall, bezpečnosť prístupu na internet, zaoberali sme sa demilitarizovanou zónou a podobne. čítať »
 
Údr­žba lo­gov – kon­fi­gu­rá­cia log­ro­ta­te
V predchádzajúcej časti sme sa venovali rotácii logov. Vysvetlili sme princíp ukladania logov, spôsob, ako sa rotujú, a uviedli sme niečo o tom, čo a ako treba nastaviť čítať »
 
Údr­žba lo­gov – ro­tá­cia
V predošlej časti sme sa zaoberali spôsobom logovania informácií na iný alebo vzdialený počítač a ukázali sme, ako riešiť problém s logovaním uzavretých procesov pomocou chroot. čítať »
 
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter