Merhaba değerli WMForum üyeleri,
Sunucu güvenliği kategorisinin hakkını vermek ve forumda gerçekten işe yarar, kopyala-yapıştır çözümlerden ziyade mantığını kavratan kalıcı bir kaynak oluşturmak istedim. Özellikle web projelerimizde sıklıkla kullandığımız WHM/cPanel altyapıları, PHP tabanlı uygulamalar ve MySQL / SQL Server veritabanı sistemleri üzerinde tam izolasyon ve güvenlik sağlamak için adım adım neler yapmamız gerektiğini bu devasa rehberde topladım.
Bir sunucuyu yayına almadan önce ve yayın sırasında yaşanabilecek kriz anlarında uyguladığım uçtan uca "Hardening" (Sertleştirme) ve Log Analizi prosedürleri aşağıdadır. Çayınızı, kahvenizi alın; uzun ve teknik bir yolculuğa çıkıyoruz.
BÖLÜM 1: İŞLETİM SİSTEMİ VE SSH ERİŞİM GÜVENLİĞİ
Her şeyin başı, sunucunun kapısı olan SSH'ı güvene almaktır. Varsayılan ayarları kullanan bir sunucu, botnetlerin ve brute-force (kaba kuvvet) saldırılarının açık hedefidir.
1.1. Varsayılan SSH Portunu Değiştirme
Botların %99'u standart olarak 22 numaralı porta saldırır. Bunu değiştirmek, gereksiz log kirliliğini ve CPU tüketimini anında keser.
/etc/ssh/sshd_config dosyasını favori editörünüzle açın:
Bash
nano /etc/ssh/sshd_config
Aşağıdaki satırı bulun ve 1024 ile 65535 arasında kullanılmayan bir port ile değiştirin:
Port 22 -> Port 48592 (Örnek)
1.2. Root Girişini Doğrudan Kapatmak
Sunucuya asla doğrudan root olarak girmemelisiniz. Sınırlı yetkilere sahip bir kullanıcı oluşturup, gerektiğinde su - komutu ile root yetkisine geçiş yapılmalıdır.
Yine sshd_config dosyası içinde:
PermitRootLogin yes satırını PermitRootLogin no olarak güncelleyin.
1.3. Şifreli Girişi Kapatıp SSH Anahtarı (Public/Private Key) Kullanmak
Şifreler kırılabilir, ancak 4096-bit RSA anahtarlarını kırmak günümüz teknolojisiyle imkansıza yakındır.
Bilgisayarınızda (Windows kullanıyorsanız PuTTYgen ile veya terminalden ssh-keygen -t rsa -b 4096 komutuyla) bir anahtar çifti oluşturun. Public key'i sunucuda ~/.ssh/authorized_keys dosyasına ekleyin.
Ardından sshd_config dosyasında şu ayarları yapın:
Bash
PasswordAuthentication no
PubkeyAuthentication yes
Değişikliklerin aktif olması için SSH servisini yeniden başlatın: systemctl restart sshd
BÖLÜM 2: WHM / cPANEL VE GÜVENLİK DUVARI (FIREWALL) SERTLEŞTİRMESİ
Panel kullanan sistemlerde güvenlik, panelin sağladığı araçları doğru konfigüre etmekten geçer.
2.1. ConfigServer Security & Firewall (CSF) Mimarisi
Yeni kurulan bir WHM sunucusunda ilk yapılacak işlem CSF kurmaktır. Sadece kurmak yetmez, yapılandırmak şarttır.
/etc/csf/csf.conf dosyasında şu kritik ayarları yapın:
TESTING = "0": Kurulumdan sonra test modunu kapatın, yoksa firewall çalışmaz.
RESTRICT_SYSLOG = "3": Sunucudaki standart kullanıcıların sistem loglarını okumasını engeller. Çok kritik bir izolasyon adımıdır.
LF_SCRIPT_ALERT = "1": Eğer bir PHP scripti üzerinden toplu mail (spam) çıkışı tespit edilirse sizi uyarır.
PT_USERMEM = "512" ve PT_USERTIME = "1800": Bir kullanıcının gereğinden fazla RAM ve işlemci zamanı tüketmesi durumunda süreci sonlandırır. (Sürekli askıda kalan işlemleri temizler).
2.2. Port Kısıtlamaları (IPv4 Port Settings)
Sadece ihtiyacınız olan portları açık tutun.
TCP_IN ve TCP_OUT değerlerini minimize edin. Örneğin SSH portunuzu değiştirdiyseniz (örn: 48592), bunu TCP_IN'e eklemeyi unutmayın, aksi takdirde dışarıda kalırsınız. Veritabanı portlarını (MySQL için 3306, SQL Server kullanıyorsanız 1433) dışarıya (TCP_IN) asla açmayın. Veritabanı bağlantıları sadece localhost (127.0.0.1) üzerinden olmalıdır. Eğer uzaktan veritabanı yönetimi yapacaksanız, kendi IP adresinizi CSF üzerinden csf -a IP_ADRESINIZ şeklinde beyaz listeye alın.
2.3. cPHulk Brute Force Protection
WHM içinde "cPHulk" mutlaka aktif edilmelidir. Özellikle cPanel arayüzüne, FTP'ye ve e-posta (IMAP/POP3) hesaplarına yapılan şifre deneme saldırılarını bloklar.
Configuration Settings: "IP Address-based Protection" kısmında hatalı giriş limitini maksimum 5 olarak belirleyin ve IP'yi 1 gün boyunca banlayacak şekilde ayarlayın.
2.4. CageFS (CloudLinux) İle Kullanıcı İzolasyonu
Eğer sunucunuzda birden fazla proje veya müşteri barındırıyorsanız, CloudLinux ve CageFS hayat kurtarır. CageFS, her bir cPanel kullanıcısını kendi sanal kafesine koyar. Bir sitede açık bulunup hacklense bile, saldırgan diğer sitelerin dosyalarına veya sunucunun kök dizinlerine erişemez. Sembolik link (Symlink) saldırılarına karşı en kesin çözümdür.
BÖLÜM 3: UYGULAMA KATMANI VE PHP GÜVENLİĞİ
Web tabanlı saldırıların büyük bir kısmı uygulama katmanından, özellikle zayıf yazılmış kodlardan veya güncellenmemiş eklentilerden gelir.
3.1. php.ini Sertleştirmesi (MultiPHP INI Editor)
Sisteminizdeki tüm PHP versiyonları için şu fonksiyonları devre dışı bırakmak (disable_functions) büyük bir güvenlik bariyeri oluşturur. Eğer özel bir yazılımınız bu fonksiyonları zorunlu kılmıyorsa, mutlaka kapatın:
Ini, TOML
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
Not: curl_exec e-ticaret sitelerinde sanal pos entegrasyonları (XML/SOAP istekleri) için gerekebilir, projenizin yapısına göre curl_exec'i bu listeden çıkarabilirsiniz.
Diğer Kritik php.ini Ayarları:
expose_php = Off: Sunucunun header (başlık) bilgilerinde PHP versiyonunu gizler. Saldırganın sunucudaki PHP sürümünün zafiyetlerini araştırmasını engeller.
display_errors = Off: Canlı ortamda (Production) hatalar asla ekrana basılmamalıdır. Hatalar ekrana basılırsa, SQL tablolarınızın yapısı veya dosya yollarınız ifşa olur. Bunun yerine log_errors = On yapın.
open_basedir: Bu ayar, PHP'nin sadece belirtilen dizinlerdeki dosyaları çalıştırabilmesini sağlar. Kullanıcı kendi ana dizini (public_html) dışına çıkamaz.
3.2. ModSecurity Kurulumu ve OWASP Kuralları
ModSecurity bir Web Application Firewall (WAF) aracıdır. Özellikle SQL Injection (SQLi), Cross-Site Scripting (XSS) ve Local File Inclusion (LFI) saldırılarını ağ katmanında engeller.
WHM üzerinden "ModSecurity Vendors" bölümünden OWASP (Open Web Application Security Project) kural setini kurun ve aktif edin.
İpucu: OWASP kuralları bazen çok agresif olabilir ve masum istekleri (False Positive) engelleyebilir. Eğer sitenizde bir işlem yaparken 403 Forbidden hatası alırsanız, kural ID'sini tespit edip sadece o projeye veya o kurala özel bir istisna (whitelist) tanımlamanız gerekebilir.
BÖLÜM 4: VERİTABANI GÜVENLİĞİ VE OPTİMİZASYONU
Veritabanları, projelerimizin kalbidir. Müşteri verileri, siparişler ve sistem konfigürasyonları burada yaşar.
4.1. MySQL / MariaDB Güvenliği
İlk kurulumun ardından mutlaka mysql_secure_installation komutunu çalıştırın. Bu sihirbaz:
Root şifresini belirler.
Anonim kullanıcıları siler.
Root kullanıcısının uzaktan girişini kapatır (Disallow root login remotely).
Test veritabanlarını siler.
Bind Address: Veritabanınız sadece aynı sunucudaki web uygulamasından istek alıyorsa, /etc/my.cnf (veya /etc/mysql/my.cnf) dosyasına şu satırı ekleyerek dışarıdan gelecek tüm bağlantıları reddedin:
bind-address = 127.0.0.1
4.2. SQL Server (MSSQL) Barındıranlar İçin Ekstra Önlemler
Eğer C# tabanlı projeleriniz için Windows Server üzerinde SQL Server barındırıyorsanız:
Port Gizleme: Varsayılan 1433 portunu SQL Server Configuration Manager üzerinden değiştirin.
SQL Server Browser Hizmeti: Eğer mecbur değilseniz SQL Server Browser hizmetini durdurun ve devre dışı bırakın. Bu hizmet, ağ üzerinde SQL Server instance'larının görünürlüğünü sağlar, ki bu dışarıdan bir sunucu için istenmeyen bir durumdur.
Sa (System Administrator) Hesabı: sa hesabını devre dışı bırakın (Disable) veya adını değiştirin. Uygulamalarınız için sadece o uygulamanın veritabanına yetkili, sınırlı haklara sahip (db_datareader, db_datawriter) özel SQL kullanıcıları tanımlayın. db_owner yetkisini gereksiz yere hiçbir uygulamaya vermeyin.
BÖLÜM 5: LOG OKUMA, OLAY ANALİZİ VE HATA AYIKLAMA (TROUBLESHOOTING)
Güvenliği sağladık, ancak bir şeyler ters gittiğinde sorunun kaynağını nasıl bulacağız? İyi bir sistem yöneticisi ile acemi birini ayıran en önemli fark, log okuma yeteneğidir.
5.1. 500 Internal Server Error ve Apache Logları
Ekranda "500 Internal Server Error" gördüğünüzde, sorunun kaynağı %99 ihtimalle ya yanlış yapılandırılmış bir .htaccess dosyasıdır, ya yetki (CHMOD) problemidir, ya da PHP tabanlı kritik bir fatal error'dur.
Sorunu ezbere çözmek yerine doğrudan loglara bakın:
Bash
tail -f /usr/local/apache/logs/error_log
veya belirli bir kullanıcı için:
Bash
tail -f /home/kullaniciadi/logs/kullaniciadi.com-error_log
Eğer loglarda SoftException in Application.cpp veya Directory is writable by others hatası görüyorsanız, dosya izinleriniz yanlıştır.
Çözüm:
Klasörler için 755, dosyalar için 644 izni verilmelidir:
Bash
find /home/kullaniciadi/public_html -type d -exec chmod 755 {} \;
find /home/kullaniciadi/public_html -type f -exec chmod 644 {} \;
5.2. Veritabanı Darboğazı: MySQL Slow Query Log Kullanımı
Eğer sunucunuzun CPU yükü (Load Average) aniden fırlıyorsa ve siteleriniz yavaşlıyorsa, suçlu genellikle indekslenmemiş veya kötü yazılmış veritabanı sorgularıdır.
my.cnf dosyasına şu satırları ekleyerek yavaş sorguları kayıt altına alın:
Ini, TOML
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
Bu ayar, 2 saniyeden uzun süren her sorguyu kaydeder. Daha sonra log dosyasını inceleyerek hangi sitenin/sorgunun sistemi kastığını nokta atışı bulabilir ve o tabloya INDEX ekleyerek sorunu kökten çözebilirsiniz.
5.3. SSH ve Sistem Yetkilendirme Logları
Birisi sunucunuza girmeye mi çalışıyor? Veya başarılı bir giriş mi yaptı?
CentOS/RHEL sistemlerde: tail -f /var/log/secure
Ubuntu/Debian sistemlerde: tail -f /var/log/auth.log
Bu dosyada Failed password for root şeklinde binlerce satır görüyorsanız, Brute-Force altındasınız demektir. Fail2Ban veya CSF bu aşamada devreye girip o IP'leri bloklamalıdır. Eğer Accepted password veya Accepted publickey yazan ve size ait olmayan bir IP görüyorsanız, sunucunuz ihlal edilmiştir; anında şifreleri değiştirmeli ve sistemi karantinaya almalısınız.
5.4. Zararlı Yazılım (Malware) Tespiti ve Temizliği
Sunucuya bulaşan bir virüs genellikle .php uzantılı base64 ile şifrelenmiş (obfuscated) kod blokları olarak kendini gizler.
En temel terminal komutuyla son 7 günde değiştirilen şüpheli dosyaları bulmak için:
Bash
find /home//public_html -type f -name ".php" -mtime -7
Ancak manuel arama yeterli değildir. Sunucunuzda mutlaka Imunify360 (bütçe varsa) veya ClamAV / Maldet (Linux Malware Detect) (ücretsiz alternatifler) bulunmalıdır.
Maldet kurulumu sonrası tüm sunucuyu taramak için:
Bash
maldet -a /home/?/public_html
BÖLÜM 6: YEDEKLEME VE FELAKET KURTARMA MİMARİSİ (DISASTER RECOVERY)
Sisteminiz ne kadar güvenli olursa olsun, donanımsal arızalara veya sıfırıncı gün (Zero-Day) açıklarına karşı %100 güvende değilsinizdir. Tek geçerli güvenlik önlemi: Çalışan, test edilmiş, harici bir yedektir.
6.1. 3-2-1 Yedekleme Kuralı
3 adet kopyanız olmalı (1 Orijinal veri, 2 Yedek).
2 farklı medya/depolama türünde tutulmalı.
1 kopya mutlaka sunucu dışında (Off-site, örneğin farklı bir kıtadaki bulut depolamada) olmalı.
WHM üzerinde varsayılan "Backup" aracını kullanarak yedeklerinizi Amazon S3, Google Drive veya harici bir FTP/Rsync sunucusuna yönlendirin. Sadece lokal (/backup dizini) yedek almak, diskin yanması durumunda hiçbir işe yaramaz. Ayrıca, veritabanı yedeklerinizin (SQL dump) eksiksiz alındığından emin olun, gerekirse cron job ile özel mysqldump betikleri yazın.
ÖZET VE SONUÇ
Sunucu yönetimi, "kur ve unut" mantığıyla yürümez. Canlı bir organizma gibidir, sürekli izlenmeli, güncellemeleri yapılmalı (kernel güncellemeleri dahil) ve logları takip edilmelidir.
Burada anlattığım adımlar; port güvenliğinden kullanıcı izolasyonuna, log takibinden felaket kurtarma senaryolarına kadar profesyonel bir altyapının temelini oluşturur.
Umarım bu rehber, sunucu yapılandırması aşamasında olan veya sorunlarının kaynağını loglarda arayan arkadaşlara kalıcı bir referans olur.
Sizler sunucularınızda, özellikle veritabanı yavaşlıklarını tespit ederken veya panel güvenliğini sağlarken burada bahsettiklerimin dışında hangi özel toolları (örn: htop, nmon, iotop vb.) veya metotları kullanıyorsunuz? Yorumlarda buluşalım, konuyu daha da derinleştirelim!
(Faydalı olması dileğiyle, herkese iyi forumlar!)
Sunucu güvenliği kategorisinin hakkını vermek ve forumda gerçekten işe yarar, kopyala-yapıştır çözümlerden ziyade mantığını kavratan kalıcı bir kaynak oluşturmak istedim. Özellikle web projelerimizde sıklıkla kullandığımız WHM/cPanel altyapıları, PHP tabanlı uygulamalar ve MySQL / SQL Server veritabanı sistemleri üzerinde tam izolasyon ve güvenlik sağlamak için adım adım neler yapmamız gerektiğini bu devasa rehberde topladım.
Bir sunucuyu yayına almadan önce ve yayın sırasında yaşanabilecek kriz anlarında uyguladığım uçtan uca "Hardening" (Sertleştirme) ve Log Analizi prosedürleri aşağıdadır. Çayınızı, kahvenizi alın; uzun ve teknik bir yolculuğa çıkıyoruz.
BÖLÜM 1: İŞLETİM SİSTEMİ VE SSH ERİŞİM GÜVENLİĞİ
Her şeyin başı, sunucunun kapısı olan SSH'ı güvene almaktır. Varsayılan ayarları kullanan bir sunucu, botnetlerin ve brute-force (kaba kuvvet) saldırılarının açık hedefidir.
1.1. Varsayılan SSH Portunu Değiştirme
Botların %99'u standart olarak 22 numaralı porta saldırır. Bunu değiştirmek, gereksiz log kirliliğini ve CPU tüketimini anında keser.
/etc/ssh/sshd_config dosyasını favori editörünüzle açın:
Bash
nano /etc/ssh/sshd_config
Aşağıdaki satırı bulun ve 1024 ile 65535 arasında kullanılmayan bir port ile değiştirin:
Port 22 -> Port 48592 (Örnek)
1.2. Root Girişini Doğrudan Kapatmak
Sunucuya asla doğrudan root olarak girmemelisiniz. Sınırlı yetkilere sahip bir kullanıcı oluşturup, gerektiğinde su - komutu ile root yetkisine geçiş yapılmalıdır.
Yine sshd_config dosyası içinde:
PermitRootLogin yes satırını PermitRootLogin no olarak güncelleyin.
1.3. Şifreli Girişi Kapatıp SSH Anahtarı (Public/Private Key) Kullanmak
Şifreler kırılabilir, ancak 4096-bit RSA anahtarlarını kırmak günümüz teknolojisiyle imkansıza yakındır.
Bilgisayarınızda (Windows kullanıyorsanız PuTTYgen ile veya terminalden ssh-keygen -t rsa -b 4096 komutuyla) bir anahtar çifti oluşturun. Public key'i sunucuda ~/.ssh/authorized_keys dosyasına ekleyin.
Ardından sshd_config dosyasında şu ayarları yapın:
Bash
PasswordAuthentication no
PubkeyAuthentication yes
Değişikliklerin aktif olması için SSH servisini yeniden başlatın: systemctl restart sshd
BÖLÜM 2: WHM / cPANEL VE GÜVENLİK DUVARI (FIREWALL) SERTLEŞTİRMESİ
Panel kullanan sistemlerde güvenlik, panelin sağladığı araçları doğru konfigüre etmekten geçer.
2.1. ConfigServer Security & Firewall (CSF) Mimarisi
Yeni kurulan bir WHM sunucusunda ilk yapılacak işlem CSF kurmaktır. Sadece kurmak yetmez, yapılandırmak şarttır.
/etc/csf/csf.conf dosyasında şu kritik ayarları yapın:
TESTING = "0": Kurulumdan sonra test modunu kapatın, yoksa firewall çalışmaz.
RESTRICT_SYSLOG = "3": Sunucudaki standart kullanıcıların sistem loglarını okumasını engeller. Çok kritik bir izolasyon adımıdır.
LF_SCRIPT_ALERT = "1": Eğer bir PHP scripti üzerinden toplu mail (spam) çıkışı tespit edilirse sizi uyarır.
PT_USERMEM = "512" ve PT_USERTIME = "1800": Bir kullanıcının gereğinden fazla RAM ve işlemci zamanı tüketmesi durumunda süreci sonlandırır. (Sürekli askıda kalan işlemleri temizler).
2.2. Port Kısıtlamaları (IPv4 Port Settings)
Sadece ihtiyacınız olan portları açık tutun.
TCP_IN ve TCP_OUT değerlerini minimize edin. Örneğin SSH portunuzu değiştirdiyseniz (örn: 48592), bunu TCP_IN'e eklemeyi unutmayın, aksi takdirde dışarıda kalırsınız. Veritabanı portlarını (MySQL için 3306, SQL Server kullanıyorsanız 1433) dışarıya (TCP_IN) asla açmayın. Veritabanı bağlantıları sadece localhost (127.0.0.1) üzerinden olmalıdır. Eğer uzaktan veritabanı yönetimi yapacaksanız, kendi IP adresinizi CSF üzerinden csf -a IP_ADRESINIZ şeklinde beyaz listeye alın.
2.3. cPHulk Brute Force Protection
WHM içinde "cPHulk" mutlaka aktif edilmelidir. Özellikle cPanel arayüzüne, FTP'ye ve e-posta (IMAP/POP3) hesaplarına yapılan şifre deneme saldırılarını bloklar.
Configuration Settings: "IP Address-based Protection" kısmında hatalı giriş limitini maksimum 5 olarak belirleyin ve IP'yi 1 gün boyunca banlayacak şekilde ayarlayın.
2.4. CageFS (CloudLinux) İle Kullanıcı İzolasyonu
Eğer sunucunuzda birden fazla proje veya müşteri barındırıyorsanız, CloudLinux ve CageFS hayat kurtarır. CageFS, her bir cPanel kullanıcısını kendi sanal kafesine koyar. Bir sitede açık bulunup hacklense bile, saldırgan diğer sitelerin dosyalarına veya sunucunun kök dizinlerine erişemez. Sembolik link (Symlink) saldırılarına karşı en kesin çözümdür.
BÖLÜM 3: UYGULAMA KATMANI VE PHP GÜVENLİĞİ
Web tabanlı saldırıların büyük bir kısmı uygulama katmanından, özellikle zayıf yazılmış kodlardan veya güncellenmemiş eklentilerden gelir.
3.1. php.ini Sertleştirmesi (MultiPHP INI Editor)
Sisteminizdeki tüm PHP versiyonları için şu fonksiyonları devre dışı bırakmak (disable_functions) büyük bir güvenlik bariyeri oluşturur. Eğer özel bir yazılımınız bu fonksiyonları zorunlu kılmıyorsa, mutlaka kapatın:
Ini, TOML
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
Not: curl_exec e-ticaret sitelerinde sanal pos entegrasyonları (XML/SOAP istekleri) için gerekebilir, projenizin yapısına göre curl_exec'i bu listeden çıkarabilirsiniz.
Diğer Kritik php.ini Ayarları:
expose_php = Off: Sunucunun header (başlık) bilgilerinde PHP versiyonunu gizler. Saldırganın sunucudaki PHP sürümünün zafiyetlerini araştırmasını engeller.
display_errors = Off: Canlı ortamda (Production) hatalar asla ekrana basılmamalıdır. Hatalar ekrana basılırsa, SQL tablolarınızın yapısı veya dosya yollarınız ifşa olur. Bunun yerine log_errors = On yapın.
open_basedir: Bu ayar, PHP'nin sadece belirtilen dizinlerdeki dosyaları çalıştırabilmesini sağlar. Kullanıcı kendi ana dizini (public_html) dışına çıkamaz.
3.2. ModSecurity Kurulumu ve OWASP Kuralları
ModSecurity bir Web Application Firewall (WAF) aracıdır. Özellikle SQL Injection (SQLi), Cross-Site Scripting (XSS) ve Local File Inclusion (LFI) saldırılarını ağ katmanında engeller.
WHM üzerinden "ModSecurity Vendors" bölümünden OWASP (Open Web Application Security Project) kural setini kurun ve aktif edin.
İpucu: OWASP kuralları bazen çok agresif olabilir ve masum istekleri (False Positive) engelleyebilir. Eğer sitenizde bir işlem yaparken 403 Forbidden hatası alırsanız, kural ID'sini tespit edip sadece o projeye veya o kurala özel bir istisna (whitelist) tanımlamanız gerekebilir.
BÖLÜM 4: VERİTABANI GÜVENLİĞİ VE OPTİMİZASYONU
Veritabanları, projelerimizin kalbidir. Müşteri verileri, siparişler ve sistem konfigürasyonları burada yaşar.
4.1. MySQL / MariaDB Güvenliği
İlk kurulumun ardından mutlaka mysql_secure_installation komutunu çalıştırın. Bu sihirbaz:
Root şifresini belirler.
Anonim kullanıcıları siler.
Root kullanıcısının uzaktan girişini kapatır (Disallow root login remotely).
Test veritabanlarını siler.
Bind Address: Veritabanınız sadece aynı sunucudaki web uygulamasından istek alıyorsa, /etc/my.cnf (veya /etc/mysql/my.cnf) dosyasına şu satırı ekleyerek dışarıdan gelecek tüm bağlantıları reddedin:
bind-address = 127.0.0.1
4.2. SQL Server (MSSQL) Barındıranlar İçin Ekstra Önlemler
Eğer C# tabanlı projeleriniz için Windows Server üzerinde SQL Server barındırıyorsanız:
Port Gizleme: Varsayılan 1433 portunu SQL Server Configuration Manager üzerinden değiştirin.
SQL Server Browser Hizmeti: Eğer mecbur değilseniz SQL Server Browser hizmetini durdurun ve devre dışı bırakın. Bu hizmet, ağ üzerinde SQL Server instance'larının görünürlüğünü sağlar, ki bu dışarıdan bir sunucu için istenmeyen bir durumdur.
Sa (System Administrator) Hesabı: sa hesabını devre dışı bırakın (Disable) veya adını değiştirin. Uygulamalarınız için sadece o uygulamanın veritabanına yetkili, sınırlı haklara sahip (db_datareader, db_datawriter) özel SQL kullanıcıları tanımlayın. db_owner yetkisini gereksiz yere hiçbir uygulamaya vermeyin.
BÖLÜM 5: LOG OKUMA, OLAY ANALİZİ VE HATA AYIKLAMA (TROUBLESHOOTING)
Güvenliği sağladık, ancak bir şeyler ters gittiğinde sorunun kaynağını nasıl bulacağız? İyi bir sistem yöneticisi ile acemi birini ayıran en önemli fark, log okuma yeteneğidir.
5.1. 500 Internal Server Error ve Apache Logları
Ekranda "500 Internal Server Error" gördüğünüzde, sorunun kaynağı %99 ihtimalle ya yanlış yapılandırılmış bir .htaccess dosyasıdır, ya yetki (CHMOD) problemidir, ya da PHP tabanlı kritik bir fatal error'dur.
Sorunu ezbere çözmek yerine doğrudan loglara bakın:
Bash
tail -f /usr/local/apache/logs/error_log
veya belirli bir kullanıcı için:
Bash
tail -f /home/kullaniciadi/logs/kullaniciadi.com-error_log
Eğer loglarda SoftException in Application.cpp veya Directory is writable by others hatası görüyorsanız, dosya izinleriniz yanlıştır.
Çözüm:
Klasörler için 755, dosyalar için 644 izni verilmelidir:
Bash
find /home/kullaniciadi/public_html -type d -exec chmod 755 {} \;
find /home/kullaniciadi/public_html -type f -exec chmod 644 {} \;
5.2. Veritabanı Darboğazı: MySQL Slow Query Log Kullanımı
Eğer sunucunuzun CPU yükü (Load Average) aniden fırlıyorsa ve siteleriniz yavaşlıyorsa, suçlu genellikle indekslenmemiş veya kötü yazılmış veritabanı sorgularıdır.
my.cnf dosyasına şu satırları ekleyerek yavaş sorguları kayıt altına alın:
Ini, TOML
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
Bu ayar, 2 saniyeden uzun süren her sorguyu kaydeder. Daha sonra log dosyasını inceleyerek hangi sitenin/sorgunun sistemi kastığını nokta atışı bulabilir ve o tabloya INDEX ekleyerek sorunu kökten çözebilirsiniz.
5.3. SSH ve Sistem Yetkilendirme Logları
Birisi sunucunuza girmeye mi çalışıyor? Veya başarılı bir giriş mi yaptı?
CentOS/RHEL sistemlerde: tail -f /var/log/secure
Ubuntu/Debian sistemlerde: tail -f /var/log/auth.log
Bu dosyada Failed password for root şeklinde binlerce satır görüyorsanız, Brute-Force altındasınız demektir. Fail2Ban veya CSF bu aşamada devreye girip o IP'leri bloklamalıdır. Eğer Accepted password veya Accepted publickey yazan ve size ait olmayan bir IP görüyorsanız, sunucunuz ihlal edilmiştir; anında şifreleri değiştirmeli ve sistemi karantinaya almalısınız.
5.4. Zararlı Yazılım (Malware) Tespiti ve Temizliği
Sunucuya bulaşan bir virüs genellikle .php uzantılı base64 ile şifrelenmiş (obfuscated) kod blokları olarak kendini gizler.
En temel terminal komutuyla son 7 günde değiştirilen şüpheli dosyaları bulmak için:
Bash
find /home//public_html -type f -name ".php" -mtime -7
Ancak manuel arama yeterli değildir. Sunucunuzda mutlaka Imunify360 (bütçe varsa) veya ClamAV / Maldet (Linux Malware Detect) (ücretsiz alternatifler) bulunmalıdır.
Maldet kurulumu sonrası tüm sunucuyu taramak için:
Bash
maldet -a /home/?/public_html
BÖLÜM 6: YEDEKLEME VE FELAKET KURTARMA MİMARİSİ (DISASTER RECOVERY)
Sisteminiz ne kadar güvenli olursa olsun, donanımsal arızalara veya sıfırıncı gün (Zero-Day) açıklarına karşı %100 güvende değilsinizdir. Tek geçerli güvenlik önlemi: Çalışan, test edilmiş, harici bir yedektir.
6.1. 3-2-1 Yedekleme Kuralı
3 adet kopyanız olmalı (1 Orijinal veri, 2 Yedek).
2 farklı medya/depolama türünde tutulmalı.
1 kopya mutlaka sunucu dışında (Off-site, örneğin farklı bir kıtadaki bulut depolamada) olmalı.
WHM üzerinde varsayılan "Backup" aracını kullanarak yedeklerinizi Amazon S3, Google Drive veya harici bir FTP/Rsync sunucusuna yönlendirin. Sadece lokal (/backup dizini) yedek almak, diskin yanması durumunda hiçbir işe yaramaz. Ayrıca, veritabanı yedeklerinizin (SQL dump) eksiksiz alındığından emin olun, gerekirse cron job ile özel mysqldump betikleri yazın.
ÖZET VE SONUÇ
Sunucu yönetimi, "kur ve unut" mantığıyla yürümez. Canlı bir organizma gibidir, sürekli izlenmeli, güncellemeleri yapılmalı (kernel güncellemeleri dahil) ve logları takip edilmelidir.
Burada anlattığım adımlar; port güvenliğinden kullanıcı izolasyonuna, log takibinden felaket kurtarma senaryolarına kadar profesyonel bir altyapının temelini oluşturur.
Umarım bu rehber, sunucu yapılandırması aşamasında olan veya sorunlarının kaynağını loglarda arayan arkadaşlara kalıcı bir referans olur.
Sizler sunucularınızda, özellikle veritabanı yavaşlıklarını tespit ederken veya panel güvenliğini sağlarken burada bahsettiklerimin dışında hangi özel toolları (örn: htop, nmon, iotop vb.) veya metotları kullanıyorsunuz? Yorumlarda buluşalım, konuyu daha da derinleştirelim!
(Faydalı olması dileğiyle, herkese iyi forumlar!)