On Mon, Jan 20, 2003 at 02:53:24PM +0100, Kosa Attila wrote:
On Mon, Jan 20, 2003 at 02:35:25PM +0100, Balazs Scheidler wrote:
On Mon, Jan 20, 2003 at 01:46:39PM +0100, HOLTZL Peter wrote:
ha nagy mennyisegu snmp forgalom elkepzelheto, akkor erdemes bekapcsolni a plug masodlagos kapcsolat lehetoseget, ami azt jelenti, hogy nem minden session indit szalat, egy szallal tobb kapcsolat is lekezelheto. Ezt valahogy igy lehet: [...] Igazabol ha SNMP forgalom pontosan egy korbehatarolhato geprol erkezik, ahol meg tudsz bizni a gep forras IP-jeben (merthogy UDP-nel az konnyen hamisithato), akkor nem kell szenvedni a masodlagos kapcsolatokkal, ha viszont nem, akkor konnyen eldugithatjak a tuzfaladat. (azon mondjuk lehet segiteni egy max_instances= Service parameterrel.)
Jol ertem, hogy nem javaslod a masodlagos kapcsolatok engedelyezeset? A doksit koszi, at fogom nezni.
a masodlagos kapcsolatok lete egy performance hack, ami az UDP mukodesebol kovetkezoen szukseges. a tuzfal maga attekinthetobb, ha nincsenek masodlagos kapcsolatok, mivel az megkeruli a Pythonos access controlt, es csak egy _nagyon_ egyszeru bitmezovel helyettesiti. nem elnek a szolgaltatasra rakott egyeb limitek sem (pl. max_instances), nagyjabol olyasmi mint a Fast forwarding a kernelben, amikor az egyik halokartyarol kozvetlenul a fo memoria erintese nelkul masolodnak a csomagok (megkerulve az IP stacket es a csomagszurest) ha birod CPU-val es nem felsz a DoS-tol, akkor szerintem ne hasznald, ha viszont barmelyiknek a leghalvanyabb eselye is van, akkor egyszeruen szukseges. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1