Home Map Index Search News Archives Links About LF
[Top bar]
[Bottom bar]
Bu makalenin farkl� dillerde bulundu�u adresler: English  Castellano  Deutsch  Francais  Nederlands  Turkce  

convert to palmConvert to GutenPalm
or to PalmDoc


taraf�ndan Frédéric Raynal

Yazar hakk�nda:
Fr�d�ric Raynal parmak say�sal resimlerin watermarking'i hakk�nda INRIA (Institut National de Recherche en Informatique et Automatique)'da bir tez haz�rl�yor.
��erik:

xinetd

�eviri : Kadriye �zt�rk

security

�zet:

xinetd - geni�letilmi� Internet servisleri daemon'� (eXtended InterNET services daemon) - i�eri sokulmaya kar�� iyi bir g�venlik sa�lar ve Servislerin reddi- Deny of services (DoS) nin risklerini azalt�r. En iyi bilinen �ift gibi (inetd+tcpd), verilen bir makinan�n eri�im haklar�n� d�zenlemeye izin verir, ama o bundan daha fazlas�n� da yapabilir. Bu makalede onun bir�ok �zelli�ini ke�fedece�iz.


 

Bu xinetd nedir?

Klasik olarak inetd bir bilgisayar�n a� ba�lant�lar�n� kontrol etmeye yard�m eder. inetd taraf�ndan y�netilen bir porta istek geld�inde, inetd bunu tcpd denilen bir programa g�nderir. Tcpd, iste�e izin verilip verilmeyece�ini hosts.{allow, deny} dosyalar�ndaki kurallara g�re karar verir. �ste�e izin verilirse, ilgili sunucu s�reci (process) ba�lat�l�r (e.g ftp). Bu mekanizma tcp_wrapper olarak da bilinir.

xinetd, tcp_wrapper'�n sa�lad���na benzer eri�im kontrol� yeteneklerine sahiptir. Bununla birlikte, onun yetenekleri daha fazlad�r:

Ana geri�ekilim, az �nce bahsedilen, zay�f desteklenmi� RPC �a�r�lar�n� ilgilendirir. Bununla birlikte, portmap ve xinetd birlikte iyi �al���rlar.

Bu makalenin ilk b�l�m� xinetd'nin nas�l �al��t���n� anlat�r. Servis bi�imlendiriminde ve baz� �zel se�eneklerde (Bir aray�ze ba�lama (binding), redirection) zaman harcayaca��z, sonra bunlar� �rneklerin yard�m�yla uygulamayla a��layaca��z. �kinci b�l�m ise xinetd'nin �al��mas�n�, yaratt��� loglar� g�steriyor ve kullan��l� ipu�lar�yla da bitiyor.    

Derleme ve Y�kleme

xinetd'yi �u adresten elde edebilirsiniz: http://www.xinetd.org/. Bu makale i�in 2.1.8.9pre10 s�r�m�n� kullan�yoruz.
Derleme ve y�kleme klasik yolla yap�l�r: al���lm�� komutlar ./configure; make; make install hepsini yap�n :) configure al���lm�� se�enekleri desteklerler. �� �zel se�enek derleme an�nda kullan�labilir:
  1. --with-libwrap : bu se�enekle, xinetd, tcpd bi�imlendirim dosyalar�n� (/etc/hosts.{allow, deny}) kontrol eder ve eri�im kabul edilirse kendi kontrol usullerini kullan�r. Bu se�en�in �al��mas� i�in, tcp_wrapper ve k�t�phanelerinin makinaya y�klenmi� olmas� gerekmektedir. (Yazar�n notu: wrapper ile ne yap�labiliyorsa xinetd ile de yap�labilir. Buna izin vermek, config dosyalar�n�n �o�almas�na ve y�netimin daha g�� olams�na yol a�ar. �zetle tavsiye etmiyorum.)
  2. --with-loadavg : bu se�enek xinetd'nin max_load configuration se�ene�ini kullanmas�na izin verir. Bu size makinaya fazla y�klenildi�inde baz� servisleri yeniden aktive etmenizi sa�lar. Baz� DoS ataklar�n� (max_load niteli�ini table 1 de kontrol edin) �nlemek i�in gerekli bir se�enek.
  3. --with-inet6 : e�er IPv6 'y� kullanaca��n�z� d���n�yorsan�z, bu se�enek onu desteklemenize izin verir. IPv4 ve IPv6 ba�lant�lar� y�netilir ama IPv4 adresleri IPv6 �ekline d�n��t�r�l�r.
xinetd 'yi ba�latmadan �nce, inetd 'yi durdurman�za gerek yoktur. Yine de iki deamon'�n umulmayan davran��larda bulunmas�na yol a�maya gerek yok!

