SSH erişimini kesmeden sunucu güvenlik duvarı yapılandırması

Saat gece iki ve SSH kesildi. Yaptığınız son şey INPUT zincirine bir DROP kuralı eklemekti ve şimdi ne ping yanıt veriyor ne de 22 numaralı port. KVM konsolunuz veya rescue modunuz yoksa bu durum sunucunun yeniden kurulması anlamına gelir. "SSH erişimini kesmeden sunucu güvenlik duvarı" meselesinin tamamı basit bir noktaya dayanır: geri dönüş yolunu önceden açmadığınız sürece, geri dönüş yolunu kapatan bir kuralı asla uygulamayın.

Her kuraldan önce kurtarma yolunu oluşturun

İş sırası önemlidir. Önce sunucu panelinden konsola veya rescue moduna erişiminiz olduğundan emin olun. Yoksa hemen şimdi etkinleştirme talebinde bulunun. Bu olmadan, güvenlik duvarındaki her küçük hata saatler süren bir olaya dönüşür. Erişimi kaybettiyseniz, kurtarma yolu rescue modu ve sunucuyu yeniden kurma ile başlar; ancak oraya hiç varmamak daha iyidir.

İkinci adım, ikinci bir SSH oturumu açıp onu açık tutmaktır. İlk oturumu kapatmayın. Kuralı ilk oturumda uygulayın ve ikinci oturumdan test edin. İkinci oturum kesilirse, ilk oturum hâlâ canlıdır ve kuralı silebilirsiniz. Bu basit teknik, diğer tüm araçlardan daha fazla kesintiyi önlemiştir.

Zamanlı kural: kurtarma zamanlayıcısı

Üçüncü adım zamanlayıcıdır. Kuralı uygulamadan önce, önümüzdeki 5 dakika içinde onaylamazsanız güvenlik duvarını önceki durumuna döndürecek bir betik yerleştirin:

cat > /root/fw-rollback.sh <<'EOF'
#!/bin/bash
sleep 300
iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
EOF
chmod +x /root/fw-rollback.sh
nohup /root/fw-rollback.sh &

Şimdi kuralı uygulayın. Her şey yolundaysa, kill %1 ile veya betiğin PID'ini bularak onu sonlandırın. Hata yaptıysanız, 5 dakika sonra güvenlik duvarı kendini temizler ve erişim geri döner. Bu sayıyı 3 dakikadan az yapmayın; yüksek trafikli sunucularda büyük zincirler üzerinde iptables -F çalıştırmak birkaç saniye sürer ve test etme fırsatınız olmaz.

Hangi portları gerçekten açık bırakmalısınız

Kısa cevap: yalnızca üzerinde aktif bir servisin dinlediği portları. Gerçek listeyi ss -tulpn ile alın, tahmini listeyi değil. Yeni bir web sunucusunun tipik çıktısı:

ss -tulpn | grep LISTEN
tcp   LISTEN 0 128 0.0.0.0:22     users:(("sshd",pid=812))
tcp   LISTEN 0 511 0.0.0.0:80     users:(("nginx",pid=1204))
tcp   LISTEN 0 511 0.0.0.0:443    users:(("nginx",pid=1204))
tcp   LISTEN 0 70  127.0.0.1:3306 users:(("mysqld",pid=1502))

MySQL'in 0.0.0.0 değil 127.0.0.1 üzerinde dinlediğine dikkat edin. Yani 3306 portunu güvenlik duvarında açık bıraksanız bile dışarıdan erişilemez. Ancak my.cnf içinde bind-address değerini bir kez 0.0.0.0 olarak değiştirdiyseniz, açılan o port bir arka kapıya dönüşür. MySQL güvenliği ve erişimlerin kısıtlanması rehberi bu durumu tamamen kapsar.

Bir nedeniniz yoksa SSH portunu değiştirmeyin

22 portunu 2222 gibi bir şeye değiştirmek gerçek bir güvenlik katmanı değildir; yalnızca log gürültüsünü azaltır. Tam port taraması yapan bir saldırgan yeni portu birkaç saniye içinde bulur. Bunu yapıyorsanız, mutlaka /etc/ssh/sshd_config içine de Port 2222 ekleyin ve servisi yeniden başlatın, aksi halde yeniden başlatmadan sonra SSH ayağa kalkmaz. Ben pratikte varsayılan portu koruyorum ve yerine PasswordAuthentication no ile PermitRootLogin prohibit-password seçeneklerini etkinleştiriyorum. Bu iki satır, port değiştirmekten daha etkilidir.

iptables mı ufw mi? Pratik seçim

Tek bir sunucunuz varsa ve kurallar basitse ufw seçin. Kubernetes, bridge ağlı Docker veya dahili NAT üzerinde çalışıyorsanız doğrudan iptables veya nftables'a gidin. Bunun nedeni, Docker'ın kendi kurallarını DOCKER-USER zincirine yazması ve ufw'nin bunları görmemesidir; sonuç olarak konteynerinizin 8080 portu dışarıdan açıkken ufw status engellendiğini söyler. VPS üzerinde Docker çalıştırıyorsanız, güvenlik duvarını yapılandırmadan önce VPS üzerinde Docker kurulumu yazısını okuyun.

ufw hakkında pratik bir not: ufw enable komutundan önce ufw allow 22/tcp komutunu çalıştırın. Önce enable yaparsanız, ufw varsayılan olarak incoming'i deny eder ve SSH standart dışı bir porttaysa o anda bağlantınız kesilir. ufw'nin kendisi "bu mevcut oturumu kesebilir" şeklinde bir uyarı verir ve çoğu kişi bunu görmezden gelir.

