Kern.securelevel
-
Any particular reason why this is set to "-1"? I'd think "2" should be ok after install. Although, I could see how ntpd might cause some issues at "2". If that's the case "1" is way better than "-1". Personally, I set kern.securelevel to "3" in /etc/sysctl.conf once I've the FW rules set.
As an FY from security(7)
The kernel runs with five different security levels. Any super-user
process can raise the level, but no process can lower it. The security
levels are:-1 Permanently insecure mode - always run the system in insecure mode.
This is the default initial value.0 Insecure mode - immutable and append-only flags may be turned off.
All devices may be read or written subject to their permissions.1 Secure mode - the system immutable and system append-only flags may
not be turned off; disks for mounted file systems, /dev/mem and
/dev/kmem may not be opened for writing; /dev/io (if your platform
has it) may not be opened at all; kernel modules (see kld(4)) may
not be loaded or unloaded. The kernel debugger may not be entered
using the debug.kdb.enter sysctl. A panic or trap cannot be forced
using the debug.kdb.panic and other sysctl's.2 Highly secure mode - same as secure mode, plus disks may not be
opened for writing (except by mount(2)) whether mounted or not.
This level precludes tampering with file systems by unmounting
them, but also inhibits running newfs(8) while the system is multi-
user.In addition, kernel time changes are restricted to less than or
equal to one second. Attempts to change the time by more than this
will log the message ``Time adjustment clamped to +1 second''.3 Network secure mode - same as highly secure mode, plus IP packet
filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
changed and dummynet(4) or pf(4) configuration cannot be adjusted. -
I had to reply just to say for whatever reason your forum name made me laugh. ;D
-
kernel modules (see kld(4)) may
not be loaded or unloaded.egrep -Rw 'kldload|kldunload' /etc | wc -l
708
In addition, kernel time changes are restricted to less than or
equal to one second. Attempts to change the time by more than this
will log the message ``Time adjustment clamped to +1 second''.Ever tried this on an embedded system with no RTC battery? Will definitely rock.
-
The way the system is designed, it's unlikely that it could ever run above 0.
While it would be nice and extra secure, the restrictions are not feasible for tasks performed by a user-managed firewall.
-
The way the system is designed, it's unlikely that it could ever run above 0.
While it would be nice and extra secure, the restrictions are not feasible for tasks performed by a user-managed firewall.
The problem being the kernel module loads/unloads? Perhaps a "lockdown" mode where the needed modules are loaded at boot, and then securelevel set to "1"?
-
While that may be technically possible, it's still not feasible. There is not much to be gained by that method either. What specifically are you trying to accomplish? Using that method is not always better than using other security practices.
If you are worried about someone hacking the firewall, don't run services on the firewall and don't let anyone else have access to manage the firewall. Run the services on other servers than can be locked down tighter in that manner.
-
While that may be technically possible, it's still not feasible. There is not much to be gained by that method either. What specifically are you trying to accomplish? Using that method is not always better than using other security practices.
If you are worried about someone hacking the firewall, don't run services on the firewall and don't let anyone else have access to manage the firewall. Run the services on other servers than can be locked down tighter in that manner.
Absolutely, agree on minimizing services on the FW- least privilege is a good thing. I am just trying to lock down the FW like our existing FreeBSD servers.
I'll try and work on a hardening guide in my copious spare time (unless one exists already).
