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.
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:
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).
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.
Note: this will cover a very basic setup. For more details, please refer to the Gentoo documentation links above.
Start the virtual machine, and log in as
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).
The first thing you need to do is change the password of the base environment.
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).
I set my timezone to my local one, but others may wish to use UTC; it's up to you.
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)
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.
OpenDNS servers are already configured as the DNS servers. If you prefer, edit
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.
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
# listen on this local IPv4 address ListenAddress 192.168.2.1 # listen on this local IPv6 address ListenAddress fe80::20c:29ff:feae:4631%eth0Note: 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 restartThen check that the ssh server is only listening on the IP address(es) that you specify:
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 tableYou 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.
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
For a list of Gentoo update servers, run this and choose a few servers:
mirrorselect -i -o >> /etc/make.confFor the Gentoo rsync server, run this and choose one server:
mirrorselect -i -r -o >> /etc/make.confNow edit the /etc/make.conf, check the lines added at the end, and remove any duplicate SYNC or GENTOO_MIRROR lines above these.
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.
grep SYNC /etc/make.conf >> /root/livecd/source/etc/make.conf grep GENTOO_MIRROR /etc/make.conf >> /root/livecd/source/etc/make.confThen edit the file to remove duplicate SYNC or GENTOO_MIRROR lines if needed
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
under Installing Portage. Make sure you unpack it in the
/usr directory, instead of the one listed in the instructions.
nano /etc/ntpd.confBy 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:
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
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.
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.shand you'll be working inside the
/root/livecd/sourcedir 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.shThe 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
passwdAgain, 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.
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/netNote: the default setup lists
eth0as the internal interface, and
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.
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.
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
Set the host name & domain name - replace "fireball" with the name of your server:
nano /etc/hosts nano /etc/conf.d/hostname
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 ''
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.
dhcp-range, and put in the address range that you'd like to use.
dhcp-hostline for them. Look at the existing examples in the file to see several ways you can do this.
/etc/hostsand add each host name and corresponding IP address.
I set my timezone to my local one, but others may wish to use UTC; it's up to you.
ls /usr/share/zoneinfoThis uses
CST6CDTas an example; replace with your desired timezone:
cp /usr/share/zoneinfo/CST6CDT /etc/localtimeAdd your timezone name to these files:
nano /etc/profile # set the TZ variable to your timezone name
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
/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.
You can use the default Gentoo NTP servers, or edit this files and add others:
nano /etc/ntpd.confBy default, the NTP server doesn't allow other hosts to synchronize their time with it.
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
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.
nano /etc/conf.d/iptables # This defines variables for the iptables script below nano /etc/init.d/iptablesFor 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,
/etc/init.d/iptables restart and/or
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
ip6tables.original files in the above directories
(and the corresponding files in the /etc/conf.d directory as well), instead of the
ip6tables files, respectively. Look at the files in the base environment to see how it was done there.
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
Disadvantages of using
genkerneldefaults, you might have to manually configure the kernel anyway.
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 hereTo use
genkernelto 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
# 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
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.
# add the new kernel and initramfs to the grub config, and make any changes needed nano /boot/grub/menu.lstNote: if you intend to use encryption in the generated ISO, you will need a few different options in the
kernelline 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
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 worldMake 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.
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:
Changes to make:
if_prefixto the network interface that is facing your internal network.
v6anyv4or perhaps some other option.
If you want the gogoc IPv6 functionality to start automatically, run the following command:
rc-update add gogoc defaultIf 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 serverWhile 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
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 rootand 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.
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.
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.
While inside the chrooted build environment:
cd /root ./clean.shThe 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.shNow build the Fireball ISO.
A simple overview of the build process: the files from
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.
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
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
/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.
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:
/root/livecd/target/*directory; they will be created again when you build the next ISO, though the build will take a little longer.
rm -rf /root/livecd/target/*
rm -f /root/livecd/livecd.iso
rm -rf /usr/portage/*
rm -rf /root/livecd/source/var/cache/*
rm -rf /var/cache/* # Optional; perhaps some slight risk here
cat /dev/zero > /root/zeros.bin; sync; sleep 1; sync; rm -f /root/zeros.binWhen you're ready, shut down the virtual machine
shutdown -h now
Exit whatever VMWare program you use.
*.lockfiles inside the directory containing the virtual appliance - these aren't needed.
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.
/root/run_after_exiting_chrootone or more times (it may take multiple times), until you get umount errors with paths "not mounted". Then run the build script again.
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.
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
/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.rulesThen reboot the virtual machine:
shutdown -r now
"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.