Syslog Sunucusu Kurulumu: Ubuntu'da Merkezi Log

Merkezi bir syslog sunucusu kurmak, Ubuntu üzerinde tek bir yapılandırma dosyası yazmak kadar kısa bir iştir. Uzun olan kısım kurulum değil, sonrasıdır: hangi cihazın ne göndereceğine karar vermek, gelen kaydı okunur tutmak ve diskin dolmasını önlemek.

Bir önceki yazıda syslog protokolünü duruşma salonundaki zabıt katibine benzetmiştik: katip söyleneni yorumlamadan, olduğu gibi ve saatiyle yazar. Bu yazıda katibin bittiği yerden başlıyoruz. Tutanaklar yazıldı, peki nereye gidiyor? Adliyenin arşivine. Ve bir arşivin değeri raf sayısında değil, aradığınızı bulabilmenizdedir.

Aşağıda sercesyslog adını verdiğim gerçek bir Ubuntu 24.04 sunucuda toplayıcıyı kuruyor, lab switch’imi ona bağlıyor ve ilk gerçek kayıtları alıyoruz. Yol boyunca en çok kopyalanan ilk adımın bu makinede hiçbir şey yapmadığını da ölçeceğiz.

Bu makale BT Sistem Yönetimi hizmetimizin log altyapısı tarafına, Ubuntu Server üzerinde çalışan kurumsal rollerden birine odaklanır.

Başlamadan Önce: Sunucu, Disk ve Saat

Bu rehber, üzerine syslog toplayıcı kuracağınız Ubuntu Server’ı zaten ayağa kaldırdığınızı varsayar. İşletim sistemi kurulumu, disk düzeni ve ilk yapılandırma ayrı bir konudur ve Ubuntu Server kurulum rehberimizde ele alınmaktadır.

Kullandığımız makine mütevazı: Ubuntu 24.04.4 LTS, 2 sanal işlemci, 1,9 GB bellek. Syslog toplamak işlemci istemez, disk ister.

Diskin Yarısı Boşta Kalmış Olabilir

Log sunucusunda disk, işlemciden de bellekten de önemlidir; o yüzden başlamadan önce gerçekten ne kadar alanınız olduğunu doğrulayın. LVM ile kurulmuş bir Ubuntu’da bu, göründüğü kadar olmayabilir:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

sda                         20G             disk
├─sda1                       1M             part
├─sda2                     1.8G ext4        part /boot
└─sda3                    18.2G LVM2_member part
  └─ubuntu--vg-ubuntu--lv   10G ext4        lvm  /

Son satıra dikkat edin. Makineye 20 GB disk verdim, LVM birim grubu 18,2 GB, ama kök bölüme yalnız 10 GB düşmüş. Ubuntu’nun rehberli kurulumu gerisini bilerek tahsis etmeden bırakıyor.

Log biriktiren bir makinede bu sinsi bir tuzaktır: disk “20 GB” sanılır, gerçekte 10 GB’tır, ve dolduğu gün log yazımı sessizce durur. Bu sunucuda boştaki 8,2 GB’ı köke ekledim ve kök bölüm 18 GB’a çıktı.

Genişletme komutu ve bedeli, bu bölümün başında linklediğimiz Ubuntu Server kurulum rehberinin kurulum sonrası kontroller kısmında duruyor. Bedeli tek cümleyle söyleyeyim, çünkü kararı etkiler: boş alanın tamamını köke aktarırsanız geriye snapshot için yer kalmaz ve ext4 çalışırken büyütülebilir ama küçültülemez, yani işlem pratikte geri alınmaz. Log sunucusunda genellikle tamamını almak doğrudur; snapshot alma alışkanlığınız varsa bir miktar pay bırakın.

Buradaki tek mesaj şu: toplayıcıyı kurmadan önce diskin gerçek boyutunu ölçün.

Saat Kaynağı Toplayıcıdan Önce Gelir

