Allah’ın Rahmeti Ve Bereketi Üzerinize Olsun
Selamun aleyküm dostlarım. Bu makalemizde Linux üzerinde kimlik doğrulama, çalışma zamanı ve sistem loglarını inceleyeceğiz ve Loglarla çalışırken kullanılan komutları ve karşılaşılabilecek sorunları öğreneceğiz Allah’ın izniyle.
Metin Logları İle Çalışmak
Log Formatı
Yaygın bir inanışın aksine, Linux tabanlı sistemler zararlı yazılımlara karşı bağışık değildir. Dahası, Linux’u hedef alan saldırılar giderek artan bir sorun haline gelmektedir. Bu nedenle bir SOC analisti olarak sık sık Linux uyarılarını incelemeniz gerekecek ve bunun için loglama sisteminin nasıl çalıştığını anlamanız önemlidir. Şimdi bazı noktaları netleştirelim ve devam edelim:
Windows’un aksine, Linux çoğu olayı düz metin dosyalarına kaydeder. Bu da, Event Viewer gibi özel araçlara ihtiyaç duymadan logları herhangi bir metin editörüyle okuyabileceğiniz anlamına gelir. Öte yandan, varsayılan Linux logları daha az yapılandırılmıştır; çünkü olay kodları ve katı log formatlama kuralları bulunmaz.
Çoğu Linux logu /var/log klasöründe yer alır. Bu yüzden, farklı sistem olaylarının bir araya getirildiği bir akış olan /var/log/syslog dosyasını inceleyerek yolculuğumuza başlayalım.
Logları Filtreleme
Genel olarak dostlarım linux dağılımın syslog dosyasını okuduğunuzda binlerce olay göreceksiniz, ancak bunların yalnızca küçük bir kısmı SOC açısından faydalıdır. Bu nedenle logları filtrelemeniz ve aramanızı mümkün olduğunca daraltmanız gerekir.
Örneğin, "grep" komutunu kullanarak "CRON" anahtar kelimesine göre filtreleme yapabilir ve sadece cronjob loglarını görüntüleyebilirsiniz dostlarım:
Logları Keşfetme
Son olarak, tüm kullanıcı girişlerini araştırmak istediğinizi ancak bunları nerede bulacağınızı bilmediğinizi varsayalım. Linux sistem logları /var/log/ klasöründe düz metin olarak saklanır. Bu nedenle, bu dizindeki tüm log dosyalarında "login", "auth" veya "session" gibi ilgili anahtar kelimeleri grep komutuyla arayarak sonuçları daraltabilir ve sonraki aramalarınızı daha hedefli hale getirebilirsiniz dostlarım.
Loglama ile İlgili Dikkat Edilmesi Gerekenler
Windows’un aksine, Linux log formatını, ayrıntı seviyesini (verbosity) ve saklama konumunu kolayca değiştirmenize olanak tanır. Yüzlerce farklı Linux dağıtımının bulunması ve her birinin loglama yapısını kendine özgü şekilde özelleştirebilmesi nedeniyle, bu bölümde gördüğünüz logların sizin sisteminizde farklı görünebileceğini veya hiç bulunmayabileceğini göz önünde bulundurmalısınız dostlarım.
Kimlik Doğrulama Logları
İzlemek isteyeceğiniz ilk ve çoğu zaman en faydalı log dosyası /var/log/auth.log’dur (RHEL tabanlı sistemlerde /var/log/secure). Her ne kadar adı yalnızca kimlik doğrulama olaylarını içerdiğini düşündürse de, kullanıcı yönetimi olaylarını, çalıştırılan sudo komutlarını ve çok daha fazlasını da barındırabilir. Şimdi log dosyasının formatıyla başlayalım:
Giriş ve Çıkış Olayları
Kullanıcılar bir Linux makinesine farklı şekillerde kimlik doğrulaması yapabilir: yerel olarak, SSH üzerinden, "sudo" veya "su" komutlarını kullanarak ya da bir cron job çalıştırmak için otomatik olarak. Her başarılı giriş (logon) ve çıkış (logoff) işlemi kaydedilir. Bu kayıtları görmek için "session opened" veya "session closed" anahtar kelimelerini içeren olayları filtreleyebilirsiniz:
Sistem loglarına ek olarak, SSH servisi (daemon) başarılı ve başarısız SSH girişlerinin kendi kayıtlarını da tutar. Bu loglar aynı auth.log dosyasına yazılır, ancak formatları biraz farklıdır. Şimdi iki başarısız ve bir başarılı SSH girişine ait örneğe bakalım:
Diğer (Çeşitli) Olaylar
Aynı log dosyasını kullanıcı yönetimi olaylarını tespit etmek için de kullanabilirsiniz. Temel Linux komutlarını biliyorsanız bu oldukça kolaydır: Örneğin, yeni kullanıcı eklemek için kullanılan useradd komutunu biliyorsanız, kullanıcı oluşturma olaylarını görmek için "useradd" anahtar kelimesini arayabilirsiniz.
Aşağıda loglarda görebileceğiniz örneklere yer verilmiştir: parola değişikliği, kullanıcı silme ve ardından yetkili (privileged) kullanıcı oluşturma.
Son olarak, sistem yapılandırmasına ve yüklü paketlere bağlı olarak ilginç veya beklenmedik olaylarla karşılaşabilirsiniz. Örneğin, sudo ile çalıştırılan komutları görebilirsiniz; bu da kötü niyetli faaliyetleri takip etmenize yardımcı olabilir.
Aşağıdaki örnekte, "ubuntu" kullanıcısının sudo kullanarak EDR’yi durdurduğu, güvenlik duvarı durumunu kontrol ettiği ve son olarak "sudo su" komutuyla root erişimi elde ettiği görülmektedir:
Yaygın Linux Logları
Genel Sistem Logları
Linux, /var/log dizinine dağılmış birçok farklı olayı kaydeder: kernel logları, ağ değişiklikleri, servis veya cron çalışmaları, paket kurulumu ve daha pek çok şey. İçerikleri ve formatları kullanılan işletim sistemine göre değişiklik gösterebilir. En yaygın log dosyaları şunlardır:
Uygulamaya Özel Loglar
SOC çalışmalarında belirli bir uygulamayı da izleyebilirsiniz ve bunu etkili şekilde yapmak için o uygulamanın loglarını kullanmanız gerekir. Örneğin, hangi sorguların çalıştırıldığını görmek için veritabanı loglarını analiz edebilir, phishing saldırılarını incelemek için mail loglarına bakabilir, anormallikleri tespit etmek için container loglarını inceleyebilir ve hangi sayfaların kim tarafından ve ne zaman açıldığını görmek için web sunucu loglarını kullanabilirsiniz.
Bu logları ilerleyen makalelerimizde daha detaylı inceleyeceğiz Allah’ın izniyle. Genel bir fikir vermek gerekirse, aşağıda tipik bir Nginx web sunucusu logundan bir örnek bulunmaktadır:
Bash Geçmişi
Bir diğer değerli log kaynağı Bash geçmişidir (Bash history). Bu özellik, Enter tuşuna bastıktan sonra çalıştırdığınız her komutu kaydeder. Varsayılan olarak komutlar önce oturum süresince bellekte tutulur ve daha sonra oturumdan çıkış yaptığınızda her kullanıcıya ait ~/.bash_history dosyasına yazılır.
Geçmiş oturumlarda kullanılan komutları incelemek için ~/.bash_history dosyasını açabilirsiniz veya hem mevcut hem de önceki oturumlardaki komutları görmek için history komutunu kullanabilirsiniz:
Bash history dosyası önemli bir log kaynağı gibi görünse de, SOC ekipleri tarafından günlük rutinlerinde nadiren kullanılır. Bunun nedeni, etkileşimsiz (non-interactive) komutları kaydetmemesidir (örneğin işletim sistemi tarafından başlatılan işlemler, cron job’lar veya web sunucuları tarafından çalıştırılan komutlar gibi). Ayrıca başka bazı sınırlamaları da vardır. Yapılandırma ile (opens in new tab) daha faydalı hale getirilebilse de, yine de bilmeniz gereken birkaç önemli sorun bulunmaktadır:
Çalışma Süresi İzleme
Çalışma Zamanı (Runtime) İzleme
Şu ana kadar çeşitli Linux log kaynaklarını incelediniz, ancak hiçbiri “Ali bugün hangi programları çalıştırdı?” veya “Ev dizinimi kim ve ne zaman sildi?” gibi soruları güvenilir bir şekilde cevaplayamaz. Bunun nedeni, varsayılan olarak Linux’un süreç oluşturma, dosya değişiklikleri veya ağ ile ilgili olayları (topluca runtime olayları olarak bilinir) loglamamasıdır.
İlginç bir şekilde Windows da aynı sınırlamaya sahiptir; bu yüzden SOC İçin Windows Günlük Kaydı Makalelerimizde Sysmon adlı ek bir araç kullanmak zorunda kalmıştık. Linux’ta da benzer bir yaklaşım izleyeceğiz.
Sistem Çağrıları (System Calls)
Devam etmeden önce, birçok farklı konuyu anlamanıza yardımcı olabilecek temel bir işletim sistemi kavramını inceleyelim: sistem çağrıları (system calls). Kısaca, bir dosya açmak, bir süreç (process) oluşturmak, kameraya erişmek veya işletim sisteminden herhangi bir hizmet istemek istediğinizde belirli bir sistem çağrısı yaparsınız.
Linux’ta 300’den fazla (opens in new tab) sistem çağrısı bulunmaktadır. Örneğin execve, bir programı çalıştırmak için kullanılan sistem çağrılarından biridir. Aşağıda bunun nasıl çalıştığını gösteren yüksek seviyeli bir akış diyagramı yer almaktadır:
Sistem çağrılarını neden bilmeniz gerekir? Çünkü tüm modern EDR’ler ve loglama araçları bunlara dayanır; temel sistem çağrılarını izler ve detayları insan tarafından okunabilir bir formatta kaydederler.
Saldırganların sistem çağrılarını atlatmasının neredeyse hiçbir yolu olmadığı için, yapmanız gereken tek şey hangi sistem çağrılarını loglamak ve izlemek istediğinizi seçmektir.
Auditd’i Kullanma
Audit Daemon
Auditd (Audit Daemon), SOC ekipleri tarafından çalışma zamanı izleme (runtime monitoring) için sıkça kullanılan yerleşik bir denetim (auditing) çözümüdür. Öncelikle kurallardan başlayalım: /etc/audit/rules.d/ dizininde yer alan bu talimatlar, hangi sistem çağrılarının izleneceğini ve hangi filtrelerin uygulanacağını tanımlar.
Her süreç, dosya ve ağ olayını izlemek kısa sürede her gün gigabaytlarca log üretilmesine neden olabilir. Ancak daha fazla log her zaman daha iyi tespit anlamına gelmez; çünkü bir terabaytlık gürültü içinde gizlenmiş bir saldırı yine görünmez kalır.
Bu yüzden SOC ekipleri genellikle en yüksek riskli olaylara odaklanır ve dengeli kural setleri oluşturur; örneğin bu (opens in new tab) veya yukarıda gördüğünüz örnek gibi dostlarım.
Auditd Kullanımı
Oluşturulan logları gerçek zamanlı olarak /var/log/audit/audit.log dosyasında görüntüleyebilirsiniz, ancak çıktıyı daha okunabilir hale getirdiği ve filtreleme seçenekleri sunduğu için ausearch komutunu kullanmak daha kolaydır.
Yukarıdaki yer alan kurallara dayanarak, "proc_wget" anahtarına uyan olayları arayarak bir örnek inceleyelim:
Yukarıdaki terminal, tek bir “wget” komutuna ait bir logu göstermektedir. Burada auditd olayı dört satıra böler: PROCTITLE işlem komut satırını gösterir, CWD mevcut çalışma dizinini (current working directory) bildirir ve kalan iki satır sistem çağrısı detaylarını içerir. Örneğin:
Şimdi "file_sshconf" anahtarına eşleşen dosya olaylarına bakalım. Aşağıdaki terminal çıktısında görebileceğiniz gibi, auditd /etc/ssh/sshd_config dosyasında yapılan değişikliği "nano" komutu üzerinden takip etmiştir.
SOC ekipleri genellikle kritik dosya ve dizinlerde yapılan değişiklikleri izlemek için kurallar oluşturur (örneğin SSH yapılandırma dosyaları, cron job tanımları veya sistem ayarları).
Auditd Alternatifleri
auditd’nin rahatsız edici bir yönünü fark etmiş olabilirsiniz: ayrıntılı (verbose) loglama sağlasa da çıktıyı okumak ve SIEM’e aktarmak oldukça zordur. Bu yüzden birçok SOC ekibi alternatif runtime loglama çözümlerine yönelir. Örneğin:
Okuduğunuz için teşekkür ederim
CW-Ommah
Bug Researchers Tim Sundu...
Selamun aleyküm dostlarım. Bu makalemizde Linux üzerinde kimlik doğrulama, çalışma zamanı ve sistem loglarını inceleyeceğiz ve Loglarla çalışırken kullanılan komutları ve karşılaşılabilecek sorunları öğreneceğiz Allah’ın izniyle.
Metin Logları İle Çalışmak
Log Formatı
Yaygın bir inanışın aksine, Linux tabanlı sistemler zararlı yazılımlara karşı bağışık değildir. Dahası, Linux’u hedef alan saldırılar giderek artan bir sorun haline gelmektedir. Bu nedenle bir SOC analisti olarak sık sık Linux uyarılarını incelemeniz gerekecek ve bunun için loglama sisteminin nasıl çalıştığını anlamanız önemlidir. Şimdi bazı noktaları netleştirelim ve devam edelim:
- Bu bölümde “Linux” ifadesiyle Debian, Ubuntu, CentOS veya RHEL gibi Linux dağıtımları kastedilmektedir.
- Bu bölüm, grafik arayüzü (GUI) olmayan Linux sunucularına odaklanır ve masaüstü loglamayı kapsamaz.
Windows’un aksine, Linux çoğu olayı düz metin dosyalarına kaydeder. Bu da, Event Viewer gibi özel araçlara ihtiyaç duymadan logları herhangi bir metin editörüyle okuyabileceğiniz anlamına gelir. Öte yandan, varsayılan Linux logları daha az yapılandırılmıştır; çünkü olay kodları ve katı log formatlama kuralları bulunmaz.
Çoğu Linux logu /var/log klasöründe yer alır. Bu yüzden, farklı sistem olaylarının bir araya getirildiği bir akış olan /var/log/syslog dosyasını inceleyerek yolculuğumuza başlayalım.
Kod:
root@CW-ommah:~$ cat /var/log/syslog | head
[...]
2025-08-13T13:57:49.388941+00:00 thm-vm systemd-timesyncd[268]: Initial clock synchronization to Wed 2025-08-13 13:57:49.387835 UTC.
2025-08-13T13:59:39.970029+00:00 thm-vm systemd[888]: Starting dbus.socket - D-Bus User Message Bus Socket...
2025-08-13T14:02:22.606216+00:00 thm-vm dbus-daemon[564]: [system] Successfully activated service 'org.freedesktop.timedate1'
2025-08-13T14:05:01.999677+00:00 thm-vm CRON[1027]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
[...]Logları Filtreleme
Genel olarak dostlarım linux dağılımın syslog dosyasını okuduğunuzda binlerce olay göreceksiniz, ancak bunların yalnızca küçük bir kısmı SOC açısından faydalıdır. Bu nedenle logları filtrelemeniz ve aramanızı mümkün olduğunca daraltmanız gerekir.
Örneğin, "grep" komutunu kullanarak "CRON" anahtar kelimesine göre filtreleme yapabilir ve sadece cronjob loglarını görüntüleyebilirsiniz dostlarım:
Kod:
# Or "grep -v CRON" to exclude "CRON" from results
root@thm-vm:~$ cat /var/log/syslog | grep CRON
2025-08-13T14:17:01.025846+00:00 thm-vm CRON[1042]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
2025-08-13T14:25:01.043238+00:00 thm-vm CRON[1046]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
2025-08-13T14:30:01.014532+00:00 thm-vm CRON[1048]: (root) CMD (date > mycrondebug.log)Logları Keşfetme
Son olarak, tüm kullanıcı girişlerini araştırmak istediğinizi ancak bunları nerede bulacağınızı bilmediğinizi varsayalım. Linux sistem logları /var/log/ klasöründe düz metin olarak saklanır. Bu nedenle, bu dizindeki tüm log dosyalarında "login", "auth" veya "session" gibi ilgili anahtar kelimeleri grep komutuyla arayarak sonuçları daraltabilir ve sonraki aramalarınızı daha hedefli hale getirebilirsiniz dostlarım.
Kod:
# Sisteminizde hangi günlüklerin kaydedildiğini listeleyin (/var/log klasörü)
root@CW-ommah:~$ ls -l /var/log
drwxr-xr-x 2 root root 4096 Aug 12 16:41 apt
drwxr-x--- 2 root adm 4096 Aug 12 12:40 audit
-rw-r----- 1 syslog adm 45399 Aug 13 15:05 auth.log
-rw-r--r-- 1 root root 1361277 Aug 12 16:41 dpkg.log
drwxr-sr-x+ 3 root systemd-journal 4096 Oct 22 2024 journal
-rw-r----- 1 syslog adm 214772 Aug 13 13:57 kern.log
-rw-r----- 1 syslog adm 315798 Aug 13 15:05 syslog
[...]
# Tüm günlük dosyalarında (/var/log) olası oturum açma girişlerini ara
root@CW-ommah:~$ grep -R -E "auth|login|session" /var/log
[...]Loglama ile İlgili Dikkat Edilmesi Gerekenler
Windows’un aksine, Linux log formatını, ayrıntı seviyesini (verbosity) ve saklama konumunu kolayca değiştirmenize olanak tanır. Yüzlerce farklı Linux dağıtımının bulunması ve her birinin loglama yapısını kendine özgü şekilde özelleştirebilmesi nedeniyle, bu bölümde gördüğünüz logların sizin sisteminizde farklı görünebileceğini veya hiç bulunmayabileceğini göz önünde bulundurmalısınız dostlarım.
Kimlik Doğrulama Logları
İzlemek isteyeceğiniz ilk ve çoğu zaman en faydalı log dosyası /var/log/auth.log’dur (RHEL tabanlı sistemlerde /var/log/secure). Her ne kadar adı yalnızca kimlik doğrulama olaylarını içerdiğini düşündürse de, kullanıcı yönetimi olaylarını, çalıştırılan sudo komutlarını ve çok daha fazlasını da barındırabilir. Şimdi log dosyasının formatıyla başlayalım:
Giriş ve Çıkış Olayları
Kullanıcılar bir Linux makinesine farklı şekillerde kimlik doğrulaması yapabilir: yerel olarak, SSH üzerinden, "sudo" veya "su" komutlarını kullanarak ya da bir cron job çalıştırmak için otomatik olarak. Her başarılı giriş (logon) ve çıkış (logoff) işlemi kaydedilir. Bu kayıtları görmek için "session opened" veya "session closed" anahtar kelimelerini içeren olayları filtreleyebilirsiniz:
Kod:
root@CW-ommah:~$ cat /var/log/auth.log | grep -E 'session opened|session closed'
# Ali’nin yerel, klavye üzerinden oturum açma ve kapatma (login:session)
2025-08-02T16:04:43 thm-vm login[1138]: pam_unix(login:session): session opened for user Ali(uid=1001) by Ali(uid=0)
2025-08-02T19:23:08 thm-vm login[1138]: pam_unix(login:session): session closed for user Ali
# Hüseyin'nin uzaktan oturum açma örnekleri (SSH ve ardından SMB yoluyla)
2025-08-04T09:09:06 thm-vm sshd[839]: pam_unix(sshd:session): session opened for user Hüseyin(uid=1002) by Hüseyin(uid=0)
2025-08-04T12:46:13 thm-vm smbd[1795]: pam_unix(samba:session): session opened for user Hüseyin(uid=1002) by Hüseyin(uid=0)Sistem loglarına ek olarak, SSH servisi (daemon) başarılı ve başarısız SSH girişlerinin kendi kayıtlarını da tutar. Bu loglar aynı auth.log dosyasına yazılır, ancak formatları biraz farklıdır. Şimdi iki başarısız ve bir başarılı SSH girişine ait örneğe bakalım:
Kod:
root@CW-ommah:~$ cat /var/log/auth.log | grep "sshd" | grep -E 'Accepted|Failed'
# Yaygın SSH günlük biçimi: <is-successful> <auth-method> for <user> from <ip>
2025-08-07T11:21:25 thm-vm sshd[3139]: Failed password for root from 222.124.17.227 port 50293 ssh2
2025-08-07T14:17:40 thm-vm sshd[3139]: Failed password for admin from 138.204.127.54 port 52670 ssh2
2025-08-09T20:30:51 thm-vm sshd[1690]: Accepted publickey for bob from 10.19.92.18 port 55050 ssh2: <key>Diğer (Çeşitli) Olaylar
Aynı log dosyasını kullanıcı yönetimi olaylarını tespit etmek için de kullanabilirsiniz. Temel Linux komutlarını biliyorsanız bu oldukça kolaydır: Örneğin, yeni kullanıcı eklemek için kullanılan useradd komutunu biliyorsanız, kullanıcı oluşturma olaylarını görmek için "useradd" anahtar kelimesini arayabilirsiniz.
Aşağıda loglarda görebileceğiniz örneklere yer verilmiştir: parola değişikliği, kullanıcı silme ve ardından yetkili (privileged) kullanıcı oluşturma.
Kod:
root@CW-ommah:~$ cat /var/log/auth.log | grep -E '(passwd|useradd|usermod|userdel)\['
2023-02-01T11:09:55 thm-vm passwd[644]: password for 'ubuntu' changed by 'root'
2025-08-07T22:11:11 thm-vm userdel[1887]: delete user 'oldbackdoor'
2025-08-07T22:11:29 thm-vm useradd[1878]: new user: name=backdoor, UID=1002, GID=1002, shell=/bin/sh
2025-08-07T22:11:54 thm-vm usermod[1906]: add 'backdoor' to group 'sudo'
2025-08-07T22:11:54 thm-vm usermod[1906]: add 'backdoor' to shadow group 'sudo'Son olarak, sistem yapılandırmasına ve yüklü paketlere bağlı olarak ilginç veya beklenmedik olaylarla karşılaşabilirsiniz. Örneğin, sudo ile çalıştırılan komutları görebilirsiniz; bu da kötü niyetli faaliyetleri takip etmenize yardımcı olabilir.
Aşağıdaki örnekte, "ubuntu" kullanıcısının sudo kullanarak EDR’yi durdurduğu, güvenlik duvarı durumunu kontrol ettiği ve son olarak "sudo su" komutuyla root erişimi elde ettiği görülmektedir:
Kod:
root@Cw-ommah:~$ cat /var/log/auth.log | grep -E 'COMMAND='
2025-08-07T11:21:49 thm-vm sudo: ubuntu : TTY=pts/0 ; [...] COMMAND=/usr/bin/systemctl stop edr
2025-08-07T11:23:18 thm-vm sudo: ubuntu : TTY=pts/0 ; [...] COMMAND=/usr/bin/ufw status numbered
2025-08-07T11:23:33 thm-vm sudo: ubuntu : TTY=pts/0 ; [...] COMMAND=/usr/bin/suYaygın Linux Logları
Genel Sistem Logları
Linux, /var/log dizinine dağılmış birçok farklı olayı kaydeder: kernel logları, ağ değişiklikleri, servis veya cron çalışmaları, paket kurulumu ve daha pek çok şey. İçerikleri ve formatları kullanılan işletim sistemine göre değişiklik gösterebilir. En yaygın log dosyaları şunlardır:
- /var/log/kern.log: Kernel mesajları ve hataları; daha ileri seviye incelemeler için faydalıdır
- /var/log/syslog (veya /var/log/messages): Çeşitli Linux olaylarının bir araya getirildiği birleşik bir akış
- /var/log/dpkg.log (veya /var/log/apt): Debian tabanlı sistemlerde paket yöneticisi logları
- /var/log/dnf.log (veya /var/log/yum.log): RHEL tabanlı sistemlerde paket yöneticisi logları
Uygulamaya Özel Loglar
SOC çalışmalarında belirli bir uygulamayı da izleyebilirsiniz ve bunu etkili şekilde yapmak için o uygulamanın loglarını kullanmanız gerekir. Örneğin, hangi sorguların çalıştırıldığını görmek için veritabanı loglarını analiz edebilir, phishing saldırılarını incelemek için mail loglarına bakabilir, anormallikleri tespit etmek için container loglarını inceleyebilir ve hangi sayfaların kim tarafından ve ne zaman açıldığını görmek için web sunucu loglarını kullanabilirsiniz.
Bu logları ilerleyen makalelerimizde daha detaylı inceleyeceğiz Allah’ın izniyle. Genel bir fikir vermek gerekirse, aşağıda tipik bir Nginx web sunucusu logundan bir örnek bulunmaktadır:
Kod:
root@CW-ommah:~$ cat /var/log/nginx/access.log
# Her bir günlük satırı, web sunucusuna yapılan bir web isteğine karşılık gelir
10.0.1.12 - - [11/08/2025:14:32:10 +0000] "GET / HTTP/1.1" 200 3022
10.0.1.12 - - [11/08/2025:14:32:14 +0000] "GET /login HTTP/1.1" 200 1056
10.0.1.12 - - [11/08/2025:14:33:09 +0000] "POST /login HTTP/1.1" 302 112
10.0.4.99 - - [11/08/2025:17:11:20 +0000] "GET /images/logo.png HTTP/1.1" 200 5432
10.0.5.21 - - [11/08/2025:17:56:23 +0000] "GET /admin HTTP/1.1" 403 104Bash Geçmişi
Bir diğer değerli log kaynağı Bash geçmişidir (Bash history). Bu özellik, Enter tuşuna bastıktan sonra çalıştırdığınız her komutu kaydeder. Varsayılan olarak komutlar önce oturum süresince bellekte tutulur ve daha sonra oturumdan çıkış yaptığınızda her kullanıcıya ait ~/.bash_history dosyasına yazılır.
Geçmiş oturumlarda kullanılan komutları incelemek için ~/.bash_history dosyasını açabilirsiniz veya hem mevcut hem de önceki oturumlardaki komutları görmek için history komutunu kullanabilirsiniz:
Kod:
ubuntu@thm-vm:~$ cat /home/ubuntu/.bash_history
echo "hello" > world.txt
nano /etc/ssh/sshd_config
sudo su
ubuntu@thm-vm:~$ history
1 echo "hello" > world.txt
2 nano /etc/ssh/sshd_config
3 sudo su
4 ls -la /home/ubuntu
5 cat /home/ubuntu/.bash_history
6 history
Kod:
# Saldırganlar, eylemlerinin günlüğe kaydedilmesini önlemek için komutun başına basitçe bir boşluk ekleyebilirler
ubuntu@CW-ommah:~$ echo "Beni asla Loglarda göremezsin!"
# Saldırganlar, komutlarını bir komut dosyasına yapıştırarak bunları Bash geçmişinden gizleyebilirler
ubuntu@CW-ommah:~$ nano legit.sh && ./legit.sh
# Saldırganlar, Bash gibi geçmişi kaydetmeyen /bin/sh gibi diğer kabukları kullanabilir
ubuntu@CW-ommah:~$ sh
$ echo "Artık Bash tarafından izlenmiyorum!"Çalışma Süresi İzleme
Çalışma Zamanı (Runtime) İzleme
Şu ana kadar çeşitli Linux log kaynaklarını incelediniz, ancak hiçbiri “Ali bugün hangi programları çalıştırdı?” veya “Ev dizinimi kim ve ne zaman sildi?” gibi soruları güvenilir bir şekilde cevaplayamaz. Bunun nedeni, varsayılan olarak Linux’un süreç oluşturma, dosya değişiklikleri veya ağ ile ilgili olayları (topluca runtime olayları olarak bilinir) loglamamasıdır.
İlginç bir şekilde Windows da aynı sınırlamaya sahiptir; bu yüzden SOC İçin Windows Günlük Kaydı Makalelerimizde Sysmon adlı ek bir araç kullanmak zorunda kalmıştık. Linux’ta da benzer bir yaklaşım izleyeceğiz.
Sistem Çağrıları (System Calls)
Devam etmeden önce, birçok farklı konuyu anlamanıza yardımcı olabilecek temel bir işletim sistemi kavramını inceleyelim: sistem çağrıları (system calls). Kısaca, bir dosya açmak, bir süreç (process) oluşturmak, kameraya erişmek veya işletim sisteminden herhangi bir hizmet istemek istediğinizde belirli bir sistem çağrısı yaparsınız.
Linux’ta 300’den fazla (opens in new tab) sistem çağrısı bulunmaktadır. Örneğin execve, bir programı çalıştırmak için kullanılan sistem çağrılarından biridir. Aşağıda bunun nasıl çalıştığını gösteren yüksek seviyeli bir akış diyagramı yer almaktadır:
Sistem çağrılarını neden bilmeniz gerekir? Çünkü tüm modern EDR’ler ve loglama araçları bunlara dayanır; temel sistem çağrılarını izler ve detayları insan tarafından okunabilir bir formatta kaydederler.
Saldırganların sistem çağrılarını atlatmasının neredeyse hiçbir yolu olmadığı için, yapmanız gereken tek şey hangi sistem çağrılarını loglamak ve izlemek istediğinizi seçmektir.
Auditd’i Kullanma
Audit Daemon
Auditd (Audit Daemon), SOC ekipleri tarafından çalışma zamanı izleme (runtime monitoring) için sıkça kullanılan yerleşik bir denetim (auditing) çözümüdür. Öncelikle kurallardan başlayalım: /etc/audit/rules.d/ dizininde yer alan bu talimatlar, hangi sistem çağrılarının izleneceğini ve hangi filtrelerin uygulanacağını tanımlar.
Bu yüzden SOC ekipleri genellikle en yüksek riskli olaylara odaklanır ve dengeli kural setleri oluşturur; örneğin bu (opens in new tab) veya yukarıda gördüğünüz örnek gibi dostlarım.
Auditd Kullanımı
Oluşturulan logları gerçek zamanlı olarak /var/log/audit/audit.log dosyasında görüntüleyebilirsiniz, ancak çıktıyı daha okunabilir hale getirdiği ve filtreleme seçenekleri sunduğu için ausearch komutunu kullanmak daha kolaydır.
Yukarıdaki yer alan kurallara dayanarak, "proc_wget" anahtarına uyan olayları arayarak bir örnek inceleyelim:
Kod:
root@CW-ommah:~$ ausearch -i -k proc_wget
----
type=PROCTITLE msg=audit(08/12/25 12:48:19.093:2219) : proctitle=wget https://files.tryhackme.thm/report.zip
type=CWD msg=audit(08/12/25 12:48:19.093:2219) : cwd=/root
type=EXECVE msg=audit(08/12/25 12:48:19.093:2219) : argc=2 a0=wget a1=https://files.tryhackme.thm/report.zip
type=SYSCALL msg=audit(08/12/25 12:48:19.093:2219) : arch=x86_64 syscall=execve [...] ppid=3752 pid=3888 auid=ubuntu uid=root tty=pts1 exe=/usr/bin/wget key=proc_wgetYukarıdaki terminal, tek bir “wget” komutuna ait bir logu göstermektedir. Burada auditd olayı dört satıra böler: PROCTITLE işlem komut satırını gösterir, CWD mevcut çalışma dizinini (current working directory) bildirir ve kalan iki satır sistem çağrısı detaylarını içerir. Örneğin:
- pid=3888, ppid=3752: Süreç ID’si ve ebeveyn süreç ID’si. Olayları birbirine bağlamak ve süreç ağacı (process tree) oluşturmak için kullanışlıdır
- auid=ubuntu: Audit kullanıcısı. Yerel (klavye) veya uzaktan (SSH) giriş yapılmış olsun, oturum açarken kullanılan orijinal hesap
- uid=root: Komutu çalıştıran kullanıcı. sudo veya su ile kullanıcı değiştirildiyse bu alan auid’den farklı olabilir
- tty=pts1: Oturum tanımlayıcısı. Aynı Linux sunucusunda birden fazla kişi çalıştığında olayları ayırt etmeye yardımcı olur
- exe=/usr/bin/wget: Çalıştırılan ikilinin (binary) tam yolu. SOC tespit kuralları oluşturmak için sıklıkla kullanılır
- key=proc_wget: auditd kurallarında mühendisler tarafından belirlenen isteğe bağlı bir etiket. Olayları filtrelemek için faydalıdır
Şimdi "file_sshconf" anahtarına eşleşen dosya olaylarına bakalım. Aşağıdaki terminal çıktısında görebileceğiniz gibi, auditd /etc/ssh/sshd_config dosyasında yapılan değişikliği "nano" komutu üzerinden takip etmiştir.
SOC ekipleri genellikle kritik dosya ve dizinlerde yapılan değişiklikleri izlemek için kurallar oluşturur (örneğin SSH yapılandırma dosyaları, cron job tanımları veya sistem ayarları).
Kod:
root@CW-ommah:~$ ausearch -i -k file_sshconf
----
type=PROCTITLE msg=audit(08/12/25 13:06:47.656:2240) : proctitle=nano /etc/ssh/sshd_config
type=CWD msg=audit(08/12/25 13:06:47.656:2240) : cwd=/
type=PATH msg=audit(08/12/25 13:06:47.656:2240) : item=0 name=/etc/ssh/sshd_config [...]
type=SYSCALL msg=audit(08/12/25 13:06:47.656:2240) : arch=x86_64 syscall=openat [...] ppid=3752 pid=3899 auid=ubuntu uid=root tty=pts1 exe=/usr/bin/nano key=file_sshconfAuditd Alternatifleri
auditd’nin rahatsız edici bir yönünü fark etmiş olabilirsiniz: ayrıntılı (verbose) loglama sağlasa da çıktıyı okumak ve SIEM’e aktarmak oldukça zordur. Bu yüzden birçok SOC ekibi alternatif runtime loglama çözümlerine yönelir. Örneğin:
- Sysmon for Linux (opens in new tab): Zaten Sysmon kullanıyorsanız ve XML formatını seviyorsanız mükemmel bir seçimdir
- Falco (opens in new tab): Modern, açık kaynaklı bir çözüm olup özellikle konteynerleştirilmiş sistemleri izlemek için idealdir
- Osquery (opens in new tab): Çeşitli güvenlik amaçları için geniş şekilde kullanılabilen ilginç bir araçtır
- EDR’ler: Çoğu EDR çözümü, Linux üzerindeki çeşitli runtime olaylarını takip edebilir ve izleyebilir
Okuduğunuz için teşekkür ederimCW-Ommah
Bug Researchers Tim Sundu...
