7 ms·

This person means well, but suffers from the same myopia a lot of security-first people do: making these changes to default settings is a huge violation of expe

by stonogo 10y ago

This person means well, but suffers from the same myopia a lot of security-first people do: making these changes to default settings is a huge violation of expectations, and the changes need to be widely publicized once they are decided upon. Suddenly dropping support mid-cycle for tons of things will result in pitchforks and torches from people who, despite the constant insinuations of this document, do in fact know what they are doing. This document, in short, makes a great to-do list but completely ignores the roadbuilding that needs to happen to get people ready and on board.

fleitz 10y ago
Exactly. I don't see these so much as poor choices as not security focused choices. Perhaps OpenBSD might be a better fit for this users needs.
api 10y ago
This is what's wrong with infosec. The majority of security people seem to have no concern for any other issue, resulting in them giving a lot of ham fisted advice that gets ignored. In the end security is worse as a result. I worked in infosec for a while and saw it at the org level: 1. Security recommends something with no concern for how it inconveniences (or worse) the users. 2. Users ignore or even actively work around security. 3. Users get pwned and blame security. 4. Security gets mad, calls users stupid, goes back to making ham fisted recommendations that everyone ignores because they have to get their work done. 5. Goto 1. In the end I concluded that we (security) were at fault. In many cases there were user sensitive options and I would make an effort to find them, but most of security actively had contempt for anyone outside security and didn't care.
- X86BSD 10y ago
  That is just common in IT not specifically the security nerds. Every group has their little fiefdom. DBAs, data architects, Unix admins, etc.
- jms703 10y ago
  This isn't about myopic security recommendations. These are just plain bad defaults and a failure to manage tech debt. No one that "knows what they are doing" wants to accept these risks and addressing them doesn't hurt users. Fixing these problems is totally realistic.
  - toast0 10y ago
    Some of these are bad defaults, some of these are common defaults that turned out to be bad, some of these are not easy to fix. Many of these things just take time to do right. Examples: ntpd is clearly not great software, but OpenNTPD is maybe a little bit too minimal. When ntimed is worthy, I'm sure it'll make it into FreeBSD base, but it's most likely going to be in a .0 release, so it'll be a while and people will be impatient. OpenSSL is hard. software in base needs libcrypto and libssl, so you need to pick a version and stick with it throughout the release cycle; but the FreeBSD release cycle is longer than the OpenSSL cycle; OpenSSL has also historically not been very good at keeping ABI compatibility. There's a lot of smart people working on this, but I think the least bad option is to not use openssl from base for anything outside of base. Firewall: I don't think default to no firewall is a problem -- if you want something, you can set it up. > Five months after this document was published, FreeBSD disabled DSA hostkey and SSHv1 server support in their bundled version of OpenSSH. This was done more than a year after upstream OpenSSH removed them, and both will remain enabled the 10.x branch until its end of life date. This decision upsets the author, but is the right thing to do. You don't turn off things that people may be depending on in a .x release, you do it in a .0 release. 11.0 was the first .0 release since he wrote this, so it was done as fast as possible. As a FreeBSD user, I appreciate that the .x releases do not contain major changes that break things I may have been depending on. I accept that I need to carefully read the release notes for a .0 release, to see what things I can expect to be broken.
    - byuu 10y ago
      > Firewall: I don't think default to no firewall is a problem -- if you want something, you can set it up. I'm very curious about this one ... As far as I know, any remote holes without a firewall on a default install would be a ground-breaking, DEFCON-1 level security event to server admins. Complete with CVEs, news coverage on various sites, etc ... right? The only time in history I recall this being a problem was with Windows XP, which led to Blaster and Sasser. Now I'm absolutely in favor of firewalls, but whenever I spin up a new VPS, there's going to be a window of about 20-30 minutes where I need to get in there, upload my SSH public keys, secure SSHD, tweak my sysctls, write out my pf firewall rules, and then activate them. There are also times when I need to test why a connection is failing, and one of the steps to testing is to turn off the firewall momentarily. I know that attacks are basically incessant against any server on the net. I see dozens of IPs trying brute-force root login SSH attempts a day against my boxes. How much danger is there, honestly speaking (not hypothetically), in this window? Would it be worth it to petition VPS providers to allow us to specify our own IP address, and have them enable a default "deny everything except from this one IP" firewall setup on new instances, or is that just total overkill?
