Re: new match extension to implement port knocking in one

Re: new match extension to implement port knocking in one

[Luis Floreani]

> If you're interested in port knocking, you might want to read this
> paper:  http://www.acsac.org/2005/abstracts/156.html  It covers security
> issues relating to port knocking in detail, and presents an architecture
> for solving most of them.
>
> Full disclosure:  I wrote that paper.  Feel free to contact me if you
> have questions.
>
> Rennie deGraaf
>


In our implementation, for security, we are using the Tumbler protocol, we
found it simple yet powerful, check it out here:
http://tumbler.sourceforge.net/.

Well, hope to read you paper soon and give you some feedback.

Luis

Re: new match extension to implement port knocking in one

[Alexey Toptygin]

On Wed, 11 Oct 2006, Luis Floreani wrote:

>> If you're interested in port knocking, you might want to read this
>> paper:  http://www.acsac.org/2005/abstracts/156.html  It covers security
>> issues relating to port knocking in detail, and presents an architecture
>> for solving most of them.
>> 
>> Full disclosure:  I wrote that paper.  Feel free to contact me if you
>> have questions.
>> 
>> Rennie deGraaf
>
> In our implementation, for security, we are using the Tumbler protocol, we
> found it simple yet powerful, check it out here:
> http://tumbler.sourceforge.net/.

It seems that Tumbler is not capable of working across NAT, unless the 
client can somehow obtain its public IP address. Also, it relies on clocks 
being synchronized, since authentication will fail if the UTC time in 
minutes is not identical on the client and server. Tumbler is not as 
stealthy as the techniques in Rennie deGraaf's paper, since it uses an 
open UDP port.

Finally, I doubt the cryptographic security of the Tumbler protocol - it 
relies on a SHA256 hash over the UTC time (in minutes), the client's IP 
and the shared secret. Observing a few authentications from the same 
client will give you hashes of strings with known prefixes (time + IP) and 
a fixed suffix (the secret). The insertion of the optional username 
between the time and IP (not at the end as documented) increases security 
slightly by making the pattern known,fixed,known,fixed but I think some 
attacks will still be possible because there are multiple ralated 
plaintexts with no random parts.

 			Alexey

Re: new match extension to implement port knocking in one

[Alexey Toptygin]

On Thu, 12 Oct 2006, Alexey Toptygin wrote:

> Finally, I doubt the cryptographic security of the Tumbler protocol - it 
> relies on a SHA256 hash over the UTC time (in minutes), the client's IP and 
> the shared secret. Observing a few authentications from the same client will 
> give you hashes of strings with known prefixes (time + IP) and a fixed suffix 
> (the secret). The insertion of the optional username between the time and IP 
> (not at the end as documented) increases security slightly by making the 
> pattern known,fixed,known,fixed but I think some attacks will still be 
> possible because there are multiple ralated plaintexts with no random parts.

Never mind this last bit, I wasn't thinking clearly.

 			Alexey

Re: new match extension to implement port knocking in one

[Michael Rash]

On Oct 12, 2006, Alexey Toptygin wrote:

> On Wed, 11 Oct 2006, Luis Floreani wrote:
> 
> >>If you're interested in port knocking, you might want to read this
> >>paper:  http://www.acsac.org/2005/abstracts/156.html  It covers security
> >>issues relating to port knocking in detail, and presents an architecture
> >>for solving most of them.
> >>
> >>Full disclosure:  I wrote that paper.  Feel free to contact me if you
> >>have questions.
> >>
> >>Rennie deGraaf
> >
> >In our implementation, for security, we are using the Tumbler protocol, we
> >found it simple yet powerful, check it out here:
> >http://tumbler.sourceforge.net/.
> 
> It seems that Tumbler is not capable of working across NAT, unless the 
> client can somehow obtain its public IP address. Also, it relies on clocks 
> being synchronized, since authentication will fail if the UTC time in 
> minutes is not identical on the client and server. Tumbler is not as 
> stealthy as the techniques in Rennie deGraaf's paper, since it uses an 
> open UDP port.

Why not use fwknop in Single Packet Authorization mode?:

http://www.cipherdyne.org/fwknop/

(Disclosure: I wrote it).

Here are some of the highlights (parts of this are related to both the
original poster's question and the Alexey's observation above about the
open UDP port in Tumbler):

 - Support for both asymmetric and symmetric encryption via Rijndael and
   GnuPG.  If GnuPG is used, then fwknop verifies that the data is both
   signed and encrypted.  Any multi-packet port knocking scheme would
   have serious difficulty in using an asymmetric cipher because of the
   generally long key lengths and resulting size of encrypted data.
 - No open ports on the server side; all packet data is monitored via a
   sniffer.  Iptables should be configured in a default-drop stance for
   all protected services and for the port on which the SPA packet is
   sent (UDP 62201 by default, but fwknop also supports sending over
   ICMP and over a blind TCP ACK packet).
 - Automatic reconfiguration of the local iptables policy via the
   IPTables::ChainMgr perl module; this is not as cool as using a
   netlink socket to communicate to a userspace program, but doing the
   knock verification in the kernel itself limits your options for doing
   things like using GnuPG.
 - Because an encrypted payload is used, any access directive can be
   used instead of just a pre-determined set of access directives for
   which the hashes can be worked out as in the Tumbler protocol.  A
   full command channel is also supported by fwknop.
 - SPA packets are non-replayable in both asymmetric and symmetric
   encryption modes due to the fact that 16 bytes of random data is
   included within every packet, and the md5 sum is tracked (and written
   to disk) on the server side.
 - Support for multiple users, each with their own encryption keys and
   authorization rules.
 - Support for a time window over which an SPA packet is accepted (this
   feature can easily be disabled if time synchronization is a problem).
 - Custom patch against openssh, so (after fwknop is run against <host>
   for the first time so it can cache your command line arguments) you
   can just do:

ssh -K "-L <host>" user@host

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

Re: new match extension to implement port knocking in one

[Luis Floreani]

