Günümüzde “bilgi güvenliği” farkındalığı sadece büyük ağların ihtiyacı değil 3 - 5 kullanıcılı ağlarda bile gerekli önlemlerin alınması, doğru konfigürasyonun yapılması, güvenliğin sağlanmasında en önemli faktörlerden. Kullanıcı kimliğinin doğrulanması, orta büyüklükteki ve büyük ağlarda bir dizin yapısı kullanılarak yapılır. (Active Directory, Novell Directory, Open LDAP vb.) Ancak çok az kullanıcı bulunan ağlarda kimlik doğrulaması için daha basit çözümlere ihtiyaç vardır. Watchguard XTM serisi cihazların kendi bünyesinde bulunan kullanıcı veritabanı ve otomatik browser yönlendirmesi özelliklerini, MAC adresi kısıtlaması ile birleştirdiğimizde, başarılı bir doğrulama yapısı kurmuş oluyoruz. Client sayısının yüksek olduğu yerlerde kullanışsız olan bu metot az kullanıcı yerlerde oldukça başarılı bir şekilde çalışmaktadır.

Bu makalemizde WatchGuard ürünü üzerinde MAC address kısıtlamalı Kimlik Doğrulamalı Internet Erişimi konfigürasyonunun nasıl yapıldığını anlatmaya çalışacağım. MAC adres kısıtlaması bize, her kullanıcının ağ kablosunu takıp veya kablosuz yayına bağlanıp internet te dolaşmasını engellemek ve bu erişim kontrolünün tamamen bizim kontrolümüzde olmasını sağlayacaktır. User Authentication ise, kullanıcı mac adresi tanımlandıktan sonra internet erişimini sağlarken, logların daha anlaşılabilir bir şekilde tutulması için faydalı olacaktır. Bunu yapmayıp direkt internet izni de verebilirdik. Fakat bu bizim için ve log kayıtlarını anlamakta zorlanmamıza neden olacaktır. Bu konfigürasyonu ister şirket içinde, isterseniz Misafirler için sağlanan internet erişiminde kullanabilirsiniz. Anlatım teknik bir anlatım olduğu için sık ekran paylaşımları ile ilerleyeceğiz;

Önemli Bir Not: MAC Adreslerini tanımlarken mutlaka ve mutlaka cihazı yönetmek için bir MAC adresi tanımlamayı unutmayın. Eğer tanımlamazsanız cihaza erişemez ve cihazı yeniden yapılandırmak zorunda kalırsınız.

İlk olarak XTM cihazımıza login oluyoruz.

Daha sonra “Policy Manager” tabına tıklıyoruz.

MAC erişimlerini tanımlamak için Menü den “Network” daha sonra “Configuration” tabını seçiyoruz.

Gelen ekranda “MAC Access Control” tabına tıklıyoruz ve aşağıda bulunan “Restrict access by MAC adress” kutucuğunu işaretliyoruz. Daha sonra “Add” butonuna tıklayıp ilgili MAC adresimizi tanımlıyoruz.

Daha sonra kullanıcıların Kimlik doğrulama ekranına yönlendirilmesini sağlamak için “Setup” – “Authentication” – “Authentication Settings” ekranına giriyoruz.

Burada “Firewall Authentication” tabına gelip aşağıdaki “Auto redirect user to authentication page for authentication” kutucuğunu işaretliyoruz. Bu kutucuğu işaretledikten sonra kullanıcı internet erişmek istediğinde otomatik olarak kimlik doğrulama ekranına yönlendirilecektir. Tabi MAC adresi tanımlarında adresi tanımlı ise.

Daha sonra kullanıcılarımızı oluşturmak için “Setup” – “Authentication” – “Authentication Servers” ekranına giriyoruz.

Ben burada ilk önce “naviga” grubunu oluşturdum, Daha sonra “cem” kullanıcısını oluşturup “naviga” grubunun üyesi yaptım. Bu grup kurallarımızı oluştururken bize kolaylık sağlayacaktır. Kullanıcının ağdaki kalma ve Boşta kalma sürelerini de istediğimiz şekilde tanımlayabiliriz.

Kullanıcımızı ve grubumuzu da tanımladıktan sonra artık kurallarımızı yazmaya başlayabiliriz. Kuralımızda dikkat etmemiz gereken bir şey var. “DNS” kuralını network e vermek zorundayız. Burada kullanıcı erişimi sağlamak için, DNS sorgusu yapmak zorundadır. Eğer sorguyu yapmaz ise “Kimlik doğrulama ekranı” da yönlendirilemez. Dns kuralımızı oluşturduktan sonra web erişimi için “http proxy” kuralını oluşturduğumuz kullanıcıların erişebileceği şekilde yapılandırıyoruz. Aşağıdaki resimde de görüldüğü gibi… Bu işlemler “https proxy” içinde geçerlidir.

Kurallarımız da hazır artık. Fakat dikkat etmemiz gereken bir unsur daha. Henüz kuralımızı kaydetmedik. Bunu da resimde en üste gördüğümüz “XTM510.xml” yazısının yanında bulunan “*” işaretinden anlıyoruz. Konfigürasyonumuzu kaydediyoruz. Kaydettikten sonra “*” kaybolduğunu göreceksiniz.

Kullanıcımız Internet erişim sağlamak istediğinde WatchGuard direkt olarak kullanıcıyı “Kimlik doğrulama ekranı” na yönlendirecektir.

Kullanıcı “Login” oluyor.

Ve artık internet erişimi sağlanmış durumdadır.

Loglarımızda da gördüğümüz gibi kullanıcıya izin verilmiş ve internet erişimi sağlanmış durumda. Eğer Mac adresi tanımlanmamış bir kullanıcı internet e erişmek isterse aşağıdaki loglarda görüldüğü gibi “Deny” ve “Mac address blocked” kayıtları gözükecektir.

Konfigürasyonumuz bu şekilde sonlanmıştır. Umarım faydalı bir makale olmuştur.

Yeni makalelerde görüşmek üzere…

Ölçeklenebilir bir altyapı kurmaya çalışsak da, bazen elimizdeki ürünün sınırlarına geliriz. Bu gibi durumlarda (özellikle donanımsal bir ürün söz konusu ise) bir üst modele geçer ve sorunumuzu çözeriz. Bir çok BT uzmanının karşılaştığı bu ortak sorunu WatchGuard ürünleri açısından inceledim ve aşağıdaki makaleyi hazırlamaya karar verdim. UTM gibi içinde karışık konfigürasyon olan ürünlerin terfisi sırasında, herşey elle yapılır ve konfigürasyon baştan yapılırsa insan hataları kaçınılmaz olur. Neyse ki WatchGuard ürünlerinde kullandığımız bazı eski kızılderili numaraları var. Aşağıda bunlardan bahsedeceğiz. Bu makaleyi okuduktan sonra, herhangi bir WatchGuard cihazındaki konfigürasyonu en az efor ile farklı bir modele kopyalayabilir olacaksınız. Ben XTM 23 ten XTM 510 a geçiş yapacağım. XTM 510 un ilk yapılandırmasını yaptıktan sonra İşlemlerimize başlıyoruz;

WatchGuard System Manager’ i açıyoruz. Sisteme login olmadan doğrudan Policy Manager simgesini tıklayarak daha önceden kaydettiğimiz XTM 23 cihazımızın konfigürasyon dosyasını açıyoruz.

Burada ürünlerimiz farklı olduğu için Feature Key (lisans) dosyasında sıkıntı olacaktır. Bu yüzden Feature Key imiz yeni takacağımız XTM 510 un Feature key i olmak zorundadır. Eğer eski Feature Key kullanmak istersek bize hata verecektir.

Ekrana gelen eski XTM 23 Feature Key ini Remove edip XTM 510 Feature Key ini Import ediyoruz. Burada ekrana gelen uyarıda Interface sayıları tutmadığı için Konfigürasyonda sıkıntı çıkabileceğini belirtiyor. Bizim Interface yapılandırmamızda sıkıntı yaratacak bir durum olmadığı için devam ediyoruz.

Feature Key imizi Import ettikten sonra artık bu konfigürasyon u XTM 510 üzerine kaydedebiliriz. Kayıt esnasında Ip yapısı değişeceği için uyarı veriyor. Biz buna Yes deyip devam ediyoruz. Kayıt işlemi bittikten sonra artık XTM 23 üzerindeki konfigürasyonumuz bire bir XTM 510 a aktarılmış olacaktır.

System Manager dan artık cihazımıza yeni ip mizden (XTM 23 e ait konfigürasyon daki ip) login oluyoruz. Artık default ip ler yok. XTM 23 üzerindeki yapılandırmamızı kullanıyoruz.

Görüldüğü gibi kurallarımız artık aktarılmış durumda ve Cihaz geçişi sorunsuz bir şekilde yapılmış oldu.

Önemli Bir Not : Cihaz şifresi unuttulduğu zaman da bu yöntem kullanılabilir. Sadece elimizde konfigürasyon yedeğimizin olması yeterli. Cihazı factory default a çekip yedek konfigürasyonu cihaza kaydetmemiz yeterli olacaktır. Artık factory default a alırken verdiğimiz şifreler geçerlidir ve bu işlem max 10 dk alacaktır.

Umarım faydalı bir makale olmuştur. Yeni makalerde görüşmek üzere…

Zaafiyet Yönetimi Sistemi ile BT Sistemleri’ndeki olası zaafiyetler belirlenerek tehditler için kontrol aksiyonları alınması amaçlanır. Peki zaafiyet ve tehdit nedir?

Zaafiyet (vulnerability) , sistemlerde tehditlere hedef olabilecek yapısal ve konfigürasyonel açıklıklardır.

Tehdit (threat): Sistemlerdeki açıkları kullanarak sistemleri ele geçirme veya devre dışı bırakmaya yönelik kullanılabilen suistimallerdir.

