Plugin, Shell Access and Firewall Security

Status
Not open for further replies.

gundam212

Dabbler
Joined
Mar 16, 2014
Messages
10
I'm in love with FreeNAS. Unfortunately, over the last year I've become increasingly aware of the many security risks that seem to be overlooked by the community. I'm not saying that everyone is as security conscious as I am but I find it somewhat staggering that default out of box FreeNAS configuration leaves so many holes open for a would be attacker.

When setting up file system permissions for my plugins I noticed that the method for FreeNAS to check status and change configuration for the plugins was via FastCGI bound to a large consecutive port number. At first I assumed this port was only accessible via the FreeNAS IP or something similar but after some investigation I discovered that it was access to this FastCGI port was completely unrestricted.

In most cases this could prove to be a bit of an annoyance, as an attacker could send malicious commands to turn on or off your plugins causing the administrator some headaches, but this unrestricted access could also be used to view or change the settings of any plugin installed on your FreeNAS system, something I personally view as an unacceptable risk.

To prevent this kind of access I've enabled ipfw rules for all the plugins that I'm running to only accept connections on that port from the FreeNAS IP.

I wish that the security woes ended there, but unfortunately they continue with many issues associated with how much unrestricted access is given to a single username/password combination for the WebGUI.

As far as I know the root user is the only one who has access to the WebGUI with no method of allowing access for another user or disabling the root user all together. Regular use of the root account is and should be strongly discouraged for any BSD or Linux based operating system, yet FreeNAS forces the use of the root user account.

It really baffles me, especially when out of the box FreeNAS does not encrypt access to the WebGUI allowing transmission of the root password in plain-text each time the root user is logged in. In addition my attempts to configure HTTPS access has left me with so many bugs it almost feels like the developers are ignoring them. With HTTPS enabled the WebGUI can not acquire status information from the plugins and adding new plugins or attempting to upgrade old plugins fails. Albeit this is my personal setup and it might simply be a bug, but the truth is that for me at least HTTPS seems almost un-useable.

Ultimately here is my request:
  1. A tiered permission system for access to sections of the WebGUI.
  2. Disable or discourage root access to the WebGUI.
  3. Enable HTTPS by default.
  4. Prevent shell access without login by default, both in WebGUI and console for FreeNAS and Jails.
  5. Rethink using FastCGI for plugin configuration and status or enable firewall rules to prevent remote access to the FastCGI ports.
  6. Enable ipfw firewall on FreeNAS install by default and only allow access for services and jails that are actively running.
I hope that we all agree that without these changes we're putting Exabytes of data at risk for all FreeNAS users.
 

joeschmuck

Old Man
Moderator
Joined
May 28, 2011
Messages
10,970
I think you are barking up the tree but if there was a feature you desired you should submit a feature request via "BugReports".
 

Knowltey

Patron
Joined
Jul 21, 2013
Messages
430
Regarding #2, that used to be the case, but was very recently made not the case for reasons.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
  1. A tiered permission system for access to sections of the WebGUI.
  2. Disable or discourage root access to the WebGUI.
  3. Enable HTTPS by default.
  4. Prevent shell access without login by default, both in WebGUI and console for FreeNAS and Jails.
  5. Rethink using FastCGI for plugin configuration and status or enable firewall rules to prevent remote access to the FastCGI ports.
  6. Enable ipfw firewall on FreeNAS install by default and only allow access for services and jails that are actively running.
I hope that we all agree that without these changes we're putting Exabytes of data at risk for all FreeNAS users.

Well, we don't all agree.

Discouraging use of root is historically something that new admins have been taught is a "good thing" for sometimes vague and nebulous reasons, but largely has to do with accountability and accident-prevention. However, FreeNAS is really an appliance and not a UNIX box, and so the mentality that's appropriate is an appliance-style mentality, not a UNIX-style mentality. The original design actually attempted to implement a separate "admin" account which turned out to be a bit of a quagmire - because it was a UNIX-style mentality.

Enabling HTTPS by default involves some fudgery with certificates, and my opinion is that half-assing it is not a good idea. If you want HTTPS, then the right way is to get a certificate from your local CA or a commercial CA and install it. "Default" HTTPS designs always involve some sort of cruddy self-signed certificate strategy that usually fails at some point when someone does something like reinstalls the firmware - I've seen this too often on products. Either HTTPS is important or it isn't. If it is important then it should be done correctly, and basically that means an admin should properly configure it.

ipfw by default isn't going to happen for performance reasons, and because your filer probably shouldn't be exposed to attackers in the first place. That said, I do appreciate that ipfw is now an available option.

