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: > > > >> 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. > > > > 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. > > > > > +1 > > "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. > > 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="-minimal *") setup. Quite impressive, not to count all external so libraries involved. > 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. > > 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=/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
pgpoLHa1UkyGi.pgp
Description: PGP signature
