makale - yazar_detay

İnternet, pek çok arkadaşımızın TMG hakkında hazırladığı makaleleri ve videoları taliplilerine ulaştırmasına rağmen, hâlâ cevap bekleyen pek çok soruya da ev sahipliği ediyor. Dikkatlice incelendiğinde, aslında aynı konu başlıklarının çok fazla öne çıktığını görebiliriz. Hedefimiz, işte bu ortak sorulara çözüm sunabilmektir. Tespit edebildiğim bu sorular:

Şirket ağlarının güvenlik seviyesini tespit edip varsa açıklarının kapatmak günümüz Bilgi Teknolojileri dünyası için gayet önemli bir görevdir. Açıklar kimi zaman worm, trojan, virus gibi isimler altında üretilen kötü amaçlı kodlarla kimi zaman da hacker, lammer gibi kötü amaçlı kişilerce kullanılabilir. Önemsenmeyen bir açık tüm ağı ve ağ üzerinden geçen bilgiyi tehdit edip kullanılamaz hale getirebilir. Örneğin işletim sisteminin yayımlanmış bir yamasının şirket sunucularına uygulanmaması bu açığı şirket içerisinde kullanılabilir kılar. Sasser, Blaster, Slammer gibi meşhur olmuş kötü amaçlı kodlar, dünya çapında sistem açıklarını kullanarak milyonlarca liralık yıkımlara mal olmuştur.

Beşinci JunOS makalemizde, güvenlik politikalarının(security policy) konfigürasyonunu inceleyeceğiz. Güvenlik gereksinimleri aynı olan bir ya da daha fazla network segmentinin bir arada bulunduğu alanlar zone olarak tanımlanır ki bu zone’lar arasındaki trafiğin kontrolünü de security policy’ler sağlar. Interface’leri ve zone’ları aşağıdaki tabloda gösterildiği şekilde konfigüre etmiştik.

Altıncı JunOS makalemizde, JunOS işletim sistemli bir Juniper SRX 3400 Firewall üzerinde NAT(Network Address Translation) konfigürasyonlarının nasıl gerçekleştirileceğini inceleyeceğiz. IPv4 adreslerinin yetersizliğine çözüm olarak geliştirilmiş NAT fonksiyonu sayesinde internet ortamında kullanılan gerçek IP’ler (public) ve lokal ağda kullanılan özel IP’ler (private) arasında dönüşüm ve dolayısıyla iletişim mümkün olabilmektedir. Bu sayede zaten yetersiz kalan public IP’lerin lokal ağlarda kullanılma mecburiyerinin önüne geçilmiş olmaktadır. Private IP olarak kullanılabilecek IP blokları şu şekildedir:

JunOS işletim sistemini, CLI mimarisini, Cluster mimarisini ve temel konfigürasyonunu inceledeğimiz ilk üç makalenin ardından şimdi de Interface ve Zone konfigürasyonlarını inceleyeceğimiz bu dördüncü makalemizle devam ediyoruz. Çalışmalarımızı, cluster çalışacak şekilde yapılandırdığımız iki SRX 3400 Firewall üzerinde gerçekleştireceğiz.

JunOS işletim sistemi ve JunOS CLI mimarisini incelediğimiz ilk iki makalemizden sonra, bu üçüncü makalemizde de JunOS işletim sistemli High-End Serisi SRX Firewall’lar üzerinde temel konfigürasyon ve Cluster kurulumunun nasıl gerçekleştirileceğini inceleyeceğiz. Juniper tarafından üretilen JunOS işletim sistemli High-End Serisi SRX Firewall’lar, SRX1400, SRX3400, SRX3600, SRX5600, SRX5800 modelleridir. Biz incelemelerimizde modeli SRX 3400 olan bir firewall kullanacağız.

F5 Load Balance Cihazı üzerinde, LoadBalance için gerekli Network parametrelerinin tanımlanması: İlk makalemizde, F5’in LoadBalance edeceği iki SharePoint web sunucusu için, F5 üzerinde yapılması gerekli network tanımlamalarını açıklamıştık. İkinci makalemizde, F5’in template ekranını kullanarak, MS SharePoint uygulamasını loadbalance etmek için, VS, Pool ve Node tanımlamalarını yapmıştık.

Citrix NetScaler cihazı üzerinden bir SSL web sitesinin yük dağıtımının yapılması için gerekli adımları bu makalede ele alacağız. Öncelik ile Bir web sitesinin SSL olarak hizmet verebilmesi için elbette sertifika ihtiyacı olacaktır. Gerçek hayatta sertifikanın temini için Verisign, GlobalSign, Thawte gibi ticari sertifakasyon otoriteleri kullanılır. Biz test için kendi lokal Microsoft sertifkasyon yapımızı kullanacağız. Sertifkasyon yapısı bir offline Root ve onun altında konumlandırılmış bir Subordinate CA’den oluşmaktadır.

