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@xxxxxxxxxx>
---
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list