Zaafiyetler hangi sistemlerde bulunur, bu sistemlerin sahipleri kimlerdir? Bu sistemlerin kritik seviyeleri nelerdir? Kritik olmayan bir sunucuda bulunan kritik bir açık ne kadar kritiktir? ZYS için öncelikle varlıklarımızı kritiklik seviyelerine göre sınıflandırmış olmamız gerekmektedir.   

Sahiplik

Sistemlerimizde kullanılan sunucu, network cihazı, terminal, utp kablo vb’nin sahibi kimdir? Bankalardaki Veritabanı Yönetim Servisi’nden örnek verecek olursak, Veritabanı Sunucusu’nun ve içinde barındırdığı bilginin sahibi Sistemci mi yoksa bu bilgileri kullanarak kuruma gelir kazandıran iş birimi midir? Müşteri kayıt formundaki iki imzadan biri müşterinin ise diğer imza kime aittir? BT’ye mi? Tabii ki hayır:  İlgili şube, dolayısıyla o şubenin bağlı olduğu ilgili İş Birimi Müdürlüğü’ne aittir. Bu açıdan düşünüldüğünde, Veri ve Sistem’in sahibi, kurumlardaki İş Birimleri’dir. BT, bu verinin ve sistemin bütünlüğünden (integrity), gizliliğinden (confidentiality) ve erişilebilirliğinden (availability) sorumludur (Data Custodian).

Sistemlerin sahiplerini bulduğumuza göre artık ZYS’ye dönebiliriz. Günümüzde, zaafiyet analizleri BT Güvenliği, BT Risk,  BT Uyum gibi farklı birimlerce yürütülmektedir. Buradaki yaklaşım –çoğunlukla-, zaafiyetlerin bu işe özel bir yazılım ile bulunması (şanslı ise manuel testlerle de), ilgili sistem yöneticilerine ticket/issue açılması (giydirilmesi J ), son olarak da bulguların giderildiğinin belirtilmesinden sonra kontrol taraması yapılmasıdır.

Peki, bu taramanın yapılmasını kim istemiştir? Taramayı yapan birim, kendi kendine aksiyon almaya yetkili midir? Tarama sırasında ya da iyileştirici aksiyon alınırken hizmet dışı vb oluşursa sorumluluk kime ait olacaktır? (Bazı yamaların ya da konfigürasyonların etkin olması için restart gerekmesi vb). Bu noktada, İş Birimleri’ne gerekli farkındalığın kazandırılması ve onlar adına bu teknik faaliyetlerin ilgili birimlerce yürütülmesi gerekmektedir. Bu olgunluk düzeyinin sağlanması ilgili BT Birimleri’nin sorumluluğundadır. Unutulmamalıdır ki, İş Birimi’nin önceliği İş Sürekliliği (Business Continuity), Sistem Birimi’nin önceliği ise Erişilebilirliktir (Availability).

NE’nin yapılacağına İş Birimi karar verdikten sonra (BT Birimleri’nin yönlendirmesiyle) NASIL yapılacağı konusunu BT Güvenliği Birimi’ne outsource edebilir. Bu noktadan sonra sistem sahibinden yetki alan BT birimi, gerekli taramaları yaptıktan sonra dikey ve yatay taramaların kesişimindeki sistemlerin zaafiyetlerini ilgili sistem yöneticisine nokta atışı çözüm önerisiyle birlikte sunmalıdır. Zaafiyet Analizi yazılımlarının çoğu sadece link verdiğinden o kadar linki okuyacak kaynak/bilinç maalesef yoktur.

Günümüzde çoğu zaafiyet taraması yatay yapılmakta; varlıklar türlerine göre (Microsoft Sunucu, Unix/Linux Sunucu, Network Cihazı, Veritabanı Sunucusu vb) zaafiyet taramasından geçirilmektedir.

Aşağıdaki tabloda görüldüğü gibi, yatay tarama sonucu sadece ilgili sistem yöneticisine özel bir rapor olacaktır:

Tarama1: MS1+MS2+MS3 olduğunda, birçok MS Sistem Yöneticisi için hepsinin önceliği aynıdır: “0”, sıfır J

Neden? Sistem Yönecisi’nin önceliği Güvenlik değildir de ondan. Sistem Yöneticisi’nin önceliği erişilebilirliktir (availability). Sistem Yöneticisi gözünden bakıldığında, zaafiyetleri kendisine gönderen (giydiren) birim, bir tool ile next-next yaparak tarama yapıp sonuçlarını mouse ile sağ tık- assign  eden birimdir. Bu yaklaşımın çok etkin/başarılı olmamasının sebebi de budur. Öyle ise burada yanlış olan nedir? ZYS’nin yetkilendirilmesi için taramanın dikey olarak proje bazlı yapılması gerekmektedir.

Her hafta ctesi gece 03:00’te Internet Bankacılığı Projesi’nin zaafiyet analizini dikey yapıp (MS1+DB1+SW1+U/L1) Executive Report olarak ilgili İş Birimi Müdürü’ne sunduğumuzda, pie-charttaki kırmızı dilimin fazlalığı BT Güvenliği’nin aksiyon alma sürecindeki en büyük destekçisi olacaktır. Bu açıdan bakıldığında, İş Birimi, BT Güvenliği Birimi’ni para kazandığı Internet Bankacılığı Projesi’ndeki teknik risklerin giderilmesi için kiralamış gibi düşünülebilir. BT Güvenliği Birimi’nin de aldığı bu gücü ve ZYS raporlarını kullanarak bu süreci etkin şekilde yönetmesi sonuçlarını da Yönetim’e raporlaması gerekmektedir.

Etkin ZYS Sistemi için:

Dikey ve yatay taramalar sonucu, kurum sistemlerindeki en kritik açıklar sistem bazında (unix, ms,  network, veritabanı vb) belirlenerek sistem kurulum prosedürlerinde BT Güvenliği adımı olarak yerini almalıdır. Örneğin, Unix sunucularda kronik hale gelmiş yüksek seviyeli 10 bulgu Unix Sunucu Kurulum Prosedürü’nde BT Güvenliği adımı olarak yerini aldığında taramalarda, yüksek dereceli bulgu sayısı azalacaktır. Bu da Sistem ve Güvenlik Birimleri’nin iş yükünü önemli ölçüde azaltacaktır. Bu liste dinamik olacağından yeni bulgular eklenip geçerli olmayanlar çıkarılacaktır.

Güvenlik sadece zaafiyet taraması yapan birimin işi değildir. Öncelikle, ilgili sistemi (dikey) kullanarak para kazanan iş biriminin, sonrasında Sistem Yöneticisi’nin, son olarak da zaafiyet analizini yapan birimindir. Zaafiyet taramalarında çok sayıda bulgu çıkması durumunda, bu Sistem Birimi’nin mi yoksa BT Güvenliği’nin mi başarısızlığıdır? Yoksa başarısı mıdır?

Zaafiyet Analizi Raporu’ndaki bulguların seviyelerini değerlendirirken bulgu sahibi varlığın da kritiklik seviyesini göz önünde bulundurarak İyileştirme Planı (Remediation Planı) yapılmalıdır. Yüksek seviyeli bulgular 1 hafta içinde, orta seviyeli bulgular 1 ay içinde, düşük seviyeli olanlar da 3 ay içinde giderilmli gibi kurum politikasına göre oluşturulan, bir nevi bulgu takip listesi hüvüyetinde olacak bu liste yardımıyla bulguların bir plan dahilinde giderilmesi ve kontrolü sağlanacaktır.

Zaafiyet aracının önerisinin yanısıra kuruma özel çözümlerin de kayıt altına alınabileceği bir sistem kurularak know-how havuzu oluşturulmalıdır. Bu sayede, aynı zaafiyet farklı bir sistemde de raporlandığında bu know-how kullanılarak hızlı/etkin aksiyon alınabilir.

Denetimler açısından bakıldığında, ZYS’de kullanılan ürünün yetkinliği değil; sürecin bir bütün halinde işletilmesi önemlidir. En çok bulgu bulup nokta atışı iyileştirmeler öneren bir ürün alındığında bile açılan ticket/issuelar uzay boşluğuna gidiyorsa denetim konusunda sıkıntı yaşanacağı aşikardır.

Önemli olan zaafiyet ürününden ziyade Zaafiyet Yönetimi Sistemi kurmaktır. Zaafiyetin bulunması için yetki alınmasından giderildiğinden emin olunmasına kadar geçen süreç bir bütün olarak düşünülmelidir.

Güvenliğin tüm birimlerin görevi olduğu noktasından çıkıldığında ZYS içindeki olası aksaklıklar ivedilikle çözülebilir. Bir adım ileriye gidildiğinde ise, bu ZYS operasyonlarını ilgili sistem yöneticilerin yapması sağlanmalıdır. Böylece, sistem yöneticilerinin ZYS’yi daha fazla benimseyerek kurum kültürünün parçası haline getirmeleri sağlanmalıdır.

Peki en iyi ZYS Yazılımı hangisidir?

Zaafiyetleri en çok bulan mıdır? Bu zaafiyetlerle ilgili iyileştirme adımlarını en net şekilde ortaya koyan mıdır? Bulduğu zaafiyetlerle ilgili otomatik ticket/issue açan mıdır? Sürecin herhangi bir anında istediğiniz türde raporlama yapan mıdır?

İyi bir ZYS Yazılımı’nın aşağıdaki sorulara cevap veriyor olması gerekmektedir:

Umarım faydalı bir makale olmuştur.

İnternet doğası gereği karşımızdakinin doğru kişi olup olmadığını hatta karşımızda olup olmadığını dahi bilemeyeceğiz bir yapıda gelişmiştir. İnternetin gelişimi ile bilgi birikiminin gelişiminin aynı hızla ilerlememekte, ilerleyememektedir. Bu sebeple birçok suiistimal ile karşılaşılmaktadır. Saldırganların iştahını en çok kabartan suiistimal yöntemlerinden biri de son kullanıcının farkında olmadan başka bir web sitesine yönlendirilmesidir.

