[conspire] Running your own Web server (was: Bay Area ISPs for servers/hosting)

Rick Moen rick at linuxmafia.com
Fri Nov 15 10:45:54 PST 2019


Quoting Jim Stockford (jim at well.com):

>     I still have Comcast business with
> five static IPs and, at least when I
> was using it as such, no blockage of
> any ports whatsoever.
>     I've abandoned putting servers on
> it because they (three generations)
> have gotten wiped. I do not know
> enough of sys adm and also networking
> to defend myself, so if I ever decide
> to put up a web site, I'll use some
> hosting service such as SquareSpace
> that has a dedicate net ops team to
> manage intrusions from without.

I come bearing good news, then:  If you stand up a Web server
using a reasonable distro (Devuan/Debian, CentOS) and use the 
default configuration of one of the main HTTP daemons (Apache HTTPd,
Lighttp, nginx), and _don't go out of your way_ to add gratuitous
security loopholes _manually_, it is astronomically unlikely that 
your system will be security-cracked / wiped from across the Internet.

_Just_ running a Web server is not security-risky in any way.  There is
an extremely small attack surface, and even lackadaisical package
updating will avert even unlikely modes of entry.

Typically when someone says 'My Web server got wiped', the speaker is
absolutely _not_ talking about having just stood up Apache and serving 
static Web pages.  Pretty much inevitably, what the speaker is failing
to mention is all the other, inherently dangerous junk he/she
deliberately added and exposed to public attack.

And, in that category, the most frequent own-goal is unpackaged Web
apps.  The speaker at some point yielded to temptation to pull down a
developer tarball of, say, some extemely buggy PHP app.  That unpackaged
PHP code is now (1) outside the distro package regime, hence will never
receive security updates, and (2) creates (usually severe) ongoing
security risk for the system that otherwise would not exist.

The speaker then followed instructions provided by the PHP app developer
or elsewhere to enable PHP interpreter support inline in the packaged
HTTPd.  Which is a manageable if (IMO) unacceptable (in the case of PHP)
security risk, where at least the PHP interpreter software and support
libs are maintained by the distro package maintenance system.


There are other ways to commit security own-goals with Web servers you
build and run, but they all follow that basic pattern:  In all cases,
you the admin can only open yourself to serious security attacks by
manual and unusual, non-default steps to add gratuitous and fairly
severe risk factors.

And the good news is:  It's dead-simple to avoid doing that.  You just
basically stop and think before ever going way, way out of your way to
disfigure and injure your system, and, when in doubt, just Don't Do
That, Then.

A 'dedicated net ops team to manage intrusions from without' is
superflous.  And, by the way, SquareSpace doesn't provide that.
They just have marketing babble about 'top-of-the-line security'.

SquareSpace is a hosted proprietary drag'n'drool 'Web site builder' CMS
built on proprietary JavaScript frameworks.  In using it, you're giving
up on open source, on controlling your own software, and on controlling
even your own data.  But hey, if outsourcing absolutely everything works
for you, great!


And hey, if you're not going to make any use of those five static IPs on
Comcast Business, maybe you should lend a couple to BALUG and SF-LUG.




More information about the conspire mailing list