Introduction to BSD and BSD Jails

From JonDonym Wiki
(Difference between revisions)
Jump to: navigation, search
m (Protected "Introduction to BSD and BSD Jails" ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
Line 4: Line 4:
 
=== Introduction to BSD and BSD Jails ===
 
=== Introduction to BSD and BSD Jails ===
  
FreeBSD is one of the Decendants from the „original“ Berkey Software Distribution (BSD) Unix, the Unix that may not called Unix since the trademark belonged to AT & T and now belongs to the „Open Group“.
+
FreeBSD is one of the descendants from the „original“ Berkeley Software Distribution (BSD) Unix, the Unix that may not called Unix since the trademark belonged to AT & T and now belongs to the „Open Group“.
  
 
Besides FreeBSD there are further descendants but they all have their common roots in the Unix version from Berkeley:
 
Besides FreeBSD there are further descendants but they all have their common roots in the Unix version from Berkeley:
Line 12: Line 12:
 
NetBSD is focused on deployments in advanced networking environments.
 
NetBSD is focused on deployments in advanced networking environments.
  
FreeBSD itself is the BSD Unix with the broadest distribution base. It is very often deployed by large firms (such as Yahoo), large sites and service providers. FreeBSD, NetBSD and OpenBSD share huge parts of code sooner or later. As only two examples: OpenSSH was developed by the OpenBSD community and lateron go deployed too by other BSDs and finally by Linux and further operating systems. The OpenBSD packet filter „PF“ is available on FreeBSD too.
+
FreeBSD itself is the BSD Unix with the broadest distribution base. It is very often deployed by large firms (such as Yahoo), large sites and service providers. FreeBSD, NetBSD and OpenBSD share huge parts of code sooner or later. As only two examples: OpenSSH was developed by the OpenBSD community and later on got deployed, too, by other BSDs and finally by Linux and further operating systems. The OpenBSD packet filter „PF“ is available on FreeBSD, too.
  
 
BSD Unices offer security solutions going far beyond the ones offered by the various Linux distributions and both BSDs are well known for their rocksolidness and reliability.  
 
BSD Unices offer security solutions going far beyond the ones offered by the various Linux distributions and both BSDs are well known for their rocksolidness and reliability.  
  
FreeBSD too offers the „portaudit“ mechanism which regularly checks your installed „ports“ (software packages) on vulnerabilities.
+
FreeBSD, too, offers the „portaudit“ mechanism which regularly checks your installed „ports“ (software packages) on vulnerabilities.
  
 
And last but not least FreeBSD offers the option to setup „Jails“ as a method to have virtualized „servers within a server“. Jails should in no case get compared to simple chroot environments. chrooting a certain part of a server or a service by far doesn't offer the same level of security. It's comparable easy to escape a usual chroot environment if the attacker is skilled but there's no way to escape a BSD jail.
 
And last but not least FreeBSD offers the option to setup „Jails“ as a method to have virtualized „servers within a server“. Jails should in no case get compared to simple chroot environments. chrooting a certain part of a server or a service by far doesn't offer the same level of security. It's comparable easy to escape a usual chroot environment if the attacker is skilled but there's no way to escape a BSD jail.
Line 23: Line 23:
  
 
Each mix runs in it's own Unix environment (in it's own Jail).
 
Each mix runs in it's own Unix environment (in it's own Jail).
Each mix jail uses it's own encrypted hard disc partition. The host system can get bootet without any need to enter pass phrases at boot time (not KVM required to boot). Nonetheless nobody can enter the data of any mix without the keyfile and additional entering the pass phrase. This of course is valid too for the data center staff.  
+
Each mix jail uses it's own encrypted hard disc partition. The host system can get booted without any need to enter pass phrases at boot time (no KVM required to boot). Nonetheless, nobody can enter the data of any mix without the keyfile and additional entering the pass phrase. This, of course, is valid for the data center staff, too.  
Following the setup instructions below, the /tmp directory will be setup as a memory disc and the SWAP partition also gets encrypted. Through this, when the host got shutdown, there's no method to access the encrypted data of any mix jail.
+
Following the setup instructions below, the /tmp directory will be set up as a memory disc and the SWAP partition also gets encrypted. Through this, when the host got shutdown, there's no method to access the encrypted data of any mix jail.
The mix jails doesn't share memory. System V memory data exchange gets disabled. Each mix gets it's own IP address of course. Firewalls (by PF as an example) can get formed to individually meet all mix jails needs.
+
The mix jails don't share memory. System V memory data exchange gets disabled. Each mix gets it's own IP address, of course. Firewalls (by PF as an example) can get formed to individually meet all mix jail's needs.
 
None of the mix jails is reachable from outside through SSH since the admin needs SSH only on the host system. Since no SSH daemon runs in the jails, this is a significant plus regarding security of the mixes. Administration of the mix jails is done by first SSH-ing into the host system and from there access the jail areas and administer the mixes.
 
None of the mix jails is reachable from outside through SSH since the admin needs SSH only on the host system. Since no SSH daemon runs in the jails, this is a significant plus regarding security of the mixes. Administration of the mix jails is done by first SSH-ing into the host system and from there access the jail areas and administer the mixes.
  
 
FreeBSD offers further security measures beyond the ones named above but this HowTo will only describe the ones listed here.
 
FreeBSD offers further security measures beyond the ones named above but this HowTo will only describe the ones listed here.
  
