How do I take full ownership of my FreeBSD installation?

Hi all,

I'm struggling with getting an overview of all the services installed, and what configuration I have to check.

How do I find out what services are active in my fresh FreeBSD install?
How do I find out which ones are present but inactive?
How do I identify all the rc.conf settings that pertain to a service?
How do I make sure I didn't overlook an important rc.conf setting (or other setting)?
(Substitute "feature" for "service" as appropriate.)

Background: I want to set up a FreeBSD box that's secure. It is going to run a pretty minimal install (otherwise I wouldn't bother trying to understand it all), and I want to know the weakest links so I know what to strengthen first, or where to look first in a post-mortem investigation.

I do assume that FreeBSD is pretty secure by default.
I just want to be slightly smarter than "just assume it's safe", because "just assume" and "secure" Just Don't Mix.

If possible, I'd prefer a strategy to use over a plain list of things to check, which would become less useful as FreeBSD evolves.
Though a plain list is better than nothing at all, so if there's no good strategy that a FreeBSD newb like myself can just follow, feel free to collect list items anyway !

Any insights appreciated!
 
How do I find out what services are active in my fresh FreeBSD install?
service -e

How do I find out which ones are present but inactive?
service -l

How do I identify all the rc.conf settings that pertain to a service?
You can read the scripts. /etc/rc.d/ and /usr/local/etc/rc.d
Also service(8) has a switch for that. Here is cron for example.
service cron rcvar
Code:
# cron : Daemon to execute scheduled commands
#
cron_enable="NO"
#   (default: "")
 
When you wrote "How do I take ownership" I was thinking "Make sure you get root's email", but it looks like your actual question is covered.
 
If you are interested in first principles, there's a few more jelly beans in the trail.

To investigate beyond what's enabled, you may see all the options, which may be over-ridden in /etc/rc.conf, and their default values, in /etc/defaults/rc.conf:
Code:
[ritz.157] $ grep sshd_ /etc/defaults/rc.conf
sshd_enable="NO"        # Enable sshd
sshd_program="/usr/sbin/sshd"    # path to sshd, if you want a different one.
sshd_flags=""            # Additional flags for sshd.
And occasionally there are undocumented options, such as those found in /etc/rc.d/sshd
Code:
: ${sshd_rsa1_enable:="no"}
: ${sshd_rsa_enable:="yes"}
: ${sshd_dsa_enable:="no"}
: ${sshd_ecdsa_enable:="yes"}
: ${sshd_ed25519_enable:="yes"}
Lastly, if you can't find what you expect in /etc, don't forget to look in /usr/local/etc.
 
Ah pity, I wrote "service" and should have said "feature".
Stuff like packet filters aren't in services, right?
Are there other kernel features I should be careful about?
 
Stuff like packet filters
To list all the running rules:
ipfw list

All logged packets messages:
/var/log/security

kernel features
List of loaded modules:
kldstat

List of all installed packages by you:
pkg prime-list

Disable toor account:
chsh -s /usr/sbin/nologin toor

Enable process accounting:
Code:
touch /var/account/acct
chmod 600 /var/account/acct
accton /var/account/acct
sysrc accounting_enable=yes
sa

Secure /etc/ssh/sshd_config (change the default port i.e. 22 to smoething else, e.g. 2222)
Code:
Port 2222
PermitEmptyPasswords no

Mark the console as insecure in the /etc/ttys
(I think it is the default behaviour in recent versions of FreeBSD, I'm not sure!)
Code:
console none unknown off insecure

Change file permission of some of the files such as ipfw.rules and wpa_supplicant.conf to something more secure (If it is not!)
Code:
chmod 0500 /etc/ipfw.rules
chmod 0500 /etc/wpa_supplicant.conf

Add a few setting to the sysctl.conf
(Some of the following changes maybe overkill, or cause some problems in your system. Search them in the mailing list and forums.)
/etc/sysctl.conf
Code:
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.see_jail_proc=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
security.bsd.stack_guard_page=1
kern.randompid=1

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.drop_redirect=1
net.inet.ip.redirect=0
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
net.inet.icmp.bmcastecho=0

To preserve file permissions, use net/rsync to copy files, (whenever possible/applicable)

Don't mess with /root folder. Do all of your tasks, with Normal User as much as possible.
Don't change the default shell of root account. Use one of those in which by default available in /bin folder:
Code:
/bin/sh
/bin/csh
/bin/tcsh
 
If your machine is not listening on any ports, even if you have no firewall, it is impossible for an intruder to break in.

So it is sometimes useful to be able to find this information via sockstat: https://www.cyberciti.biz/tips/freebsd-lists-open-internet-unix-domain-sockets.html

I tend to close all ports apart from 22 (sshd).

Then the only way you can really be compromised is running buggy client software (like web browsers). Thats not really an intruder breaking in, more like you letting them in.
 
Ah pity, I wrote "service" and should have said "feature".

This semantic shift show you're looking for a solution to a problem that is not well defined. You will end up with a huge list of solutions from which you'll be unable to choose due to your imprecise problem definition.

A simple example, why do you include packet filtering in your list and not the HTTP or CIFS or database servers? Their configuration can also put your at risk, not only the fact they are running.

You should feel "fully owning" your system in the first place because you're the one who installed it, so you know what's inside and why it's there, so the correct question is probably not "How do I know what's running on my computer?".

If your concern is security, why not run an audit tool such as Lynis as a first step?
Applying all current best practices is a good starting point and you'll learn a lot doing this, including learning what you should keep learning about. ;)
 
This semantic shift

No semantic shift. I had "services and features", thought it would be silly to repeat that everytime I wrote it, removed the "features" and wanted to explain the scope in the first paragraph, had something else to correct before posting, and forgot about it.
Too much second-guessing on your side it seems to me ;-)

