My FreeBSD hardening script

Wravoc

Wravoc

Hello all, my first post!
Been using FreeBSD for a week or two now and I wanted to secure the simple things right away as is my nature. I wrote a Python script that can set and re-set:

  • rc.conf
  • sysctl.conf
  • loader.conf
  • login.conf

Along with a set of mitigations that I've gathered over the years from everywhere including a lot in this forum, including the hardening FreeBSD thread of course.

The script also does simple syntax verification of the flags like equal is present, quotes are present in pairs, etc. It sets blowfish encryption for passwords as suggested in the official guide, password expirations, and lots more. I also included some third-party software in the repo to validate the implementation of the settings to ensure confidence.

I really aimed it at the new user like myself who can quickly just run a script that is not so impactful of function but also get a lot for it, quickly.

Let me know if there are holes in it, things I could better, just plain mistakes, etc. Also this is my second Python script ever so if you have any suggestions where I could really use some refactoring or streamlining I'd hear that too!

github.com

GitHub - wravoc/harden-freebsd: Updated for 14.0. A half days worth of work can be done in seconds, with comprehensive logging, togglable secure/performance settings, and backups. Implements a broad, time-tested, thoroughly researched, cohesive grou

Updated for 14.0. A half days worth of work can be done in seconds, with comprehensive logging, togglable secure/performance settings, and backups. Implements a broad, time-tested, thoroughly rese...
github.com github.com

Thanks!
Elias
 
Ok, naïvely I had the syntax checking tuned for the default amd64 FreeBSD confs which was too narrow and just not suitable for the purposes I had listed. I'm removed the syntax checking to much more lenient so it will work on hosted VM's from cloud providers for instance. As well, a FreeBSD developer pointed out that many kernel directives are already on by default for 64bit since 13.1; reverted those to 32bit and removing two others.

I updated the code so if you had errors please try again. Updating the README to reflect the changes now.
 
Hi

I reviewed your project and I will only say this

1.- The license sucks. Almost proprietary in essence.
2.- You are looking for AIs not to use your code, but it is ironic that you use an AI to generate the image of your project.
 
🤨 You don’t do that. It seems you are replicating functionality. How is your script addressing a need that has not been addressed otherwise?​
ArgentoSoma said:
You are looking for AIs not to use your code, but it is ironic that you use an AI to generate the image of your project.
Click to expand...
Given that (to the best of my knowledge) no jurisdiction ascribes legal capacity to non-humans in the first place, some provisions are laughable.​
 
Interesting perspectives.

A ton of forward thinking and planning was put into my *first of it's kind* License for very specific aims that may not be apparent and it's certainly unique, so difficult to compare. I expected some amount of negative feedback on the License which I'm fine with. I think that the fact that anyone can add as much code as they wish, modify the code, and modularize it within their own code base takes it right out of the proprietary zone.

> You don’t do that. It seems you are replicating functionality. How is your script addressing a need that has not been addressed otherwise?

I am hardening FreeBSD and quite well! To verify, run the additional software checks **before** you run my script, to compare afterwards. Huge difference.

I'm not replicating functionality, I'm replicating results, there is a difference. I go about these settings in a completely different way (function) than anything/one else. The script goes far beyond the default hardening script and any other *script* I've seen. If we are comparing my script to HardenedFreeBSD project the differences are very apparent and not applicable.

My script is easier, faster, and does less lockdown than the aforementioned leaving more functionality intact. The scopes are very very different. My script is aimed at new users to FreeBSD so that the distribution can be more confidence inspiring to new users so as to enlarge the user base of FreeBSD while at the same time making it more secure. I'd like to think I'm providing a valuable service to this community.

HardenedFreeBSD project is for advanced uses where the SysAdmin knows how to restore the functionality of applications and services lost with more the more impactful settings and kernel modifications. With my script, most applications and services are not impacted.

Additionally, my script allows for easily undoing all of it and with no kernel recompile needed. My script allows for you to customize your own security. My script allows it to be used just for jails.

> Given that (to the best of my knowledge) no jurisdiction ascribes legal capacity to non-humans in the first place, some provisions are laughable.

