Yeni UFW kuralı, eski bağlantı: yerleşik durum kazanır

Bir ret kuralı ekleyip açık bir indirmenin devam ettiğini görmek UFW hatası değildir. Eklediğiniz kural, akışı zaten kabul etmiş kuralların ardından gelir ve daha önce kurulmuş bir bağlantı onlarla eşleşmeye devam eder. Bunu düzeltmek, doğru konuma eklemek ve önceki kuralların ne vaat ettiğini anlamak demektir. Bu değişikliğin dar sürümü aşağıdadır.

Kuralın varlığı değil, sıra belirler

UFW, netfilter kurallarını aşamalar hâlinde yazan bir ön uçtur: kullanıcı kurallarından önce çalışan bir çerçeve bölümü, ardından kullanıcı kurallarının kendisi, sonra onlardan sonra çalışan bir bölüm. Standart önceki kurallar yerleşik ve ilişkili bağlantıların trafiğini kabul eder ve bu kurallar, normal bir allow veya deny ile eklediğiniz her şeyden önce değerlendirilir. UFW komut başvurusu, ekleme sözdizimini ve bu değişikliğin bağlı olduğu numaralı durum görünümünü belgeler.

Bu sıra şaşkınlığı açıklar. Yeni kuralınız gerçektir ve doğru tablodadır, ancak paketin karşılaştığı ilk karar o değildir. Zaten yerleşik olarak izlenen bir bağlantı ona hiç ulaşmaz.

Bu iş için route kurallarını kullanın, çünkü paket ağ geçidinin kendi hizmetlerine adreslenmek yerine ağ geçidinden yönlendirilir. Bir giriş kuralı yanlış trafiği süzer ve hiçbir şey yapmıyormuş gibi görünürdü.

Geniş iznin üstüne ekleyin

Uygulamadan önce eklemeyi önizleyin ve kuralın listede başka bir yerde zaten bulunmadığını doğrulayın. Aynı politikayı çoğaltmak sonraki kaldırmayı belirsizleştirir ve yanlış kopyayı kaldıran kişi bunu haftalarca fark etmez.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Önizleme beklediğiniz konumda tam olarak bir kural gösteriyorsa, aynı komutu dry-run bayrağı olmadan uygulayın. Konum 1, kuralı daha geniş kullanıcı izinlerinin üstüne koyar, daha önce ele alınan çerçeve kurallarının üstüne değil. Arayüz adının bu ağ geçidindeki tünel aygıtıyla eşleştiğini doğrulayın, çünkü artık var olmayan bir arayüze bağlı kural listede durur ve doğru görünürken hiçbir şeyle eşleşmez. Aygıt referansını uygulamadan önce yeniden adlandırın, test başarısız olduktan sonra değil.

Bu kuralda hedef bağlantı noktası yoktur, dolayısıyla yalnızca HTTPS değil, o adresteki her TCP bağlantı noktasını reddeder. Amaç tek bir hizmetse bağlantı noktasını adlandırın; politikadan daha geniş bir kural, ilk okuyucusunu bekleyen gelecekteki bir olaydır.

Kaynağı tek bir adresle sınırlayın, yalnızca o adres amaçlanan kimliğe bağlıysa. Dinamik atama yapan bir VPN havuzu yarın aynı adresi başka bir istemciye verebilir ve ret, kişiyi değil adresi izler.

Yerleşik akışlar yeni kuraldan sağ çıkar

Mevcut oturumun sürmesinin nedeni bağlantı izlemedir. Bir akış yerleşik olarak kaydedildiğinde, önceki kurallar onun paketlerini sizin reddinize bakılmadan önce kabul eder ve aktarım hiçbir şey değişmemiş gibi biter. Bu yüzden açık bir bağlantıyı yeniden kullanan tarayıcıyla test etmek yeni politika hakkında size hiçbir şey söylemez. Bir ret, devreye alındıktan dakikalar sonra işe yaramaz görünebilir ve bağlanan bir sonraki kullanıcı için tamamen etkili olabilir.

Gereksinim canlı trafiği kesmeyi içeriyorsa, bu kullanıcı kuralı değişikliği bunu sağlayamaz. İzlenen durumun geri alınması kendi etki yarıçapına sahip ayrı bir işlemdir ve kuralı ekleyene değil, güvenlik duvarı sahibine aittir. Bir oturumun kaybolması için ağ geçidindeki tüm bağlantıları boşaltmak, ikinci bir olay üreten türde bir düzeltmedir.

Sınırları da unutmayın. Bu kural ICMP, UDP veya IPv6 hakkında hiçbir şey söylemez, bu yüzden başarılı bir ping reddin başarısız olduğunun kanıtı değildir. Tek bir IPv4 adresi de web sitesi değildir: bir ad birden çok adrese çözülebilir ve yalnızca adlandırdığınız adres kapsanır.

Yeni bir akışla test edin

Numaralı kullanıcı kurallarını ve etkin ham görünümü okuyun, ardından seçilen istemciden yeni bir bağlantı açın:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

Ham görünüm önemlidir çünkü status elle yazılmış çerçeve kurallarını atlar, bu nedenle sıra çekirdeğin uyguladığından farklı görünebilir. Bir kuralın yanlış yerde olduğu sonucuna varmadan önce ikisini karşılaştırın.

Ardından kuralın geniş değil dar olduğunu kanıtlayan iki kontrolü denetleyin: aynı istemciden izin verilen hedef hâlâ çalışır ve ikinci bir istemci, politikası izin veriyorsa reddedilen hedefe hâlâ ulaşır. İki testi de bozan bir ret, politika değişikliğidir, hedefli bir önlem değil.

Test bittiğinde yalnızca eklediğiniz kuralı kaldırın, tam olarak yeniden yazarak. Politika kalıcıysa, güvenlik duvarı sahibine istemci kimliği, hedefin sahibi ve bir inceleme tarihiyle birlikte teslim edin; böylece yeniden atanan tünel adresi eski bir ret bırakmaz.