# How do I take full ownership of my FreeBSD installation?



## Toolforger (May 20, 2020)

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!


----------



## Phishfry (May 20, 2020)

Toolforger said:


> How do I find out what services are active in my fresh FreeBSD install?


`service -e`



Toolforger said:


> How do I find out which ones are present but inactive?


`service -l`



Toolforger said:


> 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`

```
# cron : Daemon to execute scheduled commands
#
cron_enable="NO"
#   (default: "")
```


----------



## msplsh (May 20, 2020)

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.


----------



## gpw928 (May 21, 2020)

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:
	
	



```
[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

```
: ${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.


----------



## Toolforger (May 21, 2020)

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?


----------



## George (May 21, 2020)

For userland, just run `top`


----------



## a6h (May 21, 2020)

Toolforger said:


> Stuff like packet filters


To list all the running rules:
`ipfw list`

All logged packets messages:
/var/log/security



Toolforger said:


> 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:

```
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)

```
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!)

```
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!)

```
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

```
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:

```
/bin/sh
/bin/csh
/bin/tcsh
```


----------



## kpedersen (May 21, 2020)

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.


----------



## 20-100-2fe (May 21, 2020)

Toolforger said:


> 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.


----------



## Toolforger (May 21, 2020)

20-100-2fe said:


> 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.


----------



## 20-100-2fe (May 21, 2020)

It was not my intent to criticize you (it was rather a "been there, here's what's likely to happen next"), but that's the problem with forums and mailing lists, you lose the intonation and other non-verbal elements present in face-to-face conversations.



Toolforger said:


> I will still get criticized for them


----------



## gpw928 (May 22, 2020)

kpedersen said:


> 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).


----------



## Lamia (May 23, 2020)

vigole said:


> 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.


----------



## ralphbsz (May 23, 2020)

gpw928 said:


> ...
> 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.



Lamia said:


> 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.


----------



## Hakaba (May 23, 2020)

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.


----------



## Jose (May 23, 2020)

Agreed. Especially Phishfry's post. I dun learned things.


----------



## a6h (May 23, 2020)

Lamia said:


> 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`

```
If you use a non-default ssh port, specify it in ~/.ssh/config.
```


----------



## ralphbsz (May 23, 2020)

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.


----------



## kpedersen (May 23, 2020)

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.



ralphbsz said:


> 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.


----------



## Jose (May 23, 2020)

I'm not a big fan of the use-random-ports approach to securing services. It smacks of security by obscurity.


----------



## msplsh (May 23, 2020)

Jose said:


> It smacks of security by obscurity.



Shodan will eventually find it.  Don't bother changing the ports, you're just making it harder on yourself.


----------



## Toolforger (May 23, 2020)

I do it even more obscurely: sshd isn't even listening. It's not there


----------



## kpedersen (May 23, 2020)

Toolforger said:


> I do it even more obscurely: sshd isn't even listening. It's not there



Fair enough. Hopefully it hasn't been replaced with rsh or telnet


----------



## Toolforger (May 27, 2020)

sshd is replaced with a physical console


----------



## Toolforger (May 27, 2020)

Hakaba said:


> 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.)


----------



## SirDice (May 28, 2020)

Toolforger said:


> I want to know the weakest links


Just to get back to this. Your biggest threat is you and anyone else that uses the system. Even the most secure system in the world isn't going to protect you if you run something stupid.


----------



## gpw928 (May 29, 2020)

I think that disabling ssh might make your system less secure, because you will require routine access (from secure networks) for patching and general administration if you want to keep your system secure.

By all means disable PermitRootLogin, and PasswordAuthentication.

Otherwise it's difficult to offer generic advice without knowing the attack surfaces.  e.g. putting a competent firewall between your host an the Internet makes some difference...

For a generic high level approach, there's a lot of prior art curated by various cyber security organisations.

e.g. when I was working full time, the ASD Essential Eight for Linux was mandatory, and audited.  You can see it's written for Windows and adapted to Linux/Unix, but many of the ideas are relevant to FreeBSD.

And I agree with SirDice.  A competent backup system is your best insurance, by far.


----------



## msplsh (May 29, 2020)

If he's only logging in at the console, then it doesn't matter if sshd is disabled.


----------



## Toolforger (May 30, 2020)

gpw928 said:


> A competent backup system is your best insurance, by far.



Actually I am trying to build that competent backup system 
(Project blurb: "Panicroom: A citadel for your data" - "citadel" in the sense of "the building to retreat to when under attack", maybe there's a better word?)


----------



## gpw928 (May 31, 2020)

This thread on the subject of backups may be of interest.


----------



## Mjölnir (May 31, 2020)

Toolforger said:


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


install the freebsd-doc (english + your native language) and get through it.  It's of the finest you can find among OS user/admin docs.
`$ su -
# pkg search freebsd-doc
# pkg install {en,it}-freebsd-doc`
_You may want to transfer or download the PDF or HTML docs to your graphical desktop computer. _


Toolforger said:


> How do I identify all the rc.conf settings that pertain to a service?


_Replace "ipfw" with the service name you get from  service -l_
`$ service ipfw rcvar`
Unfortunately, very few service scripts support this, so you have to read the service scripts.  They are in /etc/rc.d and /usr/local/etc/rc.d.  Luckily, the relevant settings are at the top of the scripts (mostly, not always).  The default settings are in /etc/defaults/rc.conf.  Besides that, many services grab additional settings from their own configurations files, mostly found under /etc and /usr/local/etc


Toolforger said:


> How do I make sure I didn't overlook an important rc.conf setting (or other setting)?


It's hard to give an honest answer... Be curious but patient and start to learn.  It's worth it, be ashured you have solid system.


Toolforger said:


> I do assume that FreeBSD is pretty secure by default.


Hmm.  Yes and no...
At least go through `# bsdconfig` and set the single user console to ask for a password (that edits /etc/ttys)
Last not least, you need to have a system manufactured before 2008  because todays consumer devices are like mainframe systems twenty years ago.  If you want to be absolutely safe -- well, don't use any computer at all.


----------

