On 28/03/22 at 08:28, xwindows <
xwindows@tilde.club> wrote:
On Mon, 21 Mar 2022, klu wrote:
Particularly,
I'm concerned of exposing my home network to the internet. I'm wondering
if there's a way for safe hosting by putting the pubnix in a container
or jail, then config its network interface through a VPN or something.
At some point I was running a internet-facing server with ssh access,
as I lived distant from were the server (legacy IBM thinkpad) was
actually located. I would even grant shell access to few friends.
Malicious attacks were commonplace, but, over a couple of years,
nobody managed to break into it, at least as far as I can tell.
From my experience, the single most important factor is disabling
password authentication and root login. This alone will take care of
most brute-force attacks. Publickey authentication or 2FA is the only authentication method you should enable. You may even force your users
to use a passphrased pubkey.
Then you can play with sandboxing, containers, bans, firewall settings
and resource limits.
My rather 'picky' sshd_config:
=======================================================================
ListenAddress x.x.x.x
Port <port>
PidFile /var/run/sshd.pid
# Cryptographic policy
HostKey /etc/ssh/ssh_host_ed25519_key
Ciphers
chacha20-poly1305@openssh.com,
aes256-gcm@openssh.com,
aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
HostKeyAlgorithms
ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
KexAlgorithms curve25519-sha256,
curve25519-sha256@libssh.org
MACs hmac-sha2-512,
hmac-sha2-512-etm@openssh.com
RekeyLimit 1G 1300
# Logging
LogLevel VERBOSE
SyslogFacility AUTH
UseDNS no
# Authentication
PermitRootLogin no
StrictModes yes
UsePam no
AllowUsers user1,user2
MaxAuthTries 3
MaxSessions 2
PermitEmptyPasswords no
PasswordAuthentication no
HostbasedAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
LoginGraceTime 30
IgnoreUserKnownHosts yes
IgnoreRhosts yes
# Session
Banner /etc/ssh/sshd_banner
PrintLastLog yes
ClientAliveInterval 300
ClientAliveCountMax 0
MaxStartups 2
TCPKeepAlive yes
X11Forwarding no
# Port Forwarding
AllowTcpForwarding no
AllowAgentForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
# Misc
AcceptEnv LANG LC_*
Subsystem sftp /usr/libexec/sftp-server -f AUTHPRIV -l INFO
=======================================================================
On NetBSD there's this daemon called blocklistd(8), which allows you to
ban IPs for a given time after a given number of failed authentication
attempts on a series of services, which include ftp, ssh and smtp.
I set it to ban IPs for 72h after 3 failed attempts. The NPF firewall
can also be configured to read the blocklistd database and refuse any
packet from those IPs even before ever allowing them to authenticate.
I also have script which keeps track of those addresses which have been
banned more than once and sends them to a permanent blocklist via a cron
job. NPF reads the list upon startup and flags the addresses as
permanently banned.
On Linux I think Fail2Ban provides this exact same functionality, but I
haven't had the chance to experiment with it yet.
You can set hard limits for users inside login.conf on *BSD (e.g.,
with a 'guest' class) and in limits.conf on Linux.
On *BSD you can partially contain the effect of privilege escalation by
raising the securelevel
https://wiki.netbsd.org/tutorials/kernel_secure_levels/
You may also restrict information passed from the kernel to userland so
that users can only view information relative to their own processes.
This feature is available under different names on most Unices.
While Jails, LXC, and Zones aren't born as a security measure, they do
provide a certain degree of isolation, by running in a separate
namespace. My personal experience mostly regards Solaris zones, where
the level of sandboxing is noteworthy. With Crossbow you can have a
virtual NIC with a dedicated IP, while hiding most of the host's network
thus providing a functionality similar to VLAN but at OS level.
Afaict FreeBSD has VNET to accomplish the same, and I bet this is
feasible on Linux too.
On NetBSD, I successfully limited some services to their own TCP/IP stack, by running them inside a networking rump kernel. This on one hand addresses
the problem of isolation, and on the other, reduces the software attack surface.
As an amateur, I do not claim to know how to secure a server, but these
are some of the security practices I decided to adopt over the years,
after skimming through the docs.
Kindest Regards.
--
-----------+------------------------------------
Snow Crash |
gopher://tilde.pink:70/1/~snowcrash
--- Synchronet 3.19a-Linux NewsLink 1.113