Bir arşivin en kritik alanı tarihtir. İki cihazın saati birbirinden farklıysa, ikisinden gelen kayıtları yan yana koyduğunuzda olayların sırası yanlış görünür ve bunun teşhisi zordur, çünkü kayıtların kendisi doğrudur.

Bu yüzden merkezi log kurulumunun sırası şudur: önce saat, sonra toplayıcı. Ağdaki bütün cihazların aynı zaman kaynağına bağlanması gerekir; kurumsal ağda saat dağıtımını NTP protokolü yazımızda, Linux tarafındaki kurulumu ise chrony rehberimizde anlatıyoruz.

rsyslog Zaten Kurulu: apt Adımını Neden Atlıyoruz?

Sunucu hazır. Sıra yazılımda, ve ilk adım tam olarak atlamanız gereken adım.

Türkçe kaynakların neredeyse tamamı bu işe apt install rsyslog ile başlıyor. Google’ın arama sonuçlarının tepesindeki yapay zekâ özeti de aynı şeyi söylüyor: “Paketi yükle: sudo apt update && sudo apt install rsyslog”.

Ölçtüm.

Kutudan Gelen Hâli Ölçelim

Temiz kurulmuş sunucuda, hiçbir şey yapmadan:

dpkg -l rsyslog | tail -1
systemctl is-active rsyslog
systemctl is-enabled rsyslog

ii  rsyslog  8.2312.0-3ubuntu9.3  amd64  reliable system and kernel logging daemon
active
enabled

Paket kurulu, servis çalışıyor, açılışta kendiliğinden başlıyor. apt install komutu bu makinede rsyslog is already the newest version deyip çıkar. Yani en çok kopyalanan ilk adım, gerçek yolda bir işe yaramıyor.

Çalışıyor Olmak ile Dinliyor Olmak Aynı Şey Değil

Peki servis çalışıyorsa iş bitti mi? Aynı makinede ikinci ölçüm:

sudo ss -lunp | grep 514
sudo ss -ltnp | grep 514
grep -rE '^\s*module\(load="(imudp|imtcp)"' /etc/rsyslog.conf /etc/rsyslog.d/

UDP 514 DINLENMIYOR
TCP 514 DINLENMIYOR
HICBIRI YUKLU DEGIL

İşte gerçek durum. rsyslog ayakta ama hiçbir yeri dinlemiyor. Varsayılan yapılandırma yalnızca makinenin kendi kayıtlarını toplar; ağdan gelen bir syslog paketini kabul edecek modül (imudp ya da imtcp) yüklü bile değil.

Arşiv binası ayakta, memur masasında oturuyor, ama kapı kapalı. Dışarıdan gelen evrak içeri giremiyor ve kimse bunu fark etmiyor, çünkü içeride kendi işleri sorunsuz yürüyor.

Yapılacak iş paket kurmak değil, kapıyı açmaktır. Bir sonraki bölüm bunu yapıyor.

Toplayıcıyı Açmak: imudp Modülü ve 514 Portu

Toplayıcıyı açmak için var olan dosyaları düzenlemeyin; /etc/rsyslog.d/ altına kendi dosyanızı ekleyin. Paket güncellemeleri kendi dosyalarının üzerine yazar, sizinkine dokunmaz.

Tek Dosya, Dört İş

sudo nano /etc/rsyslog.d/10-uzak-loglar.conf

# Uzak cihazlardan syslog toplama
module(load="imudp")
input(type="imudp" port="514")

# Gönderen başına ayrı dizin, program başına ayrı dosya
template(name="UzakLog" type="string"
         string="/var/log/uzak/%HOSTNAME%/%PROGRAMNAME%.log")

# Yerel olmayan her kaynak uzak dizine yazılır ve işlem DURUR
if $fromhost-ip != "127.0.0.1" then {
    action(type="omfile" dynaFile="UzakLog"
           createDirs="on" fileCreateMode="0640" dirCreateMode="0755")
    stop
}

Dosya dört iş yapıyor ve dördü de gerekli:

