linux-kernel - Re: [PATCH] TCP: add option for silent port knocking with integrity protection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Dec 2013 21:39:42 +0100
From:	Christian Grothoff <grothoff@...tum.de>
To:	Stephen Hemminger <stephen@...workplumber.org>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, knock@...net.org, jacob@...elbaum.net
Subject: Re: [PATCH] TCP: add option for silent port knocking with integrity
 protection

On 12/11/2013 09:26 PM, Stephen Hemminger wrote:
> On Wed, 11 Dec 2013 21:19:00 +0100
> Christian Grothoff <grothoff@...tum.de> wrote:
> 
>> On 12/11/2013 09:01 PM, David Miller wrote:
>>> From: Christian Grothoff <grothoff@...tum.de>
>>> Date: Tue, 10 Dec 2013 19:35:36 +0100
>>>
>>>> Only NAT implementations that change the SQN are not supported
>>>> (those should be rare, but we have no hard data on this).
>>>
>>> Even Linux's netfilter can and does do this, it is absolutely necessary
>>> for tracking SIP and FTP protocols, and it's also used in our virtual
>>> server load balancing modules.
>>>
>>
>> We're aware that Linux _can_ do this.  I was not aware it was doing this
>> for
>> SIP and FTP specifically; regardless, what implementations can do is less
>> important than what they are configured to do most of the time, and that's
>> what we'd need hard data on.  Anyway, I'd be very interested to learn how
>> you use this for SIP/FTP to evaluate the impact.  Do you have documentation
>> on this?
>>
>> As for server load balancing, I suspect that those are not the kinds of
>> services that one would typically use port knocking for.  Still, again a
>> good hint as to where trouble might lurk (and we will definitively include
>> those points in the next revision of the documentation).
> 
> The point is that doing it outside of TCP core is safer, less error prone
> and more flexible.
> 

I'm not sure how you drew that conclusion from what I or David said.
Outside of TCP core doesn't fix the NAT issues at all, having a
dozen user-space implementations with configuration quirks doesn't
really sound less error prone to me, and finally I do not even see
a reasonably sane way of doing the TCP payload authentication in
userspace (even writing a process that relays data won't work, as
then you'd loose the source address for the server process).  So
I'd go as far as saying that some of what we do cannot really be
done in userspace.  Now, maybe you mean something other than
"userspace" with "outside of TCP core", in which case I again totally
fail to relate this to what was said here before.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/