FreeBSD 13.2: Comprehensive Home Server Setup with OpenZFS, IPFW, Ports, Jails, Mediawiki, Nginx, and Remote Access

Use Case Setup

I have a LocalWiki installed on my home network that I frequently use to create drafts. However, I also want to be able to access it remotely when I'm out and about. To achieve this, I plan on using an SSH tunnel.

While Ubuntu/Linux LXD-LXC containers do allow for the container to have both a public and private IP address, I've encountered some issues with accessing the Wiki. Specifically:

• I am unable to connect to the Public IP of the Wiki from the server (i.e., the box hosting the container). I can only access the Wiki via its private IP.
• I am unable to connect to the Wiki from the private IP when using a different box than the one hosting the container.(unless i always use SSH Tunneling)
• If I use a container with both a public and private IP, I can only set up Mediawiki's LocalSettings.php file to forward to one of the IPs.

After being away from FreeBSD for over 5 years, I've decided to switch back to it as I believe it will be a better fit for my needs.

Can access the Wiki from the Public IP on Both the server(box) hosting and other devices connected to my network.

Check updates for Base system

• Check for updates:

freebsd-update fetch

• freebsd-update fetch downloads the latest updates for the FreeBSD base system, including any security patches or bug fixes that have been released since the last update.

• If there are any update's install with:

freebsd-update install

• freebsd-update install installs the downloaded updates onto the system, making any necessary changes to the operating system files to apply the updates. This command may also prompt the user for any necessary configuration changes or to restart any services that were affected by the update.

It is important to regularly update the FreeBSD base system using these commands to ensure that the system is secure and stable, and to avoid any potential security vulnerabilities that could be exploited by attackers.

Allowed root to login with ssh

This is not really recommended as its best to use a username and just switch to root user using sudo but i have not yet configured and installed sudo (want to build sudo with insults) and will be doing the rest of the setup headless from my laptop (After i setup the firewall, Do Not setup Firewall with remote connection unless your are next to the server - a mistake can lock you out of server).

• Permit Root SSH Login
  • By default FreeBSD does not allow root to login using SSH
  • We change this by editing the sshd_config file:

$EDITOR /etc/ssh/sshd_config

In the Authentication section of the file:

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

• Change the line:
  • #PermitRootLogin no
• To
  • PermitRootLogin yes

Save and exit file

• Restart sshd for changes to take effect:
  • service sshd restart

Now we can login headless as root from another box

Firewalls

Important Note: Do not setup your firewall remotely, as you can lock yourself out if it goes wrong: Do and Test when you have access to the server.

A firewall is a security mechanism that monitors and controls incoming and outgoing network traffic based on predetermined security rules. It acts as a barrier between an internal network and external networks, such as the internet, and can prevent unauthorized access to a system or network.

FreeBSD has several firewall options available. Here are the most commonly used ones:

• IPFW (IP Firewall) - This is the default firewall in FreeBSD. It is a packet-filtering firewall that is integrated into the kernel. IPFW provides a flexible and powerful set of rules to filter and control network traffic.

• PF (Packet Filter) - This is another packet-filtering firewall that can be used on FreeBSD. PF provides more advanced features than IPFW, such as packet normalization, traffic shaping, and stateful packet inspection.

• IPF (IP Filter) - IPF is a third-party packet-filtering firewall that can be installed on FreeBSD. It provides a similar feature set to IPFW, but with a different syntax and configuration file format.

• NPF (NetBSD Packet Filter) - NPF is a new packet-filtering firewall that was introduced in FreeBSD 11. It is based on the NetBSD Packet Filter and provides a modern, modular architecture that allows for more flexible configuration and performance optimization.

Built-in Firewalls

FreeBSD comes with two built-in firewalls: IPFW and PF.

IPFW (IP Firewall) is the default firewall in FreeBSD. It is a packet-filtering firewall that is integrated into the kernel. IPFW provides a flexible and powerful set of rules to filter and control network traffic.

PF (Packet Filter) is also included in FreeBSD and can be used as an alternative to IPFW. PF provides more advanced features than IPFW, such as packet normalization, traffic shaping, and stateful packet inspection.

Note that while both IPFW and PF come preinstalled in FreeBSD, they are not enabled by default. You will need to configure and enable the firewall of your choice manually, depending on your specific needs and requirements.

Going to be using IPFW

Note for Later (can delete)

This is a clean install so IPFW should not be enabled, but still.

To check if IPFW is already installed on FreeBSD, you can use the kldstat command to list the currently loaded kernel modules. Here's how:

Open a terminal window on your FreeBSD system.

• Type the following command and press Enter:

kldstat | grep ipfw

• This command will search the list of loaded kernel modules for the string "ipfw". If IPFW is installed, you should see one or more lines of output that include the string "ipfw".

• If you don't see any output, IPFW is not currently loaded.

Alternatively, you can check if the IPFW binary is installed on your system by looking for the presence of the ipfw command in your system's sbin directory. Type the following command and press Enter:

ls /sbin/ipfw

If the command is found, you should see the path to the ipfw binary as the output. If it is not found, IPFW is not installed.

Note that on FreeBSD, IPFW is typically installed by default. If you don't have IPFW installed, you can install it using the pkg package manager(or ports).

IPFW - Basic Firewall Rules and how to setup

• Allow port 22
• Block in - Allow out
• Allow a Jail (will setup later) pass firewall

To configure IPFW on FreeBSD to block all incoming traffic, allow all outgoing traffic, and permit incoming traffic on port 22 for SSH, follow these steps:

Enable IPFW

• To enable IPFW, edit the /etc/rc.conf file and add the following lines:

firewall_enable="YES"
firewall_type="open"

What is the rc.conf file:

