Hardening FreeBSD

[cajunman4life]

I'd like to start a lively discussion on the methods and procedures everyone uses to "harden" their FreeBSD systems.

Anyone?

[edhunter]

On pure os level, actually I do almost nothing on hardening my freebsd machines :)
I just keep number of users to minimum, also number of servers (daemons) to minimum too. On some machines I change the ssh port because of bots trying to login with different user/passwords on 22 port.
I have rerouted all machines email logs to one account and I quick check this email daily.

I dont say this is right, this is how it works for me.
Yes one my machine once were hacked and our web were deleted, but this has nothing to do with freebsd itself. It was poor php script on our web.

[corey_james]

argh @ php ... let's not start a discussion on that haha

I don't really do much to freebsd ... if you really want to go into hardening a freebsd have a look at the OS security levels and perhaps changing the default md5 hashing in master.passwd to blowfish encryption.

Definitely reduce the amount of daemons that run on the machine and if you really want, change the default SSH port ( as edhunter suggets )

[horizon]

I tend to chmod 4750 any setuid root binaries so that only people in wheel can execute them. Could help prevent a local privilege escalation if someone manages to obtain uid nobody via Apache or some other service, or you just have untrusted users on your system.

I also chmod 700 all home directories to prevent users snooping through each others files -- the amount of times I've come across 'passwords.txt'-like files is alarming!

[corey_james]

what's wrong with keeping a password.txt file ? *sniggers*

[anomie]

I'd like to start a lively discussion on the methods and procedures everyone uses to "harden" their FreeBSD systems.

Desktop or server? In either case, depending on how it's being used would determine how many hardening cycles I'd go through.

Pretty straightforward for my desktop:

make sure no daemons are listening for tcp/udp connections (except maybe dhclient);
search for and disable useless (to me) suid/sgid programs;
enable the blackhole(4) sysctl MIBs;
turn off core dumps (more because I don't want to have to look for and delete them);
occasionally run the security/rkhunter app to perform some sanity checking;
believe it or not, scan downloaded files with clamav;
review system logs and emails;
keep base system and ports updated with security fixes asap.


I actually need to run an annoying proprietary java app that listens on all local interfaces to establish a secure connection with a system at work, so keeping in line with point #1 I run a packet filtering firewall to prevent outside connections to it. (Otherwise I probably wouldn't bother with the firewall.)

[cajunman4life]

Me personally (and all I've been setting up lately are servers) I use this as a start:

http://www.bsdguides.org/guides/freebsd/security/harden.php

And go on from there depending on each service that needs to be run. I've also been building ezjails (I like it for its low overhead and read only base system) lately. One for each service I want to run (For example, one is running Apache/OpenSSL/PHP, another is running MySQL, another running PostgreSQL, and yet another running VSFTPd). I find it tends to make each jail easy to secure as there is relatively little installed in each jail.

[stukov]

I like to check the filesystem for changes with tools like TripWire or Yafic. I also like to have a quick look at my logs every morning while drinking coffee.

[keithlybsd]

Lots of good suggestions here,

I am sure this is a lame one but host based firewall is a must. Stateful inspection and make sure to apply out bound rules.

I prefer to only use ssh keys for login and not allow user/pass.

And you can dll the free version of cis bench mark and run that against a system. That little app shows you tons of ways to tighten down a box.

I do these things combined most of the above suggestions.

[18Googol2]

I prefer to only use ssh keys for login and not allow user/pass.


Just so you know you can use ssh key with passphrase :)

The followings configuration I would implement to secure ssh access and I think they are quite elegant:

- VPN

- No direct ssh access from internet. To access the server, all the ssh traffic is tunnelled (the only limitation with my current tunnelling application, hts & htc is it cant accept multiple tunneling connections. Anyone know the alternative one that can do this? :) )

- Port knocking :)

[keithlybsd]

Just so you know you can use ssh key with passphrase :)

The followings configuration I would implement to secure ssh access and I think they are quite elegant:

