I’m getting these messages hourly on buster for the last 3 or 4 days …
Cron root@xxx [ -x /usr/sbin/sympl-firewall ] && /usr/sbin/sympl-firewall
*filter
:INPUT ACCEPT [364123:48122619]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [716596:95613731]
COMMIT
I didn’t see @smsm1 earlier post, which looks like is related …
Yep, it’s related. I’ll have a fix for this ASAP with an updated package for Sympl on Buster.
Now fixed in buster-testing, and will be pushed though to stable. At the start of next week.
Great and thank you.
I see that I am on stretch-testing right now.
What’s the sanest way to switch back to sympl-stable btw without breaking things? Or would it be an idea just to move everything over to buster?
No problem!
It sounds like you may have done a dist-upgrade from Debian Stretch to Debian Buster, but not updated Sympl at the same time?
Either way, if you run the Sympl installer without the --testing switch, it will swap you to the stable branch for the Debian version you’re running, which will then only take the relevant updates.
Running the installer again seems to work fine, although I did wonder that I had read that right and gave it a try on another machine just to see.
It does ask for the sympl user passwd to be set/reset.
Good point, I’ve updated the installer so it runs without prompting for a new password if you already have a sympl user.
I’ve since deleted the machine that gave this problem. Now on a freshly created instance over the weekend, the sympl firewall is nagging hourly …
It is running Buster on a DO vm, if that helps …
I’m wondering if the fix has moved from buster-testing to production?
It hadn’t until earlier today as I wanted to be as sure as possible it didn’t break anything, but is in the stable branch now.
@aye_philip If you run sympl update, it should fix it.
@Kelduum Great, it worked - eventually. When I ran the update yesterday it bombed then hung, broke the terminal sess. Unfortunately my notes, recall and the history got mangled so I can’t reproduce exactly, but here is where it failed at first in the event it says anything useful, Paul. Suffice to say it looks like it is all working, despite my efforts to break it. Thanks again.
…
…
Recommended packages:
sympl-phpmyadmin
The following packages will be upgraded:
sympl-backup sympl-core sympl-firewall sympl-mail sympl-mysql
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
…
…
Unpacking sympl-firewall (10.0.190816.0) over (10.0.190718.0) …
Preparing to unpack …/sympl-mysql_10.0.190731.0_all.deb …
I: Skipping removal.
W: /etc/mysql/my.cnf is not linked to either my.cnf.dpkg-sympl or my.cnf.dpkg-sympl-orig
Not removing diversion of /etc/mysql/my.cnf by sympl-mysql
Unpacking sympl-mysql (10.0.190731.0) over (10.0.190621.0) …
Setting up sympl-core (10.0.190908.0) …
I: Enabling dynamic MOTD
/usr/bin/sympl: line 175: 11555 Killed sudo apt-get -q -y install --only-upgrade ‘sympl-*’
A long time later…
from the logs:
Warning: iptables-legacy tables present, use iptables-legacy to see them
$ sudo iptables-legacy -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
$ sympl update
Reading package lists…
Building dependency tree…
Reading state information…
sympl-backup is already the newest version (11.20210818.1).
sympl-core is already the newest version (11.20220426.0).
sympl-cron is already the newest version (11.20220322.1).
sympl-dns is already the newest version (11.20210818.1).
sympl-firewall is already the newest version (11.20220719.0).
sympl-ftp is already the newest version (11.20210818.1).
sympl-mail is already the newest version (11.20220929.0).
sympl-monit is already the newest version (11.20210818.1).
sympl-mysql is already the newest version (11.20210818.1).
sympl-phpmyadmin is already the newest version (11.20210818.1).
sympl-updater is already the newest version (11.20210818.1).
sympl-web is already the newest version (11.20220406.0).
sympl-webmail is already the newest version (11.20220322.0).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Is there a fix?
Have you been using nftables, or had fail2ban, ufw or similar installed alongside sympl-firewall? Those are all ways to make things unhappy, and not supported configurations.
Yes, I am running fail2ban on this one. It’s banning hundreds of miscreants, so overall it seems to work
You’ll likely have inconsistent firewall results at best, and its likely that either sympl-firewall or fail2ban isn’t actually doing anything.
You’ll need to choose one or the other, and a future version of sympl-firewall will explicitly mark fail2ban as incompatible.
Can you clarify, please? Where is the incompatibility?
Does this mean I should switch to pcollison’s nftfw instead? That seems to be running happily alongside fail2ban on my other servers
iptables (nftables drop-in replacement for iptables, default in Debian), iptables-legacy (the older iptables version, which Sympl uses) and nftables are effectively two different firewalls.
The best case is that they will both work normally, the worst case however is that neither will work.
You need to either use the sympl-firewall package only, or remove itr and mix-and-match as needed, but that’s not something that can be supported here.
I was under the (possibly mistaken) understanding that only iptables is installed in Debian 12 and that iptables-legacy is a soft link to the new firewall, provided for backward compatibility.
Rather than start a new thread, I thought I’d revive an old one. Is that a bad plan?
Anyway, the issue is ever-increasing attempts at hacking email logins.
Thousands of attempts at logging in on port 587 each day, many using email addresses that aren’t on the server (though the domains are).
Fail2ban would rapidly block these, but the sympl firewall doesn’t.
Now, it is true that these attempts fail, as do the many thousand daily attempts to access wordpress config files (even though this server has never ever had wordpress installed).
Yes, it is mostly just noise in the logs, but I’d really quite like to stop at least some of it.
Is there a way to make the sympl firewall more reactive to repeated hacking attempts, or a way to make sympl play nicely with fail2ban?