Now here I can elucidate why I chose the License I did.

1. They already have precedent for full legal rights. In 2017 the robot Sophia was declared a citizen by Saudi Arabia. Under my license terms, this "robot" with undetermined cognitive faculties (Is it really AI?) would nevertheless not be allowed to use my software.
2. They will have more rights in the future. A simple web search for "AI rights" would suffice to come to this conclusion but I will show as an example this Forbes article.

> What is really needed is documentation, preferably as a handbook section, on possible hardening steps describing how and why something needs to be modified.

This is mostly in the readme although in depth explanations as to why are not. The reason is most experienced SysAdmins already know the settings and are referenced in the FreeBSD Handbook already. Being aimed also at new users, the "why" would be an entire handbook itself, a whole different project, but as stated, they have been picked so the new user *does not* need to know why what they do, only that they provide baseline security, with little to no loss of functionality.

> Running scripts from unknown source in the interwebs sounds like the opposite of any hardening.

That sounds like an indemnification of all of GitHub, a very peculiar assessment. The point of Open Source Software, in the literal sense that you are able to see my code, *is itself* the trust needed. Additionally, I put my full name and former Job working in Computer Security.

Would it endear more trust to add my LinkedIn where you can see I worked with some of the top Companies in the world in the field of Security?

-Elias
 
i don't like the license, but other than that, seems like a good piece of software for freebsd beginners, i just have a slight issue with there being no documentation. i also dont see a usecase for myself to use this.
 
Ok ffqq noted and thank you.

So help me out here. The links to mans/articles/documentation I provided for most of the security settings is not enough or doesn't even qualify as documentation and it would behove me to provide a full and comprehensive security guide that covers all settings and how they impact the OS? That would be just as much work as the software! I see this is in demand though.

  • In-repo document folder, in-line readme links, readme chapter, or separate website or all?
  • Markdown, HTML, TXT, or in-software?
  • Self-contained or curated?
  • Stick with official FreeBSD or best-of?
  • Provide impact and possible incompatibilities for each setting?
  • Recommend setting groups for particular security goals?
  • Document what each of the confs does for new users?
  • Document the additional software?
  • ?

So this is a screenshot from the readme. I just have to ask, is everyone seeing this? This is no documentation? I fear I'm missing the point entirely somehow.

EDIT: <What happened to the screenshot? Strange..>

Here is a small section of the readme contents:

​

Setting Descriptors​

Startup

  • kern_securelevel_enable = "YES"
    • Enable access to other than permanently insecure modes
  • Disable Sendmail
  • syslogd_flags="-ss"
    • Disallow syslogd to bind to a network socket
  • clear_tmp_enable = "YES"
    • Clear the /tmp directory on reboot
  • icmp_drop_redirect="YES"
    • Disallow redirection of ICMP (ping, echo)
  • inetd_enable = "NO"
    • Disallow Network File System to share directories over the network
  • portmap_enable = "NO"
    • Disallow portmapping since Network File Systems is disallowed
  • update_motd = "NO"
    • Disallow computer system details from being added to /etc/motd on system reboot