- VPN

- No direct ssh access from internet. To access the server, all the ssh traffic is tunnelled (the only limitation with my current tunnelling application, hts & htc is it cant accept multiple tunneling connections. Anyone know the alternative one that can do this? :) )

- Port knocking :)


Yes I know, I meant not plain old/user pass logins.

I typically setup agent and then forward the passphrase

[keithlybsd]

sorry not sure what you mean by hts and htc.


So you tunnel the ssh through a VPN?

[18Googol2]

hts & htc is http tunneling server and client application.

You tunnel the ssh traffic with http encapsulated. That means the ssh traffic now looks like normal web traffic, which is very nice because in some place like school and workplace, the only kind of outgoing traffic allowed is web, and the bloody firewall blocks the rest, ssh, pop3, file sharing you name it.

Unless they implement IDS or L7 firewall, you should be able to ssh your home server without any problem :)

[TerryP]

My typical steps are to:

change the headers on each vtty* above the login prompt to some thing less "let's tell the whole world what we are".

change the motd to some thing more strict and create a suitable banner for sshd

ensure proper settings for users and passwords.

create groups/users and set perms as necessary for the system and ensure a sensible setup for what it's there to do.

configure sshd to be a bit more to my 'tastes' then the defaults and change it from port 22 to some thing else.


Kill unnecessary services, I usually don't use inetd either but that's just my way of doing things.


Say hello to pf and continue with system wide adjustments as necessary (e.g. what is this machine for factors).

[keithlybsd]

hts & htc is http tunneling server and client application.

You tunnel the ssh traffic with http encapsulated. That means the ssh traffic now looks like normal web traffic, which is very nice because in some place like school and workplace, the only kind of outgoing traffic allowed is web, and the bloody firewall blocks the rest, ssh, pop3, file sharing you name it.

Unless they implement IDS or L7 firewall, you should be able to ssh your home server without any problem :)

Ahh, ok for me it is usually the other way around. Typically the only outbound protocols allowed is ssh. So I tunnel all kinds of stuff through it. This actually isn't bothered by the IDS, IPS or L7 firewalls. Kinda of the reverse situation that your in.

[lumiwa]

I am a newbie in FreeBSD world. All my life :)) I was OS/2 and Linux user but last three or for months ( am I old??) ion my computer is just FreeBSD 7.0 and I am upset with myself why I didn't install this great system 15 years ago :).
I like to work in console but I like KDE too and I use a computer as a destop machine. What I did for hardening and I hope that is okay:
In the "rc.conf" I have:

syslogd_flags="-ss"
clear_tmp_enable="YES"
log_in_vain="1"
tcp_drop_synfin="YES"
icmp_drop_redirect="YES"
icmp_log_redirect="YES"
ntpdate_enable="YES"
ntpdate_flags="ntp1.cs.wisc.edu"
linux_enable="YES"
pf_enable="YES"
pflog_enable="YES"
update_motd="NO"

Yes, I run openbsd firewall.

In sysctl.conf I wrote:

security.bsd.see_other_uids=0
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1

Maybe there are some changes more but I don't remeber know...

[schrodinger]

My suggestions for hardening (that I can remember without documentation ;) ):

-Disable root login for sshd (should be done by default)
-Change SSHD port to something different and only allow certain users/groups to login to sshd
-If you can't/don't want to change the listening port then setup something like swatch or denyhosts to block any IP addresses attempting to brute force accounts on your box
-Disable any services you do not need (don't use inetd if you don't need to)
-add -ss to disable syslogd binding to a socket
-use secure permissions on log files (don't allow any user who doesn't need to read logs files access to them)
-remove stick bit on set UID/GID binaries
-only allow authorised users to run cron jobs
-change default encryption for passwords to blowfish
-setup PF to block network access to services that remote hosts don't need access to
-add the following to /etc/rc.conf
-+ icmp_drop_redirect="YES"
-+ icmp_log_redirect="YES"
-+ log_in_vain="YES"
-Bring the ARP cache timeout down to five minutes. Append to /etc/sysctl.conf - 'net.link.ether.inet.max_age=300'
-remove toor account
-nosuid options on /tmp in /etc/fstab

