Re: [libvirt] [PATCH] nwfilter: extensions of docs with advanced filtering topics

On 06/17/2010 06:10 PM, Stefan Berger wrote: > As requested, here a couple of paragraphs about the recently added > statematch attribute and some advanced (and tricky) traffic filtering > topics. > > Signed-off-by: Stefan Berger<stefanb(a)us.ibm.com> > > --- > docs/formatnwfilter.html.in | 117 > > + a VM. As an example, if a VM has TCP port 8080 > + open, clients may connect to it on port 8080. The tracking of the > + connection then prevents the client from initiating a connection from > + (TCP client) port 8080 to the host back (after previously having > That came across awkwardly to me. How about: As an example, if a VM has TCP port 8080 open asa server, clients may connect to the VM on port 8080. The tracking of the connection then prevents the VM from initiating a connection from (TCP client) port 8080 back to a remote host that has previously gained access to the VM. (Am I understanding your intent here?) > + gained access to the VM). More importantly, tracking helps to prevent > + remote attackers to establish a connection back to a VM for example > + if the user inside the VM has established a connection to > + port 80 on an attacker site, then the attacker won't be able to > + initiate a connection from TCP port 80 towards the VM. > Again, awkward wording: More importantly, tracking helps to prevent remote attackers from establishing a connection back to a VM. For example, if a user inside the VM established a connection to port 80 on an attacker site, then the attacker won't be able to initiate a connection from TCP port 80 back towards the VM. > + packets are exchanged. However, a newly initated connection may > force > s/initated/initiated/ > + an idle connection into TCP backoff if the number of allowed > connections > + is set to a too low limit, the new connection is established > + and hits (not exceeds) the limit of allowed connections and for > + example a key is pressed on the old ssh session, which now has > become > + unresponsive due to traffic being dropped. > + Therefore, the limit of connections should be rather high so that > + fluctuations in new TCP connections don't cause odd > + traffic behavior in relaton to idle connections. > s/relaton/relation/ But overall, it looks like a good patch, so ACK with those nits addressed.