FreeBSD - a lesson in poor defaults

The fact that expected behaviour does not easily change is a big plus for FreeBSD. I can't help but think that a discussion about defaults is really about the balance between stability of older systems and expected behaviour versus out-of-the-box behaviour for new users.
 
The fact that expected behaviour does not easily change is a big plus for FreeBSD. I can't help but think that a discussion about defaults is really about the balance between stability of older systems and expected behaviour versus out-of-the-box behaviour for new users.
Good point. I would also like add to this that no matter what the defaults are, there will always be some users that don't like some of them for whatever the reason. No matter how hard you try, it's just not possible to please everyone all of the time.
 
Good point. I would also like add to this that no matter what the defaults are, there will always be some users that don't like some of them for whatever the reason. No matter how hard you try, it's just not possible to please everyone all of the time.

Honestly I don't mind the tweaking, since it teaches me about the OS and you learn why and where things are. Saves alot of time when you know how to adjust something without having to ask, or go searching the internet.
 
No offense to you, but I can't help but notice that you're fine with the defaults simply because they don't require you to learn new software and change old habits.

Have to chuckle at that comment. Yeah, I suppose I'm "new to Unix," since my first install was AT&T system 7 (as I recall) on a PDP-11 around 1979. Yes, having a recent sendmail in the distribution was a plus for me, only in that it means that I don't have to download the source distribution and compile it before configuring it for use. That is what I have been doing on Solaris, as the package in the last Solaris 10 distribution is a bit ancient. From my perspective, if something I've built and configured for use in my Solaris boxes is available on FreeBSD, either in the basic installation or in /usr/ports, great. If not, and if it is available as open source, I'll download it, compile it, and install it.
Such was the case with the CDE desktop, which I have up and running.

All in all, it has been clear to me for some time that I needed to move to another O/S, because Solaris as I have used it has vanished into the maw of Oracle, and I didn't see Openindiana as a solid replacement. The move to FreeBSD has been, for the most part, surprisingly easy, and if the installation defaults aren't what I want, it hasn't been much work to build and install what I need and want. Right now I'm waiting for the 10.3 release to replace my crash-and-burn 10.2 test installation with a production installation on another box.
 
Have to chuckle at that comment. Yeah, I suppose I'm "new to Unix," since my first install was AT&T system 7 (as I recall) on a PDP-11 around 1979.

Nah, I just meant that your post essentially says "I like the FreeBSD defaults because they let me use my old Solaris configurations." I can totally understand why that's appealing, and familiarity is a valid reason for liking something. But the concern raised by the link in the OP was that the default configurations might present easily avoidable security/stability risks to users and add unnecessary difficulties for the FreeBSD developers and maintainers.

Again, I meant no offense, but if certain choices are arguably making many people's lives riskier and harder for no good reason then changing them would arguably be a net gain for the project and community. Not wanting to force lots of people to immediately make major changes to fundamental configuration is a good reason to avoid radical change. Not wanting to force a few people to eventually reconfigure one or two things is a terrible reason to avoid gradual (and arguably progressive) change.
 
Good point. I would also like add to this that no matter what the defaults are, there will always be some users that don't like some of them for whatever the reason. No matter how hard you try, it's just not possible to please everyone all of the time.

And therein lies the crux of the matter. ANOKNUSA brings up the subject of security in a default install. While I have talked about moving from a Solaris 10 Desktop/Server setup to FreeBSD 10.2, I suspect that what I run here (essentially, a pair of ISP servers) is not what the majority of new-to-FreeBSD users need to set up. For one thing, I have full Internet backbone feeds (no filtering, including the DDoS and script kiddie stuff) with static IP's.

My upstream feed is a small local ISP, whom I've helped set up a rural wireless deployment, so I do get some "special folks" treatment from them. One biggie on my systems is that I run a Mailman server.