Juniper firması tarafından geliştirilen yeni nesil firewall, router ve switch gibi network/güvenlik cihazlarında kullanılan JunOS işletim sistemi mimarisini ve çalışma mantığını incelediğimiz Junos Isletim Sisteminin Temelleri isimli makalemizin ardından, JunOS İşletim Sistemi CLI(Command Line Interface) Mimarisini inceleyeceğimiz serinin bu ikinci makalesiyle devam ediyoruz. İlk makaleyi kısaca hatırlayacak olursak, - Juniper tarafından FreeBSD üzerinde geliştirilmiş modüler bir işletim sistemi olan JunOS’un, çoklu yazılım proseslerine ayrılacak şekilde yapılandırılmış bir işlevselliğe sahip olduğunu ve her proses’in cihazın fonksiyonalitesinin bir parçasını işleyerek kendi korunan (protected) memory alanında çalıştığını,

Junos modüler bir işletim sistemidir ve FreeBSD üzerinde geliştirilmiştir. Çoklu yazılım proseslerine ayrılacak şekilde yapılandırılmış bir işlevselliğe sahiptir. Her proses cihazın fonksiyonalitesinin bir parçasını işler ve kendi korunan memory alanında çalışır.

Management portları üzerinden birbirlerini pingleyerek bir tanesi Primary, diğeri Secondary olarak çalışan iki adet Citrix NetScaler- 12500 cihazımız olduğunu ve cihazlarımızın 1/15.portlarını kullanarak iki web sunucunun loadbalance işlemini gerçekleştireceğimizi söylemiştik. Bunun için de primary olan cihazın bu portu üzerinde ilgili network tanımlamalarını yapmıştık. Kısaca hatırlayalım: - Interface, VLAN ve Tag değerlerinin tanımlanarak 1/15 portunun Trunk çalışmasının sağlanması. - Kullanıcıların, Citrix üzerinde gelecekleri Virtual IP’nin oluşturulması. - Citrix’in, göndereceği paketlerde source IP olarak kullanacağı Subnet IP’nin oluşturulması.

Citrix NetScaler Load Balance Cihazı üzerinde, LoadBalance için gerekli Network parametrelerinin tanımlanması: Bir tanesi Primary, diğeri Secondary olarak çalışan iki adet Citrix NetScaler- 12500 NLB cihazımız bulunmaktadır. Bu cihazlarla, iki web uygulama sunucusunu load balance etmek istiyoruz. NetScaler cihazlarının birer portu Management olarak tanımlı ve bu portlara verilecek IP’ler sayesinde, NetScaler yönetimini gerçekleştiriyoruz. Bu IP’nin NetScaler üzerindeki adı NetScaler IP ’dir. İki cihaz, birbirlerini management portlarına verilen bu IP’lerinden pingleyerek Primary/Secondary modda cluster çalışacaklar.

Serinin dördüncü makalesinde de, 443 harici portlardan iletişim kurulması gereken HTTPS erişimleri hakkında yapılması gereken özel bir tanımı inceleyeceğiz. ISA 2004 ve ISA 2006’da bulunmayan, TMG ile birlikte gelen HTTPS Inspection fonksiyonunu incelemiş ve bazı HTTPS trafiklerinin bu fonksiyon ile bloklandığı zaman çözüm için neler yapılması gerektiğinden bahsetmiştik. HTTPS Inspection ekranında Destination Exceptions alanına ve Web Access Policy ekranında da izin verilecek adresler listesini tanımladığımız URL Set’e, ilgili HTTPS adresinin ne şekilde yazılacağını açıklamıştık.

İnternet erişimlerini kontrol altında tutabilmek için, işlevi, ister bloklamak(deny) isterse de izin(permit) vermek olsun, tüm web erişim kurallarında, illa ki kaynak, hedef, kullanıcılar ve tabi ki protokol tanımları yapılmak zorundadır. Bu tanımlardan birini diğerinden önemli görmek mümkün değildir; fakat sizi hedeflediğiniz işlevin yerine gelmemesi noktasında en çok sıkıntıya sokan ve uğraştıran tanım, hedef bilgisinin oluşturulduğu aşamadır. Hedef tanımlarında size bahsedeceğim yöntemleri uygularsanız sorununuz kalmayacaktır.

Gerçek ortamda URL Filtering Çözümü Olarak TMG Ürününün İncelenmesi