Peki, gerçekten girmeye çalıştığımız web sitesinin aslında erişmek istediğimiz site olduğundan nasıl emin olabiliriz? Burada devreye sertifika kavramı girmektedir. Sertifika ile kimlik doğrulama işlemi yapılır. Web sitesi kendisi son kullanıcıya tanıtır. Kimlik doğrulama sağlandıktan sonra verinin şifreli iletilmesi süreci başlar. En basit anlamıyla, Sertifika kişinin açık anahtarının yetkili bir sertifika otoritesi tarafından imzalanmış halidir denilebilir.

Sertifika otoritelerini (Certification Authority-CA), kurumların ve kişilerin gerçek manada o kurum/kişi olduklarını onaylayan üst kurumlar olarak tanımlayabiliriz. CA sertifika başvurusunda bulunan kişi/kurumun gerçekten o kişi/kurum olduğunu garanti eder. Sertifika onaylarını, kayıt otoritesi (Registration Authority-RA) olarak adlandırılan yerel kurumlar aracılığı ile yapabiliriz. Bu kurumlara yapılan sertifika taleplerinde şu adımlar izlenir;

·         Sertifika İmzalama isteği oluşturulması

·         Sertifika talebinde bulunulması

·         Kurum bilgilerinin doğrulanması

1 - Sertifika İmzalama isteği oluşturulması(Certificate Signing Request-CSR)

Sertifika talebinde bulunacak olan kurumun sunucusuna uygun bir anahtar çifti oluşturması gerekmektedir. CSR dosyasını herhangi bir web sunucuda oluşturabiliriz.

IIS yüklü bir sunucuda CSR oluşturulması

Microsoft Yönetim Konsolu (mmc) ‘den Internet Information Services (IIS) Manager açılır.

Bu adımda Web Sitesi ismi örnek olarak Default Web Site verilmiştir.

Properties denilerek Directory Security sekmesine geçilir. Burada Secure Communications altında Server Certificate seçilir.

Sihirbaz başlatılır.

Create a new certificate denilerek devam edilir.

Name alanı sertifikada görülen "Friendly name" bölümüdür. Bu alana sertifikanın kullanacağını alan adı girilir. Sertifika uzunluğu seçilir. Sertifika otoriteleri bu değerin 2048 bit olacak şekilde girilmesini şart tutmaya başlamışlardır.

Bu adımda girilecek parametreler RA tarafından kontrol edilecektir. Bu alanların doldurulması sırasında Türkçe karakterler kullanılmamalı ve girilen kurum adı bilgisi domaine ait WHOIS bilgileri ile aynı olmalıdır.

Organization: Kurumun ticari unvanı

Organization Unit: Departman

Common Name: Kullanılmak istenilen domain adresi

Country/Region: Ülke kodu (TR)

State/Province: İl

City/Locality: İlçe

CSR dosyası RA’ya gönderilecek şekilde hazırlanmıştır;

2 - Sertifika Talebinde Bulunulması

Üretilen CSR ile sertifika talebinde bulunulur. CSR’ın RA’ ya iletilmesi ile birlikte bir başvuru formu doldurulması gerekmektedir. Bu formda teknik sorumlu kişinin iletişim bilgileri ve fatura/kurum bilgileri yer alır. Kurum içerisindeki yetkili yöneticinin onayı ile RA’ya bu form gönderilir. Yönetici onayında CA tarafından sunulan abonelik anlaşmasının okunup, onaylandığı taahhüt edilir. Talep formuyla birlikte aşağıdaki belgeler RA’ya iletilir:

·         Kurumsal sicil kaydı (özel şirketler için ticari sicil gazetesi) fotokopisi

·         Kurum yetkilisine/yetkililerine ait imza sirkülerinin fotokopisi

·         Sunucu (SSL) sertifikasının bedelinin ödendiğine dair banka dekontu

·         Kurumun, sunucuya ait alan adına sahipliğini gösterir belgenin örneği

Bu mekanizma onaycı kurumlar arasında işleyiş sırası olarak farklılık gösterebilir. Bazı kurumlar başvuru için talep yazısı istemekte, ardından CSR ile başvuru formunu istemektedir.

3 - Kurum Bilgilerinin Doğrulanması

RA, kendisine iletilen belgeleri kontrol edip doğrulanmasının ardından gerekli bilgileri CA’ya gönderir. CA, başvuran kişi/kurumun Public Key' inin Hash’ ini alıp kendi Private Keyi ile şifreler (imzalar). Yani, dijital imza Public Key Hashi’nin CA’in Private Keyi ile şifrelenmesidir. CA, başvuruyu yapan kişi/kurumun Public Keyi ve ve bu Hash’i kullanarak sertifika üretir[1].

4- Sertifikanın Sunucuya Yüklenmesi

Microsoft Yönetim Konsolu (mmc) ‘den Internet Information Services (IIS) Manager açılır. Bu bölümde CSR oluşturmada ilerlenen adımlar izlenir.

Default Web Site üzerinde Properties denilerek Directory Security sekmesine geçilir. Burada Secure Communications altında Server Certificate seçilir.

Sihirbaz başlatılır.

Process the Pending Request and Install the Certificate seçilerek devam edilir.

CA tarafından teknik sorumluya ulaştırılan sertifika seçilerek yükleme işlemi tamamlanır.

5- Sertifika Temininin Ardından Yapılması Gereken Adımlar

Üretilen sertifika RA tarafından teknik sorumlu kişi ile paylaşılıp yüklenmesinin ardından teknik sorumlu bu adımda sertifikayı yedeklemeli ve güvenli bir harici depolama ortamında saklanmalıdır.

IIS yüklü bir sunucuda sertifikanın yedeklenmesi

Microsoft Yönetim Konsolu (mmc) ‘den Certificates açılır.

Computer Account seçilir.

Local Computer seçilerek işlem tamamlanır

“Add/Remove Snap-in” penceresini kapatmamızın ardından Console Root" altında, Certificates (Local Computer)">Personal>Certificates" da sertifikayı görebiliriz.

All Tasks>Export denilir;

Sihirbaz başlatılır;

Private key ile birlikte export edilir;

“Include all certificates in the certification path if possible" ve "Enable strong protection” seçilerek devam edilir.

Sertifika dosyasını güvenli olarak saklamak için bir şifre girilir. Bu şifre import edilme işlemi sırasında sorulacaktır.

Yedek dosyasına isim verilerek işlem tamamlanır.

Bu yedek dosyası kullanılmak istenildiğinde import edilmesi yeterli olacaktır. Gerekli root sertifikalar ve private-public key bu dosya içerisindedir.

NSM(Network and Security Manager),birden fazla netscreen güvenlik cihazının tek bir elden yönetilebilmesini sağlayan bir programdır. NSM üzerinden cihaza bir şekilde Read only erişim yaptıktan sonra, aşağıdaki menülerden get config komutu ile cihaz üzerindeki kullanıcılara ait kullanıcıadı ve hashli şifre bilgisini alabilirsiniz.

Configure/Devices menüsünden ilgili cihaz seçilip, cihaz üzerine sağ click yapılarak Troubleshoot menüsünden komut koşturulucak arayüze aşağıdaki gibi ulaşılabilir.

Bu arayüzde aşağıda görebileceğiniz ve yetkiniz dâhilinde set ve get komutları koşturulabilir. Sol menüdeki hazır komutlar seçilerek veya netscreen komutlarına hâkimseniz farklı komutlar verilerek execute command demeniz yeterli. Get config komutu ile cihaz üzerindeki kullanıcı bilgileri dahil tüm konfigrasyon alınabilir.Read only bir hesap ile NSM'e eriştiyseniz yalnızca get komutlarını koşturabileceksiniz buda sizin hash bilgisini almanıza yetecektir zaten.

Bir netscreen firewall'u üzerinde komut satırından veya NSM üzerinden get config komutu koşturulduğunda aşağıdaki gibi bir çıktı ile karşılaşacaksınız. Bu bilgileri kullanacağız. Buradaki bilgiler ile boşu(boşu)na uğraşmayın bu arada :)

Biz şifre kırma çalışmamızda JTR üzerinden oluşturduğumuz hash'i kullanacağız. Öncelikle gerçek bir netscreen ürününün kullandığı özel hash algoritması(NS MD5) ile aynı algoritmayı kullanarak hash'lenmiş şifreye sahip bir örnek kullanıcı hesabı oluşturacağız.Bu hesap gerçek bir netscreen ürününün verdiği çıktıyı elde etmek için oluşturulacaktır.Bu özel kulanıcı hesabımızı(kullanıcıadı/şifre) JTR desteği ile nasıl oluşturulabileceğini ve ardından nasıl kırılabileceğini anlatmaya başlayalım.

Backtrack işletim sistemi üzerinde, öncelikle john komutunu koşturuyoruz.Böylece sistem bizi ilgili dizine gönderiyor.

Daha sonra netscreen ürünlerinin kullandığı hashing algoritması(NS MD5) ile aynı algoritmayı kullanıp bir user account oluşturalım. Bunun için python dilinde yazılmış netscreen.py scriptini kullanıyoruz.

Aşağıdaki örneğimizde deneme kullanıcı adına ve password parolasına sahip bir user account oluşturduk. Parolamız netscreen ile aynı algoritma ile şifrelenecektir."$ " işaretinden sonraki "n" , ve satır sonundaki "n" karakterleri netscreen hashing algoritması kullanıldığını gösteriyor.Burada "$" işaretinden öncesi kullanıcı adı bilgisini, sonrası ise kullanıcının password hash bilgisini verir.

Netscreen firewall'u üzerinde gerek CLI(Command Line Interface) gerekse NSM üzerinden(yukarıda anlattığım gibi) get config komutu ile gerekli account bilgileri(username ve password hash) alınabilir. Burada oluşturduğumuz account bilgilerini bir text dosyasına (netscreenhack.txt ) kopyalayalım.

Text dosyasını touch komutu ile oluşturuyoruz.

