Hardening bsd.

Do you really think that automout usb on BSD is a security problem?
 
The biggest problem usually sits between the chair and the keyboard.
Always has been and always will be.

Users are a bigger risk then a few outgoing connections to Microsoft sites.
They must have missed the part where I said my port 0 rule broke MS updating on Win10Pro when used in their firewall. ^

My rule blocking port 0 carried over from my Win98 ConSeal PC Firewall ruleset. Years later, while tweaking the Win10Pro firewall, I discovered it will stop Win10Pro from downloading updates and installing updates for the Windows 10 Service.

Probably the part where it isn't even considered an OS in MS Docs, too. Hidden right under that, lost somewhere in my ramblings...

And is automounting usb-sticks a good idea when users have access to a system...
Some people who do it for a living, here in the forums, think so.

"Do you really think that automout usb on BSD is a security problem?"

Told you. And I wasn't even talking about them while I was typing that.
 
Some people who do it for a living, here in the forums, think so.

"Do you really think that automout usb on BSD is a security problem?"

Told you. And I wasn't even talking about them while I was typing that.
Some other, who do it for a living, does not think so.
Please explain exactly how an USB automount on FreeBSD create a security problem
There is always something to learn

PS Windows update what? We are talking about BSD
 
Please explain exactly how an USB automount on FreeBSD create a security problem
There is always something to learn
I was trying to get around doing this:


PS Windows update what? We are talking about BSD
That's a FreeBSD boxen?

This is an example of a useful firewall: what (an unused) Windows 10 will do?
View attachment 10023
 
I was trying to get around doing this:



That's a FreeBSD boxen?
The question is easy.
If you do not want to log, or restrict to 'someone' connecting to you (and you do not use Windows), what do in practice a desktop firewall?
How?

About USB and BSD. It is still not clear to me what the risk of a USB automount might be.
Will some kind of program be launched automatically?
Maybe, I never use GNOME or GUI in general.
Can you explain if, by inserting a USB stick, the same happens for BSD as for Windows?
Thank you
 
Do you really think that automonut usb on BSD is a security problem?
Yes. I run some kiosks and the last thing I would want is an inserted USB stick to be automounted.
Thankfully automount is optional.
FreeBSD is used in many environments so please consider many different use cases concerning hardening.
 
  • Thanks
Reactions: a6h
fcorbelli said:
It is still not clear to me what the risk of a USB automount might be.

Simply because you don't know what is on that USB-stick, it may contain all sorts of malware. Automount allows users to bring that stuff in and that may turn your FreeBSD into a FleaBSD sooner than you like. It may not be as bad as that autorun facility on Windows (do they still have that?), but is a security hole. A bigger one than a port not covered by a firewall where no process is listening to imho.
Because normal users don't have rights to mount a USB-stick, no automount is a very effective measure.
 
FreeBSD is used in many environments so please consider many different use cases concerning hardening.
Right here. This is the key point that seems to have been missed in this topic.
Different users have different needs.
What is mandatory/common sense for one, could make no sense to another.
Just because one disagrees with or doesn't understand another users "use case" does not mean either of them are wrong.

If I want to wear a red shirt today, why do I have to justify it to you or convince you that it's a valid choice? Maybe I just want to wear a red shirt.

