Rehberler 23 dk okuma

SSH Güvenlik Sıkılaştırma: 2026 İçin Kapsamlı Rehber

OpenSSH 10.0 post-kuantum algoritmaları, FIDO2 donanım anahtarları, Fail2Ban yapılandırması ve ssh-audit ile SSH sunucunuzu adım adım sıkılaştırın.

Editorial Team

Giris: 2026'da SSH Guvenligi Neden Her Zamankinden Daha Kritik?

SSH (Secure Shell) protokolu, Linux sunucu yonetiminin omurgasini olusturuyor. Bulut altyapilarindan DevOps pipeline'larina, veritabani yonetiminden konteyner orkestresyonuna kadar her yerde SSH var. Ama tam da bu yayginlik, SSH'i saldirganlarin bir numarali hedefi haline getiriyor.

2025 yilinin rakamlarina bir bakin -- gercekten urkutucu: Linux ucnoktalarina yonelik saldirilarin %89'u SSH brute-force veya kimlik bilgisi doldurma (credential stuffing) saldirilari icerir hale geldi. Internete acik yeni bir VPS, port 22 uzerinden ilk prob'unu ortalama 90 saniye icinde aliyor. Dusunun, daha sunucuyu kurup bir kahve yapmaya firsat bulamadan saldiri basliyior.

Shadowserver Foundation'in bal kukla (honeypot) aglari, yalnizca 2025'in son ceyreginde 17 milyonun uzerinde SSH giris denemesi kayit altina aldi. P2PInfect solucan zararlisi tek basina bu saldirilarin %80,4'unu olusturuyordu.

Bir de su var: Subat 2025'te aciklanan CVE-2025-26465 guvenlik acigi, VerifyHostKeyDNS secenegi etkin olan OpenSSH istemcilerinde ortadaki adam (MitM) saldirisi gerceklestirmeye olanak taniyordu. Bu acik, OpenSSH 6.8p1'den 9.9p1'e kadar tum surumleri etkiledi ve ancak 9.9p2 surumunde giderildi. Ozellikle FreeBSD sistemlerinde bu secenek varsayilan olarak acik oldugu icin risk cok daha buyuktu.

Tum bunlari goz onunde bulundurarak, bu makalede SSH guvenligi icin kapsamli bir sikilastirma rehberi haziladim. Cekirdek sikilastirma rehberimizi okuduysan, bu makalenin o temelin uzerine insa ettigini goreceksin. Benzer sekilde, nftables rehberimiz ile birlikte uygulandiginda, sunucularin icin cok katmanli bir savunma hatti olusturmus olacaksin.

1. OpenSSH Surum Yonetimi ve Guncelleme Stratejisi

1.1 Mevcut Surumu Dogrulama

Herhangi bir sikilastirma islemine baslamadan once, sunucunda calisan OpenSSH surumunu bilmen gerekiyor. Kulaga basit geliyor ama inan bana, cogu insan bunu atliyor:

# Sunucu surumunu kontrol et
sshd -V

# Istemci surumunu kontrol et
ssh -V

# Kurulu paket surumunu kontrol et (Debian/Ubuntu)
dpkg -l | grep openssh

# Kurulu paket surumunu kontrol et (RHEL/Fedora)
rpm -qa | grep openssh

Nisan 2025'te yayimlanan OpenSSH 10.0, SSH tarihinde bir donum noktasi oldu. Bu surumle birlikte mlkem768x25519-sha256 algoritmasi varsayilan post-kuantum anahtar degisim algoritmasi haline geldi. Hibrit bir algoritma olan bu yaklasim, NIST tarafindan standartlastirilan ML-KEM mekanizmasini klasik X25519 ile birlestiriyor -- boylece hem kuantum bilgisayar saldiriharina hem de klasik saldirilara karsi koruma sagliyor.

OpenSSH 10.0 ayrica DSA algoritmasini tamamen kaldirdi. Eger hala DSA anahtarlari kullanan eski sistemlerin varsa, bu gecisi planlamamis olman ciddi sorunlara yol acabilir. Ben bu gecisi ilk uyguladigimda, envanterimdeki bes eski sunucunun hala DSA anahtari kullandigini kesfetmistim -- zamaninda fark etmesem bugun hala ugrasiyior olurdum.

OpenSSH 10.1 ise post-kuantum olmayan anahtar degisim algoritmalari kullanildiginda uyari mesaji gostermeye basladi. Bu uyari, WarnWeakCrypto secenegi ile kontrol edilebilir. Sunucularin henuz post-kuantum destegi sunmuyorsa, istemcilerin bu uyariyi gormeye baslayacak.

1.2 Otomatik Guvenlik Guncellemeleri

SSH guncellemeleri, ozellikle guvenlik yamalari, mumkun olan en kisa surede uygulanmali. Manuel takip her zaman mumkun olmayabilir (hele bir de birden fazla sunucu yonetiyorsan), bu yuzden otomatik guvenlik guncellemelerini yapilandirmani siddetle oneririm.

Debian/Ubuntu icin (unattended-upgrades):

# Kurulum
sudo apt install unattended-upgrades apt-listchanges

# Yapilandirma dosyasini duzenle
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

# Yalnizca guvenlik guncellemelerini etkinlestir
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

# SSH paketlerini oncelikli olarak guncelle
Unattended-Upgrade::Package-Blacklist {
};

# Guncelleme sonrasi otomatik yeniden baslatma (dikkatli kullanin)
Unattended-Upgrade::Automatic-Reboot "false";

# E-posta bildirimi
Unattended-Upgrade::Mail "[email protected]";

RHEL/Fedora icin (dnf-automatic):

# Kurulum
sudo dnf install dnf-automatic

# Yapilandirma
sudo nano /etc/dnf/automatic.conf

[commands]
upgrade_type = security
apply_updates = yes

# Servisi etkinlestir
sudo systemctl enable --now dnf-automatic-install.timer

# Yalnizca openssh icin manuel kontrol
sudo dnf update --security openssh-server openssh-clients

2. sshd_config ile Kapsamli Sikilastirma

