Re: Permit *any* destination port from source ip

[Simon Labrecque <simon@clubbeadplus.com>]

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