The rc.conf file is a system configuration file in FreeBSD that contains settings for various system services, options, and daemons. It is located in the /etc/ directory. The main purpose of rc.conf is to define how the system and its services should be configured during the boot process. The file contains a series of variable assignments in the form of key-value pairs, which are shell script syntax.

FreeBSD uses a series of scripts and configuration files during the boot process. These files are located in /etc/rc.d/ and /usr/local/etc/rc.d/. Each script in these directories represents a service, option, or daemon that can be enabled, disabled, or customized using the rc.conf file.

When the system boots, the /etc/rc script is executed. This script is responsible for reading the settings from rc.conf and initializing system services accordingly. It first sources the /etc/defaults/rc.conf file, which contains default values for various settings. Then, it sources the /etc/rc.conf file, which can override or supplement the default settings. This allows system administrators to customize the behavior of the system without modifying the default settings directly.

Here are some common settings found in rc.conf:

• hostname: Sets the system's hostname.
• ifconfig_<interface>: Configures network interfaces (e.g., ifconfig_em0="inet 192.168.0.2 netmask 255.255.255.0").
• defaultrouter: Specifies the IP address of the default gateway.
• sshd_enable: Enables or disables the OpenSSH server daemon (YES or NO).
• firewall_enable: Enables or disables the IPFW firewall (YES or NO).
• firewall_type: Defines the firewall type or points to a custom firewall script (e.g., open, closed, or /path/to/custom/script).

By modifying the rc.conf file, you can enable or disable services, configure network settings, set up firewall rules, and customize the system to meet your specific needs. After making changes to rc.conf, you will need to either reboot your system or restart the affected services for the changes to take effect.

firewall_type="type"

The firewall_type in the rc.conf file determines the predefined firewall configuration to be used by IPFW when it starts. There are several predefined firewall types available in FreeBSD, each with different levels of security and complexity. The most commonly used types are:

• open: No restrictions, allows all incoming and outgoing traffic.
• closed: Blocks all incoming traffic, allows outgoing traffic.
• client: A more permissive configuration that allows outgoing traffic and specific incoming traffic needed for regular client operation (e.g., DHCP, DNS, ICMP).
• simple: A basic configuration with some common rules to allow specific types of incoming traffic (e.g., SSH, HTTP, HTTPS, ICMP).
• workstation: A more secure configuration suitable for a typical workstation, allowing only specific incoming traffic and enabling stateful packet filtering for better security.
• UNKNOWN: A placeholder type that does not apply any rules, typically used as a starting point for creating custom firewall configurations.

When you use firewall_type="workstation", FreeBSD will apply the predefined "workstation" firewall configuration. This configuration is designed for workstations and provides a balance between security and usability. It allows only specific incoming traffic and enables stateful packet filtering.

If you prefer to use your custom firewall rules defined in the /etc/ipfw.rules file, you can set the firewall_type in the rc.conf file to UNKNOWN. This will tell IPFW not to use any predefined rules:

firewall_enable="YES"
firewall_type="UNKNOWN"
firewall_script="/etc/ipfw.rules"

Make sure the firewall_script directive points to your custom rules file. After making these changes, restart the IPFW service:

sudo service ipfw restart

Now, IPFW should use your custom rules in the /etc/ipfw.rules file when starting up. This should resolve any issues with the predefined firewall configurations conflicting with your custom rules.

Create a custom ruleset

Create a new file called /etc/ipfw.rules. This file will contain the IPFW rules for your custom configuration.

Edit the /etc/ipfw.rules file

• Add the following rules to your custom ruleset:

#!/bin/sh

# Flush existing rules
ipfw -q flush

# Allow loopback traffic
ipfw -q add 00001 allow all from any to any via lo0

# Allow established connections
ipfw -q add 01000 allow tcp from any to any established in

# Allow incoming SSH traffic on port 22
ipfw -q add 00100 allow tcp from any to any 22 in setup keep-state

# Allow all outgoing traffic
ipfw -q add 00200 allow all from any to any out keep-state

# Set default policies
ipfw -q add 10000 allow all from any to any out
ipfw -q add 20000 deny all from any to any in

# Log everything else
ipfw -q add 65000 deny log all from any to any

Explain IPFW and the ipfw.rules file/content like i am five::

IPFW is like a security guard for your computer that checks who is allowed to come in and go out. The security guard has a set of rules to follow, and the rules are numbered so that they can be followed in order.

The numbers you see are the rule numbers. They help the security guard (IPFW) follow the rules in the right order. Smaller numbers come first, and bigger numbers come later. So, the rule with number 100 comes before the rule with number 200.

Now, let's look at the options:

• add: This tells the security guard to add a new rule.
• <number>: This is the rule number, which decides the order of the rules.
• allow or deny: These options tell the security guard if the traffic should be allowed or denied (not allowed).
• all, tcp, or udp: These options tell the security guard what kind of messages to check.
• from any or from <IP address>: This tells the security guard where the messages are coming from.
• to any or to <IP address>: This tells the security guard where the messages are going to.
• in or out: This tells the security guard if the messages are coming in (to your computer) or going out (from your computer).

So, when you create a rule with a number and some options, the security guard (IPFW) follows the rules in the order of their numbers and checks the messages based on the options given. This way, your computer stays safe and only allows the messages you want!

Let's break down the contents of the ipfw.rules file.

• #!/bin/sh: This line tells your computer that this file is a set of instructions, like a recipe, that it should follow using a specific language called "shell script."

• ipfw -q flush: This line tells the security guard (IPFW) to forget all the old rules and start fresh.

• ipfw -q add 00001 allow all from any to any via lo0: This is rule number 1. It tells the security guard to allow all messages within your computer to talk to itself using a special path called "loopback."

• ipfw -q add 01000 allow tcp from any to any established in: This is rule number 1000. It tells the security guard to let messages come into your computer if they are part of an ongoing conversation. This way, your computer can talk to other computers without any problem.