System

  • kern.securelevel = 1 (*)
    • The system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem and /dev/kmem may not be opened for writing; /dev/io (if your platform has it) may not be opened at all; kernel modules (see kld(4)) may not be loaded or unloaded. The kernel debugger may not be entered using the debug.kdb.enter sysctl. A panic or trap cannot be forced using the debug.kdb.panic, debug.kdb.panic_str and other sysctl's.
  • security.bsd.see_other_uids = 0
    • Disallow users from seeing information about processes that are being run by another user (UID)
  • security.bsd.see_other_gids = 0 (*)
    • Disallow users from seeing information about processes that are being run by another group (GID)
  • security.bsd.see_jail_proc = 0 (Sysctl MIB Entry sysctl -a | grep security.bsd)
    • Disallow non-root users from seeing processes in jail
  • security.bsd.unprivileged_read_msgbuf = 0 (Sysctl MIB Entry sysctl -a | grep security.bsd)
    • Disallow non-root users from reading system message buffer
  • kern.randompid = 107 (*)
    • Force kernel to randomize process ID's using above salt value instead of sequential
  • net.inet.ip.random_id = 1
    • Randomize IP packet ID
  • net.inet.ip.redirect = 0
    • Disallow ICMP host redirects
  • net.inet.tcp.always_keepalive = 0
    • Disallow keeping open idle TCP connections
  • net.inet.tcp.blackhole = 2 +(UDP)(*)
    • Packets that are received on a closed port will not initiate a reply
  • net.inet.tcp.path_mtu_discovery = 0 (*)
    • Disallows TCP to determine the minimum MTU size on any network that is currently in the path between two hosts
  • net.inet.icmp.drop_redirect = 1
    • Pairs with rc.conf startup, as once enabled, it is then set
  • hw.mds_disable = 3 (*)
    • Enable Microarchitectural Data Sampling Mitigation version VERW
    • Change value to 3 (AUTO) if using a Hypervisor without MDS Patch
  • hw.spec_store_bypass_disable = 1 (*)
    • Disallow Speculative Bypass used by Spectre and Meltdown
  • kern.elf64.allow_wx = 0 (*)
    • Disallow write and execute for shared memory
Kernel

  • security.bsd.allow_destructive_dtrace = "0"
    • Disallow DTrace to terminate proccesses
    • Test DTrace hardening: Using all 3 commands should result in Permission denied or Destructive actions not allowed:
    • dtrace -wn 'tcp:::connect-established { @[args[3]->tcps_raddr] = count(); }'
    • dtrace -wqn tick-1sec'{system("date")}'
    • dtrace -qn tick-1sec'{system("date")}'
  • hw.ibrs_disable = "3" (*)
    • Prevent Spectre and Meltdown CPU Vulnerabilities, 3 for AUTO
  • kern.elf32.aslr.stack = "3" (*)
    • Address space layout randomization is used to increase the difficulty of performing a buffer overflow attack
    • 64bit is enabled by default in 13.2 so you can set this to 0 for 64bit processors or remove
  • kern.elf32.aslr.pie_enable = "1"
    • Enable ASLR for Position-Independent Executables (PIE) binaries
  • cpu_microcode_load = "NO"
    • Disallow automatic CPU Microcode updates
 

Attachments

  • Harden-freebsd-ss1.png
    Harden-freebsd-ss1.png
    970.4 KB · Views: 84
Wravoc said:
Let me know if there are holes in it, things I could better, just plain mistakes, etc.
Click to expand...
Your license will likely hamper any input - this drifts into "eat the cake and have it too" territory.

Why even go to the length of inventing a new proprietary license if there's more than enough boiler plate out there that gets the job done already? How do you measure 25% for example - does that include the comments noone is supposed to change? Is it LOC or functions we're counting here? Would you like to sue anyone who's got a sysctl command on Github because the other lines of code differ more than 25% from your repo?

Last time I checked, the BSD community was open to learning from each other and modifying things to your liking. While I can reasonably assume you're aiming for the first, you're basically chopping off the latter.

I'll stop the rant now and simply close with the following: I won't even look at your code. This way I can truthfully state that I wouldn't even be able to break your license because whatever I write will be "clean room'ed".
 
cmoerz said:
Your license will likely hamper any input - this drifts into "eat the cake and have it too" territory.

Why even go to the length of inventing a new proprietary license if there's more than enough boiler plate out there that gets the job done already? How do you measure 25% for example - does that include the comments noone is supposed to change? Is it LOC or functions we're counting here? Would you like to sue anyone who's got a sysctl command on Github because the other lines of code differ more than 25% from your repo?

Last time I checked, the BSD community was open to learning from each other and modifying things to your liking. While I can reasonably assume you're aiming for the first, you're basically chopping off the latter.

I'll stop the rant now and simply close with the following: I won't even look at your code. This way I can truthfully state that I wouldn't even be able to break your license because whatever I write will be "clean room'ed".
Click to expand...

What a nasty and mean comment. So if I don't work entirely free for you and give you the ability to do what you want with my work, you'll just steal my work/idea (replete with crime scene reference) and somehow that is better behavior than my behavior/choice with the License?
 
