Sunucu Güvenliği
cPanel sunucusunda açık port denetimi: MySQL, Redis ve Docker dışarıya açık mı?
ss ile dinleyen servisleri çıkarın, MySQL, Redis, MongoDB ve Docker'ı yerel arayüze bağlayın, CSF kurallarını gözden geçirin ve güvenlik duvarı değişikliğini geri alma zamanlayıcısıyla güvenle yapın.
Güncellendi:
Bir cPanel sunucusunun internete açması gereken portlar bellidir: web (80, 443), e-posta (25, 465, 587, 993, 995 ve diğerleri), DNS (53), FTP ve cPanel, WHM, Webmail arayüzleri (2082 ile 2096 arası). Sorun genellikle bu listenin dışında kalanlardadır. Bir müşteri için kurulan Redis, bir deneme için açılan Docker API'si ya da uzaktan bağlantı istendiği için tüm arayüzlere açılan MySQL, kimse fark etmeden aylarca internete açık kalabilir.
Bu yazıda sunucunuzda neyin dinlediğini nasıl çıkaracağınızı, veritabanı ve önbellek servislerini yalnızca yerel arayüze nasıl bağlayacağınızı, CSF kurallarını nasıl gözden geçireceğinizi ve güvenlik duvarı değişikliğini kendinizi sunucunun dışında bırakmadan nasıl yapacağınızı anlatıyoruz. Komutlar AlmaLinux, Rocky Linux ve CloudLinux üzerinde cPanel/WHM için yazıldı.
1. Adım: Ne dinliyor?
Her şey ss komutuyla başlar. -t TCP, -u UDP, -l yalnızca dinleyen soketler, -n sayısal adres, -p süreç bilgisi demektir:
bash
# Tüm TCP dinleyicileri ve süreçleri
ss -tlnp
# Yalnızca yerel olmayan arayüzlerde dinleyenler (127.0.0.1 ve ::1 hariç)
ss -H -tlnp | awk '$4 !~ /^(127\.|\[::1\]|::1)/'
# UDP tarafı
ss -H -ulnp | awk '$4 !~ /^(127\.|\[::1\]|::1)/'Yerel adres sütununda 0.0.0.0:6379, *:6379 veya [::]:6379 görüyorsanız servis tüm arayüzlerde dinliyordur. 127.0.0.1:6379 ise yalnızca sunucunun kendisinden erişilebilir. Bir portun dinliyor olması dışarıdan erişilebilir olduğu anlamına gelmez; arada güvenlik duvarı vardır. Ama güvenlik duvarı kuralları değişebilir, yanlışlıkla kapanabilir ya da test moduna alınabilir. Hassas bir servisin yalnızca yerel arayüzde dinlemesi, güvenlik duvarına ek ikinci bir katmandır.
Bilmediğiniz bir süreç görürseniz hangi pakete ait olduğuna bakın:
bash
PID=12345 # ss çıktısındaki pid
readlink -f /proc/$PID/exe
rpm -qf "$(readlink -f /proc/$PID/exe)"Hangi portlar dikkat gerektirir?
Aşağıdaki liste, Sentinel'in hassas kabul ettiği 16 portun listesidir. Bunlar veritabanı, önbellek, RPC ve yönetim servisleridir; bir cPanel sunucusunun bunları internete açması için neredeyse hiçbir zaman iyi bir neden yoktur.
| Port | Servis | Önem |
|---|---|---|
| 111 | rpcbind / portmapper | Yüksek |
| 953 | BIND rndc | Orta |
| 2049 | NFS | Yüksek |
| 2375 | Docker API (TLS'siz) | Yüksek |
| 2376 | Docker API (TLS) | Orta |
| 3306 | MySQL / MariaDB | Orta |
| 5432 | PostgreSQL | Orta |
| 5984 | CouchDB | Yüksek |
| 6379 | Redis | Yüksek |
| 8086 | InfluxDB | Yüksek |
| 9200 | Elasticsearch HTTP | Yüksek |
| 9300 | Elasticsearch transport | Yüksek |
| 10250 | Kubelet API | Yüksek |
| 11211 | Memcached | Yüksek |
| 25826 | collectd | Orta |
| 27017 | MongoDB | Yüksek |
Tek komutla bu portlardan hangilerinin yerel olmayan bir arayüzde dinlediğini görebilirsiniz:
bash
ss -H -tulnp | awk '$5 !~ /^(127\.|\[::1\]|::1)/' \
| grep -E ':(111|953|2049|2375|2376|3306|5432|5984|6379|8086|9200|9300|10250|11211|25826|27017)[[:space:]]'2. Adım: Servisleri yerel arayüze bağlayın
Her servis için yöntem aynıdır: yapılandırma dosyasını yedekleyin, dinleme adresini 127.0.0.1 yapın, servisi yeniden başlatın ve ss ile doğrulayın. Yeniden başlatma adımını atlamayın; yapılandırma dosyası değişse bile çalışan servis eski adreste dinlemeye devam eder.
MySQL / MariaDB
bash
# Çalışan servisin gerçek ayarı
mysql -e "SHOW VARIABLES LIKE 'bind_address';"
ss -tlnp | grep ':3306'
# Yapılandırmada tanımlı mı?
grep -rn '^bind-address' /etc/my.cnf /etc/my.cnf.d/ 2>/dev/null
# Yedek
cp -p /etc/my.cnf /etc/my.cnf.yedek-$(date -u +%Y%m%d_%H%M%S)
# [mysqld] bölümüne ekleyin ya da mevcut satırı değiştirin:
# bind-address = 127.0.0.1
/scripts/restartsrv_mysql
ss -tlnp | grep ':3306'Redis
bash
redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode
# Yapılandırma dosyası dağıtıma göre /etc/redis.conf veya /etc/redis/redis.conf
CONF=/etc/redis/redis.conf; [ -f "$CONF" ] || CONF=/etc/redis.conf
cp -p "$CONF" "$CONF.yedek-$(date -u +%Y%m%d_%H%M%S)"
grep -nE '^(bind|protected-mode|requirepass)' "$CONF"
# Olması gerekenler:
# bind 127.0.0.1 -::1
# protected-mode yes
systemctl restart redis
ss -tlnp | grep ':6379'protected-mode, Redis'in parola tanımlanmadan dış bağlantı kabul etmesini engeller. Ancak tek başına yeterli değildir: bind satırı 0.0.0.0 ise ve bir parola tanımlanmışsa Redis yine dışarıdan erişilebilir olur ve parolanın tahmin edilmesine açık kalır. Önce bind, sonra protected-mode.
MongoDB, Memcached ve Elasticsearch
bash
# MongoDB: /etc/mongod.conf içinde
# net:
# bindIp: 127.0.0.1
grep -A3 '^net:' /etc/mongod.conf
# Memcached: /etc/sysconfig/memcached içinde
# OPTIONS="-l 127.0.0.1 -U 0"
cat /etc/sysconfig/memcached
# Elasticsearch: /etc/elasticsearch/elasticsearch.yml içinde
# network.host: 127.0.0.1
grep -n '^network.host' /etc/elasticsearch/elasticsearch.ymlMemcached'de -U 0 seçeneği UDP dinleyicisini kapatır; Memcached'in UDP portu geçmişte trafik büyütme saldırılarında yoğun olarak kullanıldı.
Docker API
2375 numaralı port, Docker daemon'una TLS ve kimlik doğrulaması olmadan erişim sağlar. Bu portu açık bulan biri sunucuda istediği konteyneri root yetkisiyle başlatabilir; pratikte sunucunun tamamını ele geçirmek demektir. Docker'ın nereden dinlediğine bakın:
bash
ss -tlnp | grep -E ':(2375|2376)[[:space:]]'
grep -n '"hosts"' /etc/docker/daemon.json 2>/dev/null
systemctl cat docker | grep -n 'ExecStart'ExecStart satırında -H tcp://0.0.0.0:2375 veya daemon.json içinde benzeri bir hosts girdisi varsa kaldırın; yerel kullanım için /var/run/docker.sock yeterlidir. Uzaktan yönetim gerekiyorsa SSH tüneli kullanın. Ayrıca Docker'ın -p ile yayımlanan konteyner portları için kendi iptables kurallarını eklediğini ve bunların ana güvenlik duvarı kurallarınızın önüne geçebildiğini unutmayın; konteyner portlarını 127.0.0.1:PORT biçiminde yayımlamak daha güvenlidir.
3. Adım: CSF kurallarını gözden geçirin
cPanel sunucularının çoğunda güvenlik duvarı olarak CSF (ConfigServer Security & Firewall) ve onun giriş denetimi servisi LFD kullanılır. Gelen trafik için izinli portlar /etc/csf/csf.conf içindeki TCP_IN, UDP_IN, TCP6_IN ve UDP6_IN satırlarındadır:
bash
grep -E '^(TESTING|TCP_IN|TCP6_IN|UDP_IN|UDP6_IN) ' /etc/csf/csf.conf
systemctl is-active lfd
# Belirli IP'lere özel port izinleri
grep -vE '^[[:space:]]*(#|$)' /etc/csf/csf.allow | grep -E '\|'Bakmanız gerekenler:
- TESTING = “1” ise CSF test modundadır: kurallar belirli aralıklarla temizlenir ve sunucu fiilen korumasız kalır. Kurulumdan sonra 0'a çekilmesi unutulan en yaygın ayardır.
- TCP_IN içinde yukarıdaki hassas portlardan biri var mı? 3306 gibi bir port bir müşteri için eklendiyse, genel listeden çıkarıp csf.allow içinde yalnızca o müşterinin IP adresine açın: tcp|in|d=3306|s=198.51.100.7
- TCP6_IN listesi TCP_IN ile aynı özeni görüyor mu? IPv4 listesinden kaldırılan bir port IPv6 listesinde unutulabilir; sunucunun IPv6 adresi varsa o kapı açık kalır.
- SSH portunuz TCP_IN listesinde mi? Portu değiştirdiyseniz yeni portun listede olduğundan emin olmadan CSF'i yeniden başlatmayın.
- LFD çalışıyor mu? LFD kapalıysa CSF portları süzer ama başarısız giriş denemelerine karşı otomatik engelleme yapılmaz.
CSF yerine firewalld kullanan sunucularda karşılığı firewall-cmd --list-all çıktısıdır. Burada yalnızca ports satırına değil, services ve rich rules satırlarına da bakın; bir servis tanımı ya da zengin kural da hassas bir portu açıyor olabilir.
4. Adım: Dışarıdan test edin
Sunucunun içinden bakmak, güvenlik duvarının gerçekte ne yaptığını göstermez. Testi başka bir makineden, örneğin kendi bilgisayarınızdan veya yönettiğiniz başka bir sunucudan yapın. Port taraması yalnızca kendi sunucunuzda ya da yazılı izin aldığınız sunucularda yapılmalıdır; başkasının sunucusunu taramak hem etik hem hukuki sorun yaratır.
bash
# Başka bir makineden; 203.0.113.10 yerine kendi sunucunuzun adresi
nc -zv -w 3 203.0.113.10 6379
nc -zv -w 3 203.0.113.10 3306
# nmap ile hassas portların hepsi
nmap -Pn -p 111,953,2049,2375,2376,3306,5432,5984,6379,8086,9200,9300,10250,11211,25826,27017 203.0.113.10nmap çıktısında open görünen her port bir bulgudur. filtered güvenlik duvarının paketi düşürdüğünü, closed ise portta dinleyen servis olmadığını gösterir. IPv6 adresiniz varsa aynı testi -6 seçeneğiyle tekrarlayın.
5. Adım: Güvenlik duvarını geri alma zamanlayıcısıyla değiştirin
Uzaktaki bir sunucuda güvenlik duvarı değiştirmenin en kötü sonucu, SSH bağlantınızı kesip kendinizi dışarıda bırakmaktır. Bunu önlemenin basit yolu, değişiklikten önce belirli bir süre sonra eski hâle dönecek bir zamanlayıcı kurmaktır. Değişiklik sonrasında her şey çalışıyorsa zamanlayıcıyı iptal edersiniz; bağlantı koptuysa zamanlayıcı sizin yerinize geri alır.
bash
# 1) Yedek
BAK=/etc/csf/csf.conf.yedek-$(date -u +%Y%m%d_%H%M%S)
cp -p /etc/csf/csf.conf "$BAK"
# 2) 5 dakika sonra yedeği geri yükleyecek zamanlayıcı
systemd-run --unit=fw-geri-al --on-active=300 /bin/bash -c "cp -p $BAK /etc/csf/csf.conf && csf -r"
systemctl list-timers fw-geri-al.timer
# 3) Değişikliği yapın (csf.conf düzenleyin) ve uygulayın
csf -r
# 4) YENİ bir terminalden SSH ile bağlanın, WHM (2087) ve siteleri kontrol edin.
# Her şey çalışıyorsa zamanlayıcıyı iptal edin:
systemctl stop fw-geri-al.timerDoğrulamayı mutlaka yeni bir SSH oturumuyla yapın. Açık olan mevcut oturum, kurallar değişse bile çoğu zaman bağlantı takibi sayesinde yaşamaya devam eder ve size yanlış bir güven verir.
Açık bir servis bulduğunuzda: kapatmak mı, kısıtlamak mı?
Dışarı açık bir servis bulduğunuzda üç seçeneğiniz vardır ve sırası önemlidir. Servis kullanılmıyorsa durdurup açılışta başlamasını engellemek en temiz çözümdür: systemctl disable --now SERVİS. Kullanılıyor ama yalnızca sunucunun kendisi kullanıyorsa, örneğin bir WordPress sitesinin nesne önbelleği olarak Redis, dinleme adresini 127.0.0.1 yapın. Dışarıdan erişim gerçekten gerekiyorsa, portu genel listeden çıkarıp yalnızca bilinen IP adreslerine açın ve servisin kendi kimlik doğrulamasını güçlü bir parolayla etkinleştirin.
Hangisini seçerseniz seçin, değişiklikten sonra aynı kontrolleri tekrarlayın: içeriden ss ile dinleme adresine, dışarıdan nc veya nmap ile erişime bakın. İkisi birlikte doğrulanmadıkça iş bitmiş sayılmaz.
Kısa kontrol listesi
- ss -tlnp ve ss -ulnp çıktısında yerel olmayan arayüzde dinleyen her servisin ne olduğunu biliyor musunuz?
- MySQL, Redis, MongoDB, Memcached ve Elasticsearch yalnızca 127.0.0.1 üzerinde mi dinliyor; dinlemiyorsa nedeni belgelenmiş mi?
- Docker API 2375 kapalı mı; konteyner portları 127.0.0.1 üzerinden mi yayımlanıyor?
- CSF TESTING değeri 0 mı, LFD çalışıyor mu?
- TCP_IN ve TCP6_IN listelerinde hassas port var mı; varsa csf.allow ile IP'ye özel hâle getirildi mi?
- Başka bir makineden yapılan nmap taramasında beklenmeyen open port kaldı mı?
- Son güvenlik duvarı değişikliğinin yedeği ve tarihi kayıtlı mı?
Sentinel bunu nasıl yapar
Sentinel'in csf-firewall modülü önce sunucuda hangi güvenlik duvarının çalıştığını belirler: CSF, Imunify360, firewalld ya da elle yazılmış nft/iptables kuralları. CSF kuruluysa TESTING modunu ve LFD'nin durumunu denetler; onayınızla TESTING'i kapatır, SSH portunu TCP_IN'e ekler ve LFD'yi etkinleştirir. CSF kurulu değilse onu internetten indirip otomatik kurmaz.
firewalld etkinse ya da sunucuda hiç güvenlik duvarı yoksa, dinleyen servisleri çıkarır ve yukarıdaki 16 hassas porttan dışarı açık olanları Dışa Açık Veritabanı/RPC Servisi bulgusu olarak raporlar. MySQL için ayrı mysql-hardening modülü, yapılandırma dosyasına değil çalışan servisin gerçekten loopback dışında 3306'yı dinleyip dinlemediğine bakar.
Hiç güvenlik duvarı olmayan bir sunucuda onaylanan düzeltme firewalld'yi cPanel'in port listesi ve o anki SSH portuyla açar; diğer servisler varsayılan olarak kapalı kalır. Uygulamadan önce Sentinel kendi tarafından yeni bir SSH bağlantısı, WHM 2087 ve HTTP 80/443 erişimini yoklar, sunucuda 300 saniyelik bir geri alma zamanlayıcısı (sentinel-fw-rollback) kurar ve değişiklikten sonra aynı portları yeniden dener. Erişim bozulduysa değişiklik hemen geri alınır; Sentinel'in oturumu yanıt vermez hâle geldiyse zamanlayıcı 5 dakika içinde güvenlik duvarını eski hâline döndürür. Her şey doğrulanırsa zamanlayıcı iptal edilir. Bu düzeltmeyi panelde önce kuru çalıştırma ile görebilir, onaylamadan hiçbir şey değişmez.
TEKNOWEB ÇÖZÜMLERİ
Bu rehberle ilgili çözümler
Rehberdeki konuyu gerçek ürün ve hizmet seçenekleriyle birlikte değerlendirin.
Yorumlar ve sorular
Deneyimini paylaş, birlikte çözelim.
Yorumlar yükleniyor…
Okumaya devam edin
Tüm rehberlerSunucu Güvenliği
Sentinel güvenlik raporu nasıl okunur: puan, önem derecesi ve öncelik sırası
Sentinel'de ilk sunucunuzu ekledikten sonra panel ve PDF raporda gördüğünüz puanın nasıl hesaplandığı, önem ile durum farkı, bulgulara hangi sırayla bakacağınız ve onaylı düzeltmenin nasıl çalıştığı.
Sunucu Güvenliği
cPanel'de PHP güvenlik ayarları: her sürümde expose_php, display_errors ve fazlası
Çoklu ea-php ve alt-php sürümü olan cPanel sunucusunda expose_php, display_errors, allow_url_include ve disable_functions ayarlarının etkin değerini nasıl doğrularsınız, hangilerini güvenle kapatırsınız?
Sunucu Güvenliği
cPanel'de Süresi Dolmuş SSL Sertifikaları: AutoSSL Neden Yenilemez, Nasıl Kontrol Edilir?
AutoSSL açık olsa bile sertifikalar neden süresini doldurur? DNS, CAA, Cloudflare ve sağlayıcı limitleri; tüm site ve servis sertifikalarını openssl ile bitiş tarihine göre listelemenin yolları.