- acidbaseextract 10y ago
  The contempt for people outside security, and their perspectives, is a huge problem. Another great article, "Infosec's Jerk Problem" (2013): http://adversari.es/blog/2013/06/19/cant-we-all-just-get-along/ http://adversari.es/blog/2013/06/19/cant-we-all-just-get-alo...
  - AstralStorm 10y ago
    It is not contempt when nobody would have and business enabling these unapproved options, especially by default. Backwards compatibility is not a reason for insecurity. Even Microsoft deprecated wrong options after some time.
byuu 10y ago
I have to agree. I'm reminded of OpenBSD's move in 6.0 to enforce W^X on binaries. This breaks the use of my cooperative threading library: in order to avoid requiring specific compilers/assemblers (for the portion that's impossible to write in pure C), I use ~50 bytes of pre-compiled code so that it'll compile anywhere. To do that, I have to mark the block R|X. But I can't know with 100% certainty that the codepage doesn't overlap with something that was writable (since there is no mgetprotect), so I have no choice but to set R|W|X. So probably what I'll have to end up doing is allocate at least three codepages at run-time, set to R|W, copy the code there, then set R|X, and take a performance penalty for needing a pointer to the code block. What I would like to see FreeBSD do to help with migrating to stronger security is something like "freebsd-harden" that you run once after a new installation or version upgrade, and it will walk you through a series of yes/no prompts, and advise, "if you aren't sure, say no."
- deaddodo 10y ago
  HardenedBSD[1] is FreeBSD pre-hardened. This is one of the few times I agree with a parallel sister project over multi-paradigm design, since they make pretty significant changes to the Kernel+World[2] that aren't necessarily beneficial to home users. 1 - https://hardenedbsd.org/ https://hardenedbsd.org/ 2 - https://hardenedbsd.org/content/freebsd-and-hardenedbsd-feature-comparisons https://hardenedbsd.org/content/freebsd-and-hardenedbsd-feat...
- danieldk 10y ago
  What I would like to see FreeBSD do to help with migrating to stronger security is something like "freebsd-harden" that you run once after a new installation or version upgrade, and it will walk you through a series of yes/no prompts, and advise, "if you aren't sure, say no." Actually, they now have such a post-install script: https://reviews.freebsd.org/D6826 https://reviews.freebsd.org/D6826 https://wiki.freebsd.org/WhatsNew/FreeBSD11#Security https://wiki.freebsd.org/WhatsNew/FreeBSD11#Security
  - byuu 10y ago
    Very cool! And I can use this menu over a VPS SSH session (so no color support) after the initial install? Usually I think of bsdinstall as being run pre-install, not post-install.

by stonogo 10y ago

fleitz 10y ago

Exactly. I don't see these so much as poor choices as not security focused choices. Perhaps OpenBSD might be a better fit for this users needs.

api 10y ago

This is what's wrong with infosec. The majority of security people seem to have no concern for any other issue, resulting in them giving a lot of ham fisted advice that gets ignored. In the end security is worse as a result. I worked in infosec for a while and saw it at the org level: 1. Security recommends something with no concern for how it inconveniences (or worse) the users. 2. Users ignore or even actively work around security. 3. Users get pwned and blame security. 4. Security gets mad, calls users stupid, goes back to making ham fisted recommendations that everyone ignores because they have to get their work done. 5. Goto 1. In the end I concluded that we (security) were at fault. In many cases there were user sensitive options and I would make an effort to find them, but most of security actively had contempt for anyone outside security and didn't care.

X86BSD 10y ago
That is just common in IT not specifically the security nerds. Every group has their little fiefdom. DBAs, data architects, Unix admins, etc.
jms703 10y ago
This isn't about myopic security recommendations. These are just plain bad defaults and a failure to manage tech debt. No one that "knows what they are doing" wants to accept these risks and addressing them doesn't hurt users. Fixing these problems is totally realistic.
- toast0 10y ago
  Some of these are bad defaults, some of these are common defaults that turned out to be bad, some of these are not easy to fix. Many of these things just take time to do right. Examples: ntpd is clearly not great software, but OpenNTPD is maybe a little bit too minimal. When ntimed is worthy, I'm sure it'll make it into FreeBSD base, but it's most likely going to be in a .0 release, so it'll be a while and people will be impatient. OpenSSL is hard. software in base needs libcrypto and libssl, so you need to pick a version and stick with it throughout the release cycle; but the FreeBSD release cycle is longer than the OpenSSL cycle; OpenSSL has also historically not been very good at keeping ABI compatibility. There's a lot of smart people working on this, but I think the least bad option is to not use openssl from base for anything outside of base. Firewall: I don't think default to no firewall is a problem -- if you want something, you can set it up. > Five months after this document was published, FreeBSD disabled DSA hostkey and SSHv1 server support in their bundled version of OpenSSH. This was done more than a year after upstream OpenSSH removed them, and both will remain enabled the 10.x branch until its end of life date. This decision upsets the author, but is the right thing to do. You don't turn off things that people may be depending on in a .x release, you do it in a .0 release. 11.0 was the first .0 release since he wrote this, so it was done as fast as possible. As a FreeBSD user, I appreciate that the .x releases do not contain major changes that break things I may have been depending on. I accept that I need to carefully read the release notes for a .0 release, to see what things I can expect to be broken.
  - byuu 10y ago
    > Firewall: I don't think default to no firewall is a problem -- if you want something, you can set it up. I'm very curious about this one ... As far as I know, any remote holes without a firewall on a default install would be a ground-breaking, DEFCON-1 level security event to server admins. Complete with CVEs, news coverage on various sites, etc ... right? The only time in history I recall this being a problem was with Windows XP, which led to Blaster and Sasser. Now I'm absolutely in favor of firewalls, but whenever I spin up a new VPS, there's going to be a window of about 20-30 minutes where I need to get in there, upload my SSH public keys, secure SSHD, tweak my sysctls, write out my pf firewall rules, and then activate them. There are also times when I need to test why a connection is failing, and one of the steps to testing is to turn off the firewall momentarily. I know that attacks are basically incessant against any server on the net. I see dozens of IPs trying brute-force root login SSH attempts a day against my boxes. How much danger is there, honestly speaking (not hypothetically), in this window? Would it be worth it to petition VPS providers to allow us to specify our own IP address, and have them enable a default "deny everything except from this one IP" firewall setup on new instances, or is that just total overkill?
acidbaseextract 10y ago
The contempt for people outside security, and their perspectives, is a huge problem. Another great article, "Infosec's Jerk Problem" (2013): http://adversari.es/blog/2013/06/19/cant-we-all-just-get-along/ http://adversari.es/blog/2013/06/19/cant-we-all-just-get-alo...
- AstralStorm 10y ago
  It is not contempt when nobody would have and business enabling these unapproved options, especially by default. Backwards compatibility is not a reason for insecurity. Even Microsoft deprecated wrong options after some time.

byuu 10y ago

I have to agree. I'm reminded of OpenBSD's move in 6.0 to enforce W^X on binaries. This breaks the use of my cooperative threading library: in order to avoid requiring specific compilers/assemblers (for the portion that's impossible to write in pure C), I use ~50 bytes of pre-compiled code so that it'll compile anywhere. To do that, I have to mark the block R|X. But I can't know with 100% certainty that the codepage doesn't overlap with something that was writable (since there is no mgetprotect), so I have no choice but to set R|W|X. So probably what I'll have to end up doing is allocate at least three codepages at run-time, set to R|W, copy the code there, then set R|X, and take a performance penalty for needing a pointer to the code block. What I would like to see FreeBSD do to help with migrating to stronger security is something like "freebsd-harden" that you run once after a new installation or version upgrade, and it will walk you through a series of yes/no prompts, and advise, "if you aren't sure, say no."

deaddodo 10y ago
HardenedBSD[1] is FreeBSD pre-hardened. This is one of the few times I agree with a parallel sister project over multi-paradigm design, since they make pretty significant changes to the Kernel+World[2] that aren't necessarily beneficial to home users. 1 - https://hardenedbsd.org/ https://hardenedbsd.org/ 2 - https://hardenedbsd.org/content/freebsd-and-hardenedbsd-feature-comparisons https://hardenedbsd.org/content/freebsd-and-hardenedbsd-feat...
danieldk 10y ago
What I would like to see FreeBSD do to help with migrating to stronger security is something like "freebsd-harden" that you run once after a new installation or version upgrade, and it will walk you through a series of yes/no prompts, and advise, "if you aren't sure, say no." Actually, they now have such a post-install script: https://reviews.freebsd.org/D6826 https://reviews.freebsd.org/D6826 https://wiki.freebsd.org/WhatsNew/FreeBSD11#Security https://wiki.freebsd.org/WhatsNew/FreeBSD11#Security
- byuu 10y ago
  Very cool! And I can use this menu over a VPS SSH session (so no color support) after the initial install? Usually I think of bsdinstall as being run pre-install, not post-install.