[tanked]

I've also been building ezjails (I like it for its low overhead and read only base system) lately. One for each service I want to run (For example, one is running Apache/OpenSSL/PHP, another is running MySQL, another running PostgreSQL, and yet another running VSFTPd). I find it tends to make each jail easy to secure as there is relatively little installed in each jail.

I too use ezjail and would recommend it to anyone running multiple servers; its just so easy to set up plus the added protection of making the userland read-only means anyone breaking into your jail would find it hard to corrupt the binaries. The only thing jails need now is the virtual network stack implementation, maybe it will be MFC'd at some point.

[kazcor]

- /usr ro,nodev, /home nosuid,nodev,noexec, /tmp->/var/tmp
- use of rkhunter, chkrootkit, logcheck
- lock up all services that allow access to the inside in jails (yep, ezjail)
- jails on separate partition(s) or image(s)
- OTPs for all accounts
- disable local console root access
- kernel without module support
- all services on non-standard ports
- chflags schg on all sensitive files, sappend on logs
- afterwards raise securitylevels, if you care
- provide a VPN for access to your server, regardless of LAN/WLAN

Even more paranoid :p

- disable .history for all shells
- don't cache passwords to LAN services (HTTP/SMTP/etc.)
- use tor (at least for DNS queries)
- use privoxy for filtering (in a jail, of course)
- if using firefox from inside use NoScript where possible

Want more?
- provide a UPS for your machine
- provide a webcam with motion recognition and shutdown timer (harddisk encrypted, of course)
- close windows and draw the curtains, before touching a keyboard
- <add your favourite option here>

[starbuck]

- chflags schg on all sensitive files, sappend on logs


Does flagging the logs as "sappend" prevent them from being rotated? How do you get around this?

I noticed no one mentioned using various "Secure Levels." Is there anyone here running their FreeBSD system at Secure Level 2 or 3?

[anomie]

Does flagging the logs as "sappend" prevent them from being rotated? How do you get around this?

Yes, it does. You could remove the flag, then rotate the logs, then re-add the flag. But then that would imply that you're running in a securelevel < 1 (which somewhat defeats the purpose of the file flag if root can just remove it ;)).

So the real answer is that your log file will be growing indefinitely (until you take the steps to temporarily get to a lower securelevel and manually rotate it).

If you haven't already, check out the manpages for security(7) and chflags(1). There is a good book I reviewed here (http://daemonforums.org/showthread.php?t=56) that discusses this topic in great detail.

[cajunman4life]

Yes, using sappend will prevent your logs from being rotated. As for a work-around... I don't know. One must mull the good vs the bad... Having your logs grow to an incredible size (for a medium to heavy load server) but being better poised to "stumble upon" someone evil, or having nice small compressed logs (but potentially not catching the evil person).

As far as secure levels, it's only something I'm beginning to look into. I hope someone else comes along and sheds some more light on this subject...

[coppermine]

Quite vast topic. It's better to define some more pronounced direction for discussion, but the presence of this thread is good by itself.

My strategies are:
1) really strong passwords. At least 10 chars with big and small letters + numbers. Any user who actively refuses to obey this, is excluded being possible to login from outside
2) read or at least quickly skim the logs every day
3) before installing any service, I make sure that I really need this. It is worth to put services in DMZs if you have enough free boxes. Good network design to say...
4) frequently make and check the checksums with aide.
5) use sshguard to get rid of ssh login attempts
6) setup firewall with tested enough ruleset
7) whenever I see portaudit complaining about installed package security - I take the time to install it
8) if there are FreeBSD vulnerabilities published - I devote more time and inform the users about planned works.
9) and... the more important changes I am planning to do, I devote even more time to prepare and explore the consequences
10) finally, I use the handwritten journal about any more or less changes done to boxes either in hardware or in software world. It may be boring, but this book-keeping saved me more time in troubleshooting afterwards.

