On Mon, Jan 20, 2003 at 01:14:41PM +0100, HOLTZL Peter wrote:

On 2003 Jan 20, Kosa Attila wrote:

...

Van snmp proxy, vagy csak sima plug-gal lehet atvinni?

egyelore nincs

Ez azt jelenti, hogy van kilatasban? Ha igen, mikorra varhato? 2-es Zorphoz egy UDP-s peldat tudnal mutatni? A kernelbe kell valami "trukkos" dolog, mint a 2.2-es sorozatnal az udp-patch? -- Udvozlettel Zsiga

On Mon, Jan 20, 2003 at 01:46:39PM +0100, HOLTZL Peter wrote:

...

Ez azt jelenti, hogy van kilatasban? Ha igen, mikorra varhato?

Kerdes jo. A fejlesztok biztos tudjak a valszt. (megkerdeztem: majd lesz, ez a valsz)

...

2-es Zorphoz egy UDP-s peldat tudnal mutatni? A kernelbe kell valami "trukkos" dolog, mint a 2.2-es sorozatnal az udp-patch?

Nincs trukk, ugyanugy kell, mint a tcp:) A 2.2-esben az udp patch is csak a ForgeClientSourceNAT hasznalatahoz kellett!

Listener helyett Receiver kell, valahogy igy: def udp(): Service('snmp', PlugProxy) Receiver(SockAddrInet('192.168.0.1', 50163), 'snmp') 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: class SNMPProxy(PlugProxy): def config(self): PlugProxy.config(self) self.secondary_mask = 0xC self.secondary_sessions = 100 Ezek kozul a secondary mask egy bitmask, ami megadja, hogy mely sessionok kerulhetnek ugyanabba a plugba. Itt a funkcio leirasa (ez a nalad levo peldanynal valoszinuleg meg nincs dokumentalva): Secondary sessions Plug supports several sessions in the same proxy instance (e.g. in the same thread), effectively reusing proxy instances. As new sessions enter the proxy via a fastpath, using secondary sessions might decrease firewall load significantly. When a new connection is accepted, Zorp looks for the appropriate proxy instance which is willing to accept secondary sessions. If there is none, a new proxy instance is started. An already running proxy instance is appropriate if it is willing to accept secondary channels and the criteria about secondary sessions set by the administrator match. The critera in plug is set by the 'secondary_mask' attribute, consult the attribute documentation for more details. Es itt vannak az attributumok: secondary_sessions -- [INTEGER:10:RW:R] The number of possible secondary sessions within a single plug instance. secondary_mask -- [INTEGER:0:RW:R] an integer specifying which properties of an established session is marked important. If all important properties match, a secondary session is handled by this plug proxy given the new session would not exceed 'secondary_sessions'. This is a bitfield with the following interpretation: bit 0 means source address, bit 1 means source port, bit 2 means destination address, bit 3 means destination port. A 0xC ertek nagyjabol azt jelenti, hogy ha ugyanarra a gepre, ugyanarra a portra iranyulo keres van barmelyik belso halozati gep eseten ugyanarra a plugra kerul. Arra vigyazz, hogy a masodlagos kapcsolatok nem erintik a Python-t, ezert nem szamitanak a Pythonban megadott access control tenyezok (zona, stb) 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.) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

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