Miroslav Lachman wrote:
"kernel: sonewconn: pcb '0xffff..hexadecimal..': Listen queue overflow:..."
Dokazal bys popsat, jaky typ utoku zpusobi tenhle problem?
Kdyz prichazi TCP spojeni, vytvori se pro nej struktura a ta se ulozi do fronty, odkud si to spojeni aplikace nasledne "vyzvedne" (API funkce accept() ).
Velikost fronty je dana bud' aplikaci (druhy parametr listen()) kde casto byva ovlivnitelna konfiguraci (treba ListenBacklog u Apache), nebo systemovym defaultem (kern.ipc.somaxconn sysctl).
Ve skutecnosti se ale pri naplneni fronty na 100% nedeje nic, teprve pri dosazeni 150% se prichozi spojeni zacnou zahazovat, pricemz se vypisuje citovana hlaska (ne s kazdym zahozenym spojenim, jen "jednou za cas").
Takze to zpusobi kazdy utok, ktery znamena, ze po doby delsi nez kratkou (pro kratke spicky je tam ta fronta) prichazi vic prichozich spojeni, nez kolik aplikace stiha obsluhovat.
Vetsi fronta dokaze vstrebat vetsi/delsi spicky, ale pokud jde o trvajici utok (nebo i trvale velke legitimni zatizeni), tak neni resenim problemu, protoze sebevetsi fronta se nakonec preplni.
U utoku nezbyva nez najit zpusob jak omezit pocet prichozich spojeni, u legitimniho zatizeni je nutne zvysit vykon aplikace.
Dan -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