Baz� sinyaller xinetd 'nin davran��lar�n� nitelemek i�in kullan�l�r:

Daha ba�kalr� da var (gelin belgelemedeki ve man sayfalar�ndaki bir hatadan bahsedelim: SIGHUP ��plerini (dump) /var/run/xinetd.dump dosyas�na yazar,/tmp/xinetd.dump dosyas�na de�il), ama yukar�da bahsedilen ��� start, stop, restart, soft, hard se�eneklerini (son ikisi s�ras�yla SIGUSR1 ve SIGUSR2 ile ilgilidir) i�eren k���k bir program par�ac���yla kolayca y�netilebilir.    

Yap�land�rma

/etc/xinetd.conf dosyas� xinetd deamon'� (bir komut sat�r� se�ene�i bir ba�kas�na sa�lamas�na izin verir) i�in benimsenmi� bi�imlendirim dosyas�d�r. xinetd bi�imlendirimi �ok zor de�il ama, uzun bir i� olabilir ve s�z dizimi ne yaz�k ki atas� inetd den daha farkl�d�r.

�ki yararl� �zellik (itox ve xconv.pl) xinetd ile sa�lan�r ve /etc/inetd.conf dosyas�n� xinetd i�in bir bi�imlendirim dosyas�na d�n��t�rmeye izin verir. A��k�as� bu, wrapper bi�imlendirim dosyas�nda belirtilen kurallar �nemsenmedi�inden beri yeterli de�ildir. itox program� hala korunmas�na ra�men uzun s�redir geli�tirilmemi�tir. xconv.pl program� iyi bir ��z�md�r, sonu�, xinetd'nin inetd den farkl� olarak sahip oldu�u �zelliklerden dolay� belirtilmek zorunda olsa da.:

>>/usr/local/sbin/xconv.pl < /etc/inetd.conf > /etc/xinetd.conf
Bi�imlendirim dosyas� defaults (benimsenmi�ler) b�l�m�yle ba�lar. Bu b�l�mdeki nitelikler xinetd'nin y�netti�i her serviste kullan�lacakt�r. Bundan sonra, servisler gibi bir�ok b�l�m bulacaks�n�z, onlar�n her biri �zel se�enekleri benimsenmi� olanlarla ili�kili olarak tekrar tan�mlayabiliyor.

defaults b�l�m� �una benzer:

defaults
{
    attribute operator value(s)
    ...
}
Bu b�l�mde tan�mlanan her nitelik sa�lanmi� de�er(ler)i sonra tan�mlancak servislerin hepsi i�in saklar. Bunun i�in, only_from niteli�i, sunucuya ba�lanabilecek yetkilendirilmi� adreslerin bir listesini vermeye izin verir:
only_from = 192.168.1.0/24 192.168.5.0/24 192.168.10.17
Sonra, her bildirilen servis, listede olan b�r adrese sahip makinalar�n eri�imine izin verir. Bununla birlikte, bu benimsenmi� de�erler her servis i�in nitelendirilmelidir (biraz a�a��da a��klanan i�lemcileri kontrol edin). Yine de bu s�re� biraz riskli. Ger�ek�i olursak, kolay ve gizli bir �ekilde bir�eyleri saklamak yerine, benimsenmi� de�erleri tan�mlamamak ve onlar� sonra servislerin i�inde de�i�tirmek daha iyidir. �rne�in, eri�im haklar� hakk�nda konu�ursak en kolay politika herkese eri�imi yasaklamak sonra da ger�ekten gereksinimi olanlar�n herbir servise eri�imine izin vermekten meydana gelir. (tcp_wrapper ile , Bu ALL:ALL@ALL i�eren hosts.deny dosyas�yla ve sadece yetkilendirilmi� (authorized) servis ve adresleri sa�layan hosts.allow dosyas�yla yap�labilir.

config dosyas�ndaki servisi anlatan her b�l�m �una benzer:

serviceservice_name
{
    attribute operator value(s)
    ...
}
�� operat�r mevcuttur: '=', '+=' and '-='. Niteliklerin �o�u sadece '=' i�lemcisini destekler. Bu niteli�e sabit bir de�er veir.'-=' i�lemcisi bir maddeyi silerken, '+=' i�lemcisi bir madde ekler.

table 1 bu �zelliklerin baz�lar�n� k�saca anlat�yor. Sonra da bunlar� nas�l kullan�ca��m�z� birka� �rnekle g�r�ce�iz. xinetd.conf'un yard�m sayfalar� size daha fazla bilgi verecektir.
 
   

Nitelik De�erler ve a��klamalar
flags Sadece en ge�erli de�erler burada bahsedilecektir, di�erleri i�in belgelendirmeye ba�vurun:
  • IDONLY : Sadece bir kimlik sunucusuna sahip istemcilerden gelen ba�lant�lar� kabul eder;
  • NORETRY : hata halinde yeni bir s�recin (process) tekrar �atalla�mas�n� (fork) �nler;
  • NAMEINARGS : server_args niteli�inin ilk bile�eni sunucu i�in argv[0] olarak kullan�l�r. Bu tcpd'yi server niteli�ine yerle�tirerek kullanman�za izin verir ve sonra inetd de yapt���n�z gibi sunucu ad� ve bile�enlerini server_args gibi yazars�n�z.
log_type xinetd benimsenmi� olarak syslogd daemon.info 'yu kullan�r.
  • SYSLOG selector [d�zey] : syslogd dan daemon, auth, user veya local0-7 den birini se�menize izin verir;
  • FILE [max_size [absolute_max_size]] : belirtilmi� dosya bilgi al�r. �ki se�enek dosyan�n boyutunun s�n�r�n� belirler. Bu boyuta gelindi�inde, ilk se�enek syslogd 'ye bir mesaj g�nderir, ikincisi de bu servise giri�i durdurur E�er bu bir ortak dosya ise - veya sabitle�tirilmi� - farkl� servisler ilgilenebilir).
log_on_success Bir sunucu �al��t���nda farkl� bilgiler giri� yapabilir:
  • PID : sunucunun PID'i (E�er bu bir i� xinetd servisi ise PID n�n de�eri 0 olur);
  • HOST : istemci adresi;
  • USERID : RFC1413 kimlik belirleme protokol�ne g�re uzaktaki kullan�c�n�n kimli�i belirlenir;
  • EXIT : s�recin (process) ��k�� durumu;
  • DURATION : oturum s�resi.
log_on_failure Burada tekrar, sunucu kaynaklar�n�n eksikli�inden veya giri� kurallar�ndan dolay� �al��mad��� zaman xinetd bir�ok bilgi giri�i al�r:
  • HOST, USERID : yukar�da bahsedildi�i gibi;
  • ATTEMPT : bir eri�im te�ebb�s�n� girer. Ba�ka bir de�er atanana kadar bu benimsenmi� bir de�erdir;
  • RECORD : istemcide m�mk�n olan her bilgiyi girer.
nice nice komutunun yapt��� gibi sunucunun �st�nl�k hakk�n� de�i�tirir.
no_access Bu servise eri�im hakk� olmayan kullan�c�lar�n listesi.
only_from Yetkilendirilmi� (authorized) istemcilerin listesi. Bu niteli�e hi� bir de�er atanmad�ysa servi�e eri�im reddedilir.
port Servise ilgili portlar. Bu /etc/services dosyas�nda da tan�mland�ysa, her iki port numaras� e�le�melidir.
protocol Belirtilmi� protokol /etc/protocols dosyas�nda olmal�d�r. E�er hi�bir protokol verilmemi�se, yerine servisin benimsenmi� birtanesi kullan�l�r.
server Sunucunun yolu.
server_args Sunucuya verilen bile�enler.
socket_type stream (TCP), dgram (UDP), raw (IP direkt eri�imi) veya seqpacket ().
type xinetd 3 tip servisi y�netebilir:
  1. RPC : /etc/rpc dosyas�nda tan�mlananlar i�in... ama �ok iyi �al��maz;
  2. INTERNAL : xinetd taraf�ndan direkt olarak y�netilen servisler i�in (echo, time, daytime, chargen ve discard);
  3. UNLISTED : /etc/rpc /etc/services dosyalar�ndan birinde tan�mlanmayan servisler i�in;
Not edelim, servers, services ve xadmin i� servislerinde g�rd���m�z gibi �e�itli de�erleri birle�tirmek m�mk�nd�r.
wait Servislerin threadlere do�ru olan davran��lar�n� tan�mlar. �ki de�er kabul edilebilirdir:
  • yes : servis mono-thread dir, sadece bu tipin bir ba�lant�s� servis taraf�nda y�netilebilir;
  • no : bir yeni servis, tan�mlanan maksimum s�n�ra g�re her yeni servis iste�i i�in xinetd taraf�ndan ba�lat�l�r. (Uyar�, benimsenmi� olarak bu de�er s�n�rs�zd�r).
cps Gelen ba�lant�lar�n say�s�n�n s�n�r�. �lk bile�en bu say�n�n kendisidir. S�n�r a��ld���nda, ikinci bile�enin sa�lad��� saniyelerle ifade edilen bir s�rede servis tekrar etkin hale ge�er.
instances Ayn� anda �al��abilecek ayn� tip sunucular�n maksimum say�s�n� belirler.
max_load Bu bir sunucun i�in ger�ek maksimum y�klemeyi verir (�rne�in, 2 veya 2.5). Bu s�n�r�n �tesinde, bu sunucuya gelen istekler reddedilir.
per_source Bir tamsay� veya UNLIMITED(s�n�rs�z), bir sunucuya ayn� kaynaktan gelen ba�lant�lar�n say�s�n� s�n�rlamak i�in kullan�l�r. 
Tab. 1 : xinetd i�in birka� nitelik

tablo1 de g�sterilen son d�rt nitelik, bir sunucuya ba�l� olan kaynaklar�n kontrol�ne izin verir. Bu Denial of Service - Servis reddi (DoS) ataklar�ndan (b�t�n kaynaklar�n� kullanarak makinay� dondurma) korunman�n en etkili yoludur.

Bu b�l�m birka� xinetd �zelli�ini sundu.Bir sonraki b�l�m onu nas�l kullanaca��m�z� g�sterecek ve d�zg�n bir �ekilde �al��mas� i�in birka� kural verecektir.   

Access Control

Daha �nce de g�rd���m�z gibi, IP adreslerini kullanarak makinan�za eri�imleri kabul (red) edebilirsiniz.Bununla birlikte xinetd daha fazla �zelli�e izin verir:

Bunlar� a���a kavu�turmak i�in, a��k�as� IP adresleri daha iyidir, bu yolla bu servise gelen ba�lant�larda isim arama(lar)y� �nlemi� olursunuz. Eri�im kontrol�n� makina ad� ile yapmak zorunda iseniz, yerel bir isim sunucusu (en az�nda bir caching) �al��t�r�rsan�z, i�ler daha h�zl� olur. Adres ��z�n�rl���n�z� yapmak i�in alan ad� yuvalar�n� (socket) kullanman�z daha iyidir (/etc/resolv.conf'un i�ine bir nameserver- isim sunucusu giri�i yerle�tirmeyiniz).

   

Service defaults

defaults b�l�m�, niteliklerin bir say�s� i�in de�erleri ataman�za izin verir (b�t�n liste i�in belgelendirime g�z at�n�z). Bu �zelliklerden baz�lar� (only_from, no_access, log_on_success, log_on_failure, ...) e� zamanl� olarak bu b�l�mde atanm�� de�erleri ve servis taraf�ndan sa�lananlar� tutar.

Benimsenmi� olarak, Bir makinaya eri�imin reddi, ger�ek�i bir g�venlik politikas�n�n ilk ad�m�d�r. Sonra, servislere g�re eri�imlere izin vermek yeterlidir. ��mdi bir makinaya eri�imi kontrol etmeye izin veren IP tabanli iki niteli�i inceleyece�iz: only_from ve no_access. �kincisini se�ersek ve ��yle yazarsak:

no_access = 0.0.0.0/0
servislere eri�imi tamamen engelleriz. Bununla birlikte herkese izin vermek istiyorsan�z �rne�in echo (ping)'e eri�ebilmek i�in, echo servisinde ��yle yazmal�s�n�z:
only_from = 0.0.0.0/0
Bu bi�imlendirmeyle elde edece�iniz giri� ��yledir:
Sep 17 15:11:12 charly xinetd[26686]: Service=echo-stream: only_from list and no_access list match equally the address 192.168.1.1
Ger�ek�i olursak, eri�im kontrol� her iki nitelikteki adreslerin kar��la�t�r�lmas�yla yap�l�r. �stemci adresi her 2 listede e�le�iyorsa en az genel olan� tercih edilir. E�itlik halinde, �rnekteki gibi, xinetd se�im yapamayacakt�r ve ba�lant�y� reddecektir. Bu belirsilikten kurtarmak i�in ��yle yazmal�s�n�z:
only_from = 192.0.0.0/8
Eri�imi sadece nitelikle kontrol etmek i�in daha kolay bir y�ntem:
only_from =
De�er vermemek her ba�lant�y� koparmaz :) Sonra, her servis eri�imi kabul eder.

S�ylenmesi gerek: Verilen bir servis (direkt olarak veya default ile tahsis edilmi� olan) b�l�m� i�in hi�bir kural�n olmad��� durumda (ne bu only_from ne de �tekinde no_access) servise eri�ime izin verilir!

defaults'un bir �rne�i burda:

defaults
{
  instances       = 15
  log_type        = FILE /var/log/servicelog
  log_on_success  = HOST PID USERID DURATION EXIT
  log_on_failure  = HOST USERID RECORD
  only_from       =
  per_source      = 5

  disabled = shell login exec comsat
  disabled = telnet ftp
  disabled = name uucp tftp
  disabled = finger systat netstat

  #INTERNAL
  disabled = time daytime chargen servers services xadmin

  #RPC
  disabled = rstatd rquotad rusersd sprayd walld
}

i� servislerin aras�nda, servers, services, ve  xadmin xinetd'yi y�netebilmenize olanak sa�lar.Daha fazlas� sonra.  

Servisin Yap�land�r�lmas�

Bir sevisi bi�imlendirmek i�in ihtiya� duydu�umuz ... hi�bir�ey yoktur :) Ger�ekte, her�ey benimsenmi� de�erdeki gibi �al���r: Siz sadece servisi y�netmek i�in do�ru nitelik ve de�erlerini kullanmal�s�n�z. Bu, benimsenmi� de�erlerdeki bir de�i�imi veya bu servis i�in ba�ka bir niteli�i ifade eder. Baz� nitelikler servisin tipine (INTERNAL, UNLISTED veya RPC) g�re sunulmal�d�r:
 
 
Nitelik A��klama
socket-type Her servis.
user Sadece �� olmayan servisler i�in
server Sadece �� olmayan servisler i�in
wait Her servis.
protocol Her RPC servisi ve /etc/services da olmayanlar i�in.
rpc_version Her RPC servisi.
rpc_number /etc/rpc de yer almayan her RPC servisi i�in.
port /etc/servicesde bulunmayan her RPC olmayan servis i�in.
Tab. 2: gereksinilen nitelikler