• ipfw -q add 00100 allow tcp from any to any 22 in setup keep-state: This is rule number 100. It tells the security guard to allow messages coming into your computer only if they are using a special door called "port 22" (used for SSH) and keeps track of the conversation so it can manage it better.

• ipfw -q add 10000 allow all from any to any out: This is rule number 10000. It tells the security guard to let all messages go out of your computer.

• ipfw -q add 20000 deny all from any to any in: This is rule number 20000. It tells the security guard to stop all messages from coming into your computer that don't follow the previous rules.

• ipfw -q add 00200 allow all from any to any out keep-state: This is a new rule that tells the security guard to allow all messages from your computer to go out and talk to other computers. The security guard will also remember these outgoing messages so it can let replies come back in.

• ipfw -q add 65000 deny log all from any to any: This is rule number 65000. It tells the security guard to stop any other messages that don't follow the previous rules and make a note of them. This helps you know if someone is trying to send messages to your computer that they shouldn't be.

So, this ipfw.rules file is like a recipe for the security guard (IPFW) to follow. It helps protect your computer by allowing only the messages you want to come in and letting all messages go out.

The -q flag in ipfw -q stands for "quiet." When you use this flag with the ipfw command, it tells the command to run quietly, meaning it won't display any output or messages while executing the rules.

This is particularly useful when you're running a script that contains multiple ipfw commands. By using the -q flag, you avoid cluttering the terminal with unnecessary output, making it easier to read any important messages or errors that might appear.

Loopback lo0

The "loopback" is a special network interface in a computer's networking system. Its main purpose is to let the computer send messages to itself without using any physical network connection. This is useful for testing and troubleshooting various networking applications and services.

In the context of the ipfw.rules, "via lo0" refers to using the loopback network interface (lo0) as the pathway for messages.

Now, let's dive a little deeper into the loopback concept and its uses:

• Testing network applications: The loopback interface allows developers to test network applications and services without needing a physical network connection. For example, if you're building a web server, you can use the loopback interface to access the server from the same computer without needing an actual network.

• Troubleshooting: The loopback interface can be used to diagnose network issues. By sending a message to the loopback address, you can check whether your network stack is working correctly. If the message is successfully received, it means your network software is functioning properly.

• Localhost: The loopback interface is often associated with the IP address 127.0.0.1, which is also known as "localhost." Localhost is a hostname that refers to the current device used to access it. When you use "localhost" or "127.0.0.1" as the address, you're essentially telling your computer to send a message to itself via the loopback interface.

• Network isolation: Sometimes, you might want to run network applications or services that don't need to be accessible to other devices on the network. By using the loopback interface, you can ensure that these services are only available to your local machine, keeping them isolated from other devices.

For example, if you're running a database server on your computer for local development, you can bind it to the loopback address (127.0.0.1). This way, the database server will only accept connections from your computer, preventing other devices on the network from accessing it.

"setup" and "setup keep-state"

In IPFW rules, the 'setup' keyword is used to specify a particular type of TCP connection. It helps the IPFW firewall filter incoming TCP connections based on their state, and more specifically, it targets the initial stages of a TCP connection.

TCP, or Transmission Control Protocol, is a connection-oriented protocol used for reliable communication between devices on a network. When two devices establish a TCP connection, they go through a process called the "TCP three-way handshake." This handshake involves three steps:

• SYN (Synchronize): The client sends a packet with the SYN flag set, indicating a request to establish a connection with the server.
• SYN-ACK (Synchronize-Acknowledge): The server acknowledges the SYN request by sending a packet with both SYN and ACK flags set.
• ACK (Acknowledge): The client sends a packet with the ACK flag set, acknowledging the server's SYN-ACK, and the connection is established.

The 'setup' keyword in IPFW rules specifically targets the first step of the TCP three-way handshake (the SYN packet). When used in a rule like this:

ipfw -q add 00100 allow tcp from any to any 22 in setup keep-state

The 'setup' keyword tells the IPFW firewall to allow incoming TCP connections on port 22 (commonly used for SSH) only if the packet has the SYN flag set, meaning it's an attempt to establish a new connection. This helps the firewall filter out packets that don't initiate a proper TCP connection.

Additionally, the 'keep-state' option in the rule tells IPFW to track the state of the allowed connections. This way, the firewall can automatically allow subsequent packets related to the same connection without needing to match them against the rules again. This is useful for efficiently managing and filtering traffic on a per-connection basis.

Make the rules file executable

• Run the following command to make the /etc/ipfw.rules file executable:

chmod +x /etc/ipfw.rules

Modify /etc/rc.conf to use the custom ruleset

• Edit the /etc/rc.conf file again and change the firewall_type line to:

firewall_script="/etc/ipfw.rules"

If did not setup an IPv6 address when installing freebsd:

If you didn't set up IPv6 during the installation of FreeBSD and you want to ensure that IPFW doesn't initialize IPv6-related settings, you can disable IPv6 entirely by adding a few lines to your /etc/rc.conf file.

To disable IPv6, follow these steps:

Open the /etc/rc.conf file using a text editor. For example, you can use vi, nano, or ee.

$EDITOR /etc/rc.conf

• Add the following lines at the end of the file to disable IPv6:

ipv6_activate_all_interfaces="NO"

Save the changes and exit the text editor. If you're using vi, press Esc, then type :wq and press Enter.

Reboot your system for the changes to take effect:

reboot

After these steps, IPv6 will be disabled on your FreeBSD system. Consequently, IPFW will no longer initialize IPv6-related settings, which should also prevent the "divert loadable" message from appearing.

If you specifically want to disable IPFW for IPv6 only and leave IPv6 enabled, you can remove or comment out the lines related to IPv6 in the IPFW startup script, typically located in /etc/rc.d/ipfw. However, I recommend not modifying the startup script directly, as it might affect system stability or cause issues during updates.