Of course, further jails can get setup on the same host to run other services than mixes too. In this case on just has to consider bandwith available through network adapter and uplink. Another point is – as with all server virtualization – that the hardware is a single point of failure.
+
Of course, further jails can get setup on the same host to run other services than mixes, too. In this case one just has to consider the bandwidth available through network adapter and uplink. Another point is – as with all server virtualizations – that the hardware is a single point of failure.
  
It is possible to shape bandwidth of each jail individually through using PF or other tools but this also doesn't get described in this document. Managing bandwidth shaping with PF or other tools requires sound knowledge of the protocols and the tools.
+
It is possible to shape the bandwidth of each jail individually through using PF or other tools but this also doesn't get described in this document. Managing bandwidth shaping with PF or other tools requires sound knowledge of the protocols and the tools.
  
The following description is based on FreeBSD 7.2 production release. For later production releases it might be not fully applicapable but probably most things will not change. However it is strongly recommended to always use only „production releases“ and no alternate releases as production releases are dedicated to production systems (like the one you're planning to setup).
+
The following description is based on FreeBSD 7.2 production release. For later production releases it might be not fully applicable but probably most things will not change. However, it is strongly recommended to always use only „production releases“ and no alternate releases as production releases are dedicated to production systems (like the one you're planning to setup).
  
 
Links:
 
Links:

Revision as of 10:39, 3 March 2010

FreeBSD and Jails

Introduction to BSD and BSD Jails

FreeBSD is one of the descendants from the „original“ Berkeley Software Distribution (BSD) Unix, the Unix that may not called Unix since the trademark belonged to AT & T and now belongs to the „Open Group“.

Besides FreeBSD there are further descendants but they all have their common roots in the Unix version from Berkeley:

OpenBSD is focused on best of breed security. The community has a very strong peer review method applied to all code going to be released. But – as often – security needs to get paid through some things not beeing as easy as when reducing the security approach.

NetBSD is focused on deployments in advanced networking environments.

FreeBSD itself is the BSD Unix with the broadest distribution base. It is very often deployed by large firms (such as Yahoo), large sites and service providers. FreeBSD, NetBSD and OpenBSD share huge parts of code sooner or later. As only two examples: OpenSSH was developed by the OpenBSD community and later on got deployed, too, by other BSDs and finally by Linux and further operating systems. The OpenBSD packet filter „PF“ is available on FreeBSD, too.

BSD Unices offer security solutions going far beyond the ones offered by the various Linux distributions and both BSDs are well known for their rocksolidness and reliability.

FreeBSD, too, offers the „portaudit“ mechanism which regularly checks your installed „ports“ (software packages) on vulnerabilities.

And last but not least FreeBSD offers the option to setup „Jails“ as a method to have virtualized „servers within a server“. Jails should in no case get compared to simple chroot environments. chrooting a certain part of a server or a service by far doesn't offer the same level of security. It's comparable easy to escape a usual chroot environment if the attacker is skilled but there's no way to escape a BSD jail.

To run JonDonym mixes, FreeBSD and BSD jails are an ideal opportunity to use one server (hardware) to run several mixes – each mix in it's own BSD jail. The results from such a setup are (among others):

Each mix runs in it's own Unix environment (in it's own Jail). Each mix jail uses it's own encrypted hard disc partition. The host system can get booted without any need to enter pass phrases at boot time (no KVM required to boot). Nonetheless, nobody can enter the data of any mix without the keyfile and additional entering the pass phrase. This, of course, is valid for the data center staff, too. Following the setup instructions below, the /tmp directory will be set up as a memory disc and the SWAP partition also gets encrypted. Through this, when the host got shutdown, there's no method to access the encrypted data of any mix jail. The mix jails don't share memory. System V memory data exchange gets disabled. Each mix gets it's own IP address, of course. Firewalls (by PF as an example) can get formed to individually meet all mix jail's needs. None of the mix jails is reachable from outside through SSH since the admin needs SSH only on the host system. Since no SSH daemon runs in the jails, this is a significant plus regarding security of the mixes. Administration of the mix jails is done by first SSH-ing into the host system and from there access the jail areas and administer the mixes.

FreeBSD offers further security measures beyond the ones named above but this HowTo will only describe the ones listed here.

Of course, further jails can get setup on the same host to run other services than mixes, too. In this case one just has to consider the bandwidth available through network adapter and uplink. Another point is – as with all server virtualizations – that the hardware is a single point of failure.

It is possible to shape the bandwidth of each jail individually through using PF or other tools but this also doesn't get described in this document. Managing bandwidth shaping with PF or other tools requires sound knowledge of the protocols and the tools.

The following description is based on FreeBSD 7.2 production release. For later production releases it might be not fully applicable but probably most things will not change. However, it is strongly recommended to always use only „production releases“ and no alternate releases as production releases are dedicated to production systems (like the one you're planning to setup).

Links:

Documentation recommended

FreeBSD is well documented. There is a „FreeBSD handbook“ available from www.freebsd.org as PDF (around 1.000 pages) as well as HTML web pages. The handbook is a great source and also great as an introduction to Unix in general.

Also strongly recommended is a textbook named „Absolute FreeBSD“. This book really can be named the bible of FreeBSD admins. It is full of priceless hints and the author knows very well what admins need to know.

Personal tools