Merhaba
XINETD DAEMON (the extended Internet services daemon)
xinetd – eXtended InterNET services daemon, ağ üzerinden sisteme gelebilecek zorla sisteme girme ve Denial of Services (DoS) saldırıları riskine karşı erişim kontrolü ile oldukça iyi bir güvenlik sağlayan bir yapıdır. İyi bilinen bir ikili olan tcpd ve inetd gibi, bir makine için erişim haklarının yapılandırılmasını mümkün kılarken daha fazlasınıda yapar. Bu dökümanda artık inetd’nin yerini alan xinetd’nin bu özelliklerinin çoğu incelenecektir.
1.1 XINETD SUNUCUSUNUN GÖREVLERİ
Klasik inetd, bir bilgisayara yapılan ağ bağlantılarının kontrol altında tutlmasına yardımcı olur. inetd tarafından yönetilen bir port’a bir istek geldiği zaman, inetd isteği tcpd adı verilen programa iletir. tcpd, /etc/hosts.allow ve /etc/hosts.deny dosyalarında tanımlanmış olan kurallara göre isteği kabul edip etmeyeceğine karar verir. Eğer istek kabul edilirse kaşılık gelen sunucu yordamı (procedure) çalıştırılabilir. Bu mekanizma aynı zamanda tcp_wrapper olarak da bilinir.
xinetd, tcp_wrapper’ın desteğine benzeyen bir erişim kontrol kabiliyeti sağlar. Ancak yetenekleri bununla sınırlı değildir,
- TCP, UDP, RPC servisleri için erişim kontrolü (RPC henüz iyi desteklenemiyor)
- Zaman dilimlerine dayalı erişim kontrolü
- Başarılı yada başarısız bağlantı için tam günlük tutma (Full Logging)
- DOS ataklarına karşı etkin koruma (DOS atağı-bir bilgisayarın kaynaklarını iyice doldurarak, işgal ederek makinanın donmasına sebep veren saldırı girişimi)
- Aynı anda, aynı servis için çalıştırılabilecek sunucu sayısına kısıtlama getirebilme
- Tüm servisler için calıştırlabilecek maksimum sunucu sayısını kısıtlama
- Günlük dosyalarının büyüklüklerine sınırlama koyabilme
- Bir servisi belirli bir arayüze ilişkilendirebilme veya bağlayabilme (Örneğin, belli bir servisin sadece iç ağa yönlendirilmesi dış ağlara kapatılmasını sağlamaya yarar)
- Ağ üzerindeki diğer sistemler için PROXY olarak kullanılabilir (İç ağa ulaşmak için ip_masquerading (veya NAT) ile birlikte oldukça iyi ve fayalı bir kombinasyon oluşturabilir.
xinetd için tek eksiklik yukarıdada bahsedildiği gibi RPC üzerinde zayıf bir desteğin olmasıdır. Ancak portmap’in bu problem için xinetd ile birlikte varolması soruna şimdilik çözüm getirmektedir.
xinetd, internet servislerini sağlayan programları çalıştırarak inetd ile aynı işlerliği yerine getirir. Servis sunucularını sistem başlangıç zamanında çalıştırmak yerine veya bir bağlantı isteği gelene kadar uyuyan daemonları sürekli çalıştırmak yerine xinetd çalıştırıldığında yapılandırma dosyasında listelenen servisler için tüm servis portlarını dinler ve bir istek geldiği zaman xinetd uygun sunucuyu çalıştırır. Bu çalışma tarzı yüzünden xinetd (inetd içinde aynı tanımlama mevcuttur) Super-Server olarak adlandırılır.
xinetd yapılandırma dosyasındaki listelenen servisler iki kategoriye ayrılırlar. İlk gruptaki servisler multi-threaded olarak adlandırılırlar ve her yeni bağlantı isteği için yeni bir sunucu yordamının çatallaşmasına (UNIX Fork – yani child process oluşturma) ihtiyaç duyarlar. Yeni sunucu o bağlantıyı ele alır. Bu tür servisler için, xinetd yeni istekler için portları dinlemeye devam eder ve böylece yeni sunucular (child processler) çalıştırabilir. Diğer yandan ikinci grup, tüm yeni bağlantı isteklerini ele almakla yükümlü servis daemonlarını içerir. Bu tür servislere single-threaded servisler ası verilir. xinetd single-threaded servisler için yeni gelecek olan istekleri ele almak için daha önceki istek için çalıştırılmış bulunan servis daemon’ının ölmesini bekler. Bu gruptaki servisler genellikle datagram tabanlı servislerdir.
Şu ana kadar, super-server’ın kullanılmasının tek sebebi, çalışma sürelerinin çoğunu uyuyarak geçiren bir çok süreçin çatallaşmasını (fork) önleyerek sistem kaynaklarını korumaktan ibaret idi. Bu fonksiyonun yerine getirirken, xinetd erişim kontrolü ve günlük tutma özellikleri sağlamak için super-server mantığının avantajlarını kullanır. Daha ileri olarak xinetd /etc/services dosyasında belirtilen servisler ile sınırlı değildir. Bu yüzden isteyen herhangi biri özel amaçlı bir sunucu programını xinetd kullanarak başlatabilir.
1.2 XINETD KURULUMU
Bu döküman boyunca 2.1.8.9pre14 sürümü kullanılacaktır. xinetd, kurulum için gelen yazılımlar dağıtım CD lerinden rpm paketleri halinde,
RedHat 7.1 DISK 1 için /Red Hat/RPMS/xinetd-2.1.8.9pre14-6.i386.rpm
Red Hat 7.2 DISK 2 için /RedHat/RPMS/xinetd-2.3.3-1.i386.rpm
veya www.xinetd.org web adresinden mevcut sistemlere indirilebilir.
http://www.xinetd.org/pub/xinetd/xinetd-2.1.8.9pre14.tar.gz
http://www.xinetd.org/pub/xinetd/xinetd-2.3.3.tar.gz
tar.gz formatındaki paketler halinde dosya sisteminde uygun bir yere kaydedilir ve arşiv burada açılır. Derleme ve sisteme kurma alışılagelmiş yollarla yapılabilir yani #./configure; make; make install herşeyi gerçekleştirir. Ancak derleme zamanında kullanılabilecek bazı özel seçimler yada anahtarlar vardır. Bunlardan üç tanesi incelemeye değerdir,
- –with-libwrap ; bu opsiyon ile xinetd’nin tcpd yapılandırma dosyalarını kendisinin kontrol etmesi sağlanır. { /etc/hosts.allow, /etc/hosts.deny }. Eğer erişim kabul edilirse, kendi kontrol rutinlerini kullanır. Bu aslında tcp_wrapper ile ne yapılabiliyorsa aynısının xinetd ile yapılabileceğini gösterir. Ancak bu uyumluluğun kullanılması yapılandırma dosyalarının sayısının çoğaltacağı ve yönetimlerinide zorlaştıracağı unutmamak gerekir.
- –with-loadavg ; bu anahtar ile derleme sonucu, xinetd’nin max_load yapılandırma seçeneğini kullanmasına izin verir. Bu bazı servislerin, makinanın aşırı yüklenmesi durumunda devre dışı bırakılmasını sağlar. Bu seçenek DOS ataklarını engellemek için gereklidir. (Tablo 1 deki öznitelikleri kontrol edilebilir)
- –with-inet6 ; Eğer IPv6 kullanılacak ise, bu seçenek buna izin verir. IPv4 ve IPv6 adresleri desteklenir ancak IPv4 adresleri IPv6 formatına dönüştürülür.
RPM formatındaki paketler ise #rpm –ivh komutu ile sisteme kurulabilir. xinetd’nin bir özelliğide, xinetd başlatılırken inetd’nin durdurulması gerekmez. Yine de her ikisinin aynı anda çalışması önceden tahmin edilemeyen sorunlar çıkartabilir. Bazı sistem sinyalleri kullanılması xinetd’nin çalışmasını etkileyebilir bunlardan bazıları,
- SIGUSR1 : Yazılım Yeniden Yapılandırma ; yapılandırma dosyası yeniden okunur ve buna göre servis parametreleri değiştirilir.
- SIGUSR2 : Donanım Yeniden Yapılandırma; SIGUSR1 gibi ancak daha ileri gidilerek zamanı dolmuş program sunucuları (DAEMONS) öldürülür.
- SIGTERM : xinetd’yi ve yarattığı daemonları sonlandırır.
Bunların haricinde SIGHUP gibi başka sinyallerde vardır. Ancak bu üç tanesi içinde start, stop, restart, soft, hard (son ikisi sırayla SIGUSR1 ve SIGUSR2’ye karşılık gelir) seçeneklerini içeren basit bir kabuk scripti yazılarak kontrol amacıyla kullanılabilir. Adı geçene benzer bir script, aslında kurulum esnasında servis scriptlerinin bulunduğu dizine kopyalanır.
/etc/rc.d/init.d/xinet {start|stop|status|restart|condrestart|reload}
UYARI: SIGHUP sinyali, cıktısını man dosyalarında belirtildiği gibi /tmp/xinetd.dump dosyasına değil /var/run/xinetd.dump dosyasına yazar.
1.3 YAPILANDIRMA
/etc/xinetd.conf dosyası, xinetd için varsayılan yapılandırma dosyasıdır. Ancak bir komut satırı anahtarı kullanılarak farklı bir yapılandırma dosyasıda kullanılabilir. xinetd yapılandırması çok karmaşı bir yapıya sahip değildir. Ancak yapılandırma inetd’den daha uzun sürebilir ve maalesef sentaksı oldukça farklıdır. Bununla beraber eski /etc/inetd yapılandırma dosyasını xinetd yapılandırma dosyasına dönüştürebilen itox ve xconv.pl adında iki yardımcı program bulunmaktadır. Açıkcası wrapper yapılandırılmasında tanımlanan kurallar ihmal edildiği için bu iki program yeterli değildir. Itox programı artık geliştirilmemektedir ve en iyi çözüm xconv.pl perl programını kullanmaktır. Fakat, xinetd inetd’den daha üstün ve farklı özelliklere sahip olduğu için yinede elden geçirilmelidir.
# /usr/local/sbin/xconv.pl < /etc/inetd.conf > /etc/xinetd.conf
Ancak bu scriptler inetd.conf dosyasından xinetd.conf dosyasını tüm servis tanımlama bloklarınıda içinde bulunduracak şekilde oluşturur. Fakat xinetd ‘nin rpm paketlerinden yada sistemin baştan kurulumu esnasında bazı içsel veya içsel olmayan yapılandırmalar /etc/xinetd.d dizini altında herbir servis tanımlaması ayrı bir dosyada bulunacak ve kullanıma hazır bir şekilde oluşturulur. /etc/xinetd.conf dosyasında ise sadece öntanım bloğu bulunur ve dosya sonunda includedir deklerasyonu kullanılarak servis tanımlamalarının bulunduğu /etc/xinetd.d dizini yapılandırmaya dahil edilmiş olur (Şekil 1). Yapılandırma dosyası bir varsayılanlar bölümü ile başlar. Bu bölümdeki öznitelikler (attributes), xinetd nin yönettiği tüm servisler tarafından kullanılır. Daha sonra tüm servislerin sıralandığı servislere ait bölüm başlar. Herbiri içinde o servise özgü tanımlamalar yapılabileceği gibi varsayılan bölümde yapılan öntanımlı öznitelikler bu bölümlerde yeniden tanımlanabilirler (Tablo 1).
defaults
{
attribute operator value(s)
…
}
includedir /etc/xinetd.d
Genel olarak bir öntanım bölgesinde yapılan tanımlamalar bu formdadır. Bu bölümde tanımlanan her özniteliğin değeri, daha sonra tanımlanacak tüm servisler için kullanılmak üzere saklanır (Detaylı bilgi için ÖZNİTELİKLER ve DEĞERLERİ Bölümüne bakınız)
only_from = 192.168.1.0/24 192.168.5.0/24 192.168.10.17
Örneğin only_from özniteliği, sunucuya bağlanabilecek olan bazı yetkili adreslerin bir listesini tanımlamaya izin verir ve tüm xinetd ile çalışacak olan sunucu tanım blokları için geçerli bir ön tanımlamadır.
Öntanımlı bölümde yapılan tanımlamalara bir örnek Şekil 1 de gösterilmiştir. Bu bölümden sonra yapılacak olan her servis tanımlaması için listedeki bu adresler geçerli olmakla beraber, bu öntanımlı değerler servis tanım blokları içinde modifiye edilebilirler. Bununla beraber bu yaklaşım biraz risklidir. Gerçekte, bir takım şeyleri güvenli ve basit tutmak için varsayılan tanımlamalar yapmamak ve daha sonra bunları servisler içinde değiştirmemek çok daha iyidir. Örneğin erişim kurallarından bahsederken, en basit strateji herkese erişimi yasaklamak ve daha sonra greçekten ihtiyacı olanlara bu servisten faydalanmaları için izin vermektir. (Bu işlem TCP_WRAPPER ile /etc/hosts.deny dosyasında ALL:ALL@ALL yazmak ve /etc/hosts.allow dosyasında yetkili servisleri ve bu servisi kullanacak adresleri aynı satırda belirtmekten ibarettir.)
Yapılandırma dosyasındaki bir servisi tanımlayan bir bölüm Şekil 2 deki formdadır. Üç çeşit operatör mevcuttur ve bunlar “=” , “+=” , “-=” operatörleridir. Ancak bir çok öznitelik sadece “=” operatörünü kullanır
- = operatörü özniteliğe sabit, değişmeyen bir değer atamak için,
- += operatörü bir değerler kümesine yenisi eklemek,
- -= operatörü bir değerler kümesinden bir değer çıkarmak için kullanılır.
Tablo 1 özniteliklerin bazılarını kısaca açıklamaktadır. xinetd.conf man dosyasından daha detaylı bilgi edinilebilir. Tabloda listelenen son dört öznitelik belirli bir sunucu üzerindeki kaynakların kontrolüne izin verir. Bu öznitelikler kullanımı DoS ataklarını engellemede oldukça etkilidir. Takip eden bölümlerde xinetd’nin nasıl yapılandırıldığı ve etkili çalışmasını sağlamak için bazı kuralların nasıl tanımlandığı anlatılacaktır.
1.3.1Erişim Kontrolü
Önceden de bahsedildiği gibi, IP adreslerini kullanarak Linux box’a erişim onaylanabilir (yada yasaklanabilir). Bununla birlikte xinetd çok daha fazla özellik sunar.
- İsim çözümleme ile erişim kontrolü yapılabilir. only_from özniteliğine eğer uzak sistemler için hostname yazılırsa, xinetd ilk önce kendisinden istekte bulunan hostun IP adresinden ismini çözümler, elde edilen host ismi tanımlanan ismi karşılaştırır. Bunu aynı hosttan gelecek her bağlantı isteği için yeniden gerçekleştirir.
- .domain.com ile erişim kontrolü gerçekleştirir. only_from özniteliğine domain.com gibi tanımlamalar girilebilir. Bir istemci bağlandığı zaman xinetd bağlanan IP için ters kayıt çözümlemesi gerçekleştirir ve elde edilen domain ismi tanımlanmışmı diye kontrol eder.
Erişim kontrolünden tam anlamıyla yararlanmak için (optimization) IP adresleri açıkça daha faydalıdır. Bu yolla hostname çözümlemelerinden kaçınılmış olunur. Eğer bu bir zorunluluk ise o zaman en azından aynı yerel sistemde bir sadece-önbellekli-alanadı-sunucusu (caching only name server) çalıştırılması hızı arttırarak işleri oldukça kolaylaştıracaktır.
Tablo 1 (Devam)
1.3.2Servis Öntanımları
Öntanım bölümü bir grup öznitelik için değer tanımlamaya izin verir. Bu özniteliklerden bazıları (only_from, no_access, log_on_success, log_on_faliure,….) bu bölümde yeralan bazı değerler ile servisler bölümünde atanan değerleri eşzamanlı olarak ele alır. Bir makineye erişimin öntanımlı olarak yasaklanması iyi bir güvenlik politikasının ilk adımıdır. İkinci olarak erişim izni servis bazında yapılandırılmalıdır. Daha önce bir makinaya erişimi IP adresi bazında kontrol eden iki öznitelikten bahsedilmişti. Bunlar only_from ve no_access du. İkincisi,
no_access = 0.0.0.0/0
şeklinde kullanılır ise servise erişim tamamen bloke edilmiş olur. Bununla beraber, herkes için echo (ping) servisine erişerek bu makinenin canlı olduğunun anlaşılmasına izin verilecek ise echo servisinin tanımlama bloğu içinde
only_from = 0.0.0.0/0
yazılması gerekir. Bu yapılandırma ile alınacak olan /var/log/messages dosyasındaki günlük kaydı (log mesajı),
Şekil 3 de görüldüğü gibi olacaktır. Belirli bir biçimde erişm kontrolü IP adreslerinin, her iki özniteliğin içerdiği adres listelerinin karşılaştırılması ile gerçekleştirilir. Eğer istemci her iki liste ile uyuşuyor ise en az genel olan seçilir. Örnekte gibi bir eşitlik durumunda ise xinetd seçim yapamaz ve istek reddedilir. Bu karmaşıklıktan kurtulmak için
only_from = 192.0.0.0/8
yazmak yeterlidir. Erişim kontrolüne daha kolay bir çözüm sadece,
only_from =
özniteliğini kullanmak olacaktır. Arkasından her servis için kendi bloğunda aynı öznitelik yeniden kullanılarak erişim hakkı tanınabilir. Tipik bir öntanım bloğu Şekil 4 de gösterilmiştir.
UYARI: Ancak hiçbir değer vermemek tüm erişimlerin bloke olmasına sebep olacaktır.
Bir başka makalede görüşmek üzere..
Tayfun DEĞER