1. module(load="imudp") ağdan syslog kabul eden modülü yükler. Bu satır olmadan aşağıdakilerin hiçbiri çalışmaz.
2. input(type="imudp" port="514") hangi portun dinleneceğini söyler.
3. template gelen kaydın hangi dosyaya yazılacağını belirler. %HOSTNAME% gönderen cihazın adı, %PROGRAMNAME% kaydı üreten süreçtir.
4. stop işlemi orada bitirir. Bunun neden şart olduğu birazdan ölçümle görünecek.

Yazdıktan sonra uygulamadan önce sözdizimini doğrulayın:

sudo rsyslogd -N1

rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

Hata satırı yoksa temizdir. Şimdi servisi yeniden başlatın ve kapının açıldığını teyit edin:

sudo systemctl restart rsyslog
sudo ss -lunp | grep 514

UNCONN 0 0    0.0.0.0:514    0.0.0.0:*    users:(("rsyslogd",pid=3193,fd=6))
UNCONN 0 0       [::]:514       [::]:*    users:(("rsyslogd",pid=3193,fd=7))

Artık dinliyor.

Dosya Adındaki 10- Öneki Neden Önemli?

rsyslog /etc/rsyslog.d/ altındaki dosyaları alfabetik sırayla okur ve kuralları bu sırayla uygular. Ubuntu’nun kendi kuralları 50-default.conf dosyasında durur.

Dosyaya 10- önekini verdiğimiz için bizim kurallarımız o dosyadan önce çalışıyor. Bu, stop komutunun işe yaramasının ön koşulu: stop, kendisinden sonraki kuralların çalışmasını engeller. Dosya 60- olsaydı Ubuntu’nun varsayılan kuralları çoktan işlemiş olurdu ve stop geç kalırdı.

Arşiv dilinde: gelen evrakı kapıda ayırıyoruz, iç servislere dağıldıktan sonra değil.

TCP de İstiyorsanız İki Satır Daha

UDP’de yolda kaybolan kayıt hiçbir yerde iz bırakmaz. Kaybı görmek istiyorsanız TCP’yi de açın; ikisi aynı anda çalışabilir, cihazlar hangisini destekliyorsa ondan gönderir. Yeni bir dosya açmıyorsunuz, az önce yazdığınız 10-uzak-loglar.conf dosyasına iki satır ekliyorsunuz. Yeri şurası:

# --- Bu iki satır dosyada ZATEN VAR, dokunmayın ---
module(load="imudp")
input(type="imudp" port="514")

# --- BU İKİSİNİ EKLEYİN (hemen yukarıdakilerin altına) ---
module(load="imtcp")
input(type="imtcp" port="514")

# --- Dosyanın geri kalanı (template ve if bloğu) aynen kalsın ---

sudo rsyslogd -N1 && sudo systemctl restart rsyslog
sudo ss -ltnp | grep 514

LISTEN 0 25    0.0.0.0:514    0.0.0.0:*    users:(("rsyslogd",pid=4021,fd=8))

Gönderen tarafta fark tek karakterdir: Linux istemcide @ UDP, @@ TCP demektir. Test ederken logger komutuna -T bayrağı eklemek de aynı işi görür.

TCP kaybı görünür kılar ama kaydı şifrelemez; satır ağda hâlâ okunabilir durumda gider. Şifreli taşımayı, sertifika üretiminden paket dökümüne kadar aşağıda ayrı bir bölümde ele alıyoruz.

Doğrulama: Switch’e Dokunmadan Önce Kendi Üstünde Test

Kapı açıldı. Şimdi bir cihaz bağlamadan önce boru hattının kendi üstünde çalıştığını görelim, çünkü ilerde “log gelmiyor” dediğinizde toplayıcı mı gönderen mi bozuk ayırt edebilmeniz gerekir. Bu adımı atlarsanız iki bilinmeyenli bir arıza ile uğraşırsınız.

logger ile Ağ Yolunu Sınamak