As for the remainder of your points, I may either agree or have no opinion, depending.
 

Knowltey

Patron
Joined
Jul 21, 2013
Messages
430
ipfw by default isn't going to happen for performance reasons, and because your filer probably shouldn't be exposed to attackers in the first place. That said, I do appreciate that ipfw is now an available option.

Yeah, being a firewall isn't something that the FreeNAS should be doing. If you have a properly configured network, the network gateway, or a device somewhere upstream on the network should be handling all of the traffic and security enforcements. Clients on the network, be they servers or workstations should not be relied on to provide their own security. You're just asking for trouble doing that.
 

Whattteva

Wizard
Joined
Mar 5, 2013
Messages
1,824
I think you're confusing FreeNAS with PFSense or even OpenBSD.
FreeNAS was never designed to be a security product. It is a file server designed to stay in a trusted private network and isolated from the outside world with a primary focus on performance, data integrity, and ease of use, not security.

Also, basic UNIX philosophy: Do one thing and do it well. Use the right tool for the job. You're asking FreeNAS to essentially be an all-in-one firewall/NAS solution.
 
Last edited:

gundam212

Dabbler
Joined
Mar 16, 2014
Messages
10
I think I'm being misinterpreted, I don't feel like FreeNAS should be a network wide firewall solution but I feel that it should protect itself from internal attacks. I understand that placing FreeNAS behind a dedicated firewall on both the local and remote side and honestly I did not think of this as an option mostly because in my home environment I do not have the resources or hardware to setup such a system.

After reading some of your comments I do agree that FreeNAS does a great job of focusing on its purpose and I should not remain ignorant to the ideal usage scenario. In an enterprise environment I could easily see FreeNAS sitting behind a local firewall protecting it from access to all but needed services for clients and in that case many of my suggestions become irrelevant.

I do still believe that FreeNAS plugins should find a better way to configure, control and check plugin status and more tiered access levels for WebGUI administration would be superb.
 

Whattteva

Wizard
Joined
Mar 5, 2013
Messages
1,824
I do still believe that FreeNAS plugins should find a better way to configure, control and check plugin status and more tiered access levels for WebGUI administration would be superb.
Plugins are totally extra and not part of the base system. I would think the burden of "securing" such a setup is on the individual user that chooses to install them. Also, the fact that they run in an isolated jail environment as unprivileged user sort of minimizes damage should a breach occur.

Regarding tiered access levels for WebGUI. I think that just adds a whole level of complexity and headaches considering some of the target audience. I mean people already have ENOUGH problems as is with UNIX and Windows ACL's... adding yet another level of ACL's just to administer that would probably warrant yet another topic on the forums.
 

SwampRabbit

Explorer
Joined
Apr 25, 2014
Messages
61
This thread sparked my interest right away as I already searched around for security related threads when I first joined.

I am only replying to the thread to spark some good security conversation, maybe help people learn more (including myself), and maybe help FreeNAS become more secure than it already is. Be it with these items or others.

I fully understand some of the reasoning given to gundam212, but at the same time I think they do bring up some very valid points, or at least thinking that is always very important with any system (be it designed as an appliance or not).
I am not arguing his points, but a few of the items he brought up bothered me when I first installed FreeNAS and found out they weren't already implemented.

Honestly I don't buy the whole "appliance", "some of the target audience", "trusted network" reasons. I understand the view point, I do, but I also think it goes against best security practices in general.
All software should focus on security from the design and development, this is being pushed more and is slowly catching on more. I'm NOT saying the FreeNAS Dev team is not doing this well or not doing this at all.

Let me explain how I see their individual points:

1. A tiered permission system for access to sections of the WebGUI.​

This creates least privilege and separation of duties, accountability, and auditing. Not sure how anyone can argue against having that, especially in a very large organization where you have to sprinkle out responsibilities more.
I do understand that many times it may be overkill, especially if you have one person administering a single box, but if FreeNAS/TrueNAS is really suppose to be for enterprise organizations then this would be a very good feature.
That said, least privilege, separation of duties, accountability, and auditing are a bit hard to do if you need to incorporate them as it stands now.
More often than not these are actual organizational requirements and if something doesn't support it, it makes it hard to fit it into an organization without accepting that risk.

2. Disable or discourage root access to the WebGUI.​