On 10/12/06, Alexey Toptygin <alexeyt@freeshell.org> wrote:
> On Wed, 11 Oct 2006, Luis Floreani wrote:
>
> >> If you're interested in port knocking, you might want to read this
> >> paper:  http://www.acsac.org/2005/abstracts/156.html  It covers security
> >> issues relating to port knocking in detail, and presents an architecture
> >> for solving most of them.
> >>
> >> Full disclosure:  I wrote that paper.  Feel free to contact me if you
> >> have questions.
> >>
> >> Rennie deGraaf
> >
> > In our implementation, for security, we are using the Tumbler protocol, we
> > found it simple yet powerful, check it out here:
> > http://tumbler.sourceforge.net/.
>
> It seems that Tumbler is not capable of working across NAT, unless the
> client can somehow obtain its public IP address.

Yes, with our implementation you need to know the public IP. On the
other hand, the Rennie implementation makes that easier, but from a
security point of view, both ways leaves the service open to the
public IP address, so anybody behind the NAT has the service port
open. That's a general problem with PK.

> Also, it relies on clocks
> being synchronized, since authentication will fail if the UTC time in
> minutes is not identical on the client and server.

it's very easy to sync a clock, you can do it with "rdate". e.g: $
rdate time-a.nist.gov

> Tumbler is not as
> stealthy as the techniques in Rennie deGraaf's paper, since it uses an
> open UDP port.

In our netfilter extension, the knock ports are CLOSED, also, the
server never sends an answer to any client knock, which really means
being "stealthy".

Re: new match extension to implement port knocking in one

[J. Federico Hernandez]

> On Oct 12, 2006, Alexey Toptygin wrote:
>
> > On Wed, 11 Oct 2006, Luis Floreani wrote:
> >
> > >>If you're interested in port knocking, you might want to read this
> > >>paper:  http://www.acsac.org/2005/abstracts/156.html  It covers security
> > >>issues relating to port knocking in detail, and presents an architecture
> > >>for solving most of them.
> > >>
> > >>Full disclosure:  I wrote that paper.  Feel free to contact me if you
> > >>have questions.
> > >>
> > >>Rennie deGraaf
> > >
> > >In our implementation, for security, we are using the Tumbler protocol, we
> > >found it simple yet powerful, check it out here:
> > >http://tumbler.sourceforge.net/.
> >
> > It seems that Tumbler is not capable of working across NAT, unless the
> > client can somehow obtain its public IP address. Also, it relies on clocks
> > being synchronized, since authentication will fail if the UTC time in
> > minutes is not identical on the client and server. Tumbler is not as
> > stealthy as the techniques in Rennie deGraaf's paper, since it uses an
> > open UDP port.
>
> Why not use fwknop in Single Packet Authorization mode?:

Why not using iptables to implement port knocking?
You won't depend on any daemon.

If you know the iptables syntaxis, you don't need to learn the daemon
syntaxis or its configuration.


-- 
Federico

Re: new match extension to implement port knocking in one

[Michael Rash]

On Oct 13, 2006, J. Federico Hernandez wrote:

> >On Oct 12, 2006, Alexey Toptygin wrote:
> >
> >> On Wed, 11 Oct 2006, Luis Floreani wrote:
> >>
> >> >>If you're interested in port knocking, you might want to read this
> >> >>paper:  http://www.acsac.org/2005/abstracts/156.html  It covers 
> >security
> >> >>issues relating to port knocking in detail, and presents an 
> >architecture
> >> >>for solving most of them.
> >> >>
> >> >>Full disclosure:  I wrote that paper.  Feel free to contact me if you
> >> >>have questions.
> >> >>
> >> >>Rennie deGraaf
> >> >
> >> >In our implementation, for security, we are using the Tumbler protocol, 
> >we
> >> >found it simple yet powerful, check it out here:
> >> >http://tumbler.sourceforge.net/.
> >>
> >> It seems that Tumbler is not capable of working across NAT, unless the
> >> client can somehow obtain its public IP address. Also, it relies on 
> >clocks
> >> being synchronized, since authentication will fail if the UTC time in
> >> minutes is not identical on the client and server. Tumbler is not as
> >> stealthy as the techniques in Rennie deGraaf's paper, since it uses an
> >> open UDP port.
> >
> >Why not use fwknop in Single Packet Authorization mode?:
> 
> Why not using iptables to implement port knocking?
> You won't depend on any daemon.
> 
> If you know the iptables syntaxis, you don't need to learn the daemon
> syntaxis or its configuration.
>
> Federico

Well, I agree that having an implementation that builds some port
knocking capabilities directly into iptables is a good thing for the
reasons you mention.  However, I would say that there are some design
considerations that warrant userspace implementations as well.  Users
should be able to select the system that offers the best security
properties, and putting both the authentication and authorization
verification code in the kernel is not always going to meet everyone's
needs.

(Sorry for the length of this email, but I want to be thorough).

First, port knocking as opposed to single packet strategies have some
serious problems:

- Hard to solve the replay problem
- Insufficient data transfer rate and reliability because of necessary
  time delays to enforce packet ordering to make reasonably sized
  data transfers (asymmetric encryption is not even an option)
- Knock sequences look like port scans
- Trivially easy to bust a knock sequence just by spoofing a duplicate
  packet into the sequence

