IT altyapılarının güvenilirliğini ve bağlı olarak sürekliliğini sağlamak üzere uygulanması gereken süreç disiplinlerinde kritik data içeren mecralara erişimlerde sıkı güvenlik prosedürleri izlenmesi gerekiyor. Bu anlamda özellikle PCI-DSS ya da ISO 27001 standartlarına tabii olan ya da olmak isteyen firmaların, kendi networklerine “dışarıdan” erişim ihtiyacının bulunması durumunda implemente edecekleri VPN çözümlerinin, bahsi geçen güvenlik standartlarına uygun olması gerekiyor. Örnek olarak PCI-DSS uyumluluğu için kullanılan VPN çözümünde kimlik doğrulama işlemi en az iki aşamalı olarak gerçekleştirilmek durumunda. Bu zorunluluk PCS-DSS V3’de şu şekilde tarif edilmiş durumda:

Implement Strong Access Control Measures 8.3 – Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance). Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. 8.2 Authentication methods – Something you know, such as a password or passphrase – Something you have, such as a token device or smart card – Something you are, such as a biometric.

Bu tanıma göre, networkünüze uzaktan erişim sağlayacak her türlü bağlantı için yapılacak kimlik denetimlerinde madde 8.2’de belirtilen metodlardan en az ikisinin kullanılması gerekiyor. Günümüzde yaygın olarak kullanılan SSL VPN çözümlerinde PKI altyapısı kullanılarak, bir username üzerinden key ibraz etmek sureti ile kimlik denetimi gerçekleştirilip bağlantı kuruluyor. Ancak bu tek yönlü kimlik denetimi, anlaşıldığı üzere yeterli değil. Bu nedenle kullandığınız VPN çözümünün username/ password (ya da key) ibraz etmeye ek olarak token ya da bir biometric denetim mekanizmasını destekliyor olması gerekiyor. Biometric denetim mekanizmalarının oldukça sınırlayıcı ve maliyetli çözümler olduğunu düşünürsek, iki yönlü doğrulama için username + token mekanizmalarını birlikte kullanmak konunun pratik çözümü olacaktır. İşte bu konudan hareketle bu yazıda, bir SSL VPN implementastonu olan OpenVPN ve Google Authenticator kullanılarak two-factor authentication destekleyen bir VPN sunucusu kurulumundan bahsedeceğim. En nihayetinde halihazırda kullandığınız OpenVPN altyapınıza yazıda anlatıldığı şekli ile google authenticator entegrasyonu da yapabilirsiniz.

Yazinin devami icin tiklayin.

Portspoof, bir network scanner uygulaması kullanarak sunucular üzerinde çalışan servisleri tespit etmek isteyen saldırganların işlerini zorlaştırmak ve tarama sonucunu manupule etmek sureti onları yanıltmak üzere geliştirilmiş enteresan bir uygulamadır.

Bildiğiniz gibi network scanner uygulamalarının uzaktaki bir sistemde çalışan servisleri tespit etmeleri için kullandıkları bir takım teknikler vardır. Bu tekniklerden en tipik olanı ise TCP’nin üçlü el sıkışma prensibinden hareketle uzak sunucunun tüm portlarına (ya da ilgilenilen portlarına) birer SYN paketi göndermek ve alınacak cevaba göre ilgili servisin mevcudiyeti ya da durumu ile ilgili karara varmaktır. Örnek olarak üzerinde bir web sunucusu çalıştığını bildiğiniz uzaktaki bir sistemin 80. portuna bir SYN paketi gönderirseniz ve uzak sunucudaki bu servis çalışır durumdaysa -ayrıca herhangi bir engelleme yoksa- cevap olarak SYN+ACK paketi alırsınız. Bu şekilde ilgili servisin çalışır vaziyette olduğu uzaktan tespit edilir ve örneğin nmap ilgili port’u OPEN olarak bildirir. Aynı şekilde gönderilen SYN paketine RST paketi dönerse, uzak sunucuda ilgili portu dinleyen bir servis olmadığı anlaşılır ve scanner uygulaması durumu CLOSED olarak değerlendirir. Eğer uzak sunucu bir firewall üzerinden korunuyorsa ve SYN paketini gönderdiğiniz porta erişim izniniz yoksa ilgili paket -genel olarak- drop edilir bu nedenle de geriye herhangi bir paket döndürülmez. Bu durumda da network scanner uygulaması durumu FILTERED olarak bildirir, bu şekilde de uzaktaki sistemin bir firewall’a sahip olduğunu tespit edebilirsiniz.

