Should be installed automatically only if it is used:
Debian 10
wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
bash hst-install.sh
reboot
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.deb
Go 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
@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.
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
reboot
Hi @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:17
root@hestia:~# cat /etc/debian_version
10.4
root@hestia:~# nginx -v
nginx version: nginx/1.19.0
root@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 Technologies
uname -> 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
@arktex54 Thanks for the details, the issue has been fixed here: https://github.com/hestiacp/hestiacp/commit/e6dca969aaa6d8456a81b826f5c1dba1f1ccc71c
@kpv May I ask you to create a github issue with your suggestion to adjust the match user part in sshd config? So we could track the feature request there: https://github.com/hestiacp/hestiacp/issues/new
@Raphael I can open a new issue, actually I had first suggested this back in Feb-2020:
If there a usage scenario where a hestia user shouldn’t be allowed to use sftp to access his website(s), then we might have to create a new group (e.g. hestia-sftp). Otherwise the simple sshd_config snippet above would suffice.
Hi @kpv
Thanks for the information, to answer your question: no, I think there is no case that sftp have to be restricted. We currently discuss the change, not sure if we can implement it for 1.2.0, because we want to ship it on monday - if not, we we will place it on 1.2.1 .
Ouch that shiny line-through-the-middle UI looks a little dated. It’s ok.
The shortcuts listed at the bottom seem to ignore users and thus numbers are shifted -1.
Install went without a hitch on debian 10 64bit, default options, redirected from http to https given the port. Next will test without nginx.
UPDATE: crap. The installer from master branch installed 1.1.1. Let me update.
Upon installing the hestia .deb I got these:
(*) Hardening Apache2 Server Status Module...
(*) Updating Roundcube configuration...
(*) Updating exim4 configuration...
Enabling conf hestia-event.
Enabling module hestia-status.
(*) Configuring Filegator FileManager...
(*) Updating public_(s)html ownership...
/usr/local/hestia/install/upgrade/versions/latest.sh: line 117: conditional binary operator expected
/usr/local/hestia/install/upgrade/versions/latest.sh: line 117: syntax error near `/home/${user}/web/*/public_*html'
/usr/local/hestia/install/upgrade/versions/latest.sh: line 117: ` [[ ls /home/${user}/web/*/public_*html >/dev/null 2>&1 ]] || continue'
(*) Upgrading phpMyAdmin to version v5.0.2...
(*) Rebuilding domains and account for user: admin...
(*) Restarting services...
Otherwise everything seems in order, but the shortcuts thing is still eating users, links are -1.
The beta package wasn’t rebuilt since yesterday, should be sorted now (latest.sh error)
Environment:
QEMU / KVM Virtualization
Core: 2
Ram: 20Gb
SO: Debian 10.4
Hestia: v1.2.0 (APACHE + NGINX)
No problems when updating, following the indicated steps.
Errors found so far:
Backup section:
When you want to download a backup file, you do not download it, but queue a new backup.
Should be fixed 4 days ago
It is effectively solved.
Thank you very much!