The NAT issue and the lack of association between a knock sequence and
follow-on connection mentioned in deGraaf's paper are important, but I
think we basically have to live with it in any practical implementation
that is generally deployable.  And, these two limitations extend to
single-packet solutions as well.  (Although, if you run both SPA and the
follow-on SSH connection over the Tor network - at the expense of having
an established TCP connection for the SPA packet - and you use the
MapAddress functionality to request a specific exit router, then it is
possible to overcome the NAT issue, see
http://www.cipherdyne.org/fwknop/docs/talks/dc14_fwknop_slides.pdf).

Still, single-packet solutions are generally the way to go (assuming we
are looking for a scheme that has good security properties).

So, your hmac method from within iptables is the most interesting.  Some
differences between this method and using a userspace daemon with an
encrypted payload include:

- Clients cannot include information that the server might use to
  differentiate them.  For example, the server might require that the
  client include both a valid username and crypt() password on the local
  system that can be verified (or even talking with an LDAP server
  first) before opening the firewall.  If you changed your protocol to
  include the hmac of the <secret, ip, epoch_min> and the appended
  additional information, that would work, but it would have to be sent
  in the clear.  Your userspace daemon could perform these userland
  verifications, but by then the firewall is already open.  (Fwknop
  supports the username/password verification via crypt(), but not the
  LDAP bit yet).

- The above also extends to the clients determining the access rules
  themselves, and also sending complete commands across.  (Neither of
  these are probably a big requirement on the part of users, but they
  are worth mentioning, and fwknop supports both).

- The hmac non-replay functionality does allow replays for up to one
  minute, correct?  I.e. multiple identical hmac packets could be sent
  for up to one minute and all would be honored by iptables?  Suppose
  a user does:

knock.sh opensecret; ssh user@host "do command"; knock.sh closesecret

  Then an attacker would still have one minute in order to replay the
  first opensecret packet, and the IP would be allowed through until
  the attacker decides to voluntarily send the closesecret packet, yes?

  Fwknop never allows duplicate SPA packets, period.

- The hmac functionality allows new sessions to be initiated until a
  client decides to close access.  This magnifies the NAT problem.
  In fwknop, because all ACCEPT rules are automatically deleted
  after a configurable amount of time and sessions remain open with
  Netfilter's conntrack facilities, the NAT problem is minimized.  I
  wonder if you could move to a timeout architecture within your pknock
  match?

- Finally, a userspace implementation is free to support any number of
  encryption schemes (as implemented by projects that concentrate in that
  area), many of which I doubt will ever be put within the kernel.
  Fwknop can take advantage of the benefits of asymmetric ciphers with
  GnuPG (as implemented by the GnuPG project itself) for example.

While I think that having the hmac functionality in iptables would meet
the needs of many users, I think the above shows that the effort of
learning a new daemon syntax is worth having a userspace implementation
with more robust security properties.  If I have misunderstood your
architecture, please correct me.

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

Re: new match extension to implement port knocking in one

[J. Federico Hernandez]

> On Oct 14, 2006, Michael Rash wrote:
>
> > On Oct 13, 2006, J. Federico Hernandez wrote:
> >
> > >On Oct 12, 2006, Alexey Toptygin wrote:
> > >
> > >> On Wed, 11 Oct 2006, Luis Floreani wrote:
> > >>
> > >> >>If you're interested in port knocking, you might want to read this
> > >> >>paper:  http://www.acsac.org/2005/abstracts/156.html  It covers
> > >security
> > >> >>issues relating to port knocking in detail, and presents an
> > >architecture
> > >> >>for solving most of them.
> > >> >>
> > >> >>Full disclosure:  I wrote that paper.  Feel free to contact me if you
> > >> >>have questions.
> > >> >>
> > >> >>Rennie deGraaf
> > >> >
> > >> >In our implementation, for security, we are using the Tumbler protocol,
> > >we
> > >> >found it simple yet powerful, check it out here:
> > >> >http://tumbler.sourceforge.net/.
> > >>
> > >> It seems that Tumbler is not capable of working across NAT, unless the
> > >> client can somehow obtain its public IP address. Also, it relies on
> > >clocks
> > >> being synchronized, since authentication will fail if the UTC time in
> > >> minutes is not identical on the client and server. Tumbler is not as
> > >> stealthy as the techniques in Rennie deGraaf's paper, since it uses an
> > >> open UDP port.
> > >
> > >Why not use fwknop in Single Packet Authorization mode?:
> >
> > Why not using iptables to implement port knocking?
> > You won't depend on any daemon.
> >
> > If you know the iptables syntaxis, you don't need to learn the daemon
> > syntaxis or its configuration.
> >
>
> Well, I agree that having an implementation that builds some port
> knocking capabilities directly into iptables is a good thing for the
> reasons you mention.  However, I would say that there are some design
> considerations that warrant userspace implementations as well.  Users
> should be able to select the system that offers the best security
> properties, and putting both the authentication and authorization
> verification code in the kernel is not always going to meet everyone's
> needs.

We think that recognizing a port knocking sequence is an issue of the
firewall (netfilter in this case), and if you want to open a port
after a correct seq, the firewall is also the place. But sometimes you
want to trigger a more complex action from this correct knock seq
(e.g. start a webserver), so we allow to send a netlink msg from
kernel to a listening userspace application that could decide what
action to take. This userspace app is not scanning logs nor sniffing
your iface, it's just waiting to receive an important message from
kernel.

here is a nice intro to netlink sockets:

http://www.linuxjournal.com/article/7356

> First, port knocking as opposed to single packet strategies have some
> serious problems:
>
> - Hard to solve the replay problem
> - Insufficient data transfer rate and reliability because of necessary
>   time delays to enforce packet ordering to make reasonably sized
>   data transfers (asymmetric encryption is not even an option)
> - Knock sequences look like port scans

Tumbler is a Single Packet Authorization protocol. We offer 2 modes of
operation: the traditional port knock sequence and the SPA way.

> - Trivially easy to bust a knock sequence just by spoofing a duplicate
>   packet into the sequence

This is not possible with our anti-replay option.

Luis Floreani: "In our implementation there is no room for replay,
cause each knock must change from minute to minute, and we just allow
one knock per peer(IP) per minute. So if you knock(open), then
connect, then knock(close), in the remaining minute, a replay would be
useless cause that peer is "blocked" in that minute. Look at the
function has_logged_during_this_minute(), that solves this issue."

Rennie deGraaf: "That's quite a clever idea.  I never thought of using
rate-limiting in my system."

> The NAT issue and the lack of association between a knock sequence and
> follow-on connection mentioned in deGraaf's paper are important, but I
> think we basically have to live with it in any practical implementation
> that is generally deployable.  And, these two limitations extend to
> single-packet solutions as well.

The NAT issue is a general problem with portknocking. Doesn't exist
any portknocking application that solves it, for a while.

> (Although, if you run both SPA and the
> follow-on SSH connection over the Tor network - at the expense of having
> an established TCP connection for the SPA packet - and you use the
> MapAddress functionality to request a specific exit router, then it is
> possible to overcome the NAT issue, see
> http://www.cipherdyne.org/fwknop/docs/talks/dc14_fwknop_slides.pdf).

I will read this paper soon.

> Still, single-packet solutions are generally the way to go (assuming we
> are looking for a scheme that has good security properties).
>
> So, your hmac method from within iptables is the most interesting.  Some
> differences between this method and using a userspace daemon with an
> encrypted payload include:
>
> - Clients cannot include information that the server might use to
>   differentiate them.  For example, the server might require that the
>   client include both a valid username and crypt() password on the local
>   system that can be verified (or even talking with an LDAP server
>   first) before opening the firewall.  If you changed your protocol to
>   include the hmac of the <secret, ip, epoch_min> and the appended
>   additional information, that would work, but it would have to be sent
>   in the clear.

Yes, adding users would allow granularity decisions, by now we prefer
a more general and simple approach. Maybe in a near future we consider
users.

> - The above also extends to the clients determining the access rules
>   themselves, and also sending complete commands across.  (Neither of
>   these are probably a big requirement on the part of users, but they
>   are worth mentioning, and fwknop supports both).

Yes, sending commands could be seen as a good feature, but also could
be a security issue, We prefer to "hardcode" the action in the
iptables rule or let the userspace app (see netlink sockets) decide
the action, rather than the client.

> - The hmac non-replay functionality does allow replays for up to one
>   minute, correct?  I.e. multiple identical hmac packets could be sent
>   for up to one minute and all would be honored by iptables?  Suppose
>   a user does:
>
> knock.sh opensecret; ssh user@host "do command"; knock.sh closesecret
>
>   Then an attacker would still have one minute in order to replay the
>   first opensecret packet, and the IP would be allowed through until
>   the attacker decides to voluntarily send the closesecret packet, yes?

as mentioned before, we just allow ONE knock PER peer(IP) PER minute.
Replay attacks are not possible here, cause the epoch min do change
every min.

> - The hmac functionality allows new sessions to be initiated until a
>   client decides to close access.  This magnifies the NAT problem.
>   In fwknop, because all ACCEPT rules are automatically deleted
>   after a configurable amount of time and sessions remain open with
>   Netfilter's conntrack facilities, the NAT problem is minimized.

Yes, we are thinking about this idea of conntrack to avoid the
"manual" close knock, but remember that someone could cause a DoS,
spoofing your IP and just trying to establish a connection before you.

>   I wonder if you could move to a timeout architecture within your pknock
>   match?

We have a garbage collector that runs from time to time to clean
already allowed and "defunct" peers.

> - Finally, a userspace implementation is free to support any number of
>   encryption schemes (as implemented by projects that concentrate in that
>   area), many of which I doubt will ever be put within the kernel.
>   Fwknop can take advantage of the benefits of asymmetric ciphers with
>   GnuPG (as implemented by the GnuPG project itself) for example.

With a port knocking application any users manipulate firewall rules.
Would you allow that any users or application change your firewall
configuration on the fly?

What happens if a port knocking daemon is shutdowned by a remote
attacker. If the daemon dies, then no further authentication is
possible.

> While I think that having the hmac functionality in iptables would meet
> the needs of many users, I think the above shows that the effort of
> learning a new daemon syntax is worth having a userspace implementation
> with more robust security properties.  If I have misunderstood your
> architecture, please correct me.

We think our architecture is flexible enough so you can spread
functionality between kernel and userspace (through netlink sockets),
as we we mention before.

regards,

-- 
Federico

Re: new match extension to implement port knocking in one

[Pablo Neira Ayuso]

J. Federico Hernandez wrote:
>> On Oct 14, 2006, Michael Rash wrote:
>>
>> Well, I agree that having an implementation that builds some port
>> knocking capabilities directly into iptables is a good thing for the
>> reasons you mention.  However, I would say that there are some design
>> considerations that warrant userspace implementations as well.  Users
>> should be able to select the system that offers the best security
>> properties, and putting both the authentication and authorization
>> verification code in the kernel is not always going to meet everyone's
>> needs.
> 
> We think that recognizing a port knocking sequence is an issue of the
> firewall (netfilter in this case), and if you want to open a port
> after a correct seq, the firewall is also the place. But sometimes you
> want to trigger a more complex action from this correct knock seq
> (e.g. start a webserver), so we allow to send a netlink msg from
> kernel to a listening userspace application that could decide what
> action to take. This userspace app is not scanning logs nor sniffing
> your iface, it's just waiting to receive an important message from
> kernel.

Perhaps I'm just influenced by my first impression but I think that this
thing should be in userspace. We are providing the appropiate netfilter
netlink subsystems (nfqueue, nflog...) to implement this as a userland
daemon.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: new match extension to implement port knocking in one

[J. Federico Hernandez]

On 10/16/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> J. Federico Hernandez wrote:
> >> On Oct 14, 2006, Michael Rash wrote:
> >>
> >> Well, I agree that having an implementation that builds some port
> >> knocking capabilities directly into iptables is a good thing for the
> >> reasons you mention.  However, I would say that there are some design
> >> considerations that warrant userspace implementations as well.  Users
> >> should be able to select the system that offers the best security
> >> properties, and putting both the authentication and authorization
> >> verification code in the kernel is not always going to meet everyone's
> >> needs.
> >
> > We think that recognizing a port knocking sequence is an issue of the
> > firewall (netfilter in this case), and if you want to open a port
> > after a correct seq, the firewall is also the place. But sometimes you
> > want to trigger a more complex action from this correct knock seq
> > (e.g. start a webserver), so we allow to send a netlink msg from
> > kernel to a listening userspace application that could decide what
> > action to take. This userspace app is not scanning logs nor sniffing
> > your iface, it's just waiting to receive an important message from
> > kernel.
>
> Perhaps I'm just influenced by my first impression but I think that this
> thing should be in userspace. We are providing the appropiate netfilter
> netlink subsystems (nfqueue, nflog...) to implement this as a userland
> daemon.
>

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.

In other more complex situations, you can recognize the knocks in the
kernel and let a userspace app take an action using netlink sockets,
as you say, but you should never allow a port knocking app to add or
remove firewall rules on the fly.

Regards.

-- 
Federico

Re: new match extension to implement port knocking in one

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

Le mardi 17 octobre 2006 à 09:19 -0300, J. Federico Hernandez a écrit :
> On 10/16/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > J. Federico Hernandez wrote:
> > >> On Oct 14, 2006, Michael Rash wrote:
> > >>
> > >> Well, I agree that having an implementation that builds some port
> > >> knocking capabilities directly into iptables is a good thing for the
> >
> > Perhaps I'm just influenced by my first impression but I think that this
> > thing should be in userspace. We are providing the appropiate netfilter
> > netlink subsystems (nfqueue, nflog...) to implement this as a userland
> > daemon.
> >
> 
> 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.

> In other more complex situations, you can recognize the knocks in the
> kernel and let a userspace app take an action using netlink sockets,
> as you say, but you should never allow a port knocking app to add or
> remove firewall rules on the fly.

I don't think this was Pablo's intention : you can queue packet for all
port including the one that must pass through and when the port knocking
sequence is complete, allow packet to go through target port from
userspace.

BR,
-- 
Éric Leblond, eleblond@inl.fr
Téléphone : 01 44 89 46 39, Fax : 01 44 89 45 01
INL, http://www.inl.fr

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new match extension to implement port knocking in one

[Michael Rash]

On Oct 16, 2006, J. Federico Hernandez wrote:

> >On Oct 14, 2006, Michael Rash wrote:
> >
> >> On Oct 13, 2006, J. Federico Hernandez wrote:
> >>
> >> >On Oct 12, 2006, Alexey Toptygin wrote:
> >> >
> >> >> On Wed, 11 Oct 2006, Luis Floreani wrote:
> >> >>
> >> >> >>If you're interested in port knocking, you might want to read this
> >> >> >>paper:  http://www.acsac.org/2005/abstracts/156.html  It covers
> >> >security
> >> >> >>issues relating to port knocking in detail, and presents an
> >> >architecture
> >> >> >>for solving most of them.
> >> >> >>
> >> >> >>Full disclosure:  I wrote that paper.  Feel free to contact me if 
> >you
> >> >> >>have questions.
> >> >> >>
> >> >> >>Rennie deGraaf
> >> >> >
> >> >> >In our implementation, for security, we are using the Tumbler 
> >protocol,
> >> >we
> >> >> >found it simple yet powerful, check it out here:
> >> >> >http://tumbler.sourceforge.net/.
> >> >>
> >> >> It seems that Tumbler is not capable of working across NAT, unless the
> >> >> client can somehow obtain its public IP address. Also, it relies on
> >> >clocks
> >> >> being synchronized, since authentication will fail if the UTC time in
> >> >> minutes is not identical on the client and server. Tumbler is not as
> >> >> stealthy as the techniques in Rennie deGraaf's paper, since it uses an
> >> >> open UDP port.
> >> >
> >> >Why not use fwknop in Single Packet Authorization mode?:
> >>
> >> Why not using iptables to implement port knocking?
> >> You won't depend on any daemon.
> >>
> >> If you know the iptables syntaxis, you don't need to learn the daemon
> >> syntaxis or its configuration.
> >>
> >
> >Well, I agree that having an implementation that builds some port
> >knocking capabilities directly into iptables is a good thing for the
> >reasons you mention.  However, I would say that there are some design
> >considerations that warrant userspace implementations as well.  Users
> >should be able to select the system that offers the best security
> >properties, and putting both the authentication and authorization
> >verification code in the kernel is not always going to meet everyone's
> >needs.
> 
> We think that recognizing a port knocking sequence is an issue of the
> firewall (netfilter in this case), and if you want to open a port
> after a correct seq, the firewall is also the place. But sometimes you
> want to trigger a more complex action from this correct knock seq
> (e.g. start a webserver), so we allow to send a netlink msg from
> kernel to a listening userspace application that could decide what
> action to take. This userspace app is not scanning logs nor sniffing
> your iface, it's just waiting to receive an important message from
> kernel.
> 
> here is a nice intro to netlink sockets:
> 
> http://www.linuxjournal.com/article/7356
> 
> >First, port knocking as opposed to single packet strategies have some
> >serious problems:
> >
> >- Hard to solve the replay problem
> >- Insufficient data transfer rate and reliability because of necessary
> >  time delays to enforce packet ordering to make reasonably sized
> >  data transfers (asymmetric encryption is not even an option)
> >- Knock sequences look like port scans
> 
> Tumbler is a Single Packet Authorization protocol. We offer 2 modes of
> operation: the traditional port knock sequence and the SPA way.

Right, I was treating the two modes separately (port knocking vs. SPA).
I'm trying to make the case that port knocking has enough problems to
motivate people to use an SPA solution instead.

> >- Trivially easy to bust a knock sequence just by spoofing a duplicate
> >  packet into the sequence
> 
> This is not possible with our anti-replay option.
> 
> Luis Floreani: "In our implementation there is no room for replay,
> cause each knock must change from minute to minute, and we just allow
> one knock per peer(IP) per minute. So if you knock(open), then
> connect, then knock(close), in the remaining minute, a replay would be
> useless cause that peer is "blocked" in that minute. Look at the
> function has_logged_during_this_minute(), that solves this issue."
> 
> Rennie deGraaf: "That's quite a clever idea.  I never thought of using
> rate-limiting in my system."

Spoofing a duplicate packet into a port knock sequence is not a replay
attack.  This is a DoS attack against your knock server; an attacker can
force the client to appear to not know the correct knock sequence.  This
is yet another reason to switch to an SPA solution because it is so
trivially easy to do.

> >The NAT issue and the lack of association between a knock sequence and
> >follow-on connection mentioned in deGraaf's paper are important, but I
> >think we basically have to live with it in any practical implementation
> >that is generally deployable.  And, these two limitations extend to
> >single-packet solutions as well.
> 
> The NAT issue is a general problem with portknocking. Doesn't exist
> any portknocking application that solves it, for a while.
> 
> >(Although, if you run both SPA and the
> >follow-on SSH connection over the Tor network - at the expense of having
> >an established TCP connection for the SPA packet - and you use the
> >MapAddress functionality to request a specific exit router, then it is
> >possible to overcome the NAT issue, see
> >http://www.cipherdyne.org/fwknop/docs/talks/dc14_fwknop_slides.pdf).
> 
> I will read this paper soon.
> 
> >Still, single-packet solutions are generally the way to go (assuming we
> >are looking for a scheme that has good security properties).
> >
> >So, your hmac method from within iptables is the most interesting.  Some
> >differences between this method and using a userspace daemon with an
> >encrypted payload include:
> >
> >- Clients cannot include information that the server might use to
> >  differentiate them.  For example, the server might require that the
> >  client include both a valid username and crypt() password on the local
> >  system that can be verified (or even talking with an LDAP server
> >  first) before opening the firewall.  If you changed your protocol to
> >  include the hmac of the <secret, ip, epoch_min> and the appended
> >  additional information, that would work, but it would have to be sent
> >  in the clear.
> 
> Yes, adding users would allow granularity decisions, by now we prefer
> a more general and simple approach. Maybe in a near future we consider
> users.

Ok, but doesn't "considering users" imply more user space type functions?
Sure, I suppose you can read the /etc/shadow file from kernel space and
then do crypt() from within the kernel, but this is limited and seems
wrong.  What if you want to tie access to a remote LDAP server for
example?  Your user space app could do it, but then user-specific
information would have to be transmitted over the netlink socket as
well, correct?

> >- The above also extends to the clients determining the access rules
> >  themselves, and also sending complete commands across.  (Neither of
> >  these are probably a big requirement on the part of users, but they
> >  are worth mentioning, and fwknop supports both).
> 
> Yes, sending commands could be seen as a good feature, but also could
> be a security issue, We prefer to "hardcode" the action in the
> iptables rule or let the userspace app (see netlink sockets) decide
> the action, rather than the client.

Yes, sending commands could be a security issue, and this is not enabled
by default in fwknop; it is just there for those who find it useful (and
also find that the security risks are acceptable given that fwknop is
compatible with things like GnuPG, etc.).

> >- The hmac non-replay functionality does allow replays for up to one
> >  minute, correct?  I.e. multiple identical hmac packets could be sent
> >  for up to one minute and all would be honored by iptables?  Suppose
> >  a user does:
> >
> >knock.sh opensecret; ssh user@host "do command"; knock.sh closesecret
> >
> >  Then an attacker would still have one minute in order to replay the
> >  first opensecret packet, and the IP would be allowed through until
> >  the attacker decides to voluntarily send the closesecret packet, yes?
> 
> as mentioned before, we just allow ONE knock PER peer(IP) PER minute.
> Replay attacks are not possible here, cause the epoch min do change
> every min.

Ok, that's cool.

> >- The hmac functionality allows new sessions to be initiated until a
> >  client decides to close access.  This magnifies the NAT problem.
> >  In fwknop, because all ACCEPT rules are automatically deleted
> >  after a configurable amount of time and sessions remain open with
> >  Netfilter's conntrack facilities, the NAT problem is minimized.
> 
> Yes, we are thinking about this idea of conntrack to avoid the
> "manual" close knock, but remember that someone could cause a DoS,
> spoofing your IP and just trying to establish a connection before you.

I'm not sure I understand.  It seems like this would be an issue only if
you allow just one follow-on connection per SPA packet, yes?  Fwknop
uses a timeout window, so it doesn't matter how many connections are
established as long as it is within the window.

> >  I wonder if you could move to a timeout architecture within your pknock
> >  match?
> 
> We have a garbage collector that runs from time to time to clean
> already allowed and "defunct" peers.
> 
> >- Finally, a userspace implementation is free to support any number of
> >  encryption schemes (as implemented by projects that concentrate in that
> >  area), many of which I doubt will ever be put within the kernel.
> >  Fwknop can take advantage of the benefits of asymmetric ciphers with
> >  GnuPG (as implemented by the GnuPG project itself) for example.
> 
> With a port knocking application any users manipulate firewall rules.
> Would you allow that any users or application change your firewall
> configuration on the fly?

With strong enough security properties and a good design, yes.  Fwknop
always keeps rules within a custom chain in order to separate them from
an existing iptables policy, has a well-defined mechanism for
manipulating rules, etc.

> What happens if a port knocking daemon is shutdowned by a remote
> attacker. If the daemon dies, then no further authentication is
> possible.

Fwknop has a process monitoring daemon, and is written in a (mostly)
buffer safe language (perl).  Being able to be shutdown by an attacker
implies a bug or design flaw - these can exist in the kernel as well to
more damaging effect.

> >While I think that having the hmac functionality in iptables would meet
> >the needs of many users, I think the above shows that the effort of
> >learning a new daemon syntax is worth having a userspace implementation
> >with more robust security properties.  If I have misunderstood your
> >architecture, please correct me.
> 
> We think our architecture is flexible enough so you can spread
> functionality between kernel and userspace (through netlink sockets),
> as we we mention before.
> 
> regards,
> 
> -- 
> Federico

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

Re: new match extension to implement port knocking in one

[J. Federico Hernandez]

On 10/17/06, Eric Leblond <eric@inl.fr> wrote:
> Le mardi 17 octobre 2006 à 09:19 -0300, J. Federico Hernandez a écrit :
> > On 10/16/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > J. Federico Hernandez wrote:
> > > >> On Oct 14, 2006, Michael Rash wrote:
> > > >>
> > > >> Well, I agree that having an implementation that builds some port
> > > >> knocking capabilities directly into iptables is a good thing for the
> > >
> > > Perhaps I'm just influenced by my first impression but I think that this
> > > thing should be in userspace. We are providing the appropiate netfilter
> > > netlink subsystems (nfqueue, nflog...) to implement this as a userland
> > > daemon.
> > >
> >
> > 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.

By the way, Linux runs in a wide spectrum of devices, like mobile
devices, where you musn't waste resources. (see linksys ap wireless,
smart phones, etc)

regards,

-- 
Federico

Re: new match extension to implement port knocking in one

[J. Federico Hernandez]

On 10/17/06, Michael Rash <mbr@cipherdyne.org> wrote:
> On Oct 16, 2006, J. Federico Hernandez wrote:
>
> > >On Oct 14, 2006, Michael Rash wrote:
> > >
> > >> On Oct 13, 2006, J. Federico Hernandez wrote:
> > >>
> > >> >On Oct 12, 2006, Alexey Toptygin wrote:
> > >> >
> > >> >> On Wed, 11 Oct 2006, Luis Floreani wrote:
> > >> >>
> > >> >> >>If you're interested in port knocking, you might want to read this
> > >> >> >>paper:  http://www.acsac.org/2005/abstracts/156.html  It covers
> > >> >security
> > >> >> >>issues relating to port knocking in detail, and presents an
> > >> >architecture
> > >> >> >>for solving most of them.
> > >> >> >>
> > >> >> >>Full disclosure:  I wrote that paper.  Feel free to contact me if
> > >you
> > >> >> >>have questions.
> > >> >> >>
> > >> >> >>Rennie deGraaf
> > >> >> >
> > >> >> >In our implementation, for security, we are using the Tumbler
> > >protocol,
> > >> >we
> > >> >> >found it simple yet powerful, check it out here:
> > >> >> >http://tumbler.sourceforge.net/.
> > >> >>
> > >> >> It seems that Tumbler is not capable of working across NAT, unless the
> > >> >> client can somehow obtain its public IP address. Also, it relies on
> > >> >clocks
> > >> >> being synchronized, since authentication will fail if the UTC time in
> > >> >> minutes is not identical on the client and server. Tumbler is not as
> > >> >> stealthy as the techniques in Rennie deGraaf's paper, since it uses an
> > >> >> open UDP port.
> > >> >
> > >> >Why not use fwknop in Single Packet Authorization mode?:
> > >>
> > >> Why not using iptables to implement port knocking?
> > >> You won't depend on any daemon.
> > >>
> > >> If you know the iptables syntaxis, you don't need to learn the daemon
> > >> syntaxis or its configuration.
> > >>
> > >
> > >Well, I agree that having an implementation that builds some port
> > >knocking capabilities directly into iptables is a good thing for the
> > >reasons you mention.  However, I would say that there are some design
> > >considerations that warrant userspace implementations as well.  Users
> > >should be able to select the system that offers the best security
> > >properties, and putting both the authentication and authorization
> > >verification code in the kernel is not always going to meet everyone's
> > >needs.
> >
> > We think that recognizing a port knocking sequence is an issue of the
> > firewall (netfilter in this case), and if you want to open a port
> > after a correct seq, the firewall is also the place. But sometimes you
> > want to trigger a more complex action from this correct knock seq
> > (e.g. start a webserver), so we allow to send a netlink msg from
> > kernel to a listening userspace application that could decide what
> > action to take. This userspace app is not scanning logs nor sniffing
> > your iface, it's just waiting to receive an important message from
> > kernel.
> >
> > here is a nice intro to netlink sockets:
> >
> > http://www.linuxjournal.com/article/7356
> >
> > >First, port knocking as opposed to single packet strategies have some
> > >serious problems:
> > >
> > >- Hard to solve the replay problem
> > >- Insufficient data transfer rate and reliability because of necessary
> > >  time delays to enforce packet ordering to make reasonably sized
> > >  data transfers (asymmetric encryption is not even an option)
> > >- Knock sequences look like port scans
> >
> > Tumbler is a Single Packet Authorization protocol. We offer 2 modes of
> > operation: the traditional port knock sequence and the SPA way.
>
> Right, I was treating the two modes separately (port knocking vs. SPA).
> I'm trying to make the case that port knocking has enough problems to
> motivate people to use an SPA solution instead.

we agree, that's why we offer both solutions.

<snip>

> > >
> > >- Clients cannot include information that the server might use to
> > >  differentiate them.  For example, the server might require that the
> > >  client include both a valid username and crypt() password on the local
> > >  system that can be verified (or even talking with an LDAP server
> > >  first) before opening the firewall.  If you changed your protocol to
> > >  include the hmac of the <secret, ip, epoch_min> and the appended
> > >  additional information, that would work, but it would have to be sent
> > >  in the clear.
> >
> > Yes, adding users would allow granularity decisions, by now we prefer
> > a more general and simple approach. Maybe in a near future we consider
> > users.
>
> Ok, but doesn't "considering users" imply more user space type functions?
> Sure, I suppose you can read the /etc/shadow file from kernel space and
> then do crypt() from within the kernel, but this is limited and seems
> wrong.  What if you want to tie access to a remote LDAP server for
> example?  Your user space app could do it, but then user-specific
> information would have to be transmitted over the netlink socket as
> well, correct?
>

the listening(netlink sockets) userspace app can receive as much
information as you want, in fact, the bytes received from the socket
are casted to a struct, containing n items.

<snip>

>
> > >- The hmac functionality allows new sessions to be initiated until a
> > >  client decides to close access.  This magnifies the NAT problem.
> > >  In fwknop, because all ACCEPT rules are automatically deleted
> > >  after a configurable amount of time and sessions remain open with
> > >  Netfilter's conntrack facilities, the NAT problem is minimized.
> >
> > Yes, we are thinking about this idea of conntrack to avoid the
> > "manual" close knock, but remember that someone could cause a DoS,
> > spoofing your IP and just trying to establish a connection before you.
>
> I'm not sure I understand.  It seems like this would be an issue only if
> you allow just one follow-on connection per SPA packet, yes?  Fwknop
> uses a timeout window, so it doesn't matter how many connections are
> established as long as it is within the window.
>

ok, in our case, if you do not do the "close" knock, you also have a
timeout window configurable as a the kernel module param.

<snip>

seems that fwknop is an interesting app, but we are looking for a more
kernel oriented feedback. ;-)


regards,

-- 
Federico

Re: new match extension to implement port knocking in one

[Pablo Neira Ayuso]

J. Federico Hernandez wrote:
> On 10/17/06, Eric Leblond <eric@inl.fr> wrote:
>> Le mardi 17 octobre 2006 à 09:19 -0300, J. Federico Hernandez a écrit :
>> > On 10/16/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>> > > J. Federico Hernandez wrote:
>> > > >> On Oct 14, 2006, Michael Rash wrote:
>> > > >>
>> > > >> Well, I agree that having an implementation that builds some port
>> > > >> knocking capabilities directly into iptables is a good thing
>> for the
>> > >
>> > > Perhaps I'm just influenced by my first impression but I think
>> that this
>> > > thing should be in userspace. We are providing the appropiate
>> netfilter
>> > > netlink subsystems (nfqueue, nflog...) to implement this as a
>> userland
>> > > daemon.
>> > >
>> >
>> > 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.

> By the way, Linux runs in a wide spectrum of devices, like mobile
> devices, where you musn't waste resources. (see linksys ap wireless,
> smart phones, etc)

