Modül Teması

Bir sisteme sızmak isteyen saldırganın önünde genellikle iki temel yol vardır: teknik bir açığı istismar etmek ya da sistemde zaten var olan bir hesabı ele geçirmek. İkinci yol çoğu zaman birincisinden daha kolaydır. Zayıf parola kullanan bir hesap, gereğinden fazla yetkiye sahip bir kullanıcı ya da uzun süredir kullanılmayan ama sistemde hâlâ aktif bırakılmış bir hesap, saldırgan için doğrudan giriş kapısı hâline gelebilir.

Bu modülde işletim sistemlerinin kullanıcı ve grup yapısını, kimlik doğrulama güvenliğini, yetki yönetimini ve bu konulara ilişkin temel komut satırı araçlarını ele alacağız. Kullanıcı hesaplarının nasıl tanımlandığını, grupların neden kullanıldığını, standart kullanıcı ile yönetici hesabı arasındaki farkı ve root/Administrator gibi yüksek ayrıcalıklı hesapların neden dikkatli yönetilmesi gerektiğini öğreneceksiniz.

Kullanıcı ve hesap güvenliği, güvenlik zincirinin en insan odaklı halkalarından biridir. Teknik önlemler ne kadar güçlü olursa olsun, hesap güvenliği ihmal edildiğinde tüm sistem savunması zayıflar. Bu modülün sonunda yalnızca kavramsal bilgi edinmiş olmayacaksınız; aynı zamanda bir sistemde kimlerin hangi yetkilerle çalıştığını denetleyebilecek, şüpheli hesap ve grup yapılarını fark edebilecek ve temel bulguları raporlayabilecek pratik bir bakış açısı kazanacaksınız.

1. Kullanıcı ve Grup Yapısı

1.1 Kullanıcı Hesapları ve Grup Mantığı

İşletim sistemi, sisteme erişen her kişiyi veya süreci bir kullanıcı hesabı aracılığıyla tanır. Hesap, sistem açısından temel kimlik birimidir. Başka bir ifadeyle işletim sistemi, "Bu kişi kim?" ve "Bu kişi ne yapabilir?" sorularının cevabını kullanıcı hesabı üzerinden verir.

Küçük bir sistemde birkaç hesabı tek tek yönetmek mümkün olabilir. Ancak onlarca, yüzlerce hatta binlerce kullanıcının bulunduğu sistemlerde her hesabın yetkisini ayrı ayrı yönetmek hem zaman alır hem de hata yapma ihtimalini artırır. Bu noktada gruplar devreye girer.

Grup, ortak yetkilere sahip kullanıcıların bir araya getirildiği mantıksal bir yapıdır. Bir kullanıcıyı belirli bir gruba eklemek, o grubun sahip olduğu izinleri kullanıcıya da tanımak anlamına gelir. Grubun izinleri değiştirildiğinde, bu değişiklik gruptaki tüm kullanıcılara yansır. Böylece yetki yönetimi daha düzenli, sürdürülebilir ve denetlenebilir hâle gelir.

Bunu bir okul üzerinden düşünebiliriz. Öğretmenler, öğrenciler ve yöneticiler farklı odalara, belgelere veya sistemlere erişebilir. Her kişiye tek tek izin vermek yerine, bu kişiler rollerine göre gruplara ayrılır. Öğretmenler öğretmen grubuna, öğrenciler öğrenci grubuna, yöneticiler ise yönetici grubuna eklenir. Her grubun erişim hakları ayrı tanımlanır.

Windows sistemlerde Administrators, Users ve Remote Desktop Users gibi yerleşik gruplar bulunur. Linux sistemlerde ise sudo, www-data, docker gibi gruplar belirli ayrıcalıkları kontrol eder. Grup yapısının doğru kurulması, yetki yönetimini hem güvenli hem de yönetilebilir kılar. Bu yapı kurulmadan yapılan yetki dağıtımı zamanla karmaşıklaşır ve kontrol edilmesi zor bir hâl alır.

1.2 Standart Kullanıcı ve Yönetici Hesabı Farkı

İşletim sistemleri temelde iki ana hesap türü üzerine kuruludur: standart kullanıcı ve yönetici hesabı. Standart kullanıcı, günlük işlemler için gerekli olan sınırlı yetkilere sahiptir. Kendi dosyalarını oluşturabilir, uygulamaları çalıştırabilir ve bazı kişisel ayarlarını değiştirebilir. Ancak sistem genelini etkileyen işlemleri yapamaz. Örneğin sistem genelini etkileyen yeni yazılım kuramaz, sistem dosyalarını değiştiremez veya diğer kullanıcıların verilerine erişemez.

Yönetici hesabı ise çok daha geniş yetkilere sahiptir. Yazılım kurabilir, kullanıcı ekleyip silebilir, sistem yapılandırmalarını değiştirebilir ve cihaz genelinde etkili olacak işlemler gerçekleştirebilir. Bu nedenle yönetici hesabı güçlüdür; fakat aynı zamanda risklidir.

Bu ayrım güvenlik açısından kritik öneme sahiptir. Bir kullanıcı yönetici hesabıyla çalışırken kötü amaçlı bir dosyayı yanlışlıkla açarsa, o zararlı yazılım da yönetici haklarıyla çalışabilir. Böyle bir durumda zararlı yazılım sistem dosyalarını değiştirebilir, güvenlik ayarlarını devre dışı bırakabilir, yeni kullanıcılar oluşturabilir veya sistemin derin katmanlarına yerleşebilir.

Aynı hata standart kullanıcı hesabıyla yapılmış olsaydı, zararlı yazılımın yapabilecekleri o kullanıcının yetkileriyle sınırlı kalırdı. Bu nedenle günlük bilgisayar kullanımı için standart kullanıcı hesabı tercih edilmeli, yönetici yetkisi yalnızca gerçekten gerektiğinde ve geçici olarak kullanılmalıdır.

Dikkat: "Ben zaten kendi bilgisayarımda yöneticiyim, sorun yok." Bu yaygın ama tehlikeli bir yanılgıdır. Yönetici hesabıyla sürekli çalışmak, olası bir saldırı veya hata durumunda hasarın kapsamını büyütür. Standart hesapla çalışmak günlük kullanımı çoğu zaman kısıtlamaz; yalnızca olası bir hatanın veya saldırının etkisini sınırlar.

1.3 Yerel Hesap ve Merkezi Hesap Kavramı

Bir işletim sistemindeki hesaplar, nerede tanımlandıklarına göre iki ana kategoriye ayrılır: yerel hesap ve merkezi hesap.

Yerel hesap (local account), yalnızca tanımlandığı bilgisayar üzerinde geçerli olan hesaptır. Bu hesabın kullanıcı adı, parolası ve yetkileri ilgili sisteme özgüdür. Ev kullanıcıları, bireysel bilgisayarlar ve küçük işletmeler çoğunlukla yerel hesaplarla çalışır. Örneğin bir dizüstü bilgisayarda oluşturulan ogrenci01 hesabı, yalnızca o bilgisayarda geçerliyse bu bir yerel hesaptır.

Merkezi hesap (centralized account) ise bir sunucu üzerinden yönetilen ve birden fazla sisteme erişim sağlayabilen hesap yapısıdır. Windows ortamlarında bu yapı genellikle Active Directory (AD) ile sağlanır. Bir kullanıcı, etki alanına katılmış farklı bilgisayarlarda aynı kimlik bilgisiyle oturum açabilir. Linux ortamlarında benzer işlevi LDAP veya Kerberos gibi yapılar üstlenir.

Merkezi hesap yönetimi büyük kurumlar için önemli avantajlar sunar. Bir çalışan işten ayrıldığında hesabı tek bir noktadan devre dışı bırakılabilir ve bu işlem bağlı sistemlere yansır. Parola politikaları, grup üyelikleri ve erişim yetkileri merkezi olarak uygulanabilir. Böylece hesap yönetimi daha tutarlı hâle gelir.

Bununla birlikte merkezi kimlik yönetimi ek sorumluluk da getirir. Merkezi kimlik yönetim sunucusunun ele geçirilmesi, bağlı tüm sistemler için büyük risk oluşturur. Bu yüzden Active Directory, LDAP veya benzeri kimlik altyapılarının güvenliği kurumsal güvenliğin en kritik başlıklarından biridir.

1.4 Root ve Administrator Mantığına Giriş

Her işletim sisteminde, normal kullanıcı ve yönetici hesaplarının ötesinde çok yüksek ayrıcalıklara sahip özel hesaplar bulunur. Linux ve macOS sistemlerde bu hesap root, Windows sistemlerde ise built-in Administrator olarak bilinir.

Root hesabı, Linux/Unix tabanlı sistemlerde sistemin tamamı üzerinde sınırsız yetkiye sahiptir. Her dosyayı okuyabilir, silebilir, her süreci sonlandırabilir, her yapılandırmayı değiştirebilir. Windows tarafında built-in Administrator hesabı da benzer şekilde sistem üzerinde çok geniş yetkilere sahiptir.

Bu düzeyde bir yetki büyük bir kolaylık sağlasa da ciddi riskler taşır. Root veya built-in Administrator yetkisiyle yapılan bir hata, sistemin çalışmaz hâle gelmesine neden olabilir. Aynı şekilde bu yetkilerle çalışan bir zararlı yazılım, sisteme telafi edilmesi zor zararlar verebilir.

Güvenli sistem yönetiminin temel kuralı, root veya built-in Administrator hesabının günlük kullanım için doğrudan kullanılmamasıdır. Linux'ta sudo mekanizması bu amaçla kullanılır. Normal bir kullanıcı, yalnızca ihtiyaç duyduğu belirli komutlar için geçici olarak root yetkisi kazanır. İşlem tamamlandığında yetki yeniden normal seviyeye döner. Windows'ta ise UAC (User Account Control) benzer bir güvenlik yaklaşımı sunar.

Modern Linux dağıtımlarının çoğunda root hesabının doğrudan kullanımı varsayılan olarak sınırlandırılır ve sudo kullanımı teşvik edilir. Bu bir tesadüf değil, bilinçli bir güvenlik tercihidir. Amaç, yüksek yetkilerin yalnızca gerekli olduğunda ve kontrollü biçimde kullanılmasını sağlamaktır.

Dikkat: Root veya built-in Administrator hesabının parolasını zayıf bırakmak ya da bu hesabı uzak bağlantılara açık tutmak, sisteme doğrudan tam erişim kapısı açmak anlamına gelir. Bu hesapların yönetimi, bir sistemin en kritik güvenlik kararlarından biridir.

2. Kimlik Doğrulama Güvenliği

2.1 Güçlü Parola Oluşturma Prensipleri

Parola, kimlik doğrulamanın en yaygın kullanılan ama aynı zamanda en çok hata yapılan unsurudur. Güçlü bir parola, saldırganın sistematik tahmin, otomatik deneme veya sızdırılmış parola listeleriyle kısa sürede ele geçiremeyeceği nitelikte olmalıdır.

Güçlü parola oluştururken dört temel ölçüt öne çıkar: uzunluk, karmaşıklık, tahmin edilemezlik ve özgünlük. Uzunluk, parolanın kırılmasını zorlaştıran en önemli faktörlerden biridir. Genel yaklaşım olarak en az 12-16 karakterlik parolalar tercih edilmelidir. Karmaşıklık, büyük harf, küçük harf, rakam ve özel karakterlerin birlikte kullanılmasını ifade eder. Tahmin edilemezlik ise parolanın kişisel bilgiler, doğum tarihi, isim, sözlük kelimeleri veya sıralı karakterler içermemesi anlamına gelir. Özgünlük ise aynı parolanın birden fazla hesapta kullanılmamasıdır.

İpucu: Pratikte güçlü parola oluşturmanın etkili yollarından biri cümle parola (passphrase) yöntemidir. Bu yöntemde birbiriyle doğrudan ilişkili olmayan birkaç kelime bir araya getirilir. Böylece hem uzun hem de hatırlanabilir bir parola elde edilir.

Örnek: Tr3n!Bulut\$Ma5a gibi karmaşık görünen ama görece kısa bir parola, doğruyol-pencere-fırtına-47-bisiklet gibi daha uzun bir cümle parolaya göre daha kırılgan olabilir. Çünkü parola güvenliğinde uzunluk çoğu zaman karmaşıklıktan daha belirleyici hâle gelir.

Her hesap için güçlü ve benzersiz parola üretmek insan hafızası açısından sürdürülebilir değildir. Bu nedenle parola yöneticileri bu sürecin doğal tamamlayıcısıdır. Parola yöneticisi, her hesap için benzersiz ve güçlü parolalar üretir, bunları güvenli biçimde saklar ve gerektiğinde otomatik olarak doldurur. Böylece kullanıcı hem güçlü parola kullanabilir hem de onlarca farklı parolayı ezberlemek zorunda kalmaz.

2.2 Parola Tekrar Kullanımının Riskleri

Aynı parolayı birden fazla hesapta kullanmak, güvenlik dünyasında en yaygın ve en öngörülebilir hatalardan biridir. Saldırganlar kullanıcıların bu alışkanlığını çok iyi bilir ve saldırılarını buna göre tasarlar.

Bir web sitesinin veritabanı ele geçirildiğinde, sızdırılan kullanıcı adı ve parola kombinasyonları başka servislerde otomatik olarak denenebilir. Bu saldırı yöntemine credential stuffing denir. Kullanıcı aynı parolayı e-posta, sosyal medya, bulut depolama ve iş hesabında kullanıyorsa, tek bir sızıntı birden fazla hesabı tehlikeye atabilir.

Bu riskin büyüklüğünü anlamak için internette her yıl milyarlarca hesap bilgisinin çeşitli veri sızıntılarıyla açığa çıktığını düşünmek yeterlidir. Bu bilgiler karanlık ağda el değiştirebilir ve otomatik araçlarla büyük ölçekte denenebilir.

Bugün kullandığınız bir parolanın geçmişte başka bir sitede sızdırılıp sızdırılmadığını kontrol etmek mümkündür. haveibeenpwned.com bu konuda kamuya açık ve güvenilir bir referans noktasıdır. Ancak asıl çözüm, her hesap için farklı ve benzersiz parola kullanmaktır. Bunu sürdürülebilir kılmanın en pratik yolu ise parola yöneticisinden yararlanmaktır.

2.3 Hesap Kilitleme ve Parola Politikaları

İşletim sistemleri ve uygulamalar, kaba kuvvet saldırılarına karşı hesap kilitleme politikaları uygulayabilir. Kaba kuvvet saldırılarında saldırgan, doğru parolayı bulana kadar çok sayıda parola denemesi yapar. Hesap kilitleme politikası, belirli sayıda başarısız giriş denemesinden sonra hesabı geçici veya kalıcı olarak kilitleyerek bu tür saldırıları yavaşlatır.

Örnek: Beş başarısız giriş denemesinin ardından hesabın 30 dakika kilitlenmesi, otomatik parola deneme araçlarını büyük ölçüde etkisiz hâle getirebilir. Böyle bir politika saldırganın deneme hızını düşürür ve güvenlik ekiplerine olağandışı giriş denemelerini fark etme imkânı sağlar.

Parola politikaları, kurum veya sistem genelinde parolaların nasıl oluşturulacağını ve nasıl yönetileceğini belirleyen kurallardır. Minimum parola uzunluğu, karmaşıklık gereklilikleri, önceki parolaların yeniden kullanılmasının engellenmesi ve parola değişim periyotları bu politikaların temel unsurlarıdır.

Windows ortamlarında parola politikaları Group Policy aracılığıyla merkezi olarak uygulanabilir. Linux sistemlerde ise PAM (Pluggable Authentication Modules) yapısı bu işlevi üstlenir. Böylece sistem yöneticileri parola güvenliğini tek tek hesap bazında değil, merkezi kurallar üzerinden yönetebilir.

Dikkat: Parola politikaları gerçek kullanıcı davranışlarını dikkate alarak tasarlanmalıdır. Her 30 günde bir parola değiştirme zorunluluğu gibi aşırı katı politikalar, kullanıcıların Parola1, Parola2, Parola3 gibi tahmin edilebilir diziler oluşturmasına neden olabilir. Bu durum güvenliği artırmak yerine zayıflatır.

İpucu: Güncel güvenlik rehberleri, düzenli ve zorunlu parola değişimi yerine güçlü, benzersiz parola kullanımını ve anlamlı bir tetikleyici olmadan parola değiştirme zorunluluğunun kaldırılmasını önermektedir. Parola değişimi özellikle sızıntı, şüpheli erişim veya güvenlik olayı gibi durumlarda zorunlu hâle getirilmelidir.

2.4 Çok Faktörlü Kimlik Doğrulamaya Giriş

Parola tek başına yeterli bir güvence değildir. Parolalar sızdırılabilir, tahmin edilebilir, kimlik avı saldırılarıyla çalınabilir veya kullanıcı tarafından yanlışlıkla paylaşılabilir. Bu nedenle modern güvenlik yaklaşımında parolanın yanında ek doğrulama katmanları kullanılır.

Çok faktörlü kimlik doğrulama (Multi-Factor Authentication - MFA), kullanıcının kimliğini yalnızca bildiği bir bilgiyle değil, ikinci veya üçüncü bir kanıtla daha doğrulayan mekanizmadır. MFA, saldırganın yalnızca parolayı ele geçirmesini yeterli olmaktan çıkarır.

MFA faktörleri genel olarak üç kategoriye ayrılır:

MFA'nın en önemli avantajı, parolanız çalınsa bile saldırganın ikinci faktöre sahip olmadan sisteme girememesidir. Bunu banka kartı örneğiyle düşünebiliriz. ATM'den para çekmek için yalnızca kart yeterli değildir; PIN de gerekir. Kart "sahip olduğunuz bir şey", PIN ise "bildiğiniz bir şey"dir.

İşletim sistemi ve kurumsal erişim güvenliğinde MFA özellikle uzak bağlantı noktalarında kritik öneme sahiptir. SSH, RDP ve VPN gibi protokoller üzerinden yapılan erişimlerde MFA kullanmak, hesap ele geçirme saldırılarına karşı güçlü bir koruma sağlar.

Unutma: Yazılım tabanlı doğrulayıcı uygulamalar, yani authenticator app'ler, en yaygın ve pratik MFA yöntemlerinden biridir. Bu uygulamalar her 30 saniyede bir yenilenen tek kullanımlık kodlar üretir. SMS kodları da MFA yöntemi olarak kullanılabilir; ancak doğrulayıcı uygulamalar ve donanım anahtarları genellikle daha güvenli kabul edilir.

3. Yetki Yönetimi Temelleri

3.1 Günlük Kullanımda Ayrıcalıklı Hesapların Sınırlandırılması

Ayrıcalıklı hesaplar, özellikle yönetici veya root yetkisi taşıyan hesaplar, yalnızca bu yetkileri gerçekten gerektiren işlemler için kullanılmalıdır. Günlük rutin işler için yüksek ayrıcalıklı hesapla çalışmak, saldırı veya hata durumunda oluşabilecek zararı büyütür.

Sistem yöneticileri bile e-posta okumak, belge hazırlamak, web'de gezinmek veya günlük iletişim işlerini yürütmek için standart kullanıcı hesabı kullanmalıdır. Yönetici hesabı yalnızca sistem değişikliği yapılması gereken anlarda devreye alınmalıdır.

Bu yaklaşımın önemini basit bir senaryo üzerinden görebiliriz. Bir kullanıcı yönetici hesabıyla web'de gezinirken zararlı bir sayfadan kötü amaçlı kod indirilirse, bu kod yönetici haklarıyla çalışabilir. Aynı olay standart kullanıcı hesabıyla yaşansaydı, zararlı kodun sistemde yapabilecekleri çok daha sınırlı kalırdı.

Kurumsal ortamlarda bu ilke daha da önemlidir. Sistem yöneticileri için ayrıcalıklı işlemlere özel admin hesapları oluşturulmalı ve bu hesaplar yalnızca yönetim işlemleri için kullanılmalıdır. Örneğin bir kişinin günlük hesabı ahmet.kara, yönetici işlemleri için kullandığı hesabı ise adm-ahmet.kara olabilir. Böyle bir ayrım, hangi işlemin hangi yetki bağlamında yapıldığını daha izlenebilir hâle getirir.

Ayrıcalıklı hesaplarda güçlü parola ve MFA kullanımı zorunlu olmalıdır. Çünkü bu hesaplar saldırganlar için yüksek değerli hedeflerdir. Bir standart hesabın ele geçirilmesi zararlı olabilir; ancak bir yönetici hesabının ele geçirilmesi tüm sistemin güvenliğini doğrudan tehlikeye atabilir.

3.2 UAC ve Sudo Mantığına Temel Bakış

Windows ve Linux/macOS sistemlerde ayrıcalıklı işlemleri kontrol altına almak için farklı mekanizmalar kullanılır. Windows tarafında bu görevi UAC (User Account Control), Linux ve macOS tarafında ise büyük ölçüde sudo üstlenir.

UAC, Windows Vista ile gelen ve güncel Windows sürümlerinde kullanılmaya devam eden bir güvenlik mekanizmasıdır. Bir uygulama sistem genelini etkileyen bir değişiklik yapmak istediğinde ekranda bir onay penceresi gösterir. Yazılım kurmak, sistem ayarlarını değiştirmek veya yönetici yetkisi gerektiren bir işlem yapmak buna örnek verilebilir.

UAC'nin amacı, arka planda sessizce çalışan bir zararlı yazılımın kullanıcı farkında olmadan yönetici yetkisiyle işlem yapmasını engellemektir. Kullanıcı, ekrandaki uyarıyı gördüğünde işlemi gerçekten kendisinin başlatıp başlatmadığını sorgulamalıdır.

sudo (superuser do) ise Linux ve macOS sistemlerde standart kullanıcıların belirli komutları geçici olarak root yetkisiyle çalıştırmasını sağlar. Kullanıcı sudo ile bir komut çalıştırdığında kendi parolasını girer, yetki geçici olarak yükselir ve işlem tamamlandığında yetki normal seviyeye döner.

Dikkat: Hangi kullanıcının hangi komutları sudo ile çalıştırabileceği /etc/sudoers dosyasında tanımlanır. Bu dosyanın hatalı yapılandırılması, gereğinden fazla kullanıcının root yetkisi elde etmesine neden olabilir. Bu yüzden sudo yetkileri dikkatle verilmelidir.

UAC ve sudo farklı sistemlerde çalışsa da ortak hedefleri aynıdır: ayrıcalıklı işlemi gerektiren anı tespit etmek, kullanıcı onayı almak ve bu işlemin kaydını tutmak. Ancak bu mekanizmalar yalnızca kullanıcı dikkatli olduğunda etkili olur. UAC uyarısını otomatik olarak "Evet" diyerek geçmek veya sudo komutunu ne yaptığını anlamadan çalıştırmak, güvenlik mekanizmasını büyük ölçüde işlevsiz hâle getirir.

Doğru refleks şudur: Bir yetki yükseltme uyarısı gördüğünüzde önce "Bu işlemi ben mi başlattım?" ve "Bu işlem gerçekten gerekli mi?" sorularını sormalısınız.

3.3 Yetki Yükseltme Riskine Giriş

Yetki yükseltme (privilege escalation), düşük yetkili bir kullanıcının veya sürecin normalde sahip olmaması gereken daha yüksek ayrıcalıklar kazanmasıdır. Bu durum, işletim sistemi güvenliğinde en kritik risklerden biridir.

Yetki yükseltme iki farklı biçimde ortaya çıkabilir. Yatay yetki yükseltme, bir kullanıcının aynı yetki seviyesindeki başka bir kullanıcının verilerine veya işlemlerine erişmesidir. Örneğin bir çalışan, aynı düzeydeki başka bir çalışanın özel dosyalarına erişebiliyorsa bu yatay yetki yükseltme olarak değerlendirilebilir.

Dikey yetki yükseltme ise standart kullanıcı seviyesinden yönetici veya root seviyesine çıkmak anlamına gelir. Bu çok daha ciddi bir güvenlik ihlalidir. Çünkü saldırgan düşük yetkili bir hesapla sisteme girdikten sonra dikey yetki yükseltme yoluyla tüm sistemi kontrol edebilir.

Yetki yükseltme genellikle üç temel kaynaktan beslenir: yanlış yapılandırılmış izinler, yamanmamış işletim sistemi açıkları ve aşırı yetkili çalışan servisler veya uygulamalar. Örneğin bir klasörün gereğinden fazla yazma iznine sahip olması, bir servisin root yetkisiyle gereksiz yere çalışması veya eski bir işletim sistemi açığının yamalanmamış olması yetki yükseltme riskini artırabilir.

Bu modül saldırı tekniklerini öğretmeye odaklanmaz; bunun yerine yetki yükseltme riskini doğuran yapısal hataları tanımayı hedefler. Sistemde hangi hesapların yönetici grubunda olduğunu düzenli kontrol etmek, gereksiz yetkilerin birikmesini engellemek ve ayrıcalıklı grup üyeliklerini minimum düzeyde tutmak bu riski yönetmenin en pratik yollarındandır.

3.4 En Az Ayrıcalığın Günlük Kullanım Senaryoları

En az ayrıcalık ilkesi, yalnızca teorik bir güvenlik kavramı değildir; günlük sistem yönetiminde doğrudan uygulanması gereken bir disiplindir. Bu ilkeye göre her kullanıcı, servis, uygulama veya süreç yalnızca görevini yerine getirmek için ihtiyaç duyduğu minimum yetkiye sahip olmalıdır.

Örnek: Bir şirket çalışanının yalnızca kendi departmanına ait dosya sunucusuna erişmesi gerekiyorsa, tüm ağ paylaşımına erişim verilmemelidir. Sadece gerekli klasöre erişim tanımlanmalıdır. Bir uygulama veritabanında yalnızca okuma yapacaksa, o uygulamaya yazma veya silme yetkisi verilmemelidir. Bir destek görevlisi yalnızca parola sıfırlama işlemi yapacaksa, ona tam yönetici yetkisi vermek yerine yalnızca parola sıfırlama yetkisini kapsayan kısıtlı bir rol tanımlanmalıdır.

Bu örneklerin ortak noktası, her hesabın ve her uygulamanın yalnızca işini yapmak için gereken yetkiyle çalıştırılmasıdır. Böyle bir yapı kurulduğunda, bir hesap ele geçirilse bile saldırganın erişim kapsamı sınırlı kalır.

Zaman içinde sistemlerde gereksiz yetkiler birikebilir. Bir kullanıcı geçici olarak bir gruba eklenir ama daha sonra çıkarılmaz. Bir servis test amacıyla yüksek yetkiyle çalıştırılır ve bu yapı kalıcı hâle gelir. Bir çalışan görev değiştirir ancak eski yetkileri silinmez. Bu nedenle hesap ve grup üyeliklerinin periyodik olarak gözden geçirilmesi güvenlik rutininin vazgeçilmez bir parçasıdır.

Güvenli Alışkanlık: Her birkaç ayda bir sisteminizdeki yönetici grubu üyelerini kontrol edin. "Bu kişi neden yönetici grubunda?" sorusunu cevaplayamıyorsanız, o üyeliğin gözden geçirilmesi gerekir.

4. Temel Komut Satırı ile Hesap ve Yetki Yönetimi

4.1 Komut Satırının İşletim Sistemi Yönetimindeki Yeri

Grafiksel arayüzler günlük kullanımda kolaylık sağlar; ancak sistem yönetimi ve güvenlik denetimi söz konusu olduğunda komut satırı çoğu zaman daha hızlı, daha kesin ve daha ayrıntılı bilgi sunar. Komut satırı çıktıları kaydedilebilir, karşılaştırılabilir ve rapor formatında saklanabilir.

Bir grafik arayüzden ekran görüntüsü alınabilir; fakat ham metin çıktısı çoğu zaman daha esnek bir kanıt formatıdır. Komut çıktıları tarih ve saat bilgisiyle birlikte saklanabilir, başka çıktılarla karşılaştırılabilir ve denetim süreçlerinde kullanılabilir.

Windows sistemlerde Command Prompt (cmd) ve PowerShell, Linux ve macOS sistemlerde ise terminal bu işlevi üstlenir. Bu modülde ele alınan komutlar öncelikle denetim ve gözlem amacı taşır. Amaç sisteme zarar vermek veya izinsiz değişiklik yapmak değil; sistemde hangi hesapların bulunduğunu, hangi kullanıcıların hangi gruplara üye olduğunu ve hangi hesapların ayrıcalıklı yetkilere sahip olduğunu anlamaktır.

Bu sorulara cevap verebilmek, hesap güvenliğinin temelidir:

• Sistemde hangi kullanıcı hesapları var?
• Hangi hesaplar aktif?
• Hangi hesaplar yönetici yetkisine sahip?
• Hangi hesaplar uzun süredir kullanılmamış?
• Beklenmedik bir grup üyeliği var mı?
• Guest veya benzeri riskli hesaplar aktif mi?

Komutları çalıştırmak tek başına yeterli değildir. Asıl önemli beceri, çıktıyı doğru okumak ve güvenlik açısından yorumlayabilmektir.

4.2 Kullanıcı Kimliğini ve Yetki Bağlamını Görme: whoami, id

whoami ve id komutları, o anda sistemde hangi kullanıcı kimliğiyle çalıştığınızı ve hangi gruplara üye olduğunuzu görmenizi sağlar. Özellikle çok kullanıcılı sistemlerde veya birden fazla hesapla çalışılan ortamlarda bu bilgi kritik önem taşır.

Unutma: Bir terminal penceresinin hangi yetki bağlamında çalıştığını bilmeden işlem yapmak risklidir. Kullanıcı kendisini standart hesapla çalışıyor sanabilir; ancak aslında yönetici veya root yetkisiyle işlem yapıyor olabilir. Bu durum yanlış bir komutun çok daha büyük etki yaratmasına neden olabilir.

Windows'ta whoami, mevcut kullanıcı kimliğini gösterir. whoami /groups ise kullanıcının grup üyeliklerini listeler. Linux ve macOS'ta whoami kullanıcı adını, id komutu ise UID, GID ve grup üyeliklerini gösterir.

4.3 Hesap ve Grup Yönetimine Giriş: net user, net localgroup, useradd, groupadd

Hesap ve grup yönetimi, bir sistemde kimlerin tanımlı olduğunu ve hangi yetkilere sahip olduğunu anlamak için temel bir denetim alanıdır. Windows tarafında net user ve net localgroup komutları, yerel kullanıcıları ve grup üyeliklerini incelemek için kullanılır.

net user, sistemde tanımlı kullanıcı hesaplarını listeler. Belirli bir kullanıcı adıyla birlikte kullanıldığında, o hesabın detaylarını gösterir. Örneğin hesabın aktif olup olmadığı, son giriş zamanı, parola durumu ve yerel grup üyelikleri bu komutla incelenebilir.

net localgroup administrators, Windows sistemde yerel Administrators grubunun üyelerini listeler. Bu grup, sistemde en yüksek ayrıcalıklara sahip yerel gruplardan biridir. Bu nedenle bu gruptaki her hesabın gerçekten orada olması gerekip gerekmediği düzenli olarak kontrol edilmelidir.

Linux tarafında useradd ve groupadd gibi komutlar yeni kullanıcı ve grup oluşturmak için kullanılır. Bu modülde odak daha çok gözlem ve denetim olduğu için hesap ve grup yapısının nasıl sorgulanacağına ağırlık verilir. Bununla birlikte bu komutların varlığını ve kullanım amacını bilmek, sistem yönetiminin temel parçalarındandır.

4.4 Yetki Yükseltme ve Yönetici Yetkisi Farkındalığı: sudo, runas

sudo ve runas, geçici olarak farklı veya daha yüksek yetkiyle işlem yapmak için kullanılan araçlardır. Bu araçlar, günlük kullanımda standart hesapla çalışırken yalnızca ihtiyaç duyulan anda ayrıcalıklı işlem yapmayı mümkün kılar.

İpucu: Linux ve macOS sistemlerde sudo, belirli bir komutu root yetkisiyle çalıştırmayı sağlar. Kullanıcı kendi parolasını girer, komut yüksek yetkiyle çalışır ve işlem tamamlandığında kullanıcı normal yetki seviyesine döner. Bu yaklaşım root hesabıyla sürekli çalışmaktan çok daha güvenlidir.

Windows tarafında runas, farklı bir kullanıcı kimliğiyle komut veya uygulama çalıştırmak için kullanılır. Örneğin standart kullanıcı hesabıyla oturum açıkken, yönetici hesabı kimliğiyle yeni bir komut penceresi açmak mümkündür. Bu yöntem, günlük oturumu kapatmadan tek seferlik yönetici işlemleri yapmayı sağlar.

Unutma:Bu araçların temel amacı, ayrıcalıklı işlemleri kontrollü hâle getirmektir. Ancak yalnızca yetkili olduğunuz hesaplar için kullanılmalı ve ne yaptığınızdan emin olmadığınız komutlar yüksek yetkiyle çalıştırılmamalıdır.

4.5 Temel Hesap, Grup ve Yetki Sorgulama Mantığı

Hesap ve grup sorgulama, güvenlik denetiminin en temel pratiklerinden biridir. Bir sistemde kaç hesap bulunduğunu, hangi hesapların aktif olduğunu, hangi hesapların yönetici yetkisine sahip olduğunu ve hangi hesapların uzun süredir kullanılmadığını bilmek gerekir.

Bu sorgulamalar düzenli yapılmadığında sistemde hesap karmaşası oluşur. Eski çalışanlara ait hesaplar sistemde kalabilir, geçici olarak verilmiş yetkiler unutulabilir veya bilinmeyen hesaplar kritik gruplara eklenmiş olabilir. Bu tür durumlar saldırganlar için fırsat yaratır.

Düzenli hesap ve yetki denetimi, sistemdeki anormallikleri erken fark etmeyi sağlar. Özellikle yönetici grupları, sudo yetkisi olan kullanıcılar, Guest benzeri hesaplar ve uzun süredir kullanılmayan aktif hesaplar dikkatle incelenmelidir.

Komut & Araç Okuryazarlığı

Windows'ta Temel Kontrol

Mevcut Kullanıcı Kimliğini Görme

Komut:

 whoami

Amaç: O anda oturum açmış kullanıcının tam adını DOMAIN\kullanici veya BILGISAYAR\kullanici formatında gösterir.

Beklenen çıktı:

Bu komut, mevcut oturumun hangi kullanıcı kimliğiyle çalıştığını hızlıca doğrulamak için kullanılır. Özellikle yönetici yetkisiyle mi yoksa standart kullanıcı olarak mı işlem yaptığınızı anlamak için ilk bakılacak komutlardan biridir.

Kullanıcının Grup Üyeliklerini Görme

Komut:

 whoami /groups

Amaç: Mevcut kullanıcının üye olduğu tüm grupları listeler.

Bu çıktı, kullanıcının hangi gruplar üzerinden hangi yetkilere sahip olabileceğini anlamaya yardımcı olur. Özellikle Administrators gibi yüksek ayrıcalıklı gruplar dikkatle incelenmelidir.

Sistemdeki Kullanıcıları Listeleme

Komut:

 net user

Amaç:Yerel sistemde tanımlı tüm kullanıcı hesaplarını listeler.

Beklenen çıktı:

Bu komut, sistem envanterini çıkarmak için kullanılır. Administrators grubunda beklenmedik bir hesap görüyorsanız bu durum yetki aşımı açısından araştırılmalıdır.

Bu komut, sistemde hangi yerel hesapların bulunduğunu görmek için kullanılır. Tanınmayan hesaplar, eski kullanıcı hesapları veya aktif bırakılmış Guest hesabı güvenlik açısından incelenmelidir.

Belirli Bir Hesabın Detaylarını Görme

Komut:

 net user ogrenci01

Amaç: Belirtilen kullanıcının hesap detaylarını; son giriş, parola politikası,\ grup üyelikleri ve hesap durumu gibi bilgileri gösterir. Beklenen çıktı:

Bu komut, belirli bir hesabın aktiflik durumunu ve güvenlik açısından önemli detaylarını görmeye yarar. Uzun süredir kullanılmayan ama aktif olan hesaplar potansiyel risk oluşturabilir.

Yönetici Grubunu İnceleme

Komut:

 net localgroup administrators

Amaç: Yerel Administrators grubunun üyelerini listeler.

Beklenen çıktı:

Bu listede olmasını beklemediğiniz bir hesap varsa hemen araştırın. Yönetici grubu üyeliği en yüksek ayrıcalık kapılarından biridir.

Dikkat: Bu komut, Windows sistemde yönetici yetkisine sahip hesapları denetlemek için kritik önemdedir. Administrators grubundaki her hesabın neden orada olduğu açıklanabilir olmalıdır.

Yerel Kullanıcılar ve Gruplar Aracı

Windows'ta yerel kullanıcı ve grup yapısı grafik arayüz üzerinden de incelenebilir. Bunun için Başlat menüsüne lusrmgr.msc yazılabilir veya Win + R ile Çalıştır penceresi açılarak aynı komut girilebilir.

Sol panelde "Users" ve "Groups" klasörleri görünür. "Users" bölümünde sistemdeki yerel kullanıcı hesapları, "Groups" bölümünde ise yerel gruplar incelenebilir. Özellikle "Administrators" grubunun üyeleri kontrol edilmelidir.

Dikkat: Guest hesabının aktif olması, bilinmeyen hesapların varlığı veya Administrators grubunda tanımadığınız bir hesabın bulunması şüpheli bir durum olarak değerlendirilmelidir.

Linux'ta Temel Kontrol

Mevcut Kullanıcı Kimliğini Görme

Komut:

 whoami

Amaç: O anda aktif olan kullanıcının adını gösterir.

Beklenen çıktı:

Bu komut, terminalde hangi kullanıcı kimliğiyle çalıştığınızı gösterir. Özellikle root olarak işlem yapıp yapmadığınızı doğrulamak için kullanışlıdır.

Kullanıcı Kimliği ve Grup Üyeliklerini Görme

Komut:

 id

Amaç: Mevcut kullanıcının UID (kullanıcı kimlik numarası), GID (birincil\ grup kimliği) ve tüm grup üyeliklerini gösterir.

Beklenen çıktı:

Bu komut, kullanıcının sistemde hangi kimlik ve grup bağlamında çalıştığını gösterir. sudo, docker ve adm gibi gruplar özel dikkat gerektirir; çünkü bu gruplar bazı sistemlerde yüksek yetkilere veya hassas bilgilere erişim sağlayabilir.

Sistemdeki Tüm Kullanıcıları Listeleme

Komut:

 cat /etc/passwd

Amaç: Sistemde tanımlı tüm kullanıcı hesaplarını gösterir.

Beklenen çıktı:

Bu dosya, Linux sistemlerde kullanıcı hesaplarına ilişkin temel bilgileri içerir. Özellikle giriş kabuğu atanmış tanınmayan hesaplar incelenmelidir.

sudo Yetkisi Olan Kullanıcıları Görme

Komut:

 getent group sudo

Amaç: sudo grubunun üyelerini listeler. Debian/Ubuntu tabanlı dağıtımlar için kullanılır.

Beklenen çıktı:

Bu komut, sudo yetkisine sahip kullanıcıları hızlıca kontrol etmek için kullanılır. Debian/Ubuntu sistemlerde sudo, RHEL/CentOS tabanlı sistemlerde ise genellikle wheel grubu kontrol edilir.

Başarısız Giriş Denemelerini Görme

Komut:

 lastb

Amaç: Başarısız giriş denemelerini listeler. Root yetkisi gerektirebilir. Beklenen çıktı:

Bu komut, başarısız oturum açma denemelerini görmek için kullanılır. Kısa süre içinde aynı kullanıcıya veya aynı IP adresinden çok sayıda başarısız deneme yapılmışsa bu durum brute force saldırısına işaret edebilir.

macOS'ta Temel Kontrol

Mevcut Kullanıcı ve Gruplarını Görme

Komut:

 id

Amaç: Linux'taki ile aynı işlevi görür; UID, GID ve grup üyeliklerini gösterir.

Beklenen çıktı:

macOS üzerinde id komutu, kullanıcının kimlik ve grup bilgilerini gösterir. admin veya wheel gibi gruplar özellikle incelenmelidir.

Sistemdeki Tüm Kullanıcıları Listeleme

Komut:

 dscl . list /Users | grep -v '^_'

Amaç: macOS'ta sistemde tanımlı kullanıcı hesaplarını listeler; sistem hesaplarını, yani alt çizgi ile başlayanları filtreler.

Beklenen çıktı:

Bu komut, macOS sistemde kullanıcı hesaplarını listelemek için kullanılır. Alt çizgiyle başlayan sistem hesapları filtrelenerek daha okunabilir bir kullanıcı listesi elde edilir.

sudo Yetkili Kullanıcıları Görme

Komut:

 dscl . -read /Groups/admin GroupMembership

Amaç: macOS'ta yönetici, yani admin grubunun üyelerini listeler.

Beklenen çıktı:

Bu komut, macOS'ta admin grubunun üyelerini görmek için kullanılır. Bu listede yer alan kullanıcılar sistem üzerinde yönetici yetkisine sahip olabilir.

runas — Windows'ta Farklı Kullanıcı Kimliğiyle Komut Çalıştırma

Komut:

 runas /user:localadmin cmd

Amaç: Belirtilen kullanıcının kimliğiyle yeni bir komut penceresi açar. O kullanıcının parolası sorulur.

Beklenen çıktı:

Bu komut, standart kullanıcı oturumunda çalışırken belirli bir işlemi farklı bir kullanıcı kimliğiyle gerçekleştirmek için kullanılır. Yetkisiz hesaplarla kullanılmamalıdır.

Temel Uygulama / Kontrol Listesi

Bu kontrol listesi, bir bilgisayarda veya sunucuda hesap ve yetki yapısını temel düzeyde incelemek için kullanılabilir. Amaç, sistemde kimlerin bulunduğunu, hangi hesapların hangi yetkilere sahip olduğunu ve şüpheli bir durum olup olmadığını anlamaktır.

Hazırlık

• Hangi sistemi incelediğinizi not edin: işletim sistemi, sürüm ve sistem adı.
• Standart kullanıcı hesabıyla mı, yönetici hesabıyla mı çalıştığınızı belirleyin.
• Bulguları kaydedeceğiniz bir metin dosyası veya not defteri açın.

Kontrol Adımları

• whoami ile mevcut kullanıcı kimliğini doğrulayın.
• whoami /groups (Windows) veya id (Linux/macOS) ile grup üyeliklerini inceleyin.
• net user (Windows) veya cat /etc/passwd (Linux) ile sistemdeki hesapları listeleyin.
• Yönetici / Administrators / sudo grubunun üyelerini kontrol edin.
• Uzun süredir giriş yapılmamış hesapları tespit edin. Windows'ta net user \ komutuyla Last logon alanına bakın.
• Guest hesabının aktif olup olmadığını kontrol edin.
• Devre dışı bırakılması gereken hesaplar olup olmadığını değerlendirin.

Doğrulama

• Yönetici grubundaki her hesabın orada olması gerekip gerekmediğini sorgulayın.
• Listede tanımadığınız hesapları araştırın.
• Parola politikasının uygulanıp uygulanmadığını kontrol edin.

Kanıt Notu

• Tüm komut çıktılarının ekran görüntüsünü veya metin kopyasını tarih ve saat bilgisiyle kaydedin.
• Her şüpheli bulgu için şunları not edin: Hangi hesap? Hangi grup üyeliği? Ne zaman fark edildi?

Geri Dönüş / Dikkat Edilmesi Gerekenler

• Bir hesabı silmeden önce o hesabın aktif bir kullanıcıya ait olup olmadığını doğrulayın.
• Yetki değişikliklerini yetkili kişilerle onaylamadan uygulamayın.
• Şüpheli bir hesap bulduğunuzda hemen silmeyin; önce yetkili kişilere bildirin ve kanıtı saklayın.

Temel Operasyonel Senaryo

Senaryo: "Yönetici Grubunda Tanımadığım Bir Hesap Var"

Rutin sistem bakımı sırasında bir IT çalışanı, Windows iş istasyonundaki Administrators grubunu incelerken listede backup_user adlı bir hesabın bulunduğunu fark eder. Bu hesap IT departmanı kayıtlarında yedek sistemler için tanımlıdır; ancak ilgili iş istasyonunda yönetici yetkisine sahip olması beklenmemektedir.

Bu durumda ilk soru şudur: Bu hesap yanlışlıkla mı eklendi, yoksa yetkisiz bir değişiklik mi yapıldı? Hesabın ne zaman Administrators grubuna eklendiği, son ne zaman kullanıldığı ve bu hesapla hangi işlemlerin yapıldığı incelenmelidir.

Kontrol edilecek noktalar şunlardır:

• net localgroup administrators komutuyla Administrators grubunun tam listesi alınır.
• net user backup_user komutuyla hesabın son giriş tarihi ve parola bilgileri kontrol edilir.
• Windows Event Viewer'da güvenlik logları üzerinden bu hesaba ait giriş olayları incelenir.
• Hesabın ne zaman Administrators grubuna eklendiğini gösteren Event ID 4732 kaydı aranır.

Toplanacak kanıtlar:

• net localgroup administrators çıktısının ekran görüntüsü
• net user backup_user çıktısının ekran görüntüsü
• Event Viewer'dan ilgili log kayıtlarının dışa aktarımı
• İnceleme tarihi, saati ve incelemeyi yapan kişinin adı

                        # Adli Analiz Raporu | Hedef Hesap: backup_user | Analist: [İsim]
                        
                        C:\> net localgroup administrators
                        Members
                        -------------------------------------------------------------------------------
                        Administrator
                        backup_user (Yetkisiz Grup Üyeliği)
                        
                        C:\> net user backup_user
                        User name              backup_user
                        Last logon             14.04.2026 09:12:45
                        Password last set      14.04.2026 02:30:10
                        Account active         Yes
                        
                        C:\> wevtutil qe Security /q:"*[System[(EventID=4732)]]" /f:text /c:1
                        
                        [EVENT ID 4732] - A member was added to a security-enabled local group.
                        Date:          2026-04-14T02:45:12.000Z
                        Subject:       Administrator
                        Member:        SID: S-1-5-21...-1004 (backup_user)
                        Target Group:  Administrators
                        
                        
                        

                        ADLİ BULGULAR VE KANITLAR:
                        - KRİTİK ZAMAN: Hesap 02:45 (mesai dışı) saatinde yönetici grubuna eklenmiş.
                        - PERSISTENCE: Kısıtlı 'backup_user' hesabı kalıcılık için yükseltilmiş.
                        - LOGON: Yetki yükseltilmesinden sonra sabah 09:12'de giriş yapılmış.
                        - DURUM: Onaylı bir IT işlemi kaydı yok; hesap "Compromised" (Ele Geçirilmiş).
                        

İnceleme sırasında Event Viewer kayıtlarında backup_user hesabının iki hafta önce yerel saatle 02:45'te Administrators grubuna eklendiği görülür. Bu saatte sistemde planlı veya onaylı bir IT işlemi bulunmamaktadır. Hesabın son girişinin ise gruba eklendiği günün sabahında gerçekleştiği tespit edilir.

Bu değişiklik onaylı bir işlem değildir. Dolayısıyla yetkisiz bir hesap manipülasyonu söz konusu olabilir. Güvenlik ekibi derhal bilgilendirilmeli, backup_user hesabı Administrators grubundan çıkarılmalı ve hesabın bu süre içinde hangi işlemleri gerçekleştirdiği kapsamlı biçimde araştırılmalıdır.

Bulgu → Etki → Öneri → Kanıt

Bulgu: DESKTOP-XYZ iş istasyonunda backup_user hesabının iki hafta önce, gece 02:45'te yetkisiz biçimde Administrators grubuna eklendiği tespit edilmiştir. Bu işlem planlı IT faaliyetleri kapsamında değildir.

Etki: backup_user hesabı bu süre içinde yönetici haklarıyla sisteme giriş yapmış ve ayrıcalıklı işlem gerçekleştirme imkânına sahip olmuştur. Sistemdeki verilere yetkisiz erişim ve değişiklik riski mevcuttur.

Öneri: backup_user hesabı Administrators grubundan derhal çıkarılmalıdır. Hesabın bu süre içinde gerçekleştirdiği tüm işlemler log analizi yoluyla incelenmelidir. Administrators grubundaki değişiklikler için uyarı tabanlı izleme (alerting) yapılandırılmalıdır. Benzer yetkisiz değişikliklerin diğer sistemlerde de yaşanıp yaşanmadığı kontrol edilmelidir.

Kanıt: net localgroup administrators çıktısı tarih-saat damgalı ekran görüntüsüyle saklanmalıdır. net user backup_user çıktısı alınmalıdır. Event Viewer'dan dışa aktarılan Event ID 4732 ve 4624 log kayıtları korunmalıdır. İncelemeyi gerçekleştiren kişinin adı ve inceleme tarihi kayıt altına alınmalıdır.

Kendini Değerlendir — Kullanıcı, Hesap ve Yetki Güvenliği

Terimler Sözlüğü

Bu Modülde Kazanılan Yetkinlikler

• Bu modülde kullanıcı hesaplarının ve grupların işletim sisteminde kimlik ile yetki yönetiminin temel yapı taşları olduğunu öğrendik. Grup yapısının doğru kurulmadığı ortamlarda yetki yönetiminin zamanla karmaşıklaştığını ve kontrol edilmesi zor bir hâl aldığını gördük.
• Standart kullanıcı ve yönetici hesabı arasındaki farkı ele aldık. Bu farkın yalnızca teknik bir ayrım olmadığını, aynı zamanda saldırı hasarını sınırlandıran önemli bir güvenlik katmanı olduğunu kavradık.
• Yerel hesapların yalnızca tanımlandıkları sistemde geçerli olduğunu, merkezi hesapların ise birden fazla sistemde kullanılabildiğini öğrendik. Merkezi kimlik yönetiminin kurumlar için büyük avantajlar sunduğunu; ancak merkezi yapının ele geçirilmesi durumunda büyük riskler doğurabileceğini gördük.
• Root ve built-in Administrator hesaplarının sınırsız ayrıcalık taşıdığını, bu nedenle günlük kullanım için uygun olmadığını öğrendik. Bu hesapların yalnızca gerektiğinde, kontrollü ve dikkatli şekilde kullanılması gerektiğini kavradık.
• Güçlü parola oluşturmanın uzunluk, karmaşıklık, tahmin edilemezlik ve özgünlük ilkelerine dayandığını gördük. Parola yöneticilerinin bu gereklilikleri sürdürülebilir hâle getirdiğini öğrendik.
• Parola tekrar kullanımının credential stuffing saldırıları için büyük bir fırsat oluşturduğunu ele aldık. Tek bir hesabın sızdırılmasının, aynı parolayla korunan diğer hesapları da tehlikeye atabileceğini anladık.
• Hesap kilitleme politikalarının kaba kuvvet saldırılarını yavaşlatmak için önemli olduğunu, parola politikalarının ise gerçek kullanıcı davranışlarını dikkate alarak tasarlanması gerektiğini kavradık.
• MFA'nın, parola tek başına ele geçirilse bile yetkisiz erişimi engelleyebilen güçlü bir ek güvenlik katmanı olduğunu öğrendik. Özellikle ayrıcalıklı hesaplar ve uzak erişim noktaları için MFA kullanımının kritik olduğunu gördük.
• UAC ve sudo mekanizmalarının, yetki yükseltme gerektiren işlemleri kontrol altına aldığını ve kullanıcı onayı gerektirdiğini öğrendik. Bu uyarıların otomatik olarak geçiştirilmesinin güvenlik mekanizmasını işlevsiz hâle getirebileceğini kavradık.
• Yetki yükseltme riskinin çoğunlukla yanlış izin yapılandırmaları, yamanmamış işletim sistemi açıkları veya aşırı yetkili hesaplardan beslendiğini gördük. Bu riskin yönetilmesi için periyodik hesap ve grup denetiminin gerekli olduğunu öğrendik.
• whoami, id, net user, net localgroup, sudo ve runas gibi komutların hesap ve yetki denetiminde nasıl kullanılabileceğini ele aldık. Bu komutlarla sistemdeki hesapları, grup üyeliklerini ve yetki bağlamını gözlemleyebileceğimizi öğrendik.
• Son olarak, bir sistemdeki yönetici gruplarını düzenli olarak incelemenin ve "Bu hesap neden burada?" sorusunu sormayı alışkanlık hâline getirmenin hesap güvenliğinin en temel pratiklerinden biri olduğunu kavradık.

Modül Teması

Bir işletim sistemi üzerindeki hemen her şey (ayarlar, uygulamalar, kullanıcı belgeleri, kimlik bilgileri, sistem günlükleri ve yapılandırmalar) sonuçta bir dosya olarak saklanır. Dosya sistemi, bu verilerin diskte nasıl organize edildiğini, hangi kullanıcının hangi kaynağa erişebileceğini ve hangi işlemlerin hangi koşullar altında gerçekleştirilebileceğini belirleyen temel yapıdır. Bu yapıyı anlamadan güvenli bir sistem yönetmek, haritasız bir şehirde trafik düzenlemeye çalışmaya benzer.

Bu modülde dosya ve klasör yapısının nasıl kurulduğunu, sistem dosyaları ile kullanıcı dosyalarının neden birbirinden ayrıldığını, kritik dizinlerin hangileri olduğunu ve verinin işletim sistemi içinde nasıl organize edildiğini ele alacağız. Ardından dosya izinlerine geçerek okuma, yazma ve çalıştırma yetkilerinin ne ifade ettiğini, Linux izin modelinin nasıl çalıştığını, Windows'ta NTFS ve ACL yapısının nasıl kullanıldığını ve yanlış izin yapılandırmalarının nasıl ciddi güvenlik açıklarına dönüşebileceğini inceleyeceğiz.

Modülün son bölümünde ise veriyi koruma konusuna odaklanacağız. Paylaşılan klasör güvenliği, USB ve taşınabilir medya riskleri, disk şifreleme, yedekleme, güvenli silme ve dosya bütünlüğü gibi başlıkları temel düzeyde değerlendireceğiz. Bu modül tamamlandığında, dosya sistemi üzerinde verilen her kararın aynı zamanda bir güvenlik kararı olduğunu daha net biçimde görebileceksiniz.

1. Dosya Sistemi Mantığı

1.1 Dosya ve Klasör Yapısı

İşletim sistemi, diskteki verileri rastgele bir şekilde değil, belirli bir hiyerarşi içinde organize eder. Bu yapının temelinde dosya (file) ve klasör (directory/folder) kavramları bulunur. Dosya, içerik barındıran en küçük depolama birimidir. Bir metin belgesi, bir program, bir yapılandırma kaydı, bir günlük dosyası veya bir resim dosyası bu yapının parçasıdır. Klasör ise dosyaları ve başka klasörleri bir arada tutan kapsayıcıdır.

Dosya ve klasörlerin iç içe geçmesiyle ağaç benzeri bir yapı oluşur. Her dosya bu ağacın belirli bir dalında yer alır. Kullanıcının masaüstündeki bir belge, sistemin çalışması için gerekli olan bir yapılandırma dosyası ya da bir uygulamanın arka planda kullandığı veri dosyası, bu hiyerarşinin farklı noktalarında bulunur.

Dosya sistemi yapısını anlamak güvenlik açısından oldukça önemlidir. Çünkü hangi dosyanın nerede bulunduğunu bilmeden yanlış izin yapılandırmalarını fark etmek, beklenmedik değişiklikleri tespit etmek veya zararlı bir yazılımın sisteme nereye yerleştiğini anlamak son derece zorlaşır. Bir saldırgan sisteme sızdığında genellikle belirli dizinleri hedef alır: geçici dosya dizinleri, sistem yapılandırma dosyaları, kullanıcı profil klasörleri veya otomatik çalışan betiklerin bulunduğu alanlar.

Bu nedenle dosya ağacını tanımak, sistemde neyin normal neyin şüpheli olduğunu ayırt etmenin temelidir. Güvenli sistem yönetimi yalnızca çalışan süreçleri veya açık portları izlemekten ibaret değildir; dosyaların nerede durduğunu, kim tarafından değiştirilebildiğini ve hangi izinlerle erişilebilir olduğunu bilmek de aynı derecede önemlidir.

1.2 Sistem Dosyaları ve Kullanıcı Dosyaları

İşletim sistemi dosyaları işlevlerine göre genel olarak iki ana kategoride değerlendirir: sistem dosyaları ve kullanıcı dosyaları. Sistem dosyaları, işletim sisteminin çalışması için zorunlu olan çekirdek bileşenler, sürücüler, yapılandırma kayıtları, sistem uygulamaları ve hizmet dosyalarından oluşur. Bu dosyalar genellikle korumalıdır; standart kullanıcıların bu dosyaları değiştirmesine izin verilmez.

Kullanıcı dosyaları ise her kullanıcının kendi profilinde sakladığı belgeler, indirmeler, masaüstü içerikleri, kişisel ayarlar ve uygulama verileridir.

Örnek: Bir kullanıcının belge klasöründeki rapor dosyası, indirdiği bir PDF veya masaüstündeki bir görsel kullanıcı dosyası olarak düşünülebilir.

Bu ayrım güvenlik açısından kritik bir tasarım ilkesidir. Sistem dosyalarının yetkisiz biçimde değiştirilmesi, işletim sisteminin kararsız çalışmasına, güvenlik mekanizmalarının devre dışı kalmasına veya saldırganın sistemde kalıcılık sağlamasına neden olabilir. Eğer bir zararlı yazılım sistem dizinlerine yazabiliyorsa ya da standart bir kullanıcı sistem dosyalarını silebiliyor veya değiştirebiliyorsa, bu durum izin yapılandırmasının doğru yapılmadığına işaret eder.

Dikkat:Sistem dosyaları ile kullanıcı dosyalarının fiziksel ve mantıksal olarak ayrı tutulması, olası bir ihlalin kapsamını da sınırlar. Kullanıcı alanında gerçekleşen bir hata ya da zararlı yazılım faaliyeti, doğru izin yapılandırması sayesinde sistemin çekirdek bileşenlerine doğrudan zarar veremeyebilir. Bu nedenle dosya sistemi ayrımı yalnızca düzen sağlamak için değil, güvenlik sınırlarını korumak için de kullanılır.

1.3 Kritik Dizinler ve Temel Sistem Klasörleri

Her işletim sisteminde güvenlik açısından özel öneme sahip dizinler bulunur. Bu dizinler, işletim sisteminin çalışması, uygulamaların yönetilmesi, kullanıcı verilerinin saklanması ve günlük kayıtlarının tutulması açısından kritik rol oynar. Bu klasörleri tanımak, hem normal sistem davranışını anlamak hem de olağandışı durumları fark etmek için gereklidir.

Windows'ta Kritik Dizinler

Linux'ta Kritik Dizinler

macOS'ta Kritik Dizinler

Geçici dizinler, güvenlik açısından ayrıca dikkat gerektirir. Linux ve macOS'ta /tmp, Windows'ta ise C:\Windows\Temp dizinleri geçici dosyalar için kullanılır. Bu alanlar çoğu sistemde geniş yazma izinlerine sahip olduğu için zararlı yazılımlar tarafından sıkça tercih edilir. Bu dizinlerde beklenmedik çalıştırılabilir dosyalar, bilinmeyen betikler veya olağandışı isimlere sahip dosyalar görülürse dikkatle incelenmelidir.

Dikkat: /tmp, /private/tmp ve C:\Windows\Temp gibi geçici dizinlerde beklenmedik çalıştırılabilir dosyaların bulunması önemli bir uyarı işaretidir. Bu dosyalar silinmeden önce yolu, izinleri, zaman damgaları ve hash değeri kayıt altına alınmalıdır.

1.4 Verinin İşletim Sistemi İçinde Organize Edilmesi

İşletim sistemi, verinin fiziksel disk üzerinde nasıl depolanacağını dosya sistemi biçimi aracılığıyla yönetir. Windows'ta yaygın olarak NTFS (New Technology File System), Linux'ta ext4, macOS'ta ise APFS (Apple File System) kullanılır. Bu dosya sistemi biçimleri; dosyaların diskte nasıl saklanacağını, meta verilerin nasıl tutulacağını, izinlerin nasıl uygulanacağını ve dosya bütünlüğünün hangi mekanizmalarla korunacağını belirler.

Bir dosyanın yalnızca içeriği önemli değildir. Dosyanın adı, boyutu, oluşturulma tarihi, son değiştirilme zamanı, son erişim zamanı, sahibi, grubu ve izinleri de güvenlik açısından değerli bilgiler taşır. Bu bilgilere genel olarak meta veri denir. Özellikle bir güvenlik olayı incelenirken dosyanın ne zaman oluşturulduğu, ne zaman değiştirildiği ve kim tarafından erişilebilir olduğu kritik kanıt niteliği taşıyabilir.

Dosya sisteminin izin yapısını nasıl desteklediği de önemlidir. Örneğin NTFS, her dosya ve klasör için ayrıntılı erişim denetim listeleri, yani ACL yapısını destekler. Buna karşılık FAT32 ile biçimlendirilmiş bir USB bellek, NTFS'in sunduğu ayrıntılı izin modelini aynı şekilde taşıyamaz. Bu nedenle dosyanın bir ortamdan başka bir ortama taşınması, izin ve güvenlik özelliklerinin değişmesine yol açabilir.

Dosyalara ait zaman bilgileri zaman damgası (timestamp) olarak adlandırılır. Oluşturulma, erişilme, değiştirilme ve meta veri değişikliği gibi zamanlar, dijital adli analizde önemli ipuçları sağlar. Örneğin kritik bir yapılandırma dosyasının planlı bakım dışı bir saatte değişmiş olması, yetkisiz müdahale ihtimalini gündeme getirebilir.

2. Dosya İzinleri ve Erişim Kontrolü

2.1 Okuma, Yazma ve Çalıştırma İzinleri

Dosya izinleri, bir kullanıcının belirli bir dosya veya klasör üzerinde ne yapabileceğini belirleyen kurallardır. Büyük işletim sistemlerinde farklı ayrıntılar bulunsa da temel izin mantığı üç ana kavrama dayanır: okuma (read), yazma (write) ve çalıştırma (execute).

Okuma (read) izni, dosyanın içeriğini görüntüleme veya bir klasörün içindeki öğeleri listeleme yetkisidir. Bir belgeyi açmak, bir görseli görüntülemek veya bir dizindeki dosyaları görmek okuma izni gerektirir.

Yazma (write) izni, dosyanın içeriğini değiştirme, dosyaya yeni veri ekleme veya dosyayı silme yetkisiyle ilişkilidir. Klasörler için yazma izni, klasör içine yeni dosya oluşturma veya mevcut dosyaları silme gibi işlemleri mümkün kılar.

Çalıştırma (execute) izni, bir programı veya betiği çalıştırma yetkisidir. Dizinler açısından çalıştırma izni, o dizinin içine girilebilmesini sağlar. Linux sistemlerde bir dizini listelemek için okuma izni gerekirken, o dizine erişip içine girebilmek için çalıştırma izni de gerekir.

Bu üç iznin doğru kombinasyonu, her dosya için "Kim ne yapabilir?" sorusunun cevabını verir. Bir yapılandırma dosyasının herkes tarafından okunabilir ama yalnızca yönetici tarafından yazılabilir olması, bir sistem betiğinin çalıştırılabilir ancak yetkisiz kullanıcılar tarafından değiştirilemez olması ya da bir kullanıcının özel klasörüne yalnızca kendisinin erişebilmesi bu izinlerin doğru uygulanmasıyla sağlanır.

2.2 Linux'ta Temel İzin Mantığı

Linux, dosya izinlerini üç özne grubu için ayrı ayrı tanımlar: sahip (owner), grup (group) ve diğerleri (others). Her grup için okuma, yazma ve çalıştırma izinleri bağımsız biçimde ayarlanır. Bu yapı, hem basit hem de güçlü bir erişim kontrol modeli sunar.

Bir dosyanın izinleri ls -l komutuyla görüntülenebilir:

-rwxr-xr\-- 1 ogrenci01 staff 4096 Jan 10 10:00 rapor.sh

Bu çıktının ilk bölümü dosya türünü ve izinleri gösterir:

                        - rwx r-x r--
                        | |   |   |
                        | |   |   L__ Diğerleri: yalnızca okuma
                        | |   |
                        | |   L______ Grup: okuma + çalıştırma
                        | |
                        | L__________ Sahip: okuma + yazma + çalıştırma
                        |
                        L____________ Dosya türü (- = dosya, d = dizin)
                        

Buradaki ilk karakter dosya türünü belirtir. - normal dosyayı, d ise dizini ifade eder. Sonraki üçlü sahip izinlerini, ikinci üçlü grup izinlerini, son üçlü ise diğer kullanıcıların izinlerini gösterir.

İzinler sayısal olarak da ifade edilebilir. Bu modelde r = 4, w = 2, x = 1 değerine karşılık gelir. Her kullanıcı grubu için bu değerler toplanır. Örneğin rwx = 7, r-x = 5, r-- = 4 anlamına gelir. Yukarıdaki örnek bu nedenle 754 olarak da ifade edilebilir.

chmod komutu izinleri değiştirmek için, chown komutu ise dosya veya dizin sahipliğini değiştirmek için kullanılır. Bu modülde asıl odak, bu komutlarla agresif değişiklikler yapmak değil, mevcut izinleri okuyup güvenlik açısından yorumlayabilmektir.

Linux sistemlerde bazı dosyalar bilinçli olarak belirli izinlerle korunur. Örneğin /etc/passwd dosyası tüm kullanıcılar tarafından okunabilir durumdadır; çünkü sistemdeki kullanıcı bilgilerini bazı süreçlerin okuyabilmesi gerekir. Ancak bu dosyaya yalnızca root yazabilir. Parola hash'leri ise /etc/shadow dosyasında saklanır ve bu dosya çok daha sıkı korunur; yalnızca root tarafından okunabilir. Bu ayrım bilinçli bir güvenlik tasarımının sonucudur.

Örnek: /etc/passwd dosyası genellikle -rw-r\--r\-- izinlerine sahiptir; tüm kullanıcılar okuyabilir ama yalnızca root yazabilir. /etc/shadow ise parola hash'lerini içerdiği için çok daha kısıtlı izinlerle korunur. Bu yapı, sistemin çalışması için gereken erişim ile hassas verinin korunması arasındaki dengeyi gösterir.

2.3 Windows'ta NTFS ve ACL Mantığına Giriş

Windows sistemlerde NTFS dosya sistemi, her dosya ve klasör için ACL (Access Control List — Erişim Denetim Listesi) adı verilen ayrıntılı bir izin yapısını destekler. ACL, bir dosya veya klasör üzerinde hangi kullanıcı ya da grubun hangi yetkilere sahip olduğunu tanımlayan kayıtların toplamıdır.

ACL içindeki her tekil izin kaydına ACE (Access Control Entry) denir. Bir ACE kaydı genellikle şu bilgileri içerir: hangi kullanıcı veya grup için geçerli olduğu, hangi izin türünü verdiği veya engellediği, bu iznin yalnızca ilgili dosya için mi yoksa alt klasör ve dosyalara da uygulanıp uygulanmayacağı.

Windows izin modeli Linux'a göre daha ayrıntılıdır. Temel izin kategorileri şunlardır:

Windows'ta bir dosya veya klasörün izinleri grafik arayüzden incelenebilir. Bunun için dosya veya klasöre sağ tıklanır, Özellikler menüsüne girilir ve Güvenlik sekmesi açılır. Bu bölümde hangi kullanıcı ve grupların hangi izinlere sahip olduğu görülebilir.

Komut satırında ise icacls aracı ACL'leri sorgulamak ve gerektiğinde yönetmek için kullanılır. Güvenlik denetimlerinde özellikle Everyone, Users, Authenticated Users veya beklenmedik gruplara verilmiş yazma ve tam denetim izinleri dikkatle incelenmelidir.

2.4 Yanlış İzin Yapılandırmalarının Güvenlik Sonuçları

İzin hataları, güvenlik ihlallerinin en yaygın kaynaklarından biridir. Bir sistem güncel ve güçlü araçlarla korunuyor olsa bile yanlış dosya izinleri saldırgan için ciddi fırsatlar oluşturabilir. Yanlış izin yapılandırmaları genellikle üç ana biçimde karşımıza çıkar: aşırı geniş izinler, yazma izninin yanlış verilmesi ve çalıştırma izninin gereğinden fazla tanımlanması.

Aşırı geniş izinler, hassas dosyaların gereğinden fazla kullanıcı tarafından okunabilmesi anlamına gelir. Örneğin veritabanı bağlantı bilgileri içeren bir yapılandırma dosyasının tüm kullanıcılar tarafından okunabilir durumda olması, bu dosyaya erişebilen herkesin veritabanı kimlik bilgilerini ele geçirebilmesine yol açabilir. Bu durum özellikle uygulama yapılandırma dosyaları, .env dosyaları, anahtar dosyaları ve yedek dosyaları için ciddi risk oluşturur.

Yazma izninin yanlış verilmesi, daha da tehlikeli sonuçlar doğurabilir. Bir sistem betiğine veya çalıştırılabilir dosyaya standart kullanıcıların yazabilmesi, o dosyanın içeriğinin değiştirilerek zararlı komut eklenmesine zemin hazırlar. Eğer bu betik belirli aralıklarla otomatik çalışıyorsa, saldırganın eklediği komut da her çalışmada devreye girebilir.

Çalıştırma izninin gereğinden fazla verilmesi ise özellikle geçici dizinlerde ve kullanıcı profil klasörlerinde risk oluşturur. Zararlı bir dosya bu alanlara yerleştirildikten sonra çalıştırılabiliyorsa, saldırgan için ek bir fırsat doğar. Bu nedenle geçici dizinler, indirme klasörleri ve herkesin yazabildiği alanlar düzenli olarak kontrol edilmelidir.

Dosya izinlerinde de en az ayrıcalık ilkesi uygulanmalıdır. Bir dosya yalnızca okunacaksa yazma izni verilmemeli, bir betik yalnızca belirli bir kullanıcı tarafından çalıştırılacaksa çalıştırma izni yalnızca o kullanıcıyla sınırlandırılmalıdır. Gereksiz her izin, potansiyel bir saldırı yüzeyi olarak görülmelidir.

Dikkat:
Güvenli Alışkanlık: Dosya izinlerini değerlendirirken "Bu kullanıcı gerçekten bu dosyayı okumalı mı, değiştirmeli mi, çalıştırmalı mı?" sorusunu sorun. Cevap net değilse izin gözden geçirilmelidir.

3. Hassas Veri Koruma Temelleri

3.1 Paylaşılan Klasör Güvenliği

Ağ üzerinden paylaşıma açılan klasörler, izin yönetiminin en dikkatli uygulanması gereken alanlardan biridir. Bir klasör ağda paylaşıldığında, o klasöre erişimi olan kullanıcılar üzerindeki dosyalara da erişebilir. Bu nedenle paylaşılan klasörler yalnızca erişim kolaylığı açısından değil, güvenlik açısından da düzenli olarak denetlenmelidir.

Ağ paylaşımlarında iki katmanlı bir izin yapısı değerlendirilir. İlk katman paylaşım izinleri (share permissions) olarak adlandırılır. Bu katman, ağ üzerinden o paylaşıma kimlerin erişebileceğini belirler. İkinci katman ise dosya sistemi izinleridir. Windows ortamında bu genellikle NTFS izinleriyle uygulanır. Dosya sistemi izinleri, yerel erişim dahil olmak üzere gerçek okuma, yazma, değiştirme veya tam denetim yetkilerini belirler.

Yaygın hatalardan biri, "Everyone" grubuna tam denetim izni vermektir. Bu yaklaşım kısa vadede erişim sorunlarını azaltıyor gibi görünse de uzun vadede ciddi güvenlik riski oluşturur. Bir diğer hata, artık ihtiyaç duyulmayan paylaşımların açık bırakılmasıdır. Kullanılmayan ama hâlâ erişilebilir durumda olan her paylaşım, saldırı yüzeyini genişletir.

Paylaşılan klasörlerde temel yaklaşım, yalnızca ilgili kişi ve gruplara ihtiyaç duydukları düzeyde erişim vermektir. Erişimler düzenli olarak gözden geçirilmeli, görev değişikliği veya işten ayrılma gibi durumlarda gereksiz yetkiler kaldırılmalıdır. Paylaşım izinleri ile dosya sistemi izinleri birlikte değerlendirilmeden güvenli bir ağ paylaşımından söz edilemez.

3.2 Taşınabilir Medya ve USB Riskleri

USB bellekler, harici diskler ve SD kartlar veriyi hızlı ve pratik şekilde taşımayı sağlar. Ancak bu kolaylık, beraberinde önemli güvenlik riskleri getirir. Taşınabilir medya güvenlik açısından iki yönlü risk taşır: veri çıkışı ve zararlı yazılım girişi.

Veri çıkışı riski, yetkisiz bir kişinin kurumsal veya hassas verileri taşınabilir bir ortama kopyalayıp dışarı çıkarmasıdır. Örneğin bir çalışan müşteri veritabanını, proje dosyalarını veya gizli belgeleri USB belleğe kopyalayabilir. Fiziksel güvenlik ve erişim kontrolleri zayıfsa bu tür veri sızıntılarını fark etmek zor olabilir.

Zararlı yazılım girişi ise sisteme takılan bir USB cihazı üzerinden kötü amaçlı yazılım bulaşmasıdır. Kullanıcı, bulduğu veya güvenmediği bir kaynaktan aldığı USB belleği sisteme taktığında zararlı yazılım devreye girebilir. Eski sistemlerde Autorun gibi mekanizmalar bu riski daha da artırmıştır. Modern sistemlerde bu mekanizmalar büyük ölçüde sınırlandırılmış olsa da USB kaynaklı saldırılar hâlâ önemli bir tehdittir.

Kurumsal ortamlarda USB portlarının politika düzeyinde kısıtlanması, yalnızca onaylı cihazların kullanılmasına izin verilmesi ve taşınabilir medya kullanımının izlenmesi etkili önlemler arasındadır. Bireysel düzeyde ise kaynağı bilinmeyen USB cihazları kesinlikle sisteme takılmamalıdır.

Dikkat: Bilinmeyen USB cihazları yalnızca içinde ne olduğunu merak etmenizi sağlamak amacıyla bırakılmış olabilir. Bu yöntem sosyal mühendislik saldırılarında yaygın olarak kullanılır. Merak, saldırganın en çok faydalandığı insan davranışlarından biridir.

3.3 Temel Disk ve Dosya Şifreleme Kavramı

Şifreleme (encryption), verinin yalnızca doğru anahtara sahip kişiler tarafından okunabilmesini sağlayan matematiksel bir dönüşümdür. Şifrelenmiş bir dosya veya disk, anahtar olmadan anlamsız bir veri yığını gibi görünür. Bu özellik özellikle cihazın çalınması, kaybolması veya diske doğrudan fiziksel erişim sağlanması durumunda kritik bir koruma katmanı sunar.

Tam disk şifrelemesi (full-disk encryption), diskin tamamının şifrelenmesini sağlar. İşletim sistemi yüklenmeden önce parola, PIN, donanım anahtarı veya benzeri bir doğrulama mekanizması gerekebilir. Windows'ta BitLocker, Linux'ta LUKS (Linux Unified Key Setup), macOS'ta ise FileVault bu işlevi yerine getirir. Disk şifrelemesi etkinleştirilmiş bir dizüstü bilgisayar çalınsa bile, saldırgan doğru anahtara sahip olmadan diskteki verilere erişemez.

Dosya düzeyinde şifreleme ise yalnızca belirli dosya veya klasörlerin şifrelenmesini sağlar. Windows'ta EFS (Encrypting File System) ve çeşitli üçüncü taraf araçlar bu yaklaşımı destekler. Bu yöntem, tüm diski değil yalnızca belirli hassas verileri korumak için kullanılabilir.

Şifreleme güçlü bir koruma sağlar; ancak tek başına yeterli değildir. Anahtar yönetimi doğru yapılmazsa şifreleme anlamsız hâle gelebilir. Şifreleme anahtarının veya parolasının kaybedilmesi, veriye kullanıcının kendisinin de erişememesi anlamına gelir. Bu nedenle şifreleme ve yedekleme birlikte düşünülmelidir. Şifreli verinin yedeği yoksa, anahtar kaybı kalıcı veri kaybına dönüşebilir.

3.4 Yedekleme, Veri Kaybı Önleme ve Geri Dönüş Farkındalığı

Yedekleme, verinin bir kopyasını farklı bir konumda saklama işlemidir. Donanım arızası, insan hatası, yanlış silme, güvenlik olayı veya fidye yazılımı saldırısı gibi durumlarda yedek olmadan geri dönüş çoğu zaman mümkün değildir. Bu nedenle yedekleme, veri güvenliğinin en temel bileşenlerinden biridir.

Fidye yazılımları yalnızca ana verileri değil, yedekleri de hedef alabilir. Bu yüzden yedeklerin ana sistemden bağımsız, mümkünse çevrimdışı veya ağ erişimi olmayan bir konumda tutulması önemlidir. Sürekli bağlı duran bir yedek disk, fidye yazılımı tarafından şifrelenebilir. Aynı şekilde ağ paylaşımı üzerinde duran yedekler de saldırganın erişim alanına girebilir.

Etkili yedekleme stratejileri için yaygın olarak 3-2-1 kuralı kullanılır. Bu kurala göre verinin en az 3 kopyası bulunmalı, bu kopyalar 2 farklı ortam türünde saklanmalı ve 1 kopya coğrafi olarak farklı bir konumda tutulmalıdır. Örneğin ana sistemdeki veri, yerel bir yedek disk ve güvenli bir bulut yedeğiyle desteklenebilir.

Yedekleme yapmak tek başına yeterli değildir. Yedeğin gerçekten çalışıp çalışmadığı, yalnızca geri yükleme testiyle anlaşılır. Bu nedenle yedekler düzenli olarak test edilmeli, kritik dosyaların geri getirilebildiği doğrulanmalıdır. Kullanılamayan bir yedek, güvenlik hissi verir ama gerçek bir güvenlik sağlamaz.

İpucu: "Yedeklerim var." demek ile "Yedeklerimden geri yükleme yaptım ve çalıştığını doğruladım." demek aynı şey değildir. Gerçek güvenlik, ikinci cümleyi güvenle söyleyebildiğinizde başlar.

3.5 Güvenli Silme ve Kalıcı Veri Silme Farkındalığı

Bir dosyayı geri dönüşüm kutusuna atmak, geri dönüşüm kutusunu boşaltmak veya klavyeden "Sil" tuşuna basmak, o dosyanın çoğu durumda gerçek anlamda yok edildiği anlamına gelmez. İşletim sistemi genellikle dosyanın yalnızca referansını kaldırır. Verinin kendisi, disk üzerinde üzerine yeni veri yazılana kadar kalmaya devam edebilir.

Bu nedenle veri kurtarma araçları, silinmiş gibi görünen dosyaları çoğu zaman geri getirebilir. Bu durum özellikle bilgisayarın satılması, başka bir kullanıcıya verilmesi, kurum dışına çıkarılması veya imha edilmesi öncesinde büyük risk oluşturur. Normal silme işlemi, hassas veriler için yeterli bir koruma yöntemi değildir.

Gerçek anlamda veri silme için iki temel yaklaşım vardır. İlki üzerine yazma (overwrite) yöntemidir. Bu yöntemde diskteki verinin üzerine rastgele veri yazılarak orijinal içeriğin kurtarılması engellenmeye çalışılır. İkinci yöntem ise fiziksel imhadır. Disk mekanik, elektronik veya manyetik olarak kullanılamaz hâle getirilir.

Dikkat: SSD diskler, mekanik disklerden farklı bir veri depolama mantığına sahiptir. Aşınma dengeleme ve hücre yönetimi gibi teknolojiler nedeniyle klasik üzerine yazma yöntemi SSD'lerde her zaman aynı etkiyi göstermeyebilir. Bu nedenle SSD'ler için üretici tarafından sağlanan güvenli silme araçları, donanımsal güvenli silme özellikleri veya şifreleme + anahtar silme yaklaşımı tercih edilmelidir.

ipucu: Bir cihaz elden çıkarılmadan önce diskin doğru yöntemle temizlendiğinden emin olunmalıdır. Aksi durumda silindiği düşünülen hassas dosyalar, yeni kullanıcı veya üçüncü kişiler tarafından kurtarılabilir.

3.6 Dosya Bütünlüğü ve Kritik Değişiklik Farkındalığına Giriş

Dosya bütünlüğü (file integrity), bir dosyanın içeriğinin yetkisiz biçimde değiştirilmediğini doğrulamayı ifade eder. Özellikle sistem dosyaları, yapılandırma dosyaları, betikler, yedekleme komutları ve güvenlik araçlarına ait dosyalar için bütünlük kontrolü önemli bir güvenlik uygulamasıdır.

Dosya bütünlüğünü doğrulamanın en yaygın yöntemlerinden biri hash (özet) değeri kullanmaktır. Hash, bir dosyanın içeriğini sabit uzunlukta benzersiz bir parmak izi değerine dönüştüren matematiksel bir işlemdir. Dosyanın içeriğinde tek bir bit bile değişse hash değeri tamamen farklı bir çıktı üretir.

Bu yaklaşım pratikte şu şekilde kullanılır: Kritik bir dosyanın bilinen iyi durumdaki hash değeri kaydedilir. Daha sonra belirli aralıklarla aynı dosyanın hash değeri yeniden hesaplanır ve referans değerle karşılaştırılır. Eğer değerler eşleşiyorsa dosyanın içeriği değişmemiş kabul edilir. Eğer değerler farklıysa dosyada değişiklik yapılmış demektir. Bu değişikliğin yetkili bir güncellemeden mi yoksa yetkisiz bir müdahaleden mi kaynaklandığı araştırılmalıdır.

Dikkat: Güvenlik amacıyla yaygın olarak SHA-256 ve SHA-512 gibi hash algoritmaları tercih edilir. MD5 ise artık güvenlik amaçlı bütünlük doğrulamalarında önerilmez; çünkü çakışma saldırılarına karşı zayıf kabul edilir.

Örnek: Bir yazılım indirdiğinizde üreticinin web sitesinde SHA-256 hash değeri yayınlanmışsa, indirdiğiniz dosyanın hash değerini hesaplayıp bu değerle karşılaştırabilirsiniz. Değerler eşleşiyorsa dosyanın aktarım sırasında bozulmadığı veya değiştirilmediği doğrulanmış olur. Eşleşmiyorsa dosya çalıştırılmamalıdır.

Komut & Araç Okuryazarlığı

Bu bölümdeki komutlar, dosya izinlerini, ağ paylaşımlarını, hash değerlerini ve dosya meta verilerini denetim amacıyla incelemek için kullanılır. Amaç sistemi değiştirmek değil, mevcut durumu güvenli şekilde gözlemlemek ve bulguları kayıt altına almaktır.

Windows'ta Temel Kontrol

Dosya ve Klasör İzinlerini Görme

Komut:

 icacls C:\Users\ogrenci01\Documents

Amaç: Belirtilen dizin veya dosyanın ACL, yani erişim denetim listesi içeriğini gösterir.

Beklenen çıktı:

icacls, Windows sistemlerde dosya ve klasör izinlerini komut satırından görmek için kullanılır. Özellikle hassas klasörlerde Everyone, Users veya beklenmedik gruplara yazma ya da tam denetim izni verilmişse bu durum incelenmelidir.

Bir Dosyanın Hash Değerini Hesaplama

Komut:

 certutil -hashfile C:\Users\ogrenci01\Downloads\setup.exe SHA256

Amaç: Belirtilen dosyanın SHA-256 hash değerini hesaplar.

Beklenen çıktı:

Bu komut, indirilen bir dosyanın bütünlüğünü kontrol etmek için kullanılabilir. Üretici tarafından yayınlanan resmi hash değeriyle karşılaştırma yapılması, dosyanın değiştirilmediğini veya bozulmadığını doğrulamaya yardımcı olur.

Gizli Paylaşımları ve Ağ Paylaşımlarını Listeleme

Komut:

 net share

Amaç: Sistemdeki tüm ağ paylaşımlarını, varsayılan gizli paylaşımlar dahil listeler.

Beklenen çıktı:

Bu komut, sistemde hangi klasörlerin ağ üzerinden paylaşıldığını görmek için kullanılır. Kullanılmayan veya tanınmayan paylaşımlar saldırı yüzeyini genişletebilir.

Windows Dosya Gezgini - Güvenlik Sekmesi

Windows'ta dosya ve klasör izinleri grafik arayüz üzerinden de incelenebilir. Bunun için herhangi bir dosya veya klasöre sağ tıklanır, Özellikler menüsü açılır ve Güvenlik sekmesine girilir.

Bu ekranda üst bölümde kullanıcı ve gruplar, alt bölümde ise seçilen kullanıcı veya grup için izin detayları görünür. "Everyone" veya beklenmedik kullanıcı/grupların tam denetim ya da yazma iznine sahip olup olmadığı kontrol edilmelidir. Bulgular kanıta dönüştürülmek istenirse, ekran görüntüsü alınmalı ve dosya yolu ile tarih bilgisi birlikte kaydedilmelidir.

Linux'ta Temel Kontrol

Dosya ve Klasör İzinlerini Görme

Komut:

 ls -la /home/ogrenci01/

Amaç: Belirtilen dizindeki dosyaların gizli dosyalar dahil izinlerini, sahibini ve grubunu listeler.

Beklenen çıktı:

Bu komut, Linux sistemlerde dosya ve klasör izinlerini hızlıca incelemek için kullanılır. Özellikle kullanıcı ev dizinleri, sistem yapılandırma dosyaları ve geçici dizinler bu komutla kontrol edilebilir.

Tüm Dünyaya Yazılabilir Dosyaları Bulma

Komut:

 find /tmp -perm -o+w -type f 2>/dev/null

Amaç: /tmp dizininde "diğerleri" (others) tarafından yazılabilir dosyaları listeler.

Beklenen çıktı:

Bu komut, geçici dizinlerde diğer kullanıcılar tarafından yazılabilir dosyaları görmek için kullanılabilir. Özellikle .sh gibi betik dosyaları veya bilinmeyen çalıştırılabilir dosyalar dikkat gerektirir.

Bir Dosyanın Hash Değerini Hesaplama

Komut:

 sha256sum /usr/bin/bash

Amaç: Belirtilen dosyanın SHA-256 hash değerini hesaplar.

Beklenen çıktı:

Bu komut, dosya bütünlüğünü kontrol etmek için kullanılır. Kritik sistem dosyalarının hash değerleri referans değerlerle karşılaştırılarak yetkisiz değişiklikler tespit edilebilir.

Dosya Sahibi ve İzin Denetimi

Komut:

 stat /etc/passwd

Amaç: Bir dosyanın izin, sahip, grup ve zaman damgası bilgilerini ayrıntılı gösterir.

Beklenen çıktı:

stat komutu, dosya hakkında ls -l çıktısından daha ayrıntılı bilgi verir. Özellikle zaman damgaları, izinler ve sahiplik bilgisi güvenlik incelemelerinde önemli ipuçları sağlar.

macOS'ta Temel Kontrol

Dosya İzinlerini Görme

Komut:

 ls -la ~/Documents/

Amaç: Kullanıcının Belgeler klasöründeki dosyaların izinlerini listeler. Linux ile aynı çıktı formatını kullanır.

Beklenen çıktı:

macOS, Unix temelli bir sistem olduğu için dosya izinleri Linux'a benzer şekilde okunabilir. Kullanıcı belgeleri, uygulama dizinleri ve geçici dizinler bu yöntemle incelenebilir.

Bir Dosyanın Hash Değerini Hesaplama

Komut:

 shasum -a 256 ~/Downloads/uygulama.dmg

Amaç: İndirilen dosyanın SHA-256 hash değerini hesaplar.

Beklenen çıktı:

Bu komut, özellikle internetten indirilen .dmg dosyalarının bütünlüğünü kontrol etmek için kullanılabilir. Resmi hash değeriyle eşleşmeyen dosyalar çalıştırılmamalıdır.

Temel Uygulama / Kontrol Listesi

Bu kontrol listesi, dosya sistemi, izinler ve veri koruma açısından temel güvenlik durumunu değerlendirmek için kullanılabilir. Amaç, sistemdeki kritik dosyaların izinlerini, geçici dizinleri, ağ paylaşımlarını, disk şifreleme durumunu ve dosya bütünlüğü kontrollerini güvenli şekilde gözden geçirmektir.

Hazırlık

• Hangi sistemi incelediğinizi not edin: işletim sistemi, sürüm ve tarih.
• Standart kullanıcı hesabıyla çalışın; yönetici yetkisi gerektiren komutlar için yalnızca gerektiğinde geçici yetki yükseltme yapın.
• Bulguları kaydedeceğiniz bir metin dosyası hazırlayın.

Kontrol Adımları

• Geçici dizinlerde (/tmp, /private/tmp, C:\Windows\Temp) beklenmedik çalıştırılabilir dosya var mı?
• Kritik sistem dosyalarının izinleri beklenen değerlerde mi? Örneğin Linux'ta ls -la /etc/passwd, Windows'ta icacls C:\Windows\System32 çıktıları incelenebilir.
• Ağ paylaşımları listesini inceleyin. İhtiyaç duyulmayan açık paylaşım var mı? Windows'ta net share komutu kullanılabilir.
• Sistem diskinde şifreleme etkin mi? Windows'ta BitLocker durumu, Linux'ta lsblk ve LUKS yapısı, macOS'ta FileVault durumu kontrol edilmelidir.
• Kritik dosyaların referans hash değerleri kayıt altında mı?

Doğrulama

• Yüksek riskli dizinlerdeki beklenmedik dosyaları sha256sum, certutil-hashfile veya shasum -a 256 ile hash alarak kayıt altına alın.
• Disk şifrelemesinin gerçekten etkin olduğunu sistem ayarlarından doğrulayın.
• Paylaşılan klasörlerin doğru izin yapısına sahip olduğunu teyit edin.
• Kritik dosyalarda beklenmedik zaman damgası değişiklikleri olup olmadığını kontrol edin.

Kanıt Notu

• Tüm komut çıktılarını tarih ve saat bilgisiyle birlikte kaydedin.
• Her şüpheli dosya için şu bilgileri not alın: dosya yolu, izin bilgisi, sahip/grup, son değiştirilme tarihi ve hash değeri.
• İzin değişikliği yapılacaksa, değişiklik öncesi mevcut durumu mutlaka belgeleyin.

Geri Dönüş / Dikkat Edilmesi Gerekenler

• Şüpheli bir dosyayı silmeden önce hash değerini, tam dosya yolunu,izinlerini ve zaman damgalarını kaydedin.
• İzin değişikliği yapmadan önce mevcut izin durumunu belgeleyin.
• Disk şifrelemesini etkinleştirmeden önce veri yedeği aldığınızdan emin olun.
• Yedeklerin yalnızca alındığını değil, geri yüklenebilir olduğunu da düzenli olarak test edin.

Temel Operasyonel Senaryo

Senaryo: "Sistem Betiği Beklenmedik Biçimde Değiştirilmiş"

Bir Linux sunucusunda her gece saat 02:00'de otomatik olarak çalışan bir yedekleme betiği, yani /usr/local/bin/backup.sh, son birkaç gündür düzgün çalışmamaktadır. Yedekleme logları beklenmedik hata mesajları içermekte ve yedek dosyaları oluşturulmamaktadır.

Bu durumda ilk olarak betiğin kendisinin değiştirilmiş olup olmadığı düşünülmelidir. Sorun betiğin içeriğinden, izinlerinden, sahiplik bilgisinden veya betiğin çağırdığı başka bir bileşenden kaynaklanıyor olabilir. Müdahale etmeden önce betiğin mevcut durumu güvenli şekilde incelenmeli ve kanıtlar kaydedilmelidir.

Kontrol edilecek noktalar şunlardır:

1. 1. ls -la /usr/local/bin/backup.sh komutuyla betiğin izinleri ve son değiştirilme tarihi incelenir.
2. 2. stat /usr/local/bin/backup.sh komutuyla tam zaman damgası bilgisi alınır.
3. 3. sha256sum /usr/local/bin/backup.sh komutuyla mevcut hash değeri hesaplanır ve referans değerle karşılaştırılır.
4. 4. /var/log/syslog veya ilgili log dosyasında betikle ilgili kayıtlar incelenir.
5. 5. Betiğe yazma izni olan kullanıcılar ve gruplar tespit edilir.

Toplanacak kanıtlar:

• ls -la /usr/local/bin/backup.sh çıktısı veya ekran görüntüsü
• stat /usr/local/bin/backup.sh çıktısı
• Hesaplanan SHA-256 hash değeri ve referans hash değeri
• Log dosyasından ilgili satırların kopyası
• İnceleme tarihi, saati ve incelemeyi yapan kişinin adı

                        # Dosya Bütünlük Analizi | Dosya: /usr/local/bin/backup.sh | Analist: [İsim]
                        
                        root@analiz:~# ls -la /usr/local/bin/backup.sh
                        -rwxr-xr-x 1 root root 2048 Apr 29 23:47 /usr/local/bin/backup.sh
                        
                        root@analiz:~# stat /usr/local/bin/backup.sh
                          File: /usr/local/bin/backup.sh
                          Size: 2048        Blocks: 8          IO Block: 4096   regular file
                        Device: 801h/2049d  Inode: 12543       Links: 1
                        Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
                        Access: 2026-05-01 10:00:00.000000000 +0300
                        Modify: 2026-04-29 23:47:12.000000000 +0300
                        Change: 2026-04-29 23:47:12.000000000 +0300
                         Birth: -
                        
                        root@analiz:~# sha256sum /usr/local/bin/backup.sh
                        e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  backup.sh
                        # REFERANS HASH (1 Ay Önce): 85e135d782381254782351283742125162351234123...
                        
                        root@analiz:~# grep "backup.sh" /var/log/syslog | tail -n 2
                        Apr 29 23:47:12 server-01 systemd: /usr/local/bin/backup.sh modified by unknown process.
                        
                        

                        ADLİ ANALİZ BULGULARI:
                        - ZAMAN DAMGASI İHLALİ: Dosya, 23:47 (bakım dışı saat) tarihinde modifiye edilmiş.
                        - BÜTÜNLÜK HATASI: Mevcut SHA-256 değeri referans değerle EŞLEŞMİYOR.
                        - RİSK: Meşru yedekleme betiği içine zararlı kod (backdoor) enjekte edilmiş olabilir.
                        - DURUM: "Tamper" (Dosya Manipülasyonu) kanıtlanmıştır.
                        

İnceleme sırasında stat çıktısı, betiğin Modify zaman damgasının iki gün önce saat 23:47'de değiştiğini göstermektedir. Bu saat hiçbir planlı bakım penceresiyle örtüşmemektedir. Hesaplanan SHA-256 hash değeri, bir ay önce alınan referans hash değeriyle eşleşmemektedir.

Betiğin izin yapısı incelendiğinde, yazma izninin yalnızca root kullanıcısına tanımlı olması gerekirken www-data grubunun da yazma iznine sahip olduğu görülmektedir. Bu durum, web servisleriyle ilişkili bir hesabın veya sürecin bu betiği değiştirebilmiş olabileceğini düşündürür.

Bu bulgular, betiğin yetkisiz biçimde değiştirilmiş olabileceğini gösterir. Sunucu ağdan izole edilmeli, değiştirilmiş betik kanıt olarak yedeklenmeli ve güvenlik birimi bilgilendirilmelidir. Mevcut betik çalıştırılmamalı; temiz ve güvenilir bir referans kopyası varsa onunla geri dönüş yapılmalıdır.

Bulgu → Etki → Öneri → Kanıt

Bulgu: /usr/local/bin/backup.sh betiği iki gün önce saat 23:47'de planlı bakım dışı bir zamanda değiştirilmiştir. Hesaplanan SHA-256 hash değeri, referans hash değeriyle eşleşmemektedir. Betiğin yazma iznine www-data grubu da sahiptir; bu yapılandırma beklenen izin modeliyle çelişmektedir.

Etki: Betiğin yetkisiz içerik değişikliği yedekleme sürecini devre dışı bırakmış ve yedeklerin alınamamasına neden olmuştur. Değiştirilen betik zararlı komut içeriyorsa, root yetkisiyle çalışan zamanlanmış görev aracılığıyla sistem genelinde etki yaratma riski mevcuttur.

Öneri: Betik hemen çalışmaktan alınmalı ve mevcut hâli kanıt olarak saklanmalıdır. www-data grubunun yazma iznini kaldırmak için betik izinleri chmod 750 ile düzeltilmeli, sahiplik chown root:root ile root'a atanmalıdır. Sunucudaki diğer kritik betikler ve yapılandırma dosyaları da hash karşılaştırmasıyla denetlenmelidir. Temiz referans kopyasından betik yeniden yüklenmelidir.

Kanıt: ls -la ve stat çıktıları tarih-saat damgalı şekilde saklanmalıdır. Hesaplanan ve referans SHA-256 hash değerleri kayıt altına alınmalıdır. Log dosyasından ilgili satırların kopyası korunmalıdır. İzin değişikliği öncesi ve sonrası durumu gösteren ekran görüntüleri alınmalıdır. İncelemeyi gerçekleştiren kişinin adı ve inceleme tarihi kaydedilmelidir.

Kendini Değerlendir — Dosya Sistemi ve İzinler

Terimler Sözlüğü

Bu Modülde Kazanılan Yetkinlikler

• Bu modülde dosya ve klasör yapısının işletim sisteminde veriyi organize etmenin temel yolu olduğunu gördük. Dosya sistemini tanımanın, güvenlik denetiminin vazgeçilmez parçalarından biri olduğunu kavradık.
• Sistem dosyaları ile kullanıcı dosyalarının neden birbirinden ayrı tutulduğunu ele aldık. Bu ayrımın yalnızca düzen sağlamak için değil, güvenlik sınırlarını korumak için de önemli olduğunu öğrendik.
• Windows, Linux ve macOS'taki kritik dizinleri inceledik. /tmp, /private/tmp ve C:\\Windows\\Temp gibi geçici dizinlerin zararlı yazılımlar tarafından sıkça hedef alınabildiğini gördük.
• Dosya sistemi biçimlerinin, yani NTFS, ext4 ve APFS gibi yapıların yalnızca veri saklama biçimini değil, izin ve erişim denetimi mantığını da etkilediğini öğrendik.
• Okuma, yazma ve çalıştırma izinlerinin her dosya ve kullanıcı için farklı kombinasyonlarla uygulanabildiğini gördük. Bu izinlerin "Kim ne yapabilir?" sorusuna doğrudan yanıt verdiğini kavradık.
• Linux izin modelini rwx formatında ve sayısal gösterimle okuyup yorumlamayı öğrendik. Sahip, grup ve diğerleri ayrımının bu modeldeki yerini değerlendirdik.
• Windows'ta ACL yapısının Linux'a kıyasla daha ayrıntılı bir izin modeli sunduğunu ve icacls komutuyla bu izinlerin nasıl sorgulanabileceğini gördük.
• Paylaşılan klasörlerde hem paylaşım izinlerinin hem de dosya sistemi izinlerinin birlikte değerlendirilmesi gerektiğini kavradık. Gereksiz açık paylaşımların saldırı yüzeyini genişlettiğini gördük.
• Disk şifrelemesinin fiziksel erişim senaryolarında verinin ele geçirilmesine karşı kritik bir koruma katmanı sağladığını gördük. BitLocker, LUKS ve FileVault'un bu işlevi üstlendiğini öğrendik.
• Yedeklemenin veri güvenliğinde hayati bir rol oynadığını ve 3-2-1 yedekleme kuralının temel mantığını öğrendik. Yedek almak ile yedekten geri yükleme yapıp doğrulamanın farklı şeyler olduğunu kavradık.
• Normal silme ile güvenli silme arasındaki farkı ele aldık. Silinmiş görünen verilerin kurtarma araçlarıyla geri getirilebildiğini ve cihaz elden çıkarılmadan önce güvenli silme yapılması gerektiğini öğrendik.
• Hash değerinin dosya bütünlüğünü doğrulamanın en güvenilir yollarından biri olduğunu gördük. sha256sum, certutil -hashfile ve shasum -a 256 gibi komutlarla hash değeri hesaplayıp referans değerlerle karşılaştırmanın kritik dosyalardaki yetkisiz değişiklikleri fark etmeye yardımcı olduğunu öğrendik.

Modül Teması

Bir işletim sistemi veya uygulama ne kadar iyi tasarlanmış olursa olsun, zaman içinde güvenlik açıklarının keşfedilmesi kaçınılmazdır. Bu açıklar üretici tarafından kapatılana kadar saldırganlar için açık bir kapı işlevi görür. Güncelleme ve yama yönetimi, bu kapıları zamanında kapatmanın en sistematik yoludur. Gerçek hayattaki büyük güvenlik ihlallerinin önemli bir bölümü, aslında daha önce kapatılmış ama ilgili sistemlere uygulanmamış açıklar üzerinden gerçekleşir. Yani çoğu olayda çözüm zaten vardır; fakat sistem henüz güncellenmemiştir.

Bu modülde güvenlik yamalarının ne olduğunu, bir açığın keşfinden istismar edilmesine uzanan süreci, güncellenmeyen sistemlerin karşı karşıya kaldığı riskleri ve destek süresi biten sistemlerin doğurduğu tehlikeleri ele alacağız. Ardından işletim sistemi, yazılım ve sürücü güncellemeleri arasındaki farkları; Windows Update mekanizmasını ve Linux paket yöneticilerinin güncelleme mantığını inceleyeceğiz.

Modülün son bölümünde güvenli güncelleme alışkanlıklarına odaklanacağız. Güncellemelerin neden yalnızca resmî kaynaklardan alınması gerektiğini, sahte güncelleme tuzaklarının nasıl fark edileceğini ve güncelleme öncesi ile sonrası yapılması gereken temel kontrolleri değerlendireceğiz. Bu modülü tamamladığınızda güncelleme yönetimini yalnızca teknik bir zorunluluk olarak değil, güvenlik savunmasının aktif ve sürekli bir parçası olarak göreceksiniz.

1. Güncelleme Güvenliği

1.1 Güvenlik Yamalarının Önemi

Yazılım geliştirme süreci ne kadar dikkatli yürütülürse yürütülsün, karmaşık bir kod tabanında güvenlik açıklarının ortaya çıkması mümkündür. İşletim sistemleri, tarayıcılar, ofis uygulamaları, sürücüler ve sunucu yazılımları milyonlarca satır koddan oluşur. Bu kadar büyük yapılarda hataların tamamen ortadan kaldırılması pratikte mümkün değildir.

Bir güvenlik açığı keşfedildiğinde üretici, bu açığı kapatan bir kod düzeltmesi yayımlar. Bu düzeltmeye güvenlik yaması (security patch) denir. Yama, her zaman yeni bir sürüm veya büyük bir özellik güncellemesi anlamına gelmez. Çoğu zaman var olan sürümdeki belirli bir zafiyeti kapatan hedefli bir düzeltmedir. Bu yüzden güvenlik yamaları, yazılımın işlevini genişletmekten çok, mevcut riskleri azaltmaya odaklanır.

Güvenlik yamalarının önemi, açıkların duyurulma biçimiyle doğrudan ilişkilidir. Bir açık kamuoyuna duyurulduğunda aynı anda iki taraf harekete geçer. Üretici, yamayı geliştirip dağıtmaya çalışır. Saldırganlar ise bu açığı istismar etmek için yöntemler üretir. Bu süreçte hızlı davranan taraf avantaj kazanır. Yama sisteme erken uygulanırsa açık kapatılmış olur. Yama ertelenirse sistem, artık herkes tarafından bilinen ve belgelenmiş bir güvenlik açığını taşımaya devam eder.

Bu nedenle güvenlik yamaları isteğe bağlı küçük iyileştirmeler olarak görülmemelidir. Her yama, saldırı yüzeyini azaltan ve sistemin bilinen açıklarla hedef alınmasını zorlaştıran aktif bir savunma adımıdır. Güncellemeleri düzenli takip etmek ve güvenlik yamalarını zamanında uygulamak, işletim sistemi güvenliğinin temel alışkanlıklarından biridir.

1.2 Exploit Yaşam Döngüsüne Temel Bakış

Bir güvenlik açığının ortaya çıkmasından kapatılmasına kadar geçen süreç belirli aşamalardan oluşur. Bu süreci anlamak, yamaların neden geciktirilmemesi gerektiğini daha somut hâle getirir.

İlk aşama keşiftir. Açık, bir güvenlik araştırmacısı, üretici bünyesindeki bir ekip veya saldırgan tarafından fark edilebilir. Açığı kimin keşfettiği sonraki süreci büyük ölçüde etkiler. Eğer açık iyi niyetli bir araştırmacı tarafından bulunursa genellikle önce üreticiye bildirilir. Eğer saldırganlar tarafından keşfedilirse, açık kullanıcılar fark etmeden istismar edilmeye başlanabilir.

İkinci aşama bildirim ve geliştirme sürecidir. Sorumlu bir güvenlik araştırmacısı açığı doğrudan kamuya açıklamak yerine önce üreticiye bildirir. Bu yaklaşıma responsible disclosure, yani sorumlu ifşa denir. Üretici açığı inceler, doğrular, yamayı geliştirir ve test eder. Bu süreç açığın karmaşıklığına göre birkaç günden birkaç aya kadar uzayabilir.

Üçüncü aşama yayımlamadır. Üretici yamayı yayımlar ve çoğu zaman açığın bazı ayrıntıları kamuoyuyla paylaşılır. Bu aşamadan itibaren açık artık yalnızca üretici veya araştırmacı tarafından değil, saldırganlar tarafından da bilinir hâle gelir.

Dördüncü aşama istismardır. Açık kamuoyuna duyurulduktan sonra saldırı araçları hızla ortaya çıkabilir. Bazı durumlarda yama yayımlanmadan önce saldırılar başlamış olabilir. Bu tür açıklar zero-day olarak adlandırılır. Zero-day saldırılarında üreticinin henüz yayımlanmış bir yaması bulunmadığı için risk daha yüksektir.

Son aşama yama uygulamasıdır. Kullanıcıların ve sistem yöneticilerinin yayımlanan yamayı sistemlerine kurması gerekir. Bu adım gecikirse açık teknik olarak kapatılmış olsa bile ilgili sistem hâlâ savunmasız kalır. Yani üreticinin yamayı yayımlaması tek başına yeterli değildir; yamanın gerçekten sisteme uygulanması gerekir.

İpucu: Bir yamayı uyguladığınızda yalnızca kendi cihazınızı değil, aynı ağdaki diğer sistemleri de korumuş olursunuz. Yamanmamış tek bir sistem, saldırganların ağ içinde ilerlemek için kullanabileceği zayıf halka hâline gelebilir.

1.3 Güncellenmeyen Sistemlerin Tehditlere Açıklığı

Bir güvenlik açığı kamuya duyurulduğunda, o açığa yönelik saldırı araçlarının ortaya çıkması uzun sürmeyebilir. Bu araçlar otomatik tarama yetenekleriyle birleştiğinde, internete açık olan veya ağ içinde erişilebilir durumdaki güncellenmemiş sistemler kısa sürede tespit edilebilir.

Saldırganların her hedef için sıfırdan araştırma yapmasına gerek yoktur. Bilinen açıklar, zafiyet tarayıcıları, otomatik exploit araçları ve internete açık sistemleri indeksleyen platformlar sayesinde belirli sürümleri çalıştıran sistemler kolayca filtrelenebilir. Böylece güncellenmemiş sistemler, saldırganlar için düşük maliyetli ve öngörülebilir hedeflere dönüşür.

Bunu gerçekçi bir senaryo üzerinden düşünelim. Bir uygulama sunucusu 18 ay önce yayımlanan bir güvenlik yamasını hâlâ uygulamamış olsun. Bu yamanın kapattığı açık, aynı ağda çalışan diğer sistemlere yayılabilen bir zararlı yazılım tarafından istismar edilebiliyor olsun. Saldırgan bu sunucuyu tespit ettiğinde yeni bir teknik geliştirmek zorunda değildir. Açık zaten uzun süredir kamuoyunda bilinmektedir, saldırı aracı hazırdır ve sistem hâlâ savunmasızdır. Tek eksik, güncellemenin yapılmamış olmasıdır.

Güvenlik olaylarında sık karşılaşılan tablo budur. Kurumlar bazen güncellemeleri erteler, test süreçlerini geciktirir veya güncelleme mekanizmasının çalışıp çalışmadığını kontrol etmez. Sonuçta sistemler, aylar önce kapatılmış açıkları taşımaya devam eder. Bu nedenle güncelleme yönetimi yalnızca teknik bakım değil, doğrudan risk yönetimi faaliyetidir.

1.4 Destek Süresi Biten İşletim Sistemlerinin Riski

Her işletim sistemi ve yazılım sürümünün bir destek süresi (End of Life --- EOL) vardır. Üretici, belirli bir süre boyunca ilgili sürüm için güvenlik yamaları, hata düzeltmeleri ve teknik destek sağlar. Bu süre sona erdiğinde ise o sürüm için güvenlik güncellemeleri yayımlanmaz.

Destek süresi biten bir sistemin en büyük riski budur: Yeni bir açık keşfedilse bile üretici artık bu sistem için yama yayımlamayabilir. Böylece sistem, zaman içinde kapatılamayan açıkların biriktiği bir yapıya dönüşür. Güncel sistemlerde yama ile giderilen sorunlar, destek dışı sistemlerde kalıcı risk olarak yaşamaya devam eder.

Kurumlar bazen bütçe kısıtlamaları, uyumluluk gereklilikleri veya eski bir uygulamanın yeni işletim sistemleriyle çalışmaması nedeniyle destek süresi bitmiş sistemleri kullanmaya devam eder. Bu karar bazı durumlarda operasyonel olarak anlaşılabilir olabilir; ancak güvenlik riski mutlaka açıkça değerlendirilmelidir. Destek dışı sistemler standart güncelleme mekanizmasıyla korunamaz. Bu nedenle ek önlemler gerekir.

Bu ek önlemler arasında ağ izolasyonu, uygulama beyaz listeleme, sıkı erişim denetimi, yalnızca belirli sistemlerden bağlantıya izin verme ve sistemin internete doğrudan çıkışını sınırlandırma gibi kontroller bulunur. Ancak bu önlemler geçici çözümler olarak görülmelidir. Asıl hedef, desteklenen bir sürüme geçiş planını zamanında hazırlamak olmalıdır.

Destek takvimlerini takip etmek, kurumsal güvenlik yönetiminin temel sorumluluklarından biridir. Bir sistemin ne zaman destek dışı kalacağı önceden bilinmeli, geçiş planı son güne bırakılmamalıdır.

Dikkat: Windows 7 ve Windows Server 2008 gibi sistemlerin ana akım desteği yıllar önce sona ermiştir. Bu sistemler hâlâ bazı ortamlarda kullanılmakta ve kamuoyunda belgelenmiş çok sayıda açık taşımaktadır. Ağınızda böyle bir sistem tespit ederseniz, bu durumu acil güvenlik önlemi gerektiren bir bulgu olarak değerlendirmelisiniz.

2. Güncelleme Süreçleri

2.1 İşletim Sistemi Güncellemeleri

İşletim sistemi güncellemeleri; çekirdek bileşenleri, sistem kütüphanelerini, yerleşik araçları, güvenlik altyapısını ve işletim sisteminin genel çalışma davranışını etkileyen düzeltmeleri kapsar. Bu güncellemeler yalnızca yeni özellikler getirmek için değil, güvenlik açıklarını kapatmak ve sistem kararlılığını artırmak için de yayımlanır.

İşletim sistemi güncellemeleri genel olarak üç ana grupta değerlendirilebilir. Güvenlik güncellemeleri, belirli güvenlik açıklarını kapatmaya odaklanır ve genellikle en yüksek önceliğe sahiptir. Kümülatif güncellemeler, belirli bir tarihe kadar yayımlanmış birden fazla yamayı tek pakette toplar. Böylece kullanıcı veya sistem yöneticisi, geçmişte yayımlanan birçok düzeltmeyi tek güncelleme paketiyle alabilir. Özellik güncellemeleri (feature updates) ise işletim sistemine yeni işlevler ekleyen, büyük değişiklikler içeren ve bazen sürüm yükseltmesi niteliği taşıyan güncellemelerdir.

Güvenlik güncellemeleri ile özellik güncellemelerini aynı öncelikte değerlendirmek doğru değildir. Özellik güncellemeleri bazı durumlarda uyumluluk sorunlarına yol açabilir ve daha kapsamlı test gerektirebilir. Güvenlik güncellemeleri ise bilinen açıkları kapattığı için mümkün olan en kısa sürede uygulanmalıdır.

Dikkat: Bireysel sistemlerde otomatik güncelleme çoğu zaman doğru yaklaşımdır. Kurumsal ortamlarda ise güncellemeler önce test ortamında denenmeli, ardından üretim sistemlerine planlı şekilde uygulanmalıdır. Bu yaklaşım hem güvenlik açıklarının kapatılmasını sağlar hem de kritik sistemlerde beklenmedik kesintilerin önüne geçer.

2.2 Yazılım ve Sürücü Güncellemeleri

İşletim sistemi güncellemeleri güvenliğin yalnızca bir bölümünü kapsar. Sisteme kurulu uygulamalar ve donanım sürücüleri de ayrı güncelleme süreçlerine sahiptir. Bir tarayıcı, ofis uygulaması, PDF okuyucu, arşivleme programı veya medya oynatıcı kendi güvenlik açıklarını taşıyabilir. Bu açıklar işletim sistemi güncellemesiyle kapatılmaz; ilgili uygulamanın güncellenmesi gerekir.

Özellikle tarayıcılar, PDF okuyucular, ofis yazılımları ve sık kullanılan üçüncü taraf uygulamalar saldırganların hedef aldığı yazılımlar arasında yer alır. Çünkü bu uygulamalar kullanıcı tarafından sık kullanılır, internetten gelen dosyalarla etkileşime girer ve çoğu zaman hassas verilere erişir. Bu nedenle uygulama güncellemeleri, işletim sistemi güncellemeleri kadar dikkatle takip edilmelidir.

Sürücüler (drivers) ise donanım bileşenlerinin işletim sistemiyle iletişim kurmasını sağlayan yazılımlardır. Grafik kartı, ses kartı, ağ kartı, yazıcı veya depolama birimi sürücüleri bu kapsama girer. Sürücülerin bazıları düşük seviyede, hatta çekirdek düzeyinde çalışır. Bu nedenle güvenlik açığı barındıran bir sürücü istismar edildiğinde, saldırgan sistem üzerinde çok yüksek yetkiler elde edebilir.

Sürücü güncellemeleri yalnızca performans veya uyumluluk iyileştirmesi olarak görülmemelidir. Güvenlik açıklarını kapatan sürücü güncellemeleri de yayımlanabilir. Bu nedenle sürücülerin üretici tarafından sağlanan güvenilir kaynaklardan güncellenmesi gerekir.

İpucu: Yazılım güncellemelerini yönetmenin en sağlıklı yollarından biri, mümkün olan uygulamalarda otomatik güncellemeyi etkinleştirmektir. Uygulamaların kendi güncelleme bildirimlerini kapatmak, kullanıcının kritik yamalardan habersiz kalmasına neden olabilir. Ancak güncellemeler her zaman resmî kaynaklardan alınmalı, rastgele web sitelerindeki güncelleme dosyalarına güvenilmemelidir.

2.3 Windows Update Mantığı

Windows Update, Microsoft'un işletim sistemi ve yerleşik bileşenler için güncellemeleri dağıttığı merkezi mekanizmadır. Arka planda çalışır, belirli aralıklarla güncelleme denetimi yapar ve sistem ayarlarına göre güncellemeleri indirip yükler. Bazı güncellemeler yükleme sonrasında yeniden başlatma gerektirebilir.

Windows Update üzerinden gelen güncellemeler birkaç ana gruba ayrılır. Quality Updates, aylık olarak yayımlanan güvenlik ve kalite düzeltme paketleridir. Microsoft'un her ayın ikinci Salı günü güncelleme yayımlama geleneği Patch Tuesday olarak bilinir. Bu güncellemeler genellikle güvenlik açıklarını, hata düzeltmelerini ve sistem kararlılığına ilişkin iyileştirmeleri içerir.

Feature Updates, Windows'un daha büyük sürüm güncellemeleridir. Yeni özellikler, arayüz değişiklikleri veya işletim sistemi davranışındaki kapsamlı yenilikler bu kategoriye girer. Bu tür güncellemeler daha geniş etkili olduğu için özellikle kurumsal ortamlarda test edilmeden yaygın şekilde uygulanmamalıdır.

Driver Updates ise donanım sürücülerine ilişkin güncellemelerdir. Windows Update bazı sürücü güncellemelerini de dağıtabilir. Bununla birlikte kritik donanımlar için üretici sayfaları ve kurumsal yönetim araçları da takip edilmelidir.

Windows Update Ayarları ekranından güncelleme geçmişi görülebilir, bekleyen güncellemeler listelenebilir ve otomatik güncelleme tercihleri yönetilebilir. Güncelleme geçmişinde başarısız güncellemeler veya uzun süredir güncelleme yapılmadığını gösteren kayıtlar varsa bu durum incelenmelidir.

Kurumsal ortamlarda Windows güncellemeleri doğrudan her cihazın internetten güncelleme almasıyla değil, merkezi yönetim araçlarıyla uygulanabilir. Windows Server Update Services (WSUS) veya Microsoft Endpoint Manager gibi araçlar, güncellemeleri önce test etmeye, sonra belirlenen cihaz gruplarına aşamalı olarak dağıtmaya imkân verir. Bu yöntem, güvenlik ile operasyonel süreklilik arasında denge kurmayı sağlar.

2.4 Linux Paket Yöneticileriyle Güncelleme Mantığı

Linux sistemlerde yazılımlar ve güncellemeler genellikle paket yöneticisi aracılığıyla yönetilir. Kullanılan paket yöneticisi dağıtıma göre değişir. Debian ve Ubuntu tabanlı sistemlerde apt, Red Hat, CentOS ve Fedora tabanlı sistemlerde yum veya dnf, Arch Linux'ta ise pacman kullanılır.

Paket yöneticisi, sistemi resmî yazılım depolarıyla senkronize eder. Bu depolarda sistemde yüklü paketlerin daha güncel sürümleri varsa bunları kullanıcıya sunar. Güncelleme süreci genellikle iki temel aşamadan oluşur. İlk aşama paket listesini yenileme işlemidir. Bu işlem, depolarda hangi paketlerin ve sürümlerin bulunduğunu günceller. İkinci aşama ise paketleri yükseltme işlemidir. Bu aşamada sistemde yüklü paketler, depolardaki güncel sürümlerle değiştirilir.

Bu ayrımı bilmek önemlidir. Örneğin apt update komutu sistemi güncellemez; yalnızca paket listesini yeniler. Asıl paket yükseltme işlemi apt upgrade veya uygun başka bir yükseltme komutuyla yapılır. Bu nedenle yalnızca paket listesini yenilemek, güvenlik yamalarının sisteme uygulandığı anlamına gelmez.

Linux paket yöneticilerinin önemli avantajlarından biri, yalnızca işletim sistemi bileşenlerini değil, paket yöneticisi aracılığıyla kurulmuş birçok uygulamayı da merkezi olarak güncelleyebilmesidir. Bu yapı, güncellemeleri daha tutarlı ve denetlenebilir hâle getirir.

Buna rağmen Linux sistemlerde de güncellemeler ertelendiğinde açıklar birikir. "Linux güvenlidir, güncelleme yapmama gerek yok." düşüncesi yanlıştır. Linux sistemler de güvenlik açıklarına, yanlış yapılandırmalara ve eski paketlerden kaynaklanan risklere açıktır. Özellikle internete açık sunucularda paket güncellemelerinin düzenli takip edilmesi kritik öneme sahiptir.

3. Güvenli Güncelleme Alışkanlığı

3.1 Resmî Kaynaklardan Güncelleme

Güncellemeler yalnızca resmî ve güvenilir kaynaklardan alınmalıdır. Windows için bu kaynak Microsoft'un güncelleme altyapısı veya kurumsal ortamlarda WSUS gibi merkezi güncelleme sistemleridir. Linux için dağıtımın resmî paket depoları, macOS için Apple'ın Software Update mekanizması, uygulamalar için ise üreticinin resmî web sitesi veya resmî uygulama mağazaları tercih edilmelidir.

Resmî kaynak dışından yapılan güncellemeler ciddi risk taşır. Öncelikle paketin gerçekten üretici tarafından hazırlanıp hazırlanmadığı doğrulanamayabilir. Paket bütünlüğü garanti edilemez. Dosya değiştirilmiş, içine zararlı yazılım eklenmiş veya sahte bir kurulum dosyası oluşturulmuş olabilir.

Linux paket yöneticileri, resmî depolardaki paketleri kriptografik imzalarla doğrular. Bu güven modeli, sisteme hangi yazılımın güvenilir kabul edileceğini belirler. Ancak sisteme dış depo eklendiğinde bu güven modeli genişletilmiş olur. Her dış depo güvenilir değildir. Bu yüzden üçüncü taraf depolar dikkatle değerlendirilmelidir.

Benzer şekilde Windows veya macOS kullanıcılarının da rastgele web sitelerinden "güncelleme" dosyası indirmesi güvenli değildir. Bir uygulama güncellenecekse uygulamanın kendi güncelleme mekanizması, resmî web sitesi veya işletim sisteminin güvenilir mağaza altyapısı kullanılmalıdır.

Güvenli Alışkanlık: Herhangi bir web sitesinde gördüğünüz "güncelleme" bağlantısına hemen tıklamayın. Güncelleme gerekiyorsa işletim sisteminin kendi güncelleme mekanizmasını veya uygulamanın resmî sitesini kullanın. "Güncelleyin" yazan her uyarı gerçek bir güncelleme değildir.

3.2 Sahte Update ve Zararlı Yazılım Riski

Sahte güncelleme saldırıları, meşru sistem veya uygulama güncellemelerini taklit eden aldatıcı içeriklere dayanır. Kullanıcı bir web sitesini ziyaret ettiğinde ekranda "Tarayıcınızı güncelleyin", "Flash Player güncellemesi gerekiyor", "Java güncellemesi mevcut" veya "Video izlemek için eklentiyi güncelleyin" gibi mesajlar görebilir. Bu mesajlar gerçek güncelleme değil, zararlı yazılım indirme girişimi olabilir.

Bu saldırıların amacı kullanıcının güvenini kazanmaktır. Güncelleme kavramı kullanıcılara tanıdık geldiği için saldırganlar bu yöntemi sıkça kullanır. Kullanıcı, sistemini koruduğunu düşünerek aslında zararlı bir dosyayı indirip çalıştırabilir.

Sahte güncelleme uyarılarını tanımak için bazı işaretlere dikkat edilmelidir. Uyarı işletim sisteminin kendi bildirim alanından değil de tarayıcı penceresinin içinden geliyorsa şüphelidir. Mesaj kullanıcıyı hemen harekete geçmeye zorluyorsa, panik duygusu yaratıyorsa veya bağlantı uygulamanın resmî alan adıyla uyuşmuyorsa dikkatli olunmalıdır.

Gerçek işletim sistemi güncellemeleri genellikle tarayıcı içindeki rastgele bir web sayfasından gelmez. Windows Update, macOS Software Update veya Linux paket yöneticisi gibi sistemin kendi mekanizmaları üzerinden sunulur. Şüphe duyulduğunda yapılması gereken en doğru şey, tarayıcıdaki uyarıya tıklamak yerine işletim sisteminin ayarlar menüsünden veya resmî güncelleme aracından kontrol yapmaktır.

Unutma: Sahte güncelleme saldırılarına karşı kullanıcı farkındalığı çok önemlidir. Çünkü saldırı çoğu zaman teknik bir açıktan değil, kullanıcının güvenini kötüye kullanmaktan beslenir.

3.3 Güncelleme Öncesi Temel Hazırlık

Özellikle büyük güncellemeler, sürüm yükseltmeleri veya kritik sistemleri etkileyen yamalar uygulanmadan önce temel hazırlık adımları izlenmelidir. Bu hazırlık, olası bir sorun durumunda geri dönüş yolunu açık tutar ve güncelleme sonrası sistemin doğru çalışıp çalışmadığını doğrulamayı kolaylaştırır.

İlk adım ve en kritik adım veri yedeği almaktır.Güncellemeler genellikle güvenli şekilde uygulanır; ancak nadiren de olsa veri kaybı, sistem açılış sorunu veya uygulama uyumsuzluğu yaşanabilir. Güncel ve doğrulanmış bir yedek yoksa bu riskler çok daha ciddi hâle gelir.

İkinci adım disk alanını kontrol etmektir. Büyük güncellemeler, kurulum sırasında ek disk alanına ihtiyaç duyabilir. Yetersiz disk alanı güncellemenin yarıda kalmasına veya sistemin kararsız çalışmasına neden olabilir.

Üçüncü adım, özellikle kurumsal ortamlarda kritik uygulama uyumluluğunu değerlendirmektir. Güncelleme sonrasında muhasebe, üretim, çağrı merkezi, veritabanı veya özel kurum içi uygulamalar çalışmaz hâle gelirse operasyonel kesinti oluşabilir. Bu nedenle kritik uygulamaların güncellemeyle uyumlu olup olmadığı önceden kontrol edilmelidir.

Sunucu ve üretim ortamlarında güncellemeyi doğrudan canlı sisteme uygulamak yerine önce test veya staging ortamında denemek daha güvenlidir. Staging ortamı, üretim sistemine benzer şekilde yapılandırılmış hazırlık ortamıdır. Güncellemeler burada test edilerek olası sorunlar erkenden fark edilebilir.

Dikkat: Bu hazırlık adımları güncellemeyi yavaşlatmak için değil, güvenli ve kontrollü hâle getirmek için uygulanır. Amaç güncellemeyi ertelemek değil, riski yöneterek uygulamaktır.

3.4 Güncelleme Sonrası Temel Kontrol Adımları

Güncelleme tamamlandıktan sonra sürecin bittiği varsayılmamalıdır. Güncellemenin gerçekten başarıyla uygulanıp uygulanmadığı ve sistemin beklenen şekilde çalışıp çalışmadığı doğrulanmalıdır.

İlk olarak güncelleme geçmişi kontrol edilmelidir. Güncelleme başarılı mı yüklenmiş, hata kodu var mı, yeniden başlatma bekleniyor mu gibi bilgiler incelenmelidir. Bazı güncellemeler indirilmiş ama yüklenmemiş olabilir. Bazıları yüklenmiş ama yeniden başlatma yapılmadığı için tam olarak etkinleşmemiş olabilir.

İkinci olarak sistem sürümü doğrulanmalıdır. Windows'ta winver, Linux'ta lsb_release -a, macOS'ta sw_vers gibi komutlarla güncelleme sonrası sürüm bilgisi kontrol edilebilir. Bu adım, sistemin beklenen sürüme gerçekten geçtiğini gösterir.

Üçüncü olarak kritik servis ve uygulamaların çalıştığı doğrulanmalıdır. Özellikle sunucularda web servisi, veritabanı, kimlik doğrulama servisi, yedekleme servisi veya kurum için kritik uygulamalar kontrol edilmelidir.

Sunucu ortamlarında güncelleme sonrası kısa bir smoke test yapılması önemlidir. Smoke test, uygulamanın temel işlevlerinin hızlıca denenmesidir. Örneğin web uygulaması açılıyor mu, kullanıcı giriş yapabiliyor mu, veritabanı bağlantısı çalışıyor mu, temel işlem akışı tamamlanabiliyor mu gibi kontroller yapılır.

Dikkat: Güncelleme sonrası servis çökmesi, uygulama hatası, performans düşüşü veya beklenmedik davranışlar görülürse bunun güncellemeyle ilişkili olup olmadığı araştırılmalıdır. Gerekli durumlarda rollback planı devreye alınmalıdır. Rollback, sorunlu güncelleme sonrasında önceki kararlı duruma geri dönme sürecidir.

Komut & Araç Okuryazarlığı

Bu bölümdeki komutlar ve araçlar, sistemlerin güncelleme durumunu denetlemek için kullanılır. Amaç sistemi rastgele güncellemek değil; mevcut sürümü, son güncelleme tarihini, bekleyen paketleri ve destek durumunu güvenli şekilde gözlemlemektir.

Windows'ta Temel Kontrol

Güncelleme Loglarını Okunabilir Hale Getirme ve Analiz Etme

Komut:

Get-WindowsUpdateLog (PowerShell)

Amaç: Windows Update tarafından üretilen .etl izleme dosyalarını birleştirip okunabilir bir WindowsUpdate.log dosyasına dönüştürür.

Beklenen çıktı:

Bu komut bekleyen güncellemeleri veya tam Windows Update geçmişini listelemez; Windows Update tanılaması için ETW/.etl izleme dosyalarını okunabilir log hâline getirir.

Yüklü Güncellemeleri Listeleme

Komut:

powershell Get-HotFix
     Alternatif: Get-CimInstance Win32_QuickFixEngineering
                    

Amaç: Sistemde kayıtlı bazı Windows hotfix/KB güncellemelerini ve yüklenme tarihlerini listeler.

Beklenen çıktı:

Önemli: WMIC artık modern Windows için güvenilir bir varsayılan araç değil. Microsoft dokümantasyonuna göre Windows 11 24H2'den itibaren WMIC öntanımlı olarak kurulu gelmiyor; Windows 11 25H2'de kaldırılan/deprecated bileşenler arasında yer alıyor ve gelecekte tamamen kaldırılması bekleniyor. Güncel alternatif için Get-HotFix kullanılabilir.

Bu komut, Windows sistemde hangi yamaların kurulu olduğunu görmek için kullanılır. Son güncelleme tarihinin uzun süre önceye ait olması, sistemin bilinen açıklar açısından risk taşıyabileceğini gösterir.

Windows Sürümünü Görme

Komut:

winver

Amaç: Windows sürümünü ve derleme numarasını gösterir.

Beklenen çıktı:

winver, Windows sürümünü hızlıca görmek için kullanılır. Güncelleme denetimlerinde sürüm ve derleme numarası mutlaka kayıt altına alınmalıdır.

Windows Update Ayarları

Windows Update ekranı grafik arayüz üzerinden de kontrol edilebilir. Başlat menüsünden Ayarlar → Windows Update yoluyla açılabilir. Alternatif olarak ms-settings:windowsupdate komutu kullanılabilir.

Bu ekranda sistemin güncel olup olmadığı, bekleyen güncellemeler, yeniden başlatma gerekliliği ve güncelleme geçmişi görülebilir. "Güncel durumdasınız" mesajı tek başına yeterli kabul edilmemeli; son başarılı güncelleme tarihi ve başarısız güncelleme kayıtları da incelenmelidir.

Normal durumda otomatik güncelleme açık olmalı, son güncellemeler yakın tarihli olmalı ve başarısız güncelleme kayıtları bulunmamalıdır. Otomatik güncellemenin kapalı olması, güncelleme geçmişinde tekrar eden hatalar görülmesi veya bekleyen güncellemelerin uzun süre uygulanmamış olması dikkat gerektirir.

Linux'ta Temel Kontrol

Paket Listesini Yenileme ve Güncellemeleri Görme

Komut:

sudo apt update && apt list --upgradable 2>/dev/null

Amaç: Depo bilgilerini yenileyerek yükseltme bekleyen paketleri listeler.

Beklenen çıktı:

Bu komut Debian ve Ubuntu tabanlı sistemlerde güncelleme durumunu görmek için kullanılır. apt update yalnızca depo bilgisini yeniler; paketleri yükseltmez. Bu nedenle güncelleme uygulanmış sayılmaz. apt list \--upgradable ise güncellenebilir paketleri listeler.

Yüklü Paket Sürümünü Görme

Komut:

apt-cache policy openssl

Amaç: Belirli bir paketin yüklü sürümünü ve depodaki güncel sürümü karşılaştırır.

Beklenen çıktı:

Bu komut, belirli bir paketin sistemde hangi sürümünün kurulu olduğunu ve depoda hangi sürümün bulunduğunu görmek için kullanılır. Özellikle OpenSSL, çekirdek paketleri, web sunucuları ve uzaktan erişim bileşenleri gibi kritik paketlerde bu karşılaştırma önemlidir.

Sistem Sürümünü ve Destek Durumunu Görme

Komut:

lsb_release -a

Amaç: Linux dağıtımının sürüm bilgilerini gösterir.

Beklenen çıktı:

Bu komut Linux dağıtımının sürüm bilgisini gösterir. Destek süresi dolmuş veya dolmak üzere olan sürümler, güvenlik açısından planlama gerektiren bulgulardır.

Red Hat/CentOS/Fedora için Güncelleme Durumu

Komut:

sudo dnf check-update

Amaç: Sistemde güncellenebilir paketleri listeler; yükleme yapmaz.

Beklenen çıktı:

Bu komut Red Hat, CentOS ve Fedora tabanlı sistemlerde güncellenebilir paketleri görmek için kullanılır. Yükleme yapmadığı için denetim amacıyla güvenli şekilde çalıştırılabilir.

macOS'ta Temel Kontrol

Bekleyen Yazılım Güncellemelerini Görme

Komut:

softwareupdate -l

Amaç: Sistemde mevcut macOS güncellemelerini ve uygulama güncellemelerini listeler.

Beklenen çıktı:

Bu komut, macOS üzerinde bekleyen güncellemeleri görmek için kullanılır. Yalnızca listeleme yaptığı için sistemde değişiklik yapmaz.

macOS Sürümünü Görme

Komut:

sw_vers

Amaç: macOS sürüm ve derleme numarasını gösterir.

Beklenen çıktı:

sw_vers, macOS sürüm bilgisini hızlıca görmek için kullanılır. Güncelleme denetimlerinde mevcut sürüm ve derleme numarası kayıt altına alınmalıdır.

macOS Software Update

macOS'ta güncelleme durumu grafik arayüzden de incelenebilir. Bunun için Apple menüsünden Sistem Ayarları → Genel → Yazılım Güncellemesi yoluna gidilir.

Bu ekranda mevcut güncellemeler, otomatik güncelleme seçeneğinin durumu, güncelleme adı ve açıklaması görülebilir. Bekleyen güncelleme varsa adı, sürümü ve önerilen veya zorunlu olup olmadığı not edilmelidir. Kanıt amacıyla ekran görüntüsü alınabilir ve mevcut sürüm bilgisiyle birlikte saklanabilir.

Temel Uygulama / Kontrol Listesi

Bu kontrol listesi, bir sistemin güncelleme durumunu temel düzeyde değerlendirmek için kullanılabilir. Amaç, işletim sistemi sürümünü, son güncelleme tarihini, bekleyen güncellemeleri, otomatik güncelleme durumunu ve destek süresini kayıt altına almaktır.

Hazırlık

• Hangi sistemi incelediğinizi not edin: işletim sistemi, sürüm ve tarih.
• Mevcut sistem sürümünü kaydedin: Windows için winver, Linux için lsb_release -a, macOS için sw_vers.
• Değerlendirme sonuçlarını kaydedeceğiniz bir not dosyası hazırlayın.
• Büyük bir güncelleme uygulanacaksa güncel yedek olup olmadığını doğrulayın.

Kontrol Adımları

• İşletim sisteminin güncel sürümde mi yoksa geride mi olduğunu tespit edin.
• Son güncellemenin ne zaman uygulandığını kontrol edin.
• Bekleyen güncelleme olup olmadığını kontrol edin.
• Bekleyen güncelleme varsa güvenlikle ilgili olup olmadığını değerlendirin.
• Otomatik güncellemenin etkin olup olmadığını kontrol edin.
• Sistemin destek süresinin dolup dolmadığını, yani EOL durumunu kontrol edin.
• Kritik uygulamaların güncel olup olmadığını inceleyin: tarayıcı, ofis yazılımı, PDF okuyucu, arşiv yazılımı gibi.
• Sürücü güncellemelerinin gerekli olup olmadığını değerlendirin.

Doğrulama

• Güncelleme geçmişinde başarısız güncelleme kaydı var mı? Varsa hata kodunu not alın.
• Güncelleme uygulandıysa sistem sürümünün değiştiğini komutla teyit edin.
• Güncelleme sonrası kritik servislerin çalışıp çalışmadığını kontrol edin.
• Yeniden başlatma gerekiyorsa sistemin yeniden başlatılıp başlatılmadığını doğrulayın.
• Bekleyen başka güncelleme kalıp kalmadığını tekrar kontrol edin.

Kanıt Notu

• Sistem sürümü, güncelleme geçmişi ve bekleyen güncelleme listesinin ekran görüntülerini tarih bilgisiyle kaydedin.
• Her bulgu için şu bilgileri not alın: hangi sistem, hangi sürüm, son güncelleme tarihi, bekleyen güncelleme sayısı.
• Başarısız güncellemeler varsa hata kodunu ve tekrar sayısını kaydedin.
• Destek dışı sistem tespit edilirse sistem adı, sürüm bilgisi ve ilgili destek durumu yazılı olarak belgelenmelidir.

Geri Dönüş / Dikkat Edilmesi Gerekenler

• Büyük güncellemeler öncesinde veri yedeği alın.
• Sunucu veya üretim ortamlarında güncellemeyi iş saatleri dışına planlayın.
• Güncelleme sonrası olası servis çökmelerini izlemek için hazırlıklı olun.
• Destek dışı kalmış bir sistem tespit ederseniz ilgili yöneticiyi yazılı olarak bilgilendirin.
• Güncellemeyi rastgele kaynaklardan değil, yalnızca resmî mekanizmalardan uygulayın.
• Kritik sistemlerde güncelleme sonrası rollback planının hazır olduğundan emin olun.

Temel Operasyonel Senaryo

Senaryo: "Kritik Güvenlik Güncellemesi Uygulanmamış Sistem"

Bir kurumdaki IT denetimi sırasında, muhasebe departmanında kullanılan bir Windows iş istasyonunun güncelleme geçmişi incelenir. İnceleme sonucunda son başarılı güncellemenin dokuz ay önce uygulandığı görülür. Bu süre boyunca yayımlanan kritik güvenlik yamalarının hiçbirinin sisteme yüklenmediği anlaşılır.

Bu durumda ilk olarak güncelleme sürecinin neden durduğu araştırılmalıdır. Otomatik güncelleme devre dışı mı bırakılmıştır? Güncellemeler başarısız mı olmuştur? Sistem güncelleme sunucusuna erişemiyor mudur? Yoksa kullanıcı veya yapılandırma nedeniyle güncelleme mekanizması aktif olarak engellenmiş midir? Dokuz aylık güncelleme boşluğu, bu sistemin çok sayıda bilinen açığa maruz kalmış olabileceğini gösterir.

Kontrol edilecek noktalar şunlardır:

1. 1. Mevcut Windows sürümü ve derleme numarası alınır.
2. 2. wmic qfe list brief, Get-HotFix veya Get-CimInstance Win32_QuickFixEngineering komutuyla yüklü yamalar ve uygulama tarihleri listelenir. Güncel sistemlerde Get-HotFix ile yapılır
3. 3. Windows Update Ayarları üzerinden otomatik güncelleme durumu kontrol edilir.
4. 4. Windows Update geçmişinde başarısız güncelleme kayıtları incelenir.
5. 5. Sistemin Microsoft'un destek takvimine göre hâlâ desteklenip desteklenmediği kontrol edilir.

Toplanacak kanıtlar:

• winver ekran görüntüsü
• wmic qfe list brief / Get-HotFix / Get-CimInstance Win32_QuickFixEngineering çıktısı
• Windows Update Ayarları ekranının ekran görüntüsü
• Güncelleme geçmişinde başarısız kayıtlar varsa bu kayıtların ekran görüntüsü
• İnceleme tarihi, saati ve incelemeyi yapan kişinin adı

                        # Windows Sürüm ve Yama Uyumluluk Denetimi | Analist: [İsim]
                        
                        PS C:\> winver
                        Microsoft Windows [Sürüm 10.0.22621.1]
                        OS Build: 22621 (Windows 11 22H2)
                        
                        PS C:\> Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 3
                        Source         Description      HotFixID      InstalledBy          InstalledOn
                        ------         -----------      --------      -----------          -----------
                        WIN-LAB01      Update           KB5025239     SYSTEM               12.04.2026
                        WIN-LAB01      Security Update  KB5023706     SYSTEM               15.03.2026
                        # ANALİZ: Son başarılı yama Nisan 2026'da uygulanmış.
                        
                        PS C:\> Get-WindowsUpdateStatus
                        [!] Uyarı: 12 Kümülatif Güncelleme Bekleniyor.
                        [!] Durum: Güncelleştirmeler duraklatılmış (Bağlantı ölçümlü ağ algılandı).
                        
                        PS C:\> Get-UpdateHistory | Where-Object {$_.ResultCode -eq "Failed"}
                        # Kayıt bulunamadı. (Güncelleştirmeler hiç indirilmeye başlanmamış.)
                        
                        

                        GÜVENLİK DENETİM BULGULARI:
                        - YAMA DURUMU: Sistem güncel kararlı sürümün 12 paket gerisinde.
                        - YAPILANDIRMA HATASI: "Bağlantı ölçümlü ağ" ayarı nedeniyle otomatik güncellemeler bloklanmış.
                        - RİSK: Bilinen zafiyetlere karşı (Nisan ayından beri) sistem korumasız durumda.
                        - ÖNERİ: Ölçümlü bağlantı kısıtlamasının kaldırılması ve bekleyen KB paketlerinin ivedilikle yüklenmesi gerekir.
                        

İnceleme sırasında winver çıktısı, sistemin Windows 11 Version 22H2 derleme 22621 üzerinde çalıştığını göstermektedir. Microsoft'un yayımladığı son sürümle karşılaştırıldığında sistemin 12 kümülatif güncellemeden geride olduğu anlaşılır. wmic qfe list çıktısından son yamanın Nisan ayında uygulandığı görülür. Windows Update Ayarları incelendiğinde otomatik güncelleme seçeneğinin "Bağlantı ölçümlü" yapılandırması nedeniyle güncellemeleri indirmediği anlaşılır.

Bu bulgular sistemin dokuz ay boyunca yayımlanan güvenlik yamalarından yoksun kaldığını gösterir. Bu durum aktif bir güvenlik bulgusudur. Otomatik güncelleme ayarı düzeltilmeli, bekleyen yamalar en kısa sürede uygulanmalı ve aynı yapılandırma hatasının diğer sistemlerde de olup olmadığı kontrol edilmelidir.

Bulgu → Etki → Öneri → Kanıt

Bulgu: Muhasebe departmanında kullanılan DESKTOP-ACC01 iş istasyonunda son güncelleme dokuz ay önce uygulanmıştır. Sistem, bu süre içinde Microsoft tarafından yayımlanan 12 kümülatif güncellemeyi ve bu güncellemeler içindeki kritik güvenlik yamalarını içermemektedir. Otomatik güncelleme seçeneğinin yanlış yapılandırma nedeniyle devre dışı kaldığı tespit edilmiştir.

Etki:Sistem, kamuoyunda belgelenmiş ve dokuz ay boyunca yama uygulanmamış çok sayıda güvenlik açığını barındırmaktadır. Muhasebe verilerine erişen ve ağa bağlı olan bu cihaz, ağ içi yayılım veya veri sızdırma girişimleri için kolay hedef konumundadır.

Öneri:Otomatik güncelleme ayarı derhal düzeltilmeli ve sistem güncel sürüme yükseltilmelidir. Büyük güncelleme paketi uygulanmadan önce veri yedeği alınmalıdır. Departmandaki diğer iş istasyonlarının güncelleme durumu da denetlenmeli; benzer bir yapılandırma hatası olup olmadığı kontrol edilmelidir. Güncelleme politikasının merkezi olarak yönetilmesi için WSUS veya benzeri bir mekanizma değerlendirilmelidir.

Kanıt:Get-HotFix veya Get-CimInstance Win32_QuickFixEngineering çıktısı; gerekiyorsa eski Windows sistemlerde wmic qfe list brief çıktısı., Windows Update Ayarları ekranının ekran görüntüsü, incelemeyi yapan kişinin adı ve inceleme tarihi ile saati kayıt altına alınmalıdır.

Kendini Değerlendir — Güncelleme ve Yama Yönetimi

Terimler Sözlüğü

Bu Modülde Kazanılan Yetkinlikler

• Bu modülde güvenlik yamalarının yalnızca teknik bir düzeltme değil, aktif bir savunma adımı olduğunu öğrendik. Yamanın uygulanmaması ile sistemin bilinen açıklarla saldırıya açık kalması arasındaki doğrudan ilişkiyi kavradık.
• Bir güvenlik açığının keşfinden kapatılmasına uzanan exploit yaşam döngüsünü ele aldık. Açık kamuoyuna duyurulduktan sonra saldırı araçlarının hızla ortaya çıkabileceğini ve bu nedenle erken güncellemenin savunma açısından kritik olduğunu gördük.
• Güncellenmeyen sistemlerin otomatik tarama araçlarıyla kolayca tespit edilip hedef alınabildiğini öğrendik. Zamanında yapılan güncellemelerin saldırı olasılığını önemli ölçüde düşürdüğünü kavradık.
• Destek süresi bitmiş, yani EOL durumundaki sistemlerin neden özel risk taşıdığını inceledik. Destek süresi dolan bir sistemde yeni keşfedilen açıkların artık standart güncelleme mekanizmasıyla kapatılamayacağını öğrendik.
• İşletim sistemi güncellemeleri, yazılım güncellemeleri ve sürücü güncellemelerinin birbirinden bağımsız süreçler olduğunu gördük. Her birinin güvenlik zincirinin ayrı bir halkasını oluşturduğunu değerlendirdik.
• Windows Update mekanizmasının nasıl çalıştığını, Quality Update, Feature Update ve Driver Update ayrımını, Patch Tuesday döngüsünü ve kurumsal ortamlarda WSUS gibi araçların bu süreci nasıl merkezileştirdiğini öğrendik.
• Linux paket yöneticilerinin güncelleme mantığını ele aldık. apt update ile apt upgrade arasındaki farkı, paket listesini yenilemenin güncelleme yapmak anlamına gelmediğini ve paket yöneticilerinin merkezi güncelleme yönetimindeki rolünü kavradık.
• Güncellemelerin yalnızca resmî kaynaklardan alınması gerektiğini gördük. Üçüncü taraf kaynaklardan veya rastgele web sitelerinden indirilen güncellemelerin paket bütünlüğü ve güvenilirlik açısından ciddi risk taşıdığını öğrendik.
• Sahte güncelleme tuzaklarını tanımanın temel yollarını değerlendirdik. Gerçek sistem güncellemelerinin genellikle tarayıcı penceresinden değil, işletim sisteminin kendi güncelleme mekanizmasından geldiğini kavradık.
• Güncelleme öncesinde veri yedeği almak, disk alanını kontrol etmek, kritik uygulama uyumluluğunu değerlendirmek ve gerektiğinde staging ortamı kullanmak gibi hazırlık adımlarının neden önemli olduğunu öğrendik.
• Güncelleme sonrasında sistem sürümünü doğrulama, güncelleme geçmişini inceleme, kritik servisleri kontrol etme ve smoke test yapma gibi adımların süreci tamamlayan önemli kontroller olduğunu gördük.
• Son olarak winver, wmic qfe list, apt list \--upgradable, apt-cache policy, dnf check-update, softwareupdate -l ve sw_vers gibi komutları güncelleme durumu denetimi için nasıl kullanabileceğimizi öğrendik.

Modül Teması

Zararlı yazılımlar, yani malware, bir sisteme zarar vermek, yetkisiz erişim sağlamak, veri çalmak veya kullanıcıyı manipüle etmek amacıyla tasarlanmış kötü amaçlı yazılımların genel adıdır. Günümüzde zararlı yazılım tehdidi yalnızca teknik bir problem değildir; insan davranışını, sistem yapılandırmasını, güncelleme alışkanlıklarını ve günlük kullanım pratiklerini doğrudan etkileyen çok katmanlı bir güvenlik riskidir.

Her yıl milyonlarca kullanıcı ve kurum zararlı yazılımlardan etkilenmekte; veri kaybı, fidye ödemeleri, operasyonel kesintiler ve itibar kaybı gibi ciddi sonuçlarla karşılaşmaktadır. Bu nedenle zararlı yazılımlara karşı korunmak yalnızca antivirüs kurmakla sınırlı değildir. Tehdit türlerini tanımak, bulaşma yollarını anlamak, güvenli davranış alışkanlıkları geliştirmek ve sistemdeki olağandışı belirtileri fark edebilmek gerekir.

Bu modülde zararlı yazılımların başlıca türlerini - virüs, worm, trojan, ransomware, spyware, keylogger ve rootkit - ele alacağız. Bu yazılımların nasıl çalıştığını, sisteme nasıl zarar verdiğini ve hangi belirtilerle kendini gösterebileceğini inceleyeceğiz. Ardından bu tehditlerin sisteme nasıl girdiğine odaklanacağız: e-posta ekleri, crack ve keygen araçları, sahte yazılım kurulumları, USB cihazları, web indirmeleri ve zararlı bağlantılar.

Modülün son bölümünde temel korunma yöntemlerini değerlendireceğiz. Antivirüs ve antimalware araçlarının çalışma mantığını, gerçek zamanlı korumanın önemini, güvenli indirme alışkanlıklarını ve kullanıcı farkındalığının savunmadaki rolünü ele alacağız. Bu modülü tamamladığınızda zararlı yazılım türlerini ayırt edebilecek, bulaşma yollarını tanıyabilecek ve işletim sistemini korumak için hangi temel adımları uygulamanız gerektiğini daha net biçimde görebileceksiniz.

1. Temel Tehdit Türleri

1.1 Virüs, Worm, Trojan ve Ransomware

Zararlı yazılım dünyasında sık karşılaşılan tehdit türleri benzer sonuçlar doğurabilir; ancak çalışma, yayılma ve sisteme zarar verme biçimleri birbirinden farklıdır. Bu farkları bilmek, hem doğru önlemi almak hem de bir olay sırasında neyle karşı karşıya olunduğunu anlamak açısından önemlidir.

Virüs (Virus), kendini meşru bir dosyaya veya programa ekleyerek çoğalan zararlı koddur. Biyolojik virüsler gibi bir konağa ihtiyaç duyar. Kullanıcı virüs bulaşmış dosyayı çalıştırdığında zararlı kod devreye girer. Virüsler tek başına yayılmaz; başka bir dosyaya, belgeye veya önyükleme alanına tutunarak hareket eder. Çalıştırılabilir dosyalar, belge makroları ve önyükleme sektörleri virüslerin hedef alabileceği alanlar arasındadır.

Worm (Solucan), virüsten farklı olarak kendini başka bir dosyaya bağlamak zorunda kalmadan ağ üzerinde bağımsız biçimde çoğalabilen zararlı yazılımdır. Bir sistemden diğerine kullanıcı etkileşimi olmadan geçebilir. Genellikle ağ açıklarını, zayıf servis yapılandırmalarını veya güncellenmemiş sistemleri kullanarak yayılır. Bu nedenle özellikle kurumsal ağlarda çok kısa sürede geniş bir etki alanına ulaşabilir.

Trojan (Truva Atı), meşru veya yararlı görünen bir uygulama görünümü altında gizlenen zararlı yazılımdır. Adını Yunan mitolojisindeki Truva Atı'ndan alır. Dışarıdan masum ya da faydalı görünür; ancak içinde kötü amaçlı işlevler barındırır. Ücretsiz sunulan bir araç, oyun modu, sistem hızlandırıcı, sahte güncelleme dosyası veya yardımcı program trojan olabilir. Kullanıcı bu yazılımı kendi isteğiyle çalıştırır; çoğu zaman sisteme sızması için bir kez çalıştırılması yeterlidir.

Ransomware (Fidye Yazılımı), sisteme sızdıktan sonra dosyaları şifreleyen ve kullanıcının verilerine erişimini engelleyen zararlı yazılım türüdür. Ardından erişimi geri vermek için para talep eder. Son yıllarda hem bireysel kullanıcılar hem de kurumlar için en yıkıcı tehditlerden biri hâline gelmiştir. Ransomware saldırılarında kullanılan şifreleme çoğu zaman gerçek ve güçlüdür; anahtar saldırganın elindedir. Fidye ödemek verilerin geri alınacağını garanti etmez. Bu tehdide karşı en sağlam korunma yaklaşımı güncel yedek, güncel sistem ve kullanıcı farkındalığı üçlüsüdür.

1.2 Spyware ve Keylogger Mantığı

Bazı zararlı yazılımlar sistemi çökertmeyi veya dosyaları şifrelemeyi hedeflemez. Bunun yerine kullanıcının farkına varmadan bilgi toplar, izleme yapar ve elde ettiği verileri saldırgana iletir. Spyware ve keylogger bu tür tehditlerin en bilinen örneklerindendir.

Spyware (Casus Yazılım), kullanıcının bilgisi ve izni olmadan sistemdeki etkinlikleri izleyen, bilgi toplayan ve bu bilgileri üçüncü bir tarafa gönderen yazılımdır. Ziyaret edilen web siteleri, form girişleri, uygulama kullanımı, ekran görüntüleri ve bazen sistemdeki dosya hareketleri spyware tarafından takip edilebilir. Spyware genellikle görünmez biçimde çalışır ve kullanıcı farkında olmadan uzun süre aktif kalabilir.

Keylogger (Tuş Kaydedici), klavyede basılan tuşları kaydeden ve bu kayıtları saldırgana ileten yazılım veya donanım türüdür. Kullanıcı adı, parola, kredi kartı numarası, özel mesajlar ve diğer hassas bilgiler klavyeden girildiği anda kaydedilebilir. Keylogger'lar iki biçimde karşımıza çıkabilir. Yazılımsal keylogger'lar arka planda çalışan süreçler olarak sisteme yerleşir. Donanımsal keylogger'lar ise klavye ile bilgisayar arasına takılan fiziksel aygıtlar olabilir.

Spyware ve keylogger tehditlerinin ortak hedefi gizliliktir. Bu yazılımlar genellikle sistemi çökertmez, kullanıcının dikkatini çekecek açık bir belirti vermeyebilir ve uzun süre sessiz kalabilir. Bu nedenle düzenli güvenlik taramaları, ağ trafiği izleme, bilinmeyen süreçleri kontrol etme ve şüpheli başlangıç öğelerini inceleme bu tehditleri fark etmenin temel yollarındandır.

1.3 Rootkit'in Temel Çalışma Mantığı

Rootkit, işletim sisteminin derin katmanlarına, çoğu zaman çekirdek düzeyine sızarak hem kendi varlığını hem de barındırdığı diğer zararlı bileşenleri gizlemeye çalışan yazılımdır. Adı, Unix/Linux dünyasındaki en yüksek yetki anlamına gelen "root" ve araç seti anlamındaki "kit" sözcüklerinden gelir.

Rootkit'i özellikle tehlikeli yapan şey, sistemin kendi görme ve raporlama mekanizmalarını manipüle edebilmesidir. Normalde bir süreç listesini görüntülediğinizde çalışan uygulamaları görmeyi beklersiniz. Ancak rootkit bulaşmış bir sistemde zararlı süreçler listede görünmeyebilir. Dosya sistemi sorgulandığında zararlı dosyalar gizlenebilir. Ağ bağlantıları kontrol edildiğinde rootkit kendi trafiğini saklayabilir. Bu nedenle rootkit bulaşmış bir sistemde standart araçlarla yapılan analiz güvenilir olmayabilir.

Rootkit temizliği çoğu zaman basit bir antivirüs taramasıyla tamamlanmaz. Özel rootkit tarama araçları, sistem dışından önyükleme yapan kurtarma ortamları veya bazı durumlarda işletim sisteminin tamamen yeniden kurulması gerekebilir. Bu yüzden rootkit tehdidine karşı en etkili yaklaşım, bulaşma gerçekleştikten sonra temizlemeye çalışmaktan çok önleyici güvenlik önlemlerini güçlü tutmaktır.

Güvenilir kaynaklardan yazılım kurmak, işletim sistemi ve sürücü güncellemelerini aksatmamak, ayrıcalıklı hesapları sınırlamak ve bilinmeyen yazılımları yüksek yetkiyle çalıştırmamak rootkit riskini azaltan temel davranışlardır.

1.4 Zararlı Yazılımın Sistem Üzerindeki Etkileri

Zararlı yazılımların sistem üzerindeki etkileri türüne ve amacına göre değişir. Bazıları dosyaları şifreler, bazıları bilgi toplar, bazıları sistemi başka saldırılar için aracı olarak kullanır. Yine de belirli belirtiler zararlı yazılım şüphesi doğurabilir.

Performans sorunları, en yaygın belirtilerden biridir. İşlemci veya bellek kullanımı beklenmedik biçimde yükselmişse, sistem normalden daha yavaş çalışıyorsa, fan sürekli yüksek devirde çalışıyorsa veya cihaz boşta olmasına rağmen kaynak tüketimi devam ediyorsa arka planda gizli bir süreç çalışıyor olabilir. Kripto madenciliği yapan zararlı yazılımlar bu şekilde fark edilebilir.

Ağ davranışındaki değişiklikler de önemli bir göstergedir. Sistem arka planda yoğun ağ trafiği üretiyorsa, bilinmeyen dış IP adreslerine bağlantı kuruyorsa veya olağandışı portlar üzerinden veri gönderiyorsa spyware, trojan veya veri sızdırma amaçlı bir bileşen devrede olabilir.

Sistem davranışındaki değişiklikler de dikkatle izlenmelidir. Tarayıcı ana sayfasının değişmesi, bilinmeyen araç çubuklarının veya uzantıların belirmesi, tanımadığınız uygulamaların sistem başlangıcında çalışması, masaüstünde veya uygulama listesinde beklenmedik öğelerin görünmesi adware veya trojan bulaşmasına işaret edebilir.

Dosya sistemi değişiklikleri özellikle ransomware saldırılarında belirginleşir. Dosyalar erişilemez hâle gelmiş, uzantıları değişmiş, içerikleri bozulmuş veya klasörlerde fidye notları belirmişse bu durum ciddi bir güvenlik olayı olarak değerlendirilmelidir.

Güvenlik araçlarına müdahale de zararlı yazılımların sık kullandığı yöntemlerden biridir. Antivirüs kendiliğinden devre dışı kalmışsa, güvenlik duvarı kuralları değişmişse, sistem güncellemeleri engellenmişse veya güvenlik araçları açılmıyorsa zararlı yazılım ilk iş olarak savunma mekanizmalarını etkisiz hâle getirmeye çalışıyor olabilir.

2. Bulaşma Yolları

2.1 E-posta Ekleri ve Sahte Dosyalar

E-posta, zararlı yazılımların en yaygın dağıtım kanallarından biridir. Saldırgan, meşru görünen bir e-posta içine zararlı ek veya zararlı bağlantı yerleştirir. Kullanıcı e-postayı güvenilir sanarak eki açtığında veya bağlantıya tıkladığında zararlı yazılım sisteme bulaşabilir.

Bu ekler genellikle güvenilir görünen dosya biçimlerini taklit eder. Fatura PDF'i, kargo takip belgesi, iş teklifi, teknik destek formu, ödeme dekontu veya proje dosyası gibi isimler sık kullanılır. Saldırganın amacı, kullanıcının merakını veya aciliyet duygusunu tetikleyerek dosyayı açmasını sağlamaktır.

Tehlikelerden biri dosya uzantısı manipülasyonudur. Örneğin fatura.pdf.exe adlı bir dosya, Windows'ta bilinen dosya uzantıları gizleniyorsa yalnızca fatura.pdf gibi görünebilir. Kullanıcı dosyayı PDF sanarak açtığında aslında çalıştırılabilir bir programı başlatmış olur. Bu nedenle dosya uzantılarının tamamını görmek güvenli kullanım açısından önemlidir.

Office belgelerindeki makrolar da önemli bir bulaşma yoludur. Word veya Excel dosyası açıldığında kullanıcıdan "İçeriği Etkinleştir" veya "Makroları Etkinleştir" gibi bir onay istenebilir. Eğer belge zararlı makro içeriyorsa bu onay, kötü amaçlı kodun çalışmasını tetikleyebilir.

Dikkat: Beklenmedik bir e-posta ekini açmadan önce duraksayın. Gönderici tanıdık olsa bile hesabı ele geçirilmiş olabilir. Windows'ta "Bilinen dosya türleri için uzantıları gizle" seçeneğini kapatarak dosya uzantılarının tamamını görünür hâle getirin.

2.2 Crack, Keygen ve Lisanssız Yazılım Riski

Ücretli bir yazılımı ücretsiz kullanmak amacıyla indirilen crack ve keygen araçları, zararlı yazılım dağıtımının en yoğun kanallarından biridir. Crack, yazılımın lisans korumasını kırmaya çalışan araçtır. Keygen ise sahte veya yasa dışı seri numarası üretmek için kullanılır. Bu araçlar çoğu zaman zararlı yazılımlarla birlikte paketlenir.

Bu riski anlamak için saldırganın motivasyonunu düşünmek yeterlidir. Crack veya keygen sunan kişinin amacı kullanıcıya ücretsiz yazılım sağlamak olmayabilir; asıl hedef kullanıcının sistemine erişim kazanmak olabilir. Kullanıcı, bu aracı çalıştırırken çoğu zaman yönetici yetkisi verir, antivirüs uyarısını kapatır veya güvenlik mekanizmasını devre dışı bırakır. Bu durum saldırgan için oldukça elverişli bir ortam oluşturur.

Bu tür dosyalar çalıştırıldığında antivirüs uyarısı çıksa bile bazı kullanıcılar bunu "crack olduğu için normal" diyerek geçiştirir. Saldırganın beklediği davranış da tam olarak budur. Kullanıcı güvenlik aracının uyarısını kendisi etkisiz hâle getirir ve zararlı yazılımın sisteme yerleşmesine izin verir.

Dikkat: Lisanssız yazılım kullanımının yasal risklerinin yanı sıra güvenlik maliyeti de çok yüksektir. Elde edildiği düşünülen "bedava" yazılım, veri kaybı, hesap ele geçirilmesi, fidye yazılımı bulaşması veya sistemin tamamen yeniden kurulması gibi çok daha ağır sonuçlara yol açabilir.

2.3 Sahte Yazılım Kurulumları

Sahte yazılım kurulumları, meşru görünen ancak içinde zararlı yazılım barındıran kurulum paketleridir. Bu tür paketler trojanized installer olarak da adlandırılır. Kullanıcı, bir yazılımı indirmek için arama motoruna girer, ilk sırada çıkan reklam veya resmî siteye çok benzeyen bir bağlantıya tıklar ve indirdiği kurulum dosyasını çalıştırır. Kurulum sırasında gerçek yazılım kurulabilir; fakat arka planda zararlı bileşen de sisteme yerleşir.

Bu saldırı türünün etkili olmasının nedeni, kullanıcının her şeyin normal göründüğünü düşünmesidir. Yazılım gerçekten açılır, beklenen işlevleri yerine getirir ve bu nedenle kullanıcı şüphelenmez. Ancak aynı anda sistem başlangıcına bir zararlı süreç eklenmiş, tarayıcıya kötü amaçlı bir eklenti kurulmuş veya arka planda veri toplayan bir bileşen yerleştirilmiş olabilir.

Bu tuzağa düşmemek için indirme kaynağı her zaman doğrulanmalıdır. Yazılım gerçekten üreticinin resmî web sitesinden mi indiriliyor, yoksa üçüncü taraf bir indirme sitesinden mi geliyor? URL çubuğundaki adres doğru mu? Arama motorundaki sonuç reklam mı? Site adı küçük yazım farklarıyla meşru siteyi taklit ediyor olabilir mi?

İpucu: Resmî site adresini doğrudan adres çubuğuna yazmak, uygulama mağazalarını kullanmak ve indirilen dosyaların hash değerlerini doğrulamak bu riski azaltır. Özellikle sistem araçları, güvenlik yazılımları, VPN programları, tarayıcılar ve popüler ücretsiz yazılımlar indirilirken kaynak doğrulaması mutlaka yapılmalıdır.

2.4 USB, Web İndirmeleri ve Zararlı Bağlantılar

Zararlı yazılımlar yalnızca e-posta veya sahte kurulum dosyalarıyla yayılmaz. USB cihazları, web indirmeleri ve mesajlaşma uygulamalarında paylaşılan bağlantılar da sık kullanılan bulaşma yollarıdır.

USB ve taşınabilir medya, sisteme takılan her dış aygıtın potansiyel bir zararlı yazılım taşıyıcısı olabileceğini gösterir. Bulunan, güvenilmeyen veya kaynağı bilinmeyen bir USB belleği bilgisayara takmak ciddi risk taşır. USB içindeki zararlı yazılım Autorun mekanizmasıyla veya kullanıcıyı kandıran dosya adlarıyla devreye girebilir. Örneğin "maaş_listesi.xlsx.exe" veya "fotoğraflar.zip" gibi ilgi çekici isimler kullanıcıyı dosyayı açmaya yönlendirebilir. Modül 3'te USB riskleri veri güvenliği açısından ele alınmıştı; burada vurgu USB'nin zararlı yazılım taşıma vektörü olarak oynadığı roldür.

Web indirmeleri de dikkat gerektirir. Her web sayfasından indirilen dosya güvenli değildir. Bazı saldırılarda kullanıcı herhangi bir dosyaya bilinçli olarak tıklamasa bile, zararlı veya ele geçirilmiş bir web sayfasını ziyaret ettiğinde tarayıcıdaki ya da eklentilerdeki bir açık üzerinden zararlı yazılım indirilebilir. Bu saldırı türüne drive-by download denir. Güncel tarayıcı ve işletim sistemi bu riski azaltır; ancak tamamen ortadan kaldırmaz.

Zararlı bağlantılar, e-posta, sosyal medya, anlık mesajlaşma uygulamaları veya forumlar üzerinden paylaşılabilir. Bağlantı kullanıcıyı sahte giriş sayfasına, zararlı dosya indirme alanına veya exploit barındıran bir web sayfasına yönlendirebilir. Kısaltılmış URL'ler, örneğin bit.ly veya tinyurl gibi servisler, gerçek hedef adresi gizlediği için ayrıca dikkat gerektirir. Bağlantının gerçek hedefini görmek için URL genişletici araçlar kullanılabilir veya bağlantının üzerine gelerek tarayıcının durum çubuğundaki adres incelenebilir.

Bu tür bulaşma yollarına karşı temel savunma; güncel sistem, güncel tarayıcı, dikkatli kullanıcı davranışı ve bilinmeyen kaynaklardan gelen dosya veya bağlantılara karşı temkinli yaklaşmaktır.

3. Temel Korunma Yöntemleri

3.1 Antivirüs ve Antimalware Mantığı

Antivirüs (AV) yazılımı, bilinen zararlı yazılımları tespit etmeye, engellemeye ve gerektiğinde karantinaya almaya yarayan güvenlik aracıdır. Modern antivirüs çözümleri yalnızca klasik virüslere karşı değil; trojan, spyware, ransomware, adware ve benzeri zararlı yazılım türlerine karşı da koruma sağlar. Bu nedenle pratikte antivirüs ve antimalware kavramları çoğu zaman aynı ürün ailesini ifade eder.

Antivirüslerin çalışma mantığı genel olarak iki temel yaklaşıma dayanır. Bunlardan ilki imza tabanlı algılamadır. Her bilinen zararlı yazılımın ayırt edici bir "parmak izi" bulunur. Bu parmak izine imza denir. Antivirüs, taradığı dosyayı veya süreci bilinen zararlı yazılım imzaları veritabanıyla karşılaştırır. Eşleşme bulunursa dosya tehdit olarak işaretlenir.

İmza tabanlı algılama hızlı ve güvenilirdir; ancak yalnızca daha önce tanımlanmış tehditleri yakalayabilir. Yeni geliştirilmiş veya değiştirilmiş bir zararlı yazılım, imzası veritabanına eklenmeden önce bu yöntemle tespit edilemeyebilir. Bu nedenle antivirüs imza veritabanının güncel tutulması kritik öneme sahiptir.

İkinci yaklaşım davranış tabanlı algılamadır. Bu yöntemde yalnızca dosyanın adı veya imzası değil, sistemde ne yaptığı izlenir. Bir uygulama normal görünse bile sistem kayıtlarını değiştirmeye, başka süreçlere kod enjekte etmeye, bilinmeyen dış adreslere bağlantı kurmaya, çok sayıda dosyayı kısa sürede şifrelemeye veya güvenlik araçlarını devre dışı bırakmaya çalışıyorsa şüpheli olarak değerlendirilebilir.

Davranış tabanlı algılama, yeni ve daha önce imzası bilinmeyen tehditlere karşı daha etkilidir. Ancak yanlış alarm, yani false positive, üretme ihtimali imza tabanlı algılamaya göre daha yüksek olabilir. Bu nedenle modern güvenlik ürünleri genellikle imza tabanlı, davranış tabanlı ve bulut destekli analiz yöntemlerini birlikte kullanır.

Antimalware terimi daha geniş bir çerçeveyi ifade eder. Virüs, trojan, spyware, ransomware, adware ve benzeri zararlı yazılım kategorilerine karşı koruma sağlayan araçları kapsar. Günümüzde modern antivirüs ürünleri zaten antimalware işlevi gördüğü için bu iki kavram pratikte çoğu zaman iç içe kullanılır.

3.2 Gerçek Zamanlı Koruma Yaklaşımı

Gerçek zamanlı koruma (real-time protection), antivirüs yazılımının sürekli arka planda aktif kalarak dosya erişimlerini, indirmeleri, süreç başlatmalarını ve şüpheli sistem davranışlarını anlık olarak denetlemesidir. Kullanıcı bir dosyayı açmaya çalıştığında antivirüs dosyayı çalışmadan önce kontrol eder. Bir tehdit tespit edilirse dosyanın çalışması engellenebilir veya dosya karantinaya alınabilir.

Bu mekanizmanın önemi, zararlı yazılımların çoğu zaman çok kısa sürede zarar verebilmesinden kaynaklanır. Yalnızca günde bir kez tam tarama yapan ancak gerçek zamanlı koruması kapalı olan bir sistem, iki tarama arasında bulaşan zararlı yazılıma karşı savunmasız kalabilir. Özellikle ransomware gibi tehditlerde birkaç dakika bile büyük veri kaybı için yeterli olabilir.

Gerçek zamanlı korumayı devre dışı bırakmak, antivirüs yazılımının en kritik savunma işlevini ortadan kaldırır. Bazı kullanıcılar performans gerekçesiyle veya crack/keygen çalıştırmak için bu özelliği kapatır. Bu davranış sistemi doğrudan riske açar.

Gerçek zamanlı korumanın işlemci ve disk performansına etkisi olabilir; ancak modern antivirüs ürünleri bu yükü azaltmak için taramaları akıllıca planlar, güvenilir dosyaları önbelleğe alır ve sistem performansını daha az etkileyecek yöntemler kullanır. Bu nedenle gerçek zamanlı korumanın sürekli açık tutulması temel güvenlik gerekliliğidir.

Dikkat: "Antivirüs yazılımım var, güvendeyim." Antivirüs önemli bir koruma katmanıdır; ancak tek başına yeterli değildir. İmza veritabanı güncel değilse, gerçek zamanlı koruma kapalıysa veya kullanıcı antivirüs uyarısını geçerek zararlı yazılımı bilerek çalıştırıyorsa korumanın değeri ciddi şekilde azalır.

3.3 Güvenli İndirme ve Kurulum Alışkanlıkları

Zararlı yazılımların önemli bir kısmı, kullanıcının kendi eliyle indirdiği ve çalıştırdığı dosyalar üzerinden sisteme girer. Bu nedenle güvenli indirme ve kurulum alışkanlıkları, zararlı yazılımlara karşı ilk savunma hattıdır.

İlk temel kural resmî kaynak önceliğidir. Yazılımlar mümkün olduğunca üreticinin resmî web sitesinden veya resmî uygulama mağazasından indirilmelidir. Arama motorunda çıkan ilk sonuç her zaman güvenilir değildir. Reklam olarak görünen sonuçlar, meşru siteyi taklit eden sahte indirme sayfalarına yönlendirebilir.

İkinci temel alışkanlık URL doğrulamasıdır. İndirme bağlantısına tıklamadan önce adres kontrol edilmelidir. example-yazilim.com ile examp1e-yazilim.com birbirine çok benzeyebilir; ancak farklı sitelerdir. Bu tür küçük yazım farklarıyla kullanıcıyı kandırma tekniğine typosquatting denir. HTTPS kullanımı tek başına sitenin güvenilir olduğunu göstermez; yalnızca bağlantının şifreli olduğunu ifade eder.

Üçüncü yöntem hash doğrulamasıdır. Özellikle kritik yazılımlar, sistem araçları veya büyük kurulum dosyaları indirilirken üreticinin yayımladığı hash değeri ile indirilen dosyanın hash değeri karşılaştırılabilir. Değerler eşleşiyorsa dosyanın aktarım sırasında bozulmadığı veya değiştirilmediği doğrulanır. Modül 3'te hash doğrulama komutları ele alınmıştı.

Önemli: Kurulum sırasında da dikkatli olmak gerekir. Kurulum sihirbazını "İleri → İleri → Bitir" şeklinde hızlıca geçmek, birlikte gelen istenmeyen yazılımların veya ek bileşenlerin gözden kaçmasına neden olabilir. "Önerilen kurulum" seçeneği bazı durumlarda ek araç çubukları, reklam yazılımları veya gereksiz uygulamalar yükleyebilir. Bu nedenle kurulum adımları okunmalı, gereksiz ek seçenekler devre dışı bırakılmalı ve yalnızca ihtiyaç duyulan bileşenler kurulmalıdır.

3.4 Kullanıcı Farkındalığının İlk Savunma Hattı Olması

Teknik güvenlik araçları ne kadar güçlü olursa olsun, sistemin başındaki kullanıcının kararları bu araçları ya güçlendirir ya da etkisiz hâle getirir. Saldırganlar bunun farkındadır. Bu nedenle birçok saldırı doğrudan teknik açıkları değil, insan davranışını hedef alır.

Sosyal mühendislik, kullanıcıyı meşru bir işlem yaptığına inandırarak zararlı bir eyleme yönlendirme tekniğidir. Bu bazen bir e-posta eki açtırmak, bazen sahte bir bağlantıya tıklatmak, bazen parola paylaşmaya ikna etmek, bazen de güvenlik uyarısını görmezden getirtmek şeklinde olabilir.

Sosyal mühendislik saldırıları çoğunlukla belirli duyguları hedef alır. Aciliyet duygusu yaratılabilir: "Hesabınız 24 saat içinde kapatılacak." Otorite taklit edilebilir: "IT departmanından arıyorum, şifrenizi doğrulamamız gerekiyor." Korku kullanılabilir: "Hesabınızda şüpheli işlem tespit edildi." Merak uyandırılabilir: "Faturanız ektedir." Kullanıcı hızlı karar vermeye zorlandığında hata yapma ihtimali artar.

Farkındalıklı bir kullanıcı bazı temel refleksler geliştirir. Tanımadığı bir kaynaktan gelen eki açmaz. Aciliyet içeren talepleri başka bir kanaldan doğrular. Bir bağlantıya tıklamadan önce hedef adresi kontrol eder. Bir yazılım çok iyi veya fazla cazip görünüyorsa şüpheyle yaklaşır. Antivirüs uyarısını geçerek dosya çalıştırmaz. Kaynağı bilinmeyen USB cihazlarını sisteme takmaz.

Bu davranışlar teknik bir araç değil, güvenlik düşünme alışkanlığıdır. Eğitim, tekrar ve örnek senaryolarla gelişir. Kullanıcı farkındalığı, antivirüs, güncelleme, erişim kontrolü ve ağ güvenliği gibi teknik önlemlerin tamamlayıcısıdır.

Komut & Araç Okuryazarlığı

Bu modülün komut ve araç bölümü, zararlı yazılım şüphesi oluştuğunda sistemi gözlemlemek ve kanıt toplamak için kullanılabilecek temel yöntemlere odaklanır. Buradaki amaç zararlı yazılımı doğrudan temizlemek değil; çalışan süreçleri, başlangıç öğelerini, ağ bağlantılarını, güvenlik yazılımı durumunu ve şüpheli belirtileri güvenli şekilde incelemektir.

Şüpheli bir durum fark edildiğinde aceleyle dosya silmek veya süreç sonlandırmak yerine önce kanıt toplanmalıdır. Ekran görüntüleri, komut çıktıları, dosya yolları, süreç adları, PID bilgileri ve zaman bilgileri kayıt altına alınmalıdır.

Windows'ta Temel Kontrol

Windows Security — Windows Güvenlik Merkezi

Windows'ta yerleşik güvenlik aracı olan Windows Security, sistemin temel koruma durumunu görmek için ilk bakılacak alanlardan biridir. Başlat menüsünden "Windows Güvenlik" yazarak veya görev çubuğundaki kalkan simgesinden açılabilir.

Ana ekranda özellikle Virüs ve tehdit koruması bölümü incelenmelidir. Bu bölümde gerçek zamanlı korumanın açık olup olmadığı, son tarama tarihi, bulunan tehditler, karantina durumu ve imza güncelliği görülebilir.

Öğrenci bu ekranda şu sorulara cevap aramalıdır: Gerçek zamanlı koruma açık mı? Son tarama ne zaman yapılmış? Karantinaya alınmış tehdit var mı? Güvenlik istihbaratı veya imza veritabanı güncel mi?

"Gerçek zamanlı koruma kapalı" uyarısı, imza veritabanının birkaç haftadan eski olması veya karantinada yakın tarihli tehditlerin bulunması dikkat gerektiren durumlardır.

Şüpheli Süreçleri Görme

Komut:

tasklist /v

Amaç: Çalışan tüm süreçleri bellek kullanımı, kullanıcı bilgisi ve durum gibi ayrıntılarla listeler. (Modül 1’de bahsetmiştik.)

Beklenen çıktı:

Bu komut, zararlı yazılım şüphesinde çalışan süreçleri incelemek için kullanılabilir. Normal sistem süreçlerine benzeyen ama farklı isimde veya farklı konumdan çalışan süreçler dikkatle değerlendirilmelidir. Örneğin svchost.exe meşru bir Windows süreciyken, svchost32.exe gibi benzer ama farklı isimli süreçler şüpheli olabilir.

Başlangıç Uygulamalarını Görme

Komut:

Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location, User

Amaç: Sistem başlangıcında otomatik olarak çalışacak şekilde yapılandırılmış uygulamaları, komut hatlarını ve kayıt defteri konumlarını listeler.

Beklenen çıktı:

Ağ Bağlantılarını Görme

Komut:

netstat -ano

Amaç: Aktif ağ bağlantılarını ve dinleyen portları süreç kimlikleriyle (PID) listeler.

Beklenen çıktı:

Bu komut, sistemin hangi dış adreslerle bağlantı kurduğunu görmek için kullanılır. Zararlı yazılımlar veri sızdırmak, komut almak veya uzaktan kontrol sağlamak için dış adreslerle bağlantı kurabilir. PID bilgisi sayesinde bağlantı kuran sürecin hangi uygulama olduğu tasklist ile eşleştirilebilir.

Linux'ta Temel Kontrol

Çalışan Süreçleri Görme

Komut:

ps aux --sort=-%cpu | head -20

Amaç: CPU kullanımına göre sıralanmış ilk 20 süreci listeler.

Beklenen çıktı:

Bu komut, Linux sistemlerde yüksek kaynak tüketen süreçleri hızlıca görmek için kullanılır. /tmp dizininden çalışan, nokta ile gizlenmiş dizinlerden başlatılan veya root yetkisiyle çalışan tanınmayan süreçler özellikle dikkatle incelenmelidir.

Aktif Ağ Bağlantılarını Görme

Komut:

ss -tunap

Amaç: Aktif TCP/UDP bağlantılarını ve dinleyen portları süreç bilgisiyle (process) listeler.

Beklenen çıktı:

ss, Linux'ta ağ bağlantılarını görmek için kullanılan modern araçlardan biridir. Zararlı yazılım şüphesinde hangi sürecin hangi uzak adrese bağlantı kurduğunu anlamak için değerlidir. Özellikle bilinmeyen IP adresleri, olağandışı portlar ve beklenmeyen süreçler araştırılmalıdır.

Başlangıç Servislerini ve Zamanlı Görevleri Görme

Komut:

crontab -l

Amaç: Mevcut kullanıcının zamanlı görev (cron job) listesini gösterir.

Beklenen çıktı:

Zararlı yazılımlar kalıcılık sağlamak için zamanlı görevlere kendilerini ekleyebilir. Örneğin her beş dakikada bir /tmp/updater.sh gibi bir betiğin çalıştırılması şüpheli olabilir. Bu nedenle kullanıcı ve root crontab kayıtları incelenmelidir.

macOS'ta Temel Kontrol

Activity Monitor - Aktivite Monitörü

macOS üzerinde çalışan süreçleri grafik arayüzden incelemek için Activity Monitor kullanılabilir. Spotlight'ta Cmd + Space tuşlarına basıp "Activity Monitor" yazarak açılabilir.

CPU sekmesinde yüksek kaynak kullanan süreçler, Network sekmesinde ise ağ trafiği görülebilir. Tanınmayan, sürekli yüksek CPU kullanan veya yoğun ağ trafiği oluşturan süreçler araştırılmalıdır. Sürecin adı, yolu, geliştiricisi ve sistemde ne zaman ortaya çıktığı kontrol edilmelidir.

Bilmediğiniz bir süreç yüksek kaynak tüketiyorsa hemen sonlandırmak yerine önce adını ve yolunu not almak, ekran görüntüsü almak ve meşru olup olmadığını araştırmak daha doğru bir yaklaşımdır.

Başlangıç Öğelerini Görme

Komut / Araç:

Sistem Ayarları → Genel → Başlangıç Öğeleri

Amaç: Kullanıcı oturumu açıldığında otomatik başlayan uygulamaları ve arka plan servislerini listeler.

Beklenen çıktı:

macOS'ta başlangıç öğeleri, zararlı yazılımların kalıcılık sağlamak için kullanabileceği alanlardan biridir. Tanınmayan, simgesiz veya geliştiricisi belirsiz uygulamalar not edilmeli ve araştırılmalıdır.

Temel Uygulama / Kontrol Listesi

Bu kontrol listesi, bir sistemde zararlı yazılım şüphesi oluştuğunda veya düzenli güvenlik kontrolü yapılırken kullanılabilir. Amaç, koruma durumunu görmek, olağandışı süreçleri ve bağlantıları tespit etmek, başlangıç öğelerini incelemek ve bulguları kanıtlanabilir şekilde kayıt altına almaktır.

Hazırlık

• Hangi sistemi incelediğinizi not edin: işletim sistemi, sürüm ve tarih.
• Antivirüs veya güvenlik yazılımının adını ve sürümünü not edin.
• Bulguları kaydedeceğiniz bir metin dosyası hazırlayın.
• Şüpheli durum varsa sistemi kullanmaya devam etmeden önce kanıt toplama planı yapın.

Kontrol Adımları

• Antivirüs veya güvenlik yazılımı yüklü mü?
• Gerçek zamanlı koruma aktif mi?
• İmza veritabanı güncel mi? Son güncelleme tarihi birkaç günden eski olmamalıdır.
• Son tam sistem taraması ne zaman yapıldı?
• Karantinaya alınmış tehdit var mı? Varsa hangi tarihte ve hangi dosyadan?
• Başlangıç uygulamaları listesinde tanımadığınız öğe var mı?
• Yüksek CPU veya bellek kullanan tanımsız süreç var mı?
• Olağandışı dış bağlantı var mı? Windows için netstat, Linux için ss kullanılabilir.
• Sistem performansında son zamanlarda açıklanamayan bir düşüş yaşandı mı?
• Kullanıcı yakın zamanda beklenmedik bir e-posta eki, crack/keygen, USB cihazı veya sahte kurulum dosyası çalıştırmış mı?

Doğrulama

• Şüpheli süreç adlarını ve konumlarını araştırarak meşru olup olmadığını teyit edin.
• Antivirüs ürününün güncel sürümde olup olmadığını üretici sitesiyle karşılaştırın.
• Karantina listesindeki tehditleri not alın ve raporlayın.
• Şüpheli ağ bağlantılarında PID ile süreci eşleştirin.
• Başlangıç öğelerindeki bilinmeyen uygulamaların dosya yolunu ve geliştirici bilgisini kontrol edin.

Kanıt Notu

• Antivirüs durumu, son tarama tarihi ve karantina içeriğinin ekran görüntüsünü alın.
• Şüpheli süreç veya bağlantı için komut çıktısını tarih damgasıyla kaydedin.
• Her bulgu için şunları not alın: **Ne bulundu? Nerede bulundu? Ne zaman fark edildi?
• Şüpheli dosya varsa tam dosya yolu, hash değeri, oluşturulma tarihi ve çalıştığı kullanıcı bilgisi kaydedilmelidir.
• Ağ bağlantısı varsa uzak IP adresi, port, PID ve ilgili süreç adı kayıt altına alınmalıdır.

Geri Dönüş / Dikkat Edilmesi Gerekenler

• Şüpheli bir süreci sonlandırmadan önce kanıtı, ekran görüntüsünü veya komut çıktısını kaydedin.
• Karantinadaki bir dosyayı silmeden önce yetkili kişiyi bilgilendirin.
• Zararlı yazılım şüphesi ciddi düzeydeyse sistemi ağdan izole edin ve güvenlik birimini bilgilendirin.
• Antivirüs dışında başka bir güvenlik aracı indirmeye ihtiyaç duyarsanız yalnızca tanınmış üreticilerin resmî sitelerini kullanın.
• Ciddi bulaşma şüphesinde sistemi güvenilir bir ortamdan taramak veya yeniden kurulum seçeneğini değerlendirmek gerekebilir.
• Olay sonrası kullanıcının bu sistemde kullandığı hassas hesapların parolaları değiştirilmelidir.

Temel Operasyonel Senaryo

Senaryo: "Sistem Yavaşladı, Ağ Trafiği Artmış"

Bir kullanıcı, bilgisayarının son iki gündür olağandışı biçimde yavaşladığını, fanın sürekli çalıştığını ve internet bağlantısının yavaşladığını bildiriyor. Herhangi bir yeni yazılım kurmadığını söylüyor; ancak iki gün önce bir meslektaşından e-posta ile gelen proje dosyası.zip adlı eki açtığını hatırlıyor.

Bu durumda açılan ZIP ekinin trojan, spyware veya başka bir zararlı bileşen içeriyor olabileceği düşünülmelidir. Yüksek CPU ve bellek tüketimi kripto madenciliği yapan bir zararlıya, veri sızdıran bir arka plan sürecine veya sistem kaynaklarını kötüye kullanan bir trojana işaret edebilir. İncelemeye başlamadan önce çalışan süreçler, ağ bağlantıları, başlangıç öğeleri ve antivirüs durumu kontrol edilmelidir.

Kontrol edilecek noktalar şunlardır:

1. 1. Windows'ta tasklist /v komutuyla yüksek kaynak kullanan tanımsız süreçler tespit edilir.
2. 2. netstat -ano komutuyla olağandışı dış bağlantılar incelenir.
3. 3. Windows Security üzerinden karantina bölümü kontrol edilir.
4. 4. Get-CimInstance Win32_StartupCommand / eski sistemlerde wmic startup list full komutuylakomutuyla olağandışı başlangıç uygulaması olup olmadığı kontrol edilir.
5. 5. Antivirüs son tarama tarihi ve imza güncellik durumu incelenir.

Toplanacak kanıtlar:

• tasklist /v çıktısının ekran görüntüsü; tarih-saat damgalı olmalıdır.
• netstat -ano çıktısının ekran görüntüsü alınmalıdır.
• Windows Security karantina bölümünün ekran görüntüsü saklanmalıdır.
• Başlangıç uygulamaları listesinin ekran görüntüsü alınmalıdır.
• Antivirüs durum ekranının ekran görüntüsü kaydedilmelidir.
• İnceleme tarihi, saati ve incelemeyi yapan kişinin adı not edilmelidir.

C:\Users\ogrenci01> tasklist /v

Image Name                     PID Session Name        Session#    Mem Usage  Status          User Name               CPU Time   Window Title
========================= ======== ================ =========== ============ =============== ======================= ========== ==========================
systemIdleProcess                0 Services                   0          8 K Unknown         NT AUTHORITY\SYSTEM     0:00:00    N/A
explorer.exe                  3412 Console                    1     84.212 K Running         LAB\ogrenci01           0:00:12    N/A
chrome.exe                    5120 Console                    1    156.400 K Running         LAB\ogrenci01           0:01:45    New Tab
svchost32.exe                 7844 Console                    1     42.180 K Running         LAB\ogrenci01           0:44:12    N/A
                    

İnceleme sırasında tasklist /v çıktısında ilgili kullanıcı altında svchost32.exe adlı bir sürecin çalıştığı görülür. Bu süreç C:\Users\ogrenci01\AppData\Local\Temp\ dizininden çalışmakta ve %78 CPU kullanmaktadır. Meşru svchost.exe süreci normalde C:\Windows\System32\ dizininden çalışır. Bu nedenle hem dosya adı hem de çalıştığı konum net bir kırmızı bayraktır.

netstat -ano çıktısı incelendiğinde bu sürecin 203.0.113.99:4444 adresine sürekli veri gönderdiği tespit edilir. Windows Security'nin karantina bölümü incelendiğinde ise iki gün önce açılan ZIP dosyasının içindeki proje_raporu.exe dosyasının Trojan:Win32/Agent olarak tespit edildiği ve karantinaya alındığı görülür. Ancak şüpheli süreç hâlâ aktiftir.

Bu bulgular, sistemin muhtemelen bir trojan tarafından ele geçirildiğini ve dış bir adrese veri gönderdiğini gösterir. Sistem derhal ağdan izole edilmeli, güvenlik birimi bilgilendirilmeli ve sistem güvenilir bir ortamdan tam taramaya alınmalıdır.

Bulgu → Etki → Öneri → Kanıt

Bulgu: Kullanıcıya ait bilgisayarda C:\Users\ogrenci01\AppData\Local\Temp\svchost32.exe konumundan çalışan ve 203.0.113.99:4444 adresine aktif veri akışı sağlayan tanımsız bir süreç tespit edilmiştir. Antivirüs kaydı, bu dosyanın Trojan:Win32/Agent olarak iki gün önce tespit edildiğini göstermektedir.

Etki: Sistemin zararlı süreç tarafından ele geçirildiği ve kullanıcı verilerinin dış bir adrese iletildiği değerlendirilmektedir. Bağlantı aktif olduğu sürece veri sızdırma devam edebilir. Aynı ağdaki diğer sistemler de risk altında olabilir.

Öneri: Bilgisayar derhal ağdan izole edilmelidir. Güvenlik birimi ve sistem yöneticisi bilgilendirilmelidir. Sisteme yetkili güvenlik aracıyla tam tarama yapılmalıdır. Güvenilirliği doğrulanmadan sistem üretime döndürülmemelidir. Kullanıcının bu süreçte eriştiği tüm hesaplara ait parolalar değiştirilmelidir.

Kanıt: tasklist /v çıktısı tarih-saat damgalı şekilde saklanmalıdır. netstat -ano çıktısı kayıt altına alınmalıdır. Windows Security karantina ekranının ekran görüntüsü alınmalıdır. Başlangıç uygulamaları listesi kaydedilmelidir. İncelemeyi gerçekleştiren kişinin adı ve inceleme tarihi belgeye eklenmelidir.

Kendini Değerlendir — Zararlı Yazılım Koruması

Terimler Sözlüğü

Bu Modülde Kazanılan Yetkinlikler

• Bu modülde virüs, worm, trojan ve ransomware gibi zararlı yazılım türlerinin birbirinden farklı yayılma ve etki mekanizmalarına sahip olduğunu öğrendik. Her birinin nasıl çalıştığını, sisteme nasıl zarar verdiğini ve hangi koşullarda daha tehlikeli hâle geldiğini değerlendirdik.
• Spyware ve keylogger türlerinin sessiz ve uzun süreli tehditler olduğunu gördük. Bu tehditlerin her zaman belirgin semptomlar vermeyebileceğini, bu nedenle düzenli güvenlik taramaları ve ağ trafiği izlemenin önemli olduğunu kavradık.
• Rootkit'lerin işletim sisteminin kendi görme kapasitesini manipüle edebildiğini öğrendik. Bu nedenle rootkit tespitinin ve temizliğinin standart araçlarla çoğu zaman güvenilir biçimde yapılamayabileceğini gördük.
• Zararlı yazılımların sistemde performans düşüşü, yüksek kaynak kullanımı, olağandışı ağ trafiği, dosya sistemi değişiklikleri ve güvenlik araçlarına müdahale gibi belirtiler bırakabileceğini inceledik.
• E-posta eklerinin, dosya uzantısı manipülasyonunun ve makro tabanlı saldırıların en yaygın bulaşma vektörleri arasında yer aldığını gördük. Beklenmedik e-posta eklerinin dikkatle değerlendirilmesi gerektiğini öğrendik.
• Crack, keygen ve lisanssız yazılım araçlarının zararlı yazılım dağıtımında birincil vektörlerden biri olduğunu kavradık. Bu araçların "bedava yazılım" vaadinin çoğu zaman çok daha büyük güvenlik maliyetleri doğurabileceğini değerlendirdik.
• Sahte yazılım kurulum paketlerinin, yani trojanized installer yapıların, kullanıcının farkında olmadan sisteme zararlı yazılım yerleştirebileceğini öğrendik. URL doğrulama, resmî kaynak kullanımı ve hash kontrolünün bu riski azaltabileceğini gördük.
• USB cihazları, web indirmeleri, drive-by download saldırıları ve zararlı bağlantılar üzerinden zararlı yazılımların sisteme nasıl bulaşabileceğini ele aldık. Güncel sistem ve dikkatli kullanıcı davranışının bu riskleri azaltmada kritik olduğunu öğrendik.
• Antivirüs yazılımlarının imza tabanlı ve davranış tabanlı algılama mekanizmalarını kavradık. Gerçek zamanlı korumanın neden sürekli aktif tutulması gerektiğini ve antivirüsün tek başına yeterli bir savunma olmadığını gördük.
• Güvenli indirme ve kurulum alışkanlıklarının zararlı yazılım bulaşmasını engelleyen ilk filtrelerden biri olduğunu öğrendik. Resmî kaynak önceliği, URL doğrulama, hash kontrolü ve kurulum sihirbazını dikkatle okuma gibi pratiklerin önemini değerlendirdik.
• Kullanıcı farkındalığının tüm teknik araçları tamamlayan temel savunma katmanı olduğunu kavradık. Sosyal mühendislik saldırılarının teknik araçları atlayarak doğrudan insan kararlarını hedef aldığını öğrendik.
• Windows tarafında tasklist /v, netstat -ano ve wmic startup list full veya powershell Get-CimInstance Win32_StartupCommand komutlarını; Linux tarafında ps aux, ss -tunap ve crontab -l komutlarını zararlı yazılım belirtilerini gözlemlemek amacıyla kullanabileceğimizi gördük.
• Son olarak Windows Security aracında gerçek zamanlı koruma durumunun, son tarama tarihinin, imza güncelliğinin ve karantina içeriğinin nasıl değerlendirileceğini öğrendik.

Modül Teması

Bir işletim sistemi ağa bağlandığı andan itibaren yalnızca yerel çalışan bir sistem olmaktan çıkar. Artık dış dünyayla iletişim kuran, hizmet sunan ve potansiyel olarak saldırıya açık bir varlık hâline gelir. İşletim sisteminin ağ üzerinden sunduğu her servis, kullandığı her port ve kabul ettiği her uzak bağlantı, güvenlik değerlendirmesine dahil edilmesi gereken önemli bir unsurdur.

Bu modülde ağ ile işletim sistemi arasındaki ilişkiyi, port ve servis kavramlarını, açık portların doğurduğu riskleri ve güvenlik duvarının bu riskleri nasıl yönettiğini ele alacağız. Bir sistemin ağ üzerinde hangi kapıları açık tuttuğunu anlamak, saldırı yüzeyini değerlendirmek açısından temel bir beceridir.

Uzak erişim konusu ise hem çok yararlı hem de en sık istismar edilen alanlardan biridir. RDP ve SSH gibi protokollerin temel mantığını anlamak, bu erişim noktalarını güvenli yapılandırmanın ön koşuludur. Ortak Wi-Fi ağlarının, hotspot kullanımının ve sahte erişim noktalarının oluşturduğu riskleri kavramak da günlük mobil çalışma hayatında kritik öneme sahiptir.

Bu modülün sonunda ağ üzerinden maruziyeti azaltmanın somut yollarını öğrenecek, sisteminizde hangi servislerin ve portların aktif olduğunu denetleyebilecek ve ağ güvenliği açısından daha kontrollü bir bakış açısı kazanacaksınız.

1. İşletim Sistemi ve Ağ İlişkisi

1.1 Port, Servis ve Socket Kavramları

İşletim sistemi ağa bağlandığında, sistemler arasındaki iletişim belirli kurallara göre gerçekleşir. Bu iletişimin temel kavramlarından biri porttur. Port, bir bilgisayarda hangi servisin hangi trafik kanalını kullandığını belirleyen sayısal bir tanımlayıcıdır. Port numaraları 0 ile 65535 arasında değişir. Bu aralıkta 0-1023 arasındaki portlar iyi bilinen portlar (well-known ports) olarak adlandırılır ve genellikle standart servislere ayrılmıştır.

Örnek: HTTP 80, HTTPS 443, SSH 22, RDP 3389, FTP 21 ve DNS 53 numaralı portları kullanır.

Servis, belirli bir portu dinleyen ve o port üzerinden gelen talepleri karşılayan programdır. Bir web sunucusu 80 veya 443 numaralı portu dinleyebilir. SSH servisi 22 numaralı port üzerinden bağlantı kabul eder. Bir portun dinleme durumunda olması, o kapının dışarıdan gelen bağlantılara açık olduğu anlamına gelir.

Socket ise bir ağ bağlantısının ucunu tanımlayan IP adresi ve port kombinasyonudur. Örneğin 192.0.2.10:443 ifadesi bir socket örneğidir. İki bilgisayar arasındaki her ağ bağlantısı aslında iki socket'in birbirine bağlanmasıyla oluşur.

Bu kavramları anlamak, sistemin ağ üzerindeki görünürlüğünü değerlendirmek için önemlidir. Güvenlik açısından sorulması gereken temel sorular şunlardır: Sistem hangi portları dışarıya açık tutuyor? Bu portları hangi servisler dinliyor? Bu servislerin gerçekten açık olması gerekiyor mu? Bu sorulara cevap verebilen bir kullanıcı veya sistem yöneticisi, sistemin ağ profili üzerinde daha güçlü bir kontrol sahibi olur.

1.2 Yerel Ağ ve İnternet Farkı

Her ağ bağlantısı aynı düzeyde risk taşımaz. Yerel ağ (LAN), aynı fiziksel veya mantıksal ağ ortamındaki cihazların birbirleriyle iletişim kurduğu alandır. Ev ağı, ofis ağı veya kurum içi ağ bu kapsama girer. İnternet ise milyarlarca cihazı birbirine bağlayan küresel ağdır ve bu cihazların büyük bölümü güvenilir kabul edilemez.

Yerel ağda bulunan cihazların daha kontrollü olduğu varsayılabilir. En azından hangi cihazların ağa bağlandığı belirli ölçüde denetlenebilir. İnternette ise sisteminize ulaşabilen her cihaz potansiyel bir tehdit kaynağıdır. Bu nedenle bir servisin yalnızca yerel ağda erişilebilir olması yeterliyse, doğrudan internete açık bırakılmamalıdır.

Örnek: bir veritabanı sunucusunun yalnızca aynı ağdaki uygulama sunucusuna yanıt vermesi yeterli olabilir. Böyle bir servisin internete doğrudan açık olması gereksiz ve tehlikelidir. Aynı şekilde yönetim panelleri, uzak erişim servisleri ve test ortamları da mümkün olduğunca yalnızca yetkili ağlardan erişilebilir olmalıdır.

Dikkat: Bu ayrım, güvenlik kurallarını oluştururken "Bu servise kim erişebilmeli?" sorusunu sormayı gerektirir. Cevap yalnızca belirli bir sistem veya ağ ise erişim buna göre sınırlandırılmalıdır.

1.3 Açık Portların Oluşturduğu Riskler

Bir port dinleme durumundaysa, o porta yönelen dış bağlantı taleplerini karşılamaya hazırdır. Bu durum sistemin ağ üzerinde erişilebilir bir yüzey sunduğu anlamına gelir. Her açık port, doğru yapılandırılmadığında saldırgan için yeni bir fırsat oluşturabilir.

Açık portların oluşturduğu

ilk risk, keşif hedefi hâline gelmeleridir. Saldırganlar genellikle önce hedef sistemin hangi portlarının açık olduğunu belirlemeye çalışır. Açık portlar, arkasında hangi servisin çalıştığına dair ipucu verir. Bu bilgi sayesinde saldırgan, hangi açıkların denenebileceğini değerlendirebilir.

İkinci risk , açık portların doğrudan saldırı yüzeyi oluşturmasıdır.Bir servis eski, yanlış yapılandırılmış veya güvenlik açığı barındırıyorsa bu açık o port üzerinden istismar edilebilir. Örneğin eski bir FTP sunucusu 21 numaralı portu dinliyorsa, o FTP yazılımına ait bilinen açıklar bu port üzerinden denenebilir.

Üçüncü risk, kaba kuvvet saldırılarıdır. RDP ve SSH gibi kimlik doğrulama gerektiren servislerin portları açıksa, otomatik araçlar bu servislere sürekli parola denemesi yapabilir. İnternete açık bırakılmış bir RDP portu, kısa süre içinde otomatik tarama ve brute force araçlarının hedefi hâline gelebilir.

İpucu: prensip açıktır: Açık olması gerekmeyen her port kapatılmalıdır. Daha az açık port, saldırgan için daha az deneme noktası anlamına gelir.

1.4 Gereksiz Servislerin Riskleri

Servis kavramı daha önce işletim sistemi mantığı içinde ele alınmıştı. Ağ güvenliği açısından bakıldığında ise servisler daha kritik bir hâle gelir. Çünkü çalışan her servis potansiyel olarak bir port dinleyebilir ve dış dünyaya açık bir kapı oluşturabilir.

Gereksiz servis, sistemin mevcut görevi için ihtiyaç duyulmayan ancak çalışmaya devam eden servistir. Örneğin yalnızca web sunucusu olarak kullanılan bir sistemde Telnet servisinin çalışması, bir masaüstü bilgisayarda FTP sunucusunun aktif olması veya kullanılmayan bir yazıcı paylaşım servisinin arka planda çalışması gereksiz servis örnekleridir.

Bu servisler yalnızca sistem kaynağı tüketmez. Aynı zamanda kendi güvenlik açıklarını, yanlış yapılandırma risklerini ve saldırı yüzeyini de sisteme taşır. Daha da önemlisi, kullanılmadığı düşünülen servisler çoğu zaman güncellenmez veya denetlenmez. "Kullanılmıyor ama açık kalsın." yaklaşımı zamanla sistemde unutulmuş risklerin birikmesine neden olur.

İpucu: Yeni bir sistem devralındığında veya düzenli güvenlik denetimi yapıldığında çalışan servislerin listelenmesi önemli bir adımdır. Her servis için "Bu servis bu sistemde neden çalışıyor?" sorusu sorulmalıdır. Cevabı net olmayan servisler araştırılmalı, gerçekten ihtiyaç yoksa kapatılmalıdır.

Önemli: Bir sistemi teslim aldığınızda ilk adımlardan biri çalışan servisleri listelemek olmalıdır. Cevabını veremediğiniz her servis potansiyel risk olarak değerlendirilmeli ve gerekmiyorsa devre dışı bırakılmalıdır.

2. Host Tabanlı Koruma

2.1 Güvenlik Duvarı Nedir?

Güvenlik duvarı (firewall), ağ trafiğini önceden tanımlanmış kurallara göre filtreleyen güvenlik mekanizmasıdır. Temel amacı, hangi trafiğe izin verileceğini ve hangi trafiğin engelleneceğini belirlemektir.

Güvenlik duvarı iki farklı düzeyde uygulanabilir. Ağ güvenlik duvarı, ağın giriş ve çıkış noktasında tüm trafiği filtreleyen donanım veya ağ cihazı olabilir. Genellikle kurum ağı ile internet arasındaki sınırda konumlanır. Host tabanlı güvenlik duvarı ise doğrudan işletim sistemi üzerinde çalışan ve yalnızca o sistemin trafiğini filtreleyen yazılım katmanıdır.

Bu modülde odak host tabanlı güvenlik duvarıdır. Windows'ta Windows Defender Firewall, Linux'ta iptables veya ufw (Uncomplicated Firewall), macOS'ta ise yerleşik Application Firewall bu görevi üstlenir.

Dikkat: Host tabanlı güvenlik duvarı, ağ güvenlik duvarının yerine geçmez; onu tamamlar. Ağ güvenlik duvarını geçen tehditler veya aynı yerel ağ içinden gelen saldırılar için ikinci bir savunma katmanı oluşturur. Savunma katmanları yaklaşımı açısından ağ güvenlik duvarı ile host tabanlı güvenlik duvarının birlikte çalışması daha bütünlüklü bir koruma sağlar.

2.2 Gelen ve Giden Trafik Mantığı

Güvenlik duvarı kuralları temel olarak iki yönde çalışır: gelen trafik (inbound) ve giden trafik (outbound).

Gelen trafik, dış ağdan sisteme gelen bağlantı talepleridir. Örneğin bir kullanıcı web tarayıcısından bir web sunucusuna bağlandığında, sunucu tarafında bu trafik gelen trafik olarak değerlendirilir. Gelen trafik, sistemin dışarıya hangi hizmetleri sunduğunu belirler. Port 443'e gelen trafiğe izin verilirse web sunucusu dışarıdan erişilebilir. Port 22'ye gelen trafik engellenirse SSH servisine dışarıdan bağlantı kurulamaz.

Giden trafik, sistemden dışarıya doğru kurulan bağlantılardır. Bir tarayıcının web sayfası yüklemesi, bir uygulamanın güncelleme sunucusuna bağlanması veya bir sistem servisinin dış API'ye istek göndermesi giden trafiğe örnektir. Giden trafik kısıtlamaları çoğu zaman ihmal edilir; ancak zararlı yazılımların veri sızdırması da genellikle giden trafik üzerinden gerçekleşir. Bu nedenle giden trafiğin izlenmesi ve gerektiğinde sınırlandırılması, yetkisiz veri aktarımını fark etmek açısından değerlidir.

Güvenlik duvarı yapılandırmasında temel yaklaşım varsayılan olarak reddet, yalnızca açıkça izin verilenleri geçir mantığıdır. Bu yaklaşım default deny olarak bilinir. Böylece yanlışlıkla açık bırakılmış servislerin erişilebilir hâle gelmesi engellenir.

2.3 Uygulama Bazlı İzin Yaklaşımı

Modern host tabanlı güvenlik duvarları yalnızca port numarasına göre değil, trafiği oluşturan uygulamaya göre de kural tanımlayabilir. Bu yaklaşım, aynı portu kullanan farklı uygulamalara farklı erişim izinleri vermeyi mümkün kılar.

Windows Defender Firewall, bir uygulama ilk kez ağa bağlanmaya çalıştığında kullanıcıdan izin isteyebilir. Uyarıda genellikle uygulamanın özel ağlara mı, genel ağlara mı yoksa her ikisine birden mi erişebileceği sorulur. Özel ağlar ev veya iş ağı gibi daha kontrollü alanları ifade ederken, genel ağlar kafe, otel veya havalimanı gibi güvenilmeyen ağları ifade eder.

Bu onay mekanizması, kullanıcının hangi uygulamaların ağa eriştiğini bilinçli biçimde yönetmesini sağlar. Ancak bu uyarılar otomatik olarak onaylandığında güvenlik işlevi zayıflar. Bilinmeyen veya tanımadığınız bir uygulama ağ erişimi istediğinde durup düşünmek gerekir: Bu uygulamayı ben mi başlattım? Bu uygulamanın ağa bağlanması gerçekten gerekli mi? Uygulama güvenilir bir kaynaktan mı geldi?

Bu refleks, ağ güvenliğinde basit ama etkili bir kullanıcı davranışıdır.

2.4 Temel Güvenlik Duvarı Kural Mantığı

Güvenlik duvarı kuralları birkaç temel bileşenden oluşur: kaynak, hedef, port/protokol ve eylem. Kaynak trafiğin nereden geldiğini, hedef nereye gittiğini, port/protokol hangi servis üzerinden iletişim kurulduğunu, eylem ise bu trafiğe izin verilip verilmeyeceğini belirler.

Kurallar genellikle sırayla değerlendirilir ve ilk eşleşen kural uygulanır. Bu nedenle kural sırası önemlidir. Çok genel bir "her şeye izin ver" kuralı, daha sonra gelen daha dar kapsamlı bir "engelle" kuralını etkisiz hâle getirebilir.

Örnek: Temel kural mantığını birkaç örnekle düşünebiliriz. "Tüm kaynaklardan port 443'e gelen TCP trafiğine izin ver" kuralı, HTTPS web sunucusu için standart bir kuraldır. "Tüm kaynaklardan port 23'e gelen TCP trafiğini reddet" kuralı, güvensiz Telnet protokolünü engellemeye yöneliktir. "Yalnızca 192.0.2.0/24 ağından port 22'ye gelen trafiğe izin ver" kuralı ise SSH erişimini yalnızca belirli bir ağla sınırlandırır.

Unutma: Güvenlik duvarı kuralları oluşturulurken gereksiz izinlerden kaçınılmalı, mümkün olduğunca dar kapsamlı kurallar yazılmalıdır. Kaynak ağı, hedef portu ve izin verilen protokol net biçimde tanımlanmalıdır.

3. Uzak Erişim ve Günlük Kullanım Güvenliği

3.1 RDP ve SSH'ye Temel Bakış

RDP (Remote Desktop Protocol), Windows sistemlerine grafik arayüz üzerinden uzaktan bağlanmayı sağlayan Microsoft protokolüdür. Varsayılan olarak TCP 3389 numaralı portu kullanır. Bir kullanıcı başka bir konumdan ofis bilgisayarına sanki fiziksel olarak önündeymiş gibi bağlanabilir; masaüstünü görebilir, uygulama çalıştırabilir ve dosyalarla çalışabilir.

RDP kurumsal ortamlarda oldukça yaygındır. Ancak bu yaygınlık onu saldırganların sık hedef aldığı protokollerden biri hâline getirir. İnternete açık RDP servisleri, kaba kuvvet saldırıları, kimlik bilgisi denemeleri ve zafiyet taramaları açısından yüksek risk taşır.

SSH (Secure Shell), komut satırı üzerinden uzak bir sisteme şifreli bağlantı sağlayan protokoldür. Varsayılan olarak TCP 22 numaralı portu kullanır. Linux ve macOS sistem yönetiminde standart araçlardan biridir. Ayrıca SCP ve SFTP gibi yöntemlerle güvenli dosya aktarımı için de kullanılır. SSH trafiği şifreli olduğu için güçlü bir güvenlik avantajı sunar; ancak yanlış yapılandırılmış SSH servisleri de ciddi risk oluşturabilir.

RDP ve SSH servislerini güvenli kullanmak için bazı temel önlemler uygulanmalıdır. Güçlü kimlik doğrulama kullanılmalı, SSH için parola yerine anahtar tabanlı kimlik doğrulama tercih edilmelidir. Kullanılmayan uzak erişim servisleri kapatılmalıdır. Erişim yalnızca belirli IP adresleri veya güvenilir ağlarla sınırlandırılmalıdır. Varsayılan portu değiştirmek otomatik tarama araçlarının yükünü azaltabilir; ancak tek başına gerçek bir güvenlik önlemi olarak görülmemelidir.

Dikkat: RDP portu 3389'un internete açık bırakılması, otomatik kaba kuvvet araçlarının kısa sürede bu porta saldırmaya başlaması anlamına gelebilir. İnternet üzerinden RDP erişimi gerekiyorsa VPN üzerinden erişim sağlamak standart bir güvenlik pratiğidir.

3.2 Ortak Wi-Fi, Hotspot ve Rogue Access Point Riskleri

Kafe, havalimanı, otel, alışveriş merkezi veya benzeri kamusal alanlardaki Wi-Fi ağları güvenlik açısından riskli ortamlardır. Bu ağlarda aynı anda çok sayıda bilinmeyen cihaz bulunur. Ağa bağlı diğer kullanıcıların niyeti, cihaz güvenliği veya yaptığı işlemler üzerinde kontrolünüz yoktur.

Ortak Wi-Fi riskleri, aynı ağdaki kötü niyetli bir kullanıcının trafiği izlemeye veya manipüle etmeye çalışabilmesinden kaynaklanır. HTTPS kullanılmayan sitelerde gönderilen veriler açık metin olarak iletilebilir. Saldırgan, ağ üzerinde orta adam konumuna geçerek trafiği gözlemlemeye veya kullanıcıyı sahte sayfalara yönlendirmeye çalışabilir.

Rogue Access Point, yani sahte erişim noktası, saldırganın meşru bir Wi-Fi ağını taklit ederek oluşturduğu sahte ağdır. Örneğin gerçek ağ adı Cafe_Wifi iken saldırgan Cafe_WiFi gibi çok benzer bir isimle ağ oluşturabilir. Hatta bazen aynı ağ adını kullanabilir. Kullanıcı bu sahte ağa bağlandığında, tüm trafiği saldırganın kontrol ettiği altyapıdan geçebilir.

Bu saldırıyı kullanıcı seviyesinde ayırt etmek her zaman kolay değildir. Bu nedenle ortak Wi-Fi ağlarında dikkatli davranmak gerekir. Mümkünse VPN kullanılmalı, hassas işlemler ertelenmeli, yalnızca HTTPS kullanan siteler ziyaret edilmeli ve dosya paylaşımı kapalı tutulmalıdır. "Ağ keşfine izin ver" gibi seçenekler güvenilmeyen ağlarda devre dışı bırakılmalıdır.

Ortak ağlarda asıl ilke şudur: Ağın sahibi olduğunuzu veya ağdaki diğer cihazlara güvenebileceğinizi varsaymayın.

3.3 Uzak Erişimde Temel Güvenlik Önlemleri

Uzak erişim, sistem yönetimi ve esnek çalışma için büyük kolaylık sağlar. Ancak yanlış yapılandırıldığında saldırganlara doğrudan giriş kapısı sunabilir. Bu nedenle uzak erişim yapılandırmaları hem pratik hem de güvenlik açısından dikkatli ele alınmalıdır.

İlk önlem güçlü kimlik doğrulamadır. Uzak erişim protokollerinde yalnızca parola kullanmak yüksek risklidir. RDP gibi servislerde mümkünse çok faktörlü kimlik doğrulama uygulanmalıdır. SSH tarafında parola tabanlı giriş yerine anahtar tabanlı kimlik doğrulama tercih edilmelidir.

İkinci önlem erişim kısıtlamasıdır. Uzak erişim yalnızca gerçekten ihtiyaç duyan kullanıcılar ve cihazlar için açık olmalıdır. IP bazlı kısıtlama, VPN zorunluluğu ve ağ segmentasyonu bu kısıtlamayı uygulamanın pratik yollarıdır. Herkesin her yerden erişebildiği bir uzak erişim servisi yüksek risklidir.

Üçüncü önlem konu varsayılan portların değerlendirilmesidir. RDP için 3389, SSH için 22 numaralı portlar otomatik tarama araçlarının ilk denediği portlardır. Port değiştirmek saldırıyı tamamen engellemez; ancak otomatik taramaların gürültüsünü azaltabilir. Yine de asıl güvenlik güçlü kimlik doğrulama, erişim kısıtlama ve güvenlik duvarı kurallarıyla sağlanır.

Dördüncü önlem bağlantı loglarını izlemektir. Uzak erişim bağlantıları kayıt altına alınmalı, başarısız giriş denemeleri takip edilmelidir. Kısa sürede çok sayıda başarısız giriş denemesi kaba kuvvet saldırısına işaret edebilir.

Son olarak, kullanılmayan uzak erişim servisleri kapatılmalıdır. Bir sistemde RDP veya SSH'ye ihtiyaç yoksa bu servislerin çalışır durumda kalması gereksiz risk oluşturur. Kapalı bir porta saldırı yapılamaz.

3.4 Ağ Üzerinden Maruziyeti Azaltma Yaklaşımı

Ağ maruziyetini azaltmak, sistemin internete veya yerel ağa sunduğu saldırı yüzeyini sistematik biçimde küçültmek anlamına gelir. Bu yaklaşım tek bir güvenlik önleminden ibaret değildir; servis yönetimi, güvenlik duvarı kuralları, erişim kısıtlama ve düzenli denetimin birlikte uygulanmasını gerektirir.

İlk adım minimum açık port yaklaşımıdır. Sistemde yalnızca gerçekten gerekli servisler çalışmalı ve yalnızca bu servislerin portları açık olmalıdır. Her ek açık port, saldırgan için yeni bir deneme noktasıdır.

İkinci adım ağ segmentasyonudur. Kritik sistemler, örneğin veritabanı sunucuları, yönetim panelleri veya hassas uygulama sunucuları doğrudan internete açık olmamalıdır. Bu sistemler yalnızca belirli sistemlerin erişebildiği ayrı ağ segmentlerinde konumlandırılmalıdır.

Üçüncü adım varsayılan reddet politikasıdır. Güvenlik duvarı kuralları "herkese izin ver, gerektiğinde engelle" mantığıyla değil; "varsayılan olarak reddet, yalnızca açıkça izin verilenleri geçir" yaklaşımıyla yapılandırılmalıdır.

Dördüncü adım ise periyodik port ve servis denetimidir. Sistemler zaman içinde değişir. Yeni yazılımlar kurulur, test servisleri açılır, geçici izinler verilir ve bazıları unutulur. Bu nedenle açık portlar ve çalışan servisler düzenli aralıklarla gözden geçirilmeli, artık ihtiyaç duyulmayan servisler kapatılmalıdır.

Bu yaklaşım uygulandığında sistemin ağ üzerindeki görünürlüğü azalır ve saldırganın kullanabileceği fırsatlar daralır.

Komut & Araç Okuryazarlığı

Bu bölümdeki komutlar, sistemdeki açık portları, dinleyen servisleri, aktif bağlantıları ve güvenlik duvarı durumunu gözlemlemek için kullanılır. Amaç sistemi değiştirmek değil, ağ maruziyetini güvenli şekilde incelemek ve bulguları kayıt altına almaktır.

Windows'ta Temel Kontrol

Açık Portları ve Bağlantıları Görme

Komut:

netstat -ano

Amaç: Aktif ağ bağlantılarını, dinleyen portları ve her bağlantının ait olduğu süreç kimliğini (PID) listeler.

Beklenen çıktı:

Bu komut, Windows sistemde hangi portların dinleme durumunda olduğunu ve hangi dış bağlantıların aktif olduğunu görmek için kullanılır. LISTENING satırları sistemin dış bağlantı kabul etmeye hazır olduğu portları gösterir. ESTABLISHED satırları ise kurulmuş aktif bağlantıları ifade eder.

Belirli Bir PID'in Hangi Programa Ait Olduğunu Görme

Komut:

tasklist /fi "pid eq 1456"

Amaç: Belirtilen PID (Process ID) değerine sahip sürecin adını ve ayrıntılarını filtreleyerek gösterir.

Beklenen çıktı:

netstat çıktısında görülen bir portun hangi süreç tarafından kullanıldığını anlamak için PID bilgisi tasklist komutuyla eşleştirilebilir. Bu yöntem, tanınmayan açık portların arkasındaki uygulamayı bulmak için kullanışlıdır.

Güvenlik Duvarı Durumunu Görme

Komut:

netsh advfirewall show allprofiles

Amaç: Windows Defender Firewall'un tüm profillerdeki (Domain, Private ve Public) durumunu ve aktif politikalarını gösterir.

Beklenen çıktı:

Bu komut, Windows Defender Firewall'un tüm ağ profillerinde açık olup olmadığını kontrol etmek için kullanılır. Özellikle Public profilinin kapalı olması, ortak veya güvenilmeyen ağlarda ciddi risk oluşturur.

Windows Defender Firewall

Windows Defender Firewall grafik arayüz üzerinden de incelenebilir. Başlat menüsünden Windows Güvenlik → Güvenlik Duvarı ve ağ koruması yoluyla açılabilir.

İpucu: Bu ekranda etki alanı, özel ve genel ağ profillerinin açık veya kapalı olduğu görülebilir. Gelişmiş ayarlar bölümünde gelen ve giden kural listesi incelenebilir. Öğrenci özellikle tüm profillerin açık olup olmadığını, gelen kurallar arasında beklenmedik veya tanımadığı izinlerin bulunup bulunmadığını kontrol etmelidir.

Kanıt amacıyla profil durumlarının ve kural listesinin ekran görüntüsü tarih bilgisiyle birlikte kaydedilebilir.

Linux'ta Temel Kontrol

Açık Portları ve Dinleyen Servisleri Görme

Komut:

ss -tunlp

Amaç: Dinleyen (listening) durumundaki TCP ve UDP portlarını süreç bilgisiyle (process) listeler.

Beklenen çıktı:

Bu komut, Linux sistemlerde hangi servislerin hangi portları dinlediğini görmek için temel araçlardan biridir. Özellikle 0.0.0.0 üzerinde dinleyen servisler dikkatle değerlendirilmelidir.

UFW Güvenlik Duvarı Durumunu Görme

Komut:

sudo ufw status verbose

Amaç: UFW (Uncomplicated Firewall) güvenlik duvarının etkin olup olmadığını, varsayılan politikaları ve aktif kuralları ayrıntılı gösterir.

Beklenen çıktı:

UFW, Linux sistemlerde güvenlik duvarı kurallarını daha anlaşılır biçimde yönetmek için kullanılan araçlardan biridir. Bu komutla güvenlik duvarının aktif olup olmadığı ve hangi portlara izin verildiği görülebilir.

Aktif Ağ Bağlantılarını ve Süreçleri Görme

Komut:

ss -tunap

Amaç: Hem dinleyen hem de kurulu (aktif) bağlantıları süreç bilgisiyle birlikte listeler.

Beklenen çıktı:

Bu komut, sistemin dış adreslerle kurduğu aktif bağlantıları incelemek için kullanılır. Özellikle tanınmayan uzak IP adresleri ve beklenmeyen portlar güvenlik açısından araştırılmalıdır.

macOS'ta Temel Kontrol

Açık Portları ve Bağlantıları Görme

Komut:

netstat -anv | grep LISTEN

Amaç: macOS işletim sisteminde dinleme (listening) durumundaki portları listeler.

Beklenen çıktı:

macOS üzerinde dinleme durumundaki portları görmek için bu komut kullanılabilir. \* ile görünen portlar tüm arayüzlerden erişilebilir olabileceği için dikkatle incelenmelidir.

macOS Application Firewall

macOS'ta yerleşik güvenlik duvarı Sistem Ayarları → Ağ → Güvenlik Duvarı yoluyla açılabilir. Bu ekranda güvenlik duvarının açık veya kapalı olduğu ve uygulama izinleri görülebilir.

Öğrenci bu bölümde güvenlik duvarının etkin olup olmadığını ve izin verilen uygulamalar listesinde tanımadığı bir uygulama bulunup bulunmadığını kontrol etmelidir. Kanıt amacıyla güvenlik duvarı durumu ve uygulama listesinin ekran görüntüsü kaydedilebilir.

Temel Uygulama / Kontrol Listesi

Bu kontrol listesi, bir sistemin ağ maruziyetini temel düzeyde değerlendirmek için kullanılabilir. Amaç, sistemde hangi portların açık olduğunu, hangi servislerin bu portları dinlediğini, güvenlik duvarının aktif olup olmadığını ve uzak erişim servislerinin gereksiz risk oluşturup oluşturmadığını anlamaktır.

Hazırlık

• Hangi sistemi incelediğinizi not edin: işletim sistemi, sürüm, ağ ortamı ve tarih.
• Sistemin hangi ağda olduğunu belirleyin: yerel ağ mı, internet bağlantısı olan bir ağ mı?
• Bulguları kaydedeceğiniz bir not dosyası hazırlayın.
• Uzak erişim üzerinden bağlıysanız güvenlik duvarı değişikliklerinin bağlantıyı kesebileceğini unutmayın.

Kontrol Adımları

• Host tabanlı güvenlik duvarı etkin mi?
• Tüm güvenlik duvarı profilleri açık mı?
• Sistemde hangi portlar dinleme durumunda? Windows için netstat -ano, Linux için ss -tunlp kullanılabilir.
• Dinleyen servisler arasında tanımadığınız veya bu sistemde olmaması gereken bir servis var mı?
• Kaç port 0.0.0.0 veya tüm arayüzler üzerinden dışarıya açık?
• RDP 3389 veya SSH 22 portları internete açık mı?
• Aktif dış bağlantılar arasında tanımadığınız uzak adresler var mı?
• Ortak veya güvenilmeyen ağda çalışılıyorsa VPN bağlantısı aktif mi?
• Güvenlik duvarı kural listesinde beklenmedik izinler var mı?

Doğrulama

• Her dinleyen portu hangi servisin kullandığını PID üzerinden doğrulayın.
• Güvenlik duvarı kural listesini inceleyin; beklenmedik "izin ver" kuralı var mı?
• İnternete açık olmaması gereken servisler yerel ağa veya localhost'a kısıtlanmış mı?
• RDP veya SSH gibi uzak erişim servisleri gerçekten gerekli mi?
• Gereksiz servisler için ilgili sistem sahibi veya yöneticiyle doğrulama yapın.

Kanıt Notu

• netstat veya ss çıktısını tarih ve saat bilgisiyle birlikte kaydedin.
• Güvenlik duvarı durumu çıktısını veya ekran görüntüsünü saklayın.
• Her bulgu için şunları not alın: Hangi port, hangi servis, hangi arayüzde dinliyor, gerekli mi?
• Şüpheli bağlantılar için uzak IP adresi, port, PID ve süreç adı kaydedilmelidir.
• Güvenlik duvarı kural değişikliği yapılacaksa mevcut kural listesi önce belgelenmelidir.

Geri Dönüş / Dikkat Edilmesi Gerekenler

• Bir servisi kapatmadan önce sistemin bu servise bağımlı olup olmadığını araştırın.
• Güvenlik duvarı kuralı eklerken mevcut kuralların yedeğini alın.
• Uzak erişim üzerinden bağlıyken güvenlik duvarı kurallarını değiştirmek bağlantıyı kesebilir; yerel erişim sağlanmadan bu işlemi yapmayın.
• Şüpheli bir dış bağlantı tespit ederseniz bağlantıyı kesmeden önce kanıtı kaydedin.
• Gereksiz görünen servisleri doğrudan silmek yerine önce devre dışı bırakma ve etkisini gözlemleme yaklaşımı tercih edilmelidir./li>

Temel Operasyonel Senaryo

Senaryo: "Sunucuda Tanımadığım Bir Port Dışarıya Açık"

Bir Linux web sunucusunun rutin ağ denetimi sırasında, sunucunun port 4444 üzerinden dışarıya açık olduğu ve bu portun dinleme durumunda bulunduğu fark edilir. Web sunucusu olarak yapılandırılmış bu sistemde yalnızca 80, 443 ve yönetim amaçlı 22 numaralı portların açık olması beklenmektedir.

Port 4444 standart bir servis portu değildir ve bu sistemde tanımlı bir uygulamanın bu portu kullanması beklenmemektedir. Bu durum beklenmedik bir açık port bulgusudur. Port, zararlı yazılım tarafından dinleme modunda kurulmuş bir arka kapı olabilir veya yanlışlıkla başlatılmış bilinmeyen bir servis tarafından kullanılıyor olabilir. Bu nedenle ilk adım, hangi sürecin bu portu dinlediğini tespit etmektir.

Kontrol edilecek noktalar şunlardır:

1. 1. ss -tunlp komutuyla port 4444'ü dinleyen sürecin PID ve adı tespit edilir.
2. 2. ps aux \| grep \ komutuyla sürecin tam komut satırı ve çalışma dizini incelenir.
3. 3. ls -la /proc/\/exe komutuyla çalıştırılabilir dosyanın konumu doğrulanır.
4. 4. sha256sum \ komutuyla dosyanın hash değeri hesaplanır.
5. 5. UFW kural listesi incelenerek bu portun ne zaman ve nasıl açıldığı araştırılır.
6. 6. /var/log/syslog veya journalctl ile ilgili dönemde sistem logları incelenir.

Toplanacak kanıtlar:

• ss -tunlp çıktısının ekran görüntüsü; tarih-saat damgalı olmalıdır.
• Sürece ait ps aux çıktısı kaydedilmelidir.
• Şüpheli dosyanın tam yolu ve SHA-256 hash değeri alınmalıdır.
• İlgili log satırlarının kopyası saklanmalıdır.
• İnceleme tarihi, saati ve incelemeyi yapan kişinin adı not edilmelidir.

    tcp    LISTEN     0      128       0.0.0.0:4444          0.0.0.0:*           users:(("sys_update",pid=3721,fd=3))
                                

    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    root      3721  2.4  0.8  15420  9240 ?        Ss   14:20   0:05 /tmp/.sys_update
                                

İnceleme sırasında ss -tunlp çıktısı, port 4444'ü dinleyen sürecin PID değerini 3721 olarak gösterir. ps aux \| grep 3721 çıktısı incelendiğinde sürecin /tmp/.sys_update konumundan çalıştığı görülür. /tmp dizininden çalışan bir servis güçlü bir kırmızı bayraktır; meşru sistem servisleri normalde bu konumdan çalışmaz.

Dosyanın hash değeri hesaplanır. Log incelemesinde bu sürecin iki gün önce gece 03:12'de başlatıldığı tespit edilir. Bu zaman bilgisi planlı bakım penceresiyle örtüşmüyorsa bulgunun ciddiyeti artar.

Dikkat: Bu veriler, sunucunun ele geçirilmiş ve sisteme arka kapı kurulmuş olabileceğini düşündürür. Sunucu derhal ağdan izole edilmeli, güvenlik birimi bilgilendirilmeli ve adli analiz için sistem durumu mümkün olduğunca korunmalıdır.

Bulgu → Etki → Öneri → Kanıt

Bulgu:Linux web sunucusunda /tmp/.sys_update konumundan çalışan ve port 4444 üzerinden dışarıya açık beklenmedik bir süreç tespit edilmiştir. Süreç iki gün önce gece 03:12'de başlatılmıştır; bu saat planlı bakım penceresiyle örtüşmemektedir. Port 4444, bu sunucunun tanımlı servis yapılandırmasında yer almamaktadır.

Etki: Sunucu üzerinde yetkisiz bir dinleme noktası oluşturulmuştur. Saldırgan bu port üzerinden sisteme uzaktan erişim sağlamış veya veri iletimi gerçekleştirmiş olabilir. Sunucudaki tüm veriler ve üzerinde çalışan uygulamalar risk altındadır.

Öneri: Sunucu derhal ağdan izole edilmelidir. Güvenlik birimi ve sistem yöneticisi bilgilendirilmelidir. Sürecin dosyası kanıt olarak hash değeriyle birlikte saklanmalıdır. Sistem yeniden güvenilir duruma getirilene kadar üretim trafiği yönlendirilmemelidir. Güvenilir bir yedekten sistem kurtarma değerlendirilmelidir.

Kanıt: ss -tunlp çıktısı tarih-saat damgalı ekran görüntüsüyle saklanmalıdır. Sürecin ps aux çıktısı kaydedilmelidir. /tmp/.sys_update dosyasının SHA-256 hash değeri ve tam yolu kayıt altına alınmalıdır. journalctl log kesiti, incelemeyi yapan kişinin adı ve inceleme tarihi belgeye eklenmelidir.

Kendini Değerlendir — Ağ, Servis ve Uzak Erişim

Terimler Sözlüğü

Bu Modülde Kazanılan Yetkinlikler

• Bu modülde port, servis ve socket kavramlarını öğrendik. Bir servisin belirli bir portu dinlemesinin, o portu ağ üzerinden erişilebilir hâle getirdiğini ve bunun güvenlik değerlendirmesine dahil edilmesi gerektiğini gördük.
• Yerel ağ ve internet arasındaki güvenlik farkını ele aldık. İnternete açık olması gerekmeyen servislerin yalnızca yerel ağ veya belirli sistemlerle sınırlandırılmasının neden kritik olduğunu kavradık.
• Açık portların saldırı yüzeyi üzerindeki etkisini inceledik. Her ek açık portun keşif hedefi, doğrudan saldırı yüzeyi ve kaba kuvvet saldırısı hedefi olabileceğini öğrendik.
• Gereksiz servislerin yalnızca sistem kaynağı tüketmediğini, aynı zamanda kendi güvenlik açıklarını ve saldırı yüzeylerini sisteme taşıdığını gördük. Bu nedenle çalışan servislerin düzenli olarak gözden geçirilmesi gerektiğini kavradık.
• Host tabanlı güvenlik duvarının ne olduğunu ve ağ güvenlik duvarını nasıl tamamladığını öğrendik. Gelen ve giden trafik ayrımını, default deny yaklaşımını ve güvenlik duvarı kurallarının temel mantığını değerlendirdik.
• Uygulama bazlı izin mekanizmasını tanıdık. Bilinmeyen bir uygulama ağ erişimi istediğinde otomatik onay vermek yerine duraksayıp sorgulamanın güvenli bir refleks olduğunu gördük.
• RDP ve SSH protokollerini temel düzeyde ele aldık. Bu protokollerin güçlü kimlik doğrulama, erişim kısıtlama, log izleme ve gereksizse kapatma ilkeleriyle yönetilmesi gerektiğini öğrendik.
• Ortak Wi-Fi ağlarının, hotspot kullanımının ve rogue access point saldırılarının neden tehlikeli olduğunu inceledik. Bu ortamlarda VPN kullanmanın, hassas işlemleri ertelemenin ve şifrelenmemiş trafikten kaçınmanın önemini kavradık.
• Uzak erişimde MFA, SSH anahtar tabanlı kimlik doğrulama, IP kısıtlama, VPN zorunluluğu ve başarısız giriş denemelerini izleme gibi temel güvenlik önlemlerini öğrendik.
• Ağ maruziyetini azaltmanın sistematik bir pratik olduğunu gördük. Minimum açık port, ağ segmentasyonu, varsayılan reddet politikası ve periyodik port/servis denetiminin birlikte uygulanması gerektiğini kavradık.
• Windows tarafında netstat -ano, tasklist /fi \"pid eq \...\", netsh advfirewall show allprofiles; Linux tarafında ss -tunlp, ss -tunap, sudo ufw status verbose; macOS tarafında netstat -anv \| grep LISTEN gibi komutları güvenlik denetimi amacıyla nasıl kullanabileceğimizi öğrendik.
• Son olarak açık bir portu ve arkasındaki süreci tanımlamayı, sürecin konumunu doğrulamayı, hash değerini almayı ve bulguları rapor formatında belgelemeyi pratik bir senaryo üzerinden değerlendirdik.

Modül Teması

Bir güvenlik olayı gerçekleştiğinde genellikle ilk sorular şunlar olur: "Bu ne zaman başladı, kim yaptı ve hangi sistemleri etkiledi?" Bu sorulara sağlıklı cevap verebilmek, sistemlerin düzenli ve doğru biçimde log tutmasına bağlıdır. Log, sistemin tuttuğu dijital kayıttır. Kim ne zaman giriş yapmış, hangi dosya değiştirilmiş, hangi servis başlatılmış, hangi bağlantı kurulmuş gibi birçok kritik bilgi loglar üzerinden takip edilebilir.

Loglar olmadan geçmişe dönük analiz yapmak son derece zordur. Logsuz bir sistemde güvenlik olaylarını yönetmek, karanlık bir odada iz sürmeye benzer. Olayın ne zaman başladığını, nasıl ilerlediğini ve hangi hesapları ya da sistemleri etkilediğini anlamak neredeyse imkânsız hâle gelir.

Bu modülde log kavramını temelden ele alacağız. Logun ne olduğunu, neden tutulduğunu, hangi tür logların bulunduğunu ve güvenlik açısından hangi olayların daha önemli olduğunu inceleyeceğiz. Ardından log saklama, log rotasyonu ve log bütünlüğü gibi konulara geçeceğiz.

İzleme bölümünde Windows Event Viewer, Linux syslog ve journal yapısı, sistem izleme araçları, süreç ve bağlantı gözlemi gibi başlıkları ele alacağız. Modülün son bölümünde ise başarısız giriş denemeleri, beklenmedik süreçler, anormal kaynak kullanımı ve olağandışı ağ trafiği gibi şüpheli durumların pratikte nasıl değerlendirileceğini göreceğiz.

Bu modülü tamamladığınızda bir sistemi yalnızca kullanmayı değil, o sistemde neler olup bittiğini izlemeyi ve loglardan anlamlı sonuçlar çıkarmayı da öğrenmiş olacaksınız.

1. Log Mantığı

1.1 Log Nedir ve Neden Tutulur?

Log, bir sistemin, uygulamanın veya cihazın gerçekleştirdiği işlemleri, meydana gelen olayları ve oluşan hataları zaman damgasıyla birlikte kayıt altına aldığı yapılandırılmış kayıttır. İşletim sistemi; kullanıcı girişleri, servis başlatmaları, dosya erişimleri, ağ bağlantıları, sistem hataları ve benzeri önemli olayları log kaydı olarak saklar.

Loglar güvenlik açısından üç temel amaca hizmet eder.

İlk olarak güvenlik olaylarının tespiti ve soruşturulmasında kullanılır. Bir saldırı gerçekleştiğinde "Bu hesap dün gece saat 03:00'te giriş yapmış mı?", "Bu dosya ne zaman değiştirildi?", "Sisteme kim erişti?" gibi soruların cevabı çoğu zaman log kayıtlarında bulunur.

İkinci olarak loglar sorun giderme sürecinin temel kaynağıdır. Bir servis neden çöktü, hangi hata mesajı üretildi, bu hata hangi işlemden sonra ortaya çıktı gibi sorular loglar olmadan net biçimde cevaplanamaz. Özellikle sistem yöneticileri için loglar, arızanın nedenini anlamada en güvenilir kaynaklardan biridir.

Üçüncü olarak loglar yasal ve düzenleyici uyumluluk açısından önemlidir. Birçok sektörde belirli olayların belirli süre boyunca kayıt altında tutulması zorunludur. Finans, sağlık, kamu ve kritik altyapı gibi alanlarda log tutmak yalnızca teknik bir tercih değil, çoğu zaman yasal bir gerekliliktir.

Logların asıl değeri, olay meydana geldikten sonra geçmişe dönük analiz yapmayı mümkün kılmasından gelir. Bu nedenle loglama olay yaşandıktan sonra değil, olay yaşanmadan önce etkin olmalıdır. Olaydan sonra loglamayı açmak, geçmişte yaşanan olayı geri getirmez.

1.2 Temel Log Türleri

İşletim sistemleri logları genellikle farklı kategorilere ayırır. Güvenlik bakış açısıyla en önemli üç ana log türü sistem logları, güvenlik logları ve uygulama loglarıdır.

Sistem logları, işletim sisteminin kendi bileşenlerine ait olayları içerir. Servislerin başlatılması veya durdurulması, sürücü hataları, donanım sorunları, önyükleme olayları ve sistem seviyesindeki hatalar bu kategoriye girer. Windows sistemlerde bu loglar Event Viewer içinde Windows Logs → System altında bulunur. Linux sistemlerde ise /var/log/syslog, /var/log/messages veya journalctl çıktıları bu bilgileri barındırabilir.

Güvenlik logları, kimlik doğrulama, yetkilendirme ve güvenlikle doğrudan ilgili olayları içerir. Başarılı ve başarısız giriş denemeleri, hesap oluşturma ve silme, yetki değişiklikleri, grup üyelikleri ve politika değişiklikleri bu log türünün kapsamındadır. Windows'ta bu kayıtlar Event Viewer içinde Windows Logs → Security altında yer alır. Linux tarafında Debian/Ubuntu sistemlerde /var/log/auth.log, RHEL/CentOS sistemlerde ise /var/log/secure dosyası bu amaçla kullanılır.

Uygulama logları, belirli uygulamaların ürettiği olayları içerir. Bir web sunucusunun erişim kayıtları, bir veritabanının hata logları, bir antivirüs yazılımının tespit kayıtları veya bir uygulamanın çalışma hataları uygulama loglarına örnektir. Windows'ta bu kayıtlar Event Viewer içinde Windows Logs → Application altında görüntülenebilir. Linux sistemlerde ise /var/log/ dizini altında uygulamaya özel dosyalar bulunabilir.

ÖrneK: Nginx için /var/log/nginx/access.log dosyası erişim kayıtlarını tutar.

Bu üç log türü birlikte değerlendirildiğinde sistemde neler yaşandığına dair daha net bir tablo ortaya çıkar. Tek başına güvenlik logu bir giriş denemesini gösterebilir; sistem logu aynı anda bir servisin durduğunu, uygulama logu ise ilgili uygulamanın hata verdiğini gösterebilir. Olay analizi bu parçaları birleştirme becerisidir.

1.3 Güvenlik Açısından Önemli Olaylar

Tüm log kayıtları aynı öneme sahip değildir. Bazı kayıtlar günlük sistem çalışmasının doğal parçasıyken, bazıları güvenlik açısından doğrudan takip edilmesi gereken kritik olaylardır. Güvenlik izleme sürecinde özellikle kimlik doğrulama, hesap yönetimi, servis değişiklikleri, sistem yeniden başlatmaları ve dosya erişimleri dikkatle incelenmelidir.

Dikkat: Bu olaylar, temel bir izleme öncelik listesinin başlangıç noktasıdır. Örneğin başarısız giriş denemeleri kaba kuvvet saldırılarını, yeni hesap oluşturma olayları yetkisiz kullanıcı eklemeyi, gruba üye ekleme olayları ise ayrıcalık genişletme girişimlerini gösterebilir.

Kurumsal ortamlarda SIEM (Security Information and Event Management) sistemleri bu tür kayıtları toplar, ilişkilendirir ve alarm üretir. Ancak bu modülde hedef, bir SIEM kullanmadan da temel log kayıtlarını okuyabilecek, filtreleyebilecek ve şüpheli olayları fark edebilecek düzeyde farkındalık kazanmaktır.

1.4 Log Saklama, Rotasyon ve Yasal Zorunluluklara Giriş

Log dosyaları zamanla büyür. Özellikle aktif sistemlerde her gün binlerce hatta milyonlarca kayıt oluşabilir. Bu kayıtlar sınırsız şekilde büyümeye bırakılırsa disk dolabilir ve sistem kararsız hâle gelebilir. Bu nedenle logların düzenli biçimde yönetilmesi gerekir.

Log rotasyonu, log dosyalarının belirli bir boyuta veya yaşa ulaştığında arşivlenmesi ve yeni bir log dosyasının açılması işlemidir. Linux'ta bu işlev genellikle logrotate aracıyla sağlanır. Windows'ta Event Viewer üzerinden her log türü için maksimum boyut ve eski kayıtların üzerine yazılma politikası ayarlanabilir.

Log saklama süresi, bir güvenlik olayının ne kadar geriye dönük incelenebileceğini doğrudan etkiler. Log saklama süresi çok kısa tutulursa, saldırının ne zaman başladığı ya da saldırganın sistemde ne kadar süre kaldığı anlaşılamayabilir. Pek çok güvenlik standardı ve sektörel düzenleme, logların belirli süreler boyunca saklanmasını zorunlu kılar. PCI-DSS, ISO 27001 ve benzeri standartlarda çoğu zaman en az 90 gün ile 1 yıl arasında log saklama gereklilikleri bulunur.

Log bütünlüğü de en az log saklama kadar önemlidir. Çünkü loglar saldırgan için de kritik hedeflerden biridir. Sisteme sızan bir saldırgan, izlerini gizlemek için logları silebilir, değiştirebilir veya üzerine yazılmasını sağlayabilir. Bu nedenle logların yalnızca sistem üzerinde tutulması yeterli olmayabilir.

Kurumsal yapılarda logların merkezi ve güvenilir bir log sunucusuna gönderilmesi tercih edilir. Böylece saldırgan ele geçirdiği sistemdeki logları silse bile merkezi log sunucusunda kayıtlar korunabilir. Bireysel veya küçük ölçekli sistemlerde ise logların periyodik yedeklenmesi ve bu yedeklerin korunması asgari bir önlem olarak değerlendirilmelidir.

Dikkat: "Loglarımız var." demek ile "Loglarımızı düzenli inceliyoruz ve bütünlüğünü koruyoruz." demek aynı şey değildir. Log tutmak başlangıçtır; logları izlemek, analiz etmek ve korumak güvenliğin gerçek parçasıdır.

2. Temel İzleme Yaklaşımı

2.1 Windows Event Viewer'a Giriş

Windows Event Viewer, yani Olay Görüntüleyici, Windows sistemlerde olay kayıtlarını merkezi bir arayüzde görüntülemeye yarayan yerleşik araçtır. Sistem yöneticileri ve güvenlik analistleri için temel denetim araçlarından biridir.

Event Viewer'ı açmak için Başlat menüsüne "Event Viewer" yazılabilir veya eventvwr.msc komutu çalıştırılabilir. Sol panelde Windows Logs başlığı altında beş ana kategori bulunur: Application, Security, Setup, System ve Forwarded Events. Güvenlik denetimlerinde özellikle Security ve System logları öncelikli olarak incelenir.

Her olay kaydı belirli bilgiler içerir. Bunlar olayın tarih ve saati, kaynağı, Event ID değeri, düzeyi, ilgili kullanıcı ve açıklama alanıdır. Düzey alanında Information, Warning, Error veya Critical gibi sınıflandırmalar bulunabilir. Bu bilgiler olayın ne kadar önemli olduğunu ve hangi bileşenle ilişkili olduğunu anlamaya yardımcı olur.

Event ID değerleri, olayları hızlı tanımak için kullanılır. Örneğin 4625 başarısız giriş denemesini, 4720 yeni kullanıcı hesabı oluşturulmasını, 4732 ise bir gruba üye eklenmesini ifade eder. Bu numaraları bilmek log analizini hızlandırır; çünkü binlerce kayıt içinde doğrudan önemli olay türlerine odaklanmak mümkün olur.

İpucu:Event Viewer içinde Filter Current Log özelliği kullanılarak belirli Event ID'ler, zaman aralıkları veya olay seviyeleri filtrelenebilir. Örneğin yalnızca son 24 saatteki başarısız giriş denemelerini görmek için Security logu içinde Event ID 4625 filtresi uygulanabilir.

2.2 Linux Syslog, Journal ve Temel Kayıt Mantığı

Linux sistemlerde log yapısı iki ana mekanizma etrafında şekillenir: geleneksel syslog dosyaları ve modern systemd journal yapısı.

Geleneksel syslog dosyaları /var/log/ dizini altında düz metin dosyaları olarak bulunur. Bu dosyalar standart metin araçlarıyla okunabilir, aranabilir ve filtrelenebilir. En sık karşılaşılan log dosyaları şunlardır:

Modern Linux dağıtımlarında systemd journal da önemli bir log kaynağıdır. Systemd, servis loglarını, çekirdek mesajlarını ve sistem olaylarını kendi binary log formatında toplar. Bu logları görüntülemek için journalctl komutu kullanılır.

İpucu: journalctl, logları belirli zaman aralıklarına, servis adlarına veya öncelik seviyelerine göre filtrelemeye imkân verir. Örneğin yalnızca SSH servisine ait kayıtları, yalnızca son bir saate ait hataları veya belirli bir tarih aralığındaki sistem olaylarını görüntülemek mümkündür.

Syslog dosyalarının düz metin olması büyük bir avantajdır. grep, cat, tail, less gibi standart araçlarla hızlı arama ve inceleme yapılabilir. Bu da Linux log analizini esnek ve güçlü hâle getirir.

2.3 Sistem İzleme Araçlarına Giriş

Log dosyaları geçmişte ne olduğunu gösterirken, sistem izleme araçları o anda ne olduğunu görmeyi sağlar. Bu iki bakış açısı birbirini tamamlar. Bir olayın geçmişteki kayıtları loglardan, mevcut etkisi ise izleme araçlarından anlaşılabilir.

Windows Task Manager, yani Görev Yöneticisi, Ctrl + Shift + Esc tuşlarıyla açılabilir. CPU, bellek, disk ve ağ kullanımını uygulama ve süreç düzeyinde gösterir. "Süreçler" sekmesi çalışan süreçleri, "Performans" sekmesi sistem genelindeki kaynak kullanımını, "Uygulama Geçmişi" sekmesi ise CPU ve ağ kullanımını uygulama bazında özetler.

Windows Resource Monitor, yani Kaynak İzleyici, Task Manager'dan daha ayrıntılı bilgi sunar. resmon komutuyla veya Task Manager içinden Performans → Kaynak İzleyicisi'ni Aç yoluyla erişilebilir. CPU, bellek, disk ve ağ sekmeleri üzerinden hangi sürecin hangi kaynağı kullandığı, hangi dosyalara eriştiği ve hangi ağ bağlantılarını kurduğu görülebilir.

Linux sistemlerde top ve htop araçları anlık süreç izleme için kullanılır. top komutu CPU ve bellek kullanımına göre sıralanmış süreç listesini gerçek zamanlı olarak günceller. htop ise daha görsel ve etkileşimli bir arayüz sunar; ancak bazı sistemlerde sonradan kurulması gerekebilir. Her iki araç da yüksek kaynak tüketen süreçleri fark etmek için kullanışlıdır.

macOS tarafında Activity Monitor, Windows Task Manager'a benzer şekilde çalışır. Spotlight üzerinden Cmd + Space tuşlarına basıp "Activity Monitor" yazarak açılabilir. CPU, Bellek, Enerji, Disk ve Ağ sekmeleri üzerinden sistemin anlık durumu izlenebilir.

2.4 Süreç, Servis ve Bağlantı Gözlemi Mantığı

Sistem izleme yalnızca CPU veya bellek kullanımına bakmaktan ibaret değildir. Hangi süreçlerin çalıştığı, hangi servislerin aktif olduğu ve sistemin hangi ağ bağlantılarını kurduğu birlikte değerlendirildiğinde daha anlamlı bir güvenlik resmi ortaya çıkar.

Süreç gözlemi yapılırken yalnızca süreç adına bakmak yeterli değildir. Sürecin hangi konumdan çalıştığı, hangi kullanıcı altında çalıştığı ve ne kadar kaynak tükettiği de incelenmelidir. Meşru bir sistem süreci genellikle beklenen dizinden çalışır. Aynı isimde ama farklı konumdan çalışan bir süreç güçlü bir şüphe işaretidir.

Servis gözlemi, sistemde arka planda çalışan servislerin düzenli olarak incelenmesini kapsar. Beklenmedik, tanımlanamayan veya sistemin görevine uygun olmayan servisler araştırılmalıdır. Servis kavramı önceki modüllerde ele alınmıştı; bu modülde servisler log ve izleme açısından değerlendirilir. Bir servis ne zaman başlatılmış, kim tarafından tetiklenmiş, hata vermiş mi, beklenmedik şekilde durmuş mu gibi sorular loglardan takip edilebilir.

Bağlantı gözlemi, sistemin o anda hangi dış adreslere bağlandığını anlamayı sağlar. Windows'ta netstat -ano, Linux'ta ss -tunap komutları aktif bağlantıları ve dinleyen portları gösterebilir. Bu bilgiler loglarla birlikte değerlendirildiğinde güçlü bir olay zaman çizelgesi oluşturulabilir. Örneğin hangi süreç, ne zaman, hangi uzak adrese bağlandı sorusunun cevabı güvenlik analizi için değerlidir.

Bu üç gözlem birlikte kullanıldığında sistemdeki olağandışı aktiviteleri daha erken fark etmek mümkün olur.

3. Şüpheli Durumları Tanıma

3.1 Başarısız Giriş Denemeleri

Tek bir başarısız giriş denemesi her zaman güvenlik olayı anlamına gelmez. Kullanıcı parolasını yanlış yazmış olabilir. Ancak kısa süre içinde aynı hesaba veya farklı hesaplara çok sayıda başarısız giriş denemesi yapılması kaba kuvvet saldırısına işaret edebilir.

Windows sistemlerde başarısız giriş denemeleri Security logu içinde Event ID 4625 ile kaydedilir. Bu olay kısa süre içinde çok sayıda tekrarlanıyorsa otomatik bir aracın parola denemesi yaptığı düşünülebilir. Linux tarafında /var/log/auth.log içinde Failed password for satırlarının sık tekrarlanması benzer bir anlama gelir.

Dikkat: Burada özellikle dikkat edilmesi gereken nokta, başarısız giriş denemelerinin ardından başarılı bir girişin gerçekleşip gerçekleşmediğidir. Windows'ta Event ID 4624 başarılı giriş olayını ifade eder. Linux'ta ise Accepted password veya Accepted publickey satırları başarılı girişi gösterir. Yoğun başarısız denemelerin ardından gelen başarılı giriş, saldırının başarıya ulaşmış olabileceğini gösterir.

İpucu: Bir hesapta 5 dakika içinde 50 başarısız giriş denemesi varsa bunu "dalgınlık" olarak yorumlanmamalıdır. Bu tür bir sıklık otomatik araç kullanımının güçlü göstergesidir. Kayıtları alın ve yetkili kişilere bildirin.

3.2 Beklenmeyen Süreç ve Uygulama Çalışmaları

Bir sistemde çalışması beklenmeyen süreçlerin görülmesi önemli bir uyarı işaretidir. Beklenmeyen süreç iki şekilde ortaya çıkabilir. İlki, daha önce hiç görülmemiş veya sistemde bulunması beklenmeyen bir süreç adıdır. İkincisi ise tanıdık görünen bir adın olağandışı bir konumdan veya olağandışı bir zamanda çalışmasıdır.

Bu tür durumları tespit etmek için başlangıç programları, servis başlatma ve durdurma olayları ile süreç oluşturma kayıtları incelenebilir. Windows'ta servis başlatma veya durdurma olayları Event ID 7036 ile görülebilir. Süreç oluşturma olayları için Event ID 4688 kullanılır; ancak bu loglama varsayılan olarak kapalı olabilir. Linux tarafında journalctl ile belirli bir servisin ne zaman başlatıldığı veya durdurulduğu sorgulanabilir.

Özellikle gece yarısı, hafta sonu veya sistemde aktivitenin düşük olması beklenen saatlerde başlatılan süreçler dikkat gerektirir. Aynı şekilde /tmp, AppData\Temp gibi geçici dizinlerden çalışan süreçler ya da adı sistem süreci gibi görünen ama dosya yolu farklı olan uygulamalar mutlaka araştırılmalıdır.

Unutma: Beklenmeyen süreçler her zaman zararlı yazılım anlamına gelmez; ancak kanıt toplanmadan normal kabul edilmemelidir. Sürecin adı, yolu, çalıştığı kullanıcı, başlama zamanı ve kaynak tüketimi birlikte değerlendirilmelidir.

3.3 Anormal Kaynak Kullanımı ve Performans Düşüşü

Sürekli yüksek CPU, bellek, disk veya ağ kullanımı her zaman donanım yetersizliği anlamına gelmez. Bazı durumlarda arka planda yetkisiz işlem yapan bir süreç sistem kaynaklarını tüketiyor olabilir. Kripto madenciliği yapan zararlı yazılımlar bu duruma iyi bir örnektir. Kullanıcı yalnızca sistemin yavaşladığını fark eder; ancak arka planda sistem kaynakları saldırganın çıkarı için kullanılıyor olabilir.

Bu tür durumları doğru değerlendirebilmek için sistemin normal çalışma davranışını bilmek gerekir. Bu referans duruma baseline, yani taban çizgisi denir. Bir sistemin normalde ne kadar CPU kullandığı, hangi servislerin çalıştığı ve hangi ağ bağlantılarını kurduğu biliniyorsa, sapmalar daha kolay fark edilir.

Task Manager, Resource Monitor, top, htop ve Activity Monitor gibi araçlar anlık kaynak kullanımını görmek için kullanılabilir. Yüksek kaynak tüketen süreçler listelendiğinde yalnızca tüketim oranına değil, sürecin adı, konumu ve çalıştığı kullanıcıya da bakılmalıdır.

Önemli: Log tarafında ise disk I/O anormallikleri sistem loglarından, bellek sorunları çekirdek loglarından, ağ bant genişliği tüketimi ise ağ arayüzü istatistiklerinden takip edilebilir. Anormal kaynak kullanımı tek başına kesin bir ihlal kanıtı değildir; ancak araştırılması gereken güçlü bir sinyaldir.

3.4 Beklenmeyen Ağ Trafiği ve Kullanıcı Hareketleri

Sistemin ağ üzerindeki davranışı, şüpheli durumları tespit etmek için güçlü bir göstergedir. Beklenmeyen ağ trafiği genellikle iki açıdan değerlendirilir: bilinmeyen dış adreslerle iletişim ve olağandışı trafik hacmi.

Bir ofis bilgisayarının gece 02:00'de büyük miktarda veri göndermesi normal bir davranış olmayabilir. Aynı şekilde bir sistemin daha önce hiç iletişim kurmadığı bir dış IP adresine düzenli aralıklarla küçük paketler göndermesi, komuta-kontrol yani C2 (Command and Control) iletişimine işaret edebilir. C2 altyapısı, saldırganların ele geçirdikleri sistemleri uzaktan yönetmek için kullandığı yapıdır.

Kullanıcı hareketleri de log analiziyle izlenebilir. Bir kullanıcının normalde bağlanmadığı saatlerde oturum açması, alışılmadık bir konumdan veya cihazdan giriş yapması, normalde erişmediği kaynaklara erişmesi ya da kısa sürede çok sayıda işlem yapması dikkat gerektirir. Bu tür anormallikler tek başına ihlal kanıtı olmayabilir; ancak mutlaka araştırılması gereken sinyallerdir.

Dikkat:Log analizinde önemli olan yalnızca tekil kayıtları okumak değildir. Zaman, kullanıcı, kaynak IP, hedef sistem ve olay türleri bir arada değerlendirilmelidir. Bu sayede olayın bağlamı anlaşılır.

Güvenli Alışkanlık: Logları yalnızca sorun yaşandığında değil, rutin olarak incelemek gerekir. Beklenmedik bir şeyin olmadığını doğrulamak, bir şeylerin yanlış gittiğini geç fark etmekten çok daha değerlidir.

Komut & Araç Okuryazarlığı

Bu bölümdeki komutlar ve araçlar, logları incelemek, başarısız girişleri görmek, sistem olaylarını filtrelemek ve kullanıcı giriş geçmişini değerlendirmek için kullanılır. Amaç logları değiştirmek değil, güvenli şekilde okumak ve bulguları kayıt altına almaktır.

Windows'ta Temel Kontrol

Event Viewer'da Başarısız Girişleri Filtreleme

Komut:

wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:20 /f:text

Amaç: Güvenlik günlüğündeki (Security log) son 20 başarısız giriş (failed logon) olayını ayrıntılı metin formatında gösterir.

Beklenen çıktı:

Bu komut, Windows Security logu içindeki başarısız giriş denemelerini hızlıca görmek için kullanılabilir. Çok sayıda 4625 kaydı, özellikle aynı kullanıcıya veya aynı kaynak adrese aitse, güvenlik açısından dikkatle incelenmelidir.

Windows Event Viewer

Windows Event Viewer grafik arayüz üzerinden de kullanılabilir. eventvwr.msc komutuyla veya Başlat menüsünden Event Viewer açılarak erişilebilir.

Güvenlik incelemesi için öncelikle Windows Logs → Security ve Windows Logs → System bölümleri incelenmelidir. Security logu giriş olaylarını, hesap değişikliklerini ve yetki olaylarını gösterir. System logu ise servis olayları, sistem hataları ve işletim sistemi bileşenleriyle ilgili kayıtları içerir.

Öğrenci özellikle kırmızı Error ve sarı Warning kayıtlarını incelemeli, Security logunda 4625, 4740, 4720 ve 4732 gibi Event ID'leri filtrelemeyi bilmelidir. Filtreleme için ilgili loga sağ tıklanır, Filter Current Log seçilir ve Event ID alanına istenen numara yazılır.

Kanıt amacıyla ilgili kayda sağ tıklanıp Save Selected Events seçeneğiyle kayıt dışa aktarılabilir. Böylece log kaydı inceleme dosyasına eklenebilir.

PowerShell ile Son Başarılı Girişleri Görme

Komut:

Get-EventLog -LogName Security -InstanceId 4624 -Newest 10 | Select TimeGenerated, Message

Amaç: Güvenlik günlüğündeki (Security log) son 10 başarılı giriş (successful logon) olayını listeler.

Beklenen çıktı:

Bu komut, son başarılı giriş kayıtlarını hızlıca görmek için kullanılabilir. Başarılı girişler, başarısız giriş denemeleriyle birlikte değerlendirildiğinde daha anlamlı hâle gelir. Yoğun başarısız denemeden sonra gelen başarılı giriş özellikle kritiktir.

Linux'ta Temel Kontrol

auth.log'dan Başarısız Girişleri Görme

Komut:

Bu komut, Debian/Ubuntu tabanlı sistemlerde başarısız SSH giriş denemelerini görmek için kullanılır. Aynı IP adresinden kısa sürede çok sayıda deneme yapılması, otomatik kaba kuvvet saldırısına işaret edebilir.

journalctl ile Servis Olaylarını Görme

Komut:

journalctl -u ssh --since "2025-01-10 00:00:00" --until "2025-01-10 06:00:00"

Amaç: Belirli bir zaman aralığında SSH servisine ait log kayıtlarını gösterir.

Beklenen çıktı:

Bu komut, belirli bir servis için belirli zaman aralığındaki logları incelemeyi sağlar. SSH gibi uzak erişim servislerinde başarısız ve başarılı giriş kayıtlarının birlikte değerlendirilmesi önemlidir.

journalctl ile Son Sistem Hatalarını Görme

Komut:

journalctl -p err --since "1 hour ago"

Amaç: Son 1 saatte üretilen hata düzeyindeki log kayıtlarını gösterir.

Beklenen çıktı:

Bu komut, sistemdeki son hata kayıtlarını hızlıca görmek için kullanılır. Servislerin başlamaması, çekirdek hataları veya dosya sistemi problemleri güvenlik ve süreklilik açısından önemli olabilir.

Belirli Kullanıcının Son Giriş Geçmişini Görme

Komut:

last ogrenci01

Amaç: Belirli kullanıcının sistem giriş geçmişini ve oturum sürelerini listeler.

Beklenen çıktı:

last komutu, kullanıcıların sistem giriş geçmişini görmek için kullanılır. Belirli bir kullanıcının normal giriş saatleri ve kaynak adresleriyle karşılaştırma yapmak, olağandışı oturumları fark etmeye yardımcı olur.

macOS'ta Temel Kontrol

Console — Konsol Uygulaması

macOS'ta logları grafik arayüz üzerinden incelemek için Console uygulaması kullanılabilir. Spotlight'a "Console" yazılarak veya Uygulamalar → Araçlar → Console yoluyla açılabilir.

Sol panelde sistem log dosyaları ve log kaynakları listelenir. Güvenlik açısından özellikle system.log ve secure.log kayıtları incelenebilir. Arama çubuğuna error, failed, denied gibi ifadeler yazılarak ilgili kayıtlar filtrelenebilir.

Güncel macOS sürümlerinde klasik log dosyalarının yanında Unified Logging yapısı da kullanılır. Bu yapıdaki kayıtlar log komutuyla incelenebilir. Örneğin son 1 saatte "failed" ifadesi geçen kayıtları görmek için şu komut kullanılabilir: bash log show \--predicate \'eventMessage contains "failed" --last 1h Canlı log akışını izlemek için ise şu komut kullanılabilir: bash log stream Bu komutlar sistem davranışını daha güncel ve ayrıntılı biçimde izlemek için kullanılabilir; ancak temel kullanıcılar için Console uygulaması hâlâ pratik bir başlangıç noktasıdır.

Kanıt amacıyla ilgili log satırları seçilip kopyalanmalı ve zaman damgasıyla birlikte not edilmelidir.

Son Kullanıcı Girişlerini Görme

Komut:

last -10

Amaç: Son 10 kullanıcı girişini, kaynağını ve süresini gösterir.

Beklenen çıktı:

Bu komut macOS üzerinde son kullanıcı girişlerini görmek için kullanılır. Beklenmeyen saatlerde yapılan girişler veya tanınmayan kaynaklardan gelen oturumlar güvenlik açısından incelenmelidir.

Temel Uygulama / Kontrol Listesi

Bu kontrol listesi, bir sistemde temel log incelemesi ve olay farkındalığı oluşturmak için kullanılabilir. Amaç son olayları gözden geçirmek, şüpheli girişleri tespit etmek, yeni hesap veya yetki değişikliklerini fark etmek ve bulguları kanıtlanabilir şekilde kaydetmektir.

Hazırlık

• Hangi sistemi incelediğinizi not edin: işletim sistemi, sürüm, tarih ve saat.
• İncelenecek zaman aralığını belirleyin.
• Bulguları kaydedeceğiniz bir not dosyası hazırlayın.
• Logları değiştirmeden yalnızca okuma ve kopyalama işlemi yapacağınızı netleştirin.

Kontrol Adımları

• Güvenlik logunda son 24 saatte başarısız giriş kaydı var mı? Windows için Event ID 4625, Linux için Failed password kayıtları incelenmelidir.
• Başarısız girişlerin ardından başarılı giriş var mı? Windows için Event ID 4624, Linux için Accepted password veya Accepted publickey kayıtları kontrol edilmelidir.
• Son 24 saatte yeni hesap oluşturulmuş mu? Windows için Event ID 4720, Linux için User account created kayıtları kontrol edilmelidir.
• Herhangi bir hesap gruba eklenmiş mi? Windows için Event ID 4732, Linux için User account added to group kayıtları kontrol edilmelidir.
• Sistem yeniden başlatılmış mı? Bu yeniden başlatma planlanan bir işlem miydi?
• Çalışan süreçler arasında yüksek kaynak kullanan ve tanımlanamayan süreç var mı?
• Sistem logunda servis başlatma veya durdurma hataları var mı?
• Ağ bağlantılarında tanımlanamayan dış adres var mı?
• Loglarda olağandışı saatlerde gerçekleşen kullanıcı hareketleri var mı?

Doğrulama

• Şüpheli log kayıtlarını tarih, saat ve Event ID bilgisiyle not alın.
• Şüpheli kaydın kaynak IP adresini veya hesap adını diğer loglarla çapraz doğrulayın.
• Başarısız giriş denemeleri ile başarılı girişleri aynı zaman çizelgesinde değerlendirin.
• Log dosyalarının kendi bütünlüğünü kontrol edin; son değiştirilme zamanı beklenen mi?
• Şüpheli süreç veya bağlantı varsa ilgili süreç adı, PID, dosya yolu ve kaynak kullanıcı bilgisiyle eşleştirin.

Kanıt Notu

• İlgili log satırlarını veya Event Viewer ekran görüntülerini tarih damgasıyla kaydedin.
• Her bulgu için şu bilgileri not alın: hangi log, hangi olay, hangi tarih/saat, hangi hesap/kaynak.
• Kaynak IP, hedef kullanıcı, Event ID, servis adı ve log dosyası adı gibi alanları ayrı ayrı belirtin.
• Kanıt niteliğindeki log dosyalarını değiştirmeyin.
• Dışa aktarılan log dosyalarını güvenli bir yerde saklayın.

Geri Dönüş / Dikkat Edilmesi Gerekenler

• Log dosyalarını silmeyin veya değiştirmeyin; kanıt niteliği taşırlar.
• Şüpheli bir bulguyu doğrudan müdahaleyle "temizlemeye" çalışmayın; önce yetkili kişileri bilgilendirin.
• Log analizinde "bu muhtemelen normaldir" varsayımından kaçının. Her anormalliği not alın ve sorgulayın.
• Olayın kapsamı netleşmeden hesap silme, servis kapatma veya dosya temizleme gibi işlemler yapmayın.
• Ciddi güvenlik bulgularında sistem yöneticisi veya güvenlik ekibiyle koordineli hareket edin.

Temel Operasyonel Senaryo

Senaryo: "Gece Saatlerinde Sisteme Başarılı Giriş Yapılmış"

Hafta içi sabah rutin güvenlik kontrolü sırasında sistem yöneticisi, bir Linux sunucusunun auth.log dosyasında gece saat 02:47'de localadmin kullanıcısıyla başarılı SSH girişi yapıldığını fark eder. Bu saatte herhangi bir planlı bakım yapılmamıştır ve localadmin hesabının bu zaman diliminde giriş yapması beklenmemektedir.

Bu durumda ilk sorular şunlar olmalıdır: Bu giriş yetkili bir kullanıcı tarafından mı yapıldı? Eğer yetkili bir işlemse neden bu saatte gerçekleşti? Girişten önce başarısız denemeler var mıydı? Giriş yapıldıktan sonra hangi komutlar çalıştırıldı? Kaynak IP adresi tanıdık mı?

Kontrol edilecek noktalar:

1. 1. grep \"localadmin\" /var/log/auth.log komutuyla o geceye ait tüm localadmin kayıtları incelenir.
2. 2. Başarılı girişin hemen öncesinde başarısız giriş denemeleri olup olmadığı kontrol edilir.
3. 3.last localadmin komutuyla kullanıcının tarihsel giriş örüntüsü incelenir. Bu saatte daha önce hiç giriş yapılmış mı bakılır.
4. 4. Kaynak IP adresi, örneğin 198.51.100.X, kurumun bilinen IP havuzuyla karşılaştırılır.
5. 5. journalctl \--since \"2025-01-10 02:40\" \--until \"2025-01-10 03:30\" komutuyla bu süre içindeki tüm sistem aktivitesi incelenir.

Toplanacak kanıtlar:

• İlgili auth.log satırlarının kopyası; tarih-saat damgalı olmalıdır.
• last localadmin çıktısı kaydedilmelidir.
• Kaynak IP adresi not edilmelidir.
• journalctl çıktısından ilgili zaman dilimindeki log kesiti saklanmalıdır.
• İnceleme tarihi, saati ve incelemeyi yapan kişinin adı kayıt altına alınmalıdır.

                    # Analiz Kaydı: 2025-01-11 | Analist: Uzman_Analiz_Ekibi
                    
                    root@analiz:~# grep "localadmin" /var/log/auth.log
                    Jan 10 02:43:12 sshd[4120]: Failed password for localadmin from 198.51.100.77
                    Jan 10 02:43:45 sshd[4124]: Failed password for localadmin from 198.51.100.77
                    ... (21 başarısız deneme daha) ...
                    Jan 10 02:47:01 sshd[4210]: Accepted password for localadmin from 198.51.100.77
                    
                    root@analiz:~# last localadmin
                    localadmin  pts/0  198.51.100.77  Fri Jan 10 02:47  still logged in
                    localadmin  pts/0  10.0.0.15      Mon Jan 06 09:12 - 17:45
                    
                    root@analiz:~# journalctl --since "02:40" --until "03:30"
                    Jan 10 02:47:15 sudo: localadmin : COMMAND=/usr/bin/apt install nmap
                    Jan 10 02:50:02 crontab: (localadmin) LIST (localadmin)
                    
                    

                    BULGU ÖZETİ:
                    - Kaynak IP: 198.51.100.77 (Kurum Dışı)
                    - Saldırı: Brute Force (23 Deneme) -> Başarılı Giriş
                    - Durum: KRİTİK - Hesap Ele Geçirildi

İnceleme sırasında grep çıktısı, giriş öncesinde 02:43'ten itibaren 198.51.100.77 adresinden 23 başarısız parola denemesi yapıldığını gösterir. Saat 02:47'de ise localadmin hesabıyla başarılı giriş gerçekleşmiştir.

last localadmin çıktısı, bu hesabın son üç ayda yalnızca mesai saatlerinde, yani 09:00--18:00 arasında ve kurumun iç ağ adres bloğundan giriş yaptığını göstermektedir. Kaynak IP olan 198.51.100.77, kurumun bilinen adres bloğu dışındadır.

Bu bulgular, girişin başarılı bir kaba kuvvet saldırısı sonucunda gerçekleşmiş olabileceğini gösterir. localadmin hesabı derhal devre dışı bırakılmalı, parolası sıfırlanmalı ve güvenlik birimi bilgilendirilmelidir. Girişten sonra sunucuda hangi işlemlerin yapıldığı kapsamlı log analiziyle araştırılmalıdır.

Bulgu → Etki → Öneri → Kanıt

Bulgu: Linux sunucusunda localadmin hesabına yönelik, 198.51.100.77 adresinden gece 02:43--02:47 arasında 23 başarısız SSH giriş denemesi yapıldığı ve 02:47'de bu hesapla başarılı giriş gerçekleştiği tespit edilmiştir. Kaynak IP kurumun bilinen adres bloğu dışındadır ve localadmin hesabı tarihsel olarak bu saatte giriş yapmamıştır.

Etki: localadmin hesabının ele geçirilmiş olma ihtimali yüksektir. Bu hesabın sunucuda sahip olduğu yetkilere bağlı olarak sistem yapılandırması, kullanıcı verileri ve diğer ağ kaynakları risk altında olabilir. Giriş sonrası yapılan işlemler henüz belirsizdir.

Öneri: localadmin hesabı derhal devre dışı bırakılmalı ve parolası sıfırlanmalıdır. Giriş sonrası faaliyetler kapsamlı log analiziyle soruşturulmalıdır. 198.51.100.77 adresinden gelen tüm bağlantılar güvenlik duvarı üzerinden engellenmeli ve bu adresin kaynağı araştırılmalıdır. Diğer hesapların ve sistemlerin benzer şekilde hedef alınıp alınmadığı kontrol edilmelidir.

Kanıt: /var/log/auth.log ilgili satırlarının kopyası tarih-saat damgalı şekilde saklanmalıdır. last localadmin çıktısı kayıt altına alınmalıdır. journalctl log kesiti korunmalıdır. İncelemeyi gerçekleştiren kişinin adı ve inceleme tarihi belgeye eklenmelidir.

Kendini Değerlendir — Loglama, İzleme ve Olay

Terimler Sözlüğü

Bu Modülde Kazanılan Yetkinlikler

• Bu modülde log kavramını öğrendik. Logların güvenlik olaylarının tespiti, adli analiz ve yasal uyumluluk açısından vazgeçilmez olduğunu; olay meydana gelmeden önce tutulmaya başlanması gerektiğini kavradık.
• Sistem, güvenlik ve uygulama log türlerini birbirinden ayırt ettik. Her birinin hangi olayları kapsadığını, Windows ve Linux sistemlerde hangi dosya veya araçlar üzerinden incelenebileceğini öğrendik.
• Güvenlik açısından kritik Event ID'leri tanıdık. 4624, 4625, 4720, 4732, 4740 ve 7036 gibi olay numaralarının log analizini hızlandırdığını ve anlamlı olayları hızla filtrelemeyi sağladığını gördük.
• Log rotasyonunun disk doluluğunu önlemek için gerekli olduğunu, ancak log saklama süresinin soruşturma kapasitesini doğrudan etkilediğini öğrendik. Kısa saklama sürelerinin geçmiş olayları incelemeyi zorlaştırabileceğini kavradık.
• Log bütünlüğünün neden önemli olduğunu ele aldık. Saldırganların izlerini örtmek için logları silebileceğini veya değiştirebileceğini, bu nedenle logların güvenilir ve ayrı bir konuma gönderilmesinin önemli olduğunu gördük.
• Windows Event Viewer'ı açmayı, ilgili log kategorilerini bulmayı, filtreleme ve dışa aktarma işlemlerini yapmayı öğrendik.
• Linux'ta /var/log/auth.log dosyasını ve journalctl komutunu temel düzeyde kullanmayı öğrendik. Zaman aralığı, öncelik ve servis bazlı filtreleme yapabileceğimizi gördük.
• grep, last, wevtutil ve Get-EventLog gibi araçlarla loglardan anlamlı bilgi çıkarabileceğimizi öğrendik.
• Task Manager, Resource Monitor, top, htop ve Activity Monitor aracılığıyla anlık sistem durumunu ve anormal kaynak kullanımını gözlemleyebileceğimizi kavradık.
• Başarısız giriş denemelerinin kalıbını; sıklık, kaynak ve hedef hesap bilgileriyle okuyarak kaba kuvvet saldırısını tanımayı öğrendik. Yoğun başarısız denemelerin ardından gelen başarılı girişin kritik bir uyarı olduğunu gördük.
• Beklenmedik süreçlerin yalnızca adından değil, çalıştığı konumdan, çalıştığı kullanıcıdan ve başlama saatinden de değerlendirilmesi gerektiğini kavradık.
• Anormal kaynak tüketiminin zararlı yazılım veya yetkisiz işlem göstergesi olabileceğini, baseline kavramının bu tespiti kolaylaştırdığını öğrendik.
• Gece saatlerindeki olağandışı ağ trafiği veya kullanıcı girişlerinin şüphe uyandırması gerektiğini gördük. Bu tür bulguların raporlanması ve yetkili kişilere iletilmesinin standart prosedür olduğunu kavradık.

Modül Teması

Bir işletim sistemi kurulduğunda, üretici tarafından geniş kullanıcı kitlesine uygun olacak şekilde yapılandırılmıştır. Bu varsayılan yapılandırmada çoğu zaman kullanım kolaylığı ön plandadır; güvenlik ise her zaman en sıkı hâliyle gelmeyebilir. Varsayılan ayarlar çoğu kullanıcı için makul bir başlangıç noktası sunar. Ancak güvenlik perspektifinden bakıldığında bu ayarlar gereksiz açık kapılar, kullanılmayan özellikler ve ihtiyaç duyulmayan servisler barındırabilir.

Sertleştirme (hardening), bir sistemi güvenlik açısından daha olgun ve daha kontrollü hâle getirme sürecidir. Bu süreçte gereksiz bileşenler devre dışı bırakılır, eksik güvenlik önlemleri eklenir ve sistem daha güvenli yapılandırmalarla çalışacak biçimde düzenlenir. Amaç sistemi kullanılamaz hâle getirmek değil, yalnızca gerçekten ihtiyaç duyulan özellikleri açık bırakarak saldırı yüzeyini daraltmaktır.

Bu modülde hardening kavramını, varsayılan ayarların neden risk oluşturabileceğini ve temel güvenlik kontrol listesi mantığını ele alacağız. Ardından kullanıcı cihazlarında uygulanabilecek temel sertleştirme adımlarına geçeceğiz: gereksiz uygulama ve özelliklerin kaldırılması, başlangıç programlarının kontrol edilmesi, ekran kilidi ve oturum güvenliği, cihaz şifrelemesi, Secure Boot ve başlangıç güveni zinciri.

Modülün son bölümünde güvenli kullanım disiplinine odaklanacağız. Düzenli bakım alışkanlığı, güvenli yazılım kullanımı, hesap güvenliğini sürdürülebilir kılma ve basit güvenlik olaylarında doğru ilk tepki verme gibi konuları inceleyeceğiz. Bu modül, eğitim serisinin kapanış bölümüdür ve önceki modüllerde öğrenilen tüm kavramların pratik bir güvenlik yaklaşımına dönüştürüldüğü son adımdır.

1. Sertleştirme Yaklaşımı

1.1 Sertleştirme Mantığı

Sertleştirme (hardening), bir sistemin saldırı yüzeyini azaltmak ve güvenlik açıklarını kapatmak için varsayılan yapılandırmanın ötesinde ek güvenlik önlemleri uygulanması sürecidir. Bu süreç tek seferlik bir kurulum adımı değildir; sistemin yaşam döngüsü boyunca devam eden bir güvenlik disiplinidir.

İşletim sistemleri çoğu zaman varsayılan olarak güvenlikten çok kullanılabilirlik odaklı kurulur. Çünkü üretici, aynı işletim sistemini farklı kullanıcı türlerine, farklı donanımlara ve farklı kullanım senaryolarına uygun hâle getirmek zorundadır. Bu nedenle bazı servisler, özellikler veya izinler varsayılan olarak açık gelebilir. Ancak her sistemin ihtiyacı aynı değildir.

Yeni kurulmuş bir Windows sisteminde Print Spooler servisi çalışıyor olabilir. Yazıcı kullanmayacak bir sunucuda bu servis gereksiz yük ve potansiyel risk oluşturur. Bir Linux sunucusunda varsayılan olarak aktif gelen bazı servisler, o sunucunun görevine göre anlamsız kalabilir. macOS üzerinde varsayılan olarak açık bırakılan bazı paylaşım hizmetleri de ihtiyaç duyulmadığında kapatılmalıdır.

Örnek: Sertleştirme sürecini yeni bir eve taşınmaya benzetebiliriz. Yeni eve geçtiğinizde tüm kapı ve pencereleri kontrol edersiniz, eski anahtarları değiştirirsiniz, kullanmadığınız girişleri kapatırsınız ve gerekiyorsa ek güvenlik önlemleri alırsınız. Bilgisayar sistemlerinde hardening de benzer bir mantıkla çalışır. Sistemi olduğu gibi bırakmak yerine, gereksiz açıklıkları kapatarak daha güvenli hâle getirirsiniz.

1.2 Varsayılan Ayarların Riskleri

Varsayılan yapılandırmaların risk taşımasının temel nedeni, üreticinin sistemi milyonlarca farklı kullanım senaryosu için hazırlamasıdır. Bu nedenle varsayılan ayarlar "herkes için çalışır" olmayı hedefler. Fakat "herkes için çalışır" bir sistem, her zaman "herkes için en güvenli" sistem anlamına gelmez.

Yaygın varsayılan risk alanlarından biri varsayılan parolalardır. Bazı cihazlar, uygulamalar veya yönetim arayüzleri admin/admin, root/root gibi herkes tarafından bilinen kullanıcı adı ve parola kombinasyonlarıyla gelebilir. Bu parolalar değiştirilmeden bırakılırsa, sisteme giriş kapısı fiilen herkese açık hâle gelir.

Bir diğer risk alanı gereksiz açık portlar ve servislerdir. Bir sunucuda ihtiyaç duyulmayan servisler varsayılan olarak çalışıyor olabilir. Her çalışan servis kendi saldırı yüzeyini, kendi hata ihtimallerini ve kendi güncelleme sorumluluğunu sisteme ekler.

Aşırı geniş varsayılan izinler de sık karşılaşılan bir problemdir. Bazı uygulamalar kurulum sırasında gereğinden fazla sistem izni alabilir. Bu durum uygulamanın ele geçirilmesi veya hatalı çalışması hâlinde zararın daha geniş bir alana yayılmasına neden olabilir.

Bazı sistemlerde ise güvenlik özellikleri varsayılan olarak tam etkin olmayabilir. Örneğin Windows'ta güvenlik denetimi loglaması varsayılan olarak her olayı ayrıntılı şekilde kaydetmeyebilir. Bu durumda bazı kritik olaylar kayıt altına alınmadığı için olay sonrası analiz zorlaşır.

Önemli: Bu riskler tek tek bakıldığında küçük görünebilir. Ancak bir araya geldiklerinde geniş bir saldırı yüzeyi oluştururlar. Sertleştirmenin amacı, bu küçük ama birikimli riskleri sistematik şekilde azaltmaktır.

1.3 Minimum İhtiyaç Kadar Servis ve Özellik Açma Yaklaşımı

Minimum ihtiyaç yaklaşımı, önceki modüllerde ele alınan en az ayrıcalık ilkesinin sistem yapılandırmasına uygulanmış hâlidir. Bu yaklaşıma göre bir sistemde yalnızca gerçekten ihtiyaç duyulan servisler çalışmalı, yalnızca gerekli özellikler etkin olmalı ve yalnızca gerekli portlar açık tutulmalıdır. Bunun dışında kalan her şey kapatılmalı, kaldırılmalı veya sınırlandırılmalıdır.

Bu yaklaşım pratikte iki şekilde uygulanır. İlki kaldırmadır. Kullanılmayan uygulamalar, servisler ve işletim sistemi bileşenleri sistemden tamamen çıkarılır. İkincisi devre dışı bırakmadır. Tamamen kaldırılamayan ancak o anda kullanılmayan özellikler kapatılır veya otomatik başlaması engellenir.

Örnek: bir web sunucusunda FTP servisi kurulu ama kullanılmıyorsa önce kaldırılması düşünülmelidir. Kaldırılamıyorsa servis durdurulmalı ve sistem açılışında otomatik başlaması engellenmelidir. Aynı şekilde Bluetooth, yazıcı servisi, dosya paylaşımı veya uzak masaüstü gibi özellikler yalnızca gerçekten ihtiyaç varsa açık tutulmalıdır.

Bu yaklaşımın güvenlik ve performans açısından somut faydası vardır. Daha az çalışan servis, daha az olası açık anlamına gelir. Aynı zamanda sistem kaynakları yalnızca gerçekten gerekli işlemler için kullanılır.

İpucu: "Bu servisi kapatırsam ne olur?" sorusuna cevap veremiyorsanız kapatmadan önce araştırın. Ancak "Bu servis ne işe yarıyor ve bu sistemde neden gerekli?" sorusunu da her açık servis için sormayı alışkanlık hâline getirin.

1.4 Temel Güvenlik Checklist Mantığı

Güvenlik checklist'i, bir sistemi sertleştirmek veya güvenlik durumunu doğrulamak için kontrol edilmesi gereken maddelerin sistematik listesidir. Checklist'in gücü, süreci kişisel hafızaya bırakmamasından gelir. Yazılı ve standart bir kontrol listesi kullanıldığında adımların atlanma ihtimali azalır.

Etkili bir temel güvenlik checklist'i birkaç ana kategori içerir.

İlk kategori hesap ve yetki yönetimidir. Kimlerin yönetici olduğu, varsayılan hesapların kapatılıp kapatılmadığı, parolaların güçlü olup olmadığı ve günlük kullanımın standart kullanıcı hesabıyla yapılıp yapılmadığı bu başlık altında değerlendirilir.

İkinci kategori güncelleme durumudur. İşletim sistemi ve uygulamalar güncel mi, otomatik güncelleme etkin mi, destek süresi dolmuş bileşen var mı gibi sorular bu alana girer.

Üçüncü kategori servis ve port durumudur. Gereksiz servisler kapalı mı, güvenlik duvarı aktif mi, beklenmedik açık port var mı gibi kontroller bu bölümde yapılır.

Dördüncü kategori şifreleme ve fiziksel güvenliktir. Disk şifrelemesi etkin mi, ekran kilidi aktif mi, BIOS/UEFI parola ile korunuyor mu, Secure Boot açık mı gibi konular burada değerlendirilir.

Beşinci kategori loglama ve izlemedir. Güvenlik logları aktif mi, log saklama politikası tanımlı mı, kritik olaylar kayıt altına alınıyor mu gibi sorular bu başlığın parçasıdır.

Endüstride CIS (Center for Internet Security) Benchmarks ve DISA STIG gibi kapsamlı sertleştirme kılavuzları yayımlanmaktadır. Temel seviye bir yaklaşım, bu kılavuzların en kritik başlıklarını anlamak ve kendi sistemine uygulanabilir hâle getirmekle başlar.

2. Kullanıcı Cihazlarında Temel Hardening

2.1 Gereksiz Uygulama ve Özelliklerin Kaldırılması

İşletim sistemiyle birlikte gelen veya zaman içinde kullanıcı tarafından kurulan her uygulama sisteme ek yük ve potansiyel güvenlik riski getirir. Kullanılmayan bir uygulama çoğu zaman güncellenmez. Güncellenmeyen uygulamalar ise zamanla bilinen zafiyetleri taşıyan unutulmuş bileşenlere dönüşebilir.

Bu nedenle gereksiz uygulamaların kaldırılması, sertleştirmenin en doğrudan adımlarından biridir. Sistemde yalnızca gerçekten kullanılan, güncel tutulan ve güvenilir kaynaklardan yüklenen uygulamalar bulunmalıdır.

Windows'ta Uygulamalar ve Özellikler menüsünden kurulu programlar listelenebilir ve ihtiyaç duyulmayanlar kaldırılabilir. Linux'ta paket yöneticisi, örneğin apt veya dnf, kurulu paketleri listelemek ve gereksiz paketleri kaldırmak için kullanılabilir. macOS'ta kullanılmayan uygulamalar Uygulamalar klasöründen silinebilir; ancak bazı sistem uygulamaları SIP koruması nedeniyle kaldırılamaz.

Uygulama kaldırmanın yanında Windows Özellikleri de gözden geçirilmelidir. Denetim Masası üzerinden Programlar → Windows Özelliklerini Aç veya Kapat ekranına girilerek Telnet İstemcisi, TFTP İstemcisi veya Internet Information Services gibi çoğu kullanıcının ihtiyaç duymadığı bileşenler devre dışı bırakılabilir.

Buradaki amaç sistemi eksiltmek değil, yalnızca sistemin görevini yerine getirmesi için gerekli olan bileşenleri bırakmaktır.

2.2 Başlangıç Programlarının Kontrolü

Sistem açıldığında otomatik olarak başlayan programlar, hardening sürecinin en önemli kontrol noktalarından biridir. Gereksiz başlangıç programları performansı düşürebilir, saldırı yüzeyini genişletebilir ve bazı durumlarda zararlı yazılımların kalıcılık mekanizması olarak kullanılabilir.

Windows'ta başlangıç programlarını yönetmek için birkaç yöntem bulunur. Task Manager içinde Başlangıç sekmesi, otomatik başlayan uygulamaları listeler. msconfig aracı da bazı başlangıç yapılandırmalarını incelemek için kullanılabilir. Daha teknik bir kontrol için kayıt defterindeki

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run anahtarı incelenebilir.

Tanımadığınız bir başlangıç girişini hemen silmek doğru yaklaşım değildir. Önce ne işe yaradığını, hangi dosya yolundan çalıştığını ve hangi uygulamaya ait olduğunu araştırmak gerekir. Çünkü bazı meşru güvenlik veya sistem bileşenleri de başlangıçta çalışabilir.

Linux'ta başlangıç servisleri çoğunlukla systemd üzerinden yönetilir. systemctl list-unit-files \--type=service komutu servislerin durumunu gösterir. enabled durumundaki servisler sistem başlangıcında otomatik olarak devreye girer.

macOS'ta Sistem Ayarları → Genel → Başlangıç Öğeleri bölümü kullanılabilir. Ayrıca /Library/LaunchDaemons ve /Library/LaunchAgents dizinleri de otomatik başlayan öğeler açısından incelenmelidir.

Dikkat: Başlangıç öğeleri listesinde adını tanımadığınız ve konumu olağandışı görünen bir giriş, zararlı yazılım kalıcılık mekanizmasının belirtisi olabilir. Özellikle geçici dizinlerden veya kullanıcı profili içindeki beklenmedik klasörlerden çalışan öğeler dikkatle araştırılmalıdır.

2.3 Ekran Kilidi ve Oturum Güvenliği

Bir bilgisayarın fiziksel güvenliğinde en temel savunmalardan biri ekran kilididir. Kullanıcı masadan kalktığında oturumu açık bırakırsa, o bilgisayara fiziksel olarak erişen herhangi biri yetkili kullanıcı gibi sistemi kullanabilir. Bu durum özellikle ofis ortamlarında, ortak çalışma alanlarında, okul laboratuvarlarında ve taşınabilir cihazlarda ciddi risk oluşturur.

Otomatik ekran kilidi, belirli bir süre hareketsizlikten sonra sistemin kendini kilitlemesini sağlar. Windows'ta Güç Seçenekleri veya Ekran Koruyucu ayarlarından, Linux'ta kullanılan masaüstü ortamının ayarlarından, macOS'ta ise Sistem Ayarları → Kilit Ekranı bölümünden yapılandırılabilir. Kurumsal güvenlik politikalarında genellikle 5-15 dakika arası hareketsizlik süresi standart olarak kabul edilir.

Oturum zaman aşımı, özellikle uzak bağlantılar için önemlidir. SSH veya RDP oturumu uzun süre açık bırakılırsa, bu bağlantıya fiziksel veya mantıksal erişim sağlayan biri oturumu kötüye kullanabilir. SSH tarafında ClientAliveInterval ve ClientAliveCountMax ayarlarıyla bağlantı zaman aşımı yapılandırılabilir.

İpucu: Hızlı ekran kilitleme kısayollarını alışkanlık hâline getirmek basit ama etkili bir güvenlik davranışıdır. Windows'ta Win + L, macOS'ta Ctrl + Cmd + Q kısayolları sistemi hızlıca kilitlemek için kullanılabilir.

2.4 Cihaz Şifreleme, Secure Boot ve Başlangıç Güveni Zinciri

Disk şifrelemesi, cihazın fiziksel olarak ele geçirilmesi, kaybolması veya diskin sökülmesi durumunda verinin okunamaz kalmasını sağlar. Önceki modüllerde disk şifreleme temel düzeyde ele alınmıştı; bu modülde ise sertleştirmenin vazgeçilmez bir adımı olarak değerlendirilir.

Windows'ta BitLocker, Linux'ta LUKS, macOS'ta FileVault disk şifrelemesi için kullanılan yerleşik çözümlerdir. Disk şifrelemesi etkin değilse, fiziksel erişim sağlayan biri diski çıkarıp başka bir sisteme bağlayarak verileri okuyabilir. Bu nedenle özellikle dizüstü bilgisayarlarda ve hassas veri içeren cihazlarda disk şifrelemesi kritik bir güvenlik katmanıdır.

Secure Boot, sistemi önyükleme aşamasında koruyan bir UEFI güvenlik özelliğidir. Yalnızca imzalanmış ve güvenilir önyükleyicilerin çalışmasına izin verir. Bu sayede önyükleme sürecine zararlı veya değiştirilmiş bir bileşenin dahil edilmesi zorlaştırılır. Hardening sürecinde Secure Boot'un etkin olduğunun doğrulanması önemli bir kontrol maddesidir.

Başlangıç güveni zinciri (chain of trust), cihaz açıldığı andan işletim sistemi tamamen yüklenene kadar geçen her aşamada yazılım bütünlüğünün doğrulanması ilkesidir. UEFI firmware, Secure Boot, önyükleyici ve işletim sistemi çekirdeği birbirini takip eden bir doğrulama zinciri oluşturur. Zincirin bir halkasında bozulma varsa, sonraki aşamaların güvenilirliği de şüpheli hâle gelir.

Önemli: TPM (Trusted Platform Module) çipi bu süreçte kriptografik anahtarların güvenli şekilde saklanmasına ve platform bütünlüğünün ölçülmesine yardımcı olur. BitLocker gibi çözümler TPM'den yararlanarak disk şifreleme ve sistem bütünlüğü arasında daha güçlü bir bağ kurabilir.

3. Güvenli Kullanım Disiplini

3.1 Düzenli Kontrol ve Bakım Alışkanlığı

Hardening, yalnızca sistem kurulduktan sonra yapılan tek seferlik bir işlem değildir. Sistem zamanla değişir: yeni uygulamalar kurulur, servisler eklenir, kullanıcılar yetki kazanır, güncellemeler ertelenir ve bazı güvenlik ayarları fark edilmeden devre dışı kalabilir. Periyodik kontrol yapılmazsa bu değişiklikler birikir ve sistem yavaş yavaş güvenli başlangıç noktasından uzaklaşır.

Sürdürülebilir güvenlik için düzenli bakım rutini oluşturmak gerekir. Aylık düzeyde güncellemelerin uygulandığı doğrulanmalı, başlangıç programları gözden geçirilmeli ve yönetici grubu üyeleri kontrol edilmelidir.

Üç ayda bir daha geniş kapsamlı bir kontrol yapılabilir. Kurulu uygulamalar incelenmeli, ihtiyaç duyulmayanlar kaldırılmalı, açık portlar ve çalışan servisler listelenmeli, log saklama durumu gözden geçirilmelidir.

Yılda bir veya büyük sistem değişikliklerinden önce kapsamlı güvenlik değerlendirmesi yapılmalıdır. Disk şifrelemesi, Secure Boot, BIOS/UEFI parolası, güvenlik duvarı durumu ve temel loglama ayarları yeniden doğrulanmalıdır.

Dikkat: Bu rutini takvime yazmak ve tamamlanan adımları işaretlemek basit görünür; ancak güvenliği sürdürülebilir hâle getirir. Plansız ve yalnızca sorun çıkınca yapılan kontroller yerine düzenli bakım disiplini daha güvenilir sonuç verir.

3.2 Güvenli Yazılım Kullanımı

Güvenli yazılım kullanımı, eğitim boyunca farklı modüllerde ele alınan birçok konunun birleşimidir. Resmî kaynaklardan indirme, hash doğrulama, sahte kurulum tuzaklarından kaçınma, güncelleme yönetimi ve gereksiz uygulamaları kaldırma bu disiplinin parçalarıdır.

Güvenli yazılım kullanımının ilk ilkesi, yazılımları her zaman resmî kaynaktan indirmektir. İndirme yapılmadan önce URL doğrulanmalıdır. Arama motorlarında çıkan ilk sonuç her zaman doğru kaynak olmayabilir; reklamlar veya sahte indirme siteleri kullanıcıyı yanıltabilir.

Kurulum sırasında "Hızlı kurulum" seçeneği her zaman en güvenli seçenek değildir. Bazı kurulum sihirbazları ek yazılım, araç çubuğu veya gereksiz bileşenler yükleyebilir. Bu nedenle kurulum adımları dikkatle okunmalı, ihtiyaç duyulmayan seçenekler devre dışı bırakılmalıdır.

Kullanılmaya devam edilen uygulamalar güncel tutulmalıdır. Bir yazılımı aktif olarak kullanıyorsanız, güncellemesini ertelemek o yazılım üzerinden sisteme risk taşımak anlamına gelebilir.

Tarayıcı uzantılarına ayrıca dikkat edilmelidir. Her uzantı, tarayıcının eriştiği veriler üzerinde geniş yetkilere sahip olabilir. Bu nedenle yalnızca güvenilir, bilinen ve gerçekten ihtiyaç duyulan uzantılar kurulmalıdır.

Dikkat: Kullanılmayan uygulamalar sistemde bırakılmamalıdır. Kurulu kalan ama uzun süredir güncellenmeyen uygulamalar, zaman içinde birikmiş güvenlik açığı anlamına gelebilir.

3.3 Hesap Güvenliğini Sürdürülebilir Hâle Getirme

Hesap güvenliği bir kez ayarlanıp bırakılacak bir konu değildir. Zaman içinde kullanıcı alışkanlıkları gevşeyebilir, geçici yetkiler kalıcı hâle gelebilir, eski hesaplar unutulabilir ve MFA gibi güvenlik önlemleri devre dışı bırakılabilir. Bu durum sertleştirmenin tersine dönmesine neden olur.

Sürdürülebilir hesap güvenliği için ilk pratik yaklaşım parola yöneticisi kullanmaktır. Parola yöneticisi olmadan her hesap için güçlü ve benzersiz parola tutmak zamanla neredeyse imkânsız hâle gelir. Parola yöneticisi, güçlü parolaları üretir, saklar ve kullanıcı üzerindeki ezber yükünü azaltır.

İkinci önemli alışkanlık MFA'yı mümkün olan her hesapta etkin tutmaktır. Özellikle e-posta, bulut hizmetleri ve kurumsal erişim noktaları için MFA kritik öneme sahiptir. Tek bir parolanın ele geçirilmesi durumunda ikinci doğrulama katmanı hesabın korunmasına yardımcı olur.

Üçüncü adım hesap erişim izinlerini periyodik olarak gözden geçirmektir. Zaman içinde bir kullanıcıya geçici yönetici yetkisi verilebilir ve bu yetki daha sonra unutulabilir. Eski çalışanların hesapları aktif kalabilir. Görev değişikliği yapan kullanıcılar hâlâ eski kaynaklara erişiyor olabilir. Bu tür durumlar düzenli kontrol edilmezse aşırı yetki birikimi oluşur.

Dördüncü olarak hesap uyarıları aktif tutulmalıdır. Birçok servis yeni cihaz girişi, şüpheli oturum açma veya olağandışı aktivite için e-posta bildirimi gönderebilir. Bu bildirimleri kapatmak yerine takip etmek, hesap ele geçirme girişimlerini erken fark etmeye yardımcı olur.

3.4 Basit Olaylarda İlk Tepki Farkındalığı

Bir güvenlik belirtisiyle karşılaşıldığında panikle verilen ilk tepki çoğu zaman olayı daha da zorlaştırır. Şüpheli dosya silinebilir, loglar değiştirilebilir, sistem yeniden başlatılabilir veya aktif kanıtlar kaybolabilir. Doğru ilk tepki, çoğu zaman ne yapacağını bilmek kadar ne yapmaması gerektiğini bilmekle ilgilidir.

Bir belirti fark edildiğinde önce durum not alınmalıdır. Ne görüldü, ne zaman fark edildi, hangi sistemde gerçekleşti ve hangi koşullar altında ortaya çıktı gibi bilgiler kaydedilmelidir. Ardından mümkünse ekran görüntüsü alınmalı, ilgili log satırları kopyalanmalı ve kanıt niteliğindeki bilgiler korunmalıdır.

Sistem hemen kapatılmamalı veya yeniden başlatılmamalıdır. Çünkü aktif bellekte, çalışan süreçlerde veya açık bağlantılarda değerli kanıtlar bulunabilir. Şüpheli dosya merak amacıyla çalıştırılmamalı, log dosyaları silinmemeli ve olay rapor edilmeden geçiştirilmemelidir.

Yetkili kişi veya birim bilgilendirilmelidir. Bu kişi kurum yapısına göre güvenlik sorumlusu, IT yöneticisi veya sistem yöneticisi olabilir. Bireysel kullanımda ise en azından olayın kayıt altına alınması, sistemin güvenilir araçlarla taranması ve gerekirse profesyonel destek alınması doğru yaklaşımdır.

Dikkat: .
Basit kural şudur: Emin değilseniz dokunmayın, bildirin. Bu yaklaşım çok sayıda olayda kanıtların korunmasını ve müdahalenin daha sağlıklı yapılmasını sağlar.

Örnek: Bir çalışan bilgisayarında tanımadığı bir pop-up penceresi gördüğünde "Tamam" düğmesine basmak yerine pencereyi kapatır, ekran görüntüsü alır ve IT birimine iletir. Bu davranış, güvenlik olayının yayılmasını önlemiş olabilir.

Komut & Araç Okuryazarlığı

Bu modülde komut odağı, sertleştirme durumunu denetlemek ve belgelemek üzerinedir. Buradaki amaç sistemi değiştirmek değil, mevcut güvenlik durumunu güvenli şekilde gözlemlemek ve bulguları kayıt altına almaktır.

Windows'ta Temel Kontrol

BitLocker Durumunu Görme

Komut:

manage-bde -status C:

Amaç: C: sürücüsünün BitLocker şifreleme durumunu gösterir.

Beklenen çıktı:

Amaç: Seçilen sürücünün (C:) BitLocker şifreleme durumunu, yöntemini ve koruma aktifliğini gösterir.

Bu komut, Windows sistemlerde disk şifrelemesinin etkin olup olmadığını kontrol etmek için kullanılır. Özellikle dizüstü bilgisayarlarda BitLocker'ın açık olması kritik bir hardening adımıdır.

Başlangıç Programlarını Listeleme

Komut:

Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location

Amaç: Sistemde kayıtlı tüm başlangıç uygulamalarını ve konumlarını listeler.

Beklenen çıktı:

Bu komut, sistem açılışında otomatik çalışan uygulamaları görmek için kullanılır. Tanınmayan, olağandışı konumdan çalışan veya kullanıcı tarafından kurulmamış görünen başlangıç öğeleri araştırılmalıdır.

Çalışan Servisleri ve Durumlarını Listeleme

Komut:

Get-Service | Where-Object {$_.Status -eq "Running"} | Select-Object Name, DisplayName

Amaç: O anda çalışan tüm Windows servislerini listeler.

Beklenen çıktı:

Bu komut, çalışan servisleri hızlıca görmek için kullanılır. Gereksiz servislerin tespiti, sistemin saldırı yüzeyini azaltmak için önemli bir adımdır.

Windows Security - Cihaz Güvenliği

Windows'ta cihaz güvenliği durumu grafik arayüz üzerinden de kontrol edilebilir. Bunun için Başlat → Windows Güvenlik → Cihaz Güvenliği yolu izlenir.

Bu ekranda Çekirdek yalıtımı, Güvenli önyükleme ve TPM bilgileri görülebilir. Kullanıcı özellikle Secure Boot'un etkin olup olmadığını ve çekirdek yalıtımı, yani Memory Integrity özelliğinin açık olup olmadığını kontrol etmelidir.

Kanıt amacıyla bu ekranın ekran görüntüsü tarih bilgisiyle birlikte saklanabilir.

Linux'ta Temel Kontrol

Disk Şifreleme Durumunu Görme

Komut:

lsblk -o NAME,FSTYPE,MOUNTPOINT,SIZE

Amaç: Disk bölümlerini ve dosya sistemi türlerini listeler; şifreli bölümler "crypto_LUKS" olarak görünür.

Beklenen çıktı:

Bu komut, Linux sistemlerde disk bölümlerinin şifreli olup olmadığını anlamak için kullanılabilir. Ana sistem bölümünün şifrelenmemiş olması, fiziksel erişim senaryolarında veri güvenliği açısından risk oluşturur.

Gereksiz Servisleri Görme ve Değerlendirme

Komut:

systemctl list-unit-files --type=service --state=enabled

Amaç: Sistem başlangıcında otomatik olarak etkinleşen servisleri listeler.

Beklenen çıktı:

Bu komut, sistem başlangıcında otomatik çalışan servisleri görmek için kullanılır. Özellikle sunucu sistemlerde Bluetooth, yazıcı servisi veya kullanılmayan ağ servisleri dikkatle değerlendirilmelidir.

Secure Boot Durumunu Görme

Komut:

mokutil --sb-state

Amaç: Secure Boot'un etkin olup olmadığını gösterir.

Beklenen çıktı (etkin):

Bu komut, Linux sistemlerde Secure Boot durumunu kontrol etmek için kullanılabilir. Secure Boot'un devre dışı olması, özellikle hassas sistemlerde ayrıca değerlendirilmesi gereken bir bulgudur.

macOS'ta Temel Kontrol

FileVault Durumunu Görme

Komut:

fdesetup status

Amaç: FileVault disk şifrelemesinin durumunu gösterir.

Beklenen çıktı (etkin):

FileVault is On.

Beklenen çıktı (devre dışı):

Bu komut, macOS cihazlarda disk şifrelemesinin etkin olup olmadığını kontrol eder. FileVault kapalıysa cihaz kaybı veya hırsızlık durumunda veri güvenliği ciddi şekilde zayıflar.

macOS Sistem Ayarları - Gizlilik ve Güvenlik

macOS üzerinde güvenlik ayarları grafik arayüzden de incelenebilir. Bunun için Apple Menüsü → Sistem Ayarları → Gizlilik ve Güvenlik yolu izlenir.

Bu ekranda FileVault durumu, güvenlik duvarı durumu ve uygulama indirme kısıtlamaları kontrol edilebilir. Öğrenci şu sorulara cevap aramalıdır: FileVault etkin mi? Güvenlik duvarı açık mı? Uygulama indirme yalnızca App Store veya tanımlı geliştiricilerle sınırlı mı?

Kanıt amacıyla bu ekranın ekran görüntüsü tarih bilgisiyle birlikte saklanabilir.

Temel Uygulama / Kontrol Listesi

Bu kontrol listesi, eğitimin kapsamlı kapanış kontrol listesidir. Önceki modüllerde öğrenilen tüm güvenlik katmanlarını bir arada değerlendirmek için kullanılabilir.

Hazırlık

• Hangi sistemi denetlediğinizi not edin: işletim sistemi, sürüm, cihaz adı ve tarih.
• Yönetici veya gerekli yetki düzeyine sahip olduğunuzu doğrulayın.
• Bulguları kaydedeceğiniz bir not dosyası hazırlayın.
• Büyük değişiklikler yapılacaksa önce yedek durumunu kontrol edin.

Kontrol Adımları

Hesap ve Yetki

• Yönetici grubu yalnızca yetkili hesapları içeriyor mu?
• Varsayılan veya anonim hesaplar, örneğin Guest hesabı, devre dışı mı?
• Günlük kullanım standart kullanıcı hesabıyla mı yapılıyor?
• Geçici verilmiş yönetici yetkileri kalıcı hâle gelmiş mi?

Güncelleme

• İşletim sistemi güncel mi?
• Kritik uygulamalar güncel mi?
• Otomatik güncelleme etkin mi?
• Destek süresi dolmuş işletim sistemi veya uygulama var mı?

Servis ve Port

• Güvenlik duvarı tüm profillerde etkin mi?
• Gereksiz servisler devre dışı mı?
• Beklenmedik açık port var mı?
• Uzak erişim servisleri gerçekten gerekli mi?

Şifreleme ve Fiziksel Güvenlik

• Disk şifrelemesi, yani BitLocker, LUKS veya FileVault etkin mi?
• Secure Boot etkin mi?
• Otomatik ekran kilidi yapılandırılmış mı?
• BIOS/UEFI parolayla korumalı mı?

Loglama

• Güvenlik logları etkin mi?
• Log saklama politikası tanımlı mı?
• Kritik olaylar loglanıyor mu?
• Logların silinmesine veya değiştirilmesine karşı önlem var mı?

Yazılım

• Kullanılmayan uygulamalar kaldırılmış mı?
• Başlangıç programları listesi temiz mi?
• Antivirüs veya güvenlik yazılımı aktif ve güncel mi?
• Tarayıcı uzantıları güvenilir ve gerekli mi?

Doğrulama

• Her başlıkta durumu "evet" veya "hayır" olarak işaretleyin.
• "Hayır" veya "bilinmiyor" yanıtlarını aksiyon gerektiren bulgular olarak not alın.
• Kritik bulguları önceliklendirin.
• Düzeltme yapıldıysa tekrar kontrol ederek sonucu doğrulayın.

Kanıt Notu

• Her önemli kontrol adımının çıktısını ekran görüntüsü veya metin olarak kaydedin.
• Her bulgu için şu bilgileri not alın: kontrol maddesi, mevcut durum,gerekli aksiyon.
• Komut çıktılarında tarih, sistem adı ve incelemeyi yapan kişi bilgisi yer almalıdır.
• Yapılandırma değişikliği yapılacaksa değişiklik öncesi mevcut durum mutlaka belgelenmelidir.

Geri Dönüş / Dikkat Edilmesi Gerekenler

• Bir servisi devre dışı bırakmadan önce sistemin bu servise bağımlı olmadığını doğrulayın.
• Disk şifrelemesini etkinleştirmeden önce kurtarma anahtarını güvenli biçimde saklayın.
• Büyük yapılandırma değişikliklerinden önce sistem yedeği alın.
• Bu kontrol listesini periyodik olarak, en az üç ayda bir, tekrarlayın.
• Güvenlik bulgularını yalnızca not almakla bırakmayın; her bulgu için takip edilebilir aksiyon oluşturun.

Temel Operasyonel Senaryo

Senaryo: "Teslim Alınan Sistemin Sertleştirme Değerlendirmesi"

IT birimi, kuruma yeni katılan bir çalışan için hazırlanan dizüstü bilgisayarı teslim etmeden önce temel güvenlik değerlendirmesini yapmayı unutmuştur. Bilgisayar standart Windows kurulumu içermektedir ve ek güvenlik yapılandırması yapılmamıştır. Sistem kullanıcıya verilmeden önce sertleştirme durumunu değerlendirme görevi size verilmiştir.

Bu durumda standart kurulumda hangi risklerin bulunduğu sistematik biçimde kontrol edilmelidir. Disk şifreli mi? Güvenlik duvarı aktif mi? Gereksiz servisler çalışıyor mu? Windows güncelleme durumu nedir? Hesaplar doğru yapılandırılmış mı? Ekran kilidi ve cihaz güvenliği ayarları doğru mu?

Kontrol edilecek noktalar şunlardır:

1. 1. manage-bde -status C: komutuyla BitLocker durumu kontrol edilir.
2. 2. netsh advfirewall show allprofiles komutuyla güvenlik duvarı durumu kontrol edilir.
3. 3. Windows Update Ayarları ekranından güncelleme durumu incelenir.
4. 4. net localgroup administrators komutuyla yönetici grubundaki hesaplar listelenir.
5. 5. Get-Service | Where-Object {$_.Status -eq "Running"} komutuyla çalışan servisler incelenir.
6. 6. Task Manager → Başlangıç sekmesinden başlangıç programları kontrol edilir.
7. 7. Ekran kilidi süresinin yapılandırılmış olup olmadığı kontrol edilir.
8. 8. Windows Security → Cihaz Güvenliği ekranından Secure Boot durumu doğrulanır.

Toplanacak kanıtlar:

• manage-bde -status C: çıktısı
• netsh advfirewall show allprofiles çıktısı
• Windows Update Ayarları ekran görüntüsü
• net localgroup administrators çıktısı
• Çalışan servisler listesi
• Başlangıç programları listesi ekran görüntüsü
• Windows Security → Cihaz Güvenliği ekran görüntüsü
• İnceleme tarihi, saati ve incelemeyi yapan kişinin adı

                    # Güvenlik Denetim Kaydı | Analist: [İsim] | Tarih: 2025-01-11
                    
                    PS C:\> manage-bde -status C:
                    BitLocker Drive Encryption: Configuration Tool
                    Volume C: [OSDisk]
                        Conversion Status:    Fully Decrypted
                        Percentage Encrypted: 0.0%
                        Protection Status:    Protection Off
                    
                    PS C:\> net localgroup administrators
                    Members
                    -------------------------------------------------------------------------------
                    Administrator
                    ogrenci01 (Şüpheli Yetki Artışı)
                    
                    PS C:\> Get-Service | Where-Object {$_.Status -eq "Running"}
                    Status   Name               DisplayName
                    ------   ----               -----------
                    Running  Spooler            Print Spooler (Gereksiz Servis)
                    
                    PS C:\> Windows_Update_Check
                    [!] Son Güncelleme: 45 gün önce
                    [!] Durum: 12 Kritik Güncelleme Bekliyor
                    
                    PS C:\> Feature_Audit --check
                    [+] Telnet Client: Etkin/Yüklü (Güvenlik Riski)
                    [+] Lock Screen Timeout: Yapılandırılmamış (Süresiz)
                    
                    

                    DENETİM SONUÇ ÖZETİ:
                    - KRİTİK: BitLocker kapalı, veri bütünlüğü riski altında.
                    - ZAFİYET: ogrenci01 hesabı yönetici grubunda tanımlı.
                    - YAMA YÖNETİMİ: 45 gündür güncellenmemiş sistem.
                    - SIKILAŞTIRMA: Gereksiz servisler (Spooler/Telnet) ve ekran kilidi eksikliği.

İnceleme sonucunda beş bulgu tespit edilmiştir. BitLocker etkin değildir ve çıktı Protection Off göstermektedir. Windows güncelleme tarihi 45 gün öncesine aittir ve 12 kritik güncelleme beklemektedir. Yönetici grubunda standart kullanıcı hesabı olan ogrenci01 de bulunmaktadır. Print Spooler servisi aktiftir; Telnet Client özelliği ise sistemde etkin/yüklü durumdadır. Bu cihaz için bu bileşenlere ihtiyaç olmadığı değerlendirilmektedir. Ekran kilidi süresi yapılandırılmamıştır ve sistem otomatik olarak kilitlenmemektedir.

Bu bulgular, sistemin mevcut hâliyle kullanıma verilmemesi gerektiğini gösterir. Beş temel güvenlik bulgusu giderilmeden cihazın teslim edilmesi kurumsal güvenlik politikasıyla çelişir.

Bulgu → Etki → Öneri → Kanıt

Bulgu: Değerlendirilen dizüstü bilgisayarda beş temel güvenlik açığı tespit edilmiştir: BitLocker devre dışıdır, 45 günlük güncelleme açığı ve 12 bekleyen kritik güncelleme bulunmaktadır, standart kullanıcı hesabı Administrators grubundadır, Print Spooler servisi aktiftir; Telnet Client özelliği sistemde etkin/yüklü durumdadır. Bu bileşenler ilgili cihazın kullanım senaryosu için gereksiz görünmektedir., ekran kilidi zaman aşımı yapılandırılmamıştır.

Etki: Disk şifrelemesinin olmaması, cihaz kaybolduğunda veya çalındığında tüm verilerin açıkta kalmasına neden olur. Kritik güncellemeler uygulanmadığı için sistem bilinen güvenlik açıklarına maruz durumdadır. Standart kullanıcı hesabının yönetici yetkisine sahip olması en az ayrıcalık ilkesini ihlal eder. Gereksiz servisler saldırı yüzeyini genişletir. Ekran kilidi olmaması fiziksel erişim riskini artırır.

Öneri: BitLocker etkinleştirilmeli ve kurtarma anahtarı kurumun güvenli deposuna kaydedilmelidir. Bekleyen 12 kritik güncelleme derhal uygulanmalıdır. ogrenci01 hesabı Administrators grubundan çıkarılmalıdır. Print Spooler durdurulup devre dışı bırakılır; Telnet Client özelliği kaldırılır/devre dışı bırakılır. 10 dakikalık ekran kilidi süresi yapılandırılmalıdır. Tüm önlemler tamamlandıktan sonra sistem yeniden değerlendirilerek teslim edilmelidir.

Kanıt: manage-bde -status C: çıktısı, Windows Update durumu ekran görüntüsü, net localgroup administrators çıktısı, çalışan servisler listesi ve ekran kilidi ayarları ekran görüntüsü tarih damgasıyla saklanmalıdır. İncelemeyi gerçekleştiren kişinin adı ve inceleme tarihi belgeye eklenmelidir.

Kendini Değerlendir — İşletim Sistemi Sertleştirme

Terimler Sözlüğü

Bu Modülde Kazanılan Yetkinlikler

• Bu modülde hardening kavramını ve neden gerekli olduğunu öğrendik. İşletim sistemlerinin varsayılan olarak çoğu zaman kullanılabilirlik odaklı yapılandırıldığını, bu nedenle ek güvenlik adımlarının önemli olduğunu kavradık.
• Varsayılan yapılandırmaların taşıdığı riskleri ele aldık. Varsayılan parolalar, gereksiz servisler, aşırı izinler ve devre dışı güvenlik özellikleri gibi unsurların saldırı yüzeyini nasıl genişletebileceğini gördük.
• Minimum ihtiyaç ilkesinin sistem yapılandırmasına nasıl uygulanacağını öğrendik. Yalnızca gerçekten gerekli servisleri, özellikleri ve portları açık tutmanın saldırı yüzeyini sistematik biçimde azalttığını kavradık.
• Temel güvenlik checklist mantığını inceledik. Hesap ve yetki, güncelleme, servis ve port, şifreleme, fiziksel güvenlik, loglama ve yazılım başlıklarını kapsayan bütünleşik bir denetim yaklaşımı geliştirdik.
• Gereksiz uygulamaların ve başlangıç programlarının kaldırılmasının hem güvenlik hem de performans açısından fayda sağladığını gördük. Başlangıç listesinin aynı zamanda zararlı yazılım kalıcılığını fark etmek için önemli bir kontrol alanı olduğunu öğrendik.
• Ekran kilidi ve oturum zaman aşımının fiziksel ve uzak erişim güvenliğindeki rolünü değerlendirdik. Hızlı kilitleme kısayollarını alışkanlık hâline getirmenin basit ama etkili bir güvenlik pratiği olduğunu kavradık.
• BitLocker, LUKS ve FileVault gibi disk şifreleme çözümleri ile Secure Boot ve başlangıç güveni zincirinin fiziksel güvenlik ve sistem bütünlüğü açısından nasıl bir koruma katmanı oluşturduğunu gördük.
• Düzenli bakım rutininin hardening'i canlı tutan unsur olduğunu öğrendik. Aylık, üç aylık ve yıllık kontrollerle sürdürülebilir bir güvenlik disiplini oluşturmanın önemini kavradık.
• Güvenli yazılım kullanımı, hesap güvenliğini sürdürme ve basit olaylarda ilk tepki farkındalığını kalıcı alışkanlıklar olarak benimsemenin önemini değerlendirdik.
• "Emin değilseniz dokunmayın, bildirin." ilkesinin güvenlik olaylarında kanıtı koruma açısından neden kritik olduğunu öğrendik.
• Bu modülle birlikte sekiz modülden oluşan temel işletim sistemi güvenliği eğitimini tamamladık. İşletim sistemi mantığından başlayarak hesap güvenliği, dosya sistemi, güncelleme yönetimi, zararlı yazılım koruması, ağ güvenliği, loglama ve izleme ile sertleştirme katmanlarını bütünlüklü bir güvenlik perspektifiyle ele almış olduk.