TCP Wrappers Hakkındaki Yanlış Fikirler

Categories: Güvenlik

Güvenlik ile ilgili yazıları ve forumlardaki tartışmaları okuduğumda ve arkadaşlarımla güvenlik üzerine tartıştığımızda hosts.deny/hosts.allow ve TCP Wrappers hakkında bazı yanlış fikirlerin olduğunu gördüm. Bu yazının amacı bu karışıklığı gidermek ve güvenlik bilincinin biraz daha artması. Bu doküman bir ‘how-to’ niteliğinde değildir, daha çok hosts.deny ve ipchains arkasındaki teorinin açıklamasıdır. Yazı Linux 2.2.x e göre yazılmıştır fakat diğer UNIX platformlarınada uyacaktır.

hosts.deny ve hosts.allow Wietse Vewnema`nın, SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK ve diğer ağ servislerini izleyip filtreleyebilmenizi sağlayan TCP Wrappers`ının kontrol ayar dosyalarıdır. Kısa bir giriş bilgisi için aşağıdaki adrese bakabilirsiniz:
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.BLURB

TCP Wrappers yararlı bir araça olabilir ve pek çok güvenlik dokümanı sisteminiz güvenli olacaksa TCP Wrappers`ı kurmanız gerektiğini belirtirler. Bu dokümanların aynı zamanda TCP Wrappers kullanmadan da (inetd yi ve onunla birlikte TCP Wrappers tarafından sarılan diğer servisleri kapatarak) sisteminizi güvenli hale getirebileceğinizi anlattığını farkettim.

TCP Wrappers tarafından ‘sarılan’ daemon`lar inetd tarafından tcpd[1] ile birlikte çalıştırılırlar. Örnek olarak, telnetd, ftpd, talk, finger vb. Bu programların çoğunluğu güvensiz daemon`lardır ve hemen hemen her güvenlik dokümanında inetd.conf da kapatılmaları tavsiye edilir. Çoğu için bu iyi bir tavsiye. Bu servislerin çoğu sistem yöneticisi tarafından kullanılmamakta ve gelecekte olabilecek bir hack saldırısı için potansiyel hedeftirler.

Yeterli bilgisi olan biri inetd.conf dosyasında değişiklik yaptıktan sonra, sadece inetd[2] tarafından çalıştırılan ftp ve telnet`e sahiptir. Fakat aynı zamanda inetd tarafından başlatılmayan web sunucu, mail sunucu veya DNS sunucusu çalıştırıyor olabilirler. Bu durumda TCP Wrappers`ın nasıl çalıştığını anlamak çok önemli, yoksa yanlış bir güvenlik duygusuna sahip olabilirler.

Şu an için libwrap`ı gözardı edecek olursak, tcpd tarafından başlatılmayan servisler TCP Wrappers[1] tarafından korunmazlar. Bu sebeple, eğer politikanız sunucunuza erişimde bloklamak için hosts.deny dosyasına hostları ve ağları eklemek ise, gerçekte onların çoğu servisinize ve genelde sunucunuza erişimini bloklamıyorsunuz demektir. Saldırganlardan korunduğunuza dair yanlış bir güven duygusuna sahip olabilirsiniz. Fakat bu sırada onlar hosts.deny kurallarınızı aşıp geçecek olan en son BIND exploit`i ile uğraşmaktadırlar ve sizin bundan haberiniz bile olmaz. Bunun nasıl çalıştığına bir bakalım:

İşte standart RedHat 6.1 kurulumunda in.telnetd`nin varsayılan ayarı:
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