Bu �rnek servisleri nas�l tan�mlayaca��n�z� g�steriyor:

service ntalk
{
  socket_type   = dgram
  wait          = yes
  user          = nobody
  server        = /usr/sbin/in.ntalkd
  only_from     = 192.168.1.0/24
}

service ftp
{
  socket_type  = stream
  wait         = no
  user         = root
  server       = /usr/sbin/in.ftpd
  server_args  = -l
  instances    = 4
  access_times = 7:00-12:30 13:30-21:00
  nice         = 10
  only_from    = 192.168.1.0/24
}

  Not edin bu servisler sadece yerel a�da kullan�labilirler (192.168.1.0/24). FTP hakk�nda, biraz daha fazla s�n�rlama beklenir: sadece 4 kez izin verilir ve bu sadece zaman dilimi s�ras�nda m�mk�nd�r.    

Port binding: the bind attribute

Bu nitelik bir servisi belirli bir IP adresine ba�laman�za (bind) izin verir. E�er makina sadece bir adrese sahipse, bu kullan��s�zd�r. Di�er taraftan, bir yerel a��n par�as� olan ve Internete ba�l� olan bir makinan�n en az�ndan iki adrese sahiptir.

�rne�in, bir �irket m��terileri i�in bir FTP sunucusu y�klemek istiyor ( eri�ebilmek ve belgeleri okumak i�in). Bu �irket ayn� zamanda kendi �r�nlerine do�ru FTP eri�imi yapmak isteyen istemcileri �nlemek istiyor: bind bu �irket i�in yap�ld� :) ��z�m iki ayr� FTP servisi tan�mlamakt�r: biri genel eri�im i�in, di�eri de sadece �irket i�i eri�im i�in. Bununla birlikte, xinetd bunlar� ay�rabilmelidir: ��z�m id niteli�ini kullanmakt�r. Bu bir servisi tek bir yolla tan�mlar (Servis i�inde tan�mlanmad�ysa, de�eri servisin ad�na do�ru kayar).