My servers connect to the Internet backbone through Fortinet Fortigate firewalls with Fortiguard UTM to keep the script kiddies at bay. Not cheap, but they sure do a job.
Properly configured, a Fortigate 60 allows me to run FreeBSD "naked" without much fear of the script kiddies getting through. And let me assure you, running ISP services gets tons of hacking attempts---I spend as much time on security as I do on everything else.

As I said at the outset, installing Tcpwrappers with some security as a default gives at least some protection against the script kiddies. It's also simple for a novice to configure.

I'm not going to belabor the default install of sendmail(8) to any great extent.
As a matter of fact, I have my own way of building the .cf files, which means that my installation is already non-standard. Yes, learning to administer sendmail(8) for a novice is probably more of an exercise than something like postfix(1), but if FreeBSD installed with postfix(1), I'd build sendmail(8) and install it. Installing it as a default sends a clear message that "Hey, Toto, this isn't Linux." That along with not installing an X11 server and one of the popular (Linux) window managers by default.

Virtually all of the security notices I've seen have been for ssh(1), ssl(3), bind(1), and ntp. What are you folks going to do, eliminate ssh(1) and ssl(3) from the default install because they get security notices? A lot of things depend on having those two.

Going back to protocelt's comment, I don't think that any out-of-the-box O/S install is going to meet the exact need of any advanced UNIX user.
 
Going back to protocelt's comment, I don't think that any out-of-the-box O/S install is going to meet the exact need of any advanced Unix user.

FreeBSD actually shines here, because it doesn't install nearly as much stuff by default as some other OSs. Even Debian installs with a bunch of extra stuff, a significant percentage of which I have to delete after. The list of defaults considered in the featured article is actually pretty short, all things considered.
 
Going back to protocelt's comment, I don't think that any out-of-the-box O/S install is going to meet the exact need of any advanced UNIX user.

Completely agreed on that point. I'll also say that personally, I probably don't put as high a priority on security as the author of that list might. Just as most people don't need everything included in base (and so aren't affected by every security issue that might arise), most people don't need maximum security. Security is an important thing, and I think minimizing the effort the developers have to undertake to keep up with security should be be addressed, but I'm not advocating locking everything down by default or removing anything that has a half-dozen security issues in a single year or anything like that. The convenience of a user configuring a new system can be balanced with reasonably secure default settings. Just as most people don't need everything that's included in the base system, most people don't need the maximum security settings common programs might offer. Someone configuring a new install shouldn't have to worry about whether their version of OpenSSH is out-of-date, but they shouldn't have to physically carry their SSH keys to a new machine either.

I wouldn't be surprised if the developers actually intend to address some of these things once 11.0 is out and the new support scheme becomes active. It's only necessary to support as many older versions of common utilities as there are older minor releases of FreeBSD, for as long as those older minor releases of FreeBSD are supported. Both those quantities are about to be cut down, with only 10.3 and 11.0 being supported as of the end of this year. Fewer supported release and a more predictable user upgrade schedule could make it much easier to incorporate new releases of common utilities into new releases of FreeBSD.
 
I'll also say that personally, I probably don't put as high a priority on security as the author of that list might. Just as most people don't need everything included in base (and so aren't affected by every security issue that might arise), most people don't need maximum security. Security is an important thing, and I think minimizing the effort the developers have to undertake to keep up with security should be be addressed, but I'm not advocating locking everything down by default or removing anything that has a half-dozen security issues in a single year or anything like that. The convenience of a user configuring a new system can be balanced with reasonably secure default settings. Just as most people don't need everything that's included in the base system, most people don't need the maximum security settings common programs might offer. Someone configuring a new install shouldn't have to worry about whether their version of OpenSSH is out-of-date, but they shouldn't have to physically carry their SSH keys to a new machine either.

