1 Like
You could edit the script /usr/local/hestia/install/common/firewall/ipset/blacklist.sh and remove this line :
"https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1" # TOR Exit Nodes
To prevent the script from being overwritten, create a new one with a different name.
deleted
Yes, you can, but as I said above, change the script name and modify that script. If you change the script name, remember to remove the old ipset and create a new one pointing to the new script.
sorry I missed that post, was just confused by the renaming to avoid overwriting suggestion. backing up (beep … beep … beep)
Just an example:
cd /usr/local/hestia/install/common/firewall/ipset/
cp blacklist.sh blocklist.sh
sed -i '/torproject/d' blocklist.sh
v-add-firewall-ipset blocklist "script:/usr/local/hestia/install/common/firewall/ipset/blocklist.sh" v4 yes
v-add-firewall-rule DROP ipset:blocklist 0 TCP "BLOCKLIST"
I’d done the 1st 2 of the 5 very welcome lines and was editing blacklis.sh when your excellent assistance arrived.
As always, THANK YOU VERY MUCH
1 Like
I’d nano’d a “#” at the beginning of that torproject line rather than deleting it. But Web UI is still unreachable. I guess I’ll be removing/deleting again, and then trying again with another line remarked-out, and repeat, until I get it…
If nothing else, just DROPping only the spamhaus list should still provide significant relief.
To connect via Tor, In addition to not using torproject.org I’ve also found the need to rem (“#”) out projecthoneypot.org and raw.githubusercontent.com (AbuseIPDB 30d 100% confidence score), in case anyone’s interested.
But that leaves the server Very Slow to respond to most of my new web page requests.
So I’m also skipping 4 others:
215 KB cinsscore.com
300 KB blocklist.de
68 KB firehol.org level1
305 KB firehol.org forumspam
That means I’m only using 3:
24 KB danger.rulez.sk
38 KB spamhaus
62 KB greensnow
And it’s still sometimes quite slow to respond to a fresh (from new exit node) web page request.
So I surfed to webUI /list/firewall/ and edited ipset BLOCKLIST’s Port data field to 143,993,110,995,25,465,587 (all the email-related ports). Saved ok…
Now all new web connections are normal-Tor-laggy again (so I guess I could add more/all the other BL sources back), and the exim4 rejectlog has no more entries matching spamhous.org. 
I don’t see a way to (ie, the BL’s URL, so I could just) add a line to blocklis.sh to import the spamcop BL… 
Still, this ipset is filtering out a big portion of unwanted hits filling the rejectlog, without impacting anyone that matters.
Thanks for sharing.
That’s strange, what are your server specs (CPU and RAM)?
Keep in mind that the Spamhaus list in blocklist.sh script and the Spamhaus “list” used in Exim are not the same, you must keep both.
Spamcop doesn’t provide a file with the list (well, they do if you pay $1000):
Woah!!!
They are crazy.
Ahh, private and public.
Still 1000 per year per sever. woah..
You can keep using their service for free using the DNSBL (used in Exim).
MiB Mem : 1880.2 total, 199.6 free, 600.3 used, 1275.6 buff/cache
MiB Swap: 1024.0 total, 622.9 free, 401.1 used. 1279.9 avail Mem
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 40 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: AuthenticAMD
BIOS Vendor ID: QEMU
Model name: AMD EPYC-Milan Processor
BIOS Model name: pc-i440fx-6.1 CPU @ 2.0GHz
BUT… the excessive delay is SO EXCESSIVE that it undoubtedly has more to do with Tor + a Big Blocklist somehow multiplying the time it takes to establish a TCP ‘handshake’. IOW, way beyond just cpu processing speed/burden:
Without Blocklist affecting any web ports, the nominal Tor delay for establishing a new Tor connection hardly ever exceeds 5s. That is true for ~every web server, not just mine.
With Blocklist affecting web ports, when I’d only eliminated the 3 Tor-blocking source lists, the web browser would occasionally Time Out, as if the connection was blocked/dropped!
When only using the 3 smallest list sources, it would still sometimes take an annoying 10~15s (though sometimes it was still nominally quick, just a few seconds).
As long as the new-web-connection delay is not noticeable on your system, sure, go ahead and block all ports, but if, like mine, the multiplied delay using Tor is annoying, and the whole point of the exercise was to lessen the burden on the mail server, then making it ports-specific still seems to be very worthwhile.
Due to the slowness issues when processing ipsets, the continuous service crashes, and the fact that your system is using swap, it seems that your server is running out of RAM. When that happens and swap memory starts being used, the server will slow down significantly.
Ipsets consume memory, so if you’re running that tight on resources, it’s normal that you have to delete almost all the lists.
Continuous service crashes? ???
When I first met unix back in the 1980s, when I was endowing microcomputers with the ability to work like minicomputers, it spent way too much time swapping (which is why I spent my time w/another OS). But back then RAM was less and disks were slow…
The downloaded blocking lists hardly total 1 megabyte, and available RAM is most of 1 gigabyte. Between that, and no spikes on the RRD memory graph (in the past, I’ve caused/seen some), it [had] seemed like RAM was not the/an issue. otoh, the delays seemed worst at first, suggesting RAM had gotten shuffled.
As you’d said, it did/does seem strange. otoh, that slow-down is actually a bit of a bonus, as all the authorized email use is currently via Roundcube, anyway. But that probably means I could just shut down POP and IMAP ports completely, right?
Yes, as you said, php-fpm was crashing once and again.
Roundcube retrieves the mails connecting to the imap server (via localhost) so you can’t shut down imap.
I thought it was just my browser timing-out – running out of patience after more than a minute – those handful of times when the ipset had 7 lists loaded.
Apologies, I confused two different conversations.
so it seems…
I have a weak grasp on *nix memory usage in terms of what (buff/cache?) is considered “available”. RRD Memory Usage graph always (unless the admin is screwing around…) shows more Free than there is swap space, and the swap space always stays more than 1/2 free, so there’s always plenty of memory space, just not plenty of RAM… Then again, I’ve seen systems use some swap space when they have gigabytes of free RAM.
Anyway, in the pursuit of knowledge, I decided to reset the Port to 0 and cause some more new-Tor-web connection delays while running top
Few(er) of the delays were excessive this time around, so it wasn’t much of an experiment, but I did catch glimpses of kcompactd0 (once 1% cpu, the other 0.5%). I also glimpsed a khungtaskd.
free RAM got down to a measly 86 MiB. “available Mem” was then 1180M (swap file is 1024M)…
Entry-level vps…; never before exhibited any noticeable undue lags (unless the admin was screwing around)…; and this slimmed-down ipset only loads far less than 1 megabyte.