As a follow-up to my post earlier this week, I'll discuss some other interesting things about setting up a home server.
Unfortunately,
the
technology
here
is
a
little
bit
opaque,
and I'm not really aware of any good documentation that exists on how to set up servers that is newbie friendly.
Most
of
the
writing
here
doesn't
really
start
from
first
principles,
and a lot of what you'll find is aimed at super knowledgeable people, or people like IT systems administrators.
There's a lot of stuff on Internet forums and on Reddit and on various peoples blogs.
And
when I figure this stuff out I do a lot of Googling and visiting Reddit threads, and visiting Stack Overflow threads.
I've thought about writing a bit more about how the technology works and how to set up this type of server. But this is not something i've done yet
Setting up HTTPS has become a lot easier than it used to be.
Caddy, which I use for the reverse proxy in my server basically handles SSL without me having to do much.
There's also a helper for NGINX which deals with a lot of the setting up the reverse proxy and setting up SSL.
The existence of Let's Encrypt has basically eliminated the need to buy SSL certificates from designated certificate authorities, and it's what the tools I mentioned above are built on top of.
The
security
situation
is
kind
of
a
mixed
bag,
there
are
some
tools
I
ran
into
that
have
super
insecure
default
configurations,
fortunately the security of the most common software programs has improved a lot compared to where it used to be.
Most
of
the
big
tools
that
you'll
run
into
like
Web
servers
and
so
on
are
pretty
much secure by default, you would have to actively change the configuration in undesirable ways to make it insecure.
And
I
think
container
programs
like
Docker
and
so
on
also
help a lot with security, basically every application I have running on my server has its own docker container.
The Caddy reverse proxy works as the glue between these containers.
Docker
is
a
way
of
packaging
software
programs
with
needed
libraries
and
dependencies,
it
functions in a very VM like way – there is a high level of isolation between the different containers by default.
This
isolates
security
issues,
if
one
of
the
services
running
on
the
server
gets
owned
it's
hard
for
the
hacker
to
privilege
escalate
to
the
rest
of
the server, so it's possible to just deal with the security issue by just nuking that one container and starting fresh.
Additionally,
since
there
are
a
lot
of
docker
images
that
are
packaged
either
by
the
developers
of
the
software
or
by
someone
else
upstream,
it's pretty easy to find a docker container where everything's packaged into a pretty secure by default container.
For backups, I use the Duplicati tool, set to make daily backups of the server.
It's possible to back up to a portable hard drive, or to another server with Duplicati on it that's off-site.
I
haven't
taken
any
of
these
purist
paths,
and I have taken the more non-self hosted route of uploading my data to a cloud storage provider (in this case Wasabi).
Duplicati is capable of encrypting the backups before they go to the cloud storage provider, or friend's server, or whatever else you're using for your remote backup.
There are two ways to connect the server to the outside world.
The traditional way, what I used, is to get a static IP address from your ISP.
AT&T,
who
I
use
for
my
Internet,
sells
static
IP
addresses
in a /29 block, that is six usable IP addresses, unfortunately, they won't give you just one static IP address.
Additionally, I still have access to one dynamic IP address from them.
My router/gateway/modem gets assigned one of the static IP addresses, the home server gets assigned another, basically every other device on my network gets put behind the dynamic IP address.
Even
for
standard
home
dynamic
IP
addresses,
IP
address
geolocation,
at
least
what
you
can
do
from
publicly
available
data
sources,
isn't super accurate, the main thing you'll get with almost perfect accuracy is country and which ISP you're using.
If
it's
a
standard
dynamic
IP
address,
it
will
probably
be
able
to
take
a
really
good
guess
at what city the user of that IP addresses is in, and a pretty inaccurate guess at what neighborhood they are in.
Short
of
getting
the
ISPs
logs
of
IP
address
allocations
or customer records, you'll never be able to map this IP address one to one with a physical geographic location.
For
the
static
IP
addresses,
as
far
as
I
can
tell
AT&T
(and
my
guess
would
be
most
other
major
ISPs)
allocate
all
of
their static IP addresses from one big pool of IP addresses without giving much consideration to geographic area.
I
haven't seen any of the IP address geolocation services accurately guess anything else other than what country I am in.
I don't consider the privacy implications of a static IP address that huge.
Probably
the
main
risk
of
using
a
static
IP address is that it is known to the public and the network it's on becomes susceptible to denial of service attacks.
The
barrier
of entry to conduct a fairly crippling denial of service attack on a small server or network is pretty low.
Taking
down
your
typical home server on a fiber Internet connection is definitely something the typical unskilled script kiddie can do.
The more newfangled way of connecting your server to the internet is to use a tunneling service.
Ngrok and PageKite are two pretty good examples of these types of services.
Your
server
opens
a
connection
to
the
tunneling
service,
and
the
tunneling
service assigns an IP address to your traffic (or subdomain that can be attached to a domain name as a CNAME record).
All
of
these
tunneling
services
hide
the
server's
IP
address
from
the
open
Internet.They
also
have
the
added
security
benefit
of
adding
another
step
between
spinning
a
service
up
and
exposing
it
to
the open Internet, making it harder to accidentally expose a service that shouldn't be attached to the public Internet.
The one I've done the most experimentation with has been Cloudflare Tunnel.
The
biggest
problem with this service is that it kind of adds another ISP-like intermediary between your server and the user.
This
is
a
step
back
in
terms
of
avoiding
over
dependence
on
centralized
services,
but
since
the
data
itself
lives on a server you control, it's still an improvement over your standard content silos or proprietary services.
I didn't use this type of service in my original post for this exact reason.
Cloudflare
goes
a
bit
further
than
many
of
the
other
tunneling
services
terms
of
the
amount
of
integration
with
your
site
–
and
not
only
routes the data, but also takes over the SSL certificate and does a lot of filtering and analysis on the traffic.
This
does
provide
a
lot
of
useful
security
features,
but
it
does
mean
that
Cloudflare
does have access to all the traffic going in and out of your server, and it can view SSLed traffic in unencrypted form.
Cloudflare tunnel is probably the option I'd recommend to people who don't have a super in depth technical knowledge.
Concerns
about
this
one
company
having
control
over an increasing amount on the Internet aside, it's a very powerful service with a very powerful free tier.
Other than the core tunneling service, it handles a lot of things.
It handles reverse proxying, i.e. it can do what I use the Caddy web server for, that is acting as the glue between the various services running on your server.
It
can
put
private
services
that
aren't
supposed
to
be
accessible
to
the
whole
world
behind
an
authentication
portal,
this
can
act
as
a
source
of
two
factor authentication for self hosted web apps that don't necessarily support two factor authentication natively.
It can provide a wrapper around SSH allowing external access through a web app, but with additional authentication.
It provides a lot of security features.
It
can
provide
DDOS
protection.The
DDOS
protection
basically
eliminates
the
threat
posed
by
script
kiddy
style
DDOS
attacks,
and
if the rest of your server is configured correctly it can mitigate even very powerful denial of service attacks.
It can rate limit bots accessing your site, which reduces some security threats.
Particularly
with
the
paid
tier,
it
can
provide a web application firewall which provides some attempts to block known exploits from being used on your site.
It
also
provides
a
content
delivery
network,
meaning
that
Cloudflare's
servers
store and send out frequently accessed static content instead of sending a request to your server every time.
This basically eliminates the type of scalability issues that I spent most of my original post talking about.
