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 7B101138E20 for ; Fri, 21 Feb 2014 12:39:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AB51BE0C62; Fri, 21 Feb 2014 12:39:48 +0000 (UTC) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3E0F5E0BD9 for ; Fri, 21 Feb 2014 12:39:46 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id hr17so2257996lab.6 for ; Fri, 21 Feb 2014 04:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type; bh=e2yM0HKjWrP8focBmGTZ8feDvetEEAl/1oe2xvZlWNI=; b=oCM1Oq1vJYw4QVwa0S5Ldfxh/qWTQxmwGMgUfQfU1DSC91dF/kkrDJtnar3CNZ+guz XYl/4DEuMaITLWiF9uyexhpYAo+lzRZckyD93rMUuC3avJSTIUYlCK2KxomUvsO4guOc 8o67HsaH8hZ2El6Xwk1ILuJAhDpgAuTjcK5SrS7h5iPL3N3EW/L5MdwXxFDLacOXm6eZ 5Vk2di+2120vQrm1W1Q4UddEMN3Vh3Bug+cYJIYgU6vlawQVVk9ts+XbkdQg6kPkUPQa gWPHucdDkMvT/P8PXf02ZSVoZHVsmT9dJiAc6+bnEoM22Yi1/EYFhE6CJoFk6+LAwqhq jIlQ== X-Received: by 10.152.120.201 with SMTP id le9mr4224058lab.68.1392986384688; Fri, 21 Feb 2014 04:39:44 -0800 (PST) Received: from localhost ([85.143.114.129]) by mx.google.com with ESMTPSA id bl8sm7580288lbb.3.2014.02.21.04.39.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2014 04:39:43 -0800 (PST) Date: Fri, 21 Feb 2014 16:39:24 +0400 From: Andrew Savchenko To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment? Message-Id: <20140221163924.61f9161506b45f9cbf374f27@gmail.com> In-Reply-To: <53066CCF.3060509@gmail.com> References: <5297F0C8.3060403@gmail.com> <5305410B.1090403@gmail.com> <20140220102952.GA6784@sabayon.logifi> <20140220205207.a1f2f6077cfbc037ae9b0bdb@gmail.com> <20140220204103.GA3381@vidovic.ultras.lan> <53066CCF.3060509@gmail.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.18; x86_64-pc-linux-gnu) 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 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Fri__21_Feb_2014_16_39_25_+0400_mDrpKgsp7bjsdp1F" X-Archives-Salt: 912cee46-7430-4ab1-b357-5787c2b8fd0f X-Archives-Hash: 635925cedca90d5b44a4eb67cfbf4eb1 --Signature=_Fri__21_Feb_2014_16_39_25_+0400_mDrpKgsp7bjsdp1F Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 20 Feb 2014 22:59:59 +0200 Alan McKinnon wrote: > On 20/02/2014 22:41, Nicolas Sebrecht wrote: > > On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: > >=20 > >> And this point is one of the highest security benefits in real world: > >> one have non-standard binaries, not available in the wild. Most > >> exploits will fail on such binaries even if vulnerability is still > >> there.=20 > >=20 > > While excluding few security issues by compiling less code is possible, > > believing that "non-standard binaries" (in the sense of "compiled for > > with local compilation flags") gives more security is a dangerous dream. > >=20 >=20 >=20 > +1 >=20 > "non-standard binaries" is really just a special form of security by > obscurity. Or alternatively a special form of "no-one will eva figure > out my l33t skillz! Mwahahaha!" Exactly. This is security trough obscurity. I never claimed this is an ultimate or a sufficient way to protect a system. But this is just a single of many multiple layers which can be used to provide acceptable security level. > Which is a very poor stance to take. >=20 > The total amount of code not compiled by setting some USE flags off is > on the whole not likely to be very much, and hoping with finger crossed > that the next weakness in a package will just happen to fall within a > code path that got left out by USE flags is a fools dream. You mare compare binary sizes for e.g. openldap (and all its libraries) with minimal and full (USE=3D"-minimal *") setup. Quite impressive, not to count all external so libraries involved. =20 > I'm glad you mentioned this Andrew, because the internets are full of > stupid advice like this "non-standard binary" nonsense. Are you considering Bruce Schneier's advice as a stupid nonsense? In his "Applied cryptography" he recommended one of the ways to straighten a system: to use not so frequently used algorithms instead of selected standards because less frequently used algorithms has no better math but are less targeted, have less specialized hardware built to crack them and so on. > Yes, the > arguments at face value are difficult to refute with hard facts, but > those that do not known it is stupid are easily led into a sense of > false security, doesn't matter how many disclaimers are tagged on the end. >=20 > I reckon it's the duty of all knowledgeable sysadmins to stamp out this > crap HARD every time it raises it's head. To the user who brought it up > - this might seem overly harsh but I've yet to find a better method that > actually works and gets through to people. I never talked about a sense of security just because system has non-standard binaries. I talked about high variance which brings a _bit_ more security. And I'm talking not from some theorizing, but from practical experience on both ends (data protection and legitimate system forensics). Have you ever considered how systems became broken in the wild? The most common way (in numbers of hosts, not significance) are automated robots and botnets. They just scan the net, try to bruteforce any login service they found and try to apply any exploit appropriate from their database. If one have a widely used and improperly configured (or not timely updated) setup, it will be hacked this way. The key point of any attack is *cost*, is *money* one needs to spend for an attack. Automated attacks are cheap and such _simple and cheap_ measures as obscured binaries and non-standard (e.g. ssh) ports will stop most of these attacks. This way it will cost _more_ for the attacker to break into protected system and with raise of an attack cost system protection level also rises. Of course, obfuscation is _not_ sufficient for system protection. This is just one small step forward. I don't want to discuss full scope of server protection issues, because this is far out of the topic of this discussion and because measures needed are task- dependent. However I want to notice one critical security issue quite common for production servers: an old software. It doesn't matter how many protection layers system have, how skilled person configured it was. When software is old it is quite trivial to look up for CVEs and break the system. Quite practical encounter from my own experience: I was asked to legitimately obtain root on the box (admin forgot password, reboot (with init=3D/bin/bash) was not an option and root access was needed for reconfiguration); a box was a year old RHEL with SELinux enforced. Third kernel exploit worked perfectly (I just found them on the net, not bothered to code myself). Such trivia with Gentoo and its custom binaries is not possible. And Gentoo is quite good with recent software updates (RH sometimes is too slow with critical kernel/libc issues). Old software is evil. It doesn't matter how good and tested it _was_. Variety and diversity are quite important for real word systems protection. Of course, it is possible to break _any_ box on the Earth, the only question is how high the cost will be. My point is that Gentoo provides native techniques to raise the attack cost. That's all. Best regards, Andrew Savchenko --Signature=_Fri__21_Feb_2014_16_39_25_+0400_mDrpKgsp7bjsdp1F Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBCgAGBQJTB0kNAAoJEFZZU7lTcnVsPPIP/2TTAJ8904k0JKuSwQoqvPNC 3TzLw4kPpelgksDW37jbcfgkhwDt3roPNIMp6EmgJzAUEH1CHbCT7aFB3wOmV30m Oxqtxj1a60+4EYzAGVXSOD+84hVw0lGGIaBpclWJxfDpylWz8EC3789frBj9Eng9 ffmbEQf3j21C1gOawtJknEmLasF/bUF3ei0jYmcIm1MaMW9AASacLwVJceiM6kYI TCAFOQkrRWDWfUSBjXvtrjUlNVnR0JchSa1yLB0Ai7B9eYAKBpODXKHojqmlDkIY P6NwkfD1SvElFCRQwwSJGSmzGy1RxhCjj/LE7gctbpGct5+Pfs/HYIJHGMBp78ZH DT1lYg+XWotNjw/MQdJ7JqYeOZ7BY/2usO7cHpe0wQyZZ42Zd9jv9Yx04hvITkpz 0bInRp9O88j6NvvKw5xP/9YKbhDEygDrlDj79toLEW6QK7UJEBjz5WEaMDBAFhuo CJrI2Jdx+mA/LR/WugJRN5e6Qki/LZvT/4CRRyzPZKPrNPqzcuM6DJVsCXjT1jJz bvRnXsC/BLmLGCrQYwQvehhUrYR4+tob5fOlG8ursj7AXJ/jsXd9GRGJxlkfzFOk Ci07xbw+W/Ola/gcn8doyTnUteKMj/hZB4VmIX96HF+qEUmKhDaXWnOJRKRSFULm A3UPcAHstpbsaayXrtOI =kCwk -----END PGP SIGNATURE----- --Signature=_Fri__21_Feb_2014_16_39_25_+0400_mDrpKgsp7bjsdp1F--