My /etc/rc.conf file

clear_tmp_enable="YES"
hostname="nuc-bsd"
keymap="uk.kbd"
ifconfig_re0="DHCP"
sshd_enable="YES"
powerd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
#No IPv6 
ipv6_activate_all_interfaces="NO" 
# Firewall setup
firewall_enable="YES"
firewall_script="/etc/ipfw.rules"

Apply the new rules

• To apply the new rules, either restart your system or run the following command:

service ipfw restart

Small Error:

service ipfw restart Returns:

sysctl: unknown oid 'net.inet.ip.fw.enable'
sysctl: unknown oid 'net.inet6.ip6.fw.enable'
Firewall rules loaded.

The sysctl: unknown oid messages you see when restarting the IPFW service are warning messages indicating that the system cannot find the specified Object Identifiers (OIDs) in the sysctl configuration. Sysctl is a utility that allows you to configure kernel parameters at runtime, and OIDs are unique identifiers for kernel parameters.

In this case, the warning messages indicate that the OIDs net.inet.ip.fw.enable and net.inet6.ip6.fw.enable are not recognized. These OIDs are used to enable or disable the IPFW firewall for IPv4 and IPv6, respectively.

The reason you see these messages could be that the IPFW firewall is either not compiled into your kernel or is not loaded as a kernel module. In some cases, it might be a simple typo in the OID.

However, since the Firewall rules loaded. message is displayed after the warning messages, it indicates that the IPFW service is still running and the rules are being applied despite the warnings. The warnings are not critical, and your IPFW configuration should work as expected.

To suppress these warning messages, you can either:

Make sure that the IPFW firewall is compiled into your kernel or loaded as a kernel module. You can check if the IPFW kernel module is loaded by running kldstat | grep ipfw. If it's not loaded, you can load it with kldload ipfw.

Remove or comment out the lines related to the unknown OIDs in the IPFW startup script, typically located in /etc/rc.d/ipfw. However, I recommend not modifying the startup script directly, as it might affect system stability or cause issues during updates.

Now, your FreeBSD system will block all incoming traffic except for SSH on port 22 and allow all outgoing traffic.

Create User

To create an user account we use adduser

adduser

This will start the interactive user creation process.

Enter the new user's information

Follow the prompts to enter information about the new user named 'noob'. The important fields to fill out are:

• Username: noob
• Full name: (You can enter any full name, e.g., Noob Newbie)
• Uid: (Leave this blank for the system to assign one automatically)
• Login group: noob
• Login group is: noob
• Invite noob into other groups?: (Press 'Enter' to accept the default "no")
• Login class: (Press 'Enter' to accept the default "default")
• Shell: (Press 'Enter' to accept the default "/bin/sh", or choose another shell like "/bin/csh" or "/bin/tcsh")
• Home directory: (Press 'Enter' to accept the default "/home/noob")
• Home directory permissions: (Press 'Enter' to accept the default "755")
• Use password-based authentication?: (Press 'Enter' to accept the default "yes")
• Use an empty password?: (Press 'Enter' to accept the default "no")
• Use a random password?: (Press 'Enter' to accept the default "no")
• Enter password: (Type a secure password for the 'noob' user and press 'Enter')
• Enter password again: (Confirm the password by typing it again and pressing 'Enter')
• Lock out the account after creation?: (Press 'Enter' to accept the default "no")

Confirm the new user's information

After entering all the required information, adduser will display a summary of the new user's settings. Review the information to ensure it is correct, then type yes and press Enter to confirm and create the new user.

Verify the new user

To verify that the new user noob was created successfully, you can check the contents of the /etc/passwd file by running:

grep noob /etc/passwd

This command should display a line containing the new user's information, such as:

noob:*:1001:1001:User &:/home/noob:/bin/sh

Congratulations! You've successfully added a new user named noob to your FreeBSD system now lets install sudo and add are new user:

Install sudo with insults

Ports

If you haven't installed the Ports tree during the FreeBSD installation, you can do it using the portsnap utility. First, fetch the latest snapshot of the Ports tree:

portsnap fetch

After fetching the snapshot, extract it to /usr/ports:

portsnap extract

• Note: can also be done on one line: portsnap fetch extract

If you did install the ports tree during installation, update ports:

portsnap fetch update

Install sudo with insults enabled/configured

Why sudo with insults enabled? Because life must be enjoyed!

Navigate to the sudo port directory

First, change your working directory to the sudo port directory in the ports tree:

cd /usr/ports/security/sudo

Enable the INSULTS option

To enable the insults feature in sudo, you'll need to customize the port's options. Run the following command:

make config

This will open a text-based interface showing a list of options for the sudo port. Look for the "INSULTS" option, which should be unchecked by default. Use the arrow keys to highlight "INSULTS" and press the spacebar to enable it (an asterisk (*) will appear next to it). After that, press 'Enter' to save the configuration and exit.

Build and install sudo

Now that you've enabled the INSULTS option, you can build and install the sudo port by running:

make install clean

This command will compile sudo with the specified options and install it on your system. The process may take a few minutes, depending on your system's resources.

Configure sudo

After installing sudo, you need to configure it by editing the sudoers file. To do this safely, use the visudo command, which will open the sudoers file in your default text editor: Warning default $EDITOR will be vi Learn Basic vi first!

visudo

In the sudoers file, look for the line that defines user privilege specifications. It should look like this:

root ALL=(ALL) ALL

To grant your user account sudo privileges, add a new line with your username and the same format, replacing 'username' with your actual username:

• Syntax: username ALL=(ALL) ALL

noob ALL=(ALL) ALL

Save the file and exit the text editor.

Test sudo with insults

To test your newly installed sudo with insults enabled, login as your new user and try running a command that requires root privileges. For example:

