certificate etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
certificate etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

24 Haziran 2013 Pazartesi

Exchange Server: Sertifikalar && S/MIME

Exchange Server: Sertifikalar && S/MIME

Sertifikalar
Mail iletişimini daha güvenilir hale getirmek için sertifikalar kullanılabilmektedir. Exchange Server 2000 ve 2003 ortamlarında sertifika kullanımı yaygın olmamakla birlikte IIS üzerinde manuel olarak gerçekleştiriliyordu. Exchenge Server 2007 ile birlikte bu işlemler Exchange Management Console ve Exchange Management Shell üzerinde daha basit adımlar ile gerçeklenmeye başlamıştır.

Exchange Server 2010 üzerinde sertifika 5 servis için oluşturulabilmektedir. Bu servisler şunlardır:
  • IMAP
  • POP
  • SMTP
  • IIS (HTTP)
  • UM (Unified Messaging)

Bu trafikler ve kullanan bileşenler şu şekildedir:
  • SMTP: HTS ve ETS arasında veya ortak organizasyonlar arasındaki SMTP trafiğinde kimlik doğrulama ve şifreleme sağlamak için kullanılır.
  • EdgeSync Senkronizasyonu: HTS ve ETS arasındaki LSAP iletişimini şifrelemede kullanılır.
  • UM: UMS rolündeki sunucudan HTS rolündeki sunucuya, IP giriş kapılarına (gateway) ve Ofis İletişim Sunucuları’na (Office Communication Servers) giden SMTP trafiğini şifrelemek için kullanılır.
  • Autodiscover: CAS ve istemci arasındaki HTTPS trafiğini şifrelemek için kullanılır.
  • POP3/IMAP4: Posta alınması sürecinde şifreleme ve kimlik doğrulama için kullanılır.
  • Outlook Anywhere: CAS rolündeki sunucudan istemciye giden trafik güvenliğini sağlamak için kullanılır.
  • OWA: CAS rolündeki sunucudan istemciye giden HTTP trafiğinin güvenliğini sağlamak için kullanılır.
  • ActiveSycn: CAS rolündeki sunucudan istemciye giden HTTP trafiğinin güvenliğini sağlamak için kullanılır.

Kullanılan sertifika güvenilir bir sertifika otoritesi tarafından onaylanmış olabileceği gibi, kendimiz de bir sertifika oluşturabiliriz. Kendimizin onaylayacağı sertifikada bir uyarı mesajının çıkabileceği, bu uyarı mesajını almamak için istemcilere onaylayıcının sertifikasının yüklenmesi gerektiği unutulmamalıdır. İç sistemlerde kendimizin imzaladığı, dış sistemlerde ise bir CA tarafından imzalanan sertifikaların kullanılması önerilmektedir.
Kendimizin onayladığı sertifikaları kullanabileceğimiz sistemler şu şekildedir:
  • Hub Transport sunucuları arasına
  • HTS ve ETS arasında
  • EdgeSync trafiği için
  • UM trafiği için
  • Dahili CAS rolü sunucularında

CA tarafından onaylanan sertifikaları kullanabileceğimiz sistemler şu şekildedir:
  • POP3 & IMAP4 trafiği için
  • OWA için
  • Outlook Anywhere
  • ActiveSync için
  • Autodiscover için


Ek Bilgiler:
  • Exchange Server 2010 kurulumu sırasında varsayılan olarak SMTP sertifikası da oluşturulmuş durumdadır. Ama diğer iletişim protokolleri için sertifikalar, Exchange ortamı yöneticisi tarafından oluşturulmalıdır.
  • Exchange Server 2013 kurulumu sırasında MBS üzerinde kendinden imzalı sertifika yüklü olarak gelmektedir. CAS, MBS üzerindeki sertifikaya güvendiği için kullanıcılar herhangi bir sertifika uyarısı almamaktadır.
  • Sertifika oluşturulması için bakınız: http://www.cozumpark.com/blogs/exchangeserver/archive/2009/11/22/exchange-2010-sertifika-olu-turma.aspx