I fully understand the notion of "trusting" your administrators. But this one really is hard to accept, no matter if its Windows, Unix, Linux, or anything for that matter.
I don't like using root or administrator, but everyone has been brought up differently to this one. People (users/admins) are the problem.
Again, I feel it goes back to least privilege, separation of duties, accountability, and auditing. All of which are really hard to do, if you have a dozen or so people logging in as "root".
- Bob is about to get fired, or wants to get Jim in trouble, or is mad the receptionist doesn't like him. Bob logs in as root, breaks some stuff, removes the receptionists home folder.
All hell breaks loose in the office, Bob points the finger at Jim. Either way, you get the point.
Many organizations have a strict requirements not to use default or built in accounts (even system ones).

3. Enable HTTPS by default.​

I don't agree with this one, I understand this one is really hard to utilize in a non-enterprise (home) environment fully.
The fact that someone can enable it and utilize it, even to some degree, I believe is good enough.

4. Prevent shell access without login by default, both in WebGUI and console for FreeNAS and Jails.
What's the next best thing to physical access?
- Shell access, especially remote shell access.
I suppose shell access in the WebGUI isn't as bad as straight at the console. Then again already logged in as the account everyone except the janitor knows about.
Haven't messed with the Jails yet, but I plan on it.
I don't like shell access really, if needed I think it should be able to be restricted as much as possible.

5. Rethink using FastCGI for plugin configuration and status or enable firewall rules to prevent remote access to the FastCGI ports.
Not familiar with this fully, so I won't comment.

6. Enable ipfw firewall on FreeNAS install by default and only allow access for services and jails that are actively running.
This one along with only being able to use the root account, bothered me the most. I really do think system level firewalls are a important part of a Defense in Depth strategy. I fully understand that it can add a lot of complexity and in turn hassle.
But I also think the important part that they tried to stress was "only allow access for services and jails that are actively running".
I am not sure how hard or to what affect this would have if just a default set of rules where used for the ports, protocols, and services that FreeNAS uses was set up during install and modified as others are utilized. But honestly I think this would make FreeNAS much more secure.

Let me explain why I am sort of adding another view point, rather than just accepting what has been said, and to spark more conversation about it.

I want to use FreeNAS (at home) because of performance, data integrity, and ease of use. Not because I feel it meets my overly zealous need for security in all the software and systems I use. If I didn't know how to properly restrict access to it at multiple other levels, I wouldn't be using it. It does have some nice abilities to restrict somethings, which is almost as good as a secure true appliance based NAS that does nothing else.

But most home/small business users don't know how to, nor do they really concern themselves with it. They hook it up to their Linksys router, which probably is running more services, has more open ports, with WEP enabled WiFi than the one at McDonalds. A few more security options would be very beneficial to them, their data, and the reputation of FreeNAS.

From an enterprise stand point, especially in the environments I work in.
I would never be able to get a proposal to purchase TrueNAS or run FreeNAS off the ground without laying out a semi-large risk to mitigation matrix, along modifications to the Defense in Depth plan for the vulnerabilities being introduced, and be able to justify the benefits over other more secure options.
And honestly that is just based on the root account and firewall one because it trickles from there.

Again, I am NOT saying FreeNAS is completely insecure, or that the Devs aren't doing a good job. I think there some great options and defaults already in place there, just hoping more discussion can help it evolve even more secure.
 

Whattteva

Wizard
Joined
Mar 5, 2013
Messages
1,824
This thread sparked my interest right away as I already searched around for security related threads when I first joined.

I am only replying to the thread to spark some good security conversation, maybe help people learn more (including myself), and maybe help FreeNAS become more secure than it already is. Be it with these items or others.

I fully understand some of the reasoning given to gundam212, but at the same time I think they do bring up some very valid points, or at least thinking that is always very important with any system (be it designed as an appliance or not).
I am not arguing his points, but a few of the items he brought up bothered me when I first installed FreeNAS and found out they weren't already implemented.
Fair argument. No problems here.

Honestly I don't buy the whole "appliance", "some of the target audience", "trusted network" reasons. I understand the view point, I do, but I also think it goes against best security practices in general.
All software should focus on security from the design and development, this is being pushed more and is slowly catching on more. I'm NOT saying the FreeNAS Dev team is not doing this well or not doing this at all.
What you buy and what other people buy are totally subjective judgment. And the devs have to sacrifice something from the tradeoff triangle. Remember, you can only maximize two legs of that triangle, not all three of them.

Let me explain how I see their individual points:

1. A tiered permission system for access to sections of the WebGUI.​

