|
OpenBSD Security Functionally paranoid! |
|
Thread Tools | Display Modes |
|
|||
partitioning for optimum firewall device running on flash drive + mfs
hi all!
I am trying to setup my OpenBSD PF Firewall/Router/DHCP/DNS Caching box but am getting stuck at the partitioning setup. I could use some guidance. System Stats: Code:
- Dual Nic micro-itx board with pico psu - 16GB low profile lexar USB drive as sd0 (system) - 4GB Ram - Purpose: Embedded OpenBSD PF Firewall/Router/DHCP/DNS Caching Questions:
Critical Info: Default "Auto" OpenBSD partitioning: Code:
Filesystem Mounted on /dev/sd2a / /dev/sd2l /home /dev/sd2d /tmp /dev/sd2f /usr /dev/sd2g /usr/X11R6 /dev/sd2h /usr/local /dev/sd2k /usr/obj /dev/sd2j /usr/src /dev/sd2e /var Code:
- I have deleted /tmp, /usr, /usr/X11R6, /usr/local, /usr/obj, /usr/src and /var - /, /mfs, /home and will still be on the flash drive - /, /mfs, /home and will be read only to help usb drive last longer - /dev, /etc, /root and /var will be run in memory to be written to - /mfs will be rsync backup for /dev, /etc, /root and /var Code:
a: / = 6.5GB b: swap = 1 sector d: /mfs = ~2GB (remainder of flash drive), e: /home = 6.5GB of your CF diskspace. fstab: Code:
sd0a / ffs ro,noatime,softdep 1 1 sd0d /mfs ffs ro,noatime,softdep 1 2 sd0e /home ffs ro,noatime,softdep 1 2 swap /root mfs rw,nosuid,-P=/mfs/root,-s=20M 0 0 swap /var mfs rw,nosuid,-P=/mfs/var,-s=30M 0 0 swap /dev mfs rw,nosuid,-P=/mfs/dev,-s=30M,-i=256 0 0 swap /etc mfs rw,nosuid,-P=/mfs/etc,-s=20M 0 0 Thanks as always. Last edited by daemonbak; 3rd March 2015 at 10:31 PM. |
|
||||
Your applications listed will fit in a few hundred megabytes, so you may partition how you wish.
You've eliminated a separate /tmp filesystem, and plan to make the root filesystem read-only. That's a conflict, since /tmp needs to be writeable. You can either leave root read/write, or create a memory file system for /tmp. If you select the latter, you will want to be sure your memory filesystem uses chmod 1777 for /tmp. There are two choices: mount_mfs(8) and the newer and somewhat experimental (see CAVEATS and BUGS) mount_tmpfs(8). You may also be able to use a memory filesystem for /var/run, depending on your use of the filesystem. I do this on one or two machines, and I ensure the utmp(5) file is created there via rc.local(8). I perceive three operational advantages to partitioning -- whatever schema you implement.
Last edited by jggimi; 3rd March 2015 at 11:18 PM. Reason: /etc |
|
|||
Thank you for the quick response.
Quote:
Quote:
Continuing on from OP:
Thanks again. You are very helpful. I wish there was an openbsd embedded flash openbsd tutorial written in the last few years. Most of my idea has been lifted from here: http://techblagh.blogspot.com/2008/0...kris-5501.html I also plan on running carp and a few others as well. Last edited by daemonbak; 4th March 2015 at 12:24 AM. Reason: clarification |
|
||||
jggimi mentioned [the new] tempfs which looks interesting. You might get better performance/efficiency with that over mfs (only speculation based on a cursory perusal of the docs).
Just in case you haven't seen this yet, hier(7) and "How should I partition my disk?" introduce the structure and some of the issues/concerns/factors. I noticed that you have partitions for /root and /home. That seems a little odd assuming that you're not going to be storing much/any user data on this network appliance. I might try a layout like this: Partitions / <swap> /usr /mfs tmpfs /etc /tmp /var I'm not sure how much activity occurs in /dev - whether or not it needs to be on a tmpfs, I don't know (but I'm curious (now)). Edit: Oh, and softdep on a read-only filesystem might not make much sense. Last edited by hanzer; 4th March 2015 at 01:12 AM. |
|
|||||||
Quote:
Quote:
In order to mount these mfs filesystems, I needed to modify rc(8). And, since these were live systems, and therefore always read-only OSes, I never had to worry about saving any changes. Users could store /home files on external media if needed. A lot of people modified their copy of the rc script when they were using early flash memories for storage, because they had relatively short lifetimes for write operations. That's no longer an operational issue. Flash memories now available use one of the wear-leveling technologies, so that constant writes to the same LBAs are spread across the flash media, extending their lifespans. I have several systems that use compact flash as their storage, and I don't worry about storage failures at all. Those systems use carp(4) for redundancy, and I have good, tested backup and recovery procedures. I have not had any media failures in two years of operation, with the exception of one DOA flash card that was never deployed. Will I have failures in production? Sure. But I'm not at all worried about recovery from such a failure. Quote:
With mfs, on the other hand, if you don't specify a size you get a minimum. Testing just now on i386, I get 8 MB. Quote:
Quote:
Quote:
Quote:
|
|
||||
I haven't read through this entire thread, but given your starting point of 4 GB of RAM and 16 GB of storage, I'd say have fun with it. I'm running an ancient PIII with 384 MB RAM on an 8 GB CF card, and it has more room than I can really think up uses for. It's running pf (of course), dhcpd, unbound, dnscrypt-proxy, tor, bgpd, isakmpd, ifstated, ladvd, and a few other odds and ends with no swap and it rarely if ever goes over 125 MB of RAM usage. It also has a "quite possibly" insane number of vlan interfaces, an LACP trunk, and dual uplinks configured =\
Probably not the wisest configuration (it could certainly stand to have a "feature-set reduction" and a carp twin), but I've only experienced one unplanned outage (CF card failure) in the past ~8-10 years I've been running it.
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
|
|||
I have a couple questions.
if I were to go this route: Actual Partitions / (ro) <swap> (1 sector only) /usr (ro) /mfs (rw) Memory Filesystem Partitions (tmpfs/mfs) /etc (rw) /tmp (rw) /var (rw) /dev (rw) Would this cause any issues with logging in? I would have root login off for ssh, but I have a user that would ssh in and then elevate to root. But if I have /root and /home in the / partition (which is read only) is this an issue? Also what about /usr and /usr/local. Do these need to be writeable? Besides these following partitions, do any other need to be rw or just these: /etc /mfs /tmp /var /dev Thanks |
|
|||||
No, but I noted the following:
Quote:
Swap space larger than physical RAM is required if you wish to capture kernel core dumps after a panic. See crash(8) and ddb(4). Quote:
Quote:
Quote:
Quote:
TL;DR for all my posts in this thread: Yes, you can dance across this minefield if you want; you own the music. But I think it would be better for you if you don't. Your proposed OS architecture will add complications that make the system difficult to manage, maintain, administrate, and support. All for -- in my opinion -- what is an insignificant operational MTBF-related benefit for any flash memory device manufactured in the last dozen years. Last edited by jggimi; 14th March 2015 at 02:46 AM. Reason: two typos, one thinko, and some clarity |
|
|||
Quote:
So w/ 4GB memory on a 16GB flash drive, how would you partition it? I don't need any of the X11 partitions as this will be ssh only. From reading the book, it looks like I don't need /usr/src and /usr/obj since I am not compiling from source. Although this may be an issue on upgrades. The book didn't go into details. Would you run var/tmp and /tmp in mfs or just take that out of the equation. I am going for stability and security. So how would you partition my disk knowing my setup. Thanks and sorry for being the guy that doesn't get it. |
|
||||
The OS without the X filesets will fit in less than 300 Megabytes of disk space. That includes the compiler fileset. More storage will be needed if you run applications that require X libraries -- but your list in your first post didn't mention any.
One of my firewalls, running i386, runs the usual daemons you might find on firewall/routers: dhcpd, ftpproxy, identd, ifstated, ntpd, smtpd, syslog, and unbound built-in services. It also runs nginx and ddclient daemons, and has a few client applications (such as lynx) for administrative use. Including dependencies, there are 14 packages installed. This system runs in a single "a" partition on a 1GB compact flash card, and that filesystem is currently using 309 Megabytes. The card has a "b" partition which is swap space. I have another system which is its twin -- it is a backup firewall/router, and as it is a backup firewall/router it also is a server for some additional applications, such as PHP applications. As this system is an application server, it has a 4GB compact flash card for storage. That system includes many more applications, including those that require both X libraries and X fonts, so the xbase*.tgz and xfont*.tgz filesets are also installed. At this time, I am using a single partition once again, and 1.4 GB are in use. While these two systems do not use multiple partitions, there are benefits to having them, which I am not able to exploit with my single partition use-case. They are 1) managed growth, and 2) security. Managed growth: runaway storage allocation on one filesystem will not impact any other filesystems. This might permit a system to keep running any remaining unaffected applications. Your defined list of applications doesn't do a lot of file allocation, so I don't perceive this as being of immediate benefit. Security: some filesystem mount options can restrict use: nodev, nosuid, noexec, and as you've already noted, rdonly. These can be used as a layer of administrative security for systems which are multiuser, or as a layer of security limiting the capabilities of any attack vector that might issue arbitrary file input/output instructions . The installation script provides automatic defaults which don't fit every use case -- they can't. You've already noted that there are filesystems you will never use. I recommend starting with a custom configuration, with the intent to add to it later. Start with two partitions: a: 512 MB root partition b: swap space. If you want to ever store a kernel core dump, make this larger than 4GB. That's it. But, this is a starting point. If, in the future, you decide you want to add applications that have active databases, you can create a partition for the application, or move /var, or /var/db, into its own partition. If you decide you want to do development, you can later add /usr/ports or /usr/src. Or in the future, you can separate /home into its own partition. Easy to do so. I recommend this because at this time, your intended application set uses very little storage, and your network applications are all privilege separated. But what we intend today very rapidly changes to something we did not initially intend. Give yourself room to grow, change, and add without encumbering yourself. Otherwise, you'll end up re-installing in order to reconfigure, because reinstallation will be easier. If this sort of simple configuration is anathema, take the defaults, then delete the partitions you don't believe you'll need. Either way, your total storage use will start at about 300 MB. Less, if you elect not to install the compiler set. |
|
|||
What about this: (see image).
I would keep /tmp and /var as tmpfs or mfs and sync it to the mfs partition and back on halt and boot. There would be ~3GB unalocated space for future use. |
|
|||
The rule of thumb I use (which is advocated by many...) is to set the size of swap as 2x RAM + 1MB. I also allocate the same for /var/crash which is discussed in crash(8). As previously mentioned by jggimi, this allows the state of the kernel to be written to disk following a crash in order to ascertain the cause.
Quote:
|
|
|||
Without contributing anything useful to this thread, you can type simply:
Code:
> p m |
|
||||
/var
Since you're not running any databases, the only volatile files in that branch are in /var/run. I've got a workstation running with /var/run as tmpfs. It's never backed up, because it only contains run-time files such as process identifiers. The only thing I do is add this line to /etc/rc.local: Code:
touch /var/run/utmp I mentioned that swap has to be larger than RAM if you ever want to capture a kernel panic, and I note you've got it a bit larger. savecore(8) is run by rc(8) to store any core dumps in /var/crash during boot. If that space isn't sufficiently large, you might have to run savecore manually, pointing to an alternate directory with sufficient space. On my primary firewall, there's not enough storage to save any core dump, and in the event of any panics (none, after several years) I plan to run savecore manually to store to either an NFS mount or a USB attached drive, depending upon personal convenience at that time. Other than these last comments, your design looks fine to me. My concern wasn't so much how you slice/dice the drive so much as avoiding issues caused by having read/only partitions for data that was not intended by the Project to be read/only. Last edited by jggimi; 20th March 2015 at 02:18 AM. Reason: toyp. otyp. yopt. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
MBR GPT hybrid partitioning | J65nko | FreeBSD Installation and Upgrading | 2 | 16th November 2011 09:37 AM |
Partitioning the LiveUSB drives. | IronForge | OpenBSD Installation and Upgrading | 6 | 29th August 2010 10:27 PM |
Partitioning for web/mailserver? | DrKrall | OpenBSD Installation and Upgrading | 3 | 20th November 2009 01:14 PM |
partitioning scheme for a firewall? | Timmy66 | OpenBSD Security | 1 | 19th September 2009 01:28 PM |
identifying device associated with USB device? | spiderpig | OpenBSD General | 2 | 7th July 2008 05:18 AM |