• change to new user

su - noob

• use sudo as new user

sudo ls /root

If you enter an incorrect password, sudo should now respond with a random insult instead of the standard error message.

Congratulations! You've successfully installed sudo with insults enabled from FreeBSD 13.2 ports. Enjoy the amusing responses whenever you mistype your password.

Creating a Jail for a local mediawiki

Create a directory for the jail

In this example my ZFS Pool is called nuc and my jails directory will be in a directory called pods which will contain my jails each in a separate sub directory like so /pods/{jail1,jail2,jail3}

• Create a dataset for pods

sudo zfs create nuc/pods

• You can check with zfs list to see your new dataset.

Set the mountpoint for the pods dataset

sudo zfs set mountpoint=/pods nuc/pods

Create a Template Jail Which you can clone

In this section, we will create an OpenZFS dataset called FreeBSD_13.2_Template to extract a base.txz Which we will snapshot , and then clone the template to create a new jail.

Create the 'FreeBSD_13.2_Template' dataset

sudo zfs create your_pool_name/path/FreeBSD_13.2_Template

Replace your_pool_name with the name of your ZFS pool.

• Example:

sudo zfs create nuc/pods/FreeBSD_13.2_Template

Set the mountpoint for the template dataset

sudo zfs set mountpoint=/pods/FreeBSD_13.2_Template nuc/pods/FreeBSD_13.2_Template

Download the base.txz package for FreeBSD 13.2-RELEASE

fetch https://download.freebsd.org/ftp/releases/amd64/13.2-RELEASE/base.txz -o /tmp/base.txz

Extract the base.txz package to the 'FreeBSD_13.2_Template' dataset

sudo tar -C /pods/FreeBSD_13.2_Template -xf /tmp/base.txz

Create a snapshot of the template dataset

sudo zfs snapshot nuc/pods/FreeBSD_13.2_Template@base_snapshot

Clone the template dataset to create a new jail dataset

sudo zfs clone nuc/pods/FreeBSD_13.2_Template@base_snapshot nuc/pods/mediawiki

Set the mountpoint for the jail dataset

sudo zfs set mountpoint=/pods/mediawiki nuc/pods/mediawiki

You now have a template dataset and a jail dataset based on that template.

Configure the jail

Create a configuration file for your jail. The following example assumes you're using the jail utility provided by FreeBSD:

Edit /etc/jail.conf and add the following jail configuration:

• If /etc/jail.conf does not exist, create it with touch /etc/jail.conf

$EDITOR /etc/jail.conf

localwiki {
  host.hostname = "local.wiki";
  ip4.addr = "re0|192.168.0.33";
  path = "/pods/mediawiki";
  exec.start = "/bin/sh /etc/rc";
  exec.stop = "/bin/sh /etc/rc.shutdown";
  exec.clean;
  mount.devfs;
  allow.sysvipc;
  allow.raw_sockets;
}

• Replace
  • localwiki to what you would like your jail called
  • host.hostname = "<the_host_name_for_jail>";
  • ip4.addr = <ip_address_for_jail_to_use>;
    • "re0|192.168.0.33" where 're0' is my Network Interface Card (NIC).
      • You can find your Network Interface Card (NIC) by running the command ifconfig.
      • 192.168.0.33 is the IP address I want to assign to the jail within the 192.168.0.0/24 subnet of my network.
  • path = "</path/to/jail>";
    • The path where the jail resides (e.g., "/pods/mediawiki").

• NOTES:
  • allow.sysvipc: Allows System V IPC primitives to be used within the jail. This might be necessary for some PHP extensions or applications that rely on shared memory.
  • allow.raw_sockets: Allows raw sockets to be used within the jail. This might be required for certain PHP functions or extensions that use raw socket communication.

Allow jail pass firewall

To allow traffic to pass through IPFW for a FreeBSD jail with the IP address 192.168.0.33, you will need to modify the IPFW rules to allow incoming and outgoing traffic for this specific IP address.

Open the /etc/ipfw.rules file for editing

In this example my jails IP is 192.168.0.33

• Add the following rules to allow incoming and outgoing traffic for the jail's IP address (192.168.0.33):

# Allow incoming traffic for jail's IP (192.168.0.33)
ipfw -q add 00200 allow all from any to 192.168.0.33 in

# Allow outgoing traffic for jail's IP (192.168.0.33)
ipfw -q add 00210 allow all from 192.168.0.33 to any out

To correctly insert the rules for allowing traffic to and from the jail's IP (192.168.0.33) in your existing IPFW rules, you should place them between the "Allow established connections" rule and the "Set default policies" rules. This ensures that the jail's traffic is allowed before the default deny policy for incoming traffic is applied.

Here's the updated IPFW rules:

#!/bin/sh

# Flush existing rules
ipfw -q flush

# Allow loopback traffic
ipfw -q add 00001 allow all from any to any via lo0

# Allow established connections
ipfw -q add 01000 allow tcp from any to any established in

# Allow incoming SSH traffic on port 22
ipfw -q add 00100 allow tcp from any to any 22 in setup keep-state

# Allow all outgoing traffic
ipfw -q add 00200 allow all from any to any out keep-state

# Allow incoming traffic for jail's IP (192.168.0.33)
ipfw -q add 00200 allow all from any to 192.168.0.33 in

# Allow outgoing traffic for jail's IP (192.168.0.33)
ipfw -q add 00210 allow all from 192.168.0.33 to any out

# Set default policies
ipfw -q add 10000 allow all from any to any out
ipfw -q add 20000 deny all from any to any in

# Log everything else
ipfw -q add 65000 deny log all from any to any

This configuration allows incoming and outgoing traffic for the jail's IP (192.168.0.33) while maintaining the existing rules for other connections, such as allowing SSH traffic on port 22 and denying all other incoming traffic.

