VPS Güvenlik Duvarı Kuralları Güvenli Bir Şekilde Nasıl Yapılandırılır
4 Eylül 2026 tarihinde yayımlandı
Bir güvenlik duvarı, sunucunuzun ihtiyaç duyduğu trafiğe izin vermeli ve geri kalanını sessizce reddetmelidir. VPS güvenlik duvarı kurallarını güvenli bir şekilde yapılandırmak için, önce erişilebilir kalması gereken servislerle, özellikle SSH ile başlayın, ardından web ve uygulama portlarını tek tek ekleyin. Sahip olduğunuz tek açık terminal oturumundan her şeyi engelleyerek başlamayın. Sakin bir bakım görevinin konsol kurtarma görevine dönüşmesi işte böyle olur.
Çoğu Linux VPS dağıtımında pratik hedef basittir: varsayılan olarak istenmeyen gelen trafiği reddetmek, gerekli giden trafiğe izin vermek ve güvenilir kullanıcılar ile servisler için dar kapsamlı gelen kuralları oluşturmaktır. Bu, rutin yönetimi zorlaştırmadan saldırı yüzeyini azaltır.
Trafik haritasıyla başlayın
Herhangi bir kuralı değiştirmeden önce, VPS'in gerçekte ne yaptığını yazın. Örneğin herkese açık bir WordPress sitesi, yönetim için genellikle SSH'ye ve web trafiği için 80 ile 443 portlarına ihtiyaç duyar. Özel bir API yalnızca HTTPS gerektirebilirken, bir veritabanı sunucusu genellikle bağlantıları yalnızca özel bir ağdaki bir uygulama sunucusundan kabul etmelidir.
Önce dinleyen servisleri kontrol edin. Çoğu Linux dağıtımında bu komut faydalı bir görünüm sağlar:
```bash sudo ss -tulpn ```
Gösterilen her portu otomatik olarak açmayın. Bazı servisler yalnızca localhost veya özel bir arayüz üzerinde dinler ve herkese açık güvenlik duvarı erişimine ihtiyaç duymaz. Diğerleri eski test servisleri, izleme ajanları veya internetten hiçbir şekilde erişilebilir olmaması gereken yazılımlar olabilir.
Herkese açık her port için şu üç soruyu yanıtlayın: buna kimin ihtiyacı var, nereden ve hangi protokol üzerinden? Her yerden HTTPS'ye izin veren bir kural, herkese açık bir web sitesi için normaldir. Her yerden bir veritabanı portuna izin veren bir kural, genellikle günlüklerde usulca bekleyen bir sorundur.
VPS güvenlik duvarı kurallarını yapılandırmadan önce bir kurtarma yolu bulundurun
Güvenlik duvarı değişikliklerini yaparken iki etkin SSH oturumu açık tutun. Kuralları uygulamak için bir oturumu kullanın ve ikincisini ellemeyin. Bir değişikliği uyguladıktan sonra, herhangi bir şeyi kapatmadan önce başka bir terminalden yeni bir bağlantı test edin. Bu, iyimserliğe güvenmek yerine gerçek bağlantı yolundaki hataları yakalar.
Ayrıca VPS sağlayıcınızın konsolunun kullanılabilir olduğunu doğrulayın. Tarayıcı tabanlı bir konsol veya kurtarma ortamı, SSH engellenirse geri dönüş seçeneğidir. Bu, dikkatli çalışmanın yerine geçmez, ancak operasyonel açıdan iyi bir güvencedir.
SSH standart dışı bir portta çalışıyorsa, kural oluşturmadan önce bunu doğrulayın:
```bash sudo ss -tulpn | grep ssh ```
Standart dışı bir SSH portu, otomatik taramalardan gelen arka plan gürültüsünü azaltabilir, ancak tek başına anlamlı bir güvenlik sağlamaz. Asıl işi güçlü kimlik doğrulama, sınırlı kaynak erişimi ve zamanında yama uygulama yapar.
UFW ile varsayılan olarak reddeden bir gelen politika kullanın
UFW, Ubuntu ve Debian tabanlı VPS sunucuları için pratik bir güvenlik duvarı arayüzüdür. Daha sonra okunması kolaydır; bu da başka bir yöneticinin gece 2'de bir kesintiyi gidermesi gerektiğinde önemlidir.
Önce mantıklı varsayılanları ayarlayın:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Ardından, güvenlik duvarını etkinleştirmeden önce SSH'ye izin verin. Sunucunuz varsayılan SSH portunu kullanıyorsa, şunu kullanın:
```bash sudo ufw allow OpenSSH ```
SSH özel bir portta dinliyorsa, bunu açıkça belirtin. Bu örnekte 2222 portu kullanılıyor:
```bash sudo ufw allow 2222/tcp ```
Normal bir herkese açık web sitesi için HTTP ve HTTPS'ye izin verin:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Ardından güvenlik duvarını etkinleştirin ve ortaya çıkan politikayı kontrol edin:
```bash sudo ufw enable sudo ufw status numbered ```
Numaralı durum faydalıdır, çünkü kurallar daha sonra tam olarak kaldırılabilir. Sorun giderme sonrasında geçici geniş kapsamlı kuralları geride bırakmaktan kaçının. Geçici kuralların kalıcı demirbaşlara dönüşmek gibi komik bir alışkanlığı vardır.
VPS, bir ters proxy arkasında bir web uygulaması barındırıyorsa, uygulama portunun herkese açık olması gerekmeyebilir. Örneğin, Nginx 80 ve 443 portlarında trafiği kabul ederken uygulama `127.0.0.1:3000` üzerinde dinleyebilir. Bu tasarımda 3000 portu için hiçbir güvenlik duvarı kuralı gerekmez.
Yönetim erişimini kaynak IP'ye göre kısıtlayın
Ekibinizin gerçekten bu esnekliğe ihtiyacı olmadıkça SSH her adrese açık olmamalıdır. Ofisinizin, VPN'inizin veya geçiş ana makinenizin sabit bir genel IP adresi varsa, SSH'yi bununla sınırlayın:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
Ev IP'leri değişen dağıtık bir ekip için, SSH'yi küresel olarak açmaktan daha iyi çözüm çoğu zaman bir VPN veya bastion host'tur. Biraz ek kurulum işi getirir, ancak size tek bir kontrollü yönetim yolu ve daha temiz bir denetim izi sağlar.
Hız sınırlama, temel SSH parola tahmin girişimlerini de azaltabilir:
```bash sudo ufw limit 22/tcp ```
Bu; SSH anahtarlarının, uygun olan yerlerde parola ile kimlik doğrulamanın devre dışı bırakılmasının veya yönetim yolunuz üzerinden çok faktörlü erişimin yerine geçmez. Bunu tüm çit değil, çitin bir paneli olarak düşünün.
Veritabanlarını, panelleri ve izlemeyi ayrı ele alın
3306'daki MySQL, 5432'deki PostgreSQL, 6379'daki Redis ve 27017'deki MongoDB gibi veritabanı portları neredeyse hiçbir zaman herkese açık olmamalıdır. Bunlara yalnızca uygulama sunucusunun özel IP adresinden veya alt ağından izin verin.
Örneğin, yalnızca `10.10.0.12` adresindeki bir uygulama VPS'inden MySQL bağlantılarına izin vermek için:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
Veritabanı servisinin kendisi de mümkünse amaçlanan özel arayüze bağlanmalıdır. Güvenlik duvarı kuralları ve servis bağlama ayrı katmanlardır. Her ikisini de kullanmak, hatalı bir güvenlik duvarı değişikliğinin servisi açığa çıkarma olasılığını azaltır.
Barındırma panelleri, Grafana panoları ve izleme uç noktaları da aynı dikkati hak eder. Bunlar yalnızca personel içindeyse, bir VPN, ofis IP aralığı veya özel yönetim ağıyla sınırlandırın. Genel izleme sayfaları, gizli bilgiler göstermeseler bile beklenenden daha fazla altyapı ayrıntısı açığa çıkarabilir.
Sağlayıcı güvenlik duvarını ve IPv6'yı hesaba katın
VPS'inizde birden fazla güvenlik duvarı katmanı olabilir. Bir bulut veya sağlayıcı düzeyi güvenlik duvarı, trafik sunucuya ulaşmadan önce filtreler; UFW, firewalld, nftables veya iptables ise trafiği VPS'in kendisinde filtreler. Her ikisini birden kullanmak mantıklıdır, ancak kurallar birbiriyle uyumlu olmalıdır.
443 portu VPS üzerinde açıksa ancak sağlayıcı katmanında engelleniyorsa, ziyaretçiler yine de bağlanamaz. Sağlayıcı bir porta izin veriyor ama VPS bunu reddediyorsa, VPS korunmaya devam eder. Sorun giderme sırasında her iki katmanı da sırayla kontrol edin: sağlayıcı politikası, VPS güvenlik duvarı, servis dinleme adresi ve uygulama yapılandırması. Bunlar kontrol edildiğinde günlükler genellikle aynı hikâyeyi anlatır.
IPv6'yı unutmayın. VPS'inizin genel bir IPv6 adresi varsa, eşdeğer IPv6 kuralları gereklidir. UFW, yapılandırmasında etkinleştirildiğinde IPv6'yı yönetebilir, ancak şununla doğrulayın:
```bash sudo ufw status verbose ```
Aynı servis IPv6 üzerinden sonuna kadar açıksa, düzgün şekilde güvenliği sağlanmış bir IPv4 adresi yardımcı olmaz.
Dışarıdan test edin, ardından sonucu izleyin
Her önemli değişiklikten sonra, VPS dışındaki bir ağdan test yapın. Amaçlanan servislerin çalıştığını doğrulayın, ardından özel kalması gereken portlara erişilemediğini doğrulayın. Web siteleri için tarayıcı testi faydalıdır, ancak komut satırı testleri belirli portlar için daha net yanıtlar sağlar:
```bash nc -vz your-server-ip 443 ```
Engellenen portlar için zaman aşımı veya ret, kurala ve servis durumuna bağlı olarak farklı anlamlara gelebilir. Bir anda birkaç ayarı değiştirmek yerine güvenlik duvarı durumunu, servis durumunu ve sistem günlüklerini gözden ge çirin.
Bir sorunu teşhis ederken günlük kaydını dikkatlice etkinleştirin:
```bash sudo ufw logging low ```
Düşük düzey günlük kaydı, gereksiz disk etkinliği oluşturmadan beklenmedik şekilde reddedilen trafiği tespit etmek için genellikle yeterlidir. Yoğun sunucularda yüksek hacimli güvenlik duvarı günlükleri kendi başına küçük bir operasyonel sıkıntıya dönüşebilir.
Yeni bir servis dağıttığınızda, eski bir uygulamayı devreden çıkardığınızda, ofis IP adresleri değiştiğinde veya ağ mimarisini değiştirdiğinizde güvenlik duvarı kurallarını gözden geçirin. En iyi kurallar en uzun kural kümesi değildir. Sunucunun nasıl iletişim kurması gerektiğini doğru şekilde tanımlayan en küçük kümedir.
Bu işi tek başınıza üstlenmemeyi tercih ederseniz, bir yönetilen VPS ekibi erişim gereksinimlerini gözden geçirebilir, değişiklikleri bir kurtarma planıyla uygulayabilir ve sonrasında sunucuyu izleyebilir. kodu.cloud'da bu, özellikle paket filtreleme yerine müşterilere ve ürüne odaklanması gereken ekipler için, yönetilen operasyonlar ve sürekli izleme ile doğal olarak uyumludur.
Bir güvenlik duvarı, kimse fark etmediğinde işini yapıyor demektir. Politikayı dar tutun, her istisnanın neden var olduğunu belgelendirin ve servisin yeniden sakin olduğunu ilan etmeden önce erişimi test edin.
Andres Saar Müşteri Hizmetleri Mühendisi