4 ms·

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" w

by 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?
  - humpdinger 10y ago
    The really good VPS providers, allow out of band serial/VNC consoles so you can bring them up and configure prior to enabling networking. The really really good ones allow you to install from your own images, in which case you can preconfigure firewall etc.
  - lmm 10y ago
    I've never understood the argument for system-level firewalls at at all. If a service is listening on a port from the network, presumably that's for a reason and you're going to end up writing a firewall rule for it anyway. If you have complex rules that try to filter out "bad guys" then your firewall is a complex piece of software full of parsers and the like, probably written in C "for performance", and you're exposing it to external packets - that's a bigger attack surface than not having a firewall. If your services are using sockets for local communication, bind to 127.0.0.1 or use a unix domain socket.
    - Xylakant 10y ago
      Quite a few services bind to all interfaces by default. Redis used to, elasticsearch used to, iirc mongodb as well. The list is probably long. While this is a bug in the software, having a firewall that denies by default is an additional layer that prevents turning a slip-up into an RCE.
    - VLM 10y ago
      If you assume lack of cooperation and separation of duties it can sometimes make a microscopic amount of sense. So security says thou shall not VNC and configures a very tight system level firewall, preventing some jerk end user from compiling and running a VNC server over port 10000 because the system level firewall blocks everything that's not explicitly permitted. Oh you've "broken" the system SSHD such that I can't even use it, I'll just compile and run my own sshd as an end user and run it on port 11000 or whatever. In practice I'd agree with you in that an org where security, admins, and users are pulling opposite directions is going to have massive problems in general and a mere system level firewall isn't going to patch over all of it. For a distant historical example I've worked at places where for temporary use I've had to shut down apache on port 80 and run sshd there on port 80 for a few moments, just to copy a config file over. A REALLY smart deep packet inspection firewall would notice the conversation on port 80 was very SSH like not HTTP like, but whatever. Speaking of VNC that made me LOL at the linked article suggestion to block X11 traffic, an end user who "really wants GUI" will simply fire up an unauthenticated possibly passwordless VNC server on some port. Security would have been a lot better off with SSH trying to be secure rather than VNC not trying at all. Some end users are just crazy some times. Oh I'm not allowed to run NFS because "security theatre", well OK them I'll just set up anonymous FTP because that's not blocked. I've seen some stuff...
alwillis 10y ago
I’m fairly new to FreeBSD; I've been using it for various small projects off and on since 9.x. I also previously worked for MIT for over a dozen years and worked fairly closely with network security colleagues. To me, the attitude of we're not going to change the defaults the neckbeards cut their teeth on 20 years ago regardless of the insane threat environment we exist in today and if you get hacked, owned or worse, it's your own damn fault for not knowing all of the tweaks that could have saved your ass that we decided not to make defaults even if they are defaults upstream is the height of Unix elitism IMHO. In the world we live in, having defaults stay the same for the sake of not inconveniencing people who already know better is incredibly shortsighted. And it makes it way more difficult for newbies who don't have time to cobble together best practices from all the relevant IRC chat rooms, email lists and blog posts to learn FreeBSD’s best practices. It doesn't make a lot of sense to have a default install of FreeBSD that allows users new to the platform and who are looking around and kicking the tires that also allows users to shoot themselves in the foot unnecessarily. Thanks to the author’a article, I now disable the default settings for OpenSSH, use OpenNTPD, encrypt swap and build everything I can against libressl-devel. The fact that so many of what are mostly common sense proposed defaults are perceived as breaking some kind of FreeBSD oath of obfuscation doesn't help grow the FreeBSD community in the long run. That's something to also consider.

by jms703 10y ago

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?
- humpdinger 10y ago
  The really good VPS providers, allow out of band serial/VNC consoles so you can bring them up and configure prior to enabling networking. The really really good ones allow you to install from your own images, in which case you can preconfigure firewall etc.
- lmm 10y ago
  I've never understood the argument for system-level firewalls at at all. If a service is listening on a port from the network, presumably that's for a reason and you're going to end up writing a firewall rule for it anyway. If you have complex rules that try to filter out "bad guys" then your firewall is a complex piece of software full of parsers and the like, probably written in C "for performance", and you're exposing it to external packets - that's a bigger attack surface than not having a firewall. If your services are using sockets for local communication, bind to 127.0.0.1 or use a unix domain socket.
  - Xylakant 10y ago
    Quite a few services bind to all interfaces by default. Redis used to, elasticsearch used to, iirc mongodb as well. The list is probably long. While this is a bug in the software, having a firewall that denies by default is an additional layer that prevents turning a slip-up into an RCE.
  - VLM 10y ago
    If you assume lack of cooperation and separation of duties it can sometimes make a microscopic amount of sense. So security says thou shall not VNC and configures a very tight system level firewall, preventing some jerk end user from compiling and running a VNC server over port 10000 because the system level firewall blocks everything that's not explicitly permitted. Oh you've "broken" the system SSHD such that I can't even use it, I'll just compile and run my own sshd as an end user and run it on port 11000 or whatever. In practice I'd agree with you in that an org where security, admins, and users are pulling opposite directions is going to have massive problems in general and a mere system level firewall isn't going to patch over all of it. For a distant historical example I've worked at places where for temporary use I've had to shut down apache on port 80 and run sshd there on port 80 for a few moments, just to copy a config file over. A REALLY smart deep packet inspection firewall would notice the conversation on port 80 was very SSH like not HTTP like, but whatever. Speaking of VNC that made me LOL at the linked article suggestion to block X11 traffic, an end user who "really wants GUI" will simply fire up an unauthenticated possibly passwordless VNC server on some port. Security would have been a lot better off with SSH trying to be secure rather than VNC not trying at all. Some end users are just crazy some times. Oh I'm not allowed to run NFS because "security theatre", well OK them I'll just set up anonymous FTP because that's not blocked. I've seen some stuff...

alwillis 10y ago

I’m fairly new to FreeBSD; I've been using it for various small projects off and on since 9.x. I also previously worked for MIT for over a dozen years and worked fairly closely with network security colleagues. To me, the attitude of we're not going to change the defaults the neckbeards cut their teeth on 20 years ago regardless of the insane threat environment we exist in today and if you get hacked, owned or worse, it's your own damn fault for not knowing all of the tweaks that could have saved your ass that we decided not to make defaults even if they are defaults upstream is the height of Unix elitism IMHO. In the world we live in, having defaults stay the same for the sake of not inconveniencing people who already know better is incredibly shortsighted. And it makes it way more difficult for newbies who don't have time to cobble together best practices from all the relevant IRC chat rooms, email lists and blog posts to learn FreeBSD’s best practices. It doesn't make a lot of sense to have a default install of FreeBSD that allows users new to the platform and who are looking around and kicking the tires that also allows users to shoot themselves in the foot unnecessarily. Thanks to the author’a article, I now disable the default settings for OpenSSH, use OpenNTPD, encrypt swap and build everything I can against libressl-devel. The fact that so many of what are mostly common sense proposed defaults are perceived as breaking some kind of FreeBSD oath of obfuscation doesn't help grow the FreeBSD community in the long run. That's something to also consider.