Nastavenie superdémona xinetd

linux_server.jpg V pre­doš­lej čas­ti sme vy­svet­li­li, čo je dé­mon a čo je su­per­dé­mon xinetd. Zá­ro­veň sme ob­jas­ni­li, ako sa kon­fi­gu­ru­je su­per­dé­mon xinetd, a oz­rej­mi­li sme si naj­čas­tej­šie po­uží­va­né pre­men­né. Te­raz na prík­la­doch uká­že­me, ako vy­užiť spo­mí­na­né pre­men­né na zvý­še­nie bez­peč­nos­ti li­nuxové­ho server­a.

Zá­klad­ná kon­fi­gu­rá­cia
Na vý­pi­se č. 1 je zá­klad­ná kon­fi­gu­rá­cia su­per­dé­mo­na xinetd:

{
	in­stan­ces = 100
	log_ty­pe = SYS­LOG
	log_on_suc­cess  = HOST PID
     log_on_fai­lu­re  = HOST
     cps = 25 30
     in­clu­de­dir /etc/xinetd.d
}

Ten­to vý­pis nie je nas­ta­ve­ním kon­krét­nej služ­by, ale vy­tvá­ra vý­cho­dis­ko­vé nas­ta­ve­nie ce­lé­ho su­per­dé­mo­na xinetd. To­to nas­ta­ve­nie je plat­né pre všet­ky služ­by, ak v ich kon­krét­nych nas­ta­ve­niach nie je ur­če­né inak.

Ob­sah vý­pi­su zna­me­ná:
Maximál­ny po­čet po­žia­da­viek ob­slu­ho­va­ných na­raz je 100 (in­stan­ces). Lo­go­va­nie sa bu­de za­pi­so­vať do sys­lo­gu (log_ty­pe). V prí­pa­de ús­peš­né­ho spo­je­nia (log_on_suc­cess) sa bu­de za­zna­me­ná­vať (lo­go­vať) IP ad­re­sa, od­kiaľ po­žia­dav­ka na spo­je­nie priš­la (HOST), a iden­ti­fi­kač­né čís­lo pro­ce­su (PID), v prí­pa­de neús­peš­né­ho spo­je­nia (log_on_fai­lu­re) sa za­zna­me­ná iba IP ad­re­sa. Xinetd je na­kon­fi­gu­ro­va­ný tak, aby neu­mož­ňo­val viac spo­je­ní za se­kun­du (cps) ako 25. Ak sa ten­to po­čet do­siah­ne, služ­ba si na do­bu 30 se­kúnd „od­dýc­hne“.

Prík­la­dy kon­fi­gu­rá­cie niek­to­rých slu­žieb
Ako sme si už po­ve­da­li, ďal­šie nas­ta­ve­nia sa nac­hád­za­jú v jed­not­li­vých sú­bo­roch slu­žieb, ulo­že­ných v ad­re­sá­ri /etc/xinetd.d, kto­ré sa do kon­fi­gu­rá­cie na­čí­ta­jú pa­ra­met­rom in­clu­de­dir /etc/xinetd.d.

Na vý­pi­se č. 2 je prík­lad kon­fi­gu­rá­cie služ­by ftp.

{
	 dis­ab­le     	= no
       soc­ket_ty­pe = stream
       wait        = no
       user        = root
       server      = /usr/sbin/in.ftpd
       log_on_suc­cess      += DU­RA­TION USE­RID
}

Tú­to služ­bu bu­de ob­slu­ho­vať prog­ram in.ftpd (server) v ad­re­sá­ri /usr/sbin/, beží s prá­va­mi roo­ta a v prí­pa­de ús­peš­né­ho spo­je­nia sa bu­de za­zna­me­ná­vať do­ba tr­va­nia spo­je­nia (DU­RA­TION) a ID po­uží­va­te­ľa (USE­RID). Pa­ra­me­ter dis­ab­le je vy­pí­nač služ­by. Kon­fi­gu­rač­ný sú­bor mô­že exis­to­vať, ale služ­ba ne­bu­de za­pnu­tá, te­da je vy­pnu­tá (dis­ab­le = yes). To­to sa veľ­mi čas­to po­uží­va pri od­la­ďo­va­ní slu­žieb bez nut­nos­ti ma­zať a ko­pí­ro­vať kon­fi­gu­rač­né sú­bo­ry.