Secure/Multipurpose Internet Mail Extensions (S/MIME)
Sayısal imzalama gönderici taraflı kimlik doğrulama, bütünlük ve reddedilemezlik kazandırmak için kullanılan bir çözümdür. Sayısal imza ile, SMTP protokolünde olduğu gibi, posta açık olarak gönderilir. Base64 kodlama gerçekleştirilse bile şifreleme yapılmadığı sürece posta bir başkası tarafından okunabilir. Asimetrik şifreleme ile ise gizlilik, bütünlük ve alıcı taraflı kimlik doğrulama gerçekleştirilmektedir. Posta iletişiminde sayısal imzalama ve şifreleme kullanılması ile güvenlik arttırılması sağlanabilir. Bu amaçla posta içeriğine bir takım eklentiler konulmalıdır. MIME(Multipurpose Internet Mail Extensions) gönderilecek olan postaya resim, ses, görüntü gibi eklentileri eklemek için kullanılan bir internet standardıdır. Bu standarda bahsedilen güvenlik eklentilerinin eklenmesiyle yeni bir standart oluşturulmuştur. Bu standart S/MIME olarak adlandırılmaktadır. S/MIME temelinde asimetrik şifreleme ve sayısal imzalama yatmaktadır. S/MIME ile posta gönderilirken, önce göndericinin özel anahtarı ile imzalanır, sonra da alıcının genel anahtarı ile şifreleme gerçekleştirilir. Bu postayı alınırken, önce alıcının özel anahtarı ile şifre çözülür, sonra da göndericinin genel anahtarı ile doğrulama gerçekleşir. Böylece iki taraflı kimlik doğrulama, gizlilik, bütünlük ve reddedilemezlik sağlanır. Kullanılan sertifikalar etki alanını yöneticisi tarafından imzalanabildiği gibi, uluslar arası sertifika makamları tarafından da imzalanabilmektedir.

Ek Bilgiler:
  • Bu şekilde iletişim için posta istemcisinin S/MIME desteğinin olması gerekmektedir. Örneğin, OWA’da, S/MIME ActiveX kontrolü kullanılarak sağlanır. Bu sebeple ActiveX desteği olan bir istemci tercih edilmeli ve ActiveX özelliği açılmalıdır.
  • S/MIME desteği ilk olarak Exchange Server 2003 ile birlikte Outlook Web Access için yayınlanmıştı. Günümüzde bu destek gelişerek sürdürülmektedir. S/MIME v3 ile üç sarmallı bir iletişim (Triple-Wrapped Messages) sağlanmaktadır. Bu yapı ile önce imzalama, sonra şifreleme, sonra yine imzalama işlemi gerçekleştirilmektedir.
  • S/MIME ile gerçekleşen operasyonlar ile güvenlik sağlandığı gibi, bu operasyonlar istemci tarafında gerçekleştiği için posta sunucusu için herhangi bir işlem maliyeti yoktur. Diğer taraftan, kullanıcıların özel anahtarları etki alanı sunucusunda tutulmadığı durumlarda, sunucu tarafında yöneticilere kontrol eksikliği oluşabilmektedir. Posta sunucusundaki imzalanmış ve şifrelenmiş posta okunamadığı için taşıma kuralları uygulanamaz, Anti-virüs/Anti-spam gibi çözümlerle zararlı tespiti gerçekleştirilemez, veri kaçağı anlaşılamaz. Bu durum da kontrol eksikliğine sebep olabilmekte ve yasal düzenlemelere karşı bulguya sebep olabilmektedir.

Kaynak site:
http://technet.microsoft.com/en-us/library/aa995740(v=exchg.65).aspx

7 Nisan 2013 Pazar

AD-CS: Temel Güvenlik Önlemleri