This creates least privilege and separation of duties, accountability, and auditing. Not sure how anyone can argue against having that, especially in a very large organization where you have to sprinkle out responsibilities more.
I do understand that many times it may be overkill, especially if you have one person administering a single box, but if FreeNAS/TrueNAS is really suppose to be for enterprise organizations then this would be a very good feature.
That said, least privilege, separation of duties, accountability, and auditing are a bit hard to do if you need to incorporate them as it stands now.
More often than not these are actual organizational requirements and if something doesn't support it, it makes it hard to fit it into an organization without accepting that risk.
Overkill indeed. Majority of people would probably not use it at all. Large enterprises probably would tend to use something a lot more configurable than a somewhat "live distro" like FreeNAS anyway.
Most likely, they'd probably run vanilla FreeBSD/OpenBSD or some version of enterprise Linux.
2. Disable or discourage root access to the WebGUI.​

I fully understand the notion of "trusting" your administrators. But this one really is hard to accept, no matter if its Windows, Unix, Linux, or anything for that matter.
I don't like using root or administrator, but everyone has been brought up differently to this one. People (users/admins) are the problem.
Again, I feel it goes back to least privilege, separation of duties, accountability, and auditing. All of which are really hard to do, if you have a dozen or so people logging in as "root".
- Bob is about to get fired, or wants to get Jim in trouble, or is mad the receptionist doesn't like him. Bob logs in as root, breaks some stuff, removes the receptionists home folder.
All hell breaks loose in the office, Bob points the finger at Jim. Either way, you get the point.
Many organizations have a strict requirements not to use default or built in accounts (even system ones).
I think you bring up a valid point here, but if we look at the features configurable on the web GUI, you'd realize probably 90% (if not all) of it are root-level settings anyway (things you can't do without a sudo). It just makes a lot of sense to do it this way. Additionally, most enterprises probably only have a few people (I could be wrong) dedicated to administration tasks as it becomes chaotic the more people you pick. On top of that, any enterprise worth their salt would have access logs for every administrative task performed, essentially putting an end to any kind of blame game before it even started. Finally, an enterprise that does not have periodic backups to fall back on in case of the scenario you mentioned really deserves that catastrophe.
3. Enable HTTPS by default.​

I don't agree with this one, I understand this one is really hard to utilize in a non-enterprise (home) environment fully.
The fact that someone can enable it and utilize it, even to some degree, I believe is good enough.
I don't think I know enough to comment on this, so I'll leave this for others.
4. Prevent shell access without login by default, both in WebGUI and console for FreeNAS and Jails.
What's the next best thing to physical access?
- Shell access, especially remote shell access.
I suppose shell access in the WebGUI isn't as bad as straight at the console. Then again already logged in as the account everyone except the janitor knows about.
Haven't messed with the Jails yet, but I plan on it.
I don't like shell access really, if needed I think it should be able to be restricted as much as possible.
This argument only applies to the local console as that is the only one that's not restricted by login. But to be able to even see the web GUI, you need to login.
The same thing applies to jails. You either have to setup SSH into the jail or use jexec (which requires sudo).
I suppose I agree with your sentiment that the shell should be restricted as much as possible since a lot of people have shot themselves in the foot trying random commands from Google that they really have no business doing. However, there would need to be some sort of setting to unlock it for power users.
5. Rethink using FastCGI for plugin configuration and status or enable firewall rules to prevent remote access to the FastCGI ports.
Not familiar with this fully, so I won't comment.
I'm in same boat, lol.
6. Enable ipfw firewall on FreeNAS install by default and only allow access for services and jails that are actively running.
This one along with only being able to use the root account, bothered me the most. I really do think system level firewalls are a important part of a Defense in Depth strategy. I fully understand that it can add a lot of complexity and in turn hassle.
But I also think the important part that they tried to stress was "only allow access for services and jails that are actively running".
I am not sure how hard or to what affect this would have if just a default set of rules where used for the ports, protocols, and services that FreeNAS uses was set up during install and modified as others are utilized. But honestly I think this would make FreeNAS much more secure.
This one is a fair argument, but adds a ton of complexity that is probably unrealistic to the developers. There are so many rules and so many plugins that are not even really their responsibility. We're not even getting into normal FreeBSD packages that any arbitrary user can pick and install into their jails. I totally see your point, but it is a very unrealistic expectation.
 
Last edited:

SwampRabbit

Explorer
Joined
Apr 25, 2014
Messages
61
Fair argument. No problems here.
Overkill indeed. Majority of people would probably not use it at all. Large enterprises probably would tend to use something a lot more configurable than a somewhat "live distro" like FreeNAS anyway.
Most likely, they'd probably run vanilla FreeBSD/OpenBSD or some version of enterprise Linux.