show you're looking for a solution to a problem that is not well defined.

Actually I have a pretty exactly defined problem: "what would be a strategy to find all the attack surfaces I may be exposing?"
I tried questions in that direction, and got told that the scope is too broad.
Now I try something more focused, and I get a "the question is too vague"... it's frustrating.

Maybe I should just shoot off questions without thinking about them. I will still get criticized for them, but if I can't avoid that, why spend the time on trying to improve my questions?
(Just kidding, and venting some minor frustration here...)

You will end up with a huge list of solutions from which you'll be unable to choose due to your imprecise problem definition.

In that case I'll just try a more precise question.

A simple example, why do you include packet filtering in your list and not the HTTP or CIFS or database servers? Their configuration can also put your at risk, not only the fact they are running.

Because it was an example for things that the kernel is doing.
By no means was that meant as an exhaustive list. A one-item "list" isn't a list anyway.

You should feel "fully owning" your system in the first place because you're the one who installed it, so you know what's inside and why it's there, so the correct question is probably not "How do I know what's running on my computer?".

Well, I can't do security unless I know what's running - so I tend to disagree here.

If your concern is security, why not run an audit tool such as Lynis as a first step?
Applying all current best practices is a good starting point and you'll learn a lot doing this, including learning what you should keep learning about. ;)

Yeah, the latter is what I'm trying to do.

Lynis sounds like something I should investigate.
Which the one point we should concentrate on, I believe.
 
I tend to close all ports apart from 22 (sshd).
That's good advice.
My Internet connection is cellular mobile, so I pay for all inbound traffic, as well as all outbound traffic, and my monthly allowance is both modest and expensive.
There were lots of script kiddies trying to crash in through port 22, and I was paying for all their break-in attempts. Reading the logs was amusing.
I thought about the possible defences, including port knocking, but in the end all that was needed was to move sshd to listen at a more obscure location.
When the attackers found nothing listening in the privileged port range, they (or rather the scripts they were using) gave up.
So there is some virtue in "security through obscurity" (but you should still turn off password authentication and use a sound key).
 
Secure /etc/ssh/sshd_config (change the default port i.e. 22 to smoething else, e.g. 2222)
The problem with this recommendation is that some services are bound to 22. Changing the port no stops them. Example zfs data sync between two PCs with ZAP.
 
...
When the attackers found nothing listening in the privileged port range, they (or rather the scripts they were using) gave up.
So there is some virtue in "security through obscurity"...
Same experience here. I have two ports open on the internet-facing side, one ssh, one https. Obviously, not on port numbers 22 and 443, but random-looking large numbers. Usually, I change the port numbers every few months, but now that I think of that, I've forgotten to do that for maybe a year now. I never find attacks in my log. Non, zip, zilch. While it is not "security through obscurity" (since it does not give real security, a determined attacker would be able to get to them), it reduces the attack frequency to the point where monitoring unsuccessful attacks becomes irrelevant.

The problem with this recommendation is that some services are bound to 22. Changing the port no stops them. Example zfs data sync between two PCs with ZAP.
Yes, and all of them need to be changed and configured. For example, I always have to remember the syntax for giving the port number to scp, rsync, and so on. It's a bit of a pain, but still worth it.
 
The problem with this recommendation is that some services are bound to 22. Changing the port no stops them. Example zfs data sync between two PCs with ZAP
What problem? Stop whom?
man zap
Code:
If you use a non-default ssh port, specify it in ~/.ssh/config.
 
Oh, I just saw something else: Don't use ports 2222 for ssh, nor port 8080 for http(s). That's been done. Think of a more innovative number.

One of my favorite jokes: My password is the last 8 digits of pi.
 
Good point. I used to make my sshd listen on a non-standard port but it started getting annoying for CVS. CVS_RSH variable allows you to set ssh as the program but doesn't allow specifying flags (like -p 2999). This meant I needed a ssh_config file for each host I developed from or a wrapper script to do the same. I got a bit lazy. ;)
Plus root logins have been disabled and opportunistic scanning and password guessing only ever seems to try root as the username.

One of my favorite jokes: My password is the last 8 digits of pi.

I like it. ;) Mine is the all the other digits apart from the last 8 and I send it through 2Rot13 first.
 
Maybe this post can be rewritted in a real «HOW TO» in the appropriate part on this forum ?

The exercice force you to arrange all answers with point of view.

I'm already documenting all decisionmaking in my Panicroom project, so I'm covering that one perspective.
Please feel free to do a general-purpose Security HOWTO! I can't do it (far too little experience), and I am already too sidetracked to pick up yet another project, but I'd really like to see that happen. (Or maybe it already exists? I don't know.)
 
Back
Top