service ftp
{
  id           = ftp-public
  wait         = no
  user         = root
  server       = /usr/sbin/in.ftpd
  server_args  = -l
  instances    = 4
  nice         = 10
  only_from    = 0.0.0.0/0 #her istemciye izin verir
  bind         = 212.198.253.142 #bu sunucu i�in genel IP adresi
}

service ftp
{
  id           = ftp-public
  wait         = no
  user         = root
  server       = /usr/sbin/in.ftpd
  server_args  = -l
  instances    = 4
  nice         = 10
  only_from    = 0.0.0.0/0 #sadece i� kullan�m i�in
  bind         = 212.198.253.142 #bu servis i�in yerel IP adresi
}

bind �n kullan�m� paketlerin hedefine g�re yerini tutan daemon'�n �a��r�m�na izin verir. B�ylelikle bu bi�imlendirim ile yerel a�daki bir istemci, i� verilere eri�ebilmek i�in yerel adresi (veya ilgili ad�) vermeleri gerekmektedir. log dosyas�nda okuyabilirsiniz:
00/9/17@16:47:46: START: ftp-public pid=26861 from=212.198.253.142
00/9/17@16:47:46: EXIT: ftp-public status=0 pid=26861 duration=30(sec)
00/9/17@16:48:19: START: ftp-internal pid=26864 from=192.168.1.1
00/9/17@16:48:19: EXIT: ftp-internal status=0 pid=26864 duration=15(sec)
�lk b�l�m ftp 212.198.253.142 komutundan gelir, ikinci b�l�m ise charly den kendisine do�ru olan komut hakk�ndad�r:ftp 192.168.1.1.