Bir host bu sistemdeki telnet sunucuya bağlanmak istediğinde aşağıdakiler gerçekleşir (fazla detaya inilmeden):
1. inetd sistemde port 23`e bir bağlantı algılar. /etc/services deki bilgiye göre bunun telnet port`u olduğunu anlar ve sunucuyu çalıştırmaya kalkışır.
2. /usr/sbin/tcpd inetd tarafından çağrılır, tcpd in.telnetd yi çalıştırmak için gelen bağlantıyı hosts.deny ve hosts.allow dosyalarına göre kontrol eder. /usr/sbin/tcpd sarıcıdır (wrapper).
3. Eğer hosts.deny/hosts.allow bağlantıya izin veriyorsa, in.telnetd çalıştırılır. Aksi takdirde bağlantı reddedilir ve syslogd ile log`lanır.

BIND durumunda, ki genelde inetd tarafından çalıştırılmaz, bağlantı inetd tarafından yakalanmaz, tcpd`ye geçirilmez ve hosts.deny`a asla danışılmaz. Ayrıca bir servisi basitçe inetd ile çalıştırmak onun TCP Wrappers tarafından korunduğunu göstermez, o daemon için dizayn edilmiş belirli bir wrapper olmalıdır.

Eğer gelen trafiği bloklamada sadece hosts.deny kullanıyorsanız kendinizi korumuyorsunuz!

Linux sisteminizin bir adresten bilgi kabul etmesini bloklamak için, yada bazı diğer kurallara uymada (hedef veya kaynak port gibi) ya ipchains kullanmalı yada trafik makinenize ulaşmadan önce bir güvenlik duvarında yada router`da bloklamalısınız. Çoğu ev kullanıcısı için ipchains tek gerçek çözümdür.

Ipchains trafiği, inetd veya tcpd tarafından işlenmeden önce kernel seviyesinde bloklar (işte bu yüzden ipchains tarafından bloklanan bir paket varsa loglayıcıya mesajı gönderen kernel olacaktır).

ipchains ayarları hosts.deny`dan çok daha karışıktır ve kurallar bir dosya yerine hafızada tutulduğundan her reboot edildiğinde tekrar başlatılır. Fakat başlangıçta çalıştırılacak bir ipchains kural seti hazırlamak çok kolaydır (ör. geleneksel rc.firewall) ve bu ek çalışma eklenen güvenliğe[3] değer. Alternatif olarak portsentry gibi güvenlik yazılımları beklenmeyen bağlantı denemelerinde ipchains`e otomatik kurallar ekleyecek çekilde ayarlanabilir.

Peki tüm daemonları niye inetd`den çalıştırmayalım? Bu mümkün fakat sitenizde yoğun bir trafik akışı varsa aşırı yük sisteminizin kaldırabileceğinden fazla olabilir. inetd her gelen bağlantıyı yakalayacak ve yeni bir sunucu daemon[4] çalıştıracaktır. Başlangıç işlemleri işlemci zamanı ve hafıza gerektirir, inetd gelen bağlantıyı tanıyacak, tcpd`ye gönderecek, tcpd hosts.allow ve hosts.deny dosyalarını kontrol edecek ve daemon`u çalıştıracak. Bu pek iyi bir seçenek değil ve pek çok durumda da mümkün değil.

Ek olarak inetd`nin potansiyel olarak exploit edilmesi söz konusu. Son günlerde inetd yi direk olarak etkileyen bir güvenlik açığından haber değilim fakat root olarak çalışıyor ve gelecekteki potansiyel exploit`ler için bir hedef. Örneğin inetd Linux kernel 2.2.15`i etkileyen, programların kendi efektif UID lerini değiştiremediği güvenlik açığından etkilenebilirdi. Bu sadece benim bir varsayımım fakat kayda değer bir sebep.

Notlar:
[1] Bazı daemon`lar libwrap`ın dahil edilmesiyle tcp_wrappers ile çalışabilirler. Bu durumda hosts.deny kontrolü için programın inetd ile çalıştırılması gerekmez. libwrap`ten bu yazıda bahsedilmemesinin iki sebebi var: ilki, libwrap bu yazının olması gerektiğinden daha fazla gelişmiş bir konu. ikincisi, yazıyı hazırlanken bilgimin az olması bu konuda eğitici bir yazı yazmamı engelliyor.
[2] SSH telnet`in yerine güvenli olarak kullanılabilir. SFTP ve SCP, FTP yerine kullanılabilir. SSH ve SCP için PuTTY ve WinSCP gibi ücretsiz windows yazılımları dahi mevcut.
[3] RedHat 6.2 sürümünde ipchains ile System V init stilinde kullanabileceğiniz, o anki kuralları kaydedebilme seçeneği de olan bir shell script sundu. Bu ipchains kullanımında pek çok işi hafifletiyor fakat yinede kendi özel ipchains kural setinizi yaratmalısınız.
[4] Bu başlangıç yüküne örnek olarak ssh daemon`u düşünün. sshd her başladığında yeni bir host key yaratır ki buda çok işlemci gücü harcar. Eğer sunucu her gelen bağlantı için yeni bir host key yaratmaya zorlanırsa host key hazır olmadan bağlantı muhtemelen zaman aşımına uğrayacaktır.