İptable'ın bağlantı modülü paket durumlarını ne zaman izler?
Öncelikle durumları saklaması gerekir. Kullandığım bazı eski BSD güvenlik duvarlarıyla, sanırım IPFW olarak adlandırıldı, "ayrılan paketin durumunu takip et" şeklinde bir kural koyuyordum ve bu, arayüzlerin giden yönüne yerleştirildi. Ardından, giden yönü kuralı tarafından oluşturulan bu durumlarla karşılaştırarak onları kontrol eden gelen yöne ilişkin başka bir kural. Yani eskiden 2 kural vardı: (1) durumlar tablosunu doldurmak için, bu giden yönündeydi ve (2) durumlar tablosunu aramak için, bu gelen yöndeydi.
Ancak connntrack ile, INPUT zincirinde şu kural gibi uygulandığını görüyorum:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Bu beni meraklandırıyor, bu ifade aslında ne yapıyor?
- Bilgilerini durum tablosuna koyarak bu kuralla eşleşen paketleri izlemeye başlayacağını mı söylüyor?
- Yoksa zaten eyalet bilgisine sahip olduğunu ve buna dayalı olarak gelen mesajlara karşı hareket edeceğini mi söylüyor? (örneğin önceden kabul edilmiş bir bağlantıya aitlerse kabul edilsin mi?). Ama bu durumda, eyaletler tablosu nerede doldu? Hangi kuralı yapar? Yoksa kuralsız ve üstü kapalı mı?
Yanıtlar
Netfilter ve conntrack'in tanıtım sunumu
Öncelikle, Netfilter ve General Networking'deki Paket akışı ile ilgili zorunlu şema:
Netfilter, kendisini ağ yığınının geri kalanına ekleyen paket filtreleme çerçevesidir ("yönlendirme kararı" ve diğer beyaz yuvarlak kenarlı kutu parçalarıyla temsil edilir). Netfilter, diğer alt sistemler ve "istemciler" için kancalar ve API'ler sağlar. Bu parçalar arasında conntrack (bağlantı izleyicisi) ve iptables (veya nftables ) bulunur. Netfilter ve conntrack arasındaki ayrım oldukça belirsiz. Conntrack'i Netfilter'ın entegre bir parçası olarak düşünebilirsiniz .
Bir paketin geçtiği çeşitli adımları açıklayan şemada, bir noktada (ham / PREROUTING ve mangle / PREROUTING arasında veya raw / OUTPUT ve mangle / OUTPUT arasında) paketin bağlantı yollarını geçtiğini görebilirsiniz .
Bu noktada, conntrack kendi arama tablolarında arama yapacaktır (çekirdek belleğinde tutulan mini bir arama veritabanı):
- bu paketin özellikleri bulunamazsa (ve ham tabloda UNTRACKED olarak belirtilmemişse), yeni bir bağlantı çift yönlü tuple girişi (protokol, daha sonra belirli aile ve protokol bilgileri: ilk kaynak ve bağlantı noktası, ilk hedef ve bağlantı noktası, yanıt kaynağı ve bağlantı noktası, yanıt hedefi ve bağlantı noktası (NAT veya ICMP için yankı yanıtı eşleştirme yankı isteği gibi bazı garip protokoller söz konusu olmadıkça, genellikle son ikisi tersidir) akışı açıklayan YENİ durumuyla oluşturulur.
- önceki bir girişle eşleşirse (herhangi bir yönde) ve bu akışın durumuyla uyumluysa, akış durumu değiştirilebilir (örneğin: daha önce durum böyle değilse YENİ'den KURULDU'ya geçiş).
- belirli bir nedenden ötürü paket, özelliklerine sahip olmasına rağmen mevcut bir akışla eşleşemezse (örneğin: bir yeniden iletimin başarılı bir şekilde başlatılmasından sonra alınan geç bir TCP paketi, dolayısıyla sıra ve SACK değerleri açısından pencerenin dışında olmak) paket INVALID olarak etiketlenecek.
- İLGİLİ gibi birkaç başka durum daha vardır: bu, akışın bir parçası olmayan, başka bir mevcut (yani: veritabanındaki) akışla ilişkilendirilebilen yeni bir akışla ilgili olan paketlerle ilgilidir. İki örnek bir paket alıcı oluşturulan bir ICMP hata (örneğin: UDP bağlantı ulaşılamaz) çekirdek modülü gibi özel bir protokol yardımcı zaman ya da
nf_conntrack_ftpbir eklenti, conntrack alt sistemi, bir paket algılar olduğu ayrı verilerinin bir kısmı ilişkili akış komut akışında yapılan PASV / EPSV veya PORT / EPRT FTP komutlarıyla (bağlantı noktası 21'de).
Soruyu ele almak
Bütün bunlar söyleniyor, işte iki merminizin cevapları:
ana ağ ad alanında conntrack , modülleri (olası ilgili protokole özgü alt modüller dahil) yüklenir yüklenmez bağlantıları izlemeye başlar. İlk olmayan ağ ad alanları (kapsayıcılar ...) için bu, aynı zamanda başka bir alt sistemin ona başvurmasını gerektirir (örneğin, OP'nin iptables'ın bağlantı modülü veya
conntrackdaha sonra açıklanan komutu bir kez kullanma ). Bu varsayılandır ve bağlantı alt sistemi, bu paketin izlenmemesi için onu görmeden önce , bir paket özellikle TRACKED olarak işaretlenmelidir . Linux'ta, izlemeye ihtiyaç duyulmayan yalnızca birkaç durum vardır, ancak o zaman tabii ki durum bilgisi olan güvenlik duvarı ve durum bilgisi olan / dinamik NAT artık kullanılamayacaktır (ilk etapta UNTRACKED'i kullanmayı bile gerektirebilecek steless NAT, yine de olabilir. yapılır, ancak iptables . tc veya nftables ile değil ). Conntrack'in bazı paketleri işlemesini önlemek için bu tür bir iptables kuralı kullanılabilir (örneğin: port 80 / tcp):iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrackPaket filtre / GİRİŞ'ten geçip bu kurala ulaştığında:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTİptables kendine özgü çekirdek modülü
xt_conntracksorgular conntrack (çeşitli ilgili çekirdek modülleri ile alt sisteminf_conntrack*) ve arama veri bankasında bu paketin durumu hakkında sorar. Cevap iseRELATEDveyaESTABLISHEDpaket eşleşiyorsa ve KABUL kararı ile devam ederse . Aslında sonuç, arama ilk kez yapıldığında (genellikle bağlantı ile ) paket içinde zaten önbelleğe alınmıştır , bu nedenle bu ucuz bir "arama" dır. Bu nedenle bu, önceden kabul edilmiş akışları işlemek için genel bir kuraldır. Bu akışlar, başlangıçta açıkça bahseden veya sadece ondan bahsetmeyen ancak bu genel kuralın sonrasına yerleştirilen kurallarda kabul edilebilir (ancak genellikle bunu yapmadan önce DROP edilmesi gereken GEÇERSİZ durumunu aklınızda bulundurun).-m conntrack --ctstate NEWbir kurşun ekleyerek: Gelen paketler ve giden paketlerin taşıma PREROUTING ve ÇIKIŞ (hatta eğer simetrik görünmüyor) arasında oldukça simetriktir: conntrack arayüzleri PREROUTING yanı sıra ÇIKIŞ içinde (ve birkaç başka yerlerde, dikkate NAT olduğunu Conntrack ile çalışma , YENİ durumundaki iptables'ın nat tablosunu çaprazlama durumundaki ilk paketi hariç ). Bu, IPFW hakkında yazdığınız açıklamadan biraz farklı olabilir. Uygulamaları çalıştıran bir sunucu aynı zamanda giden akışları da kısıtlıyorsa, o zaman büyük olasılıkla , zaten kabul edilmiş gelen trafiğin giden yanıt paketlerinin geçmesine izin vermek için hem filtre / ÇIKIŞ hem de filtre / GİRİŞ içindeki aynı jenerik iptables kuralına ihtiyaç duyar .
Ek bilgiler
İle etkileşim adanmış araçlar vardır conntrack gelen alt-sistemin arama tabloları conntrack-araçları .
conntrack: conntrack tarafından işlenen arama tablolarının içeriğini sorgulamak, silmek veya güncellemek için .
Bazı örnekler.
İzlenen tüm girişleri (ek filtre olmadan büyük olabilir) aşağıdakilerle listeleyebilirsiniz:
conntrack -LSistem (özel LAN önünde örneğin bir yönlendirici veya VM ve konteyner çalıştıran) NAT yapıyorsa kullanabileceğiniz
--any-nat,--src-natya--dst-nattek ekran resp için. tüm NAT, tüm kaynak NAT (maskeli) veya tüm hedef NAT (tipik olarak iletilen bağlantı noktaları için):Conntrack olaylarının gerçek zamanlı izlenmesi :
conntrack -Econntrackd: iki ana amacı (bağlantı) akış muhasebesi ve istatistikleri veya yüksek kullanılabilirliğe sahip durum bilgisi olan güvenlik duvarı küme durum senkronizasyonu olan bir arka plan programı .
Bağlantı izleme, Netfilter'ın ayrı bir işlevidir ve IPTables ile yapılandırılmamıştır.
Resimde conntrackGİRİŞ yolunda iki ve ÇIKIŞ yolunda bir adım vardır . Bu adımlar, ayrı paketleri bağlantı izleme tablosunda izlenen mevcut bağlantılarla ilişkilendirir veya tabloda yeni bağlantı izleme girişleri oluşturur.
Conntrack işlevselliği bir Linux çekirdek modülüdür ve genellikle çekirdekte varsayılan yapılandırmada bulunur.
Conntrack işlemi, net.netfilter.nf_conntracksysctl değerleri ayarlanarak ayarlanabilir .
İkinci alternatifiniz ne olduğu. Durum bilgisi Conntrack fonksiyonu tarafından kaydedilir ve IPTables kuralı bilgi için sadece Conntrack tablosuna başvurur.