SSH sunucusunun ana yapilandirma dosyasi olan /etc/ssh/sshd_config, guvenlik sikilastirmasinin kalbi. Simdi her bir ayari neden yaptigimizi ve ne ise yaradigini tek tek inceleyelim.

2.1 Kimlik Dogrulama Guvenligi

Kimlik dogrulama ayarlari, SSH guvenliginin en kritik parcasi. Yanlis yapilandirilmis bir kimlik dogrulama, tum diger onlemleri anlamsiz kilar -- bunu hep soyleyeyim.

# Root kullanicisi ile dogrudan giris KAPATILMALI
PermitRootLogin no

# Parola tabanli kimlik dogrulama KAPATILMALI
PasswordAuthentication no

# Bos parola ile giris kesinlikle KAPATILMALI
PermitEmptyPasswords no

# Acik anahtar tabanli kimlik dogrulama ACILMALI
PubkeyAuthentication yes

# Maksimum kimlik dogrulama denemesi
MaxAuthTries 3

# Maksimum esitli oturum sayisi
MaxSessions 3

# Kimlik dogrulama icin verilen sure (saniye)
LoginGraceTime 30

# Yalnizca belirli kullanicilara erisim izni ver
AllowUsers deployer admin sysops

# Veya grup bazinda erisim kontrolu
AllowGroups ssh-users ssh-admins

PermitRootLogin no ayari tek basina en etkili onlemlerden biri. Saldirganlar ilk olarak root kullanici adini dener. Bu ayari ilk uyguladigimda, log dosyalarindaki basarisiz giris denemelerinin yarisinin aninda kayboldigunu gordum -- ciddi anlamda yarisinin. MaxAuthTries 3 ise brute-force saldirilarinin hizini onemli olcude dusurur; her baglanti icin yalnizca uc deneme hakki verilir.

LoginGraceTime 30 ayarina ozellikle dikkat etmeni istiyorum. Varsayilan deger genellikle 120 saniye, bu da saldirgana her baglantida iki dakika kazandiriyor. 30 saniye, mesru bir kullanicinin kimligini dogrulamasi icin fazlasiyla yeterli.

2.2 Oturum ve Baglanti Guvenligi

Aktif oturumlarin guvenligini saglamak da en az kimlik dogrulama kadar onemli. Unutulmus oturumlar ve gereksiz yonlendirmeler saldiri yuzeyini genisletir -- ve bu genellikle gozden kacirilan bir nokta.

# Istemci canlilik kontrolu (5 dakikada bir sinyal gonder)
ClientAliveInterval 300

# 2 basarisiz canlilik kontrolunden sonra baglantiyi kes
ClientAliveCountMax 2

# Esitli baglanti sinirlamasi (rate limiting)
# 10 esitli baglantidan sonra %30 olasilikla red,
# 60 esitli baglantiyi asarsa tum yeni baglantilar reddedilir
MaxStartups 10:30:60

# X11 yonlendirmesini kapat (GUI gereksizse)
X11Forwarding no

# Agent yonlendirmesini kapat
AllowAgentForwarding no

# TCP yonlendirmesini kapat (tunel gereksizse)
AllowTcpForwarding no

# Yasal uyari banner'i
Banner /etc/ssh/banner

MaxStartups 10:30:60 ayari, SSH'in yerlesik hiz sinirlamasi mekanizmasi. Peki bu "10:30:60" ne anlama geliyor? Basitce soyle: ilk 10 kimlik dogrulanmamis baglanti kabul edilir, sonrasinda her yeni baglanti %30 olasilikla reddedilir ve bu oran esitli baglanti sayisi 60'a ulasana kadar dogrusal olarak artar. 60'i asinsa? Tum yeni baglantilar reddedilir. Brute-force saldirilarini onemli olcude yavaslatir.

Banner dosyasi icin basit bir yasal uyari olusturabilirsin:

sudo tee /etc/ssh/banner << 'EOF'
*******************************************************************
UYARI: Bu sistem yetkili kullanicilar icindir. Yetkisiz erisim
girisimleri kayit altina alinmakta ve yasal islem baslatilabilir.
Tum oturumlar izlenmekte ve kaydedilmektedir.
*******************************************************************
EOF

2.3 Port ve Ag Yapilandirmasi

SSH'in ag duzeyindeki yapilandirmasi, saldiri yuzeyini daraltmak icin onemli bir adim.

# Belirli bir IP adresinde dinle (tum arayuzler yerine)
ListenAddress 192.168.1.10

# Varsayilan portu degistir (detaylari asagida)
Port 2222

# Yalnizca IPv4 kullan (IPv6 gerekmiyorsa)
AddressFamily inet

Port degisikligi hakkinda onemli bir not: SSH portunu 22'den baska bir porta degistirmek, acikcasi gercek bir guvenlik onlemi degil. "Gizlilik yoluyla guvenlik" (security through obscurity) kategorisinde. Kararli bir saldirgan port taramasi ile yeni portu kolayca bulur. Ama su da var: otomatik tarama botlarinin buyuk cogunu filtreler ve log dosyalarindaki gurultuyu azaltir. Ben bunu "derinlemesine savunma" (defense-in-depth) stratejisinin kucuk ama faydali bir parcasi olarak goruyorum -- tek basina asla guvenme, ama diger onlemlerle birlikte ise yarar.

ListenAddress ayari ozellikle birden fazla ag arayuzune sahip sunucularda kritik. Ornegin, yonetim arayuzu ile uygulama arayuzu ayri ise, SSH'i yalnizca yonetim arayuzunde dinletmen gerekir.

2.4 Tam Uretim sshd_config Ornegi

Asagida, yukaridaki tum ayarlari birlestiren, uretim ortamina hazir kapsamli bir sshd_config dosyasi var. Bunu dogrudan kopyalayip kendi ortamina uyarlayabilirsin:

# =============================================================
# Uretim Ortami SSH Sikilastirma Yapilandirmasi
# Linux Secure Ops - 2026
# =============================================================

# --- Ag Yapilandirmasi ---
Port 2222
ListenAddress 192.168.1.10
AddressFamily inet
Protocol 2

