Güvenlik duvarı kuralı değişikliği çalışmıyor: kural sırası ve bağlantı durumu

Kuralı düzenlediniz, kural kümesini yeniden yüklediniz ve tünel tam olarak eskisi gibi davranıyor. Bu sonucun iki yaygın nedeni var ve bunlar farklı testler gerektiriyor. Ya yeni kural paketi zaten kabul etmiş daha önceki bir kuraldan sonra duruyor, ya da izlediğiniz alışveriş, değişikliğin hiç yeniden değerlendirmediği izlenen bir bağlantıdır. Bir dosyadaki kural niyeti ifade eder; pakete karar veren, onun karşılaştığı etkin yoldur. Aşağıdaki kontrolleri sırayla yapın ve bunu yaparken geri dönüş yolunu açık tutun.

Kural sırası ve bağlantı durumu farklı arızalardır

Sıralı zincirler yukarıdan aşağıya değerlendirilir ve kesin bir hükme ulaşan ilk kural o zincirdeki geçişi bitirir. Dikkatle yazılmış bir kilitleme kuralının üstüne geniş bir izin koyun, kilitleme kuralı belgeye dönüşür: kümede vardır, sayacı sıfırdır ve hiçbir paket ona asla ulaşmaz. Aynı metnin başka bir zincire uygulanması da hiçbir şey kanıtlamaz. nftables'ta temel zincirler önceliklere göre kancalara bağlanır, bu yüzden bir zincirdeki izin, farklı bir kanca veya öncelikteki başka bir zincirin aynı paketi görmesini engellemez.

Bağlantı izleme ikinci belirtiyi üretir ve dışarıdan tamamen aynı görünür. Bir akış durum tablosuna girdiğinde, zincirin tepesine yakın established-or-related izni yeni kuralınız hiç dikkate alınmadan geri döner. NAT eşlemeleri de aynı özelliğe sahiptir: çeviri akış başladığında sabitlenmiştir, bu yüzden düzenlenmiş bir postrouting kuralı zaten çalışan bir oturumu yeniden yazmaz. Bir değişikliğin 09:00'da yeni bir bağlantı için çalışıyor gibi görünmesi ve 08:55'te birinin açtığı oturum için hiçbir şey yapmıyor gibi görünmesi bu yüzdendir.

Bulut güvenlik grupları, iptables ile öğrenenleri yakalayan üçüncü bir model ekler. Gelen kuralları, ilk eşleşme yürüyüşü değil küme olarak değerlendirilen bir izin listesidir, durumludur ve bir izin kuralının kaldırılması zaten izlenen akışları sonlandırmaz. İlk eşleşme semantiğini bu özelliğe sahip olmayan bir platformda varsaymak, kendinden emin ama yanlış sonuçlara götürür.

Etkin kural kümesini okuyun, düzenlediğiniz dosyayı değil

Çekirdeğin şu anda uyguladığı şeyle başlayın. Hiç uygulanmamış kayıtlı bir yapılandırma, şaşırtıcı sayıda değişmemiş davranışı açıklar ve onu elemek tek bir komuta mal olur:

nft list ruleset
iptables-save

Sonra kuralınıza hiç ulaşılıyor mu diye sorun. Paket sayaçları buna doğrudan yanıt verir ve niyet hakkındaki herhangi bir akıl yürütmeden daha iyi yanıt verir:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Gerçek bir test denemesinden sonra sıfır paketli bir kilitleme kuralı politika sorunu değil, konum sorunudur. Onu taşımak tek satırlık bir değişikliktir ve sözdizimi tam olarak asıl hataya neden olan şeydir. iptables'ta -I başa ekler, -A sona ekler; nftables'ta insert kuralı zincirin başına koyar, add ise sona ekler. Bir kural kazanmak zorundaysa, rastgele yüklenen sıraya güvenmek yerine bunu açıkça söyleyin.

Akışın izlenip izlenmediğini kanıtlayın