Hi.
Will these append the new values to my existing files. And will it remove duplicates in those files if already found?

Thanks
 
I'm sorry if you read my comment this way. My gripe goes towards the license, not the work.

I've belabored the point enough; it's fine to agree that we disagree.
 
Wravoc said:
Been using FreeBSD for a week or two now and (...)
Click to expand...
Hello mate.

IMHO 2 weeks is little to short to go that deep into the security - but millage will come - do not worry :)

For example - I know that for example kern.securelevel sounds great ... but to be honest its needed mostly on the Internet facing systems. When you have your systems not on the net - I never really turned it on (or saw anyone turning it on) when not needed.

I agree with previous commenters - information WHY you are changing them is the most important part - but I am not thinking about pasting the info from sysctl -d ... its definitely not enough. You need to explain the logic for each setting with its drawbacks/shortcomings and what good will it bring and against what it will protect You.

About the license - its your personal project and you can use whatever license suits You best - but if you expect ANY input/help/support/collaboration from the FreeBSD community - then it has to be FreeBSD license or BSD 2-Clause license.

Regards.
 
securelevel is one of those things that make it "fun". Does it work as advertised? I think so, but the tradeoff is a lot more work to administer the system. In the past it made it difficult/impossible to run X. Not sure if that holds true with current modesetting stuff.
Simple "man security" gives you a lot of really good information on hardening a system.
It's always a tradeoff between ease of use and security, one that only the user can make.
Example:
Put your root partition and say /usr on read-only media. That prevents an attacker from actually changing things, but it winds up making a lot of extra work to do a system update.

An old book that still applies is "Master FreeBSD and OpenBSD Security" by Yanek Korff, Paco Hope and Bruce Potter. It has good info about "The Big Picture" and then the building blocks to get you what you want. It was written in 2005 so some info may be outdated.

Above is all my opinion.
 
tedbell said:
Hi.
Will these append the new values to my existing files. And will it remove duplicates in those files if already found?

Thanks
Click to expand...
It will not remove duplicates in your existing confs although it will change them to the same value that is set in settings.ini. I might include that functionality later, thanks for that. I don't think there is any harm from duplicates AFAIK.

It definitely appends new values to the confs as most security values are not present and must be present for the script to fulfill it's goal.
 
Wravoc said:
I don't think there is any harm from duplicates AFAIK.
Click to expand...
Functionally, probably not, but understanding definitely.
If values are the same, it's a non issue, but if the values are different, it will be confusing.
Look at sysctls.conf
say you have a line early in the file that sets a specific sysctl to the value 1.
now that same sysctl is added at the end of the file but with the value of 0.
The final value on the running system will be 0, not 1 and a person looking at the file needs to figure out which one is correct.

Also be careful with a script automatically removing duplicates:
Some people will cut/paste the same line, but give different values and comment out the ones "not being used".
So if something is going to automatically remove duplicates, make sure they really are dupes and not just commented out on purpose.
 
  • Derivations, re-creations, re-generations, and adapations [sic] of the Software or Execution of the Software is strictly prohibited.
Click to expand...
Not allowing execution is going to drag in the rest of FreeBSD by using your script into that license. There's also mentions of execution elsewhere. The program's license shouldn't affect anything outside the software itself.

I suggest the MPL2.0 license. It could have improvements, however, it works well for what it's meant to do. It protects from patent trolls and only forces changes back which were made to files that are under the MPL. It's halfway between BSD licenses and GPL (closer to LGPL with better clarity of boundaries and less restriction), which importantly, it's not viral. From reading your license, it seems you want more restriction than MPL.

I was thinking about HardenedBSD, when I saw this thread. I'm glad that you mentioned it, and how your script was meant to be different.
 
sidetone said:
Not allowing execution is going to drag in the rest of FreeBSD by using your script into that license. There's also mentions of execution elsewhere. The program's license shouldn't affect anything outside the software itself.

I suggest the MPL2.0 license. It could have improvements, however, it works well for what it's meant to do. It protects from patent trolls and only forces changes back which were made to files that are under the MPL. It's halfway between BSD licenses and GPL (closer to LGPL with better clarity of boundaries and less restriction), which importantly, it's not viral. From reading your license, it seems you want more restriction than MPL.

