Mrznuce FTP

[Richard Willmann]

> Je to tak, avsak ked sa prehladaju stavy, tak vysledkom nemusi byt iba 
> povol, ale aj zahod. PFko zahadzuje pakety, ktore odpovedaju zaznamu v 
> stavovej tabulke, ale prijaty paket neodpoveda zaznamenanemu stavu 
> (neocakavane flagy alebo sekvencne cislo). Spominany pripad je taky, podla 
> PF ide o uzavrete spojenie a pride paket so SYN flagom - podla PF taky 
> paket tu nema co robit, tak ho zahodi.

ano, mas pravdu. pozrel som sa do man pfctl/pf.conf. Je celkom nechutne ze 
to moze zahodit. Spravnejsie by asi bolo to nezahodit a pozriet sa do 
pravidiel.

> Ano, ak bol pripojeni niekto iny, tak je to jedno. Ale ked sa pripaja ta 
> ista IP adresa a pure-ftpd povedal klientovi, ze ma pouzit ten isty port, 
> tak by to bol problem, ak by sa zvolil este rovnaky zdrojovy port. Nie su 
> klienti za NATom?

su za NAT. Ak tomu spravne rozumiem, toto sa moze stat ak klient aj server 
"priliz skoro" pouziju rovnaku dvojicu portov.

Ale vratme sa k nastaveniu PFka. Ty hovoris, ze riesenim by mohlo byt 
nizenie tcp.closed na povadzme 20 sekund z povodnych 90.

Ale podla dokumentacie:

tcp.closed - The state after one endpoint sends an RST.

Tam ale predsa nikto neposiela RST...

Podla mna to funguje takto. Server povie klientovi "vezmi si data na porte 
XY" a zacne na porte pocuvat. Klient sa pripoji. Prebehne TCP 3W handshake. 
Server v cykle zacne data posielat a klient ich prijimat. Ked server posle 
vsetko, zavola close() a urobi tzv. aktivny close tj. posle FIN. Cele sa to 
dostane do stavu FIN_WAIT_1. Klient posle ACK pripadne aj s FIN. Tj. 
spojenie sa moze zavriet v jednom alebo dvoch krokoch na konci ktorych je 
ale TIME_WAIT. Ten by mal trvat 2 krat MSL. MSL je pre FreeBSD defaultne 30 
sekund (pozrel som to v sysctl).

Cize 60 sekund by kernel nemal pridelit ten isty port lebo cokolvek co nan 
pride z toho isteho paru IP/port (soketu) by mohol byt napr. lost duplicate.

K tomuto stavu by sa mal vztahovat PFkovy limit tcp.finwait:

                 The state after both FINs have been exchanged and the 
connec-
                 tion is closed.  Some hosts (notably web servers on 
Solaris)
                 send TCP packets even after closing the connection. 
Increas-
                 ing tcp.finwait (and possibly tcp.closing) can prevent 
block-
                 ing of such packets.

Ten je ale 45 sekund tj. menej nez 2 krat 30.

Jedine co ma napadlo je, ze na vine je pure-ftpd, ktory si vybera porty z 
rozsahu, ktory som mu povedal a serie na to, ze nesmie priliz rychlo 
znovupouzit tie iste.

Jedno zle riesenie, ktore ma napadlo je nastavit "volne porty" na rovnaky 
rozsah ako ten,  ktory som povedal pure-ftpd, vynut na nich keep state a 
nehovorit pure-ftpd, ktore porty ma pouzit. Toto by malo stacit k tomu, aby 
tie porty prideloval kernel.

Budem sa ale musiet pozriet do zdrojakov, ako ich prideluje. Resp. ci v 
pripade ak mu nepoviem ze chcem porty z tohoto rozsahu, ci necha ich 
pridelenie na kerneli.

V kazdom pripade ma celkom serie, ze ked som teraz nastavil debug misc a 
pustil tail -f na messages tak vsetko chodi :)


d~

rwi