Apply the new rules

To apply the new rules, either restart your system or run the following command:

service ipfw restart

Now, your IPFW configuration will allow traffic to pass to and from the FreeBSD jail with the IP address 192.168.0.33.

Copy over your /etc/resolv.conf to jail

It is generally a good idea to copy the /etc/resolv.conf file from the host system to the jail's /etc/resolv.conf before starting the jail. This ensures that the jail has the same DNS resolver configuration as the host, allowing it to resolve domain names correctly.

/etc/resolv.conf is a configuration file used by the DNS resolver library on Unix-based systems, including FreeBSD. It contains information about the DNS nameservers and search domains to use when resolving domain names.

To copy the resolv.conf file from the host system to the jail, you can use the cp command:

cp /etc/resolv.conf /pods/mediawiki/etc/resolv.conf

Make sure to execute this command before starting the jail to ensure proper DNS resolution within the jail environment.

Start the jail

Start the jail using the jail utility:

jail -c localwiki

Replace localwiki with the name you chose in the jail configuration.

Access the jail

Enter the jail's environment with the jexec command:

jexec localwiki /bin/sh

• Replace localwiki with your jail name

You'll now be inside your jail, and you can manage it like any other FreeBSD system.

Notes: How to Exit - Stop - Restart - Delete: The Jail

• EXIT: To exit the jail enter exit press ENTER

• STOP JAIL

sudo jail -r your_jail_name

• START JAIL

sudo jail -c your_jail_name

• To RESTART the jail you turn it off and on again :)
  • or one line

sudo jail -r your_jail_name && sudo jail -c your_jail_name

• REMOVE JAIL
  • EXIT and STOP jail
  • you can now remove the jail directory and its contents:

rm -rf /path/to/jail

• If using OpenZFS destroy dataset

Don't forget to remove the corresponding jail configuration from /etc/jail.conf.

Create Local Mediawiki Jail

How to Install a Local mediawiki in a jail with Nginx and MySQL

Creating a jail to download and store mediawiki backups

• Remote Server running Ubuntu 22.04 hosting mediawiki to create a wiki dump
• Home jail to login to server and pull down backups for local storage

Creating jail using ZFS Clone

View the FreeBSD jails Page to setup a basic jail

sudo zfs clone nuc/pods/FreeBSD_13.2_Template@base_snapshot nuc/pods/wiki_backup

sudo zfs set mountpoint=/pods/wiki_backup nuc/pods/wiki_backup

Append jail.conf

/etc/jail.conf

wikibk {
  host.hostname = "backup.wiki";
  ip4.addr = "re0|192.168.0.34";
  path = "/pods/wiki_backup";
  exec.start = "/bin/sh /etc/rc";
  exec.stop = "/bin/sh /etc/rc.shutdown";
  exec.clean;
  mount.devfs;
}

Start jail and login

jail -c wikibk

jexec wikibk /bin/sh

Scripts to dump a backup of the wiki

• This script is for running on a Ubuntu 22.04 server running mediawiki
• Will store back at /var/wikibk by default

#!/bin/bash

# Define paths and filenames
mediawiki_root_dir="/var/www/html/noobs"
local_settings_path="/var/www/html/noobs/LocalSettings.php"
database_backup_filename="Noobs_db.sql.gz"
root_dir_backup_filename="mediawiki-rootDir.tgz"
backup_path="/var/wikibk" # Define your default backup path here

# Get the current timestamp
timestamp=$(date +"%Y-%m-%d_%H-%M-%S")
combined_backup_filename="mediawiki-transfer-${timestamp}.tgz"

# Get database details from LocalSettings.php
db_host=$(grep -oP "\$wgDBserver\s*=\s*'\K[^']*" "$local_settings_path")
db_name=$(grep -oP "\$wgDBname\s*=\s*'\K[^']*" "$local_settings_path")
db_user=$(grep -oP "\$wgDBuser\s*=\s*'\K[^']*" "$local_settings_path")
db_pass=$(grep -oP "\$wgDBpassword\s*=\s*'\K[^']*" "$local_settings_path")

# Set the wiki to read-only
sed -i "/^\$wgDBpassword/ a \$wgReadOnly = 'Dumping Database, Access will be restored shortly';" "$local_settings_path"

# Run mysqldump command using the extracted details
mysqldump -h "$db_host" --default-character-set=binary --no-tablespaces -u "$db_user" --password="$db_pass" "$db_name" | gzip > /root/"$database_backup_filename"

# Remove read-only mode
sed -i "/^\$wgReadOnly = 'Dumping Database, Access will be restored shortly';/d" "$local_settings_path"

# Back up MediaWiki root directory
tar cvzhf /root/"$root_dir_backup_filename" "$mediawiki_root_dir"

# Combine backup files into a single file for easy transport
cd /root/
tar cvzhf "$backup_path/$combined_backup_filename" "$root_dir_backup_filename" "$database_backup_filename"

• This Script will run in the jail to pull and save the backups
  • Will require an sshkey for server you are pulling from

#!/usr/local/bin/bash

# Set variables
local_backup_dir="/root/wiki-backups"
remote_user="root"
remote_host="completenoobs.com"
remote_backup_dir="/var/wikibk"
private_key_path="/root/key"

# Create the local backup directory if it doesn't exist
mkdir -p "$local_backup_dir"

# Create temporary files
local_tmp_file="/tmp/FILE1.txt"
remote_tmp_file="/tmp/FILE2.txt"

# List files in the local and remote backup directories to temporary files
find "$local_backup_dir" -mindepth 1 -maxdepth 1 -type f -exec basename {} \; | sort > "$local_tmp_file"
ssh -i "$private_key_path" "$remote_user@$remote_host" "find $remote_backup_dir -mindepth 1 -maxdepth 1 -type f -exec basename {} \; | sort" > "$remote_tmp_file"

