drop packetu uz zavreneho spojeni
Libor Chocholaty
libor_ml1 na mts.cz
Čtvrtek Prosinec 1 11:23:37 CET 2005
Vlada Macek wrote:
>Mam netfilter serveru nastaveny na blokaci odchozich spojeni, na zacatku
>retezu OUTPUT je obvyklé "RELATED,ESTABLISHED -j ACCEPT". Nekolikrat
>denne mi ale server zahodi odchozi paket ukoncujici spojeni iniciovane
>puvodne klientem. Stava se to na nejruznejsich sluzbach, budu ilustrovat
>na postfixu, ktery hezky loguje otevreni i zavreni spojeni:
>
>Dec 1 05:59:20 kernel: Fw:ACCEPT: IN=eth0 OUT= SRC=<ip_klienta>
>DST=<ip_meho_serveru> LEN=64 TOS=0x10 PREC=0x00 TTL=33 ID=29869 DF
>PROTO=TCP SPT=2858 DPT=25 WINDOW=53760 RES=0x00 SYN URGP=0
>Dec 1 05:59:21 postfix/smtpd[28288]: connect from unknown[<ip_klienta>]
>Dec 1 06:04:21 postfix/smtpd[28288]: timeout after CONNECT from
>unknown[<ip_klienta>]
>Dec 1 06:04:21 postfix/smtpd[28288]: disconnect from unknown[<ip_klienta>]
>Dec 1 06:06:39 kernel: Fw:NO_OUTPUT: IN= OUT=eth0 SRC=<ip_meho_serveru>
>DST=<ip_klienta> LEN=88 TOS=0x00 PREC=0x00 TTL=64 ID=24221 DF PROTO=TCP
>SPT=25 DPT=2858 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
>
>smtpd[28288] mezitim nic jineho neloguje. Jak je videt, 139 sekund pote,
>co smtpd spojeni zavrel, se server jeste snazi poslat FIN/ACK. Pripada
>mi to neskodne, mohl bych to jednoduse odfiltrovat bud logcheckem nebo
>explicitne FIN/ACK povolit v OUTPUT. Zajima me ale pricina a pripadne
>jak ji odstranit.
>
>Diky za napady.
>
>
>
Podle toho, jakja si to pamatuju, FIN rika, ze ja uz nic neposlu. Takze
kdyz prijde i z druhe strany FIN je normalni a ocekavana situace. Taky
lze TCP spojeni rusit pomoci RST, pak bych necekal, ze mi neco prijde.
Ale na FIN klidne.
Tak to vidimja, vice viz RFC793.
Libor
Další informace o konferenci Linux