[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 06/18/2010 11:45 AM, Eric Blake wrote:
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 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.

With your comments addressed, your proposed texts largely used and some other parts slightly reworded, and a symptom for ssh clients pointed out as to what may otherwise cause one to start debugging, I now pushed this patch.

Thanks and regards,
   Stefan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]