A��k�as�, e�er bir makina dura�an iki IP adresine sahip de�ilse bir sorun meydana gelir. Bu ppp ba�lant�lar�yla veya dhcp protokol�n� kullan�yorsan�z ortaya ��kar.Servisleri adreslere de�il aray�zlere ba�lamak daha iyi gibi g�z�k�yor. Bununla birlikte bu hala xinetd'den beklenmiyor ve ger�ek bir sorun (�rne�in, bir aray�ze veya OS'e ba�l� adrese ki xinetd bir�ok OS'i destekler eri�ebilmek i�in bir C modul� yazmak). Bir program par�ac��� kullanmak bu sorunu ��zmemize izin verir:

#!/bin/sh

PUBLIC_ADDRESS=`/sbin/ifconfig $1 | grep "inet addr" | awk '{print $2}'| awk -F: '{print $2}'`
sed s/PUBLIC_ADDRESS/"$PUBLIC_ADDRESS"/g /etc/xinetd.base > /etc/xinetd.conf

Bu program par�ac���, dinamik adres i�in bir yedekleme olan PUBLIC_ADRESS'li istenen bi�imlendirimi i�eren /etc/xinetd.base dosyay� al�r. Sonra bunu, program par�ac���na bir bile�en gibi ge�en aray�zle ilgili adresi i�eren PUBLIC_ADDRESS katar�n� belirten /etc/xinetd.conf dosyas�nda de�i�tirir. Sonra, program par�ac���na �a�r� ba�lant�n�n tipine ba�l�d�r: en kolay� �a�r�y� ifup-* dosyas�n�n sa��na eklemek ve xinetd yi tekrar ba�latmakt�r.  

Die�r makinaya servis redirection : redirect bile�eni

xinetd saydam bir proxy gibi kullan�labilir, bununla redirect niteli�inden ayr�l�r (hemen hemen, sonra g�r�ce�iz). Bu, istenen kap�ya (port) bir ba�ka makinaya do�ru bir servis iste�i g�ndermenize izin verir.
telnet service
{
  flags  = REUSE
  socket_type = stream
  wait  = no
  user  = root
  server = /usr/sbin/in.telnetd
  only_from = 192.168.1.0/24
  redirect = 192.168.1.15 23
}
Neler oldu�una gelin bir g�z atal�m:
>>telnet charly
Trying 192.168.1.1...
Connected to charly.
Escape character is '^]'.
 

Digital UNIX (sabrina) (ttyp1)

login:

Ger�ek�i olursak, charly de ba�lant� kurulmu� gibi g�z�k�yor, ama a�a��daki, sabrina ("Digital UNIX") n�n idareyi elinde tuttu�unu g�steriyor. Bu mekanizma ayn� anda kullan��l� ve tehlikeli olabilir. Kuruldu�unda, giri� ba�lant�n�n her iki sonunda da yap�lmal�d�r. Daha �tesi, bu tip servisler i�in, DMZ ve firewall olduk�a tercih edilir.;-)  

Special services

�� servis sadece xinetd'ye aittir. Bu servisler /etc/rpc ve /etc/services de bulunmad���ndan dolay� UNLISTED bayra��na (flag) sahip olmal�d�rlar (INTERNAL bayra��n�n yan�nda bilgilendiren).
  1. servers: kullan�mda olan sunucular hakk�nda bilgi verir;
  2. services: m�mk�n olan servisler hakk�nda protokolleri ve kap�lar� (port) hakk�nda bilgi verir;
  3. xadmin: �nceki iki tanesinin fonks�yonlar�n� birle�tirir.
A��k�as�, Bu servisler bilgisayar�n�z� daha fazla zarar verilebilir hale getirir. �nemli bilgiler sa�larlar. �imdilik eri�im korunmuyor (�ifre korumas� mesela). Onlar� sadece bi�imlendirim zaman�nda kullanmal�s�n�z. Sonra, defaults b�l�m�nde, onlar�n kullan���n� yasaklamal�s�n�z:
defaults {
  ...
  disabled = servers services xadmin
  ...
}
Onlar� aktif hale getirmeden �nce, birtak�m �nlemler almal�s�n�z:
  1. xinetd'nin �al��t��� makina, bu servislere girebilecek tek makina olmak zorundad�r
  2. Buna giri�lerin say�s� s�n�rland�r�n
  3. Sunucudan �al��an makinadan eri�ime izin verin.
