Pardus'ta Servis Yapılandırma Dosyaları (Systemd)

Modern Pardus sürümleri, Debian tabanlı olduğu için servis yönetiminde systemd kullanmaktadır. Systemd, işletim sistemi açılırken servisleri başlatan, durduran, yeniden başlatan ve servislerin yaşam döngüsünü yöneten temel bileşendir.

Siber güvenlik açısından bakıldığında servis yapılandırma dosyalarını anlamak oldukça önemlidir. Yanlış yapılandırılmış servisler;

• Yetkisiz erişime,

• Ayrıcalık yükseltmeye (Privilege Escalation),

• Kalıcılık (Persistence),

• Bilgi sızdırmaya,

• Servis kesintilerine

neden olabilir.

---

Servis Nedir?

Servis (Service), arka planda çalışan ve kullanıcı oturumu açılmadan görev yapan programlardır.

Örnek servisler

• SSH

• Apache

• Nginx

• MariaDB

• Docker

• CrowdSec

• Samba

Servisler systemd tarafından yönetilir.

---

Systemd Dizin Yapısı

En önemli dizinler

/etc/systemd/
/usr/lib/systemd/
/lib/systemd/
/run/systemd/

Bunların görevleri farklıdır.

---

1. /etc/systemd/

En önemli dizindir.

Yönetici tarafından oluşturulan servisler burada bulunur.

Örnek

/etc/systemd/system/

İçeriği

ssh.service
apache2.service
docker.service

Listeleme

ls /etc/systemd/system

---

2. /usr/lib/systemd/

Dağıtım ile birlikte gelen servis dosyalarıdır.

/usr/lib/systemd/system

Bazı Debian/Pardus sürümlerinde

/lib/systemd/system

aynı görevi görmektedir.

Kontrol

ls /usr/lib/systemd/system

veya

ls /lib/systemd/system

---

3. /run/systemd/

Geçici çalışma dosyalarıdır.

Sistem yeniden başladığında silinir.

---

Service Unit Dosyaları

Servisler

*.service

uzantısına sahiptir.

Örneğin

sshd.service
apache2.service
cron.service
NetworkManager.service

---

Timer Dosyaları

*.timer

Cron yerine kullanılabilir.

Örnek

apt-daily.timer
logrotate.timer

Listeleme

systemctl list-timers

---

Socket Dosyaları

*.socket

Socket activation sağlar.

Örneğin

cups.socket

---

Target Dosyaları

*.target

Runlevel mantığının yerine kullanılır.

Örneğin

multi-user.target
graphical.target
rescue.target

---

Mount Dosyaları

*.mount

Disk bağlama işlemleri

---

Path Dosyaları

*.path

Dosya değişimini izler.

---

Device Dosyaları

*.device

Donanımları temsil eder.

---

Scope Dosyaları

*.scope

Harici süreçleri yönetir.

---

Slice Dosyaları

*.slice

Kaynak yönetimi için kullanılır.

---

Service Dosyasının Yapısı

Bir servis dosyası üç ana bölümden oluşur.

[Unit]
[Service]
[Install]

---

[Unit]

Servisin açıklamasını içerir.

Örnek

[Unit]
Description=Web Server
After=network.target

Parametreler

Description
Documentation
After
Before
Requires
Wants
Conflicts

---

Description

Description=Apache Web Server

---

After

Servis hangi servisten sonra başlasın?

After=network.target

---

Before

Before=apache2.service

---

Requires

Mutlaka çalışması gereken servis.

Requires=mysql.service

---

Wants

Bağımlılık isteğe bağlıdır.

Wants=network-online.target

---

[Service]

Asıl çalışma ayarları buradadır.

Örnek

[Service]
Type=simple
ExecStart=/usr/bin/python3 app.py
Restart=always

---

Type

En yaygın seçenekler

simple
forking
oneshot
notify
idle
exec

---

simple

Varsayılan tiptir.

---

forking

Daemon oluşturan uygulamalar.

Apache

MariaDB

---

oneshot

Bir kez çalışır.

---

notify

