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