Güvenlik duvarımız (Ubuntu 8.04) neden nihai paketi (FIN, ACK, PSH) bir RST ile reddediyor?

Arka planda, uzun zamandır güvenlik duvarımızla, bazen TCP istekleri zaman aşımına kadar HTTP isteklerinin kısmen yüklenmesini sağlayan sorunlar yaşadık.

Güvenlik duvarındaki trafiği izledikten sonra, bunun yalnızca belirli zamanlama koşullarında meydana geldiğini fark ettim, örneğin web sunucusu tüm istemci yükünü ACK göndermeden önce tüm yanıtı gönderdiğinde. [SYN, SYN / ACK, ACK] değiştirildi, REQUEST gönderildi ve ACK gönderildi ve ilk RESPONSE paketi alındı ​​ve ACK gönderildi, ardından web sunucusu yanıt gövdesinin geri kalanını tek çekimde gönderdi (8 paket) son FIN, PSH dahil) ve müşteri bunlardan herhangi birini ACK yapmadan önce, Güvenlik Duvarı web sunucusuna yönelik bir RST ile reddeder ve istemciyi sonsuz asılı tutar.

Güvenlik duvarının her iki tarafından paketlerle birlikte tüm wireshark izi. 192.168.126.161, istemcinin özel NAT'et IP adresidir. 172.16.1.2 web sunucusu IP'sidir (gerçek genel IP'yi göstermez) ve 10.1.1.1 güvenlik duvarı harici IP'sidir (gerçek genel IP'yi göstermez)

2105 0.086275 192.168.126.161  172.16.1.2       TCP 37854 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=89375083 TSER=0
2106 0.000066 10.1.1.1         172.16.1.2       TCP 37854 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=89375083 TSER=0
2107 0.002643 172.16.1.2       10.1.1.1         TCP http > 37854 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460
2108 0.007705 172.16.1.2       192.168.126.161  TCP http > 37854 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460
2109 0.006301 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
2110 0.000025 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
2111 0.000007 192.168.126.161  172.16.1.2       HTTP GET /test/style.css HTTP/1.1 
2112 0.000015 10.1.1.1         172.16.1.2       HTTP GET /test/style.css HTTP/1.1 
2113 0.001536 172.16.1.2       10.1.1.1         TCP http > 37854 [ACK] Seq=1 Ack=111 Win=32658 Len=0
2114 0.000014 172.16.1.2       192.168.126.161  TCP http > 37854 [ACK] Seq=1 Ack=111 Win=32658 Len=0
2115 0.002274 172.16.1.2       10.1.1.1         HTTP HTTP/1.1 200 OK  (text/css)
2116 0.000025 172.16.1.2       192.168.126.161  HTTP HTTP/1.1 200 OK  (text/css)
2117 0.005689 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=1461 Win=8760 Len=0
2118 0.000024 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=1461 Win=8760 Len=0
2119 0.001536 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2120 0.000026 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2121 0.000007 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2122 0.000023 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2123 0.000313 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2124 0.000030 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2125 0.000007 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2126 0.000023 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2127 0.000009 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2128 0.000023 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2129 0.001108 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2130 0.000035 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2131 0.000008 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
2132 0.000022 172.16.1.2       192.168.126.161  HTTP Continuation or non-HTTP traffic
2133 0.000007 172.16.1.2       10.1.1.1         HTTP Continuation or non-HTTP traffic
REJECT-->
2134 0.000089 10.1.1.1         172.16.1.2       TCP 37854 > http [RST] Seq=111 Win=0 Len=0
CLIENT FIRST ACK-->
2135 0.002421 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=2921 Win=11680 Len=0
2136 0.000033 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=2921 Win=11680 Len=0
2137 0.000007 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=4381 Win=14600 Len=0
2138 0.000014 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=4381 Win=14600 Len=0
2139 0.000008 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=5841 Win=17520 Len=0
2140 0.000014 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=5841 Win=17520 Len=0
2141 0.000007 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=7301 Win=20440 Len=0
2142 0.000013 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=7301 Win=20440 Len=0
2143 0.000007 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=8761 Win=23360 Len=0
2144 0.000015 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=8761 Win=23360 Len=0
2145 0.000007 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=10221 Win=26280 Len=0
2146 0.000013 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=10221 Win=26280 Len=0
2147 0.001059 192.168.126.161  172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=11681 Win=29200 Len=0
2148 0.000018 10.1.1.1         172.16.1.2       TCP 37854 > http [ACK] Seq=111 Ack=11681 Win=29200 Len=0

Bu tabloya göre paket dolaşımını kazıyorum ve günlüğe kaydediyorum ve son gelen paket 2133'ün ham PREROUTING, conntrack, mangle-PREROUTING'i geçtiği görünüyor ancak daha sonra kayboluyor. Benim iptables benim REJECT kuralları var, ben tüm DROP kuralları günlüğü ve hiçbiri 2133 paket nerede kaybolduğunu gösterir.

Gelen filtrede TRACE hedefini kullanmak isterim, ancak ne yazık ki ubuntu 8.04, TRACE hedefi için destekle gönderilmez.

Bu nedenle, bazı dahili örtülü yönlendirme / bağlantı / yönetme kurallarının bazı nedenlerden dolayı bağlantıyı sıfırladığına inanıyorum. Belki trafik bazı DOS koruması tetikler, ancak ben bunu yapılandırmak / analiz etmek için hiçbir fikrim yok. En sinir bozucu şey, bir paketin reddedilmesi ve hiçbir şeyin günlüğe kaydedilmemesidir ...

Ayrıca bu dosyayı istemek Windows ana bilgisayarlarından% 100 çalışıyor, ancak belirli Linux ana bilgisayarlarında başarısız oluyor ve tüm isteklerin% 99.9'u geçiyor, ancak bazen paketlerin zamanlaması güvenlik duvarımızda bu davranışı tetikliyor.

EDIT Tamam, şimdi iptables giriş ton ekledim ve aşağıdaki gibi görünüyor (hala neden bilmiyorum!)

Güvenlik duvarını başarıyla geçen paketler için aşağıdaki adımlar uygulanır, tablo / adım referansları buradan

Table 3-3 step

2     raw-pre
      conntrack
3     mangle-pre
4     [nat-pre]
5     routing-decision -> destination forward
6     mangle-fwd
7     filter-fwd
8     mangle-post
9     [nat-post]

Reddedilen paket 2133 şu adımları uygular:

Table 3-1 steps for the incoming FIN,ACK packet 2133
2     raw-pre
      conntrack
3     mangle-pre
4     [nat-pre]
5     routing-decision -> destination local
6     mangle-input
7     filter-input
8     local process emits RST -> webserver

Table 3-2 steps for the outgoing RST packet 2134 in response to 2133
1     raw-out
2     routing decision
      conntrack
3     mangle-out
      reroute-check
4     [nat-out]
5     filter-out
6     mangle-post
7     nat-post

Garip olan şey, şimdi 5. adımda paket 2133 için yönlendirme kararının, diğer paketler için yönlendirme kararından farklı olmasıdır. Çalışan istekleri analiz ederken, örneğin takılmaz, son FIN bile düzgün bir şekilde yönlendirilir. Çekirdekte bir hata gibi görünüyor veya yönlendirme kararının bir şekilde durum bilgisi var.

DÜZENLE

Bu sorunlara neden olabilecek bir şey şu ki, trafik güvenlik duvarı ve yerel LAN arasında yönlendirilir, bu nedenle istemci LAN doğrudan L2 aracılığıyla güvenlik duvarına bağlı değildir.

                +---------------------------+       +------------------+                         +------------------------+
                |                           |       |      Router      |   (   Lab network    )  |                        |
( Internet ) -- + eth1                 eth0 +-------+                  +-- (                  ) -+ Client 192.168.126.161 |
                | 10.1.1.1   192.168.60.254 |       |                  |   ( 192.168.126.0/24 )  |                        |
                +---------------------------+       +------------------+                         +------------------------+

Bu resimde, 10.1.1.1 güvenlik duvarının harici IP adresini temsil eder, diğer tüm adresler kullanılan gerçek IP adresleridir.

Güvenlik duvarındaki yönlendirme tablosu:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.1.0        0.0.0.0         255.255.255.240 U     0      0        0 eth1
192.168.126.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.60.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         10.1.1.15       0.0.0.0         UG    0      0        0 eth1

10.1.1.0 ve varsayılan gw 10.1.1.15'in oluşturulduğunu, geri kalanının da kullanılanla aynı olduğunu unutmayın. Eth0'dan (192.168.60.254) laboratuvar ağına ulaşmak için 192.168.126.0/24 yolunu manuel olarak eklemek zorunda kaldım.

Burada, yerel ana bilgisayara (örneğin güvenlik duvarı) yönlendirildiği için reddedilen son paket 2133 için paket geçişinde bazı kapsamlı günlükler verilmiştir.

[16406874.374588] raw pre IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
[16406874.374625] mangle pre IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
[16406874.374667] mangle in IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
[16406874.374699] filter in IN=eth1 OUT= MAC=00:02:b3:b9:ff:b5:00:90:1a:10:06:88:08:00 SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=13739 DF PROTO=TCP SPT=80 DPT=53497 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 
[16406874.374780] mangle out IN= OUT=eth1 SRC=10.1.1.1 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=0 RES=0x00 RST URGP=0 
[16406874.374807] mangle post IN= OUT=eth1 SRC=10.1.1.1 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=0 RES=0x00 RST URGP=0 
[16406874.378813] mangle pre IN=eth0 OUT= MAC=00:02:b3:b9:ff:b4:00:90:1a:10:0c:dd:08:00 SRC=192.168.126.161 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=35424 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=11680 RES=0x00 ACK URGP=0 
[16406874.378863] mangle fwd IN=eth0 OUT=eth1 SRC=192.168.126.161 DST=172.16.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=62 ID=35424 DF PROTO=TCP SPT=53497 DPT=80 WINDOW=11680 RES=0x00 ACK URGP=0 

Bir kez daha, fw harici IP'miz 10.1.1.1 ile değiştirildi ve NAT'ed ağının dışındaki web sunucusunun ipi 172.16.1.2 ile değiştirildi

Son Dakika Haberleri EDIT!

Tamam son deneyin RST paket DROP oldu, çok çok ilginç, ben dosyaları talep sorun var web sunucusuna hedef tüm RST paketleri düştü bir iptables kuralı ekledi. Ve sonra çalıştı , düşürülür yukarıdaki günlüğüne geçen FIN, ACK, PSH paketi 2133 örneğin, ama RST düştü çünkü web sunucusu ACK en karınca ardından son paket retransmitt karar tüm paket 2133 kez daha almak için zamanı var ve şimdi kontrack modülü ACK'nin istemciden geri döndüğünü gördüğü ve son ACK, FIN paketinin son yük ile izin verdiği için güvenlik duvarından geçiyor.

Bu kesinlikle bir zamanlama / pencere problemidir, bu belirli dosya, ACK'ların istemciden zamanlamasıyla, kontroldeki son paketi web sunucusundan reddeden bir şey tetikler.

Şimdiye kadar, googling ve Kernel doc'ın okunması, bu davranışa neden olabilecek hiçbir şey açığa çıkarmaz, bir sonraki adım, yönlendirme / bağlantı modülü için çekirdek kaynak kodunu okumak olacaktır.

SORUN ÇÖZÜLDÜ

En azından şimdi tam olarak ne olacağını biliyoruz ve sorunu çözen bir geçici çözümümüz var.

Sergey, hata ayıklamada çok yardımcı olan çok değerli -m durum - durum INVALID eşleme kuralına dikkat çekti, şimdi INVALID paketleri için açık bir kural olmadan bir iptables kurulumunun tamamlanmadığını fark ediyorum, bu yüzden bazen garip davranışlar ortaya çıkıyor.

Geçersiz pakete neyin sebep olduğu için conntrack modülünde günlüğe kaydetmeyi etkinleştirirken, ne olduğu oldukça açık ve bu konuda şüphem vardı.

[16659529.322465] nf_ct_tcp: SEQ is over the upper bound (over the window of the receiver) IN= OUT= SRC=172.16.1.2 DST=10.1.1.1 LEN=1004 TOS=0x00 PREC=0x00 TTL=55 ID=40874 DF PROTO=TCP SPT=80 DPT=55498 SEQ=658735108 ACK=1194081763 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0 

Bir kez daha 172.16.1.2 harici web sunucusudur (yanlış davranır) ve 10.1.1.1 güvenlik duvarının harici adresidir.

Web sunucusu, istemcinin alma penceresinde reklamını yaptığından daha fazla veri iletir (conntrack durum doludur ve bunu doğrular), FIN paketi, alma penceresi gerçekten çok aşıldığından FIN paketinin geldiği zaman görünür. daha erken.

Bunun web sunucusundaki ağ kartındaki yanlış TCP boşaltmadan kaynaklanabileceğine inanıyorum. Bunu analiz etmeye başladığımda, web sunucusunda yakaladım ve tcpdump / wireshark izlerine göre, jumbo kareler çekirdeğin TCP katmanı tarafından yazıldı ve daha sonra ağ kartı tarafından MTU = 1500 ile daha küçük karelere bölündü. Açıkçası bu, web sunucusunda adreslenmelidir çünkü alıcının alma penceresinde daha fazla veri göndermek doğru TCP davranışı değildir.

Hem Polinom hem de Sergey değerli girdiler sağladı, ancak Sergey beni bağlantı / NAT modülünün paket geçişi ile ilgili tam davranışına işaret etti.

Benzer bir durum http://www.spinics.net/lists/netfilter/msg51408.html adresinde açıklanmıştır : NAT tarafından işlenmesi gereken bazı paketler KURULDU yerine INVALID olarak işaretlenmiş ve INPUT zincirine gitmiştir. Bunu -m state --state INVALIDkontrol etmek için bazı kurallar eklemelisiniz ve http://www.spinics.net/lists/netfilter/msg51409.html adresindeki yanıt, böyle INVALID paketinin her zaman DROPped olması gerektiğini önermektedir, çünkü NAT düzgün bir şekilde gerçekleştirilmemiştir. , bu nedenle bunların içindeki adresler yanlış olabilir.

Sorunlu paketleriniz gerçekten GEÇERSİZ olarak işaretlenmişse, ekleme işlemi iptables -I INPUT -m state --state INVALID -j DROPmuhtemelen sorunun etrafında çalışacaktır (kırık paket yerel işleme alınmayacak ve RST yanıtına neden olmayacak, TCP bir zaman aşımından sonra kayıp paketten kurtarılacaktır). Ardından, http://www.spinics.net/lists/netfilter/msg51411.html dosyasında açıklandığı gibi sorunu daha ayrıntılı bir şekilde hata ayıklamaya çalışabilirsiniz :

echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid

(Bu durumda, sorun yol boyunca bazı TCP ağ sağlama toplamı boşaltma bozukluğu ile birlikte bazı kırık ağ donanımlarından kaynaklanmıştır.)

Bu davranışı diğer güvenlik duvarı türlerinde gördüm ve davranış o kadar özdeşti ki, oraya fırlatacağımı düşündüm.

Sahip olduğum sorun, güvenlik duvarının kutudaki geçici bağlantı noktalarıyla aynı alana NAT olmasıydı. Çekirdek artık bağlantının yerel makine için yapıldığını varsaydığı için, bu ikisi çarpışırsa bu tam davranışa neden olur. Bu amaçla kontrol edebileceğiniz birkaç şey var. İlk olarak iptables'da (- to-port kullanarak) giden bağlantı noktası yapılandırmasını belirtiyor musunuz? Veya makinedeki geçici bağlantı noktası aralığını değiştirdiniz mi?

$ cat /proc/sys/net/ipv4/ip_local_port_range

Tanılamak için yakalamanızı ayarlayabilir ve RST'den önce 3 * MSL süresi içinde aynı harici fw ip, port combo kullanarak başka herhangi bir istek görüp görmediğinizi görebilirsiniz (bence ~ 180s).

Bu sorunun cevabından henüz emin olmasam da, eğer bu durumda olsaydım, ilk önce bunu ekarte edip birkaç şeye bakardım.

Bu yeniden üretilmesi kolay mı? Güvenlik duvarı kutusundan daha fazla tanı almak ve sorunun oluştuğunu görmek mümkün müdür? Yakalamaya çalışacağım:

$ netstat -anp
$ cat /proc/net/ip_conntrack

bağlantı noktasında yerel olarak bağlanan bir şey olup olmadığını ve sorun sırasında maskeli balo tablosunun nasıl göründüğünü görmeye çalışırken her saniyede bir.

Güvenlik duvarı RST giden iç istemciden gelen ACK bağlantının başarılı olmasına neden oluyor mu?

Son olarak, tüm günlükleri görüyor musunuz? Daha önce dmesg'i kontrol ettiniz mi? Emin olmak için syslog yapılandırmasındaki güvenlik duvarı kutusunda *. * Ayarladınız mı?

Ne bulduğunu bana haber ver! Soruda verdiğiniz bilgi miktarını gerçekten takdir ediyorum, teşekkürler.