I agree, a large enterprise may not want to use TrueNAS/FreeNAS, but I think it is a very viable option to be considered either way.
For small to medium business, I think TrueNAS/FreeNAS an excellent resource, especially with granular WebGUI permissions. I'll touch on that next, because it sort of ties in with the root account concept.

I think you bring up a valid point here, but if we look at the features configurable on the web GUI, you'd realize probably 90% (if not all) of it are root-level settings anyway (things you can't do without a sudo). It just makes a lot of sense to do it this way. Additionally, most enterprises probably only have a few people (I could be wrong) dedicated to administration tasks as it becomes chaotic the more people you pick. On top of that, any enterprise worth their salt would have access logs for every administrative task performed, essentially putting an end to any kind of blame game before it even started. Finally, an enterprise that does not have periodic backups to fall back on in case of the scenario you mentioned really deserves that catastrophe.

Yes, I understand most are functioning at the root-level. But even you hit at something that could assist in not just having root login to the WebGUI and add somewhat of "A tiered permission system for access to sections of the WebGUI". Sudo, we can already give users sudo permissions, but that doesn't affect the WebGUI.
What if users added to sudo, were given WebGUI access?
This right here allows you to have accountability when you have more than one person administrating.
I can't argue that a big enterprise will have other controls in place such as access logs. But even then you may be hunting down logs at multiple levels at this point, which could be a mess, how well that works depends on logging and auditing capabilities and policy of an organization.
A SMB will probably not have all of that and yes a business like this may only have one admin (probably a Windows only one at that). But the ability to harden root access and have the ability to have the company admin mange FreeNAS, but the desktop support person add accounts would be very useful. Yes sometimes large enterprises like to go the "one man show" route to reduce issues, won't get into how this can also cause issues here. But how helpful would the example I just gave for the SMB be at an enterprise level?
I think both the root and tiered permission system for access to sections of the WebGUI boil down to least privilege and separation of duties, accountability, and auditing. I know I keep beating that drum, but meh.

This argument only applies to the local console as that is the only one that's not restricted by login. But to be able to even see the web GUI, you need to login.

If the local console is main risk with this one, then that does help. Because if someone has physical access then you sort of have bigger issues anyway.

This one is a fair argument, but adds a ton of complexity that is probably unrealistic to the developers. There are so many rules and so many plugins that are not even really their responsibility. We're not even getting into normal FreeBSD packages that any arbitrary user can pick and install into their jails. I totally see your point, but it is a very unrealistic expectation.

If someone is adding plugins, jails, or other packages in general, they are probably going to be configuring a firewall in the jail either way since more than likely they are reaching outside of LAN at that point. Personally I more than likely will not be running anything else on FreeNAS, maybe I will tinker, but I don't agree in running extra stuff on a NAS for a lot of reasons. So for me, required ports being opened OTB or when services are activated; or a simple firewall page in the WebGUI would work well. I am not disagreeing that it may be a unrealistic expectation, but I think its worth some thought, and maybe some testing.

Sorry if this isn't written up so well, at the day job.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
I agree, a large enterprise may not want to use TrueNAS/FreeNAS, but I think it is a very viable option to be considered either way.
For small to medium business, I think TrueNAS/FreeNAS an excellent resource, especially with granular WebGUI permissions. I'll touch on that next, because it sort of ties in with the root account concept.

I just had to LOL on that one. Large enterprises DO come to iX.

The rest I'm not going to even bother commenting on because:

1. It doesn't matter.
2. iX has already made their decision on this and if you don't like it you can fork it.
3. The current design for FreeNAS clearly works and is secure, so "goto #1".
 

SwampRabbit

Explorer
Joined
Apr 25, 2014
Messages
61
I just had to LOL on that one. Large enterprises DO come to iX.

The rest I'm not going to even bother commenting on because:

1. It doesn't matter.
2. iX has already made their decision on this and if you don't like it you can fork it.
3. The current design for FreeNAS clearly works and is secure, so "goto #1".

I don't think anyone is saying large enterprises do not come to iX for solutions.
And I don't think anyone is saying it is not secure; just talking about possible ways to improve it.

I don't know all the changes/enhancements TrueNAS has over FreeNAS, so maybe none of this applies to TrueNAS.
I think the thread starter was only concerned with FreeNAS anyway.

