Fireball ISO 1.3 - by Indy (indy@seerofsouls.com)


SourceForge
(http://sourceforge.net/projects/fireballiso)
Summary
  Features
New in version 1.3 (Jan 14, 2012)
New in version 1.2 (Dec 30, 2010)
Where to go for help
Security issues
Comments and suggestions
Base environment configuration
  Log in
  Change root password
  Set your local timezone
  IP address
  DNS servers
  SSH configuration
  Firewall Rules
  Rsync and update servers
  NTP timeserver
  Updates
Build environment configuration
  Set your root password (build)
  IP address (build)
  PPP setup
  DNS servers (build)
  Host name (build)
  SSH server keys (build)
  DHCP & DNS cache config
  Set your local timezone (build)
  Gentoo rsync and update servers (build)
  NTP timeserver (build)
  IPTables & IP6Tables rules (build)
  Kernel configuration
  Updates (build)
  Optional: IPv6 Internet connectivity
  Remove unnecessary packages
  Customization
Building the Fireball LiveCD
  Optional Encryption
  Build the ISO (changed in 1.3)
  Test the Fireball ISO
Making copies of your Fireball virtual appliance
Security Reminders
Troubleshooting
  Build errors
  General testing
  NIC interface changing for appliance copies
Credits

Summary

Fireball ISO is a VMWare virtual appliance that builds a bootable ISO image containing a stripped-down custom version of Gentoo Linux, focused on providing firewall and other services to a network. This image may be burned to a CD (where it may be called a LiveCD), allowing an otherwise unused, old computer to boot it and act as a network security device. The generated ISO can itself be used in a virtual machine, without needing to be burned to CD.

New in version 1.3 is support for encrypting almost all the files in the ISO with LUKS (Linux Unified Key Setup), which makes it extremely difficult for someone without the configured passphrase from reading the contents of the ISO (assuming the passphrase is a good one). The main issue to be aware of is that the passphrase must be entered during each boot, or the system will not start; the user should decide whether that is a good tradeoff for increased protection for the ISO. See the official LUKS website for details.

Even though this document is focused on using this product to generate a bootable firewall ISO, the product can be changed to perform any tasks for which a bootable (and potentially encrypted) Linux ISO makes sense. Perhaps it would be suitable for a secure cloud appliance. I would be very interested in the ideas everyone has - feel free to share through email or forum postings.

The 1.3 release will likely be the last release I make for Fireball ISO. I've accomplished all the major things that I set out to do, and everyone seems content with the current features (or at least content enough not to suggest any new features). It supports easy updates to remain current, so it's not going to get out of date as long as Gentoo Linux is maintained.

Features

Features in the generated ISO include:

New in version 1.3 (Jan 14, 2012)

New in version 1.2 (Dec 30, 2010)


Where to go for help

Please keep in mind that I myself wrote little of the software in this virtual appliance, and have no wish to take credit for the efforts of many open source software developers and companies who have been very generous with their time and knowledge. My main contribution was bringing everything together by following instructions written by the Gentoo and wider Linux communities (and occasionally providing additions or corrections), installing packages, setting up configuration files, writing scripts and documentation, and lots of testing. If you have questions or problems with any specific software in this virtual appliance, you are more likely to get the quickest and best help in these places, in order:

  1. Man page, website, or other instructions of the related software. This is where the most detailed information is usually found. Google or another search engine can help you locate information on specific issues as needed.
  2. Gentoo documentation
    1. I used the Gentoo Installation Docs and Quick Install (for those who are more familiar with Gentoo or Linux in general) extensively in the creation of Fireball. Refer to these for basic questions on configuring the Gentoo Linux aspects of both the Fireball base environment and build environment.
    2. HOWTO Build a LiveCD from scratch (alternate link) provided most of the details to create the Fireball build environment inside the virtual machine, as well as actually getting it compiled into a bootable ISO image. Consult this if you're trying to make changes to the mechanics of the build environment itself, or want details on how the ISO is generated.
  3. Me (Indy - indy@seerofsouls.com), for the build scripts and issues related to the Fireball virtual appliance as a whole. Please remember that I'm doing this for free, in my spare time (unless you hire me for a specific project :-). You will get a response eventually, and a polite, complete and focused description of your question or problem will definitely speed up my response to you. Please try to exhaust the first two options before contacting me with your application-specific questions.

Security issues

If you have security issues related to the fundamental design or implementation of Fireball as a whole, please send them to me, with FIREBALL SECURITY in the subject line somewhere. These should be flaws with the underlying design or implementation of the unmodified Fireball virtual appliance. I will do what I can to address the issue, and may release updates if warranted. Whatever happens, in the end you are ultimately responsible for the security of your network, including your Fireball installation. If you don't feel that Fireball meets your needs, feel free to modify it, or simply don't use it.

Security problems with individual pieces of software should be referred to the authors or maintainers of that software; their contact details should be in the documentation of the applicable software. Make sure you have the latest versions and are following the recommended usage guidelines before you report problems. Of course, since Fireball is a very customizable system (like Gentoo itself), and any software can be configured in an insecure manner, you should not report issues related to any inherently-insecure configuration (like setting up poor firewall rules, installing insecure services, and so on).

Comments and suggestions

Suggestions for new features are always welcome. I'm very interested in how you use Fireball, and how you modify it; perhaps others would be interested in your modifications. Constructive criticism would help to make Fireball ISO better, especially if it helps improve usability. Feel free to contact me with your stories and ideas.


Base environment configuration

Note: this will cover a very basic setup. For more details, please refer to the Gentoo documentation links above.

Log in

Start the virtual machine, and log in as root, with fireball as the password. (Note: depending on your network setup, after startup you may need to wait a while for network services to time out before you can log in; if this occurs, it won't be a problem after you configure the network for the appliance.) You are now in the "base environment", which is a basic Gentoo installation that holds the Fireball build environment (which contains the collection of files that eventually become the bootable ISO of your Fireball system).

Change root password

The first thing you need to do is change the password of the base environment.

passwd

Note: make sure you record this new password in a safe place. If forgotten, there are ways to change or recover a lost root password; Google for methods. Fireball doesn't protect against these password recovery methods, so if this is a risk for you, you should implement protections against these methods (again, Google for protection methods).

Set your local timezone

I set my timezone to my local one, but others may wish to use UTC; it's up to you.

ls /usr/share/zoneinfo

This uses CST6CDT as an example; replace with your desired timezone:

cp /usr/share/zoneinfo/CST6CDT /etc/localtime

Add your timezone name to these files:

nano /etc/profile          # set the TZ variable to your timezone name
                           # (example:  export TZ=CST6CDT)

IP address

Set the IPv4 address.

ifconfig eth0 [IP address desired]

Set your default gateway.

route add default gw [IP address of default gateway] eth0

Now edit the /etc/conf.d/net file with the same IP address and default gateway; this will save them to be set at each reboot.

nano /etc/conf.d/net

DNS servers

OpenDNS servers are already configured as the DNS servers. If you prefer, edit /etc/resolv.conf and replace the existing OpenDNS IP addresses with others (like, for example, the DNS servers of your ISP). If you choose to use the OpenDNS ones, you might wish to see http://www.opendns.com for information on additional features they provide with their free and paid DNS services that may be useful.

SSH configuration

The SSH server should start automatically when you boot up the Fireball appliance, and create new server keys. If you like, you can ssh to the machine, using the IP address you just set, and work with it from there.

One security change you should consider is to restrict the SSH server to only listen on the IP address(es) on which you want to connect to it. By default, the SSH server will listen on all interfaces, and you might not need that. For example, I want my SSH server to listen on my local IPv4 and IPv6 addresses, but I don't want it to listen on my globally-reachable IPv6 address (since I will not need to connect to my base environment using that address); to accomplish that, I'll add the following lines to the /etc/ssh/sshd_config file:

# listen on this local IPv4 address
ListenAddress 192.168.2.1
# listen on this local IPv6 address
ListenAddress fe80::20c:29ff:feae:4631%eth0
Note: make sure to use your own IP addresses. Include the correct interface at the end of the IPv6 address, since this is required for local IPv6 addresses. To make these changes effective without rebooting, simply restart the sshd server:
/etc/init.d/sshd restart
Then check that the ssh server is only listening on the IP address(es) that you specify:
netstat -an

Firewall Rules

You can display the existing firewall rules with fw (which is an alias for iptables -nv -L); same with fw6 for ip6tables rules. Other display options can be added after the alias; for example:

fw6             # display all ip6tables rules
fw INPUT        # display only the iptables rules in the INPUT chain
fw -t nat       # display only the iptables rules in the nat table
You shouldn't need to make much, if any, modifications to these firewall rules, except possibly restricting SSH access to the allowed address(es), but you will definitely need to edit the rules in the build environment, which will be used by the generated ISO.

Rsync and update servers

You may like to change the existing update and/or rsync servers, perhaps to ones closer to your geographical location. If you have Internet access, one easy way to do this is to use mirrorselect.

For a list of Gentoo update servers, run this and choose a few servers:

mirrorselect -i -o >> /etc/make.conf
For the Gentoo rsync server, run this and choose one server:
mirrorselect -i -r -o >> /etc/make.conf
Now edit the /etc/make.conf, check the lines added at the end, and remove any duplicate SYNC or GENTOO_MIRROR lines above these.
nano /etc/make.conf

Note: if you have a local rsync server, you can manually add that instead of using the mirrorselect command above. It makes sense to set up your own if you have more than one Gentoo installation in your local network, and it's very easy to do. Instructions are at http://www.gentoo.org/doc/en/home-router-howto.xml - search for Rsync Server.

Optional: if you like, copy the same update and rsync servers into the build environment
grep SYNC /etc/make.conf >> /root/livecd/source/etc/make.conf
grep GENTOO_MIRROR /etc/make.conf >> /root/livecd/source/etc/make.conf
Then edit the file to remove duplicate SYNC or GENTOO_MIRROR lines if needed
nano /root/livecd/source/etc/make.conf

To avoid generating too much traffic with the public sync servers, please make sure you don't sync more than once a day. This will help ensure that these free servers remain available to you and everyone else.

Note: the portage tree is not included with the Fireball virtual appliance, to greatly reduce the size of the download; even if it were included, it would need to be updated anyway. As a result, it will take a long time to sync the tree for the first time, especially if you don't have your own local rsync server. While syncing will work eventually, if you would like to speed it up significantly for this first time, you can download a current portage snapshot instead, unpack it, and then run the sync; instructions are in the Gentoo Handbook, under Installing Portage. Make sure you unpack it in the /usr directory, instead of the one listed in the instructions.

NTP timeserver

You can use the default time server listed, which will rotate between several different servers automatically, or edit this file to add your own choice(s):
nano /etc/ntpd.conf
By default, the NTP server doesn't listen on any ports or allow other hosts to synchronize their time with it, as a security measure. Note: occasionally you may see that the time isn't correctly set, especially if you have had your build environment suspended (not actually running in VMWare). You may tell the NTP server to restart (when the configuration will cause the time to be reset) by running this command:
/etc/init.d/ntpd restart

Updates

After you have configured the base environment, you should update it with newer software versions, fixes for security vulnerabilities, etc., like any other Gentoo system:

emerge –-sync     # not needed if run earlier that day in the build environment
emerge -aD --update --tree world

Make sure when you update configuration files (like with etc-update or other means) that you don't accidentally overwrite the important configurations you need for your system to function. You should periodically do these update commands, to ensure the base system run current versions of software. It's a good idea to take VMWare snapshots of the Fireball appliance before major changes, to help you to restore quickly from unexpected problems. You should occasionally back up the whole VMWare appliance as an additional safety measure; snapshots are not the same as backups.


Build environment configuration

Most of your customization work will likely be inside the path that holds the files that will become the generated Fireball bootable ISO (what we'll call the "build environment"). Most of the time, you'll need to chroot into it. Simply run this command:

/root/setup_chroot.sh
and you'll be working inside the /root/livecd/source dir as if you had booted into a Gentoo machine with that path as the root directory.

When you're done working in the build environment, exit the chroot by running the following commands:

exit
/root/run_after_exiting_chroot.sh
The last command will restore the previous environment; if it's not restored properly, problems may occur. (Note: for quick edits to specific files in the build environment, you can access the files without chrooting first by finding them in /root/livecd/source/[path/filename] - this is what we did in the optional section above. Make sure that you don't get confused and start changing files in the base environment when you meant to change them in the build environment.)

Run the commands below after chrooting into the build environment with the setup_chroot.sh script.

Set your root password (build)

You'll need to change the root password again, but this time it is in the build environment. It's up to you whether or not to use the same password as in the base environment, though you're encouraged to make them different.
passwd
Again, this should be kept safe, so no unauthorized individuals can log in to the system. This is only a partial protection; enable encryption below (during the build process) for more complete protection of your data.

IP address (build)

Configure your IP address for the build environment; of course, this won't be active until you actually generate the ISO and boot it up. Use /usr/share/doc/openrc*/net.example.bz2 as a reference (where openrc* is the directory corresponding to the current version of openrc installed in the system.

nano /etc/conf.d/net
Note: the default setup lists eth0 as the internal interface, and eth1 (also called ppp0) as the external interface (plugged into the DSL modem); be aware that there is no /etc/init.d/net.eth1, but there is a /etc/init.d/net.ppp0. If you have more interfaces or need a different setup, you'll need to make the appropriate changes.

PPP setup

Fireball assumes that you use DSL for your Internet network connection; while you're editing /etc/conf.d/net, add your username and password for your Internet Service Provider (ISP) to that file to allow connection when the Fireball ISO boots up.

If you don't use DSL, you'll need to configure your Internet connection appropriately. The Gentoo documentation links mentioned above should help you as needed.

DNS servers (build)

If desired, edit /etc/resolv.conf and replace the existing OpenDNS IP addresses with other server IPs (like, for example, the DNS servers of your ISP, or whatever other ones you prefer). If you choose to use the OpenDNS ones, you might wish to see the OpenDNS website for information on additional features that may be useful.

Note: the DNS servers in this file might be replaced automatically with your ISP's DNS servers, depending on how it assigns you an IP address when your Fireball ISO boots up. If you want to prevent this file from being overwritten with other values from your ISP, remove the usepeerdns line from the /etc/conf.d/net file.

Host name (build)

Set the host name & domain name - replace "fireball" with the name of your server:

nano /etc/hosts
nano /etc/conf.d/hostname

SSH server keys (build)

Generate new keys for your SSH server:

/usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
/usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
/usr/bin/ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N ''

DHCP & DNS cache config

Here we will modify the configuration for the DNS cache server (which provides DNS lookups to your network and caches them for quick replies). The same program can also provide DHCP services if you like.

nano /etc/dnsmasq.conf

Set your local timezone (build)

I set my timezone to my local one, but others may wish to use UTC; it's up to you.

ls /usr/share/zoneinfo
This uses CST6CDT as an example; replace with your desired timezone:
cp /usr/share/zoneinfo/CST6CDT /etc/localtime
Add your timezone name to these files:
nano /etc/profile          # set the TZ variable to your timezone name

Gentoo rsync and update servers (build)

Set these up in /etc/make.conf, similar to the base environment. However, the rsync one is optional; since the base environment and build environment share the same /usr/portage/* directories, if you sync in one, the other will not need sync again that day. If you always sync in the base environment, you won't need to have an rsync server configured inside the build environment.

NTP timeserver (build)

You can use the default Gentoo NTP servers, or edit this files and add others:

nano /etc/ntpd.conf
By default, the NTP server doesn't allow other hosts to synchronize their time with it.

IPTables & IP6Tables rules (build)

The firewall rules for the build environment are contained in scripts that are in the iptables and ip6tables files below; this allows those who might not be very familiar with iptables syntax to edit a config file and run the scripts (automatically at boot, or whenever you manually restart one or both) to generate the firewall rules.

Edit the firewall rule config files (in the conf.d directory) to customize your firewall rules for both IPv4 and IPv6. You may wish to exclude certain kinds of harmless traffic from being logged, if such traffic is between hosts on the local network. Of course, you should balance this with the potential of possibly missing indications of attacks.

For IPv4:

nano /etc/conf.d/iptables     # This defines variables for the iptables script below
nano /etc/init.d/iptables
For IPv6:
nano /etc/conf.d/ip6tables    # This defines variables for the ip6tables script below
nano /etc/init.d/ip6tables

To clear and reload the firewall rules, and/or apply any changes to configuration options, run /etc/init.d/iptables restart and/or /etc/init.d/ip6tables restart as needed.

Note: the scripts and associate config files can be easier to modify than typing out iptables rules, say, for port forwarding or other complex situations ; however,they add the rules one at a time, which is much slower than the iptables native rule format (which is used by the base environment). If you plan on having a large number of rules, you should consider saving your rules in the iptables native format, and using the iptables.original and ip6tables.original files in the above directories (and the corresponding files in the /etc/conf.d directory as well), instead of the iptables and ip6tables files, respectively. Look at the files in the base environment to see how it was done there.

Kernel configuration

You should be able to use the virtual appliance on any hardware, thanks to the VMWare hardware emulation. However, the Fireball ISO LiveCD that is generated from the build environment needs to have drivers for whatever hardware that you will use to run it, so you may have to configure and compile the kernel. You will need to decide whether to configure the kernel manually or use a program that will automatically configure and compile the kernel.

If you're not very familiar with compiling a Linux kernel to run on your hardware, you may find it easier to use the genkernel program to compile your kernel.

Advantages of using genkernel

Disadvantages of using genkernel

The kernel configuration used in compiling the host environment and build environment kernels are in the /root directory of each environment – you can load and modify these to generate your own customized kernel if you like. Follow the instructions in the Gentoo documentation pages.

If you want to manually compile the kernel, skip to here

To use genkernel to compile kernel:
# suggested options: don't save kernel config to /etc/kernels
# (assumes you back it up yourself - Fireball has its backup configs in /root), 
# don't run "make clean" or "make mrproper" (use existing .config),
# copy new kernel to grub bootloader,
# and add support for LUKS encryption 
genkernel --no-save-config --no-clean --no-mrproper --bootloader=grub --luks all

To manually compile kernel: (encryption is not supported)
# change to the directory that holds the kernel
cd /usr/src/linux

# optional; you can change the kernel configuration if needed
make menuconfig

# build kernel & modules
make && make modules_install

# copy the new kernel to the boot directory - it can be whatever name you like
cp arch/x86/boot/bzImage /boot/[name of kernel]

# build initramfs used in booting up the LiveCD - genkernel is only used for this
genkernel initramfs

Note: if you've cleaned /var/cache/*, you might get an error here, regarding busybox and/or genkernel source code being missing. To solve this, just re-emerge them and re-run genkernel:

emerge -a busybox genkernel
genkernel initramfs

Note: with newer versions of grsecurity, it's no longer a problem to have the CONFIG_PAX_MEMORY_UDEREF kernel option (in the Security options -> PaX -> Miscellaneous hardening menu) enabled for kernels being run in some hardware-assisted virtual environments. This option is now recommended for all environments; as with all options, do your testing with your own hardware to be sure.

Grub Setup

# add the new kernel and initramfs to the grub config, and make any changes needed
nano /boot/grub/menu.lst
Note: if you intend to use encryption in the generated ISO, you will need a few different options in the kernel line in your grub config than if you weren't using encryption. For example:
# without encryption (split into two lines for readability)
kernel /boot/[kernel name] root=/dev/ram0 real_root=/dev/loop0 
 looptype=squashfs loop=/livecd.squashfs udev nodevfs cdroot dodmraid

# with encryption (split into three lines for readability)
kernel /boot/[kernel name] root=/dev/ram0 init=/linuxrc 
 ramdisk=8192 crypt_root=/dev/loop real_root=/dev/mapper/root looptype=squashfs 
 loop=/livecd.squashfs udev nodevfs cdroot dodmraid

Updates (build)

As needed, you should update the build environment with new software versions, fixes, etc., like any other Gentoo system. You should consider creating a new ISO after significant updates.

emerge –-sync     # not needed if already run today in the base or build environment
emerge -aD --update --tree world
Make sure when you update configuration files (like with etc-update or other means) that you don't overwrite the important configurations you need for your system to function. Regular backups (and VMWare snapshots) are important, so you can easily restore from unexpected problems.

Optional: IPv6 Internet connectivity

IPv6 support is already built into the kernel, so you can use this with the autoconfigured IPv6 local address to access Fireball from your local network without any additional configuration. If you'd like to provide all your IPv6-ready hosts on your network with globally-routable IPv6 addresses, to reach the growing number of IPv6 services on the Internet, you can get an account at one of the free tunnel brokers, and run their software.

These tunnel brokers provide a tunnel from the machine running the Fireball ISO to the broker's servers, through your normal (IPv4) Internet connection, which allow you to reach the Internet using IPv6 as well as IPv4. Gogoc is a version of the client previously called gateway6 or Freenet in Gentoo, and is already installed, so if you'd like to use it, get a free account at gogonet.gogo6.com and edit the config file:

nano /etc/gogoc/gogoc.conf

Changes to make:

  • Add your userid and password.
  • Make sure the host_type is set to "router".
  • Set if_prefix to the network interface that is facing your internal network.
  • You might need to change the tunnel_mode to v6anyv4 or perhaps some other option.
  • You can change the log options if desired. It's good to turn on maximum logging (option 3) while you're figuring things out, but once things are working fine, it's better to set it to minimal logging (option 1).

If you want the gogoc IPv6 functionality to start automatically, run the following command:

rc-update add gogoc default
If you prefer, you can start the tunnel manually instead of automatically:
/etc/init.d/gogoc start    # use "restart" or "stop" to restart or stop the server
While this is running, other IPv6-enabled computers in the network will automatically be given public IPv6 addresses with which they can communicate to the Internet through the tunnel. Of course, they will also be able to use whatever IPv4 connections they have as well.

Note: if you use the gogoc tunnel broker, the network interface carrying the IPv6 traffic in and out of your network will depend on the tunnel configuration; for my setup, I use the v6udpv4 tunnel, so my tunnel interface is called tun. Your ip6tables rules should use that interface name for any filtering you want to do on that interface.

Note: The gogoc tunnel may go down at times, due to intermittent connectivity issues or other temporary problems. If you want the service to be monitored and restarted automatically, you can add a cronjob to do this automatically. To load the current crontab for root into the default editor for modification, run the command:

crontab -e -u root
and copy/paste something like the following line into the editor, then save it:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /sbin/ifconfig tun >/dev/null 2>&1 || 
/usr/local/sbin/restart_gogoc.pl >/dev/null 2>&1
(These lines are only broken up for readability, and really should be on the same line.) As written, this will check every 5 minutes to see if the tun interface is up (substitute the interface you use for your tunnel broker service), and runs the restart_gogoc.pl script to restart the service if needed. Of course, you can change the interval or the restart script as needed.

Remove unnecessary packages

Since the Fireball ISO is intended to be a security product, you should remove things that you don't need in order to reduce the potential threats to your network. However, if you're using the appliance for another purpose, your needs will dictate the packages that you install, but that is outside the scope of this document. You can remove any software packages that you don't think you'll be using with:

emerge --unmerge [package name]
For example, if you're not going to be using the gogoc tunnel broker software, consider removing it. For features built into the kernel that you don't need (like support for DSL, if you don't use DSL), you'll have to recompile the kernel to remove them. It's worth the trouble to remove any features that you won't be using, since it will help your system be more secure by reducing the potential attack area. To be safe, consider making a VMWare snapshot before doing significant changes, or ones that you're not sure about.

Customization

Feel free to customize the Fireball build environment how you see fit. This can be as flexible as a regular Gentoo Linux installation; documentation exists on the Internet for most things that you would like to do. If you'll be using the generated ISO as a security device, you should consider limiting the programs you add in order to reduce the possible vulnerabilities that the system could have.
If you have questions or problems with any of the software in the build environment, please consult the documentation and the authors of the programs.

Building the Fireball LiveCD

While inside the chrooted build environment:

cd /root
./clean.sh
The above script generates a list of files such as compilers, source code files, and many more things that are unneeded on the ISO; files contained in this list are removed by the build script before the ISO is assembled. You may need to change the script if you're using the generated ISO for something other than a firewall device. After running the clean script, leave the build environment chroot and restore the base environment:
exit
/root/run_after_exiting_chroot.sh
Now build the Fireball ISO.
/root/build_cd.sh

A simple overview of the build process: the files from /root/livecd/source/* are copied to /root/livecd/target/*, excluding many unnecessary directories and files to speed things up. More aggressive file removals are done inside /root/livecd/target, and a squashfs file is generated from the files in that directory hierarchy. If encryption is needed, additional commands are manually run to move the squashfs file into an encrypted container, with a user-specified passphrase. The ISO is then built, containing the squashfs file system.

Optional Encryption

If you don't need encryption, skip to the Build the ISO section.

To support the optional encryption, the build_cd.sh script generates the appropriate commands, setting Bash enviroment variables along the way. You will need to copy/paste the commands to run them, in the order specified. Some commands just show information, or test that the squashfs file was transferred correctly to the encrypted container, and that it can be mounted successfully.

A description of the encryption process:
# start in the right directory
cd /root/livecd/target

# define space for encrypted container, where [SIZE] is the size of the 
# squashfs file (in 512-byte blocks) + 2056 for LUKS overhead
dd if=/dev/zero of=livecd.squashfs.encrypted.img bs=512 count=1 seek=[SIZE]

# associate an available loop device (like /dev/loop) with the container file
losetup [loop device] livecd.squashfs.encrypted.img

# create the LUKS container - answer YES and enter your chosen passphrase twice 
cryptsetup -y luksFormat [loop device]

# open the newly-created container, with the passphrase
cryptsetup luksOpen [loop device] root

# copy the squashfs file to the container
dd if=/root/livecd/target/livecd.squashfs of=/dev/mapper/root bs=512

# mount the container to make sure the squashfs file was copied correctly
# - if directories aren't listed, you may need to run the cryptsetup and losetup 
# commands below, and start over with the commands; you might need to re-run the 
# build script to generate another squashfs file before you run the commands again
mkdir /mnt/test/
mount /dev/mapper/root /mnt/test/
ls -l /mnt/test/
umount /mnt/test/
rmdir /mnt/test/

# close the container
cryptsetup luksClose /dev/mapper/root

# delete the loop device association
losetup -d [loop device]

# overwrite the old squashfs file with the encrypted container
mv livecd.squashfs.encrypted.img livecd.squashfs

Build the ISO (changed in 1.3)

Whether or not you use encryption, you need to copy/paste the final commands to build the ISO; these are listed at the end of the commands printed by the build script. In previous versions of Fireball ISO, these steps were run automatically by the script; now, they are only printed, so you must manually run them.

cd /root/livecd/
time mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table 
 -iso-level 4 -hide-rr-moved -c boot.catalog -o livecd.iso -x files ~/livecd/target/

The build process may take 10 minutes or longer, depending on the speed of your computer, with more time needed if it's the first time you've built an ISO in this appliance (or if you've recently cleared the /root/livecd/target directory). The generated ISO will be placed in /root/livecd/livecd.iso, ready for copying and burning as needed.

Note: The build process is a somewhat inefficient, and there's certainly room for improvements in the methods used, as well as in the size of the resulting ISO. However, it works fine for me, and I haven't heard any complaints about it; perhaps people are happy about the flexibility provided, even if it's a bit messy. As a result, I haven't felt the need to clean things up. Feel free to experiment if you like, but be sure to make snapshots or backups so you can easily restore if something goes horribly wrong.

Testing the Fireball ISO

If you want to test a version of the ISO before burning it to a CD, the ISO can be booted in a new VMWare virtual machine easily. Some obvious things may not work when testing in a virtual machine (like the PPP/DSL setup), and of course the hardware will be different, but it should give you a good idea about whether most things work as you'd like, or whether a new ISO will even boot; this is a good idea after major changes, especially after adding encryption for the first time. As with any host, you should give this test version a different IP address than anything else on your network, so that you don't confuse machines on your network with duplicate IP addresses.

If you like, you can make modifications to configurations inside this test machine, and see how things work (though you'll be unable to compile anything here, since all compilers are removed). For any changes you want to keep, you'll need to make the same changes in the Fireball appliance build environment.

Making copies of your Fireball virtual appliance

If you want to make copies of the entire virtual appliance (definitely recommended for backups), here's some ways to reduce its size and allow it to compress even smaller:

Feel free to share any useful techniques you find.

Security Reminders

You are solely responsible for the security of your computers and network. The Fireball system can be a part of your security plan, but must not exclusively be relied upon to provide complete security. A good security plan can include regular system updates on all machines in your network (including your Fireball ISO LiveCD), complex passwords, network and host intrusion detection and prevention systems, network and host firewalls, virus scanners, anti-spyware programs, user training, policy auditing, and so on.

Update Fireball regularly by updating the software packages in both the base and build environments, and generate a new LiveCD. Since this system will become out of date as time goes on, updating it will provide you with the latest program versions, including bug and security fixes. Having said that, though, updating or otherwise modifying the system also introduces the risk of adding new bugs or problems. You should make backups before introducing significant changes, and test those changes to make sure they work as desired.

Read system logs for signs of system problems, attacks, or compromises. Security books, email lists, and Google can help here.

Tweak firewall settings as needed to both protect your network and allow your supported network activities. Remember that there are two firewalls: iptables (for IPv4) and ip6tables (for IPv6). Each has its own set of rules, which may need to change over time.

Troubleshooting

Build errors

General testing

You're encouraged to test ISOs in a virtual machine as noted above. Virtual testing may save you many CDs, and allow you to tweak things until you're satisfied.

NIC interface changing for appliance copies

If you make a copy of the appliance, and change the virtual machine ID, you will find that the virtual network interface card (NIC) will change (for example, from eth0 to eth3) If you want the NIC to still be eth0, you can either delete the /etc/udev/rules.d/70-persistent-net.rules file, or edit it and put the current MAC for the existing NIC in a line describing eth0, then reboot. The easiest method is to delete the entire file:

rm /etc/udev/rules.d/70-persistent-net.rules
Then reboot the virtual machine:
shutdown -r now

Credits

"Gentoo" is a trademark of Gentoo Foundation, Inc. It is actively used, developed and maintained by lots of smart, passionate, and friendly people around the world.

The programs used in Fireball ISO are governed by their applicable licenses, viewable through their man pages or other documentation.

This Fireball ISO documentation is based in part on http://www.gentoo.org/doc/en/gentoo-x86-quickinstall.xml, and is also licensed under Creative Commons.

The IPv6 firewall rules are partially based on those in RFC4890.