How to protect FreeBSD against 0-day exploits?

B

bryn1u

Hi,

I was wondering is there any secure way to protect FreeBSD against 0-day exploits? Assuming that we don't use jails. I was reading about PaX which is part of OpenBSD's security but I don't see this solution in FreeBSD. Using mandatory access control, can we make the same or close defense as mentioned earlier?
 
bryn1u said:
I was reading about PaX which is part of OpenBSD secure but I don't see this solution in FreeBSD. Using mandatory access control can we make the same or close defense as mentioned earlier?
Click to expand...
They're different solutions for different problems. PaX tries to protect the system somewhat by making sure a process can't easily overwrite it's stack. This helps to protect against the classic buffer-overflows. MAC is a framework that extends the unix permission model. You can use that to limit the 'reach' an attacker may have once he's in the system.

As far as I know FreeBSD uses SSP/ProPolice since version 8.0.
 
SirDice said:
They're different solutions for different problems. PaX tries to protect the system somewhat by making sure a process can't easily overwrite it's stack. This helps to protect against the classic buffer-overflows. MAC is a framework that extends the unix permission model. You can use that to limit the 'reach' an attacker may have once he's in the system.

As far as I know FreeBSD uses SSP/ProPolice since version 8.0.
Click to expand...

Somewhat akin to MAC, are securelevel(s) -- security(7). There are also hints in /etc/defaults/rc.conf
Code: 
kern_securelevel_enable="NO"	# kernel security level (see security(7))
kern_securelevel="-1"	# range: -1..3 ;
Also an option during initial install; sysinstall(8), sometimes referred to "bsdinstall".

--chris
 
bryn1u said:
I was wondering is there any secure way to protect FreeBSD against 0-day exploits? Assuming that we don't use jails. I was reading about PaX which is part of OpenBSD's security but I don't see this solution in FreeBSD. Using mandatory access control, can we make the same or close defense as mentioned earlier?
Click to expand...
You actually need to do some hacking to make MAC an effective defense against hostile root processes. In particular, you need to run sshd, cron, etc. with a MAC label other than the default, otherwise an intruder who can become root can just modify /etc/login.conf and log back in to obtain a different MAC label. You also can't completely protect data with MAC because an intruder who can mount devfs will be able to access devices even if you've changed their MAC label, since the MAC label is particular to the mount instance of devfs. On the other hand, if you use mac_biba and you have a root process that can't go to biba/equal then that process isn't privileged, and therefore is incapable of performing a wide range of superuser actions. At the same time, a non-root process that can't go to biba/equal also can't su or sudo, so it's definitely a compromise either way.

Regardless of the type of security breach you're concerned with, it's always a compromise between security and usability of the system. The best defense is to turn off the machine except when you're using it, but that's an unacceptable solution for most people.

Kevin Barry
 
Why do you have to assume that jails are not used? They are very lightweight and are very effective for containing the possible breaches to a limited environment. Why not use them?
 
kpa said:
Why do you have to assume that jails are not used? They are very lightweight and are very effective for containing the possible breaches to a limited environment. Why not use them?
Click to expand...

Becouse it's not solution of my question. I don't want to eliminate the effects of hack, but the cause ! A big diffrence.
 
Greetings,
In that case; there are but 2 options
1. eliminate the perpetrators
2. do not power up your computer
Sorry, I couldn't resist. ;)

--chris
 
bryn1u said:
I don't want to eliminate the effects of hack, but the cause!
Click to expand...
You can't. Not all of it anyway. Stack protection helps but there are ways around it. All you can do is set up hurdles making it more difficult but a determined attacker will always find ways around it. The more loops the attacker has to jump through the more likely it'll be for the attacker to pick an easier target, i.e. not you.
 
SirDice said:
You can't. Not all of it anyway. Stack protection helps but there are ways around it. All you can do is set up hurdles making it more difficult but a determined attacker will always find ways around it. The more loops the attacker has to jump through the more likely it'll be for the attacker to pick an easier target, i.e. not you.
Click to expand...

Of course, know that. There is something like probability dependent on the likelihood of intrusion security. That's why im asking about solution like PaX/Grsec under FreeBSD. This patch makes it very difficult to use explotis 0 - day.
 
You could put a content inspecting hardware firewall in front of it.

Personal opinion here: A 0-day isn't really something you can protect from with 100% success on your actual OS - because by definition for a 0-day to be found, there's a bug in it. It could be a bug that gets around securelevel (or whatever other local protection you enable in the host), too.

As mentioned, you can make it more difficult however.

Do ingress and egress filtering on your network. Block (and log/alert) traffic that should not occur on the inside of your firewall (don't just assume that because it shouldn't happen, it won't happen). I.e., if your machine doesn't connect to the outside world via port 4000 for example, port 4000 should be prohibited from exiting your network from that machine.

Run an IDS, to report on traffic anomolies on your network.

Run network monitoring and regularly check trends to look for a spike in connections, increased bandwidth utilisation, etc.

Preferably, the device you have on your edge to protect your network should be different from the devices it is protecting (i.e., protect Windows with FreeBSD. Protect FreeBSD with OpenBSD or Cisco. Protect Cisco IOS with ASA or FreeBSD, etc.). This way, an exploit for the edge won't be the same as used for the internal hosts, and vice versa - to compromsie your network first the attacker needs to find either a hole in your firewall, or TWO un-patched vulnerabilities (for different platforms), instead of one. If you can use a different CPU architecture, even better (weeds out guys who are crafting an exploit for you that only know one architecture).

If they're both the same platform, an exploit in say, the IP stack could be used to compromise both machines...
 
This is how you can turn on the stack protector for all ports in make.conf(5):

Code: 
# Use -fstack-protector for all ports
.if ${.CURDIR:M/usr/ports*}
CFLAGS+=-fstack-protector
CXXFLAGS+=-fstack-protector
.endif

There are some gotchas however. This won't work if you mix code compiled with different compilers, for example clang(1) and lang/gcc.
 
kpa said:
Why do you have to assume that jails are not used? They are very lightweight and are very effective for containing the possible breaches to a limited environment. Why not use them?
Click to expand...
For one, you can't use auditing in a jail because the audit API requires privilege, which jailed processes don't have. Even if you enable it from outside of the jail, login, sudo, su, sshd, etc. executed from within the jail won't be able to log audit events. For the same reason, you can't change the login class of a jailed process, so all processes within the jail are bound to the same rctl rules (aside from user- and process-specific rules.)

Kevin Barry
 
You must log in or register to reply here.
Back
Top