Na vý­pi­se č. 3 je prík­lad nas­ta­ve­nia služ­by ssh.

{
	soc­ket_ty­pe = stream
      wait        = no
      user        = root
      server      = /usr/sbin/sshd
	server_args = -i
	ac­cess_ti­mes = 8:00-16:00
	on­ly_from = 192.168.1.1/24
}

Dé­mon ssh je po­uži­teľ­ný den­ne len v ča­se od ôs­mej rá­no do štvr­tej po­obe­de, aj to len z jed­né­ho po­čí­ta­ča s ad­re­sou 192.168.1.1. Ar­gu­ment –i in­for­mu­je dé­mo­na ssh o tom, že bu­de spúš­ťa­ný su­per­dé­mo­nom xinetd.

Pres­me­ro­va­nie slu­žieb
Po­mo­cou su­per­dé­mo­na xinetd mô­že­me pres­me­ro­vať ľu­bo­voľ­nú služ­bu na iný po­čí­tač v sie­ti. Po­uži­je­me na to pa­ra­me­ter re­di­rect. To­to mô­že­me ús­peš­ne po­užiť v prí­pa­de, keď po­tre­bu­je­me iným po­čí­ta­čom mi­mo na­šej sie­te (te­da zvon­ku) sprís­tup­niť služ­bu, kto­rá sa nac­hád­za na po­čí­ta­či, kto­rý je v na­šej sie­ti „scho­va­ný“ za server­om s fi­rewallom, ale­bo vte­dy, keď nap­rík­lad do­čas­ne služ­bu pre­mies­tni­me za iný po­čí­tač. Na vý­pi­se č. 4 je prík­lad pres­me­ro­va­nia služ­by http (po­rt 80) na po­čí­tač s IP ad­re­sou 192.168.1.79.

{
	# pres­me­ro­va­nie služ­by na po­rt 80 po­ci­ta­ca 192.168.1.79
	re­di­rect    = 192.168.1.79 80
}
   

Prin­cíp spo­čí­va v tom, že v prí­pa­de pric­hád­za­jú­ce­ho spo­je­nia su­per­dé­mon xinetd spus­tí pro­ces, kto­rý sa spo­jí s po­čí­ta­čom na IP ad­re­se 192.168.1.79 a všet­ky dá­ta pres­me­ru­je na je­ho po­rt 80.

Oc­hra­na pred útok­mi DoS
My už vie­me, že útok ty­pu DoS (te­da zne­fun­kčne­nie server­a pre­ťa­že­ním a za­hl­te­ním sys­té­mu nad­mer­ným spúš­ťa­ním slu­žieb) je veľ­mi zá­ker­ný, pre­to­že má v po­dsta­te rôz­ne for­my, a tak aj ob­ra­na je po­mer­ne kom­pli­ko­va­ná. Ro­zo­be­rie­me nie­koľ­ko naj­čas­tej­ších prí­pa­dov a spô­so­bov, ako sa za po­mo­ci xinetd brá­niť.

Ob­med­ze­nie slu­žieb v zá­vis­los­ti od vy­ťa­že­nia sys­té­mu
Su­per­dé­mon xinetd ako me­rad­lo za­ťa­že­nia sys­té­mu po­uží­va šta­tis­ti­ku loa­davg, kto­rá vy­jad­ru­je prie­mer­né vy­ťa­že­nie sys­té­mu po­čas po­sled­nej mi­nú­ty. Čís­lo zna­me­ná prie­mer­ný po­čet pro­ce­sov prip­ra­ve­ných na beh (vo vý­pi­se prí­ka­zom ps ale­bo top ma­jú znak R) plus po­čet pro­ce­sov v sta­ve nep­re­ru­ši­teľ­né­ho spán­ku (vo vý­pi­se prí­ka­zom ps ale­bo top ma­jú znak D). Kon­fi­gu­rač­ným pa­ra­met­rom max_load ur­čí­me maximál­ne za­ťa­že­nie sys­té­mu, kto­ré mô­že da­ná služ­ba v sys­té­me spô­so­bo­vať. Ak je hod­no­ta prek­ro­če­ná, ne­bu­dú sa pri­jí­mať ďal­šie po­žia­dav­ky na spo­je­nie.