Şimdi text dosyamıza yukarıda oluşturduğumuz(veya netscreen cihaz üzerinden alacağınız) username ve password hash'ini kopyalayalım. Bunun için vi editörünü kullandık.

Şimdi vereceğimiz komut ile JTR, password.lst dosyasındaki tüm kelimeleri netscreen hashing algoritması ile hashleyip daha sonra tek tek bizim oluşturduğumuz netscreen.txt içerisindeki hash ile aynı hash olup olmadığını kıyaslayacaktır.Eğer eşleşmeyi sağlayabilirse(bunun için güçlü bir word list verilmeli), bize kullanıcı ve parola bilgisini aşağıdaki gibi verecektir.

Örneğimizi, deneme kullanıcı adına sahip bir kullanıcının password isimli şifresini kırarak anlatmaya çalıştım. Bu herhangi bir netscreen ürünü üzerinden alınan kayıt içinde yapılıp netscreen ürününün üzerindeki kullanıcıların hesapları kırılabilir. En büyük avantajı ise bu işlemi offline olarak gerçekleştirebiliyor olmamız.

Bu arada wordlist içersindeki her kelimenin hash'inin alınıp karşılaştırması işleminden dolayı işlem biraz uzun sürebilir. Bu işlemin daha hızlı gerçekleştirmesini isterseniz internet üzerinden rainbow table olarak adlandırılan hazır hash'ler bulunarak bunlar ile de crack işlemi gerçekleştirilebilir.

Çıktıdan da görüleceği üzere burada kullanılan hashing algoritması özel bir MD5(NS MD5) hashing algoritmasıdır.

Alias, Linux işletim sistemlerinde kendi girdiğiniz kelimeyle komut satırında istediğiniz komutu çalıştırmanıza yarayan oldukça hoş bir Linux komutudur. Kendi komutunuzu oluşturmanıza izin veriyor. Mesela her gün girmeniz gereken uzunca bir komut var ama bunu her gün yazmak istemiyorsunuz. Bunu yazacağınız tek kelime ve ardından enter ile halledebilirsiniz. Yine aynı işlemi fonksiyon yazarak da gerçekleştirebilirsiniz. Örneklerle konuya açıklamaya ve daha sonra güvenlik tarafında nasıl kullanılabileceğine değineceğim.

Program kurulumu:

Her seferinde program kurmak için sudo apt-get Install programadi şeklinde bir komut yazmak yerine kur programadi şeklinde bir komut girmek isteyebilirsiniz. Bunun için şöyle bir alias tanımlayabilirsiniz.

Şimdi snort kurmak istiyorsanız gireceğiniz komut aşağıdaki gibi:

Aynı işlemi shell fonksiyon yazarak oluşturalım:

Browser ile gezinme:

Networkpentest.net web sitesine girmek istiyorsunuz, komut satırından "pentest" demeniz yeterli olacaktır. Bunun için yazılacak alias aşağıdaki gibidir.

Şimdi siteye gitmek istiyorsanız yapacağınız komut satırına pentest yazmak.

Aşağıda görüldüğü gibi istediğimiz sayfa browserda açılacaktır.

Şimdi aynı işlemi bir shell fonksiyonu oluşturarak yapalım;

SYN Flood Tespiti:

Biz olaya güvenlik tarafından yaklaşalım. Syn flood saldırısı alıp almadığınızı test etmek için "netstat -ant | grep SYN_RECV" komutunun yerine komut satırına "saldırıvarmı" yazıp sonuçlarını görebilirsiniz.

Bundan sonra komut satırında saldirivarmi yazıp sonuçlarını görebilirsiniz. Bizde herhangi bir Syn flood atağı olmadığı için sonuç temizdir :) Aksi halde birçok SYN_RECV paketi ile karışılacaktık.

Şimdi aynı komutumuzu bu sefer shell fonksiyon yazarak oluşturalım:

Syn Trafik Kaydı:

Şimdi de saldırı anında paket analizi için kullanabileceğimiz küçük bir örnek olan, sunucumuz üzerindeki tüm gelen giden SYN paketlerini tcpdump ile yakalayıp networkpentest dosyasına kaydeden komutu alias ile oluşturalım, alias' ın ismine de synyakala diyelim.

Şimdi de komutu koşturalım;

Aynı işlemi şimdi shell fonksiyonu yazarak oluşturalım:

NOT:

tcp[13]=2 Syn paketlerini yakalayabilmek için kullandık diğer paketler için şunlar kullanılabilir.

tcp[13]=1 ==>> Fin için

tcp[13]=4 == >> Rst için

tcp[13]=8 ==>> Psh için

tcp[13]=16 ==>>Ack için

tcp[13]=32 ==>>Urg için

tcp[13]=18 ==>> SYN + ACK

tcp[13]=6 ==>> SYN + RST kullanılabilir.

HTTP GET Flood Tespiti:

Http GET flood saldırısı aldığımızı düşünelim. Sistemimize gelen http get isteklerini ve hangi hosttan geldiğini tespit eden bir alias oluşturup httpgetyakala ismi ile çağıralım.

Sonuçlarına bakalım;

Aynı komutumuzu bir shell fonksiyon yazarak çağıralım:

Tüm sisteminiz üzerindeki mevcut oluşturulmuş alias'ları görebilmek için alias -p komutu aşağıdaki gibi girilebilir.

İstediğiniz herhangi bir mevcut alias'ı silmek için unalias isim şeklinde bir komut koşturulabilir.

Görüleceği gibi aşağıda saldirivarmi aliasımız artık yok.

İşin alias kısmı oldukça kolay ve kullanışlı. Shell function kısmı ise programlama dilleri seviyesinde derinleştirilebilir. Komplex uygulamalar oluşturulabilir. Ben yüzeysel olarak konu için önemli kısmı üzerinde durdum.

Shell fonksiyon oluşturma işlemlerini bir text editörü aracılığı ile açılan bir dosyada da yazabiliriz. Daha sonra yazdığımız script ile aynı dizinde olmak şartı ile ./komut şeklinde çalıştırıp çıktıyı görebiliriz. Bizim komutlarımız bash script üzerinde yorumlanmaktadır. Diğer programlama dilleri(Pyhton,perl,awk v.s) scriptlerimizi de bu şekilde çalıştırabiliriz.

Bu komut oluşturma işlemleri, nerede işimize yarıyabilir? Özellikle saldırı alınan durumlarda, zaman bizim için oldukça kıymetli olacaktır. Gerekli tetkikleri, alınacak network paket kayıtları veya aktif edilecek snort imzaları vs. birçok işlem için bize zaman kazandırabilecektir. Ayrıca komut satırından girilecek tüm komutları Türkçeleştirebilirsiniz. Veya yapılması tehlikeli olan remove komutları vs.(rm -rf) şeklinde yanlışlıkla silinebilecek komutlar girildiğinde bunlar rm -i şeklinde icra edilmesi ve yapılacak işlem için bize onay verdirilmesi sağlanabilir.

Bundan sonrası hayal gücünüze kalmış :)

Metasploit aracı hackerlar ve pentest uzmanları tarafından en sık başvurulan araçların başında gelmektedir. Sistemler üzerinde zafiyet bulmada veya bulunmuş zafiyetleri exploit etmede kullanılır. Amaç hedef sistemler üzerinde root yetkilerinde erişim kazanmaktır. Metasploit framework' ü, zafiyet tespit aracı olan Nessus çıktılarını da destekleyen en gelişmiş vulnerability exploiting aracıdır.

Bu yazımda, Ssh server çalışan sistemlere yönelik bruteforce attack için metasploit kullanımını anlatacağım. Bilindiği gibi bu tarz pentest çalışmalarını yapan medusa ve hydra gibi araçlarda oldukça başarılıdır. Bu araçlar bir başka yazıma bırakıp metasploit ile devam etmek istiyorum.

Metasploit exploiting aracı Backtrack üzerinde kurulu olarak gelmektedir. Öncelikle aşağıdaki şekilde metasploiti başlatalım.

Programı başlatırken /pentest/exploits/framework3 dizinine girip ./msfconsole komutu ile de başlatabiliriz.

Şimdi ssh bruteforce için kullanacağımız ssh modülü altındaki ssh_login scriptini kullanacağımızı belirtelim.

İnfo komutu ile bu script hakkında bilgi edinebiliriz. Burada hangi parametrelerin ne işe yaradığı detaylı bir şekilde açıklanmıştır. Aynı amaç için show options komutu da koşturulabilir.

Şimdi Ssh bruteforce saldırısı gerçekleştireceğimiz sistemleri, kullanılacak username ve parola listesini belirtelim. set RHOST komutu ile hedef sunucu veya sunucular belirlenir. Eğer bir subnet belirtilecek ise 192.168.2.0/24 şeklinde kullanılabilir. USER_FILE ve PASS_FILE ile username ve parolaların belirtilen dosyalardan alınması sağlandı. Burada PASSWORD ve USERNAME kullanılarak yalnızca belli bir kullanıcı adı ve şifre ile de test yapılabilirdi.

Şimdi artık bruteforce saldırımızı başlatabiliriz. Exploit’i çalıştırmak için exploit veya run komutlarından herhangi biri kullanılabilir. Her ikisi de aynı işlevi gerçekleştirecektir. Biz exploit komutunu verdik ve aşağıda göreceğiniz üzere tüm kullanıcıadı-parola çiftleri deneniyor.

USER_FILE olarak belirttiğimiz user dosyasındaki tüm kullanıcı isimleri, PASSWORD_FILE olarak belirttiğimiz pass dosyasındaki tüm şifrelerle eşleştirilip login olma isteğinde bulunuluyor. Bu arada ssh server kurulu sistem üzerinde login sınırlaması varsa metasploit buna takılmadan denemelerine devam edebiliyor. Bu da güzel bir özelliktir. Metasploit başarılı bir şekilde bulduğu kullanıcı adı ve şifre ile sistemde bir session açıyor. Başarılı bulduğu kullanıcı adı şifre aşağıdaki gibidir.