[cajunman4life]

Quite vast topic. It's better to define some more pronounced direction for discussion, but the presence of this thread is good by itself.

My strategies are:
1) really strong passwords. At least 10 chars with big and small letters + numbers. Any user who actively refuses to obey this, is excluded being possible to login from outside
2) read or at least quickly skim the logs every day
3) before installing any service, I make sure that I really need this. It is worth to put services in DMZs if you have enough free boxes. Good network design to say...
4) frequently make and check the checksums with aide.
5) use sshguard to get rid of ssh login attempts
6) setup firewall with tested enough ruleset
7) whenever I see portaudit complaining about installed package security - I take the time to install it
8) if there are FreeBSD vulnerabilities published - I devote more time and inform the users about planned works.
9) and... the more important changes I am planning to do, I devote even more time to prepare and explore the consequences
10) finally, I use the handwritten journal about any more or less changes done to boxes either in hardware or in software world. It may be boring, but this book-keeping saved me more time in troubleshooting afterwards.

All very good. As far as a "journal," I've started updating a wiki on the intranet. It may be a bit overkill, but it works.

[anomie]

As far as a "journal," I've started updating a wiki on the intranet.

Me too. I fired up a wiki (dokuwiki) within a FBSD jail on one of my workstations. Nice way to stay organized.

[cajunman4life]

Me too. I fired up a wiki (dokuwiki) within a FBSD jail on one of my workstations. Nice way to stay organized.

Heh, same here... dokuwiki is extremely simple. Extremely nice way to stay organized.

[cajunman4life]

I just thought of something... do any of you do anything to prohibit things like forkbombs and other simple DoS attacks?

Do not try this command unless you fully know what it does:
:(){ :|:& };:

For users with bash as their shell (possibly other shells, too tired to try right now) this is a fork bomb. If your system is improperly set up, running this simple command will bring it crashing down to it's knees. I remember trying this on my Gentoo box a few years ago and nearly crying when it crashed.

Point being, this sort of attack is easily thwarted by setting values in /etc/login.conf for each user class (as appropriate). All users on my box are in the default class (except admins, which have a class called sysadmin and belong to group sysadmin), so I set max processes for default class to 20 (can be adjusted based on how many users, if any, notice the change), and set max memory usage. The default on FreeBSD was unlimited... bad idea for most users.

Also, something else... something so simple that I never really would have thought of until I stumbled across this today: http://www.arbornet.org/~cdalten/grep.html

cat < /dev/zero > /dev/null &

If you run the above command a few times, your system will not be very happy. I don't think this will really "eat resources" like the fork bomb, but the CPU goes to 100% utilization in short order. To counter this effect, set the cputime variable. For my default user class it's 60s (or 1m will have the same effect). For sysadmins it's 1h (a bit more trustworthy group, also one that may have a legitimate reason to be using lots of cpu time), and root is unlimited.

So, how many of you are rushing off to check your /etc/login.conf now? :)

[harisman]

It is a good practice to keep a record about the running processes and the network connections with the ps,sockstat,netstat commands when your system runs at normal conditions.
When something unusual happening, you can compare your findings with those to get an idea.

[coppermine]

Actually, friend of mine tried to prove FreeBSD inability to stand against fork-bombs. I allowed him to run the fork-bomb as a root written by canjuman4life... result - he was disappointed. Even ran as a root, I cleaned offending processes later with not much slowed down machine.
So, the nice variables available at login.conf are very good to start tightening malicious user activities.

[hopla]

1) really strong passwords. At least 10 chars with big and small letters + numbers. Any user who actively refuses to obey this, is excluded being possible to login from outside


I use pam_passwdqc to enforce strong passwords. It's in the base system (man pam_passwdqc).

I enable it by adding this line to /etc/pam.d/sshd (its the 3rd line, the others are already there)

