Linux

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. 1. servers   : sunucuların kullanımda olduğunu bildirir
  2. 2. services :  kullanıma açık, mevcut servislerin adını,protkollerini ve portunu bildirir
  3. 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:

  1. Bu servislere bağlanabilen sadece xinetd çalıştıran makina olmalıdır.
  2. 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. 1. help
  2. 2. show run        :  servers servisi gibi o an çalışmakta olan sunucuların listesini verir
  3. 3. show avail      :  services servisi gibi o an çalışmakta olan servislerin listesini verir.
  4. 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,

  1. xinetd isteğe izin vermiştir
  2. finger isteği xinetd tarafından tcpd ‘ye iletilmiştir
  3. 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,

  1. 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)
  2. 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.xinetd.org/

http://synack.net/xinetd/

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.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1-tcpwrappers-additional-resources.html

http://www.linuxfocus.org/English/November2000/article175.shtml#lfindex1

Bir başka makalede görüşmek üzere..

Tayfun DEGERCozumpark

0 0 votes
Makaleyi Oylamayı Unutmayın !

Tayfun DEĞER

Bu yazı blog üzerinde Tayfun DEĞER tarafından paylaşılmıştır. 2009 yılında açılan blog kısa zaman içerisinde büyük bir izleyici kitlesine sahip olmuştur. Tayfun DEĞER danışmanlık ve eğitimler vermektedir. vExpert 2013-2019, VCP4/5/6, VCP5-DT, VCP-Cloud ve MCSE sertifikalarına sahiptir.Twitter 'dan @tayfundeger veya RSS ile sitedeki değişiklikleri takip edebilirsiniz.

İlgili Makaleler

Subscribe
Bildir
guest

0 Yorum
Inline Feedbacks
View all comments
Başa dön tuşu
0
Görüşlerini belirtmek ister misin?x