But you and I both know, the enterprises that I work for are "not allowed" to use FreeNAS for some of the reasons I talked about in my first post.
It goes against mandatory security requirements, incorporating FreeNAS in would be a pain from a operational, technical, and procedural standpoint, let
alone getting someone to accept the risk even if they are limited. Again its
I saw that a few sub organizations are commented as clients or at least "notable relationships we've fostered". Honestly I have never seen or heard of any iX systems being used or recommended. And I have a really good up to date overall view of what is used throughout our enterprises.
I am sure there are some out there (more than likely only as TrueNAS if that) but still probably at a limited scope (restricted NAS or DAS), and very restricted in other ways.

I believe TrueNAS/FreeNAS overall is a better solution than the ones we use at the moment. They are horribly limited, over priced, etc, etc.
But they meet all the mandatory security requirements like the ones I hit on. When you can open it up for remote access, ftp, torrenting, and the like; this is where more risk is introduced, especially when done incorrectly.
Now many other appliance do not have full firewalls built in, but they also do not have the ability to be anything than a NAS, DAS, or SAN. In fact I could probably get away with convincing someone that measures were in place already to mitigate this.
But being forced to use a default admin account, especially root, won't work out.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
SwampRabbit,

I've worked in places that have extremely strict security requirements. The problem: Every single little market that has strict security requirements, be it health records, government classified documents, or things like nuclear security, they all have a laundry list of requirements. And every single laundry list is slightly different, with many of them being options that would exclude other industries from their required laundry list.

There's 2 things you should take away from the conversation:

1. The people that make the decisions have already made the decision.. and they don't see a need for it because of how TrueNAS(and FreeNAS) is sold. They're making money and they've decided for at least one reason to do what they are doing and it is working for them.
2. The people that make the decisions are not here, so it doesn't matter if every single point you made above is completely correct. Nobody will read it with any decision making power.

Yes, they've heard both sides of the story, and the bottom line is that the firewall really won't add much value as the only services that are listening are the minimum required to get the job done anyway. If those have security vulnerabilities a firewall isn't going to help. The whole reason people do firewalls is because many OSes (Windows in particular) has done stupid stupid things with their OS. You used to be able to call system level services remotely... without authenticating! FreeBSD is a totally different beast and isn't susceptible to those kinds of stupid and extremely poor decisions.

Anyway, I'm out of here. I spent 10 minutes responding to this thread and that was 10 minutes longer than I should have. This topic has been discussed to DEATH and there's nothing to be said that hasn't been said before in years gone by.

/rollseyes
 

SwampRabbit

Explorer
Joined
Apr 25, 2014
Messages
61
Understood.

I just thought it was a decent topic to discuss, that's all, but I know not to try and ride a dead horse.
 

gundam212

Dabbler
Joined
Mar 16, 2014
Messages
10
Understood.

I just thought it was a decent topic to discuss, that's all, but I know not to try and ride a dead horse.

This saddens me because it only confirms my suspicions about the general feel towards security in the FreeNAS community. For a user to say that discussing security is riding a dead horse really makes me lose all hope that this community and the dev's have any intention of working towards a more secure system.

Sure, for large scale environments measures would be put in place to ensure the system is adequately protected, but with passwords, data, credit card information being stolen in mass we have to admit that additional levels of security should not be considered excessive or unnecessary. The entire point of my posting this thread was to bring security minded discussions to the community. A discussion that is terrifyingly sparse in my opinion.

@cyberjock, I have ready many of your posts and understand your passion towards a properly configured ZFS setup. You provide excellent data on setting up scrubs SMART tests, understanding the necessity of ECC RAM and countless other threads dedicated to preventing mass dataloss due to hard drive failure or an improperly configured systems. My discussion of securing the FreeNAS system only extends your passions towards a properly configured ZFS system. The only difference I see here is you're protecting the data from neglect or hardware failures, I am protecting the data from from malicious intent. To have you claim that the decision has already been made and essentially be told that I can leave if I don't like it goes against the title of the thread "Feature Request". All that I hoped for was a positive exchange of dialog, but I suppose I'm looking in the wrong place.
 

Whattteva

Wizard
Joined
Mar 5, 2013
Messages
1,824
Feature Request means exactly what it says. You can request anything you want, but it doesn't necessarily mean that you will get it. I do understand your feeling of frustration of getting dismissed so bluntly though.

Some lines have to be drawn to prevent feature bloat (I'm sure you've heard that term plenty of times).
FreeNAS was designed to primarily be a file server, not all-in-one network server solution. If you looked at traditional UNIX tools (vi, ls, grep, sed, find, etc.), they're all generally designed to do one purpose and do it well. Of course, there are exceptions to this as Emacs is essentially an all-in-one mini LISP-based extensible OS, but then again, people often complain about Emacs being bloated.