Yazinin devami icin tiklayin.

Google Authenticator, sağladığı PAM modülü üzerinden OpenSSH’a entegre edilebiliyor, bu şekilde SSH erişimlerinde, şifre ya da key based auth’a ek olarak, telefonunuzda yüklü olan Google Authenticator üzerinden üretebileceğiniz time-based one-time password (TOTP) doğrulamasını da devreye alarak two-step authentication yapabiliyorsunuz.

Özellikle bir nedenle heryerden erişilebilir, standart portta çalışan SSH çalıştıran sunucularınız varsa, ek bir güvenlik katmanı sağladığından dolayı Google Authenticator entegrasyonunu da kullanmak isteyebilirsiniz. Bu nedenle yazının devamında, CentOS 6 ve Debian 7 sistemler için google authenticator PAM modülünün kurulması ve SSH’a entegre edilmesinden bahsedeceğim.

Yazinin devami icin tiklayin.

Geçenlerde ISC‘de, networklerdeki rogue gatewaylerin nmap ile nasıl tespit edilebileceğini anlatan güzel bir yazı yayınlandı. [1] Buna göre, nmap’in ip-forwarding scriptini kullanarak networkteki cihazların her birine özel bir icmp-ehco requesti gönderip, dönen cevaplardan ip forwarding’i etkin olan yani üzerinden trafik geçirebilecek durumda olan cihazları bulabiliyorsunuz. Bir başka deyişle, böyle bir taramada default gateway’iniz dışında ip forwarding’i açık olan bir cihaz listelenirse, ağınızda kontrolünüz dışında bir çıkış kapısı daha var demek olabilir ki arp poisoning ile tüm trafik bu noktadan geçiyor ve bu şekilde networkünüz sniff ediliyor bile olabilir.

Yukarıdaki örnek bir senaryo olsa da özellikle raspberry pi gibi küçük bilgisayarların networklerde arka kapı oluşturmak için kolayca kullanılabileceği bilindiğinden aslında pek de hafife alınacak bir konu değildir.

Netwörküzde böyle bir tarama yapmak için ip-forwarding scriptini şu şekilde kullanabilirsiniz:

nmap -sn 10.0.0.0/24 --script ip-forwarding --script-args="target=www.google.com"

Bu komuta göre öncelikle 10.0.0.0/24 networkünde ping scan yapılacak ve up durumdaki hostlar tespit edilecektir. Sonrasında da bu hostlara ip-forwarding scripti kullanılarak www.google.com için özel bir icmp-echo paketi gönderilecek ve ip forwarding yapan host var ise aşağıdaki gibi listelenecektir:

Nmap scan report for 10.0.0.98
Host is up (0.047s latency).
MAC Address: F4:6D:04:9D:92:ED (Asustek Computer)

Host script results:
| ip-forwarding:
|_  The host has ip forwarding enabled, tried ping against (www.google.com)

Bu şekilde de default gateway’iniz dışında ip forwarding yapan makinaları tespit etmeniz mümkün olacaktır.

Yazının orjinali şurada mevcut; detaylar için gözatabilirsiniz:

[1] http://isc.sans.edu/diary/Do+you+have+rogue+Internet+gateways+in+your+network+Check+it+with+nmap/16198