I think that the main question is how many packets you would need to
pass to userspace.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: new match extension to implement port knocking in one

[J. Federico Hernandez]

On 10/18/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> J. Federico Hernandez wrote:
> > On 10/17/06, Eric Leblond <eric@inl.fr> wrote:
> >> Le mardi 17 octobre 2006 à 09:19 -0300, J. Federico Hernandez a écrit :
> >> > On 10/16/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >> > > J. Federico Hernandez wrote:
> >> > > >> On Oct 14, 2006, Michael Rash wrote:
> >> > > >>
> >> > > >> Well, I agree that having an implementation that builds some port
> >> > > >> knocking capabilities directly into iptables is a good thing
> >> for the
> >> > >
> >> > > Perhaps I'm just influenced by my first impression but I think
> >> that this
> >> > > thing should be in userspace. We are providing the appropiate
> >> netfilter
> >> > > netlink subsystems (nfqueue, nflog...) to implement this as a
> >> userland
> >> > > daemon.
> >> > >
> >> >
> >> > 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 don't want to say that you don't use port knocking applications, we
just offer an alternative solution for port knocking.


Regards,


-- 
Federico

Re: new match extension to implement port knocking in one

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

Le lundi 23 octobre 2006 à 10:31 -0300, J. Federico Hernandez a écrit :
> On 10/18/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > J. Federico Hernandez wrote:
> > > On 10/17/06, Eric Leblond <eric@inl.fr> 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.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: new match extension to implement port knocking in one