Aktif Dizin Sertifika Servisi: Temel Güvenlik Önlemleri
Bir organizasyonda Aktif Dizin Sertifika Servisi için tavsiye edilen temel güvenlik önlemleri şu şekildedir:

  • Kök ve Ara Sertifika Otoriteleri, sadece kendisinin altındaki otoritelere sertifika dağıtımı yaparken açık olmalı, diğer zamanlarda çevrimdışı çalışmalıdır. Bu otoriteler, direk olarak son kullanıcı sertifikalarının yayımlanması ile ilgilenmemelidir. Çevrimdışı tutulan bu Sertifika Otoriteleri Hyper-V ile sanallaştırılmalıdır. Fiziksel olarak korumak daha kolay ise, sanallaştırma yerine fiziksel sunucular kullanılmalıdır.
  • Kök veya Ara Sertifika Otoriteleri’nden sertifika taşınması için USB veya floppy disk kullanılmalıdır, ağ bağlantısının kurulmasından kaçınılmalıdır.
  • Donanım güvenlik modülü (Hardware Security Module - HSM) ile bir sertifika yetkilisinin (CA) ve ortak anahtar altyapısının (PKI) güvenliği arttırılır. HSM, işletim sisteminden ayrı olarak yönetilen, tahsis edilmiş bir donanım aygıtıdır. Bu modüller ile hem imzalama ve şifreleme işlemleri hızlanır, hem de SO anahtarları için de güvenli bir donanım depo sağlanır. 
  • SYSKEY.exe aracı kullanılarak anahtarlar depolanmalıdır.
  • Sertifika otoritesi ile olan iletişim şifreli olmalıdır. Özellikle Web tabanlı sertifika kaydı için SSL üzerinden iletişim gerçekleştirilmelidir.
  • Kritik sertifika verme işlemlerinin otomatik olarak onaylanılmasından kaçınılmalıdır. Bir yönetici tarafından onaylanması ve onaylanmadan önce farklı yollarla (mail/telefon vs) bu talebin onaylanması gerekmektedir.
  • CA sunucusunda oturum açılma işlemlerinde sıkı güvenlik politikaları uygulanmalıdır. Kimlik doğrulama işleminin akıllı kartlar ile gerçekleştirilmesine özen gösterilmelidir.
  • CA tarafından verilen sertifikanın kullanım amacı belirtilmeli ve sadece bu amaç için kullanılabilmesi sağlanmalıdır. Posta yollamak için verilen sertifika, doküman imzalamak için kullanılmayacaksa, imzalama yetkisine sahip olmamalıdır.
  • Grup ilkeleri ile sertifika yönetimi sağlanmaya çalışılmalıdır. Manuel operasyonlardan kaçınılmalıdır.
  • Kullanıcılar Kök Sertifikalarını kendileri güncelleyememeleri sağlanmalıdır. Böylece zararlı bir sertifika otoritesine ait sertifika depolanmamış olur.
  • Güven yapısının olduğu sistemlerde PKI yapısına dikkat edilmelidir. Güven duyulan tarafa sertifika üretme yetkisi verilecekse, bu süre kısa tutulmalı ve verilen sertifikalar kontrol edilmelidir.
  • Etki alanındaki kimlik doğrulamış grupların (Authenticated Users), organizasyondaki Sertifika Otoriteleri üzerinde hiçbir hakkı olmamalıdır. Sertifika isteyebilecek grupların (bilgisayar veya kullanıcı) ise, sadece sertifika talep etme (Request Certificates) haklarının olması gerekmektedir.
  • Her bir Sertifika Otoritesi’nde yerel bir grup oluşturulmalı ve bu gruba CA’yı yönetmesi için gerekli haklar verilmelidir.
  • İstemcilerde ve CA’larda gizli anahtarların bulunduğu dizinler özel olarak korunmalıdır. Bu dizinler şu şekildedir:
    • Windows Vista/2008/7 istemcilerde, %APPDATA%\Microsoft\Crypto\Keys
    • Windows 2003/XP istemcilerde, %APPDATA%\Microsoft\Crypto
    • Windows Server 2003 CA’da, %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto
    • Windows Server 2008 / 2008 R2 CA’da, %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto, %WINDIR%\ServiceProfiles
  • Bir Sertifika Otoritesi üzerinde gerçekleşen olaylar için denetimler uygun şekilde yapılandırılmalıdır. Ayrıntılı bilgi için: http://technet.microsoft.com/tr-tr/library/cc772451.aspx
  • Bir Sertifika otoritesinde kritik bir olay meydana geldiğinde bu olay anlık olarak ilgili yöneticiye bildirilmelidir. Ayrıntılı bilgi için: http://technet.microsoft.com/en-us/library/cc731934.aspx
  • PKI ortamının yönetimi için rol tabanlı bir yönetim uygulanabilmektedir. Kullanıcı ve grupların yapabilecekleri operasyonlar sahip oldukları rollere göre gerçekleştirilmelidir. AD-CS üzerindeki rol tabanlı yönetim kuralları için bakınız: http://technet.microsoft.com/tr-tr/library/cc732590(v=ws.10).aspx
  • Veritabanı ve loglar ayrı disklerde tutulmalıdır.
  • Sertifika otoritesine ait veritabanı, sertifikalar ve anahtarlar yedeklenmelidir.
  • Uygulamalar sertifika geçerliliği kontrolü gerçekleştirilirken sertifikanın iptal olup olmadığı kontrolünü gerçekleştirecek şekilde ayarlanmalıdır. /NoCRLCheck parametresi kullanılması durumunda HTTPS bağlantısı öncesinde CRL kontrolünün yapılmayacağı göz önünde bulundurulmalıdır.