Şimdi mevcut sistem üzerinde session açılmış mı ona bakalım. Tüm sessionları listelemek için sessions komutunu vermek yeterli.

Session ID 1 olan bizim kırdığımız sistem üzerinde oluşturulan session' dır. Şimdi sıra ile uzak sistem üzerinde şu işlemleri yapalım:

session -i 1 komutu ile uzak sistemin komut satırını alalım

ifconfig ile ele geçirdiğimiz sistemin IP'sinin geldiğini görelim

ls -la /etc/passwd ile /etc/passwd dosyasının erişim bilgilerini görelim

uname -a ile sistem bilgisinide alalım.

Bir sonraki makalemizde görüşmek üzere.

Öcelikle Metasploit hakkında biraz bilgi verdikten sonra, Metasploit projesinin en önemli parçası olan Metasploit Framework’ünü kullanarak uzak sistemler üzerinde pentest amaçlı nasıl işlemler gerçekleştirilebileceğini örnekler ile anlatacağım.

Open source bir araç olan Metasploit , Perl programlama dilinde yazılmaya başlanmış fakat daha sonra Ruby dili ile sil baştan tekrar geliştirilmiş bir zafiyet tesbit ve exploit aracıdır.Hackerlar,antivürüs geliştiricileri ve pentest uzmanlarının olmazsa olmaz araçlarının başında gelmektedir. Metasploit, set edilen payloadların encode edilerek sistemlere gönderilebilme özelliği ile IPS/IDS gibi saldırı tespit ve engelleme sistemlerini atlatarak,Antivirüs ve personal firewallara takılmadan uzak sistemler üzerinde çalıştırabilme özelliğine de sahiptir.

Metasploit ile çalışmak için temel olarak şu 3 adım gerçekleştirilmelidir:

·         Hedef sistem işletim sistemi üzerinde çalışacak uygun exploitin tesbiti ve gerekli konfigrasyonunun yapılması

·         Uygun payload’un belirlenmesi ve konfigrasyonunun yapılması

·         Exploit işleminin gerçekleştirilmesi.

Meterpreter ise, Metasploit Frameworkü’nün sahip olduğu bir çok payloaddan yalnızca biridir. Komplex bir yapısı olmasına rağmen en yararlı payload olduğu kanaatindeyim . Genellikle uzak sistemler üzerinde download ve upload işlemleri ve uzak sistemlerin ekranlarını VNC gibi kontrol sistemleri ile kontrol etmek için kullanılır.Fakat tabi ki meterpreterin yetenekleri bunlarla sınırlı değildir.Aşağıda meterpreter ile yapılabilecek bir çok çalışmanın nasıl yapılabileceğine değindim. Ayrıca daha iyi anlaşılması ve ne ile karşılaşılacağının görülebilmesi açısından verilen komutların, çıktılarını da makaleye ekledim.

Biz tüm makalemiz boyunca psexec exploitini ve meterpreter payloadunu kullanacağız.Psecec exploitini sistemi ele geçirmek için meterpreter payloadunu ise ele geçirilen uzak sistem üzerinde kontroller ve önemli bilgilerin ele geçirilmesi için kullanacağız. Psexec exploiti, Windows işletim sistemine sahip uzak bir sistem üzerinde bilinen bir kullanıcı adı ve şifre ile oturum açma işlemini gerçekleştirmektedir.Bunun için 445 SMB portunun açık olması gerekmektedir.

Bu kadar bilgininin ardından vakit işe koyulma vakti : ) Şimdi metasploit frameworkünü consoldan çalıştırmak ile işe başlayalım. Bunun için aşağıdaki komutu sistemimize verelim.

Metasploiti çalıştırdıktan sonra aşağıdaki gibi use komutu ile,belirtilen path’deki psexec exploitini kullanarak,uzak bir sisteme erişim sağlayamak istiyoruz. Psexec ile ilgili kullanılacak ve değer atanmış/atanacak parametreler show options komutu ile metospoloit üzerinde görülebilir. Aynı şekilde info ve show advanced komutları da aynı işi görecektir.

Görüleceği üzere RHOST,SMBUser ve SMBPass parametrelerinin current setting kısımları şuan boş duruyor,bunlara gerekli değerleri atamalıyız.

Uzak bağlantı yapacağımız sunucunun IP'sini RHOST parametresine atıyoruz. Aynı şekilde SMBUser ile sistem üzerindeki bir accounta ait kullanıcı adı ve SMBPass parametresi ile de uzak sistem üzerinde aktif accounta ait parola bilgisini atıyoruz. Accountun hesap bilgilerinin nasıl ele geçirildiği bu yazımın konusu olmadığı için oralara değinmiyorum.

İlgili parametrelere değerleri belirtildikten sonra sıra bu exploiti çalıştırmaya geldi. Exploit komutu ile psexec exploitini çalıştırıyoruz. Run komutu da exploit komutu yerine aynı amaç için kullanılabilirdi.

Not: Metasploitde bir exploit kullanılmak isteniyorsa use komutundan sonra exploitin path’ini belirtmemiz ve daha sonra uygun parametreler ile gerekli ayarları yapmamız yeterlidir. Exploiti çalıştırmak için ise run veya exploit komutlarının biri koşturulmalıdır.

Evet artık meterpreter satırına kavuştuk. Farkettiyseniz yukarıda payload set etmedik.Bunun sebebi psexec zaten bizim yerimize meterpreter payload’unu uzak sisteme uploat etti.Fakat bunu yaparken default olarak 4444 local portunu kullandı.Bu ve bazı default değerleri manuel girmek isterseniz payload’u set etmek için set PAYLOAD windows/meterpreter/reverse_tcp şeklinde bir komut verdikten sonra yukarıda yaptığımız gibi LHOST,LPORT v.s gibi parametrelere değerleri atamanız gerekecektir. Bundan sonra bir sonraki adıma geçebilirsiniz.

Bundan sonrası uzak sistem üzerindeki atraksiyonlardan oluşan oldukça zevkli bir bölüm.Şimdide uzak sistem üzerindeki networksel ( interfaceler ,IP,Netmask , Gateway v.s) ayarları görmek için ipconfig –a komutunu koşturmakla işe başlayalım.

Meterpreter ile uzak sistem üzerinde sysinfo komutu ile uzak sistem üzerindeki sistem bilgilerini özetle alabilirsiniz.

Sistem üzerinde hangi yetkilerde erişim yaptığınızı görebilmek için getuid komutu koşturulabilir.Görüldüğü üzere System yetkilerinde erişim sağlanmış görünüyoruz.

Getpid komutu ile ise mevcut sistem PID değeri alınabilir.

Uzak sistem üzerinde etkin Process privilegets görebilmek için getprivs komutu koşturulabilir.

Uzak sistem üzerinde herhangi bir komut çalıştırmak istiyorsak bunu execute komutu ile gerçekleştirebiliriz. Basit kullanımı aşağıdaki gibidir.

Uzak sistemde bu komutla aynı anda aşağıdaki gibi bir ekran görüntüsü alacaktır.

Burada iletiyi görüntüle derseniz , başlat/çalıştıra "cmd" yazmışsınız gibi bir adet komut satırı görüntüleyecektir .Bu da komutun uzaktan sistemimiz de çalıştırılabildiğini bize gösteriyor.

Execute komutunu biraz daha profesyonel kullanıp aşağıdaki gibi uzak sistem üzerinde komut koşturulup ve çıktısının yani komut satırının bizim ekranımızda görüntülenmesi ve buradan çalışmalar yapılabilmesini sağlayalım.

Görüldüğü üzere uzak sistemde execute komutu bir komut koşturarak mevcut sistemin command promtunu elde ettik.Aynı işlemi shell komutu verilerek de yapılabilirdi.

Uzak sistemdeki Event logları silmek için aşağıdaki komut koşturulabilir.

Veya mevcut tüm event loglarının silinmesi için aşağıdaki komutu da kullanabiliriz.Aşağıdada görüleceği üzere çeşitli kategorilerdeki(application,hardware event,internet explorer,key management service,event log media center,Odiag ,Security v.s) tüm event loglarını silmektedir.Bu da bir pentestçinin veya hackerların sistemlere sızdıktan sonraki son aşamalarından olan Clear track aşamasındaki izlerin silinmesi için kullanılabilir.

Meterpreter ile uzak sistemin mevcut masaüstü görüntüsünün bir screenshotu kolaylıkla alınabilir.Bu işlem için screenshot komutu bizim işimizi görecektir.Kullanımı aşağıdaki gibidir.

-p ile kaydedilmesi gereken path bilgisini belirtiyoruz ve -q ile jpeg resmimizin kalite değerini giriyoruz. Kaydettiğimiz uzak makinanın screenshot görüntüsü ise aşağıdaki gibi olacaktır.

Meterpreter ile ele geçirilen uzak sistemler üzerinde etkin olan mikrofonun kontrolü kolaylıkla ele geçirilebilir.Mevcut ortam dinlemesi yapılabilir.Buna örnek olarak uzak sistemdeki mikrofondan bir dakikalık sesin nasıl kaydedilebileceğini gösterdim.

-d parametresi ile kaç saniye kayıt yapılacağını belirttik ve -f ile ise yapılan kaydın hangi isimde nereye kaydedileceğini belirttik.

Görüldüğü gibi seskaydi.wav dosyamız root dizini altındadır.Herhangi bir wav oynatıcı programı ile kayıt dinlenebilir.

Sistem üzerindeki mevcut web kameraların belirlenmesi ve etkin olan kameradan belli bir miktar görüntü(snapshot) alınması için ise aşağıdaki gibi bir komut verilmelidir.Bizim sistemimizde kamera olmadığı için çıktısını göstermeden geçiyorum.

Kameradan snapshot görüntü almak için ise aşağıdaki gibi komut koşturulabilir.