# --- Kimlik Dogrulama ---
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
MaxSessions 3
LoginGraceTime 30

# --- Erisim Kontrolu ---
AllowGroups ssh-admins ssh-users
DenyUsers nobody

# --- Anahtar Gereksinimleri ---
RequiredRSASize 3072
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256

# --- Kriptografik Algoritmalar ---
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers [email protected],[email protected],[email protected],aes256-ctr
MACs [email protected],[email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

# --- Ana Bilgisayar Anahtarlari ---
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# --- Oturum Guvenligi ---
ClientAliveInterval 300
ClientAliveCountMax 2
MaxStartups 10:30:60

# --- Yonlendirme Kisitlamalari ---
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
PermitTunnel no

# --- Gunluk Kaydi ---
SyslogFacility AUTH
LogLevel VERBOSE

# --- Diger ---
Banner /etc/ssh/banner
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
Compression no
UseDNS no
PermitUserEnvironment no
StrictModes yes

Bu yapilandirmayi uygulamadan once mutlaka test et. Yoksa kendini sunucu disindan kilitlersin -- bunu zor yoldan ogrenen insanlar taniyorum (ve itiraf edeyim, bir keresinde neredeyse ben de o insanlardan biri oluyordum):

# Yapilandirma sozdizimini dogrula
sudo sshd -t

# Test modunda calistir (mevcut baglantiyi kesmeden)
sudo sshd -t -f /etc/ssh/sshd_config

# Degisiklikleri uygula
sudo systemctl reload sshd

# ONEMLI: Mevcut SSH oturumunuzu KAPATMADAN
# yeni bir terminalde baglanti test edin!
ssh -p 2222 kullanici@sunucu-ip

3. Kriptografik Algoritma Sikilastirma

Kriptografik algoritma secimi, SSH guvenliginin temelini olusturur. Yanlis veya zayif algoritmalarin kullanimi, tum diger sikilastirma onlemlerini gecersiz kilabilir. Simdi her algoritma kategorisini detaylica inceleyelim.

3.1 Anahtar Degisim Algoritmalari (KexAlgorithms)

Anahtar degisim algoritmalari, istemci ile sunucu arasindaki sifreleme anahtarlarinin guvenli bir sekilde olusturulmasini saglar. 2026 icin onerdigim yapilandirma su sekilde:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Algoritma Tur Guvenlik Durumu Oneri
mlkem768x25519-sha256 Post-kuantum hibrit NIST standardi, OpenSSH 10.0 varsayilan Birincil tercih
sntrup761x25519-sha512 Post-kuantum hibrit OpenSSH 9.0'dan beri mevcut Ikincil tercih
curve25519-sha256 Klasik eliptik egri Guvenli (kuantum oncesi) Uyumluluk icin
diffie-hellman-group16-sha512 Klasik DH (4096-bit) Guvenli Eski istemciler icin
diffie-hellman-group18-sha512 Klasik DH (8192-bit) Guvenli Yuksek guvenlik icin
ecdh-sha2-nistp256/384/521 NIST egrileri Suphelenilen arka kapi KACINILMALI
diffie-hellman-group14-sha256 Klasik DH (2048-bit) Yetersiz anahtar boyu KACINILMALI

NIST egrileri (nistp256, nistp384, nistp521) konusunda su an guvensizlik devam ediyor. Kriptografi toplulugundaki bir cok arastirmaci, bu egrilerin secim surecinde NSA'in etkisi olduguna dair supheleri dile getiriyor. Acikcasi bu tartisma kesin olarak cozulmedi ama "ihtiyatli olmak" prensibiyle hareket etmeni oneririm -- mumkunse curve25519 tabanli algoritmalari tercih et.

3.2 Sifreleme Algoritmalari (Ciphers)

Sifreleme algoritmalari, SSH oturumundaki verilerin gizliligini saglar:

Ciphers [email protected],[email protected],[email protected],aes256-ctr
  • chacha20-poly1305: Yazilim tabanli uygulamalarda en hizli ve en guvenli secenek. Ozellikle AES donanim hizlandirmasi (AES-NI) olmayan sistemlerde ideal. Zamanlama saldiriharina karsi dogal dirence sahip.
  • aes256-gcm / aes128-gcm: AES-NI destekli islemcilerde son derece hizli calisir. GCM modu hem sifreleme hem de kimlik dogrulama saglar (AEAD). Sunucularin buyuk cogunda bu tercih edilir.
  • aes256-ctr: Eski istemcilerle uyumluluk icin son cozum olarak listede bulunuyor.

Kacinilmasi gereken algoritmalar: CBC modundaki tum sifreleme algoritmalari (aes256-cbc, aes128-cbc, vb.) padding oracle saldiriharina karsi savunmasiz. Bunlari kesinlikle kullanma.

3.3 Mesaj Dogrulama Kodlari (MACs)

MAC'ler (Message Authentication Codes), iletilen verilerin butunlugunu ve orijinalligini dogrular:

MACs [email protected],[email protected],[email protected]

-etm (Encrypt-then-MAC) son eki kritik oneme sahip. Bu mod, once sifreleme sonra MAC hesaplamasi yapar ki bu kriptografik olarak kanitlanmis guvenli yontem. -etm olmayan varyantlar MAC-then-Encrypt kullanir ve teorik saldiriharina acik olabilir. Kucuk bir detay gibi gorunuyor ama fark buyuk.

Kacinilmasi gerekenler:

  • hmac-md5 ve turevleri -- MD5 carpisma saldiriharina karsi savunmasiz
  • 64-bit MAC'ler (umac-64) -- Yetersiz etiket uzunlugu
  • -etm olmayan varyantlar -- Zayif sifreleme modu sirasi

3.4 Ana Bilgisayar Anahtar Algoritmalari

Sunucu kimligini dogrulayan ana bilgisayar anahtarlarinin algoritma tercihi:

HostKeyAlgorithms ssh-ed25519,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256

# Yalnizca Ed25519 ve RSA anahtarlarini kullan
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
  • Ed25519: En yuksek oncelik. Kucuk anahtar boyutu (256-bit), yuksek performans ve guclu guvenlik. Modern tum istemciler tarafindan destekleniyor.
  • rsa-sha2-512: RSA kullanilmasi gerektiginde, en az 3072-bit anahtar boyutu ile rsa-sha2-512 imza algoritmasi kullanilmali. RequiredRSASize 3072 ayari bu alt siniri zorlar.
  • Kacinilmasi gerekenler: DSA (OpenSSH 10.0'da tamamen kaldirildi), ssh-rsa (SHA-1 tabanli -- carpisma saldiriharina acik)

Sunucunda henuz Ed25519 ana bilgisayar anahtari yoksa, su komutla olusturabilirsin:

# Ed25519 ana bilgisayar anahtari olustur
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

# Eski ECDSA ve DSA anahtarlarini kaldir
sudo rm -f /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ecdsa_key.pub
sudo rm -f /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_dsa_key.pub

# sshd'yi yeniden yukle
sudo systemctl reload sshd

4. Anahtar Tabanli Kimlik Dogrulama

4.1 Ed25519 Anahtar Olusturma

Ed25519, su an mevcut olan en guvenli ve en performansli SSH anahtar turu. Anahtar olusturma sureci de oldukca basit:

# Ed25519 anahtari olustur
ssh-keygen -t ed25519 -C "[email protected]"

# Olusturma sirasindaki cikti:
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (/home/kullanici/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase):
# Enter same passphrase again:

Parola (passphrase) belirleme zorunlulugu: Anahtar olustururken mutlaka guclu bir parola belirle. Parolasiz bir ozel anahtar, ele gecirildiginde dogrudan erisim saglar. Parola, anahtarin sifrelenerek diskte saklanmasini saglar ve ek bir guvenlik katmani ekler. Ideal bir parola en az 16 karakter uzunlugunda, rastgele kelimeler iceren bir cumle olmali.

# Acik anahtari sunucuya kopyala
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 kullanici@sunucu-ip

# Manuel olarak kopyalamak icin
cat ~/.ssh/id_ed25519.pub | ssh -p 2222 kullanici@sunucu-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Anahtar kopyalandiktan sonra, sunucuda PasswordAuthentication no ayarini uygula. Ben genellikle sunucu ilk kurulumunda anahtar kopyalama islemini hemen yapiyorum ve ardindan parola tabanli dogrulamayi kapamadan once ikinci bir SSH oturumu acarak anahtar ile girisi test ediyorum. Bu kuralimi hic bozmuyorum -- bir gun kurtaracagini biliyorum.

4.2 FIDO2 Donanim Anahtarlari ile SSH

FIDO2 uyumlu donanim guvenlik anahtarlari (YubiKey, SoloKey gibi), SSH guvenligini bir ust seviyeye tasiyor. Bu anahtarlarin en buyuk avantaji ne biliyor musun? Ozel anahtar asla donanim disina cikmiyor. Anahtar materyal, guvenlik anahtarinin icindeki ozel bir yongada olusturulur ve oradan hicbir zaman cikarilmaz.

# FIDO2 Ed25519 anahtar olusturma (resident + dogrulama gerekli)
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "[email protected] - YubiKey"

# Birden fazla anahtar icin ozel etiket
ssh-keygen -t ed25519-sk -O resident -O application=ssh:is-sunucusu -O verify-required -C "kullanici - Uretim Sunucusu"

Komuttaki seceneklerin aciklamasi:

  • -t ed25519-sk: Guvenlik anahtari destekli Ed25519 algoritmasini kullanir
  • -O resident: Anahtari guvenlik anahtarinin uzerinde saklar (kesfedilebilir kimlik bilgisi). Bu sayede anahtari farkli bilgisayarlarda kullanabilirsin
  • -O verify-required: Her kullanmda PIN girisi gerektirir (yalnizca dokunma degil). Calinan bir YubiKey bile PIN olmadan kullanilamaz

YubiKey gereksinimleri: Ed25519-sk destegi icin YubiKey firmware 5.2.3 veya ustu gerekli. Daha eski firmware surumleri yalnizca ecdsa-sk destekler. Ayrica, resident anahtar olusturmadan once YubiKey Manager ile bir FIDO2 PIN'i belirlemen gerekiyor.

# YubiKey'deki resident anahtarlari yeni bir makineye aktar
cd ~/.ssh
ssh-keygen -K

# Bu komut, YubiKey'deki tum resident SSH anahtarlarini indirir
# Indirilen dosyalar _rk soneki ile kaydedilir

FIDO2 anahtarlarinin en guclu yani, bellekteki ozel anahtarin dump edilmesi riskini tamamen ortadan kaldirmasi. Geleneksel SSH anahtarlarinda, ssh-agent calisirken ozel anahtar bellekte sifresiz olarak bulunur. FIDO2 ile bu mumkun degil -- her islem dogrudan donanim uzerinde gerceklesir.

4.3 SSH Sertifika Tabanli Kimlik Dogrulama

Buyuk olcekli ortamlarda (onlarca veya yuzlerce sunucu), her sunucuya tek tek acik anahtar kopyalamak yonetilmesi zor bir hal alir. Cidden, 50 sunucu ve 10 kullanici dusun -- 500 anahtar ekleme islemi. SSH sertifika altyapisi (SSH CA) bu sorunu cozuyor.

SSH CA'nin temel calisma prensibi: Bir Sertifika Yetkilisi (CA) anahtari olusturulur, kullanici anahtarlari bu CA tarafindan imzalanir, sunucular CA'nin acik anahtarina guvenecek sekilde yapilandirilir. Boylece her yeni kullanici anahtari CA tarafindan imzalandiginda, tum sunuculara otomatik olarak erisim saglanir.

# 1. SSH CA anahtari olustur (guvenli bir yerde saklanmali)
ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "SSH User CA"

# 2. Kullanici anahtarini imzala (1 gunluk gecerlilik suresi)
ssh-keygen -s /etc/ssh/ca/user_ca \
    -I "[email protected]" \
    -n kullanici,deployer \
    -V +1d \
    ~/.ssh/id_ed25519.pub

# Secenekler:
# -s: Imzalama icin kullanilacak CA anahtari
# -I: Sertifika kimligi (loglarda gorunur)
# -n: Gecerli kullanici adi/adlari (principals)
# -V: Gecerlilik suresi (+1d = 1 gun, +1w = 1 hafta)

# 3. Sunucuda CA'yi guvenilir olarak yapilandir
# /etc/ssh/sshd_config'e ekle:
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub

# 4. Olusturulan sertifikayi dogrula
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Kisa sureli sertifikalar otomasyon icin harika. CI/CD pipeline'larinda, her deployment icin birkac dakikalik gecerliligi olan sertifikalar olusturabilirsin. Suresi dolan bir sertifika otomatik olarak gecersiz hale gelir -- acik anahtar temizleme islemi gerektirmez. Ozellikle dinamik bulut ortamlarinda sunucularin gelip gittigi durumlarda bu yaklasim buyuk kolaylik sagliyor.

5. Fail2Ban ile Kaba Kuvvet Korumasi

Anahtar tabanli kimlik dogrulama aktif olsa bile, kaba kuvvet saldirilari sunucu kaynaklarini tuketir ve log dosyalarini kirletir. Fail2Ban, basarisiz giris denemelerini izler ve tekrarlayan IP adreslerini otomatik olarak engeller. Cekirdek sikilastirma rehberimizi okuduysaniz, bu aracin cekirdek duzeyindeki guvenlik onlemlerine ek olarak uygulama katmaninda nasil koruma sagladigini daha iyi anlayacaksiniz.

5.1 Kurulum ve Temel Yapilandirma

# Debian/Ubuntu icin kurulum
sudo apt update && sudo apt install fail2ban -y

# RHEL/Fedora icin kurulum
sudo dnf install epel-release -y
sudo dnf install fail2ban -y

# Servisi baslat ve etkinlestir
sudo systemctl enable --now fail2ban

Fail2Ban yapilandirmasi icin asla jail.conf dosyasini dogrudan duzenleme -- guncellemelerle uzerine yazilir. Bunun yerine jail.local dosyasi olustur:

# /etc/fail2ban/jail.local
[DEFAULT]
# nftables ile entegrasyon (sonraki bolumde detayli)
banaction = nftables-multiport
banaction_allports = nftables-allports
chain = input

# Varsayilan ban suresi: 1 saat
bantime = 1h
# Inceleme penceresi: 10 dakika
findtime = 10m
# Maksimum basarisiz deneme
maxretry = 3

# E-posta bildirimi (opsiyonel)
destemail = [email protected]
sender = [email protected]
action = %(action_mwl)s

[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
backend = systemd
maxretry = 3
bantime = 1h

5.2 Ileri Duzey SSH Jail Yapilandirmasi

Temel yapilandirma iyi bir baslangic, ama gercek dunya senaryolari daha agresif koruma gerektiriyor. Artan ban sureleri ve tekrarlayan suclu tespiti ozellikle etkili -- ve duzgun yapilandirildiginda neredeyse kendin icin calisan bir guvenlik gorevlisi gibi.

# /etc/fail2ban/jail.local - Ileri duzey yapilandirma

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports
chain = input

# Artan ban sureleri (bantime.increment)
bantime.increment = true
bantime.rndtime = 30m
bantime.maxtime = 4w
bantime.factor = 24
# Ban suresi katlayicisi:
# 1. ban: 1 saat
# 2. ban: 1 gun (1h * 24)
# 3. ban: 24 gun (1d * 24)
# 4. ban: 4 hafta (maksimum)

bantime = 1h
findtime = 10m
maxretry = 3

[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
backend = systemd
maxretry = 3
# Daha agresif mod: sadece 2 basarisiz deneme ile yasakla
# maxretry = 2
filter = sshd[mode=aggressive]

# Tekrarlayan suclular icin ozel jail
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = nftables-allports
bantime = 4w
findtime = 1d
maxretry = 3

filter = sshd[mode=aggressive] ayari, Fail2Ban'in daha fazla baglanti turunu suphe olarak degerlendirmesini saglar. Normal modda yalnizca basarisiz parola denemeleri sayilirken, agresif modda gercek kullaniciya ait olmayan kullanici adi denemeleri ve diger anormal giris kaliplari da sayilir.

[recidive] jail'i ise Fail2Ban'in kendi log dosyasini izler. Bir IP adresi farkli jail'lerde tekrar tekrar yasaklaniyorsa, bu IP'yi tum portlarda 4 haftaligina engeller. Israrci saldirganlar icin son derece etkili bir cozum.

5.3 nftables ile Fail2Ban Entegrasyonu

nftables rehberimizde detaylica ele aldigimiz gibi, nftables modern Linux dagitimlarinda iptables'in yerini aldigi icin Fail2Ban'i nftables ile entegre etmek artik sart.

# /etc/fail2ban/action.d/nftables-common.local
[Init]
# nftables tablo ailesi
nftables_family = inet
# Ozel tablo adi
nftables_table = fail2ban
# Engelleme turu: drop (sessiz) veya reject (bildirimli)
blocktype = drop

Fail2Ban nftables entegrasyonu, yasaklanan IP adreslerini bir nftables set'ine ekler. Bu yaklasim, her IP icin ayri bir kural eklemekten cok daha verimli. nftables set'leri hash tablo kullanir ve O(1) zamanda arama yapabilir -- yani binlerce yasakli IP olsa bile performans etkilenmez.

Fail2Ban'in nftables ile duzgun calistiginin garantisi icin systemd bagimliligi olusturmani oneririm:

# Fail2Ban'i nftables'a bagimli yap
sudo mkdir -p /etc/systemd/system/fail2ban.service.d/
sudo tee /etc/systemd/system/fail2ban.service.d/override.conf << 'EOF'
[Unit]
Requires=nftables.service
After=nftables.service
PartOf=nftables.service

[Install]
WantedBy=multi-user.target nftables.service
EOF

sudo systemctl daemon-reload
sudo systemctl restart fail2ban

# Engellenen IP'leri kontrol et
sudo nft list ruleset | grep -A 5 "fail2ban"

# Fail2Ban durumunu kontrol et
sudo fail2ban-client status sshd

6. ssh-audit ile Guvenlik Denetimi

Tum sikilastirma onlemlerini uyguladiktan sonra, yapilandirmanin gercekten guvenli oldugunu dogrulamak gerekiyor. Biliyorum, "ben dogru yaptim" diye dusunuyor olabilirsin ama bir dogrulama araci calistirmak her zaman iyi fikir. ssh-audit araci, SSH sunucunu kapsamli bir sekilde denetler ve zayif algoritmalari, bilinen guvenlik aciklari bulunan surumleri ve uyumsuz yapilandirmalari tespit eder.

# Kurulum yontemleri
# pip ile (en guncel surum)
pip3 install ssh-audit

# Debian/Ubuntu
sudo apt install ssh-audit

# RHEL/Fedora
sudo dnf install ssh-audit

# Docker ile
docker run --rm -it positronsecurity/ssh-audit sunucu-ip

# Temel denetim
ssh-audit sunucu-ip -p 2222

# Mevcut sikilastirma rehberlerini listele
ssh-audit --list-hardening-guides

# Belirli bir sistem icin sikilastirma rehberi al
ssh-audit --get-hardening-guide "Ubuntu 24.04 LTS (Server)"

# Politika denetimi (belirli bir standarda uyumlulugu kontrol et)
ssh-audit -P "Hardened Ubuntu 24.04 LTS (Server)" sunucu-ip -p 2222

Sikilastirma oncesi tipik ssh-audit ciktisi:

# ssh-audit sunucu-ip (SIKILASTIRMA ONCESI)
[0.1] banner: SSH-2.0-OpenSSH_9.6p1
[0.2] key exchange algorithms:
    (kex) curve25519-sha256                      -- [info] available since OpenSSH 7.4
    (kex) ecdh-sha2-nistp256                     -- [fail] using NIST curves
    (kex) diffie-hellman-group14-sha256          -- [warn] 2048-bit modulus
    (kex) diffie-hellman-group1-sha1             -- [fail] using broken SHA-1
[0.3] host-key algorithms:
    (key) ssh-rsa (3072-bit)                     -- [warn] using SHA-1 signature
    (key) ssh-dss (1024-bit)                     -- [fail] removed in OpenSSH 10.0
[0.4] encryption algorithms:
    (enc) aes128-cbc                             -- [fail] CBC mode vulnerability
    (enc) aes256-ctr                             -- [info] available since OpenSSH 3.7
[0.5] message authentication codes:
    (mac) hmac-md5                               -- [fail] using broken MD5
    (mac) hmac-sha1                              -- [fail] using broken SHA-1

# Genel Sonuc: BASARISIZ (4 fail, 2 warn)

Sikilastirma sonrasi ssh-audit ciktisi:

# ssh-audit sunucu-ip -p 2222 (SIKILASTIRMA SONRASI)
[0.1] banner: SSH-2.0-OpenSSH_10.1
[0.2] key exchange algorithms:
    (kex) mlkem768x25519-sha256                  -- [info] post-quantum hybrid
    (kex) sntrup761x25519-sha512                 -- [info] post-quantum hybrid
    (kex) curve25519-sha256                      -- [info] available since OpenSSH 7.4
    (kex) diffie-hellman-group16-sha512          -- [info] 4096-bit modulus
    (kex) diffie-hellman-group18-sha512          -- [info] 8192-bit modulus
[0.3] host-key algorithms:
    (key) ssh-ed25519                            -- [info] available since OpenSSH 6.5
    (key) rsa-sha2-512 (3072-bit)               -- [info] available since OpenSSH 7.2
[0.4] encryption algorithms:
    (enc) [email protected]          -- [info] available since OpenSSH 6.5
    (enc) [email protected]                 -- [info] available since OpenSSH 6.2
    (enc) [email protected]                 -- [info] available since OpenSSH 6.2
    (enc) aes256-ctr                             -- [info] available since OpenSSH 3.7
[0.5] message authentication codes:
    (mac) [email protected]          -- [info] available since OpenSSH 6.2
    (mac) [email protected]          -- [info] available since OpenSSH 6.2
    (mac) [email protected]               -- [info] available since OpenSSH 6.2

# Genel Sonuc: BASARILI (0 fail, 0 warn)

Her yapilandirma degisikliginden sonra ssh-audit calistirmani siddetle tavsiye ederim. Bu arac, gozden kacan zayif bir algoritma veya yanlis bir ayar icin erken uyari sistemi gibi calisir. Ben kendi sunucularimda her aylik bakim doneminde mutlaka bir ssh-audit taradi gerceklestiriyorum -- ve birden fazla kez beni kurtardigini soyleyebilirim.

7. Otomasyon ve Monitoring

7.1 Ansible ile SSH Sikilastirma Otomasyonu

Birden fazla sunucu yonetiyorsan, SSH sikilastirmasini manuel olarak her sunucuya uygulamak hem zaman alici hem de hata yapma ihtimalini artiriyor. Ansible, bu sureci otomatiklestirmek icin ideal bir arac. Haydi nasil yapilandirildigina bakalim:

# ssh_hardening.yml - Ansible Playbook
---
- name: SSH Sikilastirma Playbook'u
  hosts: all
  become: yes
  vars:
    ssh_port: 2222
    ssh_allowed_groups: "ssh-admins ssh-users"

  tasks:
    - name: OpenSSH'in en son surumde oldugunu dogrula
      ansible.builtin.package:
        name: openssh-server
        state: latest
      notify: Restart sshd

    - name: Sikilastirilmis sshd_config dosyasini dagit
      ansible.builtin.template:
        src: templates/sshd_config.j2
        dest: /etc/ssh/sshd_config
        owner: root
        group: root
        mode: '0600'
        validate: 'sshd -t -f %s'
      notify: Reload sshd

    - name: SSH banner dosyasini olustur
      ansible.builtin.copy:
        src: files/ssh_banner
        dest: /etc/ssh/banner
        owner: root
        group: root
        mode: '0644'

    - name: Ed25519 ana bilgisayar anahtarinin varligini dogrula
      ansible.builtin.command:
        cmd: ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
        creates: /etc/ssh/ssh_host_ed25519_key

    - name: Eski DSA ve ECDSA anahtarlarini kaldir
      ansible.builtin.file:
        path: "{{ item }}"
        state: absent
      loop:
        - /etc/ssh/ssh_host_dsa_key
        - /etc/ssh/ssh_host_dsa_key.pub
        - /etc/ssh/ssh_host_ecdsa_key
        - /etc/ssh/ssh_host_ecdsa_key.pub
      notify: Reload sshd

    - name: Fail2Ban'in kurulu ve aktif oldugunu dogrula
      ansible.builtin.package:
        name: fail2ban
        state: present

    - name: Fail2Ban jail.local yapilandirmasini dagit
      ansible.builtin.template:
        src: templates/jail.local.j2
        dest: /etc/fail2ban/jail.local
        owner: root
        group: root
        mode: '0644'
      notify: Restart fail2ban

    - name: ssh-audit ile dogrulama yap
      ansible.builtin.command:
        cmd: "ssh-audit -p {{ ssh_port }} localhost"
      register: ssh_audit_result
      changed_when: false
      failed_when: "'fail' in ssh_audit_result.stdout"

  handlers:
    - name: Reload sshd
      ansible.builtin.systemd:
        name: sshd
        state: reloaded

    - name: Restart sshd
      ansible.builtin.systemd:
        name: sshd
        state: restarted

    - name: Restart fail2ban
      ansible.builtin.systemd:
        name: fail2ban
        state: restarted

Bu playbook'un en guclu yani, validate: 'sshd -t -f %s' satiri. Ansible, yeni yapilandirma dosyasini dagitmadan once sshd sozdizim kontrolu yapar. Yapilandirmada bir hata varsa, dosya uygulanmaz ve seni sunucu disindan kilitlenmekten kurtarir. Kucuk bir detay ama hayat kurtarici.

7.2 Gunluk Izleme ve Uyari

SSH sikilastirmasi statik bir islem degil -- surekli izleme gerektiriyor. Basarisiz giris denemeleri, olagan disi erisim kaliplari ve potansiyel saldirilarin erken tespiti kritik oneme sahip. Iste kullanabilcegin bazi komutlar:

# Basarisiz SSH giris denemelerini gercek zamanli izle
sudo journalctl -u sshd -f --no-pager | grep -i "failed\|invalid\|error"

# Son 24 saatteki basarisiz denemelerin ozeti
sudo journalctl -u sshd --since "24 hours ago" | grep "Failed password" | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

# Basarili girisleri kontrol et (yetkisiz erisim arama)
sudo journalctl -u sshd --since "24 hours ago" | grep "Accepted"

# Belirli kaliplari arayin:
# Gecersiz kullanici denemeleri
sudo journalctl -u sshd --since "1 hour ago" | grep "Invalid user"

# Baglanti kopmalari (port tarama belirtisi)
sudo journalctl -u sshd --since "1 hour ago" | grep "Connection closed by.*\[preauth\]"

# Anahtar turleri istatistikleri
sudo journalctl -u sshd --since "7 days ago" | grep "Accepted publickey" | grep -oP 'ED25519|RSA|ECDSA' | sort | uniq -c

Otomatik uyari sistemi icin basit ama etkili bir betik olusturabilirsin:

#!/bin/bash
# /usr/local/bin/ssh-alert.sh
# Yuksek hacimli basarisiz denemeleri tespit et ve uyar

THRESHOLD=50
PERIOD="10 minutes ago"
ALERT_EMAIL="[email protected]"

FAILED_COUNT=$(journalctl -u sshd --since "$PERIOD" --no-pager | grep -c "Failed\|Invalid user")

if [ "$FAILED_COUNT" -gt "$THRESHOLD" ]; then
    TOP_IPS=$(journalctl -u sshd --since "$PERIOD" --no-pager | grep "Failed\|Invalid user" | grep -oP '\d+\.\d+\.\d+\.\d+' | sort | uniq -c | sort -rn | head -10)

    echo -e "UYARI: Son 10 dakikada $FAILED_COUNT basarisiz SSH giris denemesi tespit edildi.\n\nEn cok deneme yapan IP adresleri:\n$TOP_IPS" | mail -s "[SSH UYARI] Yuksek hacimli basarisiz giris denemesi" "$ALERT_EMAIL"
fi
# Betigi cron ile her 10 dakikada bir calistir
echo "*/10 * * * * root /usr/local/bin/ssh-alert.sh" | sudo tee /etc/cron.d/ssh-alert
sudo chmod 644 /etc/cron.d/ssh-alert

Merkezi gunluk kaydi onerisi: Uretim ortamlarinda, SSH loglarini rsyslog veya systemd-journal-remote ile merkezi bir log sunucusuna gondermenizi siddetle tavsiye ederim. Boylece bir sunucu ele gecirilse bile, saldirganin log dosyalarini silmesi merkezi kayitlari etkilemez. ELK Stack (Elasticsearch, Logstash, Kibana) veya Grafana Loki gibi cozumler, SSH loglarini gorsellestirmek ve anomali tespiti yapmak icin harika araclar.

Sikca Sorulan Sorular (SSS)

1. SSH portunu degistirmek gercekten guvenligi artirir mi?

Kisaca: Tek basina hayir, ama faydali olabilir. SSH portunu 22'den baska bir degere degistirmek, gercek bir guvenlik onlemi sayilmaz cunku bilgili bir saldirgan port taramasi ile yeni portu saniyeler icinde bulabilir. Ancak otomatik tarama botlarinin buyuk cogunlugu yalnizca port 22'yi hedefler. Port degisikligi, bu botlarin onemli bir kismini filtreler ve log dosyalarindaki gurultuyu onemli olcude azaltir. Ben bunu "derinlemesine savunma" stratejisinin kucuk ama yararli bir parcasi olarak goruyorum -- tek basina asla guvenme, ama diger onlemlerle birlikte uygulandiginda yuku hafifletir.

2. Fail2Ban, anahtar tabanli kimlik dogrulama kullanilsa bile gerekli mi?

Evet, kesinlikle. Anahtar tabanli kimlik dogrulama, basarili brute-force saldirilarini onler. Ama basarisiz denemeler sunucu kaynaklarini (CPU, bellek, bant genisligi, log alani) tuketmeye devam eder. Yogun bir brute-force saldirisi sshd'nin yeni baglantilara yanit verme suresini uzatabilir ve DoS etkisi yaratabilir. Fail2Ban, bu tip saldirganlari erken asamada engelleyerek sunucu kaynaklarini korur. Ayrica, yapilandirma hatalari veya gelecekteki guvenlik aciklari nedeniyle parola dogrulamasinin yanlislikla etkinlestirilmesi ihtimaline karsi ek bir guvenlik katmani saglar.

3. Post-kuantum SSH nedir ve neden onemlidir?

Post-kuantum SSH, kuantum bilgisayarlarin mevcut sifreleme algoritmalarini kiracak kadar gelismesi durumuna karsi hazirlanan kriptografik algoritmalari kullanir. Mevcut klasik algoritmalar (RSA, ECDSA, standart Diffie-Hellman), yeterince guclu bir kuantum bilgisayar tarafindan Shor algoritmasiyla kirilabirir. Ama asil endise verici olan "simdi yakala, sonra coz" (store now, decrypt later) saldiri modeli -- saldirganlar bugun sifrelenmis SSH trafigini kaydedip, gelecekte kuantum bilgisayarlarla cozebilir. Bu tehdidi bugunun sorunu haline getiriyor. OpenSSH 10.0'nin varsayilan olarak mlkem768x25519-sha256 hibrit algoritmaya gecmis olmasi, bu tehdide karsi proaktif bir savunma. Hibrit yaklasim, kuantum-guvenli ve klasik algorithmayi birlestiriyor, boylece her iki dunya icin de guvenlik sagliyor.

4. FIDO2 anahtarimi kaybedersem ne olur?

FIDO2 guvenlik anahtarlarinin kaybi ciddi bir durum cunku ozel anahtar materyali cihazin icinde saklanir ve cikarilmasi mumkun degil. Bu riski azaltmak icin su onlemleri al:

  • Yedek anahtar: Her zaman ikinci bir FIDO2 anahtari olustur ve her iki anahtarin da acik anahtarlarini sunuculara kaydet. YubiKey'in yedek anahtar satisi bu nedenle yaygindir.
  • Acil erisim mekanizmasi: Konsol erisimine sahip bir yonetici hesabi veya bulut saglayicinin konsol erisimi gibi alternatif bir giris yolu mutlaka bulunmali.
  • SSH sertifikalari: SSH CA kullaniyorsan, CA anahtari uzerinden yeni bir anahtar imzalayarak erisimi hizla yeniden saglayabilirsin.
  • Kurtarma kodlari: Bazi kurumsal yapilandirmalarda, ozel olarak olusturulmus tek kullanimlik kurtarma kodlari ile acil erisim mumkun.

5. SSH sertifikalari ile SSH anahtarlari arasindaki fark nedir?

Standart SSH anahtarlarinda, her kullanicinin acik anahtari her sunucunun authorized_keys dosyasina tek tek eklenir. 10 kullanici ve 50 sunucu icin bu, 500 anahtar ekleme islemi demek. SSH sertifikalari ise merkezi bir yetkilendirme modeli sunar: bir Sertifika Yetkilisi (CA) anahtari olusturulur, sunucular bu CA'ya guvenir, ve CA tarafindan imzalanan herhangi bir kullanici anahtari otomatik olarak tum sunuculara erisim kazanir. Sertifikalarin en buyuk avantaji zaman sinirlamasi icermeleri -- suresi dolmus bir sertifika otomatik olarak gecersiz olur. Calisandan ayrilan birinin erisimini iptal etmek, tek tek sunucularda anahtar aramaktan cok daha kolay hale gelir. Ayrica sertifikalar, kullanici adi, sunucu kisitlamalari ve zorlanmis komutlar gibi ek meta veriler icerebilir.

Sonuc

SSH sikilastirmasi, tek seferlik bir islem degil, surekli bir surec. Bu makalede ele aldigimiz onlemleri ozetlersek:

  1. Surum yonetimi: OpenSSH'i guncel tut, otomatik guvenlik guncellemelerini yapilandir
  2. sshd_config sikilastirmasi: Root girisini kapat, parola dogrulamasini devre disi birak, hiz sinirlamasi uygula
  3. Kriptografik sikilastirma: Post-kuantum algoritmalari onceliklendir, zayif algoritmalari kaldir
  4. Anahtar yonetimi: Ed25519 kullan, mumkunse FIDO2 donanim anahtarlarina gec, buyuk ortamlar icin SSH sertifikalarini degerlendir
  5. Kaba kuvvet korumasi: Fail2Ban'i nftables entegrasyonu ile yapilandir
  6. Duzenli denetim: Her degisiklikten sonra ssh-audit calistir
  7. Surekli izleme: Log analizi ve uyari mekanizmalari kur

Bu onlemleri cekirdek sikilastirma rehberimiz ve nftables rehberimiz ile birlestirdiginizde, sunuculariniz icin kapsamli ve katmanli bir guvenlik mimarisi olusturmus olacaksiniz. Unutmayin: guvenlik bir hedef degil, bir yolculuk.

Sikilastirma islemlerini tamamladiktan sonra, benim yaptigim gibi her ay duzenli ssh-audit taramalari planla. Guvenlik durumunun zamanla bozulmadigından emin olmak, sana ileride bircok bas agrisindan kurtaracak. Guvenli gunler dilerim!

Yazar Hakkında Editorial Team

Our team of expert writers and editors.

İlgili Makaleler