AD-CS: Kurulum Türleri

Aktif Dizin Sertifika Servisi: Kurulum Türleri

İki türde AD-CS kurulumu gerçekleştirilebilir:
  • Enterprise CA
  • Standalone CA

Enterprise CA Kurulumu
Dijital imzalama, S/MIME kullanarak e-posta güvenliğini sağlama, SSL/TLS kullanarak güvenli bir Web sunucusuna kimlik doğrulaması yapma, akıllı kart kullanarak etki alanında oturum açma gibi amaçlarla sertifika yayımlayabilir. Enterprise CA şu özelliklere sahiptir:
  • Active Directory Etki Alanı Hizmetleri'ne (AD DS) erişim gerektirir.
  • Genellikle kayıt etme (issuing) işlemi için kullanılırlar.
  • Ormandaki (Forest) tüm kullanıcı ve bilgisayarlar için; sertifikasını, Güvenilen Kök Sertifika Yetkilileri (Trusted Root Certification Authorities) sertifika deposuna yerleştirmek amacıyla grup ilkesini kullanır. 
  • AD DS'ye kullanıcı sertifikaları ve sertifika iptal listeleri (CRL) yayımlar.
Enterprise CA'ları, bir sertifika şablonuna dayalı olarak sertifika verir. Sertifika şablonları kullandığınızda aşağıdaki işlevleri kullanmak mümkündür:
  • Enterprise Sertifika Otoriteleri, sertifika kaydı sırasında kullanıcılar için kimlik denetimini zorunlu kılar. Her sertifika şablonunun, sertifika istek sahibinin istediği türde sertifika almaya yetkili olup olmadığını belirleyen, AD DS üzerinde ayarlanmış bir güvenlik izni vardır.
  • Sertifika konusu veya adı, AD DS üzerindeki bilgilerden otomatik olarak oluşturulabilir veya istek sahibi tarafından sağlanabilir.
  • İlke modülü, verilen sertifikaya, sertifika uzantılarının önceden tanımlanmış bir listesini ekler. Uzantılar sertifika şablonu tarafından tanımlanır. Böylece, sertifika ve amaçlanan kullanımla ilgili olarak sertifika isteyenin sağlaması gereken bilgiler azalır.
  • Sertifika vermek için otomatik kayıt kullanılabilir. Ancak yöneticilerin, bu otomatik yapıyı kontrol etmesi ve güvenliğini sağlaması için, parola politikası gibi bazı politikaları sıkı tutması gerekir.

