On 19/01/09 3:14 PM, "Jan Engelhardt" <jengelh@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