USB automount: A lot of *nix DE's seem to be drifting towards "work the way Microsoft Windows works". For a long time (maybe still is) Windows will automount and autoplay inserted devices. I'm not sure if any *nix DEs (I don't use any) try to do the autoplay yet, but if so they could run into similar issues, especially if the automount process is running under root privs.
 
Right here. This is the key point that seems to have been missed in this topic.
Different users have different needs.
What is mandatory/common sense for one, could make no sense to another.
I give someone an old i386 laptop running FreeBSD, access to using my old account with a password of 11111. They have no concept of tapping a key to enter a password, still can't do it after a month on their own, so I take it back. That's as simple as it gets. If they can't do that no point in them having one.

I gave it to someone else and am teaching them how to Drag and Drop a Window. Ports? That side of the ship, swabby. He was in the Navy so he will sink or swim if I leave him treading water long enough.

I am surrounded by computer illiterate people who have no idea what I'm talking about when I mention a bot or FreeBSD. Somebody stared at my FreeBSD Power to Serve T-shirt today like what Devil Worshiping witchcraft wear does he have on today...

It wasn't my Sheri Moon Zombie Living Dead Girl "Say You Love Satan" shirt, but Demon/Daemon what's the difference? He's got a Devil on his shirt and He's serving something. Probably Satan... Don't let him hear you say anything or he will cast a curse on you.

I could switch to another workspace, unplug the mouse and that would be enough for local Security if I left it running and was gone a week and everybody came into look. Watch for him and tell us if he's coming, he's wearing a red shirt.

Just because one disagrees with or doesn't understand another users "use case" does not mean either of them are wrong.
Neither does it make bad policy to change my password to 11111 into good policy. Or smart or ass/u/me everyone in the World is as computer illiterate as they are. Underestimating me the worst thing you can do. I don't underestimate the rest of the World no matter how stupid I think they are, they might just steal the laptop to sell it.

Darn it... Not being a thief I never thought of that... Hey, catch that guy in the red shirt! That one! The one with the laptop. Oh, forget it... I'll cast a curse on him.

If I want to wear a red shirt today, why do I have to justify it to you or convince you that it's a valid choice? Maybe I just want to wear a red shirt.
I prefer black and nobody says anything, unless it's a compliment on my Exorcist or Werewolf Women of the SS Sheri Moon shirt. Or when I go into the Pharmacy and hear, "You're right, he does look good in a mask" continued talk between themselves.

One of the guys at the Pharmacy tried to get me to let him set up an online account with Medicare for me. I said I just woke up and would have to think what password I wanted to use and get back with him. No, not 11111.

1111111a. I always put a 1 and an a on the end of all my passwords. Makes it hard to guess. My Yahoo password is mudpuddle1a.

Naw, he'll never remember that... He's got a Devil on his shirt.
 
  • Thanks
Reactions: a6h
Somebody stared at my FreeBSD Power to Serve T-shirt today like what Devil Worshiping witchcraft wear does he have on today...
back in the 3.x days i replaced netware with a freebsd box running samba
the office was full of old ladies doing accounting stuff (they were all logging in as supervisor with no password)
after several weeks they called and said:
Well the computer works ok, email works, we can print but can you remove the devil from the server screen
we dont like devils ....
beastie screensaver
 
@trihexgonal,
inetd is obsolete.
Gonna add it to src.conf WITHOUT_INETD
I knew I had seen something mention using inetd recently but couldn't remember what it was. I happened on it again:

"Microproxy is a very small Unix-based HTTP/HTTPS proxy. It runs from inetd,
which means its performance is poor. But for low-traffic sites, it's quite
adequate."
net/micro_proxy
 
I have no idea who "Jon" is or where I got it but he wrote this tutorial on Hardening FreeBSD. I've had it on file since 2005 and it mentions FreeBSD 5.3. That was the version FreeBSD was at, and when, I started using PC-BSD:

Hardening FreeBSD
June 27, 2005 by Jon

After a fresh install, it is important to harden the security on a server before it hits your network for use. Not only making configuration changes aid in the security of your box, but there are some practical rules to abide by. These are some hardening tips to make your FreeBSD box more secure and will apply to both the 5.x and 4.x branches, but I will assume you are running 5.x. If a 4.x change is different, I will note it.

Note: Please do not apply these changes carelessly on a production server. Make sure you test, test, test on a separate box to note the effects of the changes.
Requirements

Clean installation of FreeBSD
Local root access on the box or be able to su to root.
A SSH client that supports ANSI colors such as puTTy or SecureCRT (if you aren’t on the box).
Your favorite text editor (I prefer nano).

Hardening

Filesystem Structure

On a default install, you will find two places for temporary files — /tmp and /var/tmp. Different packages and daemons use the different directories and there really isn’t any need to use two different partitions for temporary files. Here we will replace /var/tmp with a link to /tmp.

# mv /var/tmp/* /tmp/
# rm -rf /var/tmp
# ln -s /tmp /var/tmp

Disable Local root Access

The first rule to securing your box is to never treat the root account as a regular user. Never conduct mundane business while you are logged in as root. As the superuser, there are no restrictions as to what root can do, so always log in with a normal user and su to root only when needed.

With that in mind, it may be tempting to log on locally as root so let’s prevent root from directly logging on to your system console. Open /etc/ttys with your editor and change every occurence of “secure” to “insecure” as this will prevent root from logging in locally. *Note: changing the console entry will result in being prompted for the root password when booting into single-user mode; thus, making the recovery of the root password more difficult.

# nano -w /etc/ttys
Code:
***output omitted***
console none                            unknown off insecure
#
ttyv0   "/usr/libexec/getty Pc"         cons25  on  insecure
# Virtual terminals
ttyv1   "/usr/libexec/getty Pc"         cons25  on  insecure
ttyv2   "/usr/libexec/getty Pc"         cons25  on  insecure
ttyv3   "/usr/libexec/getty Pc"         cons25  on  insecure
ttyv4   "/usr/libexec/getty Pc"         cons25  on  insecure
ttyv5   "/usr/libexec/getty Pc"         cons25  on  insecure
ttyv6   "/usr/libexec/getty Pc"         cons25  on  insecure
ttyv7   "/usr/libexec/getty Pc"         cons25  on  insecure
ttyv8   "/usr/X11R6/bin/xdm -nodaemon"  xterm   off insecure
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyd0   "/usr/libexec/getty std.9600"   dialup  off insecure
ttyd1   "/usr/libexec/getty std.9600"   dialup  off insecure
ttyd2   "/usr/libexec/getty std.9600"   dialup  off insecure
ttyd3   "/usr/libexec/getty std.9600"   dialup  off insecure
# Dumb console
dcons   "/usr/libexec/getty std.9600"   vt100   off insecure
***output omitted***
Save and exit and your changes will take effect immediately.

SSH Logins

By default, FreeBSD prevents root from logging in via ssh, but it gives anyone else with a valid user account access. If you are not running a shell server, it is a good idea to restrict ssh access to only members of the wheel group — or you can create a separate group if you want some people to log in but not be able to su to root, say a group named “sshlogins.” Let’s add the following to the end of the sshd configuration file:

# cat << EOF >> /etc/ssh/sshd_config
# PermitRootLogin=no
# AllowGroups wheel sshlogins
# Protocol 2
# X11Forwarding=no
# VersionAddendum
# EOF

We also want to ensure only SSHv2 connections are made as SSHv1 does not offer all the security of v2. Servers don’t need to be running X11 so we might as well turn off forwarding for X11 to make sure there aren’t any attempts. The final entry we made was to disable the OS display.

An optional security measure to take is add a banner for users to see before they log on. If you like the idea, follow these steps:

# echo "Banner /etc/welcomemsg" >> /etc/ssh/sshd_config
# cat << EOF > /etc/welcomemsg
# !!WARNING!!!
# READ THIS BEFORE ATTEMPTING TO LOGON
#
# This System is for the use of authorized users only. Individuals
# using this computer without authority, or in excess of their authority,
# are subject to having all of their activities on this system monitored
# and recorded by system personnel. In the course of monitoring individuals
# improperly using this system, or in the course of system maintenance,
# the activities of authorized users may also be monitored. Anyone using
# this system expressly consents to such monitoring and is advised that if
# such monitoring reveals possible criminal activity, system personnel may
# provide the evidence of such monitoring to law enforcement officials.
#
# EOF

Password Rules

By default, FreeBSD uses md5 for password hashing and encryption. It’s not bad, but blowfish is much better suited for passwords and we need to update some files to reflect blowfish. *Note: Passwords will not be converted to blowfish until they have been changed.

# echo "crypt_default=blf" >> /etc/auth.conf

You need to manually edit /etc/login.conf and change the password format in the default class to blf. We should also modify the default password policy to put a minimum password length requirement and mix upper and lower case. Let’s also cause passwords to expire after 90 days and to automatically log users out if they are idle for 30 minutes. It’s also a good idea to set the default umask to prevent global access. The umask is the inverse to the chmod. So in this case when new files and directories are created, they will get the permissions of 0750.

# nano -w /etc/login.conf
Code:
***output omitted***
default:\
        :passwd_format=blf:\
        :copyright=/etc/COPYRIGHT:\
        :welcome=/etc/motd:\
        :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
        :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin ~/bin:\
        :nologin=/var/run/nologin:\
        :cputime=unlimited:\
        :datasize=unlimited:\
        :stacksize=unlimited:\
        :memorylocked=unlimited:\
        :memoryuse=unlimited:\
        :filesize=unlimited:\
        :coredumpsize=unlimited:\
        :openfiles=unlimited:\
        :maxproc=unlimited:\
        :sbsize=unlimited:\
        :vmemoryuse=unlimited:\
        :priority=0:\
        :ignoretime@:\
        :minpasswordlen=8:\
        :mixpasswordcase=true:\
        :passwordtime=90d:\
        :idletime=30:\
        :umask=027:
***output omitted***
Update the login database with:

# cap_mkdb /etc/login.conf

After you change the user’s password, you will notice the hashing for the password in /etc/master.passwd begins with $2a. This means blowfish is being used.

Restrict User Access

Scheduling jobs is a powerful feature in *nix, but at the same time, it can pose a security concern for your system if you allow users to schedule jobs — especially if they are set up incorrectly. The potential harm could be looping a process endlessly, running malicious code (though this wouldn’t pose too big of a problem if it’s not run as root), or incorrect schedules. It is recommended to restrict cron and at to only root.

# echo "root" > /var/cron/allow
# echo "root" > /var/at/at.allow
# chmod o= /etc/crontab
# chmod o= /usr/bin/crontab
# chmod o= /usr/bin/at
# chmod o= /usr/bin/atq
# chmod o= /usr/bin/atrm
# chmod o= /usr/bin/batch

The next thing we need to restrict is read and execution of certain files. Regular users should not have access to the following configuration files:

# chmod o= /etc/fstab
# chmod o= /etc/ftpusers
# chmod o= /etc/group
# chmod o= /etc/hosts
# chmod o= /etc/hosts.allow
# chmod o= /etc/hosts.equiv
# chmod o= /etc/hosts.lpd
# chmod o= /etc/inetd.conf
# chmod o= /etc/login.access
# chmod o= /etc/login.conf
# chmod o= /etc/newsyslog.conf
# chmod o= /etc/rc.conf
# chmod o= /etc/ssh/sshd_config
# chmod o= /etc/sysctl.conf
# chmod o= /etc/syslog.conf
# chmod o= /etc/ttys

Attackers tend to clear out all log files when they are finished with your box. If they don’t have access to the logs and cannot edit them or delete them, then you can go in and see what was done. First, let’s disable user access to the log file directory and then we will set the permissions so the log files cannot be deleted.
Note: Applying these changes to the log files will also mean logs can no longer be rotated.

# chmod o= /var/log
# chflags sappnd /var/log
# chflags sappnd /var/log/*

You may want to restrict users from trying to execute certain programs like the following:

# chmod o= /usr/bin/users
# chmod o= /usr/bin/w
# chmod o= /usr/bin/who
# chmod o= /usr/bin/lastcomm
# chmod o= /usr/sbin/jls
# chmod o= /usr/bin/last
# chmod o= /usr/sbin/lastlogin

There are a few services that should be disabled permanently:

# chmod ugo= /usr/bin/rlogin
# chmod ugo= /usr/bin/rsh

And of course, any third-party utilities you install and don’t want general users to access should be chmoded as well.

# chmod o= /usr/local/bin/nmap
# chmod o= /usr/local/bin/nessus

System Configuration for Daemon Startup

Now it is time to enable or disable certain services by editing /etc/rc.conf. Here we will disable sendmail as it is an insecure MTA. If you want to run a mail server, I recommend using qmail.

# echo 'sendmail_enable="NONE"' >> /etc/rc.conf

The default kernel level is -1, meaning not much gets protected. You probably only need the secure level at 2, but 3 is the most secure. If you want more information on the secure levels, read the man pages for init(8). Note: The securelevel can only increase once the kernel is loaded.

# echo 'kern_securelevel_enable="YES"' >> /etc/rc.conf
# echo 'kern_securelevel="3"' >> /etc/rc.conf

If you aren’t running NFS, disable portmap:

# echo 'portmap_enable="NO"' >> /etc/rc.conf

inetd, or the network daemon dispatcher, is insecure so we want to make sure it is disabled.

# echo 'inetd_enable="NO"' >> /etc/rc.conf

It’s a good idea to clear your /tmp directory at startup to make sure there isn’t anything malicious hanging around in your temp files.

# echo 'clear_tmp_enable="YES"' >> /etc/rc.conf

If you are not logging to a remote machine, it is a good idea to make sure syslogd does not bind to a network socket.

# echo 'syslogd_flags="-ss"' >> /etc/rc.conf

ICMP Redirect messages can be used by attackers to lead you to their router or some other router, which would be bad. Let’s ignore those packets and log them.

# echo 'icmp_drop_redirect="YES"' >> /etc/rc.conf
# echo 'icmp_log_redirect="YES"' >> /etc/rc.conf

The following option is a good choice as it will log all attempts to closed ports. This is good to know if people are trying to access your box through a specific port.

# echo 'log_in_vain="YES"' >> /etc/rc.conf

Set Kernel States

There are some kernel states we need to change and we’ll add them to /etc/sysctl.conf to make them permanent. The first one is to prevent users from seeing information about processes that are being run under another UID.

# echo "security.bsd.see_other_uids=0" >> /etc/sysctl.conf

Note: 4.x users use the following instead:

# echo "kern.ps_showallprocs=0" >> /etc/sysctl.conf

The second change to make is to enable the concept of blackholing. This is so RST packets don’t get sent back in response to closed ports. This helps to block port scans.

# echo "net.inet.tcp.blackhole=2" >> /etc/sysctl.conf
# echo "net.inet.udp.blackhole=1" >> /etc/sysctl.conf

We want to generate a random ID for the IP packets as opposed to incrementing them by one. This will prevent remote observers from determining the rate packets are being generated by watching the counter.
Note: This setting is only for 5.3 and beyond. If you are running any older version of FreeBSD, you will need to compile your kernel with this option.

# echo "net.inet.ip.random_id=1" >> /etc/sysctl.conf

Kernel Entries

There are a couple of security settings we can fix at the kernel level. One security hole we need to plug is disabling ctrl+alt+del so somebody can’t walk up to your box and reboot your server with the three-finger solute. Add the following lines to the options:
Note: The RANDOM_IP_ID option is only for versions of FreeBSD that are older than 5.3.

# nano -w /usr/srs/sys/i386/conf/MYKERNEL

***output omitted***
options SC_DISABLE_REBOOT # Disable Ctrl+Alt+Del
options RANDOM_IP_ID # Enables random IP ID generation
***output omitted***

If you haven’t already compiled a custom kernel for your hardware, make the necessary kernel config changes at this time. If you have never done that before, use Derrick’s kernel config guide as a guideline.

Once you finish customizing your kernel, install it and then reboot. Once it comes back up, log in and update your ports tree so you can upgrade your ports.

Optional Settings For a Stealthier System

The following options may be used, but are only recommended for system that are gateways, log servers, or dedicated firewalls. You may apply these to normal servers if you would like, but they may decrease performance — especially on web servers.

We can configure FreeBSD to drop SYN/FIN packets:

# echo 'tcp_drop_synfin="YES"' >> /etc/rc.conf

Add the following to your kernel configuration to enable the ability to drop SYN/FIN packets and to enable stealth forwarding. Stealth forwarding passes packets without touching the TTL, so this is useful for hiding firewalls from traceroutes.

# nano -w /usr/src/sys/i386/conf/MYKERNEL

***output omitted***
options TCP_DROP_SYNFIN # Enables the ability to drop SYN/FIN packets
options IPSTEALTH # Enable stealth forwarding
***output omitted***

Now your FreeBSD server has been hardened and ready for your production use. You can also use the lockdown utility (/usr/ports/security/lockdown) and it will automate a lot of this, but not everything.
 
Back
Top