Also, one of the traditional rules about security is that you should never mix your security and other services/content on the same box. So feature requests like this (while perfectly valid), is probably not too high on the priority list due to the things I previously discussed.

In any case, if you're really THAT paranoid about security, then you should probably be using something else anyway. OpenBSD comes to mind with their "Only 2 remote holes in a heck of a long time" motto. Then again, even that's a little misleading cause that only applies to their base system, which sure as hell doesn't have all the services that we ask for on FreeNAS.
Naturally, OpenBSD does not claim that their motto stands for non-base systems because quite frankly, protecting a system that runs all sorts of services is infinitely harder. This demonstrates yet again, the reason why you should never mix security and other things on the same box.
OpenBSD also has a rather abysmal package selection compared to FreeBSD (7199 vs 24504). Yet, another demonstration that you can't have it all. OpenBSD essentially sacrifices features and flexibility in favor of security. If security really is the be-all end-all, then we'd all be running OpenBSD right now.
 
Last edited:

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
@cyberjock, I have ready many of your posts and understand your passion towards a properly configured ZFS setup. You provide excellent data on setting up scrubs SMART tests, understanding the necessity of ECC RAM and countless other threads dedicated to preventing mass dataloss due to hard drive failure or an improperly configured systems. My discussion of securing the FreeNAS system only extends your passions towards a properly configured ZFS system. The only difference I see here is you're protecting the data from neglect or hardware failures, I am protecting the data from from malicious intent. To have you claim that the decision has already been made and essentially be told that I can leave if I don't like it goes against the title of the thread "Feature Request". All that I hoped for was a positive exchange of dialog, but I suppose I'm looking in the wrong place.

Right, but firewalls for FreeBSD are not the "end-99% of all problems" that they are for Windows machines. In fact, it's pretty unimportant if designed even remotely decently. I know many FreeBSD kernel developers that put their FreeBSD box directly on the internet with no firewall and have no qualms about it at all. While my first reaction is "f*ck you.. that system will never touch my network" after a while when you see everyone doing it you figure out that *you* are the minority.

The reality is that you have to ask yourself what firewalls are for and what do they actually block? Then you realize that all of the ports FreeNAS listens on are, for the most part, pretty secure. The only reason this is even a concern is because people are stupid and don't do things like use https, use strong passwords, setup permissions that don't involve "full permissions for guests" and crap like that. Those things are why FreeNAS should be behind a firewall. It is also why file servers themselves should always be behind a firewall.

So your arguments, while quite valid for Windows machines, aren't really in the right ball park for FreeNAS machines. People already use firewalls to separate their LAN from the WAN (aka internet). But all the arguments that continually are made aren't really any safer by giving FreeNAS a firewall.

Quite literally, if FreeBSD had a firewall it would block all ports except the ones that are already open. So what's the damn difference between blocking all ports except the open ones with a firewall and having all ports closed except the open ones? 6 of one and 1/2 dozen of the other!
 

SwampRabbit

Explorer
Joined
Apr 25, 2014
Messages
61
I really didn't want to add to this thread, I can accept cyberjock's answers, because when it boils down to it; this is how the Devs want it. I never really harped too much on the firewall piece, it was first two requests.
Whattteva - Maybe I am just interpreting what you said the wrong way. But....

Feature Request means exactly what it says. You can request anything you want, but it doesn't necessarily mean that you will get it.
Some lines have to be drawn to prevent feature bloat (I'm sure you've heard that term plenty of times).
FreeNAS was designed to primarily be a file server, not all-in-one network server solution. If you looked at traditional UNIX tools (vi, ls, grep, sed, find, etc.), they're all generally designed to do one purpose and do it well. Of course, there are exceptions to this as Emacs is essentially an all-in-one mini LISP-based extensible OS, but then again, people often complain about Emacs being bloated.

"not all-in-one network solution" "feature bloat"?
What like plugins: torrenting, plexserver, couchpotato?

Sure FreeNAS is primarily used for unified storage, but to say anything out of that scope is off the table, is also wrong because it is made to be extensible.
For some users recreational plugins are bloat, for others smart tests, logs, and scrubs are bloat, and others maybe system and file permission options are bloat. So feature bloat is in the eyes of the Devs and users.

Also, one of the traditional rules about security is that you should never mix your security and other services/content on the same box. So feature requests like this (while perfectly valid), is probably not too high on the priority list due to the things I previously discussed.

What you said is not true, mostly just how you said. I don't think anyone would gripe if the Devs said no to having Snort or Squid installed. Again I understand the firewall piece, most people could agree that you can handle that at the network level.

