It’s a symlink I use for keyboarding. Typing /usr/local/vesta/bin/ for years is natural.
Btw the “ipset” pkg should probably be added to the installer (as should the user-space “apparmor” pkg).
I find the combination of ipsets and certain iptables modules (e.g. hashlimit) to be invaluable in production Internet servers for taking “preventive” measures (since 60-80% of malicious traffic comes from specific countries).
1 Like
Ipset and apparmor are allready in the new installer…
Here’s the primary and production server:
I installed that script today. It either didn’t install or something happened when the GUI wrote the conf files.
@Lupu what would be the recommended method to use my own firewall rules on a Hestia server?
I usually install iptables-persistent with a custom iptables rule-set. Typically, I filter inbound traffic with geoIP ipsets, then use either hashlimit or recent modules block offenders. One could even add offender IPs to an ipset, see https://volkan.xyz/insane-iptables-examples-that-make-nearly-everything-possible/
PS: I haven’t used fail2ban since 2010 … It used to block offender IPs using a separate iptables rule for each IP, which resulted in huge rules.
@arktex54 It’s getting very difficult to follow your problem, please describe the steps one would have to do to reproduce your issue starting from a clean Debian10.
@kpv I would prefer to keep this thread focused on problems found when upgrading to Hestia v1.2.0 (which has support for ipset, blacklist and country wide lists)
@eris I’m using Debian (9 & 10).
Installing HestiaCP v1.1.1 and upgrading to 1.2.0 produced a server with neither ipset nor apparmor (user-space) pkgs.
Looking at git master, the ipset pkg will be installed on a fresh 1.2.0 installation, but not apparmor pkg.
Should be installed automatically only if it is used:
1 Like
Debian 10
wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
bash hst-install.shreboot
setup as needed…
upgrade
wget https://apt.hestiacp.com/beta/hestia_1.2.0_amd64.deb
wget https://apt.hestiacp.com/beta/hst-debian-10/hestia-nginx_1.17.10.deb
wget https://apt.hestiacp.com/beta/hst-debian-10/hestia-php_7.4.6.deb
dpkg -i hestia-nginx_1.17.10.deb
dpkg -i hestia-php_7.4.6.deb
apt update
apt install -f
dpkg -i hestia_1.2.0_amd64.deb
rm hestia_1.2.0_amd64.deb hestia-nginx_1.17.10.deb hestia-php_7.4.6.debGo to admin panel
Server → Firewall → IPset → Add Ipset … Save → Error
@Lupu regarding ipset, the installer won’t install ipset if either iptables or fail2ban are un-selected. I would suggest that you do it only in case of the former. So:
if [ "$iptables" = 'no' ] || [ "$fail2ban" = 'no' ]; then
software=$(echo "$software" | sed -e "s/fail2ban//")
software=$(echo "$software" | sed -e "s/ipset//")
fi
becomes:
if [ "$fail2ban" = 'no' ]; then
software=$(echo "$software" | sed -e "s/fail2ban//")
fi
if [ "$iptables" = 'no' ]; then
software=$(echo "$software" | sed -e "s/ipset//")
fi@arktex54 I’ve just tried defining an ipset on a Debian 10 with HestiaCP 1.2.0
root@vm05:~# dpkg -l|fgrep hestia
ii hestia 1.2.0 amd64 hestia
ii hestia-nginx 1.17.10 amd64 hestia Nginx
ii hestia-php 7.4.6 amd64 hestia php-fpm
root@vm05:~# cat /etc/os-release |fgrep VERSION
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
root@vm05:~#
I just tried adding an ipset for e.g. China: Server -> Firewall -> IPset -> Add IPset … Save -> Error) due to using _ (valid char btw) geoip_china, so I changed the ipset’s name to geoip-china and it worked:
# ipset -L -n
geoip-china
# ipset -L |more
Name: geoip-china
Type: hash:net
Revision: 6
Header: family inet hashsize 2048 maxelem 1048576
Size in memory: 21848
References: 0
Number of entries: 5334
Members:
43.226.32.0/19
203.8.184.0/24
103.248.64.0/22@arktex54 Done testing debian10 exactly as you described, but could not reproduce your issue. ipset func worked as expected after upgrade to 1.2.0
2 Likes
@Lupu I’ve noticed your very nice work with building a “meta-ipset” of blacklists with /usr/local/hestia/install/deb/firewall/ipset/blacklist.sh
May I suggest adding in blacklist.sh the SpamHaus EDROP list (EDROP is an extension of the DROP list that includes suballocated netblocks controlled by spammers or cyber criminals. EDROP is meant to be used in addition to the direct allocations on the DROP list) to the regular DROP list – see https://www.spamhaus.org/drop/
Also a question: is it possible to create a “complex” ipset rules ? E.g. I often use rules like “match-set blacklist_net src ! match-set whitelist_net src” so I wouldn’t get locked out of my server if my IP were to be added accidentally.
# diff /tmp/blacklist.sh-new /usr/local/hestia/install/deb/firewall/ipset/blacklist.sh
12,13c12
< "https://www.spamhaus.org/drop/drop.txt" # Spamhaus Don't Route Or Peer List (DROP)
< "https://www.spamhaus.org/drop/edrop.txt" # Spamhaus Extended Don't Route Or Peer List (EDROP)
---
> "https://www.spamhaus.org/drop/drop.lasso" # Spamhaus Don't Route Or Peer List (DROP)
#Will take a look, but the way I implemented the ipset was to be pretty generic and easy to create other custom lists. I don’t plan to update that blacklist script very regulary as there is no perfect solution, different sysadmins have different preferences/requirements.
v-add-firewall-ipset accepts 3 types of data sources: url, script, file (PR)
-one ip prefix per line, empty lines or starting with ‘#’ are ignored
-the script: datasource can be used on-demand to cleanup and compile different sources and print the result to stdout.
-the file: data source is to be used when you have a external system that compiles the lists and pushes it to the server or when it gets updated continuously by a different app like fail2ban or a bgp stream etc.
3 Likes
Wrt minor improvements before release of 1.2.0, what do you think about this change in sshd_config ?
Instead of inline editing of /etc/ssh/sshd_config with sed, replace the section “Match User sftp_dummy99,…” with “Match Group hestia-users” (see sshd_config snippet below)
root@vm05:~# tail -15 /etc/ssh/sshd_config
# Hestia SFTP Chroot for admin
Match User admin
ChrootDirectory %h
X11Forwarding no
AllowTCPForwarding no
ForceCommand internal-sftp
# Hestia SFTP Chroot for users
Match Group hestia-users
ChrootDirectory %h
X11Forwarding no
AllowTCPForwarding no
ForceCommand internal-sftp
root@vm05:~#Finally have apache2 fixed with
mv /etc/apache2/mods-available/status.conf /etc/apache2/mods-available/status.conf.bak
dpkg --purge javascript-common && apt install javascript-common -y
rebootHi @arktex54
Thanks, I’ll have a look and will implement a fix. Can you share your apache2 and os version?
root@hestia:~# apache2 -v
Server version: Apache/2.4.43 (Debian)
Server built: 2020-05-11T11:55:17root@hestia:~# cat /etc/debian_version
10.4root@hestia:~# nginx -v
nginx version: nginx/1.19.0root@hestia:~# php -v
PHP 7.3.19-1+0~20200612.60+debian10~1.gbp6c8fe1 (cli) (built: Jun 12 2020 07:48:33) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.19, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.19-1+0~20200612.60+debian10~1.gbp6c8fe1, Copyright (c) 1999-2018, by Zend Technologiesuname -> 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
2 Likes