# Compare the temporary files and download missing files using scp
while read -r remote_file; do
    if ! grep -q -F "$remote_file" "$local_tmp_file"; then
        scp -i "$private_key_path" -r "$remote_user@$remote_host:$remote_backup_dir/$remote_file" "$local_backup_dir/"
    fi
done < "$remote_tmp_file"

# Remove temporary files
rm "$local_tmp_file"
rm "$remote_tmp_file"

Cron to run script to check for new dumps twice a day

crontab -e

• Append:

0 */12 * * * /bin/sh /root/wikibk.sh

• Make sure the /root/wikibk.sh script is executable by running:

chmod +x /root/wikibk.sh

FireWall

Note: Are firewall rules already allow for connections to go out, we do not need anything from outside are jail connecting to are back up jail. so no need to mod the firewall rules.

Jail for SSH Tunnel To Remote Access Local Wiki

This guide provides a brief introduction on how to set up a secure SSH tunnel to access and edit your local wiki, hosted on a home network using a FreeBSD-based system running on a NUC. The local wiki is hosted within a FreeBSD jail with the IP address 192.168.0.33. To securely access this wiki when you're outside your home network, we'll create another jail that will act as an intermediary for SSH tunneling. By following this guide, you'll be able to create a new jail for tunneling and configure it to allow you to view and edit your local wiki remotely.

To achieve this, we will take the following steps:

• Set up a new jail using ZFS Clone.
• Configure the new jail's jail.conf file.
• Start the new jail and log in.
• Create a user for login purposes.
• Set up the user's SSH authorized_keys file.
• Restrict the SSH key for tunneling only.
• Configure the SSH server on the new jail.
• Set up port forwarding on your router.
• Append firewall rules to allow connection to the new jail.
• Access your local wiki through the SSH tunnel.

By following these steps, you can securely access your local wiki from outside your network using an SSH tunnel, allowing you to view and edit your wiki content while you're on the go.

Creating jail using ZFS Clone

View the FreeBSD jails Page to setup a basic jail

sudo zfs clone nuc/pods/FreeBSD_13.2_Template@base_snapshot nuc/pods/remote_view

sudo zfs set mountpoint=/pods/remote_view nuc/pods/remote_view

Append jail.conf

/etc/jail.conf

remotewiki {
  host.hostname = "remote.wiki";
  ip4.addr = "re0|192.168.0.35";
  path = "/pods/remote_view";
  exec.start = "/bin/sh /etc/rc";
  exec.stop = "/bin/sh /etc/rc.shutdown";
  exec.clean;
  mount.devfs;
}

Start jail and login

jail -c remotewiki

jexec remotewiki /bin/sh

Create user with for login

adduser

• note: tried with nologin shell and could not get to work - need a real shell (like sh)

Username: remote
Full name: 
Uid (Leave empty for default): 
Login group [remote]: 
Login group is remote. Invite remote into other groups? []: 
Login class [default]: 
Shell (sh csh tcsh nologin) [sh]: 
Home directory [/home/remote]: 
Home directory permissions (Leave empty for default): 
Use password-based authentication? [yes]: 
Use an empty password? (yes/no) [no]: 
Use a random password? (yes/no) [no]: 
Enter password: 
Enter password again: 
Lock out the account after creation? [no]: 
Username   : remote
Password   : *****
Full Name  : 
Uid        : 1001
Class      : 
Groups     : remote 
Home       : /home/remote
Home Mode  : 
Shell      : /bin/sh
Locked     : no
OK? (yes/no): yes
adduser: INFO: Successfully added (remote2) to the user database.
Add another user? (yes/no): no
Goodbye!

Setup user ssh authorized_keys

As the user 'remote' is using the nologin shell su - remote will not work, so with 'root'

• create a .ssh directory

mkdir /usr/home/remote/.ssh

• copy over the authorized_keys file

• and now change/check permissions for both directory and authorized_keys

chmod 700 /usr/home/remote/.ssh

chmod 600 /usr/home/remote/.ssh/authorized_keys

chown -R remote:remote /usr/home/remote/.ssh

Set up your restricted authorized_keys file in the remotewiki jail

• Add your public key to the ~/.ssh/authorized_keys file in the remotewiki jail for the user you'll be using to connect.
• To restrict the SSH key to tunneling only, add the following options at the beginning of the line containing your public key in the authorized_keys file:

no-agent-forwarding,no-X11-forwarding,no-pty,permitopen="192.168.0.33:80"

Example: authorized_keys file

no-agent-forwarding,no-X11-forwarding,no-pty,permitopen="192.168.0.33:80" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ<LONG SSH PUB KEY>

This will prevent any other SSH features except for tunneling to the specified port.

Configure the SSH server on the 'remotewiki' jail

• Ensure that the SSH server is running and enabled on the remotewiki jail. You can check if it's running using the command service sshd status. If it's not running, you can start it with service sshd start and enable it at boot using sysrc sshd_enable="YES".

sysrc sshd_enable="YES"

• Start sshd to create a host key file:

service sshd start

Configure the SSH server to only allow key-based authentication by editing the /etc/ssh/sshd_config file. Look for the following lines, and make sure they are set as shown below (uncomment them if necessary):

• Can append to bottom of file:

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AllowTcpForwarding yes

• After making changes to the sshd_config file, restart the SSH server using the command:

service sshd restart

Set up port forwarding on your router

• Access your router's administration panel, usually by typing your router's IP address into a web browser.

Look for the port forwarding settings, often called "Port Forwarding" or "Virtual Servers".

Create a new port forwarding rule that forwards an external port (e.g., 2222) to the IP address of your remotewiki jail (192.168.0.35) on port 22 (the default SSH port). This way, when you connect to your external IP address on port 2222, it will forward the connection to the remotewiki jail on port 22.