Gelin xadmin servisinin bir �rne�ini ele alal�m. (di�er ikiside ayn� yolla bi�imlendirilebilir, kap� (port) say�s� hari�;-):
service xadmin
{
  type  = INTERNAL UNLISTED
  port  = 9100
  protocol = tcp
  socket_type = stream
  wait  = no
  instances = 1
  only_from = 192.168.1.1  #charly
}
xadmin servisi 5 komuta sahip:
  1. help ...
  2. show run : servers servisi gibi, �u anda �al��an sunucular hakk�nda bilgi verir
  3. show avail : services servisi gibi m�mk�n olan servisler hakk�nda bilgi verr (ve biraz daha fazla)
  4. bye veya exit ...
�imdi onlar�n var oldu�unu biliyosunuz: unutun ;-) Bu servisler olmadan test edebilirsiniz. (netstat, fuser, lsof, ... ) gibi komutlar makinan�zda neler oldu�unu, bu servisleri kullan�rken oldu�u gibi onu zarar verilebilir hale getirmeden ��renmenize izin verir!  

Let's play a bit...

 

Starting with a riddle

Burada kurtar�lan birka�� i�in k���k bir �rnek ;-) �nce bu �rnekte kullan�lan bi�imlendirimi a��klayaca��m sonra da neler oldu�unu ve neden �al��mad���n� bulmaya �al��aca��z.

Biz sadece finger servisine ihtiya� duyar�z:

finger service
{
  flags  = REUSE NAMEINARGS
  server = /usr/sbin/tcpd
  server_args = in.fingerd
  socket_type = stream
  wait  = no
  user  = nobody
  only_from = 192.168.1.1  #charly
}
xinetd --with-libwrap se�ene�iyle derlenmedi (server niteli�ini kontrol edin). defaults b�l�m� daha �nce sa�lananlarla ayn� tip: ba�lant� nerden gelirse gelsin charly'ye her giri� yasakland�. Yine de finger servisi tekrar aktif olmad�:
pappy@charly >> finger pappy@charly
[charly]
pappy@charly >>

pappy@bosley >>  finger pappy@charly
[charly]

pappy@bosley >>


�stek, ne yetkilendirilmi� (authorized) makina olan charly (192.168.1.1)'de ne de bosley de d�zg�n �al���yormu� gibi g�z�km�yor. log dosyalr�na bir g�z atal�m:

/var/log/servicelog :
00/9/18@17:15:42: START: finger pid=28857 from=192.168.1.1
00/9/18@17:15:47: EXIT: finger status=0 pid=28857 duration=5(sec)
00/9/18@17:15:55: FAIL: finger address from=192.168.1.10
charly'den gelen istek (ilk iki sat�r) xinetd'ye g�re iyi �al���yor g�z�k�yor: giri�e izin verildi ve istek 5 saniye s�rd�. Di�er taraftan, bosley'den gelen istek ise reddedildi (FAIL).
E�er finger servisinin bi�imlendirimine bakarsak, sunucunun kulland��� in.fingerd de�il tcp_wrapper tcpd servisidir. wrapper log dosyas� ��yle diyor:
/var/log/services :
Sep 18 17:15:42 charly in.fingerd[28857]: refused connect from 192.168.1.1
G�r�ld��� gibi bizim iki sorgulamam�zla e�le�en sadece bir sat�r var! bosley'den gelen (ikincisi) ise xinetd taraf�ndan kesilmi�, bu y�zden bunu kog dosyas�nda bulamamak normaldir. Se�ilen sat�r ger�ektende xinetd'nin izin verdi�i charly'den charly'e g�nderilen iste�e (ilki) benziyor:zaman ve PID leri ayn�.

Elimizde ne oldu�unu gelin �zetleyelim:

  1. xinetd iste�e izin verdi;
  2. finger iste�i tcpd'ye do�ru gitti;
  3. in.fingerd bu iste�i reddetti.
Peki sonra neler oluyor? �stek xinetd taraf�ndan kabul edildikten sonra belirtilmi� sunucuya g�nderildi (burda tcpd). Yine de, tcpd bu ba�lant�y� reddetti. Sonra, hosts.{allow,deny} dosyas�na bir g�z atmak zorunday�z. E�er /etc/hosts.deny dosyas� sadece ALL:ALL@ALL i�eriyorsa bu, iste�in neden wrapper taraf�ndan reddedildi�ini a��klar!

