Convert 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: Bu xinetd nedir? Derleme ve Yükleme Yapılandırma Access Control Service defaults Servisin Yapılandırılması Port binding: the bind attribute Dieğr makinaya servis redirection : redirect bileşeni Special services Let's play a bit... Starting with a riddle chroot service Sonuç pop3 server Bu yazı için görüş bildiriminde bulunabilirsiniz

xinetd

Çeviri : Kadriye Öztürk

Ö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?

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

• TCP, UDP and RPC servisleri için erişim kontrolü (Sonuncular henüz iyi desteklenmiyorlar.)
• zaman bölümü (time segments) tabanlı erişim kontrolü
• tam giriş yapma, bağlantı başarılı veya hatalı olsa da
• Deny of Services (DoS) ataklarına (kaynaklarını doyurarak bir makinayı dondurmaya(freeze) çalışan ataklar) karşı etkin içerik :
  • aynı zamanda çalışan benzer tip sunucuların sayısında sınırlama
  • sunucuların toplam sayısında sınırlama
  • log dosyalarının boyutunda sınırlama.
• özel bir arayüze bir servisin bağlanması: Bu size, örneğin servislerin dışarıda değil sizin özel ağınızda kullanılabilir olmasına izin verir.
• diğer sistemlere proxy gibi kullanılabilir. İç ağa erişebilmek için IP maskelendirmesi - ip_masquerading (veya Ağ Adres Çevirici - Network Address Translation - NAT) ile oldukça kullanışlı bir birliktelik.

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

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.

Bazı sinyaller xinetd 'nin davranışlarını nitelemek için kullanılır:

• SIGUSR1 : yazılım tekrar biçimlendirimi : Biçimlendirim dosyası tekrar okunur ve servis parametreleri buna göre değiştirilir
• SIGUSR2 : donanım tekrar biçimlendirimi: yukarıdaki gibi, ama daha fazlası kullanım dışı deamonlar öldürülür
• SIGTERM : xinetd 'yi ve yarattığı deamonları öldürür

Yapılandırma

İ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

defaults bölümü şuna benzer:

defaults
{
    attribute operator value(s)
    ...
}

only_from = 192.168.1.0/24 192.168.5.0/24 192.168.10.17

config dosyasındaki servisi anlatan her bölüm şuna benzer:

serviceservice_name
{
    attribute operator value(s)
    ...
}

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.
 
   

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:

• erişim kontrolünü makina adı çözünürlülüğüyle yapabilirsiniz. Bunu yaparken, xinetd her_bağlantı_için belirlenmiş makina ad(lar)ı üzerinde arama yapar ve bağlantı adreslerini, makina adlarından dönen adreslerle karşılaştırır;
• erişim kontrolünü .domain.com ile yapabilirsiniz. İstemci bağlandığında, xinetd bağlantı adresini yerdeğiştirir ve belirlenmiş alan adında olup olmadığına bakar.

Service defaults

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

only_from = 0.0.0.0/0

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

only_from = 192.0.0.0/8

only_from =

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
}

Servisin Yapılandırılması

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
}

Port binding: the bind attribute

Ö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
}

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)

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

Dieğr makinaya servis redirection : redirect bileşeni

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
}

>>telnet charly
Trying 192.168.1.1...
Connected to charly.
Escape character is '^]'.
 

Digital UNIX (sabrina) (ttyp1)

login:

Special services

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.

defaults {
  ...
  disabled = servers services xadmin
  ...
}

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.

service xadmin
{
  type  = INTERNAL UNLISTED
  port  = 9100
  protocol = tcp
  socket_type = stream
  wait  = no
  instances = 1
  only_from = 192.168.1.1  #charly
}

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 ...

Let's play a bit...

Starting with a riddle

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
}

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

/var/log/services :
Sep 18 17:15:42 charly in.fingerd[28857]: refused connect from 192.168.1.1

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.

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

chroot [options] new_root

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
}

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
     }

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

2001-03-17, generated by lfparser version 2.9

mirror server hosted at Truenetwork, Russian Federation.