Kuralı suçlamadan önce, trafiğin gerçekten izlenen bir bağlantı olup olmadığını kontrol edin. Durum tablosunun tamamını boşaltmak yerine belirli akışı sorun:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Liste durumu ve kalan süreyi gösterir, yerleşik bir oturumu taze bir denemeden böyle ayırırsınız; olay kipi güncellemeleri oldukça yazdırır, bu da bir istemciyi yeniden bağlarken işe yarar. Bir şeye dokunmadan önce akış yerleşik durumda varsa, filtre kurallarındaki hiçbir düzenleme onun kaderini değiştirmez. Bu güvenlik duvarında bir hata değil, durumlu filtrelemenin sözleşmesidir.

Bir üretim geçidinde tüm tabloyu boşaltma kısa yoluna direnin. conntrack -F kullanılabilir ve makinedeki her izlenen akışı da yok eder, çalıştığınız yönetim oturumu ve kabuğunuzu taşıyan tünel dahil. Tek tek girdiler gerçekten ihtiyaç duyduğunuzda silinebilir, ancak yeni bir kaynak bağlantı noktasından gelen taze bir akış genellikle daha temiz bir deneydir.

Bazı yollar izlenmez ve bunlar tersine davranır. raw tablosunda notrack olarak işaretlenmiş trafik, normal kancaları atlayan bazı tüneller ve bir akışı iki geçit arasında bölen asimetrik yönlendirme, hepsi tek tek değerlendirilen paketler veya iki uçta hiç oluşmayan durum üretir. Sayaçlar her pakette hareket ediyorsa, sıradan şüphelenmeden önce bu tür bir yoldan şüphelenin.

Geri dönüş yoluyla taze bir akıştan test edin

Uzaktan erişimi kesebilecek bir kuralı test etmeden önce bir kurtarma yolu kurun: sağlayıcı konsolu, seri konsol, bant dışı yönetim adresi veya kuralın eşleşemeyeceği ikinci bir arayüz. Geri alma zamanlayıcısı makul bir yol arkadaşıdır, çünkü oturumunuz testin ortasında ölse bile önceki kural kümesini geri yükler.

Sonra durumun zaten kapsayamayacağı bir alışverişle test edin. İstemcinin bağlantısını kesip yeniden bağlayın ki yeni bir beşli oluşsun ve bu olurken iki ucu da izleyin:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Testi iki yönde de yapın. Yeni gelen el sıkışmayı engelleyen bir kural yanıt yoluna hâlâ izin verebilir veya tam tersi, ve tek yönlü sonuç bir kilidin yarım çalışmasının olağan nedenidir. Testten sonra kararlı durumu doğrulamak için bir kez daha bağlanın ve meşru yönetim erişiminin hayatta kaldığını kontrol edin; tek bir bağlantı noktası için yazılan bir kural, amaçlanandan daha geniş bir aralıkla eşleşme alışkanlığına sahiptir.

Amacı ve konumu kuralla birlikte kaydedin

Kayıtlı amacı olmayan bir kural, kimsenin kaldırmaya cesaret edemediği bir kuraldır. Her kilitleme girdisinin yanında koruduğu akışı, içinde yaşadığı zinciri ve kancayı, daha geniş izinlere göre tutması gereken konumu ve bunu kanıtlayan testi saklayın. Altı ay sonra biri çevredeki kural kümesini düzenlediğinde, o not konumun bilinçli olduğuna dair tek uyarıdır.

Değişikliği kapatmadan önce dört şeyi doğrulayın: çalışan kural kümesi dosyayla eşleşiyor, yeni kuralın taze bir denemeden sonra sıfırdan farklı sayaçları var, ters yön ve yönetim erişimi hâlâ çalışıyor ve değişiklikten daha eski bir oturumun durumunu değil, kararlı durumu kanıtlamak için bir kez yeniden bağlandınız. Bunlardan herhangi biri doğrulanmadıysa, tünel ne yaparsa yapsın değişiklik bitmemiştir.