| 2022-01-09 05:19:51 |
Chris Osgood |
description |
Running a minimal Ubuntu 20.04 on a server. The server has iptables-persistent installed and also uses iptables rules loaded in stages after boot or by various daemons to control multiple internal networks, spam, and stop attacks on the server.
I just did an upgrade which updated iptables-persistent to 1.0.14ubuntu1. When this update was applied it totally trashed the iptables rules including hundreds of existing active entries in the kernel and the file at /etc/iptables/rules.v4. Nothing was correct and the server was in some sort of weird amalgamation of failsafe mode and partial rules from another stage. I had to restore /etc/iptables/rules.v4 from a backup.
I don't think iptables-persistent should ever change any existing configuration files or change the existing rules in the kernel, especially without asking. This was unexpected behavior that could have led to a security breach.
Am I using iptables-persistent wrong? |
Edit:
Sorry, this bug was meant to go against Ubuntu Server or similar, not SBCL. I don't know how I got here from there.
This can be closed/invalid or moved if possible.
---------------------------
Running a minimal Ubuntu 20.04 on a server. The server has iptables-persistent installed and also uses iptables rules loaded in stages after boot or by various daemons to control multiple internal networks, spam, and stop attacks on the server.
I just did an upgrade which updated iptables-persistent to 1.0.14ubuntu1. When this update was applied it totally trashed the iptables rules including hundreds of existing active entries in the kernel and the file at /etc/iptables/rules.v4. Nothing was correct and the server was in some sort of weird amalgamation of failsafe mode and partial rules from another stage. I had to restore /etc/iptables/rules.v4 from a backup.
I don't think iptables-persistent should ever change any existing configuration files or change the existing rules in the kernel, especially without asking. This was unexpected behavior that could have led to a security breach.
Am I using iptables-persistent wrong? |
|
| 2022-01-09 05:23:18 |
Chris Osgood |
description |
Edit:
Sorry, this bug was meant to go against Ubuntu Server or similar, not SBCL. I don't know how I got here from there.
This can be closed/invalid or moved if possible.
---------------------------
Running a minimal Ubuntu 20.04 on a server. The server has iptables-persistent installed and also uses iptables rules loaded in stages after boot or by various daemons to control multiple internal networks, spam, and stop attacks on the server.
I just did an upgrade which updated iptables-persistent to 1.0.14ubuntu1. When this update was applied it totally trashed the iptables rules including hundreds of existing active entries in the kernel and the file at /etc/iptables/rules.v4. Nothing was correct and the server was in some sort of weird amalgamation of failsafe mode and partial rules from another stage. I had to restore /etc/iptables/rules.v4 from a backup.
I don't think iptables-persistent should ever change any existing configuration files or change the existing rules in the kernel, especially without asking. This was unexpected behavior that could have led to a security breach.
Am I using iptables-persistent wrong? |
Running a minimal Ubuntu 20.04 on a server. The server has iptables-persistent installed and also uses iptables rules loaded in stages after boot or by various daemons to control multiple internal networks, spam, and stop attacks on the server.
I just did an upgrade which updated iptables-persistent to 1.0.14ubuntu1. When this update was applied it totally trashed the iptables rules including hundreds of existing active entries in the kernel and the file at /etc/iptables/rules.v4. Nothing was correct and the server was in some sort of weird amalgamation of failsafe mode and partial rules from another stage. I had to restore /etc/iptables/rules.v4 from a backup.
I don't think iptables-persistent should ever change any existing configuration files or change the existing rules in the kernel, especially without asking. This was unexpected behavior that could have led to a security breach.
Am I using iptables-persistent wrong? |
|