From my perspective, there is just no such thing as "too much security," even if you are not running a port 25 mail server and ports 80 and 443 web server. Over the past year, botnet and script kiddie probes getting out to my system have risen dramatically, and I've had some conferences with my upstream feed's network people about botnet probes flooding their wireless antenna system and degrading performance. Last summer, I configured a Solaris 10 "crash and burn" box to run without a hardware firewall/router in front of it, just to see what was coming out as far as their transmitting antennas. WOW! Peaks of thousands of probes per second to fingerd, portmapper, named, SNMP, telnet, rlogin and a few others. That sacrificial system got hacked at least twice, requiring a full reinstall from cold to recover. I'm not going to go into a lot of detail about what my upstream provider needed to do to block those probes from their server farm vs. what I needed to do on my server network. Suffice it to say that both my upstream provider and I have had to become much more security-conscious than we were a year ago, particularly in regard to Unix/Linux security.
 
What I heard from one of the CCC network people, that when they attach their conference network and initiate the border routing (making is a new country, as far as I understood), they get about four MBit of traffic instantly. No system is there beyond the routers, but the scanning starts within seconds. So, automatic port scanning is a given, and script kiddies likewise (you are still not allowed to, ahem, re-educate them. With a pice of 2x4. With nails in it).

The default values for anything that might directly face the internet should be hard and draconic, in my opinion.
 
The default values for anything that might directly face the internet should be hard and draconic, in my opinion.

Absolutely. Better to have to switch on the stuff that is needed, rather than remember to disable the stuff that isn't. I found the original linked article/doc very informative, and it fits nicely with some new hardening scripts I am writing for our servers. If nothing else, getting people talking about these types of issues (and generating the resulting knowledge/tips) is immensely useful.
 
The default values for anything that might directly face the internet should be hard and draconic, in my opinion.

Even at points further removed things need to be tight. Several of the VPS's that I've set up had over 100 intrusion attempts per minute almost right away. This is an insignificant amount, but a threat is a threat.

Absolutely. Better to have to switch on the stuff that is needed, rather than remember to disable the stuff that isn't.

This is an extremely important point. One does not "remember" to turn something off which one has not touched in the first place. One will, however, go looking for something to turn on if things aren't working.
 
and script kiddies likewise (you are still not allowed to, ahem, re-educate them. With a pice of 2x4. With nails in it).

Wouldn't we all like to do that.?

This is an extremely important point. One does not "remember" to turn something off which one has not touched in the first place. One will, however, go looking for something to turn on if things aren't working.

This^
 
This is an extremely important point. One does not "remember" to turn something off which one has not touched in the first place. One will, however, go looking for something to turn on if things aren't working.
Or even worse is when it was off by default and gets turned on behind your back because some stupid component will not work without it. And then some installation code is being "helpful" and turns on something you know is meant to be off.

Wouldn't we all like to do that.?
I would be interested in a poll on this, but it might not be completely politically correct ;)
 
My upstream feed is a small local ISP, whom I've helped set up a rural wireless deployment...
What I heard from one of the CCC network people, that when they attach their conference network and initiate the border routing (making is a new country, as far as I understood), they get about four MBit of traffic instantly.

Yeah, things are a lot less problematic for residents of urban America, sitting behind colossal ISPs with dedicated routers at multiple junctures. It's good to be reminded now again not to take that convenience for granted. Thanks. :)
 
and there are show notes on the topic.

From the notes: "The article suggests just removing sendmail with no replacement. Not sure how they expect users to deliver mail, or the daily/weekly reports"

Can someone explain why the assumption that there are users and why, when there are any, it would be a requirement for them to deliver mail? And what's wrong with logs for reports? This just sounds like some personal use case or quirky preference and comes off as outright bizarre as a choice for everybody.

I'm loathe to criticize FreeBSD but on the surface, the above seems almost as badly conceived as when Linux distros vehemently insist that you must have an office suite the size of the rest of the OS.

I can see how this default made sense 20 years ago, and is here for backward compatibility. But that was a long time ago. I'm waiting to be educated. :)
 
From the notes: "The article suggests just removing sendmail with no replacement. Not sure how they expect users to deliver mail, or the daily/weekly reports"

