
Since the great “supply chain disruption” of 2021 has hit computer chips, and Raspberry Pi enthusiasts in particular, we’ve been working on an alternative for the AMENDMENT1 in a downloadable IPFire Build. We’ve been doing some testing and the good news is that its a pretty slick system as long as you feel comfortable configuring a pretty advanced firewall tool. If you are brave, then don’t hold back as IPFire makes it pretty simple and has a great community.
The IPFire Build
Here is a link to a version 1.0 build of the CognitiveMetropolis build of IPFire for Raspberry Pi 3B or Raspberry Pi 3B+ (IPFire does not yet support Raspberry Pi4). Please feel free to download, configure, and let us know what you think! Once downloaded, you’ll need a 4GB or larger MircoSD Card to burn the image.
IPFire Build Configuration

To make it easier for you to admin and deploy, we have used a Green-Red-Blue network configuration. Red network (outside the firewall) is the Ethernet port and Blue network is the WiFi interface. Blue network is behind the firewall and has access to Green network, which is also behind the firewall. Green Network gives access to the web administration page at https://[LAN IP]:444. The unit is configured for HDMI output so just plug the HDMI port into a monitor and the Ethernet port into your LAN – either another firewall, Cable/DSL Modem, or other DHCP-enabled port (Red requires DHCP). You’ll want to watch for the DHCP assignment or simply check after boot with the “ifconfig” command: the IP assigned to RED0 is your local administration address (see pic). It will also create a WiFi network with SSID AMENDMENT1 but you must manually add MAC Addresses to the Blue network via Administration. After a device is added to the Blue WiFi network, you can administer via the WiFi network. The root, admin, and WiFi (SSID: AMENDMENT1) password are all “cheeseandgrits”. You should obviously change them!
IPFire Build Testing
First of all, there is a problem with Tor. That sucks. But, the good news is that it should be fixed before long and there is a workaround in the interim (that undermines security but testing is possible). Here is what we have enabled in this first version of IPFire-Based AMENDMENT1.
- Flashable .img file ready to deploy on Raspberry Pi 3B or 3B+
- Blue0 WiFi Network with SSID AMENDMENT1
- Suricata/Snort Intrusion Prevention System Configured
- Intrusion Prevention System is configured to watch both Blue and Red networks (must be enabled)
- Firewall Pinhole on port 444 to allow initial setup (remove rule after initial setup)
- NAT Forwarding between Blue and Green network to allow administration via WiFi
- Web Proxy and URL Filter enabled for non-transparent use on port 800 (See Note Below)
- URL filter updated and configured to use UTC Blacklists
- Web Proxy and URL Filter logged by user, filter content, and IP Address
- Firewall rules added to block proxy circumvention on Ports 80 and 443 (See Note Below)
- Tor installed and configured (requires manual setup to run)
- SSH server disabled. Guardian brute-force logger installed (for when SSH is needed)
- Safe Search enabled for Google and YouTube
- QName minimization enabled for DNS Queries
- Log4J: IPFire is immune and can even protect your network via IPS
Overall IPFire is really impressive and it does a great job even on the little Raspberry PI 3B+. I would not recommend using a 3B unless that’s just all you have laying around because even the 3B+ was occasionally overwhelmed by administration tasks (like recompiling the URL Filter Blacklsts) or general system updates. That said, the coolest features that are baked into the software are the Hardware Vulnerability detection (and mitigation, if possible), WPA3 for HostAPD, and integrated security and package management in the Web Admin. Once again, the Raspberry Pi 3B(+) is safe from Spectre and Meltdown hardware flaws and that makes this little package even more appealing as a security device.
Note on Proxy and URL Filter: Two rules in the Firewall will block external traffic (RED) on ports 80 and 443. This is to ensure users on Blue (WiFi) must configure the proxy. As set up, the Blue network hands out DHCP Addresses on 10.0.0/24 so set your proxy to IP 10.0.0.1 and port 800. When using the Proxy/URL Filter, you cant reach administration; when not using the Proxy/URL Filter users can reach administration but nothing else. If this isn’t how you would like things, just delete the noted rules from the Firewall. Here are more links to Proxy Setup issues and a Discussion of Transparent vs Non-Transparent
You must log in to post a comment.