Standalone CA Kurulumu
Dijital imzalama, S/MIME kullanarak e-posta güvenliğini sağlama, SSL/TLS kullanarak güvenli bir Web sunucusuna kimlik doğrulaması yapma gibi amaçlarla sertifika yayımlayabilir. Standalone Sertifika Otoriteleri şu özelliklere sahiptir:
  • Enterprise Sertifika Otoriteleri’nin aksine Standalone CA'lar, Active Directory Etki Alanı Hizmetleri'ni (AD-DS) kullanmayı gerektirmez. AD DS kullanılsa bile, SO hiyerarşisinde ya sadece çevrimdışı güvenilen Kök Sertifika Otoriteleri olarak kullanılabilir; ya da istemcilere bir extranet veya Internet üzerinden sertifika vermek için kullanılabilir. 
  • Genellikle Kök ve Ara CA’lar için kullanılırlar.
  • Ağ bağlantısı kapalı tutularak, çevrimdışı olarak çalışmalıdırlar. Çevrimiçi çalışacaklarsa HSM (Hardware Security Module) kullanılmalıdır.
  • Sertifika oluşturmak için şablon kullanmazlar.
  • İstemciler, bir Standalone Sertifika Otoritesi’ne sertifika isteği gönderdiğinde, kendilerini tanımlayan bilgileri sağlamaları ve gereksinim duydukları sertifikanın türünü belirtmeleri gerekir. (Enterprise CA'larına istek gönderilirken bunların yapılmasına gerek yoktur; çünkü, etki alanındaki istemcilerin bilgileri zaten AD DS üzerinde bulunmaktadır ve sertifika türü de bir sertifika şablonuyla belirtilmiş olması gerekmektedir). İsteklerle ilgili kimlik doğrulama bilgileri yerel bilgisayarın Güvenlik Hesapları Yöneticisi (Security Accounts Manager) veritabanından alınır.
  • Varsayılan olarak, Standalone Sertifika Otoritesi’ne gönderilen tüm sertifika istekleri, Standalone Sertifika Otoritesi’nin yöneticisi gönderilen bilgileri doğrulayıp isteği onaylayana kadar beklemeye alınır. Sertifika isteyenin kimlik bilgileri Standalone Sertifika Otoritesi tarafından doğrulanmadığı için, yöneticinin bu görevleri gerçekleştirmesi gerekir.
  • Yöneticinin, Standalone CA'nın sertifikasını etki alanı kullanıcısının güvenilen kök deposuna dağıtması ya da kullanıcıların bu görevi kendilerinin yapması gerekir.
Standalone olarak kurulan bir sertifika otoritesi, AD-DS kullanırsa; bu sunucu aşağıdaki ek özelliklere sahip olur:
  • Domain Admins grubunun bir üyesi veya etki alanı denetleyicisine Yazma erişime sahip bir yönetici Standalone bir Kök (root) Sertifika Otoritesi yüklerse, etki alanındaki tüm kullanıcı ve bilgisayarlar için Güvenilen Kök Sertifika Yetkilileri (Trusted Root Certification Authorities) sertifika deposuna otomatik olarak eklenir. Bu nedenle, etki alanına Standalone bir Kök CA yüklenecekse, sertifika istekleri alındığında CA tarafından gerçekleştirilecek varsayılan eylem, istekleri beklemede (requests as pending) olarak değiştirilmelidir. Aksi takdirde, etki alanına sertifika isteyenin kimliğini doğrulamadan otomatik olarak sertifikalar veren bir güvenilen Kök CA yüklenmiş olur.
  • Kuruluştaki üst etki alanının Domain Admins grubunun bir üyesi veya AD DS'ya Yazma erişime sahip bir yönetici tarafından Standalone CA yüklenirse; yüklenen bu Standalone CA, kendi CA sertifikasını ve sertifika iptal listesini (CRL) AD DS'ye yayımlar.
Katmanlı Yapı
  • Tek katmanlı yapıda Kök SO Enterprise olarak kurulurken, Ara ve Kayıt Eden sertifika otoriteleri bulunmamaktadır.
  • İki katmanlı yapıda Kök SO olan Standalone, Kayıt Eden Sertifika Otoritesi Enterprise olarak kurulurken, Ara SO bulunmamaktadır.
  • Üç katmanlı yapıda Kök ve Ara SO Standalone olarak, Kayıt Eden SO Enterprise olarak kurulur.



6 Ekim 2012 Cumartesi

Okunası Makaleler: SSH / Tünel

SSH / Tünel Makaleleri

SSH Tunneling ile Güvenli Surf ve SSH Port Forwarding

Kaynak site:
http://www.syslogs.org/ssh-tunneling-ile-guvenli-surf-ve-ssh-port-forwarding/

Survey Finds Secure Sites Not So Secure
Kaynak site:
https://threatpost.com/en_us/blogs/survey-finds-secure-sites-not-so-secure-042712

SSH Nedir? SSH Ne Demektir? SSH Hakkında Bilgi
Kaynak site:
http://www.pcrehberi.org/14/05/2011/bilgisayar-temel-bilgileri/ssh-nedir-ssh-ne-demektir-ssh-hakkinda-bilgi.html/

VPN vs. SSH Tunnel: Which Is More Secure?
Kaynak site:
http://www.howtogeek.com/118145/vpn-vs.-ssh-tunnel-which-is-more-secure/

Top 20 OpenSSH Server Best Security Practices
Kaynak site:
http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html


SSH Tünelleme ile İçerik Filtreleyicileri Atlatmak
Kaynak site:
http://www.bga.com.tr/calismalar/ssh_proxy.pdf

Okunası Makaleler: Sertifika / SSL

Sertifika / SSL Makaleleri

Prensip
Sign with MY Private, Encrypt with YOUR Public

Sertifika ve SSL Kavramları
Kaynak site:
http://www.cozumpark.com/blogs/gvenlik/archive/2010/09/25/sertifika-ve-ssl-kavramlar.aspx

Sertifika - Sertifika Oluşturma - Sertifika Türleri
Kaynak site:
http://www.bilgiguvenligi.gov.tr/guvenlik-teknolojileri/sertifika-sertifika-olusturma-sertifika-turleri.html

DDoS Attacks on SSL: Something Old, Something New
Kaynak site:
http://ddos.arbornetworks.com/2012/04/ddos-attacks-on-ssl-something-old-something-new/

Automate testing SSL/TLS clients for resistance against MITM attacks
Kaynak site:
http://www.gremwell.com/sslcaudit_files/doc/sslcaudit-user-guide-1.0.pdf

https nasıl çalışır
Kaynak site:
http://www.networkpentest.net/2011/08/https-nasl-calsr.html

SSL/TLS Deployment Best Practices
Kaynak site:
https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.0.pdf

HTTP - Nass oluyor da oluyor? HTTPS - HTTP over SSL
Kaynak site:
http://umut-simsek.blogspot.com/2012/06/http-nass-oluyor-da-oluyor-https-http.html

CSR Decoder
Kaynak site:
http://www.sslshopper.com/csr-decoder.html

OpenSSL Public/Private Key Encryption
Kaynak site:
http://www.liatsisfotis.com/2012/04/openssl-publicprivate-key-encryption.html

Kısa Uzunluktaki Cipherlardan Kaynaklanan Zafiyetlerin Giderilmesi
Kaynak site:
http://www.cozumpark.com/blogs/gvenlik/archive/2013/01/27/k-sa-uzunluktaki-cipherlardan-kaynaklanan-zafiyetlerin-giderilmesi.aspx