I was thinking about HardenedBSD, when I saw this thread. I'm glad that you mentioned it, and how your script was meant to be different.
Click to expand...
Ah ok, that could have been worded much better. I was intending to mean that the adaptations cannot be executed which was kinda pointless. Fixed.

My License still allows for execution by Non-Human Intelligences, using the Senate and Military terms, basically intra and extra-terrestrial Aliens. The term is more broadly in denial, or otherwise more narrowly scoped, which would also exclude AI. I'll change it to that and think of other ways to strike a balance between my efforts and users want of free software.

I'm was trying to thread the needle here with my License and give people some control of my work, but not free work, and have enough appeal for the intended [newish] users. I'm keenly aware of the general fervor in the OSS space. I think most societally/civilization/people/ necessary Software like FreeBSD, should have something like BSD, LGPL, MGPL, etc so we people may all benefit, but certainly that shouldn't be the case for everything. I also think FreeBSD and RedHat shoulda had Government protection from being Corporatized. Honestly, what is keeping Meta from buying FreeBSD like IBM did with RedHat if it one day suited them? How would you feel then? Would you feel all your contributions and investment had been wasted, gated? How do we keep Software like the BSD's from buying bought by BigTech that doesn't care at all for you except for profit? Maybe that's how I view my software in a way.

I would allow FreeBSD to use my License if they wished!

I must say that my target audience probably does not zealously pursue GPL or BSD Licenses if there is a value proposition and still room the make the software work for you, make it your own, yet leaving room for the creator. This crowd here, as expected, the people that make FreeBSD work, the fans, are very driven by it being free and I do get that. Everyone's opinion has been heard and considered.

I'm surprised however that no one has considered a middle approach and asked me to up the mod percentage and made a good case for that. It seems to be a polar closed or completely open debate and that tells me a lot.

Also be careful with a script automatically removing duplicates:
Some people will cut/paste the same line, but give different values and comment out the ones "not being used".
So if something is going to automatically remove duplicates, make sure they really are dupes and not just commented out on purpose.
Click to expand...
Good point. Since this was a Python and FreeBSD learning project and License experimentation for me I was trying to avoid more SysAdmin tool approach, but I'm so close it I think I will delve into this area in the next version and handle dupes and comments better. Yeah, "Master FreeBSD and OpenBSD Security" is an old but awesome book, currently on my Desk. I am surprised by how sparse the pf chapter is, but it's still great.
 
Apart from an abominable proposed licence entirely outside both letter and spirit of the 2-clause BSD licence, I look forward to seeing some evaluation of this selection of settings by members of our security team, past and present.
 
Wravoc said:
Kai Burghardt said:
[…] It seems you are replicating functionality. How is your script addressing a need that has not been addressed otherwise?​
Click to expand...
[…] I'm not replicating functionality, I'm replicating results, there is a difference. […]
Click to expand...
Let me restate my question. When you write a piece of software, you first identify a problem some users experience. Today, I can use an editor(1) to edit (rc|sysctl|loader|login).conf. Then I issue the appropriate command so the changes take effect, e. g. reboot(8) for settings that can only be altered during boottime. Frankly, I am pretty happy with this process. 😎

Any extra piece of software needs to show its raison d’être. The extra time and effort spent on familiarizing with your software must outweigh the steps required for the status quo procedure. I see you introduce a new configuration file settings.ini (for the harden-freebsd.py script). This introduces “complexity”; any additional complexity needs good justification. Why is it “good” (preferably better) to store for instance this piece of information kern.securelevel=1 in settings.ini as well as sysctl.conf (once harden-freebsd.py has been run)? What have I gained from that, that would have been “difficult” to achieve today?
 
Wravoc said:
FreeBSD and RedHat shoulda had Government protection from being Corporatized.
Click to expand...
The FreeBSD Foundation is a corporation, albeit a non-profit organization/corporation. Maybe you mean like Suzy Linux, or something about Microsoft claiming to buy all rights, because they bought one branch of Linux.

