new match extension to implement port knocking in one

Michael Rash mbr at cipherdyne.org
Sat Oct 14 19:19:57 CEST 2006


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



More information about the netfilter-devel mailing list