[Luis Floreani]

On 10/23/06, Eric Leblond <eric@inl.fr> wrote:
> Le lundi 23 octobre 2006 à 10:31 -0300, J. Federico Hernandez a écrit :
> > On 10/18/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > J. Federico Hernandez wrote:
> > > > On 10/17/06, Eric Leblond <eric@inl.fr> 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.

Re: new match extension to implement port knocking in one

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

Hi,

Le mardi 24 octobre 2006 à 20:21 -0300, Luis Floreani a écrit :
> On 10/23/06, Eric Leblond <eric@inl.fr> wrote:
> >
> > 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.

By just queuing the SYN Packets you will introduce a ridiculous delay on
this first packet. The rest of the connectio is handled by conntrack and
there is thus no differences.

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

All can be bundle in a single script. A cleaner way could be to use
ipset to specify the ports list and not to change the rules set.

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

No, you have to use NFQUEUE to do so (which come with 2.6.14+). QUEUE is
limited to one queue.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: new match extension to implement port knocking in one

[Luis Floreani]

On 10/23/06, Eric Leblond <eric@inl.fr> wrote:
> Le lundi 23 octobre 2006 à 10:31 -0300, J. Federico Hernandez a écrit :
> > On 10/18/06, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > J. Federico Hernandez wrote:
> > > > On 10/17/06, Eric Leblond <eric@inl.fr> 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.