"one of the traditional rules about security is that you should never mix your security and other services/content on the same box" is like saying "don't run spam filters on your email server", "don't run Snort on PFsense if your using it as a router", or "don't run Fail2Ban on your remote webserver".

Over doing it is one thing, running EVERYTHING on one box is bad if you think the network can be unsecure because of it.

Security features and services to a degree are always needed on any box. FreeNAS uses Jails for a reason, don't see anyone calling that feature bloat or unneeded.
If someone at work from IT security or administration tried to sell me on that rule (exactly how you worded it); I would personally fire them, flog them, and throw them out the building myself because that person is putting the business at risk of losing money.

Please don't say "one of the traditional rules about security is that you should never mix your security and other services/content on the same box". This, how it is worded is not true, and someone could get the wrong impression.

In any case, if you're really THAT paranoid about security, then you should probably be using something else anyway. OpenBSD comes to mind with their "Only 2 remote holes in a heck of a long time" motto. Then again, even that's a little misleading cause that only applies to their base system, which sure as hell doesn't have all the services that we ask for on FreeNAS.
Naturally, OpenBSD does not claim that their motto stands for non-base systems because quite frankly, protecting a system that runs all sorts of services is infinitely harder. This demonstrates yet again, the reason why you should never mix security and other things on the same box.
OpenBSD also has a rather abysmal package selection compared to FreeBSD (7199 vs 24504). Yet, another demonstration that you can't have it all. OpenBSD essentially sacrifices features and flexibility in favor of security. If security really is the be-all end-all, then we'd all be running OpenBSD, which we all know, of course, isn't the case.

The original poster was only bringing up some things to talk about, a few that he thought of. Adding tons of services and software isn't all he talked about, he also mentioned some minor configuration changes that have very good impact on the usability and security of any system. The first two I think are the BIG ones.
Last time I checked a lot of appliances, servers, etc, etc it was pretty standard for the tiered permission system for access and to disable or discourage root access. There are reasons for this and it involves risk to time and money.

NAS4Free has those two bloated and troublesome features, then again, they don't push plugins to download games and comics with that appliance.
Not saying NAS4Free is better, just using that as an example.
 

Whattteva

Wizard
Joined
Mar 5, 2013
Messages
1,824
I really didn't want to add to this thread, I can accept cyberjock's answers, because when it boils down to it; this is how the Devs want it. I never really harped too much on the firewall piece, it was first two requests.
Whattteva - Maybe I am just interpreting what you said the wrong way. But....
Nothing wrong with adding more. A forum's intention is after all, to exchange ideas and constructive criticism.

The original poster was only bringing up some things to talk about, a few that he thought of. Adding tons of services and software isn't all he talked about, he also mentioned some minor configuration changes that have very good impact on the usability and security of any system. The first two I think are the BIG ones.
Last time I checked a lot of appliances, servers, etc, etc it was pretty standard for the tiered permission system for access and to disable or discourage root access. There are reasons for this and it involves risk to time and money.

NAS4Free has those two bloated and troublesome features, then again, they don't push plugins to download games and comics with that appliance.
Not saying NAS4Free is better, just using that as an example.
Ok, maybe I came on too strong.
If you think FreeNAS pushes plugins and jails, you're badly mistaken though. I think those are provided for flexibility so that people can run extra stuff IF they want to and they're more maintained by the PC-BSD project rather than the FreeNAS project.
Most remote holes are typically a result of code bugs and user error. The former, you can mitigate running minimal amount of services and by keeping up-to-date with security advisories. The latter one is a BIG one. No amount of security in the world is going to save you from user error.

What you said is perfectly valid (particularly in regards to fail2ban), but there are also times when too much security (complexity) can actually hinder your user so much that they just decide to turn it off altogether; effectively the exact opposite of your intention.
There are plenty of examples of this, people using transmission or some sort of the downloader plugins are prime example of this. They usually do chmod 777 cause they keep having file permission issues and that solves it in the easiest way possible.
People turning off Windows UAC (cause it was annoying) when it was first introduced in Vista is another example.
Now I have no idea what ixSystems view as the target audience, but I get the feeling that ease of setting up is one of the design goals (what with web GUI and one-click service start/stop) and simplicity usually comes at a tradeoff, which may or may not include security.

Bottom line, I'm not disagreeing with you and actually like a lot of the suggestions that the original poster mentioned. Just saying that I wouldn't put my hopes up too much for it.
 
Last edited:
Status
Not open for further replies.
Top