# password
#password sufficient pam_krb5.so no_warn try_first_pass
password requisite pam_passwdqc.so enforce=everyone min=disabled,8,8,8,8
password required pam_unix.so no_warn try_first_pass

See the man page for the meaning of the options and more.

And in /etc/adduser.conf I set

passwdtype=random
upwexpire=0-0-0

Then when I create a new user I get a random password (by default) I can give to him. And when the user first logs in with it, he must immediately change it since its expired (upwexpire). He can then only change it to a password that is strong enough according to the rules set with pam_passwdqc.

[tanked]

I use pam_passwdqc to enforce strong passwords. It's in the base system (man pam_passwdqc).

I enable it by adding this line to /etc/pam.d/sshd (its the 3rd line, the others are already there)



See the man page for the meaning of the options and more.

And in /etc/adduser.conf I set


Then when I create a new user I get a random password (by default) I can give to him. And when the user first logs in with it, he must immediately change it since its expired (upwexpire). He can then only change it to a password that is strong enough according to the rules set with pam_passwdqc.

Excellent, I never realised something like this was in the base system, I thought I'd have to install 3rd party software to get that functionality.

[hopla]

Excellent, I never realised something like this was in the base system, I thought I'd have to install 3rd party software to get that functionality.

Great, my first post here in the new forum and I already got a 'Thanks' :) Glad I could help!

[cajunman4life]

I have enabled the same functionality in the base system, without adding extra configs to sshd.

I've also installed and configured Tripwire. Just another layer in the security onion.

[hopla]

I have enabled the same functionality in the base system, without adding extra configs to sshd.

How have you done that then? By using login.conf settings perhaps? Because I tried those, but never got them to work... The pam_passwdqc also seems more powerfull (not just checking if your password is long enough, but also that it contains X number of different character sets etc)

[cajunman4life]

How have you done that then? By using login.conf settings perhaps? Because I tried those, but never got them to work... The pam_passwdqc also seems more powerfull (not just checking if your password is long enough, but also that it contains X number of different character sets etc)
Comment out everything in /etc/pam.d/passwd, and place the following lines:

password requisite pam_passwdqc.so min=disabled,8,8,8,8 retry=3 enforce=everyone
password required pam_unix.so no_warn try_first_pass nullok

And this will enable this functionality in the system without adding anything to sshd_config. This way, no matter how anyone connects (although SSH is the only method I allow right now but that's not the point) they will be held to these rules.

PS - I was never able to get the settings in login.conf for password strength to work either. I read somewhere that they are silently ignored in favor of pam's configuration, and only exist for backwards compatibility.

[anomie]

This PAM password enforcing information would make for a good forum 'Guide'. :)

[hopla]