Spúš­ťa­nie slu­žieb so zní­že­nou prio­ri­tou
Po­mo­cou pa­ra­met­ra ni­ce mô­že­me nas­ta­viť (zme­niť) prio­ri­tu, s kto­rou bu­de da­ná služ­ba spúš­ťa­ná. Prio­ri­tu mô­že­me zni­žo­vať ale­bo zvy­šo­vať. Hod­no­ta pa­ra­met­ra ni­ce udá­va aký­si po­mer k os­tat­ným služ­bám. Zní­že­nie prio­ri­ty do­siah­ne­me za­da­ním klad­né­ho čís­la, nao­pak, zvý­še­nie prio­ri­ty do­siah­ne­me za­da­ním zá­por­né­ho čís­la. Plat­ný roz­sah je -20 až +19 (po­drob­nej­šie in­for­má­cie zís­ka­me z ma­nuá­lo­vých strá­nok ni­ce, prí­pad­ne z ma­nuá­lo­vých strá­nok vo­la­nia jad­ra set­priori­ty a get­priori­ty).

Ob­med­ze­nie sys­té­mo­vých pros­tried­kov pre spúš­ťa­nú služ­bu
Kaž­dá služ­ba po­tre­bu­je na svoj beh ur­či­té sys­té­mo­vé pros­tried­ky, te­da pries­tor v ope­rač­nej pa­mä­ti a pro­ce­so­ro­vý čas. xinetd umož­ňu­je nas­ta­ve­nie li­mi­tov. Ide hlav­ne o at­ri­bú­ty rli­mit_as, rli­mit_da­ta, rli­mit_rss, rli­mit_stack a rli­mit_cpu. Tie­to li­mi­ty fun­gu­jú ako po­is­tka – na ich prek­ro­če­nie sys­tém rea­gu­je ukon­če­ním služ­by. Pa­ra­me­ter in­stan­ces slú­ži na nas­ta­ve­nie maximál­ne­ho po­čtu zá­ro­veň pre­bie­ha­jú­cich kó­pií da­nej služ­by.

Za­brá­ne­nie vy­čer­pa­nia sys­té­mo­vých pros­tried­kov chý­ba­jú­cou služ­bou
Pre prí­pad, že by niek­to­rá služ­ba opa­ko­va­ne ha­va­ro­va­la, exis­tu­je mož­nosť spus­tiť xinetd s voľ­bou –loop. Vý­cho­dis­ko­vá hod­no­ta 10 zna­me­ná, že ak bu­de da­ná služ­ba spus­te­ná viac ako 10-krát po­čas jed­nej se­kun­dy, bu­de sa po­va­žo­vať za chyb­nú a bu­de vy­pnu­tá.

Ov­lá­da­nie su­per­dé­mo­na xinetd
Ak vy­ko­ná­me akú­koľ­vek zme­nu v kon­fi­gu­rá­cii su­per­dé­mo­na xinetd, či už v glo­bál­nych nas­ta­ve­niac, ale­bo v nas­ta­ve­niach jed­not­li­vých slu­žieb, mu­sí­me za­bez­pe­čiť opä­tov­né na­čí­ta­nie kon­fi­gu­rá­cie. To mô­že­me do­siah­nuť za­sla­ním prí­ka­zu SI­GUSR1 ale­bo SI­GUSR2 (SI­GUSR2 na­vy­še spô­so­bí ukon­če­nie bež­iacich in­štan­cií tých slu­žieb, kto­ré po zme­ne kon­fi­gu­rá­cie už nie sú dos­tup­né). Sig­nál su­per­dé­mo­nu xinetd po­šle­me buď po­mo­cou prí­ka­zu kill:

kill -s SI­GUSR1 `cat /var/run/xinetd.pid`
  

ale­bo spus­tí­me štar­to­va­cí skript xinet­du

/etc/rc.d/init.d/xinetd re­load

ale­bo

servic­e xinetd re­load

Na­bu­dú­ce bu­de­me v té­me bez­peč­nos­ti po­kra­čo­vať.

Ďal­šie čas­ti >>

Zdroj: Infoware 4/2010



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