Xinetd Daemon Bölüm 2
Bir Servisin Yapılandırılması
Bir servisi yapılandırmak için aslında çok fazla şeye ihtiyaç yoktur. Gerçekte herşey öntanımlı değerleri ile çalışır. Bir servisi yönetmek için bazı özniteliklere ve değerlerine ince ayar yapmak yeterlidir. Bu ise bir servis için sadece değerleri değiştirmek yada başka öznitelikler eklemekten ibarettir. Bazı öznitelikler ilişkili olduğu servis itibari ile varolurlar (INTERNAL, UNLISTED yada RPC). (Tablo 2)
Tablo 2 Gerekli Bazı Öznitelikler
Şekil 5 ve Şekil 6 daki örnekler ile servislerin nasıl tanımlanacağı incelenecektir. Dikkat edilirse bu servislerin sadece yerel ağ için yapılandırıldığı ve yapılandırma için gerekli bazı öznitelikler ise Tablo 2 de görülebilir. FTP sözkonusu olunca, bazı başka kısıtlamaların uygulanması beklenebilir. Örneğin buradada, aynı anda maksimum 4 farklı bağlantı ( instances = 4 ) ancak günün belli saatleri için yapılabilecektir (access_times = 7:00-12:30 13:30-21:00).
Şekil 5
Şekil 6
Bind Özniteliği
Bu öznitelik, bir servisin özel bir IP adresine bağlanabilmesine olanak sağlar. Ancak bir makinenin en az iki adet NIC’e sahip olması durumunda anlam kazanır. Bir arayüzden yerel ağa diğerinden dış ağlara bağlı olan bir sunucu bu duruma model olabilir. Örneğin iç ağa bağlı arayüzden çalışanlarına dış ağa bağlı arayüzden ise ürünlere ulaşmak isteyen müşterilerine servis vermek isteyen bir firmanın varolduğu düşünülürse, çözüm ayrı FTP servisleri çalıştırmak olmalıdır. Bunlardan bir tanesi halka açık (public) diğeri ise firmaya iç ağına özel olmalıdır. Bununla beraber xinetd bu ikisini birbirinden ayırabilir. xinetd’nin bunu yapabilmesi için kullanılması gereken öznitelik id özniteliğidir. id özniteliği servisin adını diğerlerinden ayırt edilebilecek şekilde özelleştirir. Service tanım bloğu içinde tanımlanmadığı zaman değeri servis ismine öntanımlı halde kalmış olur.
Bind özniteliğinin kullanımı, paketlerin hedef adreslerine bağlı olarak karşılık gelen daemon’ın çağırılmasını sağlar. Böylece bu yapılandırma ile iç ağdaki herhangi bir istemci bu ağ için çalışan ftp servisine bağlanmak için o iç ağa ait bir adres yada ilişkili bir isim kullanmak zorunda kalacaktır. # ftp 212.198.253.142 şeklinde bir komut kullanıldığı zaman günlük dosyasında,
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)
şeklinde bir kayıta rastlanırken, # ftp 192.168.1.1. gibi bir komut için ise
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)
loglar bu şekilde olacaktır. Açıkçası ortada bir problem vardır oda eğer bir makinanın iki adet statik adresi yoksa ne olacaktır? Bu daha çok DHCP ile dinamik adresleme yada ppp bağlantıları esnasında meydana gelir. Çözüm, servisleri adreslerden daha ziyade arayüzlere bağlamaktan geçer. Ancak henüz xinetd’nin bu tür bir desteği yoktur ve bu gerçek bir problemdir.
Redirect Özniteliği
xinetd, redirect özniteliği tanımlanarak hemen hemen bir Transparan PROXY olarakda kullanılabilir. riderect, bir servis isteğinin başka bir makinada istenilen porta yönlendirilmesini sağlar.
Şekil 7
Örneğin Şekil 7 de görülen yapılandırmada, redirect özniteliği ile gelen telnet servisi istekleri 192.168.1.15 adresli makinanın telnet portuna yönlendirilmiştir. Böylece atlas makinası
Şekil 8
üzerindeki bu yapılandırma sonucunda atlas üzerine gelen her telnet servis isteği ciragan makinasının telnet servisine yönlendirilmiş olur (Şekil 8). Bu özellik çok faydalı olabildiği gibi, tehlikelide olabilir. Bu yüzden güvenlik duvarı –firewall- kullanılması tavsiye edilir.
Özel Servisler
xinetd’ye ait üç özel sistem servisi vardır. Bu servisler /etc/rpc yada /etc/services dosyalarında bulunmadığı için INTERNAL bayrağı yanında UNLISTED bayrağı ile de tanımlanmalıdırlar. INTERNAL bayrağı ile tanımlanan servisler, xinetd tarafından desteklenen yani /etc/services yada /etc/rpc dosyalarında adı geçen servislerdir. xinetd iç servisleri olarak da adlandırabileceğimiz servers, services ve xadmin servislerin kullanım amaçları arasında,
- 1. servers : sunucuların kullanımda olduğunu bildirir
- 2. services : kullanıma açık, mevcut servislerin adını,protkollerini ve portunu bildirir
- 3. xadmin : server ve services’in fonksiyonlarını birleştirir
sayılabilir. Açıkça bu servislerin kullanılması bir bilgisayarı saldırılara daha açık hale getirebilir. Çünkü bu özel servisler diğer servisler hakkında oldukça fazla bilgi sağlarlar. Halen bu servisler için bir örenğin bir şifre mekanizması yada başka bir metod kullanılarak koruma uygulanmamaktadır. Bu yüzden sadece yapılandırmalar esnasında kullanılmalı ve daha sonra öntanım bloğunada devredışı bırakılmalıdırlar (Şekil 9).
Şekil 9
Bu servisler etkinleştirilirken bazı önlemler almak gerekir:
- Bu servislere bağlanabilen sadece xinetd çalıştıran makina olmalıdır.
- Maksimum bağlantı sayısı 1 olarak ayarlanmalıdır
Örnekte xadmin servisinin nasıl yapılandırılması gerektiği gösterilmiştir (Şekil 10). Yapılandırma bittikten sonra /etc/rc.d/init.d/xinetd restart komutuyla xinetd tekrar çalıştırılır. xadmin servisinin dört adet komutu vardır bunlar ve işlevleri şöyledir:
- 1. help
- 2. show run : servers servisi gibi o an çalışmakta olan sunucuların listesini verir
- 3. show avail : services servisi gibi o an çalışmakta olan servislerin listesini verir.
- 4. by or exit…
xadmin servisi kullanılarak sunucuya ilgili port numarası kullanılarak (örnekte 9100) telnet yapılabilir ve çalışan servis ve sunucular hakkında detaylı bilgi alınabilir (Şekil 11).
Şekil 10
Ancak yinede sistem güvenliği açısından Şekil 11 de görüldüğü gibi sadece yapılandırma zamanında test amacıyla kullanılması ve daha sonra devre dışı bırakılması gerekir.
Şekil 11
Bir servis yapılandırmasında karşılaşılabilecek bir problemi bulmak ve nasıl çözüleceğini incelemek için şu örneği inceleyelim. Önce bu örnekte kullanılan yapılandırmayı açıklayalım sonra neler olduğunu ve neden çalışmadığını arastıralım.
finger servisi Şekil 12 deki gibi yapılandırılmıştır. Bu arada xinetd’nin tcp_wrapper desteği verilmek için – -with-libwrap anahtarı ile birlikte derlenmediği de varsayalım. Bu yüzden server özniteliğinin değeri /usr/src/tcpd olarak atanmıştır. Ayrıca öntanım bloğunda nerden gelirse gelsin atlas’a yapılcak tüm bağlantılar öntanımlı olarak yasaklanma getirilmiştir (no_access=0.0.0.0/0). Fakat finger servisi devre dışı bırakılmamıştır (Şekil 12).
Şekil 12
Atlas ve ciragan adlı makinalardan, atlas makinasındaki ahmet kullanıcısı için bilgi alınmaya çalışılıyor. Ancak atlas makinasında finger servisi çalışmasına rağmen hiçbir bilgi alınmıyor. Ayrıca isteğin reddedildiğine dair bir bilgide sorgulayan kişiye bildirilmemiş.
Şekil 13
xinetd’nin günlük dosyası incelenirse, /var/log/secure (Şekil 14) ilk iki satırda atlas üzerinden gelen sorgulamada xinetd’ye göre atlasın düzgün çalıştığı ve isteği kabul ve süreçin 5 saniye sürdüğü görülüyor (START …. EXIT). Fakat diğer taraftan ciragandan gelen isteğin reddedildiğide görülüyor (FAIL).
Şekil 14
finger servisi ile ilgili xinetd yapılandırması incelenirse, kullanılan sunucu programının aslında in.fingerd olamadığı ve /usr/sbin/tcpd olduğu yani tcp_wrapper olduğu anlaşılır. Bu durumda wrapper logları incelenirse /var/log/messages (Şekil 15),
Şekil 15
Her iki makina için yapılan sorgulamalardan sadece birisi için bir kayıt olduğu farkedilir. Bunun anlamı şudur : ciragan dan gelen sorgulama xinetd tarafından bloke edildiği için burda kaydının olmaması normaldir. Bununla beraber mevcut kayıt ise xinetd’nin izin verdiği yani atlas tan atlasa yapılmış olan sorgulamadır hatta her iki günlük dosyasında da zaman ve PID ‘ler tutmaktadır. Bu durumda olaylar,
- xinetd isteğe izin vermiştir
- finger isteği xinetd tarafından tcpd ‘ye iletilmiştir
- in.fingerd isteği reddetmiştir
sırasıyla gerçekleşmiş gibi gözükmektedir. Aslında gerçekte olan ise, xinetd isteği kabul ettikten sonra server özniteliğinde belirtilen sunucuya yönlendirir (burada tcpd) ama tcpd isteği reddeder. Böylesi bir durumda yapılması gereken tcp_wrapper dosyalarını incelemektir. Eğer /etc/hosts.deny ve /etc/hosts.allow dosyaları incelenirse, ve ilk dosyada ALL:ALL@ALL şeklinde bir deklerasyon ile karşılaşılırsa ve bunun yanında ikinci dosyada eğer finger servisi ile ilgili herhangi bir izin yoksa (örneğin in.fingerd:[email protected]/24 gibi) bu isteğin neden reddedildiğini açıklar. sorun in.fingerd’den değil tcp_wrappers dan kaynaklanmaktadır.
Bir Servisin kök dizinin ayarlanması
Çoğu zaman dosya sisteminin bazı bölgelerinin bir servisin erişimine yasaklamak veya bir servisin özel çevre değişkenleri yaratarak kullanmasını engellemek gerekebilir. Bir sistem komutu olan chroot bir başka komut yada scriptin çalışacağı dizinlerin kök dizinini değiştirir. Böylece komut o dizinden itibaren çalışacaktır.
chroot [options] new_root_directory
bu uygulama ençok BIND, DNS ve FTP servislerini korumak için yapılır. xinetd’nin özelliklerinden fayda sağlarken bu davranışı gerçeklemek için, örneğin ftp servis tanım bloğunda server özniteliğini /usr/bin/chroot olarak değeri ile atamak yeterlidir (Şekil 16). Sunucu özniteliğinde tanımlanan chroot komutuna gönderilecek olan parametrelerden biri ise (server_args özniteliğini) ftp servisini veren program olmalıdır. /usr/sbin/in.ftpd –l
Şekil 16
Böylece bir servis isteği geldiği zaman ilk kullanılan yönerge (instruction) chroot olacaktır. Daha sonra ilk argüman server_args satırındaki ilk parametre yani chroot ile bu servis için değiştilecek olan kök dizininin yolu ikincisi ise ftp servisini çalıştıracak olan sunucu programıdır. Arkasından sunucu bu dizin ile çalıştırılır (Şekil 16).
pop3 sunucu
Bu bölümde oldukça yaygın olarak kullanılan pop3 servisinin xinetd yapılandırmasının nasıl yapıldığı incelenecektir. Pop3 servisinin xinetd ile kullanılması günlük tutmak için kullanılan özniteliklerin aldığı değerlere bağlı olarak problemli olabilir.
Şekil 17
Örneğin bir USERID öznitelik değeri kullanıldığı zaman xinetd, pop3 istemcinin çalıştığı makina üzerindeki identd sunucusuna istek gönderir. Eğer bu makina üzerinde identd sunucusu çalışmıyor ise veya identd ile ilgili başka bir problem varsa, pop3 sunucu 30 saniyelik bir bekleme sürecine girer. Bu arada pop3 istemcide maillerini çekmek için bekleyen kullanıcı bu süre boyunca beklemek zorunda kalır. Böyle bir durumda iki şey yapılabilir,
- Her pop3 istemciye identd sunucusu kurulur böylece loglar çok daha kesin bilgiler içirir (Ancak ağ üzerinde bu bilgiler güvenli değildir ve üçüncü kişiler değiştirebilir)
- Kullanıcılar maillerini çabucak alsın diye bu servisin günlükleme kalitesi düşürülür (Şekil 17).
ÖZNİTELİKLER ve DEĞERLERİ
id
Bu öznitelik bir servisin adını ayırtedici olarak belirlemek için kullanılır. Yapılandırma dosyasında farklı protokoller kullanan servisler olabilir ve bu yüzden değişik girdilerle tanımlanmak zorundadırlar. Öntanımlı olarak bir servisin id’si servisin ismi ile aynıdır.
type
Takip eden tanımlamalardan herhangi bir kombinasyon kullanılabilir.
RPC : Eğer bir RPC servisi ise
INTERNAL : Eğer xinetd tarafından sağlanan bir servis ise
UNLISTED : Eğer standart sistem dosyalarında (rpc olmayan servisler için etc/services
veya rpc olan serisler için /etc/rpc dosyalarında) listelenmemiş bir servis
ise
flags
Bu özniteliğin alabileceği değerler ve kombinasyonları şunlardır,
REUSE : servis soketinde S0 REUSEADDR bayrağını set eder
INTERCEPT : Kabul edilen adreslerden gelip gelmediğini doğrulamak için paketleri
yada kabul edilmiş bağlantıları yakalar.(İçsel-INTERNAL- yada multi-
threaded servisler yakalanamaz)
NORETRY : Unix fork hatası oluştuğu zaman yeniden deneme yapılmamasını sağlar
IDONLY : Bağlantının ancak uzak sistem bağlanan kullanıcıyı tanımlarsa kabul
edilmesini sağlar (Yani uzak sistemde identd sunucusu çalışmalıdır).
Sadece bağlantılı servislerde kullanılabilir. USERID log seçimi
kullanılmadığı zaman etkisizdir.
NAMEINARGS : server_args özniteliğinde tanımlanan ilk argümanın server özniteliğinde
Tanımlanmak istenilen sunucu programı yani argv[0] olmasını sağlar.
Normalde tcpd kullanılmayacak ise kullanmaya gerek yoktur. Bu
durumda server özniteliğinde tcpd server_args da ise ilk argüman esasen
çalıştırılmak istenilen servis sunucu programı olur. Tamamen eski inetd
tanımlamalarına benzer.
NODELAY : Eğer servis bir tcp servisi ise ve bu bayrak etkinleştrilmis ise soket
üzerinde TCP_NODELAY bayrağı etkinleştirilir. Eğer servis tcp servisi
değil ise bir etkisi yoktur.
DISABLE : Bu bayrak servisin devre dışı bırakılıp bırakılmayacağını belirler. Aynı
zamanda öntanım bloğunda tanımlanmış enable özniteliğinin üzerine
yazar.
KEEPALIVE : Servis tcp servisi ise ve bayrak etkinleştirilmiş ise soket üzerinde
SO_KEEPALIVE bayrağı etkinleştirilir. Eğer tcp servisi değilse
Etkisizdir.
NOLIBWRAP : Eğer xinetd tcp_wrapper desteği ile derlenmiş ise, servise erişimi
denetleyen tcp_wrapper kütüphanesinin içsel olarak çağırılmasını
engeller. Bu daha çok uzun sürecek bazı sunucu süreçleri için (örneğin
xinetd) libwrap fonksiyonelliğinin etkin olmasını engellemek için
kullanılır. Ancak istenirse NAMEINARGS özniteliği ve tcpd
kullanılarak açık destek verilebilir.
disable
Bu sadece BOOLEAN (yani “yes” yada “no” ) değerler alır. Servisin devre dışı
bırakılmasına ve hiç başlatılmamasına sebep olur. (Ayrıca bak: flag=DISABLE)
enabled
Servis isimlerinden oluşmuş bir liste için bu servislerin etkin olmasını sağlar. Sadece bu listedeki servisler etkinleştirilir geri kalanlar ise devre dışı bırakılır. “yes” değerini almış disable özniteliği ile (veya flag = DISABLE bayrağı ile) bir servisin bu listede tanımlanarak etkinleştirilmiş bir servisi devre dışı bıraktığına dikkat edilmelidir.
socket type
Bu özniteilik için mümkün olasılıklar ve kombinasyonları şunlar olabilir,
stream : akış-tabanlı servis (stream-based service)
dgram : datagram-tabanlı servis (datagram-based service)
raw : IP’ye direk erişim gerektiren servis
seqpacket : güvenli ardışık datagram iletimi gerektiren servis
protocol
Servis tarafından kullanılan protokolü belirler. Ancak kullanılacak protkol /etc/protocols içinde tanımlanmış olmalıdır. Eğer belirtilmemiş ise servis tarafından varsayılan protokol kullanılır.
wait
Aldığı değer eğer “yes” ise servisin single-threaded, “no” ise multi-threaded olduğunu belirler. single-threaded ise xinetd servisi ilgili daemon ile başlatır ve yenisini başlatmak için eskisini ölene kadar bekler. Multi-threaded ise ölmesini beklemeden yeni servisler açmaya devam eder.
user
Sunucu süreci için uid’nin ne olduğunu belirler. Kullanıcı ismi /etc/passwd dosyasında mutlaka bulunmalıdır. Bu öznitelik eğer xinetd’nin etkin kullanıcısı super-user değilse etkisizdir.
group
Sunucu süreci için gid’nin ne olduğunu belirler. Grup ismi /etc/group dosyasında mutlaka bulunmalıdır. Eğer kullanıcı grubu tanımlanmamış ise kullanıcı grubu /etc/passwd dosyasından alınır. Bu öznitelik eğer xinetd’nin etkin kullanıcı ID’si super-user değilse etkisizdir.
instances
Bir servis için eşzamanlı olarak çalıştırılabilecek maksimum sunucu sayısını belirler.Öntanım olarak bir sınır yoktur. Bu özniteliğe atanabilecek değerler ya sayı yada UNLIMITED tanımlaması olabilir.
nice
Sunucu önceliğini belirtir. Değeri (çoğunlukla negatif) bir sayıdır. Daha fazla bilgi için nice(3) manualına bakılabilir.
server
Servis için çaılştırılacak sunucu programını belirler.
server_args
Server özniteliğinde tanımlanan sunucu programına geçirilecek argümanları belirler.
log_type
Servis günlüğünün nereye gönderileceğini belirler. İki format vardır,
SYSLOG
syslog facility [syslog level]
Günlük çıktısı syslog programına belirli bir facility için gönderilir. Mümkün
facility’ler daemon, auth, authpriv, user, local0-7 dir. Mümkün seviyeler ise
emerg, alert, crit, err, warning, notice, info, debug dır. Eğer seviye belli değilse
info seviyesinde günlük tutulur.
FILE
file [soft_limit [hard_limit]]
Günlük çıktısı bir dosyanın sonuna eklenir eğer dosya yoksa yaratılır. Seçimlik
olarak iki limit dosya büyüklüğü üzerinde tanımlanabilir. İlki, soft limit’tir, limit
ilk kez aşılmış ise xinetd log yazmaya devam eder. İkincisi ise hard limittir, xinetd
bu sınır aşılırsa etkilenen servis için log üertmeyi durdurur. Eğer log dosyası ortak
bir log dosyası ise birden fala servis bundan etkilenebilir. Ancak bunun haber
verecek bir log mesajı üretir ( Eğer xinetd sylog’a log üretirse bu mesaj alert
seviyesinde gönderilir). Eğer hard limit tanımlanmamış ise limit soft limite
ayarlanır ve 1% arttırılır. Ancak maksimum değer LOG_EXTRA_MIN ve
LOG_EXTRA_MAX değerleri arasında kalmalıdır. Bu değerler 5k ile 20k
arasındadır ( Bu değerler config.h’ta yeniden tanımlanabilir).
log_on_success
Bir sunucu çalıştırıldığında ve sunucu varolduğu müddetçe (servis id’si günlük tanımında daima bulunur) ne tür bir bilginin günlüğünün tutulacağını belirler. Takip eden değerlerin herhangi bir kombinasyonu kullanılabilir.
PID : Sunucu süreç id’sinin günlüğünü tutar (Eğer süreç fork mekanizması ile
başka bir süreçten doğmadı ise 0 olacaktır).
HOST : Uzak sistemin adresini tutar.
USERID :RFC 1413 tanımlama protokolünü kullanarak uzak kullanıcının kullanıcı
ID’sini tutar. Ancak sadece multı-threaded stream servisler için mevcuttur.
EXIT : Sonlandırma yada çıkış sinyali sonucunda sunucu servis dışı kalırsa
günlük tutar. Eğer PID tanımlanmış ise çıkış yapan sunucunun PID de
tutulur.
DURATION : Servis oturumunun ne kadar sürdüğünün kaydı saniye cinsinden tutulur.
log_on_faliure
Bir sunucu çalıştırılamadığı zaman ne tür bir günlük tutulacağını belirler ( ister kaynakların azalmasından ister erişim kısıtlamalarından olsun). Servis id’si herzaman hata sebebi ile birlikte daima kaydedilir.
HOST : uzak sistem adresini tutar
USERID : log_on_success ile aynıdır
ATTEMPT : Başarısız bir girişimde bulunduğu belirten bir log tutar. (Aslında tüm
diğerleri tarafından bu is zaten yapılır)
RECORD : Sunucunun başlatılamadığı durumda uzak sistemden bilgi alarak kayıt
yapar. Bu servisi kullanarak girişimleri izlemeye izin verir. Örneğin login
servisi yerel kullanıcıyı,uzak kullanıcıyı ve terminal tipini loglar. Halen,bu
özelliği destekleyen servisler sadece, login, shell, exec, finger dır.
rpc_version
Bir rpc servisi içi RPC sürümünü belirler. Sürüm numarası tek bir sayı yada sayı-sayı formundadır.
rpc_number
Tanımlanmamış yada listlenmemiş (UNLISTED) bir RPC servisinin numarasını belirler. Bu öznitelik eğer servis listelenmemiş değilse ihmal edilir.
Env
Bu özniteliğin değeri “name=value” formunda bir dizi karakterden oluşur. Bu karakter dizileri sunucu başlatılmadan önce çevre değişkeni olarak tanımlanır. Böylece sunucunun çevresi, xinetd’nin çevresi artı tanımlanmış bu karakter dizilerini içerir. “-=” operatörünü desteklemez.
passenv
Bu özniteliğin değeri sunucunun çevre değişkenlerine eklenecek olan ve xinetd’nin çevre değişkenlerinden oluşan bir listedir. Eğer liste boş ise env değişkeni kullanılarak açıkca tanımlananlardan başka sunucunun çevresine geçirilecek başka çevre değişkeni olmadığını gösterir. Ancak env değişkeni ile birlikte kullanıldığında env ile tanımlananların hangisinin geçirileceğinide belirler.
Port
Servisin portunu belirler. Eğer bu öznitelik /etc/services dosyasında bulunan bir servis için tanımlanmış ise değeri bu dosyada tanımlanmış port numarasına eşit olmak zorundadır.
interface
Bind’ın eşanlamlısıdır.
Yapılandırma esnasında her servis için tüm bu öznitelikerin kullanılmasına ihtıyaç yoktur. Bir servis için gerekli olan öznitelikler,
Şekil 18
Şekil 18 de gösterilmiştir. Şekil 19 da ise tüm atama operatörlerini ( “=”, ”-=”, “+=”) destekleyen öznitelikler listelenmiştir.
Şekil 19
Bu öznitelikler bir servis tanım bloğunda birden fazla bulunabilirler. Geri kalan öznitelikler sadece “=” operatörünü desteklerler ve bir servis tanım bloğunda en fazla bir kez görünebilirler. xinetd.conf dosyasındaki öntanım bloğunda kullanılabilecek öznitelikler ise Şekil 20 de listelenmiştir.
Şekil 20
Öznitelikler verilen bir değer ve += operatörü kullanılarak, kümülatif etki ile birden fazla tanımlanabilir. Şekil 20 de görüldüğü gibi disable istisnası dışında tümü sanki servis tanım bloğunda tanımlanmış gibi aynı manaya sahiptirler. disabled yapılandırma dosyasında tanımlamalar olsa bile devre dışı bırakılmış servisleri gösterir.
WEB ÜZERİNDE XINETD KAYNAKLARI
http://www.mandrakeuser.org/docs/#top
http://www.macsecurity.org/resources/xinetd/tutorial.shtml
http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1-tcpwrappers-xinetd.html
http://www.linuxfocus.org/English/November2000/article175.shtml#lfindex1
Bir başka makalede görüşmek üzere..
Tayfun DEGER – Cozumpark