Burada "-p /root/" görüntünün kaydedileceği path bilgisi, "-q 60" kaydın jpeg olarak kalitesini ifade eden bilgi, " -v false" ise kaydın komut durur durmaz otomatik olarak açılmaması için verilen parametre değeridir.

Uzak sistemdeki çalışılan dizin bilgisini öğrenmek için pwd komutu kullanılabilir.

Uzak sistem üzerinde dizin değiştirmek için ise cd komutu kullanılabilir.

Local sistemdeki çalıştığımız dizini öğrenmek için local pwd anlamında lpwd kullanılabilir.

Yine local sistemde dizin değiştirmek için ise lcd komutu kullanılabilir.

Sistemi keylogger ile adım adım izlemek için run keylogrecorder komutu verilebilir.Bu arada run, meterpreter scriptlerini çalıştırmak için kullanılan bir komuttur.Meterpreter scriptlerini /opt/framework/msf3/scripts/meterpreter altında bulabilirsiniz.Şimdi ele geçirdiğimiz sistemde keylogger çalıştıralım.

Belirtilen dosyaya neler kaydedildiğine bakalım:

Görüldüğü gibi klavyeden basılan her tuş kaydedilmiştir.Burada <Return> ile belirtilen enter tuşuna basılması durumudur. <Tab> isminden belli olduğu üzere tab tuşu ile bir geçiş yapıldığını göstermektedir.

Ele geçirilmiş sistem eğer windows ise bu sunucuyu enumurate etmenin en güzel yolu winenum.rb scriptini kullanmakdır.Bu meterpreter scripti kullanılarak bir çok windows komutunu aynı anda sistem üzerinde koşturulması ve bunun sonuçlarının bir dosyaya yazdırılması sağlanabilir.Komutun verilmesi,sistemde koşturulan komutlar ve sonuçların kaydedildiği dosya ile birlikte sonuçların belirtildiği ekran görüntüsü aşağıdaki gibidir:

Yukarıda belirtilen text dosyasında belirtilen tüm komutların çıktısı görülebilir.Tek komutla sistem üzerinde bir çok konuda bilgi sahibi olunması açından çok değerli bir script.

Uzak sunucuya dosyayı veya tüm bir klasörü upload etmek için,upload komutu aşağıdaki gibi kullanılabilir.Yukarıda aldığımız ekran görüntüsünü(screen.jpg) uzak sistemin D:\hacked\ dizini altına upload edelim.

Uzak sistemi kontrol edelim bakalım gerçekten screen.jpeg resmimiz başarılı bir şekilde upload edilmiş mi ?

Görüldüğü üzere mevcut resmimiz D:\hacked dizini altına gelmiş.

Şimdi ise uzak sistemden bir dosyayı veya klasörü local sistemimize nasıl download edebiliriz ona bakalım.

Şimdi de dosya bize ulaşmış mı kontrol edelim.

Görüldüğü gibi white_list_ip.xls isimli dosyayı download ettik.Aynı yöntemle belli bir klasör ve altındaki tüm dosyaları da download edebilirsiniz.

Uzak sistem üzerinde çalışan tüm uygulamaların ve bu uygulamaların versiyon bilgilerini elde edebilmek için aşağıdaki meterpreter scripti kullanılabilir.

Sistemdeki tüm uygulamaları ve bunların versiyonlarını tesbit eden oldukça hoş bir scripttir.Ben tüm sonuçlarını yukarıdaki ekran görüntüsünde göstermedim,fakat bu script sistemde ne var ne yok her programı versiyon bilgileri ile birlikte önümüze döküyor.

Uzak sisteme RDP yapmak için yeni bir account oluşturabilmek için aşağıdaki script kullanılabilir .Scripte parametre olarak verdiğimiz kullanıcı adı ve şifre ile artık uzak sisteme RDP bağlantısı da yapabiliriz.Mevcut bağlantıyı artık kullanmak istemediğinizde aşağıda belirtilen komut koşturulup oluşturulan account devre dışı bırakılabilir.

Sistem üzerindeki tüm kullanıcıları ve bunların parolalarının hashlerinin ele geçirilmesi için aşağıdaki komut koşturulabilir.

Burada dikkatten kaçmayan,ele geçirilen sistem üzerinde SysKey parolası aktif olmasına rağmen onun da hash bilgisini tesbit edebilmiş olması önemli.Bu özellikleri ile meterpretere aşık olmamak elde değil :)

Yukarıda görüldüğü üzere sistemdeki tüm kullanıcı adları ve şifrelerin hashli halleri dump edildi.Ele geçirilen bu NTLM hashleri JTR benzeri toollarla kırılarak şifrelerde ele geçirilebilir.Veya şifreye ihtiyaç duymadan mevcut kullanıcı adı ve şifrelerin hashli halleri ile de sistemlere login olunabilir.

Uzak sistemin host dosyasını zehirleyerek,bu sistem üzerinden internette çıkan kullanıcının gerçek DNS sunuculara gitmeden localdeki zehirlenen host dosyası ile isim çözümlemesine maruz bırakılıp, kullanıcıyı başka sahte sayfalara yönlendirilebilir. Bizim örneğimizde kullanıcı facebook.com sitesine gitmeye çalışırken cnn.com sitesine gidecektir.

Kötü amaçlı kullanımlarla phishing saldırıları ile account bilgileri veya bankacılık erişim bilgileri ele geçirilebilir.

Uygulamamıza öncelikle fakehost.txt isimli bir dosya oluşturup içerisine aşağıdaki gibi iki satırı ekleyerek başlayalım. Burada 157.166.224.25 IP'si cnn.com sitesine ait IP adresidir.Kullanıcının host dosyasını değiştirerek facebook yerine kullanıcının cnn web sitesine gitmesini sağlayalım.

Şimdi de bu fakehost.txt dosyasının içeriğini uzak sistemdeki windows sunucunun host dosyasına inject edelim.Script öncelikle mevcut host dosyasının yedeğini alıyor daha sonra bizim verdiğimiz satırları host dosyasına ekliyor.

Evet hepsi bu kadar.Şimdi ele geçirilen sunucuda facebook sayfasına login olmaya çalışalım bakalım ne ile karşılaşacağız.

Görüldüğü üzere ele geçirilen uzak sistemin host dosyası başarı ile değiştirilmiştir ve kullanıcı facebook.com sitesine gitmek istediğinde bu domaine ait isim çözümlemesi DNS sunucudan önce host dosyası tarafından çözüldüğü ve host dosyasını da biz zehirlediğimiz için kullanıcı facebook.com yerine cnn.com web sitesine girmiştir.

Host dosyasının içeriği ise aşağıdaki gibidir.Host dosyasına C:\Windows\System32\drivers\etc\ dizininden erişebilirsiniz.

Buradan da görüleceği üzere gerçekten host dosyası hostedit ismindeki meterpreter scripti ile değiştirilmiştir.

Meterpreter çoklu script çalıştırılmasına izin vermektedir.Bunun için multiscript isimli bir scripte bir dosyadan okutularak script listesi verilerek,bu listedeki tüm komutların tek komut ile execute edilmesi sağlanmış olur. Örnek ile anlatmaya çalışayım.Öncelikle içerisinde icra edilmesi gereken scriptlerin isimlerinin olduğu commands.txt isimli bir text dosyası oluşturuyorum.

Şimdi bu commands.txt dosyasını parametre olarak alıp işleyecek multiscript isimli scriptimizi çalıştıralım.Böylece tek seferde listedeki tüm scriptleri çalıştırmış olacağız.Sonuçlarına birlikte bakalım.

Listemizdeki 3 adet scripti dosyadan okutarak tek seferde execute ettirmiş olduk.

Bir sonraki makalemizde görüşmek üzere.

Rezervasyon nedir (Reservation) ?

Otomatik ip almaya ayarlanmış client’a (DCHP Client) hep aynı ip’ yi otomatik olarak atamak demektir. IP rezervasyonu makina üzerindeki ethernet’ in mac adresine atanır.

Bu sayede clientlarımıza tek tek el ile ip atamak zorunda kalmayız. IP Adreslerinin kira süreleri sona erdiğinde firewall’umuz da IP bazlı oluşturduğumuz kurallar da yetkili/yetkisiz isteğimiz dışı hareketlere maruz kalmamış oluruz. Kısacası denetimi tam anlamıyla elimize almış oluruz.

Örn Mac: 00:1E:64:6D:75:DC

Tabi kullanıcılar her zaman zekidirler ve hep açık bir kapı arayışı içindedirler. Giremediği sitelere erişim sağlayabilen bir ip adresi öğrenen zeki kullanıcımız, ip adresini manuel olarak bu ip ile değiştirirse gayesine ulaşmış olacaktır. Bu nokta da güzel bir özellik olan MAC/IP Binding devreye girer.

Birçok UTM Cihazda olduğu gibi WatchGuard ürünümüzde de “MAC/IP Binding” yönetimi bulunmaktadır. Peki nedir bu MAC/IP Binding ?

Firewall kuralları genellikle ip adreslerine göre oluşturulur. Yetkiler ve kısıtlamalar da tanımlanan bu ip adresleri bazında yapılandırılır. Tabi ki oluşturulan bu kuralların doğru çalışması için de kişilerin ip adreslerinin değişmemesi gerekmektedir. (Akıllı kullanıcılar) Yetkisi kısıtlanmış bir kişi daha fazla yetkiye sahip bir IP adresini kullanarak istenmeyen erişimleri gerçekleştirebilir. Bu durumu engellemenin yönetimi de MAC/IP Binding ten geçmektedir.

Öncelikle IP Rezerve nasıl yapılır?

Öncelikle IP Rezervasyonunu WatchGuard üzerine yapabilmek için DHCP mizin WatchGuad olması gerektiğini unutmamak gerekir.

Policy Manager‘ımızı açarak Network -> Configuration menüsüne giriyoruz.

IP Adresini rezerve edeceğimiz Trusted Interface‘imizi seçerek Configure ediyoruz.