Re: new match extension to implement port knocking in one

[J. Federico Hernandez]

Hello,

On 10/25/06, Eric Leblond <eric@inl.fr> wrote:
> Hi,
>
> Le mardi 24 octobre 2006 à 20:21 -0300, Luis Floreani a écrit :
> > On 10/23/06, Eric Leblond <eric@inl.fr> wrote:
> > >
> > > 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.
>
> By just queuing the SYN Packets you will introduce a ridiculous delay on
> this first packet. The rest of the connectio is handled by conntrack and
> there is thus no differences.

That design is very good. We think that it is the best among all the
"hybrid" port knocking applications that we know.

> > 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.
>
> All can be bundle in a single script. A cleaner way could be to use
> ipset to specify the ports list and not to change the rules set.

This is debatable. A cleaner way for who? Someone might want to
configure the firewall only through iptables, without depending on
other applications or daemons.

> > 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"
>
> No, you have to use NFQUEUE to do so (which come with 2.6.14+). QUEUE is
> limited to one queue.

We didn't know the NFQUEUE target extension. We thought it was very good.

Finally, we don't want to say that other port knocking applications
aren't useful. We just offer an alternative, than in our opinion has
more advantages than other solutions.

We would like know any suggestions about our pknock extension match.
If you have some, they will be welcome.

Regards,


-- 
Federico