logger komutu elle syslog mesajı üretir. Önemli olan -n bayrağı: mesajı yerel sokete değil, ağ üzerinden belirtilen adrese gönderir. Sunucunun kendi IP adresini vererek gerçek ağ yolunu sınıyoruz:

logger -n 192.168.1.46 -P 514 -d -t lab-testi "toplayici ag yolu dogrulama"

Sunucu tarafında beklenen sonuç, dizinin kendiliğinden oluşmuş olmasıdır (createDirs="on" bunu sağlıyor):

sudo find /var/log/uzak -type f
sudo cat /var/log/uzak/*/lab-testi.log

/var/log/uzak/sercesyslog/lab-testi.log
2026-08-18T22:30:17.601035+00:00 sercesyslog lab-testi toplayici ag yolu dogrulama

Kayıt geldi, gönderen adına açılmış dizine yazıldı.

Sızıntı Kontrolü: Aynı Kayıt İki Yere Düştü mü?

Bu, kurulumun en sık atlanan doğrulamasıdır. stop satırı çalışmıyorsa uzak kayıtlar hem kendi dizinine hem sunucunun kendi /var/log/syslog dosyasına düşer; sonuç iki katına çıkan disk kullanımı ve kendi kayıtlarınızın başka cihazların gürültüsü içinde kaybolmasıdır.

sudo grep -c "toplayici ag yolu dogrulama" /var/log/syslog

0

Sıfır. Kayıt yalnız gitmesi gereken yere gitti.

Log Gelmiyorsa Nereye Bakılır?

Sırayla, en ucuz kontrolden başlayarak:

1. Toplayıcı dinliyor mu: sudo ss -lunp | grep 514. Boşsa modül yüklenmemiştir, rsyslogd -N1 çıktısını okuyun.
2. Paket sunucuya ulaşıyor mu: sudo tcpdump -ni any udp port 514. Paket görünmüyorsa sorun ağda ya da gönderen tarafındadır, rsyslog’da değil.
3. Güvenlik duvarı: sudo ufw status. Etkinse sudo ufw allow 514/udp gerekir. Bizim makinede inactive olduğu için bu adım gerekmedi.
4. Yazma izni: /var/log/uzak altında dizin oluşmuyorsa createDirs="on" satırını ve rsyslog’un çalıştığı kullanıcıyı kontrol edin.

Gönderen Tarafı: Switch’i Syslog Sunucusuna Bağlamak

Toplayıcı çalışıyor. Şimdi gerçek bir cihaz bağlıyoruz: lab switch’im, yönetilebilir bir kurumsal switch.

Tek Satırlık Yapılandırma

Ağ cihazlarında bu iş genellikle tek satırdır. Bu cihazın işletim sisteminde komut şu:

configure
logging 192.168.1.46
exit

Komutu yazdığınızda cihaz bir alt yapılandırma moduna giriyor ve orada üç ayar sunuyor: description (sunucuya açıklama vermek), level (hangi önem derecesinden yukarısının gönderileceği) ve port (varsayılan 514). Hiçbirini değiştirmedik; varsayılanlar bu kurulum için doğru.

Sözdizimi tuzağı, üç turumu aldı: komut logging host <ip> değil, doğrudan logging <ip>. Ayrıca show logging hosts diye bir komut yok; tanımlı sunucuyu görmek için show running-config | include logging kullanılıyor. Cihazın kendi yazdığı yapılandırma satırı, yardım çıktısından her zaman daha güvenilir kaynaktır.

Kaydetmezseniz Elektrik Kesintisinde Kaybolur

Ağ cihazlarında çalışan yapılandırma ile açılışta okunan yapılandırma iki ayrı şeydir. Yukarıdaki komut yalnız çalışan yapılandırmaya yazıldı; cihaz yeniden başlarsa log göndermeyi bırakır ve bunu size kimse söylemez.

Öncesini ve sonrasını ölçelim:

show startup-config | include logging
copy running-config startup-config
show startup-config | include logging

(bos)

This operation may take few minutes.
Are you sure you want to save? (y/n) y
Configuration Saved!

logging 192.168.1.46

İlk sorguda çıktı boş, ikincisinde satır yerinde. Artık kalıcı.

Gönderen Başına Ayırma: Tek Dosyada Her Şey Kaybolur

Switch bağlandı ve kayıtlar akmaya başladı. Şablonun ne yaptığı şimdi görünür oluyor:

sudo find /var/log/uzak -type f -printf "%s bayt\t%p\n" | sort -rn

21386 bayt	/var/log/uzak/sercebilisimsw01-1/DOT1S.log
  147 bayt	/var/log/uzak/sercebilisimsw01-1/CLI_WEB.log
   83 bayt	/var/log/uzak/sercesyslog/lab-testi.log

Switch kendi dizinini aldı, ve dizinin içinde kayıtlar üreten sürece göre ikiye ayrıldı. Bu ayrım şablondaki %PROGRAMNAME% sayesinde kendiliğinden oldu; hiçbir kural yazmadık.

Ayrımın değeri boyutlarda saklı. CLI_WEB.log yalnız 147 bayt ve içinde tek satır var:

<190> Aug 19 07:01:59 sercebilisimsw01-1 CLI_WEB[emWeb]: %% [CLI:ilker:192.168.1.115] User has succesfully logged in

Switch’e kimin, ne zaman, hangi adresten yönetici olarak girdiği. Bir güvenlik sorusunda ilk bakacağınız satır budur. Ayrı dosyada olduğu için görünüyor; aynı dosyada olsaydı 21 KB’lık gürültünün içinde kaybolurdu.

Arşivde her mahkemenin kendi rafı, her dava türünün kendi klasörü vardır. Hepsini tek odaya yığmak da “arşivlemektir”, ama aradığınızı bulamazsınız.

Disk ve Rotasyon: Bir Switch Günde Ne Kadar Yazar?

Ayrım tamam, kayıtlar okunur durumda. Şimdi büyümeyi ölçelim, çünkü bu kurulumun bir yıl sonra hâlâ çalışıp çalışmayacağını belirleyen şey bu.

Ölçüm: Altmış Saniye, Altmış Satır

Sahada bu soruya verilen standart cevap “bir switch pek konuşmaz, ara sıra bir port düşer” şeklindedir. Ölçtüm: switch’e bağlandıktan sonra hiçbir şey yapmadan, kimseyi bağlamadan, yapılandırma değiştirmeden altmış saniye bekledim.

60 satir / 8.670 bayt

Bu hızda:

Tek switch, hiçbir olay yokken. Gerçek bir kurumda firewall’un bağlantı başına log üretmesi bu rakamı katlar; yasal saklama için iki yıl tutmanız gerekiyorsa hesap doğrudan bu tabloya bağlanır.

Gürültüyü Kaynağında Kesmek

Rakamın büyüklüğünden çok içeriği önemli. Toplanan 149 satırın 148’i aynı iki mesajın tekrarıydı: switch’in her iki saniyede bir anlamlandıramadığı bir protokol mesajını atması. Yani hacmin yüzde 99’u aynı cümlenin kopyası, anlamlı tek kayıt ise 147 bayt.

Ayıklama üç kademede yapılır ve ilk kademe en ucuzudur:

1. Gönderen tarafta eşik. Cihazın hangi önem derecesinden yukarısını göndereceğini ayarlayın; alt moddaki level ayarı bunun içindir. debug seviyesini sürekli açık bırakmak gürültünün en büyük kaynağıdır. Firewall’da bu karar daha da kritiktir, hangi kural setinin loglanacağı firewall kurulumunda baştan kararlaştırılır.
2. Toplayıcıda ayrıştırma. Zaten yaptık: gönderen ve süreç başına ayrı dosya.
3. Rotasyon ve saklama. logrotate kayıtları belirli aralıkla sıkıştırıp arşivler. Ubuntu’nun hazır kuralı /etc/logrotate.d/rsyslog dosyasındadır ama yalnız /var/log/syslog gibi kendi dosyalarını sayar; az önce açtığımız /var/log/uzak dizinini bilmez, dolayısıyla o dizin hiç dönmez ve sonsuza kadar büyür.

Uzak dizin için ayrı bir kural gerekiyor:

sudo nano /etc/logrotate.d/uzak-loglar

/var/log/uzak/*/*.log {
    daily
    rotate 730
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog syslog
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Üç satır kararı taşıyor:

• daily + rotate 730 iki yıllık saklama demektir. Bu sayı keyfî değil, 5651 kapsamındaki kayıtlar için istenen süreye denk geliyor; yükümlü değilseniz çok daha küçük tutabilirsiniz.
• create 0640 syslog syslog dönen dosyanın sahipliğini korur. Bu makinede uzak kayıtlar syslog:syslog sahipliğiyle oluşuyor; farklı bir kurulumda ls -l /var/log/uzak/*/ ile teyit edip yazın, yanlış sahiplik rsyslog’un yazmayı kesmesine yol açar.
• postrotate bloğu rsyslog’a dosyayı yeniden açmasını söyler. Atlanırsa rsyslog silinmiş dosyaya yazmaya devam eder ve kayıtlar hiçbir yere gitmez, üstelik hata da vermez.

Kuralı uygulamadan sınayın:

sudo logrotate -d /etc/logrotate.d/uzak-loglar

-d bayrağı hiçbir şey değiştirmez, yalnız ne yapacağını yazar.

Üçünü de atlarsanız sonuç öngörülebilir: disk dolar, log yazımı durur, ve bunu ancak ihtiyacınız olduğu gün fark edersiniz.

Aynı ağda ölçüm tarafını da toplamak istiyorsanız, sayısal veriyi grafiğe çeviren tarafı Cacti kurulum rehberimizde anlatıyoruz. İkisi rakip değil: biri olayı, diğeri eğriyi tutar.

Bu ayıklamanın ölçekteki karşılığını bir vakada da yaşadık: on üç lokasyonlu bir ağda pahalı bir izleme ürününden açık kaynak araçlara geçerken asıl zorluk veriyi toplamak değil, toplanan veriyi okunur kılmaktı. Tek switch’te yüzde doksan dokuz olan gürültü oranı, onlarca cihazda kendiliğinden düzelmiyor.

TLS ile Şifreli Toplama: Sertifikadan Paket Dökümüne

Disk ve gürültü tarafını yönettik, kayıtlar okunur durumda. Ama buraya kadar her şey ağda açıkça gidiyor. Şimdi onu kapatıyoruz.

Syslog düz metin taşır. Aynı ağdaki biri paketleri yakalarsa kullanıcı adları, cihaz adları ve yapılandırma değişiklikleri okunur. Bunu ölçelim: 514 portundan bir mesaj gönderip aynı anda ağdan paket yakaladım.

sudo tcpdump -ni lo -A "udp port 514" -c 2
logger -n 127.0.0.1 -P 514 -d -t gizli-test "PAROLA=CokGizli123 duz metin gidiyor"

<13>1 2026-08-19T00:58:11+00:00 sercesyslog gizli-test - - PAROLA=CokGizli123 duz metin gidiyor

Cümlenin tamamı, parola dahil, ağda açıkça duruyor. Şimdi bunu kapatıyoruz.

Adım 1: Kendi sertifika otoritenizi kurun

Dışarıdan sertifika almanıza gerek yok; iç ağ için kendi otoritenizi üretmek yeterli. Üç komut, üç dosya:

sudo mkdir -p /etc/rsyslog.d/tls && cd /etc/rsyslog.d/tls

# 1) Otoritenin kendisi: on yıl geçerli, imzalayan taraf
sudo openssl req -x509 -newkey rsa:2048 -nodes -days 3650 \
  -keyout ca-key.pem -out ca-cert.pem \
  -subj "/C=TR/O=Sirket Lab/CN=Sirket Syslog CA"

# 2) Toplayıcı için istek üret
sudo openssl req -newkey rsa:2048 -nodes \
  -keyout sunucu-key.pem -out sunucu.csr \
  -subj "/C=TR/O=Sirket Lab/CN=sercesyslog"

# 3) İsteği otoriteyle imzala. SAN satırı şart: istemciler adı buradan doğrular
printf "subjectAltName=DNS:sercesyslog,IP:192.168.1.46\n" | sudo tee san.cnf
sudo openssl x509 -req -in sunucu.csr -CA ca-cert.pem -CAkey ca-key.pem \
  -CAcreateserial -out sunucu-cert.pem -days 825 -extfile san.cnf

Dosya sahipliğini de ayarlayın; rsyslog root değil syslog kullanıcısıyla çalışır:

sudo chown -R root:syslog /etc/rsyslog.d/tls
sudo chmod 750 /etc/rsyslog.d/tls
sudo find /etc/rsyslog.d/tls -name "*.pem" -exec chmod 640 {} +

Adım 2: Toplayıcıya TLS dinleyicisi ekleyin

Gerekli paket dağıtımla gelmiyor, ayrıca kurulur:

sudo apt install rsyslog-gnutls

Ardından 10-uzak-loglar.conf dosyasına şu bloğu ekleyin:

# --- UDP bloğu dosyada ZATEN VAR, dokunmayın ---
module(load="imudp")
input(type="imudp" port="514")

# --- BU BLOĞU EKLEYİN: sertifikaları tanıt ve 6514'ü aç ---
global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca-cert.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/sunucu-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/sunucu-key.pem"
)
module(load="imtcp" StreamDriver.Name="gtls"
       StreamDriver.Mode="1" StreamDriver.AuthMode="anon")
input(type="imtcp" port="6514")

# --- template ve if bloğu aynen kalsın ---

StreamDriver.Mode="1" TLS’i zorunlu kılar, AuthMode="anon" ise istemcinin sertifika göstermesini istemez: sunucu kimliğini kanıtlar, istemci yalnız dinler. Karşılıklı doğrulama istiyorsanız istemciye de sertifika üretip AuthMode="x509/name" kullanılır.

sudo rsyslogd -N1 && sudo systemctl restart rsyslog
sudo ss -lntp | grep 6514

LISTEN 0 25    0.0.0.0:6514    0.0.0.0:*    users:(("rsyslogd",...))

Adım 3: Gönderen tarafı

Linux gönderende ca-cert.pem dosyasının bir kopyası bulunmalı; istemci sunucunun sertifikasını onunla doğrular. Yapılandırma tek blok:

global(DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca-cert.pem")
action(type="omfwd"
       target="192.168.1.46" port="6514" protocol="tcp"
       StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="anon")

Şimdi Aynı Cümleyi Yakalamada Tekrar Arayalım

Aynı parolayı, bu kez 6514 üzerinden gönderdim ve yakalamayı yine açtım:

sudo tcpdump -ni any -A "tcp port 6514" -c 12
logger -t tls-test "PAROLA=CokGizli123 sifreli gidiyor"

Yakalamada PAROLA kelimesini aradım:

eslesme sayisi: 0

Görünen tek şey TCP başlıkları:

IP 192.168.1.46.41900 > 192.168.1.46.6514: Flags [S], seq 766642195
IP 192.168.1.46.6514 > 192.168.1.46.41900: Flags [S.], seq 3200597873
IP 192.168.1.46.41900 > 192.168.1.46.6514: Flags [.], ack 1, win 512

Kayıt ise toplayıcıya sorunsuz ulaştı:

2026-08-19T00:58:18+00:00 sercesyslog tls-test: PAROLA=CokGizli123 sifreli gidiyor

Aynı cümle, aynı ağ, iki farklı port: birinde açıkça okunuyor, diğerinde tek kelime bile çıkmıyor.

Takılırsanız: “Permission denied” diyorsa sorun izinlerde olmayabilir

İlk denememizde sertifikaları /etc/rsyslog-tls/ altına koymuştuk ve servis şunu verdi:

rsyslogd: error: defaultnetstreamdriverkeyfile '/etc/rsyslog-tls/sunucu-key.pem'
could not be accessed: Permission denied

Klasik refleks izinlere bakmaktır. Ama ls -l doğru sahipliği gösteriyordu ve sudo cat dosyayı okuyabiliyordu. Sebebi çekirdek günlüğü söyledi:

apparmor="DENIED" operation="open" profile="rsyslogd"
name="/etc/rsyslog-tls/sunucu-key.pem" requested_mask="r" fsuid=0

fsuid=0 satırına dikkat: işlem root yetkisiyle okumaya çalışıyor ve yine reddediliyor. Çünkü engel dosya izni değil AppArmor profili. Teşhis komutu şudur:

sudo journalctl -k --since "-5min" | grep -i apparmor

Çözüm iki türlü: ya sertifikaları profilin zaten izin verdiği /etc/rsyslog.d/ altına taşıyın (bu rehberde yaptığımız), ya da /etc/apparmor.d/rsyslog.d/ altına kendi kuralınızı ekleyin. Birincisi daha sağlamdır, çünkü paket güncellemelerinden etkilenmez.

Güvenlik ve Sınır: 514’ü Kime Açıyorsunuz?

Taşımayı şifreledik, yani kayıtlar artık yolda okunmuyor. Ama şifreleme gönderenin kim olduğunu söylemez. Geriye iki soru kalıyor, ikisi de kurulumun kendisinden daha önemli.

Gönderen Adresini Kısıtlamak

Syslog gönderenin kim olduğunu doğrulamaz. Toplayıcı, gelen kaydı paketin kaynak adresine bakarak bir cihaza atar ve bu bir kimlik doğrulaması değildir. UDP’de kaynak adresi taklit edilebilir; ağdaki herhangi bir makine, switch’inizden geliyormuş gibi görünen kayıtlar üretebilir.

Protokol bu sorunu çözmüyor, dolayısıyla çözüm çevrede: 514 portunu ağın tamamına değil yalnız bilinen gönderen adreslerine açın.

sudo ufw allow from 192.168.1.2 to any port 514 proto udp
sudo ufw enable

Kimlik doğrulaması yerine geçmez ama çıtayı belirgin biçimde yükseltir. Aynı mantıkla toplayıcı sunucuyu yönetim ağının dışına açmayın.

Bu Kurulum 5651 İçin Yeterli mi?

Hayır, ve bunu açıkça söylemek gerekiyor.

Bu kurulum toplama sorununu çözer: kayıtlar cihazın üstünde kalmaz, merkezî bir yerde birikir, gönderen başına ayrılır. 5651 sayılı kanunun istediği ise bundan fazlasıdır: zaman damgası, değiştirilemezlik ve iki yıllık saklama garantisi. Bunların hiçbiri rsyslog’un işi değildir.

İlişki şöyle kurulur: toplama olmadan o katman da kurulamaz. Yani bu adım gerekli, ama tek başına yeterli değil. Yükümlülüğün tamamını, hangi kaydın ne kadar süreyle nasıl saklanması gerektiğini 5651 log yönetimi rehberimizde ele alıyoruz.

Sonuç: Kurmak Kolay, Arşivi Yaşatmak Ayrı İş

Ubuntu’da merkezi syslog sunucusu kurmak tek bir yapılandırma dosyasına sığdı ve paket kurmayı bile gerektirmedi. Toplam iş: bir modül yükle, bir port dinle, gönderen başına ayır, stop de.

Zor olan kısım bundan sonrası. Ölçüm şunu gösterdi: tek bir switch, hiçbir olay yokken bile dakikada altmış satır yazıyor ve bu satırların yüzde doksan dokuzu size hiçbir şey anlatmıyor. Kurulumu yapıp bırakırsanız bir yıl içinde elinizde 4,3 GB’lık, kimsenin açmadığı bir dizin olur.

Arşivi değerli yapan şey rafların dolu olması değil. Aradığınız tutanağı bulabilmenizdir.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.