My understanding is that BSD licenses are safe from being taken over, while anyone can use it for profit. There's an amount of allowing profit that we have to tolerate or accept with a free license, for me, as long as the software remains free for users. I think of when a piece of BSD code gets incorporated into a GPL license, that the original BSD code is always permissive, so long as the repository is preserved. The part of it that's GPL'd permanently is only so when used in conjunction with that GPL code, so it's like a snapshot which includes that GPL code or even proprietary code, while the same BSD licensed port is still used with other software, which that snapshot isn't under those more restrictive licenses, depending on the licenses they're used with. The word viral license alarms me, and I still don't understand the extent which it covers.

If you want code that's protected for sure, then Mozilla Public License (MPL2.0) or perhaps other licenses based on CDDL. It has a patent clause to prevent patent trolling. It can be used with anything which allows it, and the files have a clear separation from code under other licenses. However, it won't do anything about using the code. It will do good to protect the code, when some are unsure about the full extent of permissive licenses. It's not viral, so doesn't affect permissively licensed licenses outside of its directory. It can't be used with GPL, but that's kind of a good safety net and separation. MPL2.0 might be usable with LGPL, though, I'm not sure exactly how. MPL forces people to give up improvements to those files, however, software contributed outside of those files don't have to be given up, thus other ports retain their license.

Restricting execution would be harder, and perhaps not worth it. Keeping the code free, keeping clear separations and preventing patent trolling goes a long way. Then again, LGPL isn't nearly as viral as GPL, and it prevents commercial profiting off of it, but LGPL can be turned into GPL in a one way street. Creators of GPL can profit off of their own code, while others can't. We actually haven't seen something like MPL, but which prevents commercial profiting like LGPL and is incompatible with GPL.

I kind of understand your thinking, of lining things up for a type of complexity on thoughts. Some of it is excessive. It doesn't need to be that complicated.

LGPL or MPL2.0 might be the ones to use for your project. Something between those two licenses may be what you're looking for, but one doesn't exist. As long as you keep a repository of the LGPL code, it will always have that LGPL fork available, regardless of a copy being incorporated into a GPL licensed project. Though permissive licenses also have this same way of function. And at least these are compatible with a large software library of GPL code.

Thread daemon-license-an-anti-viral-license.66640

Come to think of it, just slap LGPL2 on it.
 
Perhaps someone has already mentioned it, but setting the default encryption method for user passwords to blowfish is less secure than using SHA256 or SHA512. The tutorials you probably referenced (as I have too) are outdated. The best system has an immutable filesystem, offers nothing extra (binaries) and is ready to use. From my experience, the best way to reproduce this is through a jail that has its filesystem ready to build your custom world and such. Once you have an immutable filesystem you can keep track of it with mtree.
 
alexseitsinger said:
Perhaps someone has already mentioned it, but setting the default encryption method for user passwords to blowfish is less secure than using SHA256 or SHA512. The tutorials you probably referenced (as I have too) are outdated. The best system has an immutable filesystem, offers nothing extra (binaries) and is ready to use. From my experience, the best way to reproduce this is through a jail that has its filesystem ready to build your custom world and such. Once you have an immutable filesystem you can keep track of it with mtree.
Click to expand...
You state it like a fact that SHA512 is better but give no reasoning or links. I think most security experts would disagree with you on SHA256 being superior. In fact, I would say Blowfish is still considered more secure than SHA512 by a large segment of the security space.

* https://auth0.com/blog/hashing-in-action-understanding-bcrypt/
* https://security.stackexchange.com/...er-bcrypt-or-pbkdf2-over-sha256-crypt-in-pass
* https://docs.silverstripe.org/en/5/developer_guides/security/secure_coding/
* https://www.gregorygaines.com/blog/...-in-golang-using-sha512-and-why-you-shouldnt/

I would have tested these hypotheses myself to know what I concluded was empirically better but this was not necessary as the official guide says Blowfish is upgraded security. I prefer to be in conformance with the official documentation so that was an easy choice.

As it turns out, it is probably the best choice as well.
 
You must log in or register to reply here.
Back
Top