Yola g�re, server ve server_args servis sat�rlar� tan�mland�, wrapper �zelli�i hala eri�ilebilirdir (banner - xinetd'de banner niteli�i var-, spawn, twist, ...). Hat�rlay�n; --with-libwrap derleme se�ene�i, xinetd s�reci ba�lamadan �nce sadece eri�im haklar� kontrol�n� ekler (hosts.{allow,deny} dosyalar�n�n yard�m�yla). Bu �rnekte, bu bi�imlendirim bize tcp wrapper �zelliklerini kullanmaya devam etmemize izin verir.

Bu �zelliklerin �st �ste gelmesi �al��sa bile garip davran��lara yol a�abilir. xinetd'yi inetd ve portmap ile birlikte kullanmak yerine, bir servisi bu "super-daemons" dan sadece biriyle y�netmek daha iyidir.

 

chroot service

Baz� servislerin alanlar�n� s�n�rlamak veya yeni bir �evre (environment) yaratmak �nerilir. chroot komutu, bir komutla (veya program par�ac���) s�per kullan�c� (root) dizinin de�i�tirmeye izin verir:
chroot [options] new_root
Bu �zellikle bind/DNS veya ftp gibi servisleri korumak i�in kullan�l�r. xinetd 'nin �zelliklerinden yararlanarak bu davran��n bir kopyas�n� ��karmak i�in, chroot'u bir sunucu gibi bildirmeniz gerekmektedir. Sonra sadece bile�enleri server_ags niteli�iyle aktarmn�z gerekmektedir.
service ftp
{
  id           = ftp
  socket_type  = stream
  wait         = no
  user         = root
  server       = /usr/sbin/chroot
  server_args  = /var/servers/ftp /usr/sbin/in.ftpd -l
}
B�ylelikle, bu servise bir istek g�nderildi�inde, ilk ad�m�n kulland��� chroot'tur. Sonra, ona g�nderilen ilk bile�en, server_args sat�r�nda ilk yer aland�r ve bu yeni s�per kullan�c�d�r (root). Son olarak, sunucu ba�lat�l�r.  

Sonu�

�imdi, xinetd veya inetd daemonlar�ndan hangisini kullanman�z gerekti�ini sorabilirsiniz. Ger�ek�i olursak, xinetd biraz daha fazla y�netim istiyor, �zelliklede da��t�mlarda yer almad��� s�re i�inde (Red Hat 7.0 da var). Genel eri�imli (Internet gibi) bilgisayarlarda, daha fazla koruma sundu�u i�in xinetd'yi kullanmak en g�venli ��z�md�r. Yerel a�daki makinalara inetd yeterlidir.

 

pop3 server

pop3 olduk�a ilgi g�r�yor gibi g�z�k�yor: Onu xinetd ile nas�l idare edilece�ini soran iletiler ald�m.Burada kolay bir bi�imlendirim: 

     service pop3
     {
             disable = no
             socket_type             = stream
             wait                    = no
             user                    = root
             server                  = /usr/sbin/ipop3d
     #       log_on_success          += USERID
     #       log_on_failure          += USERID
     }
Elbette ki, server niteli�ine kendi yolunuzu yazman�z gerekmektedir.

xinetd'den pop3 kullan�m�, giri� i�in kulland���n�z de�erlere ba�l� oldu�undan zahmetli olabilir. �rne�in, USERID kullan�m�, xinetd'nizden istemcideki pop'ta yer alan bir identd sunucusuna bir istek g�nderir. E�er hi�bir sunucu m�mk�n de�ilse, timeout 30 saniye bekler.

Bu y�zden, birisi iletilerini almaya �al��t���nda, identd sunucusu cevap verene kadar en az�ndan 30 saniye beklemek zorunda kalacakt�r. Bunu �nlemek i�in ikisinden birini se�mek zorundas�n�z:

  1. b�t�n istemcilere bir identd sunucusu y�kleyin b�ylelikle loglar�n�z olduk�a keskin olacakt�r (dikkatli olun, biri identd taraf�ndan sa�lanan bilgileri de�i�tirebilir);
  2. bu servis i�in giri� �zelliklerini azalt�n ki kulllan�c�lar�n�z iletilerini h�zl�ca alabilsinler.

 

Bu yaz� i�in g�r�� bildiriminde bulunabilirsiniz

Her yaz� kendi g�r�� bildirim sayfas�na sahiptir. Bu sayfaya yorumlar�n�z� yazabilir ve di�er okuyucular�n yorumlar�na bakabilirsiniz.
 talkback page 
G�rsely�re sayfalar�n�n bak�m�, LinuxFocus Edit�rleri taraf�ndan yap�lmaktad�r
© Frédéric Raynal, FDL
LinuxFocus.org
Buray� klikleyerek hatalar� rapor edebilir ya da yorumlar�n�z� LinuxFocus'a g�nderebilirsiniz
 �eviri bilgisi:
fr -> -- Frédéric Raynal
fr -> en Georges Tarbouriech
en -> tr Kadriye �zt�rk

2001-03-17, generated by lfparser version 2.9