Part of the IPFire Security Hardening Guide
Implementation Scale
This guide uses two scales:
| Impact (security benefit) | A. MAJOR | B. SIGNIFICANT | C. MINOR |
| Effort (to implement) | 1. LOW | 2. MEDIUM | 3. HIGH |
See the Security Guide introduction for a more detailed explanation of the scale.
Good Security Practice
Strong Passwords, stored securely
| Impact | Effort |
|---|---|
| A. MAJOR | 2. MEDIUM |
- Use strong passwords for the "admin" web user interface (WUI) and "root" console accounts
- Do not use the same password for "admin" and "root"
- Do not re-use a password which has been used elsewhere
- These passwords should be at least 15 characters long, contain all character types (uppercase, lowercase, numbers and symbols) and avoid using words.
- Store passwords in a Password Manager so that they can be longer and more complex than you can remember
- Ideally your Password Manager should be Open Source software which has been inspected for security flaws (such as KeePassXC)
- Do not save passwords for the IPFire WUI in your browser
- Avoid creating additional accounts on your IPFire system, unless specifically required
Patch!
| Impact | Effort |
|---|---|
| A. MAJOR | 1. LOW |
- Always use the latest stable version of IPFire. Old versions have known security flaws.
- When an update is available, the WUI will display a red note at the bottom of each screen. Arrange an outage and apply updates as soon as possible - most updates require a reboot.
- You might want to subscribe to the IPFire-Announce mailing list. That way, you will receive an e-mail in case of a new available update.
| item | |
|---|---|
| Go with security expert's advice. Source Google Security Blog |
Check logs regularly
| Impact | Effort |
|---|---|
| A. MAJOR | 1. LOW |
Most IPFire features create logs which are visible from the WUI. Without regularly checking logs it can be very difficult to know if your system is under attack, or at worst an intruder already has access to it.
Depending on your preference, you may prefer to configure some logs to be emailed to you. It would be best if this is to an internal email server and not an internet-based server as logs can contain sensitive information about your IPFire system and its configuration.
Aim to checkat least these logs regularly:
- The WUI Status > Services page, to ensure services are still running and you don't suddenly have a high number of processes or high memory usage
- The Log Summary page
- IDS Logs (if your IDS is configured, otherwise it will be of little value)
- Firewall log (Port)
- Firewall log (Country) to note which countries most attacks come from.
- After you have enabled the Location Block (highly recommended, below) to see the number of hits against your firewall from countries which you are blocking:
- In the WUI open the "Firewall" menu and click "iptables":
- In the first "iptables" section, select "LOCATIONBLOCK" from the drop down list
- Click Update
- A list of the countries you block will be displayed along with a packet and byte count for the number of hits those countries have had against your firewall and the volume of traffic blocked
Generous capacity for logs
| Impact | Effort |
|---|---|
| B. SIGNIFICANT | 3. HIGH |
When installing IPFire, ensure there is a large amount of space available for logs. Ideally IPFire will allow users to create a separate /var/log filesystem in future as this will prevent denial of service attacks created by thousands of deliberate log entries.
- When installing IPFire, ensure there is a generous capacity available for logs
- If possible, create a separate partition and remount /var/log on it
To check space availability go to menu Status > Media. Scroll down to Disk usage and search for Mounted on "/var".
Use the 64 bit version of IPFire
| Impact | Effort |
|---|---|
| B. SIGNIFICANT | 2. MEDIUM |
In the past IPFire only ran on 32 bit systems but now the majority of people use the 64 bit version. The 64 bit version has Linux kernel security mitigations (for "Meltdown", "Spectre" and the like) which are not as well tested in the 32 bit version.
- Backup a 32 bit IPFire system and reinstall with the 64 bit release
Change default login details
| Impact | Effort |
|---|---|
| A. MAJOR | 3. HIGH |
It is ideal to change the login details of accounts used to administer any system. This adds another step for a potential attacker who now has to guess your login as well as attempt to break (or brute-force) your password.
Note: Currently this requires a high amount of effort for an inexperienced user. Hopefully in future IPFire will ask new users for accounts they would like in the installation process
- Change the default "admin" account in IPFire to a different username which will not be obvious to an attacker
- Add another account to Linux on your IPFire system with a different username to the one you chose above. Allow this user the ability to start a shell and use it to login and switch user (su) to root.
- Then disable root access from SSH by adding an entry to the /etc/ssh/sshd_config configuration file
PermitRootLogin no- If you have a major outage, use a graphical console to login directly as root or remove your storage and mount it on another Linux system
Use a VPN to manage IPFire from the internet
| Impact | Effort |
|---|---|
| A. MAJOR | 3. HIGH |
If you really need to manage an IPFire system from the internet (or any "hostile" network) do not open the WUI (tcp port 444) or SSH (tcp port 22) directly to the internet. Instead research how to configure a secure VPN and use VPN access to administer IPFire using the WUI as if you were connected to on the local network.
- If you need to manage IPFire from the internet, configure and use a VPN to administer IPFire systems over the internet
--Next Page: Additional Security Configuration