From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id ABA0E1381F3 for ; Mon, 14 Oct 2013 18:50:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4B871E0AC1; Mon, 14 Oct 2013 18:50:10 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 474F2E0A9F for ; Mon, 14 Oct 2013 18:50:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 9296D33EF4F for ; Mon, 14 Oct 2013 18:50:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5.5 tests=[AWL=-0.512, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.536, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSdUUtODeys9 for ; Mon, 14 Oct 2013 18:49:56 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id BBDC933EF49 for ; Mon, 14 Oct 2013 18:49:53 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VVnDC-0004jW-Uz for gentoo-user@gentoo.org; Mon, 14 Oct 2013 20:49:50 +0200 Received: from lounge.imp.fu-berlin.de ([160.45.42.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Oct 2013 20:49:50 +0200 Received: from vaeth by lounge.imp.fu-berlin.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Oct 2013 20:49:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Martin Vaeth Subject: [gentoo-user] Re: scripted iptables-restore Date: Mon, 14 Oct 2013 18:49:23 +0000 (UTC) Message-ID: References: <524DD388.9020507@fastmail.co.uk> <524F39F6.4040409@orlitzky.com> <525AAADE.7040700@orlitzky.com> <525ACC38.8060008@orlitzky.com> <525B1878.2010908@orlitzky.com> <525BFF1B.6070805@orlitzky.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lounge.imp.fu-berlin.de User-Agent: slrn/pre1.0.0-26 (Linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Archives-Salt: 270953ef-0a7d-4bb9-9024-eb889e949dfe X-Archives-Hash: 1235747234ffdf2f8cefd6bef3fbab37 Michael Orlitzky wrote: > On 10/14/2013 07:49 AM, Martin Vaeth wrote: >> >> Using yet another service with possible holes to protect a sshd? >> In this case, I would like port knocking at least for this OpenVPN. > > The sensitive parts of OpenVPN are audited regularly, and it uses "SSL" > -- public key auth to exchange a symmetric key, both of which use > tried-and-true algorithms/code. So its completely as well-audited and secure as openssh was when the Debian disaster happened. Also IIRC there are currently some timing attacks against certain SSL modes, and who knows when some clever hacker finds another possibility nobody thought of up to now. > Port knocking on the other hand is just security through obscurity As is every password. > and is visible over the wire This is why you have to change it regularly. Actually, if you change it whenever you used it, you have a rather strong method, essentially only vulnerable if the man-in-the-middle is able to cut your connection, and even then he has only very limited time to attack the actual service which is protected by it. > problem is "solved" if it's easy to exponentially increase the amount > of work an attacker has to do. And exactly for this reason the solution is always only a theory - for very particularly specified problems. For practical machines, it is good to have this *in addition* to other safety measurements: Experience shows that rather often there are some new ideas or bugs which can be used to avoid the exponential amount by something not covered by the original theory. > Obscurity does provide some benefit, but it gets dismissed because we > tend to ignore the constant factor when talking about these things. This is reasonable for theory, but in practice the constant factor can be more important. Even more if it needs human intervention. > Hiding the salt would just be security through obscurity. And yet it is stupid if you do not do it and give away a huge constant factor for no advantage. > Similarly, putting port knocking in front of OpenVPN is like putting a > padlock on the bank vault. If someone is going to break OpenVPN, port > knocking ain't gonna stop them. No. Port knocking is more like putting your bank vault into a wooden box. If some new attack against SSL or the OpenVPN implementation is found, it is like somebody has a key to your vault. If you are a highly important target, this will not save you, but if human resources are needed to break whatever you did for obscurity, it makes in practice the crucial difference. > It's not laziness I'm advocating, just simplicity. Simple, > understandable code is more likely to be correct than clever code. And > in this case, incorrect iptables code is more of a threat than the tiny > race condition. You have a strange mentality: One the one hand you are afraid that a rather primitive translation of one syntax into another leads to unexpected effects, and on the other hand you trust much more complex things like SSL and OpenVPN which could much easier allow unexpected things with even the slightest attempt to secure them further if you can.