SSH ve VPN giriş kuralları: izin listesi gerçekte neyi denetler

Bir kuralı değiştirmeden önce bir kez bağlanın ve istemcinin asılı kaldığını mı yoksa hemen reddedildiğini mi not edin. Bu tek fark, hangi kararın paketi düşürdüğünü söyler ve politika dosyalarını okumaya harcanan bir saat kazandırır. Yolun geri kalanı kısadır: paket bir kancayı geçer, bir kuralla eşleşir ve ya bir dinleyiciye ulaşır ya da ulaşmaz. İzin listesi bu üç gerçeğin etrafındaki muhasebeden ibarettir.

Bir SSH denemesini giriş kancasına kadar izleyin

İstemci, ana makinenin adresine 22 numaralı bağlantı noktasından bir SYN gönderir ve çekirdek bu paketin yerel bir hizmet için olup olmadığına karar verir. Öyleyse giriş yolu çalışır ve kural kümesi paketi ya kabul eder ya da atar. Sessizlik, SYN'in dinleyici onu görmeden öldüğü anlamına gelir; hızlı ret ise bir şeyin sıfırlama ile yanıt verdiği anlamına gelir. Bunlar farklı kurallardan çıkan farklı hükümlerdir ve ikisi de meşru sonuçlardır.

Ardından dinleyiciyi doğrulayın, çünkü hiçbir kural olmayan bir hizmeti kurtaramaz. ss -ltnp komutunu çalıştırın ve beklediğiniz bağlantı noktası ile adres ailesine bir şeyin bağlı olduğunu kontrol edin, sonra istemcide ssh -v okuyarak nerede durduğunu görün.

Yönlendirme ayrı bir karardır

Bir VPN sunucusunda daha ilginç kanca forward'dır, çünkü istemci trafiği makineye teslim edilmek yerine o makine üzerinden yönlendirilir. Yalnızca kendi VPN istemcisini çalıştıran bir ana makine, başkalarının paketlerini ileten bir makineye göre çok daha küçük bir kural kümesine ihtiyaç duyar. İki tasarımı tek makinede karıştırmak doğru görünen ve hiçbir şeyi geçirmeyen kurallar üretir.

İç politikayı ayrı bir soru olarak yazın: hangi istemci adresleri tünel üzerinden hangi hedeflere ulaşabilir. Yönetim yolunu, örneğin SSH'ı, kendi kaynak kısıtlamasıyla giriş yolunda tutun. Test sırasında eklenen izin verici forward kuralı, testten daha uzun yaşayan klasik kusurdur; bu yüzden bir değişiklikten sonra düzenlediğiniz satırı değil tüm kural kümesini gözden geçirin. Tünelin dinleyicisini açmak, bağlı her istemcinin ana makineyi yönetmesine izin değildir.

Drop ve reject eylemlerdir, politika değil

Temel zincirin politikası kabul eder ya da düşürür ve seçeneklerin tüm listesi budur, nftables başvurusunun dediği gibi. Reject, seçilmiş bir yanıtı olan kural eylemi olarak vardır; bu yüzden onu politika olarak yazmak hem nftables hem de iptables üzerinde başarısız olur. Pratikte drop istemciye hiçbir bilgi vermez, reject ise ona üzerinde işlem yapabileceği bir hata verir.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Bu krokiyi yapıştırılacak bir dosya değil, bir kararın biçimi olarak okuyun, çünkü adres aralıkları örnektir. SSH bağlantı noktasında açık bir reject, yetkisiz bir istemciyi zaman aşımını beklemek yerine bir saniyede başarısız kılar ve bu kendi hata ayıklamanızı kısaltır. Sessizlik rastgele taramayı caydırır ve yetkili kullanıcıya hiçbir şey söylemez. Hizmet başına seçin ve nedenini yazın, yoksa bir sonraki kişi geri alır.

Gerçekten ihtiyaç duyduğunuz denetim trafiğini koruyun

Tüm ICMP'yi engellemek, yol MTU keşfini bozan popüler bir varsayılandır ve belirti, kurulan ama daha büyük paketlerde tıkanan bağlantıdır. IPv6'da komşu keşfi kendi ICMPv6 türlerine bağlıdır ve bunları düşürmek, herhangi bir TCP kuralına bakılmadan önce bağlantıyı koparır. İkisi de kapsamlı izinler olarak değil, adlandırılmış bağımlılıklar olarak izin listesine girer. Keşfi sessizce bozan bir politika, biraz tanılama trafiğine izin verenden daha kötüdür.

Kendi başlattığınız bağlantılar için established ve related durumlarına izin verin ve yanıtları durum izleyen motora bırakın. Sonra yanıt yolunun daha dışarıda engellenmediğini doğrulayın, çünkü yalnızca giden trafiğe konan üst kısıtlama, ana makineye yüklemek üzere olduğunuz aynı zaman aşımını üretir.

Eski yolu bırakmadan önce kurtarmayı kanıtlayın

Bir konsol oturumunu açık tutun, değişikliği uygulayın ve başka bir terminalden tamamen yeni bir yönetim bağlantısı açın. Var olan oturum hiçbir şeyi kanıtlamaz, çünkü her yeni oturum açmayı engelleyen bir kuraldan sağ çıkabilir; bu da onu güvenlik duvarı işinde en inandırıcı yanlış pozitif yapar. Bir izleme sistemi ana makineyi denetliyorsa, ilk uyarıdan sonra değil, değişiklikten önce kaynak adresini ekleyin. Sonra bir büyük ve bir küçük paket deneyerek keşfin hâlâ çalıştığını kanıtlayın.

Bir VPN hizmeti için, hiç bağlanmamış bir istemciden tekrarlayın, çünkü sürdürülen bir oturum yenisinin pazarlık etmesi gereken durumu yeniden kullanabilir. Geçen tam kural kümesini bir sağlama toplamı veya kopyayla birlikte yazın, böylece sonraki düzenleme tahmin yerine karşılaştırılabilsin. Kural sırasının sahibiyle koordine olun, çünkü daha önceki bir kural sizin eklediğinizi sessizce yener.