Re: new match extension to implement port knocking in one

On 10/23/06, Eric Leblond <eric@???> wrote:
> Le lundi 23 octobre 2006 à 10:31 -0300, J. Federico Hernandez a écrit :
> > On 10/18/06, Pablo Neira Ayuso <pablo@???> wrote:
> > > J. Federico Hernandez wrote:
> > > > On 10/17/06, Eric Leblond <eric@???> wrote:
> > > >> >
> > > >> > When all you want is to open a port after a correct sequence of
> > > >> > knocks, instead of sending from the kernel all the knocks to the
> > > >> > userspace, and then setting a new iptables rule so the kernel firewall
> > > >> > takes an action, it would be better to leave the whole work to the
> > > >> > kernel and avoid the transition kernel->userspace->kernel.
> > > >>
> > > >> kernel->userspace->kernel is really not a problem for nowadays computer.
> > > >> Simply think about snort-inline which is able to handle a great amount
> > > >> of traffic.
> > > >
> > > > the fact that nowadays computers have much more power, doesn't mean
> > > > that you can forget about a simple, less complex and correct design.
> > >
> > > I'm unsure that putting things in kernel implies less complexity and
> > > correct design, it depends on the case.
> > >
> >
> > Putting things in kernel doesn't mean less complexity, but on port
> > knocking case means a correct design and better performance.
> >
> > WIth traditional port knocking applications you have to switch
> > kernelspace ->userspase->kernelspace several times. Furthermore, you
> > have to load the regex engine for parsing the firewall logs and you
> > have to access the hard disk each minute for parsing logs files. In
> > our opinion, this is not a correct design.
>
> We do not understand each other about the way I (and pablo I think)
> propose you to do because the solution I thought off do not use log
> analysis...
>
> Let's say port knocking is 4138 2345 4577 to open port 22
>
> Then just do
> iptables -A INPUT -p tcp -m multiport --dports 4138,2345,4577,22 -j QUEUE
>
> Your userspace application wait for packets coming from queue, drop them
> when they come from knocking ports (but store the knock) and accept
> packet to port 22 if we just had a correct knocking sequence before.
>
> This is simple, do not use complex algorithms and should fit on all
> small routers.
>

The idea of having an userspace application receiving the queued
packets from netfilter is much better than scanning firewall logs.

Actually, I see this issues in the userspace solution:

1. (+) Could be safer to run the portknocking logic in userspace,
rather than kernel.
2. It is not clear from a admin point of view that a portknocking
system is running.
3. The port 22 traffic is suffering a small penalty because of
travelling kenel->userspace->kernel before arriving to the service.
4. There is not a single point of configuration, if you want to change
the knock sequence for instance, you have to change the app and then
the iptables rule.
5. question: Is there a way to set two or more different queues? to
avoid receiving in the userspace, packets from other rules with the
"-j QUEUE"

Luis.