And this will enable this functionality in the system without adding anything to sshd_config. This way, no matter how anyone connects (although SSH is the only method I allow right now but that's not the point) they will be held to these rules.

After close inspection (grep -ri pam_passwdqc /etc/pam.d/) it seems that I have that line added to both /etc/pam.d/sshd AND /etc/pam.d/passwd :p
So you're saying I can leave out the line in /etc/pam.d/sshd and everything will be exactly the same for me? Got to try that out next monday :D


PS - I was never able to get the settings in login.conf for password strength to work either. I read somewhere that they are silently ignored in favor of pam's configuration, and only exist for backwards compatibility.

Well, that confirms it for me, thanks!

I agree with anomie on the forum guide, even if it was only to divert this discussion away from this thread :p After my testing on monday, I might just post a guide!

[cajunman4life]

After close inspection (grep -ri pam_passwdqc /etc/pam.d/) it seems that I have that line added to both /etc/pam.d/sshd AND /etc/pam.d/passwd :p
So you're saying I can leave out the line in /etc/pam.d/sshd and everything will be exactly the same for me? Got to try that out next monday :D

You should be able to leave it out of sshd, but now I don't know :) I don't have it in my sshd, and password enforcing still works... but I don't know how it would be affected by having it (or not). Interesting...

Well, that confirms it for me, thanks!

I agree with anomie on the forum guide, even if it was only to divert this discussion away from this thread :p After my testing on monday, I might just post a guide!

Yea, the login.conf thing annoyed me for several days while I tried to figure out why it wasn't working, then I stumbled upon an article somewhere (I wish I saved the link) that explained why it didn't work and what to do to enforce password strength. All was well again.

As to the guide - it'll be a welcome addition :)

[anomie]

@hopla & @cajunman4life,

This <profane adjective> rocks! I've been researching / testing this for the last hour or so. I love discovering something new in FreeBSD (or Linux) land. I can hardly wait to unleash this upon my users once I'm comfortable with it.

Looking forward to the guide...

[cajunman4life]

You know, in thinking about this, when I put it in /etc/pam.d/passwd, it changes the way the "passwd" command runs. So any time anyone tries to change their password, this policy is invoked.

What if you use "adduser" to create users on your system?

Most of the time I use vipw to create a user account (using * as password, then run "passwd <username>" to set the password). So it'll be interesting to see... adduser is a shell script so I'll take a look at it when I've got a bit of time (at work presently).

[anomie]

I had some time today and wrote up a guide on the topic of password enforcement (http://www.daemonforums.org/showthread.php?t=1019) to get things started (I hope that's ok). Please feel free to add on any information, as requested in the closing section of the guide.

[pickupsticks]

Help from CIS. Great tool that i cannot believe was not brought up here, much of what it checks for has been brought up though. It scans your system and gives you results and a score, there is also a guide which shows how to "fix" what it calls problems.
http://www.cisecurity.org/bench_freebsd.html

here is an example of results, the "non-standard suid program"
it complains of is because of the schg flag set by /usr/ports/security/lockdown, did anyone mention it?, very useful :) )

MACY# egrep "^Negative" ./cis-ruler-log.20080624-20.00.56.59258
Negative: 1.1 System appears not to have been patched within the last month.
Negative: 1.2 ssh_config must have 'Protocol 2' underneath Host *.
Negative: 1.3 host based firewall is NOT enabled.
Negative: 3.2 Password not required for single user console.
Negative: 4.2 No secure level > 0 (sysctl.conf kern.securelevel="-1")
Negative: 5.2 No System Accounting enabled (rc.conf accounting_enable="NO")
Negative: 5.4 /var/log/Xorg.0.log should not be world readable.
Negative: 5.4 /var/log/Xorg.0.log.old should not be world readable.
Negative: 6.1 /etc/fstab does NOT mount cdroms nosuid.
Negative: 7.1 weak authentication not deactivated in /etc/pam.d/rsh.
Negative: 7.3 File /etc/hosts.equiv exists, is non-zero size, isn't linked to /dev/null, and doesn't contain only the - character.
Negative: 7.7 X11 is listening on TCP port 6000.
Negative: 8.3 User joe does not have a maximum password life. (91 days or less recommended).
Negative: 8.4 Default /etc/adduser.conf file not found.
Negative: 8.8 Current umask setting in file /etc/login.conf is 022 -- it should be stronger to block world-read/write/execute.
Negative: 8.8 Current umask setting in file /etc/login.conf is 022 -- it should be stronger to block group-read/write/execute.
Negative: 6.5 Non-standard SUID program /usr/bin/ypchfn
Negative: 6.5 Non-standard SUID program /usr/sbin/authpf
Negative: 6.5 Non-standard SUID program /usr/bin/chfn
Negative: 6.5 Non-standard SUID program /usr/bin/ypchsh
Negative: 6.5 Non-standard SUID program /usr/bin/lprm
Negative: 6.5 Non-standard SUID program /usr/bin/chpass
Negative: 6.5 Non-standard SUID program /usr/bin/ypchpass
Negative: 6.5 Non-standard SUID program /usr/bin/lpr
Negative: 6.5 Non-standard SUID program /usr/bin/chsh
Negative: 6.5 Non-standard SUID program /usr/bin/rsh
Negative: 6.5 Non-standard SUID program /usr/bin/lpq
Negative: 6.5 Non-standard SGID program /usr/sbin/authpf
Negative: 6.5 Non-standard SGID program /usr/bin/lpr
Negative: 6.5 Non-standard SGID program /usr/bin/lprm
Negative: 6.5 Non-standard SGID program /usr/bin/lpq