Sistemde aslında kullanımda olmayan servisleri kapatmak, basit ama unutulmaması gereken bir güvenlik önlemidir. Zira kullanılmadığından dolayı çalışmasına gerek olmayan servislerde çıkabilecek herhangi bir güvenlik zafiyeti  sistem bütünlüğünü tehlikeye atacağı gibi ayrı olarak sistem kaynaklarının boş yere tüketiliyor olması anlamına da gelmektedir. Dolayısı ile bu tip servislerin saptanması ve devre dışı bırakılması rutin olması gereken bir işlemdir.

Yazının devamında, sunucu olarak kullanılan sistemler için çalışan servislerin listelenmesi, gereksiz olanların hangilerinin olabileceği ve bunların devre dışı bırakılması ile ilgili detaylar bulabilirsiniz.

Yazinin devami icin tiklayin.

Gönderdiğiniz maillerin gerçekten sizin tarafınızdan gönderildiğini ispat etmeye yönelik bir kimlik doğrulama metodu olan DKIM konusuna önceki bir yazımda değinmiş ve qmail sunucularda giden maillerin DKIM (DomainKeys Identified Mail) ile imzalanmasının nasıl sağlanabileceğini anlatmıştım. Özellikle toplu mail gönderileri yapıyorsanız maillerinize mutlaka uygulanması gereken DKIM bildiğiniz gibi Domainkeys denilen bir diğer kimlik doğrulama metodunun geliştirilmiş ve yaygın olarak kullanılan versiyonudur.

DKIM ile DomainKeys aynı şeyi amaçlayıp aynı teknolojiyi kullanıyor olsalar ve sadece DKIM kullanmak yeterli gibi görünse de gönderdiğiniz mailleri hem DKIM hem de Domainkeys ile imzalamak elbette daha iyi olacaktır. Zira bazı sistemlerde sadece DKIM doğrulaması yapılırken bazılarında sadece DomainKeys kullanılıyor olabilir. Bu nedenle her iki yöntemi kullanarak yapılan imzalama, iki yöntemden sadece birini kullanan alıcı sistemlerle de iyi geçinmek anlamına gelir. Yazının devamında, daha önceki yazıma ek olarak qmail sistemlerde giden maillerin DKIM’in yanı sıra DomainKeys kullanılarak da imzalanmasından bahsedeceğim.

Yazinin devami icin tiklayin.

CeH Türkiye‘den Ozan Uçar, FreeBSD/OpenBSD işletim sistemi ile birlikte gelen Packet Filter’i (PF) temel alarak geliştirilmiş açık kod güvenlik duvarı PfSense ile bir eğitim programı hazırlamış. PfSense’in, kurumsal iş ortamlarında etkin kullanımını amaçlayan iki günlük eğitim BGA.com.tr tarafından organize ediliyor.

Konuyla ilgili detaylı bilgi almak için aşağıdaki adresleri ziyaret edebilirsiniz:

http://www.cehturkiye.com/index.php/2010/09/18/pfsense-guvenlik-duvari-ve-router-egitimi
http://www.bga.com.tr/pfsense-guvenlik-duvari-egitimi-19-20-mart-2011/

PasswordCard, uzun ve karmaşık şifreler üretmeye ve bunları kolayca hatırlamaya olanak sağlayan zekice düşünülmüş ve güzel bir şifre sistemidir. Üstelik, -resimde bir örneği görüldüğü üzere- kredi kartı ebatlarında olması ve cüzdanda taşınabilmesinden ötürü şifrelerinizi güvenle yanınızda taşımaya da olanak sağlıyor. Üst satırında semboller ve yukarıdan aşağı sol sırasında rakamlar bulunan, farklı renk satırlara sahip PasswordCard sayesinde, üretilen şifrelerin akılda tutulmasına gerek kalmıyor. Şifrenizin  sembol ile sıra numarasını/rengini bilmeniz, şifrenizi hatırlamanız için yeterli oluyor.

Bilgi güvenliğinin yumuşak karnı olan zayıf ve tahmin edilebilir şifrelerden sakınmaya olanak sağlayan bir araç olmasından ötürü, yazının devamında, PasswordCard ile ilgili biraz daha fazla detaya değinmek istiyorum;

Yazinin devami icin tiklayin.