10.0.0.2 – 10.0.0.200 olarak tanımlanan DCHP IP Havuzumuzdan 10.0.0.34 olan IP adresimizi gokhanvarol ismi ile Rezerve edeceğiz.

Reserved Addresses bölümüne geliyoruz ve Add tıklıyoruz.

10.0.0.34 IP Adresini gokhanvarol için rezerve ederek OK diyoruz.

Şimdi sırada 10.0.0.34 nin sadece 00:1E:64:6D:75:DC MAC Adresine ait olduğunu cihazımıza belirtmeye geldi. Bunun için aynı penceredeki Advanced sekmesine geçiyoruz.

Advanced sekmesine Static MAC/IP Address Binding bölümünde Add tıklıyoruz.

Karşımıza çıkan pencerede bakicubuk ismine atadığımız IP adresi 10.0.0.34 ve Client’ın sahip olduğu 00:1E:64:6D:75:DC MAC adresini giriyoruz.

İşlem görüldüğü üzere WatchGuard ile çok kolay bir şekilde sonuçlanıyor.

Ayarlarımızı WatchGuard üzerine kaydettikten sonra etkin olacaktır.

Juniper firmasına ait bir işletim sistemi olan JunOS yeni nesil Juniper ürünlerinin tümünde kullanılır. Bu ürün yelpazesinde firewall, switch, router gibi cihazlar yer alır. Dolayısıyla JunOS işletim sisteminin çalışma ve komut mantığını anlamak bu ürün yelpazesinin yönetiminde gerekli bilgiyi ve tecrübeyi sağlayacaktır. Bu makale dizisinde, işletim sisteminin mantığını anlatmakla başlayıp firewall yapılandırmasıyla devam edeceğiz.

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.

Bu şekilde bir prosesin diğeriyle çakışmaması sağlanır ve proseslerden birisinde meydana gelen bir hata tüm sistemin çalışmasına engel olmaz.

JunOS işletim sistemli tüm Juniper ürünleri tek bir source code’a dayanan image’lar kullanır. Bu şekilde pek çok özellik ve servisin konfigürasyonu ve yönetimi aynı şekilde gerçekleştirilir.

Kontrol ve İletim Ayırımı:

JunOS mimarisi, Control Plane ve Forwarding(Data) Plane olmak üzere iki ayrı bölüm üzerine tasarlanmıştır. Bu mimari ile işletim sistemi JunOS olan ürünlerde, routing control ve protocols switching işlemleri Control Plane’de gerçekleştirilirken, frame’lerin ve paketlerin iletilmesi Forwarding(Data) Plane tarafından gerçekleştirilir.

Control Plane ve Forwarding(Data) Plane süreçlerinin tamamen ayrılması sayesinde her proses maksimum performansa ve verimliliğe ulaşır.

Control Plane denildiğinde Routing Engine(RE) akla gelmelidir. Zira Routing Engine(RE) Control Plane’in beynidir. Routing Engine protocol update’lerinden ve sistemin yönetiminden sorumludur.

Routing tables(RT), bridging table, ve primary forwarding table(PFT) olmak üzere üç table’da Routing Engine(RE) sorumluluğundadır. Routing Engine(RE) bir internal link sayesinde Packet Forwarding Engine(PFE) ile iletişim halindedir.

Packet Forwarding Engine(PFE), genellikle cihaz içerisinde ayrı komponentler üzerinde çalışır. Transit trafikten sorumludur.

Ve sorumluluğunu yüksek performansla gerçekleştirmek için uygulamaya özel entegre devreler kullanır.

Bu mimari ile, protocol güncelleştirmeleri ve sistem yönetimi gibi kontrol işlemleri, trafik iletim işlemlerinden ayrilır ve JunOS bu ayrı platformlar sayesinde yüksek performans sunar.

PFE, internal bir link aracılığıyla forwarding table’ı(FT), RE’den alır. FT güncellemeleri, JunOS OS kerneli için yüksek bir önceliğe sahiptir ve aşamalı olarak yapılmaktadır.

PFE’nin görevi frame ve paketlerin forward edilmesi yönünde RE’den aldığı talimatları istikrarlı ve performanslı bir şekilde yerine getirmektir. Bu mimari tasarım sayesinde high availability feature’larının birleştirilmesi mümkün olmaktadır. Örneğin

GRES, NSR ve ISSUs gibi.

Routing Engine(RE):    

 

Control Plane’in beynidir.

