Re: [PLUG] Avoid Arvixe at all costs!

[Rich Kulawiec <rsk@gsp.org>]

On Thu, Mar 16, 2017 at 02:37:58PM -0400, Steve Litt wrote:
> Perhaps everyone *was* adding value by telling you that you need to
> prioritize, and you need to consider the goal rather than following the
> exact steps you used at Arvixe.

With that in mind, let me revisit the requirements, with some comments.
This is a cursory look at the kind of questions I'd ask if doing a
review -- which means it's missing all kinds of stuff.

*linux hosting (CentOS is probably best, what we're used to)

	- probably okay.  Your chances of success are likely better
	with a distribution you know than a theoretically optimum
	distribution.

*cPanel/WHM, including csf (ConfigServer Firewall) and clamav

	- This is too much complicated machinery to run with cPanel,
	or to be handed over to someone who can't work at the command line.

	- Why Clamav?  Exactly what threat model is this intended to address?

	- If you can't hand-configure your firewall, you shouldn't
	be the one configuring your firewall.

*WordPress, plus ability to install the various addons

	- Be aware that Wordpress is a habitual security problem.
	It would probably be good to consider a CMS that isn't,
	or a static site generator that removes the problem entirely.

*MySQL (support WordPress)

	- I believe that MariaDB has supplanted MySQL in CentOS.  Not
	a big change though, I think it presents the same API.

*A dedicated IP address, must be able to supply one that's not on spam 
blacklists

	- You'll need to conduct due diligence on this.

*Email (unlimited accounts) using dovecot, fully configurable by us. 
Must provide webmail interface (roundcube or horde).  MUST be able to 
have outgoing mail sent from our domain with our private IP (not routed 
through their server).

	- Dovecot is fine as a POP/IMAP server.  What do you plan
	to use for an MTA?   And what do you plan to use as the
	account backend for Dovecot?

	- I've come around to the viewpoint that webmail is a profoundly
	horrible idea and should be deprecated: if you're serious about
	email, use a real email client or go home.  But if you need
	roundcube/horde for the clueless ignorant newbies who are too
	stupid and too lazy to learn, fine.

	- If your IP is private, e.g,. RFC 1918 space, then it won't
	be able to send mail.  I think what you mean is through your
	public IP, as allocated by them.  You already know what this
	will require FCrDNS; it'll also require the MTA I mentioned
	earlier.  It'll also require other things if you intend to
	be able to deliver mail to the big four -- Gmail, AOL, Yahoo,
	Microsoft.  (Which you will even if you don't think you will
	because so many operations outsource to the first and last.)
	
	- Those "other things" probably include transport encryption,
	working role addresses per RFC 2142, feedback loops at those
	four providers, SPF, DKIM.  

	- If you also intend to receive mail, and you do, because you
	need to support role addresses if nothing else, then a
	comprehensive set of defenses are required.  I highly recommend
	learning procmail and mutt: these are must-have tools for
	mail system admins who have to known-hostile traffic.

*Website statistics report (AWStats)

	- I got nothin'. ;)

*Ability to do granular backup/restores (individual directories/files), 
at more than just overnight interval (this can be an extra-cost option).

	- Why do you want to do this?  What is it that you anticipate
	breaking so badly that you need to do this more than once a day?

	- Do you mean backups, or do you mean copies?  The difference
	is significant.

	- Where are these backups going to be stored?  On your server?
	On theirs?  Somewhere else?

	- Note that you can do this with standard tools like dump(8)
	by adding just a little scripting.

	- Also note that backing up a relational DB is best done by
	dumping its contents using its own native tool(s), and then
	backing the results of that up.

*Ability to add/remove subdomains

	- This one is puzzling.  Assuming that you control your own DNS,
	you can add a subdomain at will.  What's your use case for this?

	- Speaking of DNS, diversity is a good thing: at least two
	(preferaby three) servers on at least two different ASNs.

As a general comment, if I were going to build this as spec'd out,
I'd probably use four systems: firewall, web server, DB server,
mail server -- with a fifth if that's where I'm storing backups.
Could this all be put on one?  Sure.  But that means, for example,
that the DB server can't be completely firewalled from the Internet
because the DB server is also the web server.  It also means that
I can't run a different OS on the firewall than on the other servers --
something I very much like to do as a defense-in-depth strategy.

---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug