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

[Stefan Berger]

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 at 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