(Routing Table(RT) ve Forwarding Table(FT) ‘ı sağlar. Bütün protokol süreçlerinden sorumludur. Ayrıca interface’lerin kontrolü, chassis komponentleri, sistem yönetimi ve kullanıcıların cihaza erişim süreçleri gibi diğer süreçlerden de sorumludur.

Chasis’i izler ve kontrol eder. CLI ve Web GUI erişimleri de üzerinden sağlanır.

RE, PFE’yi yönetir. Layer2 ve Layer3 forwarding table’ı güncelleyerek PFE’yi kontrol eder. RE, hardware status mesajlarını PFE’den alır ve bu mesajlar sayesinde uygun hareketi belirler.

Packet Forwarding Engine(PFE):

PFE, forwarding plane’in merkezi işlem komponentidir.

Layer2 ve Layer3 forwarding table’ı RE’den alır ve bu table sayesinde trafiği hedefine iletir. PFE’nin kullandığı table, RE’den alınan forwarding table’ın bir kopyasıdır. Kaydedilen ve kullanılan bu tablo sayesinde trafik verimli bir şekilde hedefine iletildiği gibi, tablonun senkronizasyonu belirli aralıklarla gerçekleştirilerek sürekli RE’ye danışma ihtiyacı da ortadan kalkmış olur.

               
Policy’ler, Stateless Firewall Filtering ve CoS gibi hizmetler de PFE’i tarafından gerçekleştirilmektedir. Ayrıca PFE’ye farklı interface kartları monte edilerek ek hizmetler de verilebilmektedir.

JunOS ve Traffic Processing

1- Transit Traffic:

Lokal sistem tarafından iletilen trafiktir. Bir ağ noktasından giren ve Forwarding Plane’deki FT(forwarding table) ile karşılaştırılarak başka bir ağ noktasından çıkış yapan tüm trafiği ifade eder. Transit trafiğin, Forwarding Plane’den geçerek hedefe iletilmesi esnasında, Control Plane’e yani tuttuğu RE’ye herhangi bir sorgu gitmez ve bu sayede yüksek performans elde edilir. Belirli bir hedefe gitmek üzere Forwarding Plane’e gelen trafiğin, sadece Forwarding Plane’den geçerek hedefe gidebilmesi için, Forwarding Plane tarafından tutulan FT(forwarding table)’de hedef için bir kayıt/bilgi bulunması gerekmektedir.

2- Exception Traffic

Lokal sistem tarafından işlenen trafiktir ki hedefi lokal sistem olan bu trafik, Routing Engine(RE) CPU’su tarafından işlenir. Transit traffic sürecinin aksine, Exception Traffic, özel bir işleme tabi tutulur ve lokal sistem üzerinden geçerek herhangi bir hedefe gitmez. Yani Exception trafiği oluşturan paketlerin hedefi bizzat lokal sistemdir ya da paketlere dönen cevapların source’u Routing Engine(RE)’dir. Örneğin

- Routing protocol updates, Telnet sessions, pings, traceroutes işlemleri.

- Packet Forwarding Engine(PFE) IP header’ındaki option alanına müdahale etmeyecek şekilde tasarlandığı halde, header’da işlem yapılacaksa paket Control Plane’e yani RE’ye gönderilir.

- Pek çok hata durumunda PFE tarafından üretilen ICMP mesajları Exception Traffic örneğidir.

Exception Traffic Rate-Limit

JunOS işletim sistemi, tüm exception trafiği RE’ye gönderir. Forwarding Plane’den Control Plane’e (RE için) gönderilen exception traffic, internal link üzerinden geçmektedir. Internal link üzerinde oluşan trafiğin sıklığı, bir tıkanıklığa sebebiyet verip RE ile iletişimde kopma olmamasını sağlamak üzere Exception Traffic için rate-limit devreye girer. Built-in olarak gelen rate limiter konfigüre edilemez. Bir tıkanıklık anında JunOS OS tarafından hedefi RE olan trafik için preference atanır.

Hoşçakalın.

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ı,

- Control Plane ve Forwarding(Data) Plane isimli iki ayrı bölümden oluşacak şekilde tasarlanan JunOS mimarisinde, Control Plane denildiğinde Routing Engine(RE)’in, Forwarding(Data) Plane denildiğinde de Packet Forwarding Engine(PFE)’in düşünülmesi gerektiğini,

- RE’in, Control Plane’in beyni olduğunu, PFE’nin de Forwarding(Data) Plane’in merkezi işlem bileşeni olduğunu,

- JunOS işletim sistemli tüm Juniper ürünlerinin tek bir source code’a dayanan image’lar kullanması sebebiyle firewall, router ve switch gibi network/güvenlik cihazlarında pek çok özellik ve servisin konfigürasyon ve yönetiminin benzer şekilde gerçekleştirilebileceğini söylemiştik.

Yani JunOS işletim sistemli bir firewall’un CLI’ı ile JunOS işletim sistemli Router ve Switch’in CLI’ı çok benzerdir ve bu durum bizlere büyük bir yönetim avantajı sağlamaktadır.

Juniper JunOS İşletim Sistemi CLI Mimarisi başlıklı bu makalemizi oluşturacak çalışmalarımızı SRX High-End Serisi firewall’lar üzerinde gerçekleştireceğiz.

JunOS CLI’ı metin tabanlıdır ve ilk kez bağlanılmak istendiğinde konsol portu kullanılır. SRX Firewall’un RE CONSOLE başlıklı kısmında 0 ve 1 yazan portlardan 0 olanına RJ-45 uçlu bir ethernet kablosu takılır; kablonun diğer tarafı DB-9 serial dişi uçludur. SRX Firewall’a, Telnet ya da SSH yönetim protokolleri kullanan bir program kullanılarak erişilebilir.

Konsol portundan erişimde kullanılan programın parametreleri aşağıdaki gibi tanımlanmalıdır:

Factory default konfigürasyonlu bir SRX Firewall’a root kullanıcısı ile login olunur ki root’un da şifresi yoktur. SRX’e root ile login olunduktan sonra yapılacak ilk iş, root’a bir şifre atamak olmalıdır. Zira root kullanıcısı ile login olunduktan sonra yapılacak konfigürasyonlar kaydedilmek istendiğinde root’a şifre atanmadan konfigürasyon değişikliği yapılamayacağına dair uyarı mesajıyla karşılaşılır.

Root kullanıcısı ile konsol portu üzerinden login olunan bir SRX Firewall’da, bağlandığımız yer Unix shell’idir. (JunOS, FreeBSD üzerinde geliştirilmiştir.) Ekranda şu satırlar görülecektir:

root@host%

Sondaki % işareti Unix shell’inde olduğumuzu ifade etmektedir. JunOS CLI’ını başlatmak için cli komutu yazılır ve enter tuşuna basılır:

root@host% cli
root@host>

cli komutu çalıştırıldığında, % işaretinin, yerini > işaretine bıraktığını görürüz. > işareti CLI’ın operasyonel modunda olduğumuzu gösterir.

Operasyonel modda iken, configure komutu yazılarak enter tuşuna basılırsai CLI’ın konfigürasyon moduna geçilir.

root@host> configure
root@host#

configure komutu çalıştırıldığında, > işaretinin, yerini # işaretine bıraktığını görürüz. # işareti CLI’ın konfigürasyon modunda olduğumuzu gösterir.

Unix shell’ine sadece root user’ı ile bağlanılabilir. İlerleyen bölümlerde de belirteceğimiz gibi yeni user’lar tanımladığımızda, bu user’larla JunOS CLI’ının sadece operasyonel(>) ve konfigürasyon(#) modlarına login olunabilir.

CLI’ın operasyonel modunda, firewall’un monitöring ve troubleshooting çalışmaları gerçekleştirilir. Monitor, ping, show, test ve traceroute komutları kullanılarak pek çok bilgi edinilir ve firewall’un ağ iletişimi test edilebilir.

CLI’ın konfigürasyon modunda, firewall’un bütün özellikleri(interface’ler, protokoller, user erişimleri) ve de bir kaç donanım özelliği konfigüre edilebilir.

Root ile login olunduğunda Unix shell’ine(%) bağlandığımızı, burada cli komutunu çalıştırdığımızda operasyonel moda(>) bağlandığımızı ve burada da configure komutunu çalıştırdığımızda konfigürasyon moduna(#) geçtiğimizi söyledik. Root yerine başka bir user ile login olduğumuzda ise doğrudan CLI’ın operasyonel moduna(>) bağlanılır. Burada da configure komutunu çalıştırdığımızda konfigürasyon moduna(#) geçilir.

Root ile login olunmuş ve konfigürasyon moduna geçilmişken, exit komutu ile operasyonel moda geçilir. Operasyonel modda da yine exit komutunu çalıştırarak unix shell’ine düşülür.

root@host# exit
Exiting configuration mode
root@host> exit
root@host%

Root yerine başka bir user ile login olunmuş ve konfigürasyon moduna geçilmişken, exit komutu ile operasyonel moda geçilir.

sensoy@host# exit
Exiting configuration mode
sensoy@host>

configure komutunun bir de configure private ve configure exclusive şeklinde kullanıldığı halleri vardır.

Root harici bir kullanıcı firewall CLI’ının konfigürasyon modunda bir değişiklik yapıyorken, ikinci bir kullanıcı bağlanıp değişiklik yapabilir. Her bir kullanıcı yaptığı değişikliği commit de edebilir. Bu kullanıcılar, operasyonel moddan konfigürasyon moduna configure private komutlarıyla geçtikleri sürece sorun yoktur.

Ama kullanıcılardan biri, operasyonel moddan konfigürasyon moduna geçerken configure exclusive komutunu kullandıysa, bu kullanıcı haricindeki diğer tüm kullanıcıların commit edilmemiş değişiklikleri geçersiz kabul edilir. configure exclusive komutunu kullanarak bağlanan bir kullanıcı, daha evvel CLI’a bağlanmış olan ve konfigürasyon modunda değişiklik yapan kullanıcıların değişikliklerini commit etmesine izin vermez.

Configure exclusive komutuyla konfigürasyon moduna geçen kullanıcı için ekran görüntüsü aşağıdaki gibidir:

fikri@host > configure exclusive
warning: uncommitted changes will be discarded on exit
Entering configuration mode
Users currently editing the configuration:
sensoy terminal p0 (pid 28309) on since 2011-12-28 19:30:05 EET, idle 00:10:00
private [edit]
fikri@host#

configure komutuyla konfigürasyon moduna geçerek konfigürasyonda değişiklik yapan kullanıcı ve commit yapmak istediğinde aldığı hata aşağıda görülebilir:

sensoy@host # commit
error: configuration database locked by:
fikri terminal p1 (pid 28315) on since 2011-12-28 19:40:05 EET
exclusive [edit]

Exclusive olan kullanıcı konfigürasyon modundan operasyonel moda geçtiğinde, diğer kullanıcı değişikliklerini commit edebilir.

SRX’e root ile login olunduktan sonra yapılacak ilk iş, root’a bir şifre atamak olmalıdır demiştik. Şimdi root kullanıcısına şifre atayalım. Bunun için konfigürasyon modunda aşağıdaki komut çalıştırılır:

root@host# set system root-authentication plain-text-password

Komut çalıştırılınca belirlenecek şifrenin iki kez girilmesi istenir.

New password:

Retype new password:

Şifre iki kez girildikten sonra yine konfigürasyon modunda commit komutu kullanılarak yaptığımız değişiklikler aktif konfigürasyona yazılır/kaydedilir.

root@host# commit

Candidate Configuration ve Active Configuration:

Şimdi de Firewall’da konfigürasyon değişiklikleri sürecini inceleyelim. Root ya herhangi bir kullanıcı, firewall CLI’ına login olduğunda Active Configuration’a bağlanmış olur. Başlangıçta Candidate Configuration ile Active Configuration aynıdır. Kullanıcı bir değişiklik yaptığında Candidate Configuration değişmiş olur. Bu değişiklik commit komutunu çalıştırana kadar devreye girmez. Candidate Configuration commit edildiğinde Active Configuration ile eşitlenir ve yapılan değişiklikler de devreye girmiş olur. Eski Active Configuration ise 1 numaralı yedek konfigürasyon olarak saklanır. Mevcut Active Konfigurasyon haricinde son 49 commit edilmiş konfigurasyon (Active Configuration) yedekte tutulur. Mevcut Active Konfigurasyon rollback 0 olarak konumlandırılmıştır.

Örnekler üzerinden konfigürasyon yapısını incelersek daha anlaşılır olacaktır.

Örneğin bir değişiklik yaptınız fakat yaptığınız değişikliği iptal etmek istiyorsanız rollback 0 komutunu çalıştırırsanız ya da exit deyip konfigürasyon moddan çıkarsanız(commit etmeden çıkmayı kabul ettiğinize dair yes derseniz) her şey eski haline dönmüş olur.

Birinci seçenek:

root@host# rollback 0

İkinci seçenek:

root@host# exit
The configuration has been changed but not committed

Discard uncommitted changes? [yes,no] (yes) yes

Diğer bir örnekte ise bir değişiklik yaptınız ve değişikliği commit ettiniz diyelim. Bir süre sonra da yaptığınız değişikliği yapmamanız gerektiğini fark ettiniz ve eski konfigürasyona dönmek istiyorsunuz. Bu durumda değişiklik öncesindeki Active Configuration’un rollback 0 iken değişiklik sonrasında rollback 1 olduğunu düşünmelisiniz. Yani dönmek istediğiniz konfigürasyon rollback 1 dosyasındadır. Bunun için rollback 1 komutunu çalıştırmalı ve ardından da commit etmelisiniz.

root@host# rollback 1

root@host# commit

Başka bir örnekle devam edelim. Mevcut Active Configuration(rollback 0) ile rollback 25 arasındaki farkları görmek istiyorsunuz. Bunun için yapmanız gereken operasyonel modda şu komutu kullanmaktır:

root@host> show configuration | compare rollback 25

İki farklı rollback konfigürasyon arasındaki(rollback 25 ve rollback 40 olsun) farkları görmek istiyorsanız da yapmanız gereken, operasyonel modda şu komutu kullanmaktır:

root@host> show configuration | compare rollback 25 | compare rollback 40

Son olarak, birçok değişiklik yaptınız ve commit etmeden önce yaptığınız değişiklikleri görmek istiyorsunuz ve sonrasında commit etmek istiyorsunuz diyelim. Bunun için konfigürasyon modunda şu komutu kullanmalısınız:

root@host# show | compare

CLI’da Kullanılan Kısayol Tuşları

Şimdi de CLI kullanımını kolay kılan kısayol tuşlarını inceleyelim. CLI’da yazılacak komutlar ve değişkenler Spacebar ve Tab tuşları ile tamamlanmaktadır.

Örneğin, show komutu yazılmak istendiğinde, sh harflerini yazıp Spacebar tuşuna ya da Tab tuşuna basılırsa komut otomatik olarak tamamlanır.

root@host> sh<space>ow

Yine bu tuşlar kullanılarak komut ya da değişiken seçeneklerinin ekranda listelenmesi de sağlanabilir. Örneğin show configuration komutu yazılmak istendiğinde show c denilip enter’a basılırsa c harfiyle başlayan seçenekler sıralanır.

root@host > show c

^

'c' is ambiguous.

Possible completions:

chassis                 Show chassis information

class-of-service               Show class-of-service (CoS) information

cli           Show command-line interface settings

configuration    Show current configuration