I did it the way you described, but you point at the Maxmind site, which suggests that 3.1.1 is old hat, and suggests upgrading to 4. Their link to how to upgrade to v4 takes you nowhere useful.
I left it at 3.1.1 in the end.
The new geoiplocate section is more helpful, but I still feel that you need to state the obvious (to you) at the beginning, with some sort of preamble at the beginning of the info on github that says something like this:
How to install
If you are installing nftfw on Debian Buster, follow the steps in “Installing nftfw”.
You may want to follow the steps in “Installing Geolocation” but this is optional. If you don’t install it (briefly describe what you will miss).
If you are installing nftfw on a Sympl installation running Debian Buster, next follow the steps in “sympl-email-changes”
I had a look at the Maxmind page I link to - and couldn’t see anything obvious about a new release. Can you point me at it?
I’ve made a bunch of documentation changes along the lines you suggest… and there’s a change to the firewall generation logic which emerged as a bug today on my machine so please ensure you pull the new release and update Python.
Yes, the docs seem clearer now, thanks.
https://dev.maxmind.com/geoip/geoipupdate/ has the text:
=========================
nstall GeoIP Update. The latest release may be downloaded from GitHub Releases. See here for installation instructions.
If you are using an older version of GeoIP Update, you may need to upgrade to GeoIP Update 4.x or later version. The 4.x and later versions meet our requirement for using TLS 1.2 or greater for all requests to our servers to keep your data secure.
Please see our upgrade guide for more information on upgrading from an older version of GeoIP Update.
==============
But clicking the link to the update-4-x page is a fool’s errand.
Well. if it becomes necessary to run version 4, I am sure that the Debian folks will update us.
I did another set of changes today - uploaded about 5 hours ago (now 19:18 UTC).
I am hoping that will be it.
Today was a bumper day for my firewall on the Sympl machine - attacks from 455 distinct IP addresses, mostly in China - and most in a 45minute window at about 4am UTC.
Tried it again. Way better, but a few gotcha’s still there:
Under the heading Check on iptables there is a line that says
“If the output looks like this, then skip to the next section”
It isn’t obvious where the next section starts. Is it
“Run the sudo iptables -V again, to check things have switched, and”
or is it
" Installing nftfw" ?
Didn’t affect me, I had to do all the steps, because mine said legacy.
The it says “Change to a suitable directory”
so the next bit should say
Change to a suitable directory
$ cd /usr/local/source
$ sudo apt install git
$ sudo git clone GitHub - pcollinson/nftfw: nftfw - nftables firewall builder for Debian
Note that you missed sudo off the last line.
Further on, under
“Setting up config.ini”
you have got ERROR and INFO the wrong way round.
In that file, it says, " If you are running nftables on your system now and you’ve installed nftfw in the root of the file system, then in the Locations section change." but how can I tell whether I’m running nftables? Give the command to check this at this point: I’m not as smart as you think,
After that, I don’t recall any problems until the cronfiles README file, which says
sudo cp incron-nftfw /etc/incron.d/nftfw
but it should say
sudo cp incron.d-nftfw /etc/incron.d/nftfw
Though I think that it would be better to have the contents of the README in the quick instructions.
Then at the end, the file /etc/GeoIP.conf tells me I don’t need any license details if I want to use the free databases. That’s confusing and could do with an explanation,
Overall, it is a vastly better experience now. Thanks for the changes!
It could do with something similar for the Sympl email changes really.
Uh-oh. A bit of a problem:
sudo nftfwls
Traceback (most recent call last):
File “/usr/local/bin/nftfwls”, line 10, in
sys.exit(main())
File “/usr/local/lib/python3.7/dist-packages/nftfw/nftfwls.py”, line 353, in main
displaytable(cf, db, args.noborder)
File “/usr/local/lib/python3.7/dist-packages/nftfw/nftfwls.py”, line 184, in displaytable
pt.add_row(formatline(fmt, pattern_split, line, geoip))
File “/usr/local/lib/python3.7/dist-packages/nftfw/nftfwls.py”, line 119, in formatline
country, iso = geoip.lookup(ip)
File “/usr/local/lib/python3.7/dist-packages/nftfw/geoipcountry.py”, line 72, in lookup
if cn.country.names[‘en’]:
KeyError: ‘en’
Wassup?
What was the IP address? Don’t worry about this. The new code will cope if there is no country name in English.
This is more tricky because you may not want all the changes.
I’ve removed the .d from the cron-nftfw file so the files there are named consistently.
That server is in Nuremberg.
OK I’ve hopefully made geoip2 lookup a little more robust. It should hopefully fail ‘safe’ when it finds records with missing data.
I’ve also done some document fiddling.
New update on GitHub.
Yup, that seems to have sorted it, thanks.
Tested it again just now. The only error remaining is my fault:
Change to a suitable directory
$ cd /usr/local/source
should be
Change to a suitable directory
$ cd /usr/local/src
OK, it all seems to be sorted and working for me on two test servers.
Now I have some “regression” questions.
- Would this work on Debian Jessie (or more likely, Squeeze)?
- Can the email changes be usefully made to a Symbiosis system that is still running the Symbiosis firewall setup?
-
You need Python 3.6 as minimum… so where it will run depends on whether you can get the version of Python - and no guarantees.
-
Yes I think so. These changes were originally on a Symbiosis system and were posted to their forum RIP.
Oh - I am very grateful for your assistance. It’s really helped.
I’ve not helped you as much as your firewall setup has helped me!
I think it might be a good idea to reconsider the outgoing.d rule that controls outgoing connections.
As far as I know, this is not set in current versions of Symbiosis or Sympl, but this firewall has it by default.
Not saying that either option is the correct approach, but perhaps the difference ought to be mentioned.
Recent symbiosis releases has the two rules - I checked in their release base. It needs the IPv6 rule and the other one protects outbound calls from websites. So if you have no web then the www can go - and also if your website uses things like google maps - then it should go too. But it’s reasonable as a protection for most people’s websites. I think about better commenting in the rules at a later date.
You may be right about Symbiosis, but there is no www rule there in Sympl by default.
On my production server, the file got bigger and bigger, and I eventually had to delete it, mostly because of some e-commerce payment providers endlessly messing with their IP addresses.
We fairly quickly found preventing the www-data user from connecting out in Symbiosis Jessie to cause more problems than it was worth - rather than preventing compromised sites from abusing other installs, it meant that CMSs (WordPress etc), broke in odd ways (plugins malfunctioning, crowns not running), and typically didn’t get updated automatically at all, and we’re compromised eventually, and were then used to send spam or other things possible on the box which didn’t need to connect out directly.
That"s why it was not enabled by default for Symbiosis Stretch, and the same with Sympl.