Permit *any* destination port from source ip

Permit *any* destination port from source ip

[Simon Labrecque]

Hi,

   I would like to have a specific connection act like an "authentication"
service; that is, when a connection to a specific port is made and once the
required data has passed between the 2 hosts, the client is now
authenticated, permitting access to other network services which are flagged
with the RELATED state (and not the NEW one).

   I implemented this in a very simple conntrack module. For example, I can
use something like when the module is in place:

iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j
ACCEPT

   ...and it works once the "parent" connection has "authenticated" the
client.

   However, currently it seems I can only specify 1 single destination port
in the expectation (this would be port 22 in my example above), wherever I
would like to be able to support *any* port (as we can with the source
port). The filtering would then be made using subsequent iptables rules.

   Is this possible? It seems it was possible a while ago (while
exp->mask.dst was still present), but this was removed and I don't see how I
can achieve the same functionality with the current structures. Am I missing
something?


   Thanks a lot!
-- 
Simon Labrecque

Re: Permit *any* destination port from source ip

[Jan Engelhardt]

On Monday 2009-01-19 21:11, Simon Labrecque wrote:
>
>   I would like to have a specific connection act like an "authentication"
>service; that is, when a connection to a specific port is made and once the
>required data has passed between the 2 hosts, the client is now
>authenticated, permitting access to other network services which are flagged
>with the RELATED state (and not the NEW one).

"RELATED" is for protocol-related connections and, I think, it should
not be abused to denote "AUTHENTICATED".

>   Is this possible? It seems it was possible a while ago (while
>exp->mask.dst was still present), but this was removed and I don't see how I
>can achieve the same functionality with the current structures. Am I missing
>something?

A userspace daemon can augment the ruleset after authentication,
either by calling iptables(8), or iptables-restore/save.

Re: Permit *any* destination port from source ip

[Simon Labrecque]

On 19/01/09 3:14 PM, "Jan Engelhardt" <jengelh@medozas.de> wrote:

> 
> On Monday 2009-01-19 21:11, Simon Labrecque wrote:
>> 
>>   I would like to have a specific connection act like an "authentication"
>> service; that is, when a connection to a specific port is made and once the
>> required data has passed between the 2 hosts, the client is now
>> authenticated, permitting access to other network services which are flagged
>> with the RELATED state (and not the NEW one).
> 
> "RELATED" is for protocol-related connections and, I think, it should
> not be abused to denote "AUTHENTICATED".
> 

Agreed; however, currently the network services are open (ie, they accept
NEW). I need to find a way to restrict access to those services *without*
modifying the applications/services, because they are closed, and ideally
without deploying new applications/daemons.

>>   Is this possible? It seems it was possible a while ago (while
>> exp->mask.dst was still present), but this was removed and I don't see how I
>> can achieve the same functionality with the current structures. Am I missing
>> something?
> 
> A userspace daemon can augment the ruleset after authentication,
> either by calling iptables(8), or iptables-restore/save.
> 

I agree too that a userspace daemon would better fit the philosophy of
netfilter/iptables, but it's not practical as a real solution in this
particular case. 

Currently, my conntrack module takes a list of "child" ports for which it
sets expectactions, but those same ports are duplicated in the iptable
rules. It seems to me it would be a lot cleaner to just maintain the
ports/rules in a single place, ie, in iptables (as, of course, I'm using a
DROP policy on INPUT on everything not explicitely ACCEPT'ed).

If there's no way to flag a connection as RELATED for any destination port
(given a known source and destination IP), then I guess I'll have no choice,
but I'm still not sure if it's possible or not (beside the fact that this
wouldn't be a *best practice*).

Thanks!

Simon Labrecque

Re: Permit *any* destination port from source ip

[Jan Engelhardt]

On Monday 2009-01-19 21:27, Simon Labrecque wrote:
>On 19/01/09 3:14 PM, "Jan Engelhardt" <jengelh@medozas.de> wrote:
>> On Monday 2009-01-19 21:11, Simon Labrecque wrote:
>
>If there's no way to flag a connection as RELATED for any
>destination port (given a known source and destination IP), then I
>guess I'll have no choice, but I'm still not sure if it's possible
>or not (beside the fact that this wouldn't be a *best practice*).

The conntrack(8) tool allows you to set up expectations and so on
from userspace.

Re: Permit *any* destination port from source ip

[Simon Labrecque]

> On Monday 2009-01-19 21:27, Simon Labrecque wrote:
>> On 19/01/09 3:14 PM, "Jan Engelhardt" <jengelh@medozas.de> wrote:
>>> On Monday 2009-01-19 21:11, Simon Labrecque wrote:
>> 
>> If there's no way to flag a connection as RELATED for any
>> destination port (given a known source and destination IP), then I
>> guess I'll have no choice, but I'm still not sure if it's possible
>> or not (beside the fact that this wouldn't be a *best practice*).
> 
> The conntrack(8) tool allows you to set up expectations and so on
> from userspace.

Would maybe work, but then again this would require deployment of new
applications. Also, if it's possible to modify the expectations as needed
using conntrack-tools (haven't tried yet), I would expect it would be
possible to do it directly in the module... no?

Simon Labrecque