# Minimal FreeBSD system in a compromised environment



## French Fries (Aug 24, 2017)

Dear friends,

I would like to write a paper about setting-up a hardened FreeBSD administration station.

This is for use in companies or in administration to provide "wide-defense" (in French "défense en profondeur") allowing some time to react.
This setup is not intended to stop any government attack (I don't think this is possible), only casual hacks:

The admin station is a small laptop (ex: 200€ laptop) with network disabled, wireless/bluetooth removed. The admin station communicates with gateway using serial console. It boots encrypted.

The admin "gateway" is a small beaglebone black station connecting using serial. One serial "in" and one serial "out". I have such a cape for Beaglebone. The gateway boots on readonly CD to minimize the risk of infection.
I would like to avoid any "zero-day" flaw that would comprimise my admin station from the moment I am connecting to a compromised network.

I was thinking of :
* install FreeBSD 11.1 minimal.
* drop any incoming connection (pf), filter outcoming connection (pf), shutdown/uninstall any service.
* setting-up a user account with access to cu and ssh-client only. This accound should be locked-up.
* jail into this account.
* user smartcard to store SSH keys and various certs (will be using OpenSC) to avoid keyloggers and other goodies.
* connect only to network when needed for admin purpose, then shutdown.

I don't need to copy infected material on my laptop (which would make things way more complicated).

Any idea or paper appreciated.

Kind regards,
French Fries


----------



## SirDice (Aug 24, 2017)

French Fries said:


> I would like to avoid any "zero-day" flaw that would comprimise my admin station from the moment I am connecting to a compromised network.


Note that an encrypted filesystem isn't going to protect you (a common misconception). The only thing an encrypted filesystem does is protect the data in case the disk (or the entire machine) gets stolen. It's not going to prevent exploit payloads from accessing the data when the machine is up and running.


----------



## ekingston (Aug 24, 2017)

If I knew the environment was compromised, my investigation set-up would boot to read-only. Somewhat like the recovery DVDs/CDs. If you are using the system as your daily admin workstation, how do you know it wasn't compromised too?

Locking down a system does not eliminate the chance of a compromise, it only reduces it and/or slows down the attacker as he/she hunts for a way to get in.

If you are really concerned about compromises, you should be thinking of what you should have in-place to reduce the impact of the compromise after it happens, not just what you do to stop the initial attempts.

* Locking down inbound connections (pf) is a start, but locking down outbound connections should also be included.
* Jails add protection for the base operating system as an attacker still has to break out of the jail to get at the host but read-only filesystems and mandatory access controls protect the host OS even if someone gets a foot-hold. Have a look at TrustedBSD and mandatory access controls.
* Network monitoring, remote log storage and automated security analysis of those logs is a good idea too. If your host is compromised, you can't be sure the logs weren't altered. If you are trying to figure out how a compromise happened, you need logs that you can trust.
* File integrity monitoring should also be included, you want to know if someone manages to change a binary without your knowledge. You also want to know if something gets added to /bin (and friends).


----------



## French Fries (Aug 24, 2017)

Yes, thanks for those information.
Daily security is a complete process.

Yet, I am enquiring about a secure administration station.
The typical usage is once you arrive in a company and don't know where to start.

Booting on a live CV is a nice idea.
I added your idea to the draft.


----------



## ShelLuser (Aug 24, 2017)

French Fries said:


> I would like to avoid any "zero-day" flaw that would comprimise my admin station from the moment I am connecting to a compromised network.


Why do you assume it would even try to compromise your box?



French Fries said:


> I was thinking of :
> * install FreeBSD 11.1 minimal.
> * encrypted root.
> * drop any incoming connection (pf), shutdown/uninstall any service.
> ...


Security starts with a thorough understanding of your tools and environment. And no offense intended, but you make a lot of mistakes and assumptions.

First of all the obvious: "compromised network" can basically mean anything. If we're talking about the recent (Windows based) ransomware virusses then that would require a different approach than if we we're merely talking about a PC which got infected with a rootkit. So: forget about a "one size fits all" solution, that will definitely fail.

A minimal / vanilla FreeBSD installation already severely limited the amount of actively listening daemons. You probably don't need a firewall at all. That is... not to block any incoming connections.

In fact you _don't_ want to drop incoming connections. You want to log them instead, this way you'll be fully aware that something is actually trying to connect. As said: there's no risk if nothing is listening to said ports in the first place.

As to user smartcards, jails and all that... I think you're throwing out buzzwords and/or heavily over complicating things. I seriously fail to see the need there.


----------



## French Fries (Aug 24, 2017)

I will try to use Capsicum:
http://www.trustedbsd.org/2010usenix-security-capsicum-website.pdf


----------



## vermaden (Aug 24, 2017)

French Fries said:


> Dear friends,
> 
> I would like to write a paper about setting-up a hardened FreeBSD administration station.



Start with HardenedBSD (FreeBSD fork) or with OpenBSD if it must be 'ultra' secure.


----------



## French Fries (Aug 24, 2017)

I heard about HardenBSD, as it is used in OPNsense.

Is OpenBSD be more secure?
https://www.openbsd.org/security.html

OpenBSD pledge?





As a newbe, I am interested to know ...


----------



## French Fries (Aug 24, 2017)

ShelLuser said:


> Why do you assume it would even try to compromise your box?
> As to user smartcards, jails and all that... I think you're throwing out buzzwords and/or heavily over complicating things. I seriously fail to see the need there.



Smartcards is for storing SSH private key.
It has an external keyboard to enter the PIN code.
Will publish a photo tomorrow.

OpenSC is the framework used to query smartcards:
https://github.com/OpenSC/OpenSC


And https://github.com/ANSSI-FR/SmartPGP
is a nice effort to bring an opensource smarcard.


----------



## ShelLuser (Aug 24, 2017)

French Fries said:


> Smartcards is for storing SSH private key.
> It has an external keyboard to enter the PIN code.


I know what it is and does, but within this context there's absolutely no point in utilizing it. It won't improve security at all.


----------



## French Fries (Aug 24, 2017)

Is Theo de Raadt right when he states that OpenBSD is much more secure than FreeBSD? Seems outdated, no? Coming from Linux, I "thought" Linux was secure ...


----------



## French Fries (Aug 24, 2017)

ShelLuser said:


> I know what it is and does, but within this context there's absolutely no point in utilizing it. It won't improve security at all.



No, as an admin, I want to protect my SSH secret keys. Contact smartcards are good at keeping secrets. Also, as you cannot access the secret key, you are less prone to making an error and leaking a key.

If ANSSI made their own OpenPGP smartcard, it is probably for their own use and because it is absolutely needed.

A good smartcard reader with keyboard and ANSSI OpenPGP is probably the most valuable part of a good administration system.


----------



## Deleted member 30996 (Aug 25, 2017)

I have FreeBSD and OpenBSD laptops.

There are hardening measures newly available in FreeBSD 11 during the build process. Others are available, but the ones I use (including some I set myself) are:


```
Disable reading kernel message buffer for unprivledged users
Disable process dubugging facilities for unprivledged users
Ramndomize the PID for newly created processes
Insert stack guard page ahead of the growable segments
```
I'm not sure if the last one qualifies as the stack protections he speaks of as FreeBSD lacking, or what other measures, if any, have been taken by FreeBSD since that video was made in 2013.

If you disable reading kernel message buffer for unprivledged users you can no longer run dmesg as usr and must log in as root.


----------



## SirDice (Aug 25, 2017)

French Fries said:


> Is Theo de Raadt right when he states that OpenBSD is much more secure than FreeBSD? Seems outdated, no? Coming from Linux, I "thought" Linux was secure


They're all secure, they wouldn't be of much use if that wasn't the case. The thing that sets OpenBSD apart is the fact they took the original code and took a couple of years to thoroughly take it apart and audit it. Anything and everything that even remotely looked like it could be abused got taken out and/or rewritten. The goal of OpenBSD is to use the most secure programming techniques possible, usually sacrificing performance in favor of stricter code.


----------



## French Fries (Aug 25, 2017)

Coming from GNU/Linux, there is some learning curver before I can make up my own mind.

IMHO speed is nothing compared to security. So when you write "sacrificing performance in favor of stricter code", I prefer stricter code, otherwize I would still be using Linux. Do you really think one would prefer to get hacked because FreeBSD is "faster".

If 200 applications have been ported to OpenBSD Pledge, it could be a real advantage in favor of OpenBSD. This cannot be audited as easily as Pledge is only on OpenBSD. The process of purifying code is very well explained by Theo de Raadt.

OpenBSD did a very good job around random number generators, How can it be all ported to FreeBSD? Also, I am using some ARM Beaglebone, I wonder how this is secure. hardenedBSD is only available for x32/x64.

Wait and see ... I will be learning more about BSD on this project. Then I can use a combination of both FreeBSD/OpenBSD. Today I stick to FreeBSD.


----------



## SirDice (Aug 25, 2017)

French Fries said:


> IMHO speed is nothing compared to security. So when you write "sacrificing performance in favor of stricter code", I prefer stricter code, otherwize I would still be using Linux. Do you really think one would prefer to get hacked because FreeBSD is "faster".


This is too extreme. It's more like a different approach. 



French Fries said:


> OpenBSD did a very good job around random number generators, How can it be all ported to FreeBSD?


Probably already done. There's a lot of "cross pollination" between the three major BSDs.


----------



## vermaden (Aug 25, 2017)

This page makes me uncomfortable with FreeBSD security:
https://hardenedbsd.org/content/easy-feature-comparison

Also FreeBSD uses OpenSSL in base while OpenBSD and HardenedBSD both use LibreSSL.


----------



## ekingston (Aug 25, 2017)

French Fries said:


> Is Theo de Raadt right when he states that OpenBSD is much more secure than FreeBSD? Seems outdated, no? Coming from Linux, I "thought" Linux was secure ...



Google claims that Chrome OS (on the chrome books) is more secure than Windows. But, if you care about privacy, Microsoft doesn't take all the data on your Windows based laptop and scan it for context to send ads to you. Microsoft only takes data about your hardware and the software you have installed, but unless you choose to use OneDrive, they don't have any of your data files.

Point being, "more secure" is not well defined.

The OpenBSD team does more to review the code for security issues before it is accepted into the core and considers the security consequences as a priority over just about everything else when planning their framework. Does that actually make it more "secure"? Can't really say.

Whether it is FreeBSD, OpenBSD, or any of the Linux distros, we also run into the fact that everyone installs additional software to actually use their computer. Software that isn't part of the core operating system. That introduces the potential for additional security issues. It's unavoidable.


----------



## French Fries (Aug 25, 2017)

Thank you for your comments.

vermaden.
I read this too. This comparasion chart has a lot to do with compilation.
I read that a lot was being done on productible build for FreeBSD to build a continuous compilation framework (or make it better).
When it is done, plans are to make different compilations.
I guess this is how it is planned.

ekingston
Yes, this is why I am heading towards a minimal administration station.

Besides, I am pumping on GPIO settings here:
https://forums.freebsd.org/threads/62178/


----------



## French Fries (Aug 25, 2017)

Fixed.


----------



## Deleted member 30996 (Aug 25, 2017)

vermaden said:


> This page makes me uncomfortable with FreeBSD security:
> https://hardenedbsd.org/content/easy-feature-comparison
> 
> Also FreeBSD uses OpenSSL in base while OpenBSD and HardenedBSD both use LibreSSL.



I have one more spare HDD T61/X61. Looks like time I tried HardenedBSD.


----------



## SirDice (Aug 25, 2017)

vermaden said:


> Also FreeBSD uses OpenSSL in base while OpenBSD and HardenedBSD both use LibreSSL.


Wasn't there some discussion about replacing the base OpenSSL with LibreSSL? I though this was already started in -CURRENT but looking at the latest SVN tree it looks like it's still using OpenSSL.

Oh, note that even the most secure OS in the world isn't going to protect you if you accidentally run malware yourself. The most common infection vector is between the keyboard and chair.


----------

