Linux’ta Güvenlik Duvarı (iptables ve firewalld) Kullanımı

Uzaktaki bir Linux sunucusunda güvenlik duvarını düzenlerken ilk hedef yeni kuralı eklemek değil, yönetim erişimini kaybetmemektir. Mevcut SSH oturumunu açık tutun; sağlayıcı konsolu gibi bağımsız bir erişim yolunun çalıştığını doğrulamadan varsayılan politikayı değiştirmeyin.

Kuralları hangi araç yönetiyor?

iptables, nftables, firewalld ve UFW adlarını aynı sunucuda görmek, hepsini ayrı ayrı yapılandırmanız gerektiği anlamına gelmez. Önce dağıtımın ve mevcut kurulumun kullandığı yöneticiyi belirleyin. Aşağıdaki komutlar inceleme içindir; eksik komut veya pasif servis tek başına “güvenlik duvarı yok” kanıtı değildir.

systemctl is-active firewalld
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo iptables --version
sudo nft list ruleset

iptables çıktısındaki nf_tables, komutun nftables altyapısını kullandığını gösterebilir. Bu yüzden firewalld'ı her sistemde iptables üzerine çalışan bir arayüz diye tanımlamak doğru değildir. Yönetici araç çalışıyorsa onun ürettiği kuralları başka araçla değiştirmek, sonraki yeniden yüklemede değişikliğin kaybolmasına veya çakışmasına yol açabilir.

firewalld ile sınırlı bir HTTPS denemesi

Bu örnek, zaten firewalld tarafından yönetilen bir sunucu içindir. UFW kullanan sistemde sırf örneği uygulamak için firewalld başlatmayın. public örnek bölgedir; önce gerçek ağ arayüzünün veya kaynak adresinin bağlı olduğu bölgeyi bulun. Web hizmetinizin gerçekten 443 üzerinde dinlediğini de kontrol edin.

sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --permanent --zone=public --list-all
sudo firewall-cmd --info-service=https
sudo firewall-cmd --zone=public --query-service=https
sudo ss -lntp

Başlangıç durumunu bakım kaydına alın. Hizmet zaten açıksa bu örneğin geri alma adımını uygulamayın. Henüz açık olmayan HTTPS hizmetini geçici olarak eklemek için:

sudo firewall-cmd --zone=public --add-service=https --timeout=10m
sudo firewall-cmd --zone=public --query-service=https

Bu işlem on dakikalık bir çalışma zamanı kuralıdır; kalıcı ayar değildir. Ayrı bir istemciden yeni HTTPS bağlantısı kurun. Sunucunun kendisinden yapılan istek, dışarıdan erişim yolunu sınamaz. Gerekliyse hem IPv4 hem IPv6 adresini kontrol edin.

Çalışma zamanı ve kalıcı ayarı ayrı kontrol edin

Deneme başarılıysa ve hizmetin sürekli açık kalması isteniyorsa kalıcı yapılandırmaya ekleyebilirsiniz:

sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public --query-service=https

Kalıcı ekleme, geçici kuralın süresini uzatmaz. Kalıcı ayarın çalışma zamanına alınması için yapılacak --reload öncesinde iki yapılandırmanın tamamını karşılaştırın: başka geçici kurallar kaybolabilir. Yönetim erişiminin kalıcı yapılandırmada da bulunduğunu doğrulayın ve yeniden yüklemeyi kontrollü bakım adımı olarak yapın. Sonrasında yeni SSH ve HTTPS bağlantılarını tekrar sınayın.

Vazgeçerseniz yalnızca bu denemede eklediğiniz hizmeti kaldırın. Kalıcı ekleme yaptıysanız iki taraftan da kaldırmanız gerekir; önceden var olan bir HTTPS iznini silmeyin.

sudo firewall-cmd --zone=public --remove-service=https
sudo firewall-cmd --permanent --zone=public --remove-service=https

iptables ile inceleme, kural silmek değildir

sudo iptables -S
sudo ip6tables -S
sudo iptables -L INPUT -n -v --line-numbers
sudo iptables-save

Bunlar mevcut durumu okumaya yardımcı olur. iptables -F ile bütün kuralları temizlemek veya gelişigüzel INPUT DROP politikası koymak bir başlangıç kurulumu değildir. Mevcut bağlantılar, loopback, SSH portu ve IPv6 hesaba katılmadan yapılan değişiklik erişimi kesebilir. Kuralların yeniden başlatmada nasıl yüklendiği dağıtıma ve kullanılan yöneticiye bağlıdır; tek bir dosya yolu her sistem için geçerli değildir.

HTTPS hala ulaşılmıyorsa bulut güvenlik grubu, yönlendirme, uygulamanın dinlediği adres ve konteyner ağını inceleyin. Bir hizmet eklemiş olmak diğer bütün trafiğin kapalı olduğunu kanıtlamaz. Komut ayrıntıları için firewall-cmd başvurusunu kullanın.