MACY# egrep "^Positive" ./cis-ruler-log.20080624-20.00.56.59258
Positive: 2.1 inetd/xinetd is not listening on any of the miscellaneous ports checked in this item.
Positive: 2.2 telnet is deactivated.
Positive: 2.3 ftp is deactivated.
Positive: 2.4 rsh, rcp and rlogin are deactivated.
Positive: 2.5 tftp is deactivated.
Positive: 2.6 finger is deactivated.
Positive: 2.7 Kerberos v4 or v5 services are not enabled.
Positive: 3.1 All Serial login prompts are disabled.
Positive: 3.3 Good umask in all rc files.
Positive: 3.4 syslogd has the -s switch and is thus not listening to the network.
Positive: 3.5 Mail daemon is not listening on TCP 25.
Positive: 3.6 DNS named daemon is not listening on port 53.
Positive: 3.7 No RPC services enabled.
Positive: 3.8 No NFS servers enabled.
Positive: 3.9 No NFS client enabled.
Positive: 3.10 No non-privileged NFS ports allowed.
Positive: 3.11 No non-privileged mount requests allowed.
Positive: 3.12 No NIS server enabled.
Positive: 3.13 No NIS client enabled.
Positive: 3.14 No Printer daemon is enabled.
Positive: 4.1 No Core dumps enabled.
Positive: 4.3 No Users see unowned processes.
Positive: 4.4 No Users see processes in other groups.
Positive: 5.1 syslog captures daemon.debug messages.
Positive: 5.3 Logging of packets received on closed ports.
Positive: 5.5 /etc/newsyslog.conf log file permissions are correct.
Positive: 6.2 password and group files have right permissions and owners.
Positive: 6.6 No user's home directory is world or group writable.
Positive: 7.2 All .rhosts files are readable only by their owner.
Positive: 7.4 at/cron is restricted to authorized users.
Positive: 7.5 'Authorized use only' message in /etc/motd.
Positive: 7.6 X Wrapper package is NOT installed.
Positive: 8.1 All system accounts are locked/deleted
Positive: 8.2 All users have passwords
Positive: 8.5 User 'toor' has been removed.
Positive: 8.6 Only one UID 0 account AND it is named root.
Positive: 8.7 No group or world-writable dotfiles in user home directories!
Positive: 8.9 User shells default to mesg n, blocking talk/write.
Positive: 6.3 No world-writable directories without sticky bit.
Positive: 6.4 No non-standard world-writable files.
Positive: 6.7 No unowned files found.

[anomie]

Help from CIS. Great tool that i cannot believe was not brought up here, much of what it checks for has been brought up though. It scans your system and gives you results and a score...

Cool - I will try it out tomorrow morning. I'm all for automating sanity checks.

[cajunman4life]

Hmm... this CIS thing seems interesting, but fails on a few points. It mentions me not having "-s" in my syslogd flags. I do have that. In fact, I have a lot more than that. Maybe that's why it's failing.

All in all, a fairly good way for a sysadmin to get a "grasp" of a few things. He can safely ignore something that he knows otherwise (like the example above, or "named running on port 53").

[hopla]

I don't want to sound negative, but I've also ran the CIS tool on my box before and the fact that it hasn't been updated in a while really shows and is quite annoying.

Lots of false warnings hide the real problems, so you have to manually check everything...

For example:
Negative: 1.2 ssh_config must have 'Protocol 2' underneath Host *.

SSHD forces SSHv2 by default, so not having it explicitly specified is not a problem anymore!