Can someone explain why the assumption that there are users and why, when there are any, it would be a requirement for them to deliver mail? And what's wrong with logs for reports? This just sounds like some personal use case or quirky preference and comes off as outright bizarre as a choice for everybody.

I'm loathe to criticize FreeBSD but on the surface, the above seems almost as badly conceived as when Linux distros vehemently insist that you must have an office suite the size of the rest of the OS.

I can see how this default made sense 20 years ago, and is here for backward compatibility. But that was a long time ago. I'm waiting to be educated. :)
Me too was wondering why someone should rely on sendmail for notifications. Nothing against sendmail, but I enable it only for messages from cron and if there is a way to have such messages in a log file instead, I would be very happy. :)
 
I believe they are just making up stupid excuses. I guess nobody said anything about changing default OpenSSH settings in stable/* branches, it's just that head also enables DSA. The same applies to OpenSSL. While stable/* could stay on OpenSSL, as insecure as it is, head could switch to LibreSSL, at least with experimental, non-default src.conf knob. In fact, that's what HardenedBSD with FreeBSD LibreSSL maintainer do. Take a look at https://wiki.freebsd.org/LibreSSL/Base

I'm seriously considering switching to HardenedBSD when 11.0-RELEASE is out, they at least seem to take security seriously, while providing source compatibility with FreeBSD (not sure about binaries).
 
Can someone explain why the assumption that there are users and why, when there are any, it would be a requirement for them to deliver mail? And what's wrong with logs for reports?
I already mentioned this in an earlier post. It's good to see I'm backed up on that.

You guys shouldn't assume that, as users, your needs are the same as corporations, ISPs, server farms, etc.
 
I'm seriously considering switching to HardenedBSD when 11.0-RELEASE is out, they at least seem to take security seriously, while providing source compatibility with FreeBSD (not sure about binaries).

Is HBSD a drop in replacement for FreeBSD for most purposes? I've tried it a few times in a VM and it seems pretty close.
 
drhowarddrfine, I'm mostly with you. My main problems with sendmail are its weight, complexity, and historical baggage. Tons of files, in several places, with a configuration syntax that's arcane. Simply replacing it with logging won't really fix anything, though. Recording periodic and error reports to log files means the admin then has to habitually check those logs. But that's not big deal---it can be done right after punching in each morning, right?

Well, different periodic configurations take different amounts of time to run depending on which checks are performed, and different checks take different amounts of time to perform depending on how much hardware and how many files have to be dealt with. So it's not predictable when the admin might have logs ready to be checked. And that's just for periodic---everyone has differently sized crontabs, and new cron jobs and scripts being tested would also need to be logged, and these logs would be generated whenever the system got around to executing, finishing, and logging the process.

So now the admin falls prey to that perennial bad habit of the office drone, checking every half hour to see if any new messages are available and seeing that there aren't, though there could have been, though there haven't been any the last six times they were checked, but maybe next time, so keep checking... The solution to that, of course, is to create some kind of notification mechanism that alerts the admin when new logs are available. Which means new code, and new configurations. Which then need to be added to the system. And should probably have default settings, which need to be hashed out by the people making it...

So yeah, e-mail is the way to handle this. I can't argue with that. I just think a lighter mailer with a simple config should be doing the job for most, with other alternatives available in the ports tree for those who need them.
 
Thanks for the link, interesting stuff to read.
I'm glad I was not the only one who was bothered by the default permissions of configuration files such as firewall rules, default home users permissions and mainly, /root permissions. This does bother me a lot.

And as make installworld overwrites it each and every time I had to create a script that runs every day to check it - as I always forgot about it after upgrade.

This bothers me too.

I know many things in /etc/ probably need to be read by all. That's just the fact of operating systems and I'm not advocating major changes with that. However, why in the world would you have a default option for jungle to be able to see all of matoatlantis's files in the home directory?? This is a very, very small change. When you adduser, you can set the home permissions however you want, so TJ is just advocating making it not read only by everyone.
 
Back
Top