Servis hazır olduğunu systemd'ye bildirir.

---

ExecStart

Servisin başlatılacağı komut.

ExecStart=/usr/sbin/apache2

---

ExecStop

ExecStop=/bin/kill $MAINPID

---

ExecReload

ExecReload=/bin/kill -HUP $MAINPID

---

Restart

Restart=no
Restart=always
Restart=on-failure
Restart=on-abnormal

---

RestartSec

RestartSec=5

---

TimeoutStartSec

TimeoutStartSec=30

---

User

Servis hangi kullanıcıyla çalışacak?

User=www-data

---

Group

Group=www-data

---

WorkingDirectory

WorkingDirectory=/opt/app

---

Environment

Environment=PORT=8080

---

EnvironmentFile

EnvironmentFile=/etc/default/app

---

StandardOutput

journal
null
tty

---

StandardError

journal
inherit
null

---

[Install]

Servisin hangi hedefte etkin olacağını belirler.

[Install]
WantedBy=multi-user.target

---

Örnek Servis Dosyası

[Unit]
Description=Python Web API
After=network.target
[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/opt/webapi
ExecStart=/usr/bin/python3 app.py
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target

---

Yeni Servis Oluşturma

sudo nano /etc/systemd/system/demo.service

Dosya kaydedildikten sonra

sudo systemctl daemon-reload

---

Etkinleştirme

sudo systemctl enable demo.service

Başlatma

sudo systemctl start demo.service

Kontrol

sudo systemctl status demo.service

---

daemon-reload Neden Gereklidir?

Yeni servis oluşturulduğunda systemd bunu otomatik okumaz.

Bu yüzden

systemctl daemon-reload

çalıştırılır.

---

Override Yapısı

Dağıtım tarafından sağlanan servis dosyalarını doğrudan değiştirmek önerilmez. Bunun yerine bir override dosyası oluşturulur:

sudo systemctl edit ssh.service

Bu komut aşağıdaki dizinde bir yapılandırma oluşturur:

/etc/systemd/system/ssh.service.d/override.conf

Örnek:

[Service]
Restart=always
RestartSec=10

Bu yöntem, paket güncellemelerinde yapılan özelleştirmelerin korunmasını sağlar.

---

Günlük (Log) İnceleme

Systemd günlükleri journal üzerinde tutulur.

Tüm servis günlüklerini görüntüleme:

journalctl

Belirli bir servis için:

journalctl -u ssh.service

Canlı izleme:

journalctl -u ssh.service -f

Son önyüklemeye ait kayıtlar:

journalctl -b

---

Kullanışlı systemctl Komutları

Komut	Açıklama
systemctl status servis	Servis durumunu gösterir
systemctl start servis	Servisi başlatır
systemctl stop servis	Servisi durdurur
systemctl restart servis	Yeniden başlatır
systemctl reload servis	Yapılandırmayı yeniden yükler
systemctl enable servis	Açılışta otomatik başlatır
systemctl disable servis	Otomatik başlatmayı kapatır
systemctl is-enabled servis	Etkin olup olmadığını gösterir
systemctl list-units --type=service	Çalışan servisleri listeler
systemctl list-unit-files	Tüm unit dosyalarını listeler

---

Siber Güvenlik Açısından Değerlendirme

Servis yapılandırmaları, sistem güvenliğinde kritik rol oynar. Dikkat edilmesi gereken başlıca noktalar şunlardır:

• En az ayrıcalık ilkesi: User=root yerine mümkün olduğunca ayrıcalıksız bir kullanıcı (ör. www-data) kullanın.

• Dosya izinleri: /etc/systemd/system altındaki dosyaların yalnızca yetkili kullanıcılar tarafından değiştirilebildiğinden emin olun.

• Override kullanımı: Paketle gelen .service dosyalarını değiştirmek yerine systemctl edit ile override oluşturun.

• Servis denetimi: Düzenli olarak systemctl list-unit-files ve systemctl list-units çıktıları incelenerek beklenmeyen servisler tespit edilmelidir.

• Kalıcılık (Persistence): Saldırganlar kötü amaçlı servis dosyaları oluşturarak sistem her açıldığında zararlı yazılımlarını çalıştırabilir. Özellikle /etc/systemd/system dizini ve zamanlayıcı (*.timer) dosyaları düzenli olarak denetlenmelidir.

• Sandbox özellikleri: Güvenliği artırmak için ProtectSystem=, ProtectHome=, PrivateTmp=, NoNewPrivileges=yes, CapabilityBoundingSet= gibi systemd güvenlik seçeneklerinden yararlanılabilir.

• Günlük analizi: journalctl kayıtları, başarısız oturum açma denemeleri, servis çökmeleri ve şüpheli yeniden başlatmaların incelenmesinde önemli bir kaynaktır.

---

Sonuç

Pardus'ta servis yapılandırma dosyalarını anlamak; sistem yönetimi, otomasyon ve siber güvenlik açısından temel becerilerden biridir. Unit dosyalarının yapısını, systemctl komutlarını, journalctl günlüklerini ve güvenli yapılandırma yöntemlerini öğrenmek; hem sistem yöneticileri hem de sızma testi ve savunma odaklı güvenlik uzmanları için büyük avantaj sağlar.

Siber Güvenlik Açısından Ayrıntılı Değerlendirme

Systemd servis yapılandırma dosyaları yalnızca servislerin nasıl çalışacağını belirlemez; aynı zamanda bir Linux sisteminin saldırı yüzeyini (Attack Surface) doğrudan etkiler. Birçok siber saldırıda saldırganlar, sisteme erişim sağladıktan sonra kalıcılık (Persistence) oluşturmak, yetki yükseltmek (Privilege Escalation) veya zararlı yazılım çalıştırmak için systemd servislerini kullanırlar.

Bu nedenle bir siber güvenlik uzmanının yalnızca systemctl komutlarını değil, servis dosyalarının güvenlik açısından nasıl analiz edileceğini de bilmesi gerekir.

---

Neden Servis Dosyaları Hedef Alınır?

Bir servis;

• Sistem açılır açılmaz otomatik çalışabilir.

• Root yetkisiyle çalışabilir.

• Sürekli yeniden başlatılabilir.

• Ağ bağlantıları kurabilir.

• Başka programları çalıştırabilir.

Bu özellikler saldırganlar için oldukça caziptir.

Örneğin;

Bilgisayar Açılıyor
        │
        ▼
Systemd
        │
        ▼
Kötü Amaçlı Servis
        │
        ▼
Reverse Shell

Bu yüzden birçok Linux zararlısı systemd servisleri oluşturur.

---

Saldırganların En Çok Kullandığı Dizinler

Systemd servisleri genellikle aşağıdaki dizinlerde bulunur.

/etc/systemd/system/
/usr/lib/systemd/system/
/lib/systemd/system/
/run/systemd/system/

En kritik dizin

/etc/systemd/system

çünkü yönetici tarafından eklenen servisler burada bulunur.

---

Persistence (Kalıcılık)

Linux saldırılarında en yaygın tekniklerden biri persistence'dır.

Amaç;

Sistem yeniden başlasa bile zararlı yazılımın çalışmaya devam etmesi.

Örneğin saldırgan

evil.service

isimli servis oluşturabilir.

ExecStart=/tmp/backdoor

ve

systemctl enable evil.service

çalıştırır.

Sonuç

Her açılışta

/tmp/backdoor

otomatik çalışacaktır.

---

Tespit Etme

Tüm servisleri listele

systemctl list-unit-files

Şüpheli servisleri ara

systemctl list-unit-files | grep enabled

---

Servisin içeriğini incele

systemctl cat servis_adi

veya

cat /etc/systemd/system/servis.service

---

Zararlı ExecStart

En önemli satır

ExecStart=

Örneğin

ExecStart=/tmp/update

oldukça şüphelidir.

Normal servisler

/usr/bin/
/usr/sbin/
/bin/
/usr/local/bin

altında bulunur.

---

Şüpheli örnek

ExecStart=/home/user/.cache/update

veya

ExecStart=/tmp/httpd

---

Root Yetkisi

En kritik alanlardan biri

User=root

Varsayılan olarak çoğu servis root ile çalışır.

Bu ciddi risk oluşturabilir.

Örneğin

ExecStart=/opt/web/server

Eğer

/opt/web/server

dosyası saldırgan tarafından değiştirilebiliyorsa,

servis yeniden başladığında

root yetkisiyle çalışacaktır.

---

Dosya İzinlerini Kontrol Et

ls -l /opt/web/server

Doğrusu

-rwxr-xr-x

Yanlış

-rwxrwxrwx

---

Yazılabilir Dosya Riski

Örneğin

-rwxrwxrwx app

Herkes değiştirebilir.

Servis

User=root

ise

tam yetki yükseltme oluşabilir.

---

Environment Dosyaları

Bazı servislerde

EnvironmentFile=

kullanılır.

Örneğin

EnvironmentFile=/etc/default/webapp

Bu dosya saldırgan tarafından değiştirilebiliyorsa

zararlı değişkenler yüklenebilir.

---

Kontrol

ls -l /etc/default

---

WorkingDirectory

WorkingDirectory=/tmp

çok kötü bir tercihtir.

Neden?

/tmp

herkes tarafından yazılabilir.

Doğrusu

/opt/app
/usr/share/app

---

PATH Manipülasyonu

Kötü örnek

ExecStart=python app.py

PATH değiştirildiğinde

python

yerine zararlı dosya çalışabilir.

Doğrusu

ExecStart=/usr/bin/python3 app.py

Mutlak yol kullanılmalıdır.

---

ExecStartPre

Bazı servislerde

ExecStartPre=

vardır.

Örneğin

ExecStartPre=/tmp/check.sh

Bu script çalıştırılır.

Saldırgan

check.sh

dosyasını değiştirirse

servis açılırken kod çalıştırabilir.

---

ExecStartPost

Benzer şekilde

ExecStartPost=

da incelenmelidir.

---

Restart=always

Şu ayar

Restart=always

zararlı yazılımın sürekli yeniden çalışmasını sağlar.

Örneğin

Reverse Shell

kapanır.

Systemd

hemen tekrar başlatır.

---

Şüpheli Timer Dosyaları

*.timer

cron yerine kullanılabilir.

Listele

systemctl list-timers

Bilinmeyen timer'lar incelenmelidir.

---

Override Dosyaları

Saldırgan servis dosyasını değiştirmek yerine

override oluşturabilir.

Kontrol

systemctl cat ssh

çıktısında

Drop-In

bölümü varsa dikkat edilmelidir.

---

Gizlenmiş Servisler

Bazı zararlılar isimlerini

system.service
dbus-update.service
update.service
network-helper.service

gibi masum gösterir.

Bu nedenle isim değil

ExecStart

incelenmelidir.

---

Log Analizi

En önemli araç

journalctl

Örneğin

journalctl -u ssh

veya

journalctl -xe

---

Dosya Bütünlüğü

Servis dosyalarının hash'i alınabilir.

sha256sum /etc/systemd/system/*.service

Sonradan değişmiş mi karşılaştırılır.

---

İzin Kontrolü

find /etc/systemd/system -type f -exec ls -l {} \;

Yazılabilir servis dosyaları olmamalıdır.

---

Güvenli Servis Örneği

[Service]
User=www-data
Group=www-data
WorkingDirectory=/opt/webapp
ExecStart=/usr/bin/python3 /opt/webapp/app.py
Restart=on-failure
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
ProtectHostname=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictNamespaces=yes
CapabilityBoundingSet=
AmbientCapabilities=
SystemCallArchitectures=native

Bu yapılandırma, servisi sandbox içinde çalıştırarak saldırı yüzeyini önemli ölçüde azaltır.

---

Mavi Takım (Blue Team) Kontrol Listesi

Düzenli olarak aşağıdaki kontroller yapılmalıdır:

Kontrol	Amaç
systemctl list-unit-files	Etkin servisleri incelemek
systemctl list-timers	Şüpheli zamanlayıcıları bulmak
systemctl cat servis	Gerçek yapılandırmayı görmek
journalctl -u servis	Günlükleri analiz etmek
find /etc/systemd/system	Yeni servisleri tespit etmek
sha256sum	Dosya bütünlüğünü doğrulamak
systemd-analyze security servis	Servisin güvenlik puanını analiz etmek
systemctl show servis	Ayrıntılı servis özelliklerini görmek

---

Kırmızı Takım (Red Team) ve Pentest Perspektifi

Yetkili sızma testlerinde veya laboratuvar ortamlarında systemd servisleri şu amaçlarla incelenebilir:

• Yanlış yapılandırılmış ve gereksiz yere root yetkisiyle çalışan servislerin tespiti.

• Yazılabilir ExecStart hedefleri veya servis dosyaları üzerinden olası ayrıcalık yükseltme senaryolarının belirlenmesi.

• WorkingDirectory, EnvironmentFile ve PATH kullanımından kaynaklanan güvenlik zafiyetlerinin değerlendirilmesi.

• Gereksiz çalışan servislerin tespit edilerek saldırı yüzeyinin azaltılması.

• systemd-analyze security çıktılarıyla servislerin güvenlik seviyelerinin ölçülmesi ve iyileştirme önerilerinin sunulması.

Bu tür analizler yalnızca izinli sistemlerde, savunma ve güvenlik değerlendirmesi amacıyla yapılmalıdır.

---

Sonuç

Systemd servis dosyaları, Linux ve Pardus sistemlerinin güvenliğinde kritik bir bileşendir. Düzenli denetim, en az ayrıcalık ilkesi, dosya izinlerinin kontrolü, güvenlik odaklı systemd seçeneklerinin kullanılması ve servis günlüklerinin izlenmesi; hem sistem yöneticileri hem de siber güvenlik ekipleri için temel savunma uygulamalarıdır. Güvenli yapılandırılmış servisler, saldırı yüzeyini azaltır ve olası ihlallerin etkisini önemli ölçüde sınırlar.

Pardus ve Pardus ETAP sürümleri, arka plan hizmetlerini yönetmek için systemd başlangıç yöneticisini kullanır. Kendi yazdığınız bir Python betiğini, Django web projesini veya ağ tabanlı bir aracı arkaplanda sürekli çalışır halde tutmak için .service uzantılı yapılandırma dosyaları oluşturmanız gerekir.

1. Servis Dosyalarının Konumları

Pardus'ta servis dosyaları genellikle iki farklı dizinde bulunur:

• /lib/systemd/system/: Paket yöneticisi (APT) aracılığıyla kurulan yazılımların varsayılan servis dosyaları burada yer alır. Güncellemelerde üzerine yazılacağı için bu dizindeki dosyaları doğrudan düzenlemeniz önerilmez.

• /etc/systemd/system/: Sistem yöneticisinin oluşturduğu veya özelleştirdiği servisler burada bulunur. Kendi geliştirdiğiniz servisleri her zaman bu dizine eklemelisiniz.

2. Bir Servis Dosyasının Anatomisi

Bir .service dosyası temel olarak üç ana bölümden oluşur.

Terminalde sudo nano /etc/systemd/system/uygulamam.service komutuyla oluşturacağınız standart bir servis dosyası şablonu şöyledir:

Ini, TOML

[Unit]
Description=Özel Python/Django Uygulama Servisi
After=network.target

[Service]
User=root
WorkingDirectory=/opt/benimuygulamam
ExecStart=/usr/bin/python3 /opt/benimuygulamam/main.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Bu yapılandırmadaki temel parametrelerin işlevleri:

[Unit] Bölümü

Servisin tanımını ve bağımlılıklarını belirler.

• Description=: Servisin ne işe yaradığını açıklayan kısa metin.

• After=: Bu servisin hangi hedeflerden (target) veya servislerden sonra başlatılacağını belirtir. (Örn: uygulamanız internet gerektiriyorsa network.target yazarak ağın ayağa kalkmasını beklersiniz).

• Requires=: Kesinlikle çalışması gereken bağımlılıklar. Belirtilen bağımlı servis çökerse, bu servis de çöker.

[Service] Bölümü

Servisin nasıl çalıştırılacağını ve çökme durumunda ne yapılacağını tanımlar.

• ExecStart=: Servis başladığında çalıştırılacak tam komut yolu. (Python veya sanal ortam (virtualenv) kullanıyorsanız doğrudan venv/bin/python yolunu göstermelisiniz).

• WorkingDirectory=: Komutun çalıştırılacağı kök dizin.

• User= / Group=: Servisin hangi yetkilerle çalışacağı. Güvenlik gereği uygulamanın root erişimine ihtiyacı yoksa standart bir kullanıcı tanımlanmalıdır.

• Restart=: Servis çöktüğünde sistemin ne yapacağı (always, on-failure, no).

• Environment=: Çevresel değişkenleri tanımlar (Örn: Environment="DJANGO_SETTINGS_MODULE=proje.settings").

[Install] Bölümü

Servisin sistem açılışında nasıl tetikleneceğini belirler.

• WantedBy=: Çoğunlukla multi-user.target olarak ayarlanır (Grafik arayüzden bağımsız çoklu kullanıcı çalışma seviyesi).

3. Servisi Sisteme Tanıtma ve Başlatma

Dosyayı kaydedip çıktıktan sonra, systemd'nin bu yeni yapılandırmadan haberdar olması gerekir.

1. systemd'yi yenileyin:

   Bash

   sudo systemctl daemon-reload
   

2. Servisi başlatın:

   Bash

   sudo systemctl start uygulamam.service
   

3. Sistem her açıldığında otomatik başlamasını sağlayın:

   Bash

   sudo systemctl enable uygulamam.service
   

4. Hayati systemctl Komutları

Servis yönetiminde ve laboratuvar ortamlarında sıklıkla kullanacağınız komutlar şunlardır:

Komut	Açıklama
sudo systemctl status <servis>	Servisin anlık durumunu (active, failed), anlık PID değerini ve son log kayıtlarını gösterir.
sudo systemctl restart <servis>	Servisi kapatıp yeniden açar.
sudo systemctl stop <servis>	Servisi tamamen durdurur.
sudo systemctl disable <servis>	Otomatik başlama özelliğini devreden çıkarır.

Mevcut bir .service dosyasında değişiklik yaparsanız, değişikliğin geçerli olması için her zaman önce sudo systemctl daemon-reload komutunu çalıştırmalı, ardından servisi yeniden başlatmalısınız.

5. Grafik Arayüzlü (GUI) Servisleri Çalıştırma

Etkileşimli tahtalarda PyQt6 gibi grafik arayüzlü (GUI) masaüstü uygulamalarını systemd üzerinden başlatmak isterseniz, uygulamanın arayüzü hangi ekrana çizeceğini bilmesi gerekir.

Cinnamon masaüstü ortamında bir GUI uygulamasını sistem servisi olarak ekrana yansıtmak için [Service] bölümüne ekran değişkenlerini eklemelisiniz:

Ini, TOML

[Service]
Environment="DISPLAY=:0"
Environment="XAUTHORITY=/home/etapadmin/.Xauthority"

Bu sayede systemd, arka plan işlemi olarak başlattığı arayüzü doğrudan kullanıcının aktif Cinnamon masaüstüne gönderebilir.

6. Hata Ayıklama (Log İzleme)

Servisiniz failed durumuna düşerse veya beklediğiniz gibi çalışmıyorsa, hataları tespit etmek için Journald loglarına bakmanız gerekir.

Sadece ilgili servisin loglarını görüntülemek ve doğrudan en güncel (en alt) satırlara gitmek için:

Bash

journalctl -u uygulamam.service -e

Logları canlı olarak (gerçek zamanlı) akış şeklinde izlemek için:

Bash

journalctl -u uygulamam.service -f


systemd servislerinin yapılandırması ve özellikle otomatik yeniden başlatma (auto-restart) mekanizmaları, siber güvenlik dünyasında hem savunma (Blue Team) hem de saldırı (Red Team) senaryolarında kritik bir rol oynar.
Otomatik yeniden başlatma ve servis yönetimi dinamiklerini siber güvenlik merceğinden şu şekilde inceleyebiliriz:
1. Mavi Takım (Blue Team) ve Savunma Perspektifi
Erişilebilirlik (Availability) ve Direnç: Siber güvenliğin temel yapı taşlarından biri (CIA üçlüsündeki 'A') sistemin erişilebilir olmasıdır. Eğer ağ trafiğini izleyen bir araç (örneğin Tshark, Suricata) veya özel bir loglama betiği bir saldırgan tarafından kasıtlı olarak çökertilirse (DoS), Restart=on-failure parametresi bu güvenlik kalkanının saniyeler içinde tekrar ayağa kalkmasını sağlar.
Kaynak Tüketimi (Resource Exhaustion) Koruması: Bir önceki mesajda bahsettiğimiz StartLimitIntervalSec ve StartLimitBurst parametreleri siber güvenlik açısından hayati bir zırhtır. Eğer bu hız sınırlandırması olmazsa, bir saldırgan servisteki bir zafiyeti kullanarak onu sürekli çökertebilir. Servisin sonsuz bir döngüde saniyede onlarca kez yeniden başlatılması, sunucunun işlemci (CPU) ve RAM kaynaklarını tüketerek tüm sistemin kilitlenmesine (Denial of Service) yol açar.
En Az Ayrıcalık Prensibi (Least Privilege): Bir servis yapılandırılırken [Service] bölümünde User= ve Group= parametrelerinin kullanılması zorunludur. Servis root yetkileriyle çalıştırılır ve saldırgan bu servis üzerinden sisteme sızarsa (örneğin Django uygulamasındaki bir zafiyetten RCE elde ederse), doğrudan en üst düzey yetkiyi ele geçirir. Uygulamanın sadece kendi kısıtlı kullanıcısı ile çalışması hasarı izole eder.
2. Kırmızı Takım (Red Team) ve Saldırı Perspektifi
Sistemde Kalıcılık (Persistence) Sağlama: Sisteme sızan bir saldırganın ilk hedeflerinden biri, arka kapısının (backdoor) sunucu yeniden başlasa bile çalışmaya devam etmesidir. Saldırganlar genellikle /etc/systemd/system/ dizinine gizlenmiş veya yasal görünen (örneğin system-update.service) zararlı bir servis dosyası bırakırlar.
Ölümsüz İşlemler: Bir Red Team senaryosunda, zararlı bir servise Restart=always ve RestartSec=1 parametreleri eklenir. Bu durumda sistem yöneticisi (veya bir Blue Team analisti) görev yöneticisinden zararlı işlemi fark edip kill komutuyla sonlandırsa bile, systemd anında zararlı yazılımı tekrar başlatacaktır. Analistin öncelikle servis yapılandırmasını tespit edip systemctl disable ve systemctl stop komutlarıyla müdahale etmesi gerekir.
3. Ek Güvenlik: Systemd Sandboxing (Yalıtım)
Siber güvenlik bağlamında, systemd sadece bir başlatıcı değil, aynı zamanda güçlü bir yalıtım (sandboxing) aracıdır. Doğru yapılandırılmış bir servise şu parametreler eklenerek saldırı yüzeyi daraltılabilir:
ProtectSystem=strict: Servisin tüm dosya sistemine (/) sadece salt okunur (read-only) erişmesini sağlar. Saldırgan servisi ele geçirse bile sistem dosyalarını değiştiremez.
ProtectHome=yes: Servisin /home dizinlerindeki kullanıcı verilerine (SSH anahtarları, kişisel belgeler) erişmesini tamamen engeller.
PrivateTmp=yes: Servis için /tmp dizinini izole eder. Saldırgan, diğer servislerin geçici dosyalarına erişemez.