That's why I also never bothered to install security/lockdown: the last port update is from 19 Apr 2007, in fact that's still the same version 2.0.0 that was released 24 Jun 2005! It could be that it still works properly on FreeBSD6.3/7.0, but i have my doubts...

Anyway I did discover, fix and learn about a lot of problems thanks to the CIS script, so I would still recommend it to everyone! Just take it with a grain of salt :)

[richardpl]

Dont forget to add following lines to /etc/sysctl.conf

security.bsd.hardlink_check_gid=1
security.bsd.hardlink_check_uid=1
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_get_quota=0

[neurosis]

what's wrong with keeping a password.txt file ? *sniggers*

You dont need one of those if you just set your password to password. Its easy to remember. :p

[ddekok]

You dont need one of those if you just set your password to password. Its easy to remember. :p

Oh, thank you so much, I had forgotten my password. I had written it down, but I spilled my beer and the ink on the sticky-note on the bottom side of my keyboard ran!

[neurosis]

Desktop or server? In either case, depending on how it's being used would determine how many hardening cycles I'd go through.

Pretty straightforward for my desktop:

make sure no daemons are listening for tcp/udp connections (except maybe dhclient);
search for and disable useless (to me) suid/sgid programs;
enable the blackhole(4) sysctl MIBs;
turn off core dumps (more because I don't want to have to look for and delete them);
occasionally run the security/rkhunter app to perform some sanity checking;
believe it or not, scan downloaded files with clamav;
review system logs and emails;
keep base system and ports updated with security fixes asap.


I actually need to run an annoying proprietary java app that listens on all local interfaces to establish a secure connection with a system at work, so keeping in line with point #1 I run a packet filtering firewall to prevent outside connections to it. (Otherwise I probably wouldn't bother with the firewall.)

Im sorry for asking such a dumb question, but how do you disable core dumps? Ive read that ulimit -c 0 or such works but ive only been able to find information on disabling core dumps for specific files. Is this something that you do system wide? and what would be the correct way to do this. Im asking so I dont make a mistake.

thanks.

[BSDfan666]

There are several ways to disable that functionality in FreeBSD:

You can disable them via:

Login classes (See login.conf).
'ulimit -c 0' with bourne shells, 'limit coredumpsize 0' in csh.
sysctl kern.coredump = 0, kern.sugid_coredump = 0 for setuid bins.


Note: It's probably better to leave them enabled, perhaps, debugging the problem and sending it upstream.. but - we don't live in a perfect world.

[killasmurf86]

How about Sticky?

[anomie]

how do you disable core dumps?

To add to BSDfan666's answer (just in case you're not highly familiar with sysctl), you can permanently disable them using, e.g.:
echo 'kern.coredump=0' >> /etc/sysctl.conf

[valqk]

Just so you know you can use ssh key with passphrase :)

The followings configuration I would implement to secure ssh access and I think they are quite elegant:

- VPN

- No direct ssh access from internet. To access the server, all the ssh traffic is tunnelled (the only limitation with my current tunnelling application, hts & htc is it cant accept multiple tunneling connections. Anyone know the alternative one that can do this? :) )

- Port knocking :)

you can try stone (
/usr/ports/net/stone> cat pkg-descr
Stone is a TCP/IP packet repeater in the application layer. It
repeats TCP and UDP packets from inside to outside of a firewall, or
from outside to inside.

Stone has following features:

1. Simple.
Stone's source code is only 3000 lines long (written in C
language), so you can minimize the risk of security
holes.

2. Stone supports SSL.
Using OpenSSL (http://www.openssl.org/), stone can
encrypt/decrypt packets.

3. Stone is a http proxy.
Stone can also be a tiny http proxy.

4. POP -> APOP conversion.
With stone and a mailer that does not support APOP, you can
access to an APOP server.

WWW: http://www.gcd.org/sengoku/stone/
)

[18Googol2]

Thank you, it looks interesting. I will try it out soon :)