Burada hata yapıyorlar

Gördüğüm en yaygın hata şudur: kişi zincirin sonuna iptables -A INPUT -j DROP kuralını ekler, sonra sunucuyu yeniden başlatır ve SSH ayağa kalkmaz. Neden? Çünkü iptables kuralları varsayılan olarak yeniden başlatmadan sonra silinir ve zincirin varsayılan politikası ACCEPT'e döner; ancak iptables-persistent ile kaydettiyseniz, aynı DROP kuralı önyüklemeden sonra yeniden uygulanır ve bu sefer kurtarma oturumunuz da yoktur. Belirtisi şudur: sunucu ping'e yanıt verir (çünkü ICMP kuralınızda istisna tutulmuştur) ama 22 portu zaman aşımına uğrar. Ping yanıt verir ve bu yanıltıcıdır; birçok kişi sorunun SSH servisinde olduğunu düşünüp systemctl restart sshd çalıştırır, oysa paket sshd'ye hiç ulaşmaz.

İkinci hata: kuralı OUTPUT zincirine uygulamak. Sunucunun "yalnızca dışarı bağlanmasını" isteyen biri OUTPUT politikasını DROP olarak değiştirir ve sonra apt update'in neden çalışmadığını veya DNS'in neden çözümlenmediğini anlamaz. OUTPUT'u kısıtlıyorsanız, en azından şunları açık bırakın:

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

ESTABLISHED,RELATED satırını INPUT'a da koyun, aksi halde giden paketlerin yanıtı geri dönmez ve her şey yarım kalır. Bu satırı her zaman zincirin ilk kuralı olarak koyun; iptables'ta kural sırası anlamlıdır ve ilk eşleşme kazanır.

Risksiz test: nasıl emin oluruz

Sunucunun içinden test etmeyin. curl localhost her zaman yanıt verir çünkü loopback arayüzünden geçer ve güvenlik duvarını atlar. Harici bir makineden nmap ile test edin:

nmap -Pn -p 22,80,443,3306,8080 your-server-ip

open çıktısı paketin geçtiği, filtered DROP edildiği ve closed güvenlik duvarının izin verdiği ama bir servisin dinlemediği anlamına gelir. filtered ile closed arasındaki farkı ciddiye alın; birçok kişi closed'ı güvenlik duvarı sorunuyla karıştırır ve saatlerce kural değiştirir.

Web servisleri için, her güvenlik duvarı değişikliğinden sonra dışarıdan bir hız ve erişim testi yapın. Site özel bir sunucuda veya özel sunucu üzerinde barındırılıyorsa ve trafik yüksekse, kuralları düşük trafikli saatlerde uygulayın; her güvenlik duvarı reload'u paket işlemede birkaç milisaniyelik kesinti yaratır ki bu ağır yükte belirgindir. Değişikliklerden sonra sunucu yükü yükseldiyse, yüksek sunucu yükünü teşhis etme rehberi iyi bir başlangıç noktasıdır.

Kalıcı depolama ve düzenli gözden geçirme

Kuralları kaydedin, aksi halde yeniden başlatmadan sonra her şey başlangıç durumuna döner:

apt install iptables-persistent
netfilter-persistent save
iptables-save > /etc/iptables/rules.v4

Her üç ayda bir iptables -L -n -v --line-numbers çalıştırın ve hangi kuralın sıfır sayacı olduğunu görün. 90 günde tek bir paket bile yakalamayan bir kural muhtemelen artık gerekli değildir ve yalnızca saldırı yüzeyini büyütür. Bu gözden geçirmeyi ciddiye alın; güvenlik duvarları genellikle yalnızca eklenir ve hiç silinmez.

Altyapıyı yeni kuruyorsanız ve ilk günden ham iptables ile uğraşmak istemiyorsanız, tam root erişimli bir Linux hosting uygun bir başlangıç noktasıdır; orada kuralları ufw ile oluşturup sonra iptables'a geçebilirsiniz. Yapılandırma dosyalarını sunucular arasında taşımak için de scp ve rsync ile dosya transferi işi hızlandırır.

Sık sorulan sorular

Güvenlik duvarını etkinleştirdikten sonra neden SSH kesildi ama ping yanıt veriyor?

Çünkü ICMP kuralını açık bıraktınız ama 22 portunu kapatmadınız. Ping katman 3'te çalışır ve TCP portunun durumuyla ilgisi yoktur. Önce konsoldan girin ve iptables -L INPUT -n --line-numbers çıktısına bakın, sonra 22 portunu engelleyen kuralı iptables -D INPUT <numara> ile silin.

SSH portunu değiştirmek güvenliği gerçekten artırır mı?

Sanıldığı kadar değil. Tam port taraması birkaç saniye sürer ve yeni port bulunur. Gerçek etkisi başarısız deneme loglarını azaltmaktır. Gerçek güvenlik eklemek istiyorsanız, anahtarla kimlik doğrulamayı seçin ve parola girişini devre dışı bırakın.

Hangi portların dışarıdan açık olduğunu nasıl anlarım?

Sunucunun içinden ss -tulpn ile hangi servisin hangi adreste dinlediğine bakın ve harici bir makineden nmap -Pn -p- your-server-ip ile tarayın. Bu iki çıktı arasındaki fark, tam olarak güvenlik duvarının engellediği veya açtığı şeydir.

iptables kuralları yeniden başlatmadan sonra silinir mi?

Evet, netfilter-persistent save veya /etc/iptables/rules.v4 yolunda iptables-save ile kaydetmediyseniz silinir. ufw kullanıyorsanız kurallar otomatik kaydedilir ve ekstra bir işlem gerekmez.