Virgin Router Example

• You should find your default router admin password at bottom of router.
  • Visit 192.168.0.1 and login with password ( will be prompted to change passwd)
  • If you have done this a while ago and forgot the password - you can reset router to return to default password.

Go To: Advanced settings > Security > Port forwarding and click Create a new rule

You should see these option boxes:

• Local IP: 192.168.0.[ ]
  • Local IP: The IP address of the 'remotewiki' jail you want to forward the ports to. In this case, it is 192.168.0.35.
• Local start port: [ ]
  • Local start port: The starting port number of the range on your 'remotewiki' jail. Since you want to forward the SSH port, this should be 22.
• Local end port: [ ]
  • Local end port: The ending port number of the range on your 'remotewiki' jail. Since you want to forward the SSH port, this should also be 22.
• External start port: [ ]
  • External start port: The starting port number of the range you want to uscurrently in use. For example, you can use 2222.e for the external connection. You can choose any available port number not
• External end port: [ ]
  • External end port: The ending port number of the range you want to use for the external connection. In this case, it should also be 2222 (the same as the external start port).
• Protocol: [Please choose]
• Enabled: [Please choose]

My configs in these case:

• Local IP: 192.168.0.[35]
• Local start port: [22]
• Local end port: [22]
• External start port: [2222]
• External end port: [2222]
• Protocol: [TCP]
• Enabled: [On]

And click Add rule now we should have port forwarding to are jail we can access from outside of network.

Append Firewall rules to allow connection to Tunnel Jail

• These rules are to be done (appended) on host/server and not in jail!
• Firewall rules before allow access to 192.168.0.35

cat /etc/ipfw.rules
#!/bin/sh

# Flush existing rules
ipfw -q flush

# Allow loopback traffic
ipfw -q add 00001 allow all from any to any via lo0

# Allow established connections
ipfw -q add 01000 allow tcp from any to any established in

# Allow incoming SSH traffic on port 22
ipfw -q add 00100 allow tcp from any to any 22 in setup keep-state

# Allow all outgoing traffic
ipfw -q add 00200 allow all from any to any out keep-state

# Allow incoming traffic for jail's IP (192.168.0.33)
ipfw -q add 00200 allow all from any to 192.168.0.33 in

# Allow outgoing traffic for jail's IP (192.168.0.33)
ipfw -q add 00210 allow all from 192.168.0.33 to any out

# Set default policies
ipfw -q add 10000 allow all from any to any out
ipfw -q add 20000 deny all from any to any in

# Log everything else
ipfw -q add 65000 deny log all from any to any

• after allowing jail 192.168.0.35 to be connected to

 
#!/bin/sh

# Flush existing rules
ipfw -q flush

# Allow loopback traffic
ipfw -q add 00001 allow all from any to any via lo0

# Allow established connections
ipfw -q add 01000 allow tcp from any to any established in

# Allow incoming SSH traffic on port 22
ipfw -q add 00100 allow tcp from any to any 22 in setup keep-state

# Allow all outgoing traffic
ipfw -q add 00200 allow all from any to any out keep-state

# Allow incoming traffic for jail's IP (192.168.0.33)
ipfw -q add 00200 allow all from any to 192.168.0.33 in

# Allow outgoing traffic for jail's IP (192.168.0.33)
ipfw -q add 00210 allow all from 192.168.0.33 to any out

# Allow incoming SSH traffic on port 22 for 'remotewiki' jail's IP (192.168.0.35)
ipfw -q add 00220 allow tcp from any to 192.168.0.35 22 in setup keep-state

# Allow outgoing traffic for 'remotewiki' jail's IP (192.168.0.35)
ipfw -q add 00230 allow all from 192.168.0.35 to any out

# Set default policies
ipfw -q add 10000 allow all from any to any out
ipfw -q add 20000 deny all from any to any in

# Log everything else
ipfw -q add 65000 deny log all from any to any

• Allow incoming SSH traffic on port 22 for 'remotewiki' jail's IP (192.168.0.35):

ipfw -q add 00220 allow tcp from any to 192.168.0.35 22 in setup keep-state

• Allow outgoing traffic for 'remotewiki' jail's IP (192.168.0.35):

ipfw -q add 00230 allow all from 192.168.0.35 to any out

• After making these changes to /etc/ipfw.rules, you can apply the new rules by running the script:

sh /etc/ipfw.rules

Now, incoming connections to the 'remotewiki' jail (192.168.0.35) will be allowed only on port 22.

Access your 'mediawiki' jail through the SSH tunnel

• Connect to the remotewiki jail from outside your network using an SSH tunnel

On your local machine, create an SSH tunnel using the following command:

ssh -i /path/to/your/private_key -L 8080:192.168.0.33:80 -p 2222 user@your_external_ip

• to find your public IP addess - when on home network in terminal run:
  • curl ifconfig.me
• Not as tidy as curl but if on FreeBSD you can use fetch
  • fetch -o - http://ifconfig.me
  • the -o - option is used to output the result to stdout

ssh -i .ssh/remotewiki -L 8080:192.168.0.33:80 -p 2222 remote@<ip_address>

Replace /path/to/your/private_key with the path to your private SSH key, user with the username you're using to connect, and your_external_ip with your external IP address. This command will create a tunnel from your local machine's port 8080 to the mediawiki jail's IP (192.168.0.33) on port 80.

Open a web browser on your local machine and navigate to http://localhost:8080. You should now be able to access your Local Mediawiki remotely.

Make .ssh/config entry for easy login

$EDITOR ~/.ssh/config

• Append

Host remote
  HostName your_external_ip
  User remote
  Port 2222
  IdentityFile /path/to/your/private_key
  LocalForward 8080 192.168.0.33:80

Should now be able to login with

ssh remote