TR Forums

Envision yourself for a moment as the standard TR Gerbil who has accrued enough computer hardware to host a small datacenter. Now suppose you wanted to host a website or API or something externally to the world, but refuse to pay for an expensive cloud server when you have all the compute power you need sitting in your basement! Let's also suppose you have wanton disregard for that clause in your ISP contract saying you will not host servers from home.

A web request is to travel through the following chain. As safely as possible, solve for #3 in terms of software, protocols, and/or hardware:

1. Interwebs
2. Cheap cloud server with static IP and nginx or other routing software
3. ????
4. profit! TR Gerbil hardware

ie: What is the safest way to serve requests from #1 to #4 and back? And is this a viable/safe enough setup in the first place?

EDIT: please see this post for an updated wordy schematic: viewtopic.php?p=1356217#p1356217

The biggest problem in regards to whatever contract you have with your ISP isn't so much going to be "no servers" (because that's de facto null: every kid playing $MULTIPLAYER_FPS on $CONSOLE has a 1 in $NUM_OF_PLAYERS of being a server just as one example out of many) but whether or not you are offering a commercial service. That's guaranteed to be contraindicated, even if they're relatively lax about enforcing it.

So that's the first question: Is this for laughs/personal use, or are you trying to do something serious?

Don't, it's not worth it for a website or API (not sure what that "something" is so I'll leave it). That "expensive cloud server" is in fact a $5-$10 per month VPS with someone like Linode or Digital Ocean for a website or an API.

TravelMug wrote:

Don't, it's not worth it for a website or API (not sure what that "something" is so I'll leave it). That "expensive cloud server" is in fact a $5-$10 per month VPS with someone like Linode or Digital Ocean for a website or an API.

Yeah, I would agree with this too, but I'm interested in hearing what he's trying to do and why.

Yup. I highly recommend Linode. You can get their lowest tier VPS for $5/month, which is probably less than you'll pay for electricity to host a physical server yourself (unless you're talking about something ridiculously low power like a Raspberry Pi). For your $5/month you basically get console/root access to a bare VM with a fast connection to the internet. Install whatever you want on it (within reason, of course).

IIRC Digital Ocean's bottom-end service is also $5/month and should be similar to Linode's.

I use digitalocean's $5 a month tier and have never had a problem.

Glorious wrote:

So that's the first question: Is this for laughs/personal use, or are you trying to do something serious?

Mostly for personal use.

bthylafh wrote:

IIRC Digital Ocean's bottom-end service is also $5/month and should be similar to Linode's.

Glorious wrote:

I use digitalocean's $5 a month tier and have never had a problem.

I'm on RAMNode's $35/year plan and it's incredible.


I'm disappointed, TR. I did not ask for VPS reviews. Now let's dream for a moment: How would you actually answer my original post?

I imagine you could set up some sort of VPN and proxy requests from the cloud box's web server through to your box.

Or don't even run a web server on the front end system, and just set up a reverse SSH tunnel that forwards port 80 back to yourself.

As others have said just stop at step 2 and do that.

I do run some internet accessible services at home. I can check on my UPS status, schedule MythTV recordings, manage my UniFi WiFi network, and start torrent downloads. These are all running on a Linux box with Ubuntu 16.04 doing automatic updates (and I manually login about once a week to check if the updates need a reboot). There's a strict firewall on it making sure that those are the only things exposed, and I back it up to an external drive that sits unplugged the rest of the time.

One thing about the cloud if you do go that way: cloud = someone else's computer
That entity can vanish at any time. Make sure you have a full backup at your house and can restore it to another cloud provider in case your current provider vanishes in a puff of smoke. The internet is littered with stories of people who have lost everything when something went wrong with their provider.

If you are going to do it yourself, skip step 2 and get a dynamic domain name. Run a Linux box with apache and a firewall and automatic updates enabled. Don't be surprised if it gets pwned. Also take in to account how that traffic to and from your server will limit your internet link.

Duct Tape Dude wrote:

Mostly for personal use.

That's where you need to clarify. You'll get away with personal use, but if you are doing something that either is commercial or at least looks commercial, you could very easily find yourself forced into a more expensive business-class connection or get yourself terminated.

Duct Tape Dude wrote:

I'm disappointed, TR. I did not ask for VPS reviews. Now let's dream for a moment: How would you actually answer my original post?

Well my original response was asking for more details, because I'm bemused by the existence of #2.

I mean, 1) is internet, 4) is home server, right?

Just put those hands together, no? Why would you route it through a VPS or anything else first?

What are you trying to do?

The reason I'm asking is because while I have a VPS with some things, I also have several servers on my home network that are (sorta) open to the internet: I host minecraft, various web front-ends, ssh server, etc...

just brew it! wrote:

I imagine you could set up some sort of VPN and proxy requests from the cloud box's web server through to your box.

Yeah this is closer to what I was hoping to have detailed: is a reverse proxy (maybe over an SSH tunnel) "safe enough?"

Glorious wrote:

That's where you need to clarify. You'll get away with personal use, but if you are doing something that either is commercial or at least looks commercial, you could very easily find yourself forced into a more expensive business-class connection or get yourself terminated.

Hence the wanton disregard in my original post. Can we just disregard all the things I asked to disregard and even if for complete funsies, focus on the problem I outlined?

Glorious wrote:

What are you trying to do?

The reason I'm asking is because while I have a VPS with some things, I also have several servers on my home network that are (sorta) open to the internet: I host minecraft, various web front-ends, ssh server, etc...

A direct connection to the internet is exactly what I'd like to avoid. Basically, I already have #2 working as a static VPN host for #4. But suppose I felt like hosting personal projects or websites (or even a Minecraft server) locally and wanted it safely accessible to the outside--is using #2 in conjunction with #3 safer than just going straight to #4?

The point is I have all this hardware sitting at home and a static IP with enough horsepower for a solid firewall/routing service in the cloud. How can I make home-hosted services work as safely as possible for me?

Edit: Alternatively, what do self-hosted businesses do? They must have a static IP with some sort of firewall/router to serve requests to different internal servers. How can what I'm asking be so different?

Duct Tape Dude wrote:

A direct connection to the internet is exactly what I'd like to avoid

Well, you have a direct connection to the internet already. Do you mean that you don't want your home's IP address to have any open ports?

Fundamentally, however you route it, if your home servers have ports open to the internet at large, it's essentially the same risk. Adding another hop via your own VPN or a poor man's version of the same with some sort of tunneling scheme doesn't particularly make any meaningful difference, security-wise.

If anything, if you are going through a VPS provider, you're going to see MORE access attempts, because those ranges are hit harder by brute-force service triers than the residential ranges.

It really does come down to what you are trying to do. If it's just for you, you could always VPN into your home network as the only way anyone can get in. You could could firewall+whitelist all the places you or your friends use to access the internet, and if you need to add a place easily you could leave ssh up on a VPS with white-listed way into your firewall so you can add new IPs as needed.

Duct Tape Dude wrote:

Edit: Alternatively, what do self-hosted businesses do? They must have a static IP with some sort of firewall/router to serve requests to different internal servers. How can what I'm asking be so different?

It's not, but the security comes from the firewall.

Are you asking how to make your home connection canonical? That is, some way by which you can reliably address it from anywhere on the internet?

If that's the question, than without getting a static IP assigned from your ISP (which may or may not be possible or free), you can get a dynamic domain for your home connection from any number of services online, some of which are free. notfred mentioned this.

At that point you either run a simple service that notifies your dynamic domain provider whenever your IP changes, or you use your router because some of those have that functionality helpfully built-in already (you just have to configure it).

Voila. You can reach your home computer from anywhere. From there, we get into the unrelated security question, because unless your ISP is doing NAT themselves (unlikely), you're completely addressable already, *you* just don't know precisely how. There's zero security in that.

That's where the aforementioned firewall comes in, and it doesn't matter quite so much where it runs. There's no real magic in having the firewall run in the cloud, even if your own cloud. If we get to the point of layering against DoS, you're already in trouble with your ISP.

Duct Tape Dude wrote:

just brew it! wrote:

I imagine you could set up some sort of VPN and proxy requests from the cloud box's web server through to your box.

Yeah this is closer to what I was hoping to have detailed: is a reverse proxy (maybe over an SSH tunnel) "safe enough?"

If your primary concern is safety, I think you're focusing on the wrong area. If there's a vulnerability that's exploitable over HTTP, a proxy or tunnel isn't going to do squat to protect you. What you should be looking at is how to wall off the server so that if it gets compromised, it doesn't have access to the rest of your LAN.

When I was self-hosting I was fortunate enough to have two static IPs. I put my LAN router on one IP, and the server on the other -- outside my LAN. IOW, I treated my own server as potentially hostile/compromised.

If you've got Comcast for your broadband maybe you could connect the server via the public WiFi hotspot functionality to get some isolation from your LAN?

Failing that, I'd probably run the server in a NATted VM, and set up the host's routing tables to restrict the host's access to the LAN. At least this way, an attacker would need to be able to compromise the web server and break out of the VM sandbox and find a privilege escalation exploit on the host to cause trouble.

Glorious wrote:

Well, you have a direct connection to the internet already. Do you mean that you don't want your home's IP address to have any open ports?

Ah of course. Yes that's what I meant.

Glorious wrote:

Fundamentally, however you route it, if your home servers have ports open to the internet at large, it's essentially the same risk. Adding another hop via your own VPN or a poor man's version of the same with some sort of tunneling scheme doesn't particularly make any meaningful difference, security-wise.
If anything, if you are going through a VPS provider, you're going to see MORE access attempts, because those ranges are hit harder by brute-force service triers than the residential ranges.

That sort of answers the question, and that's also a good point.

Glorious wrote:

It really does come down to what you are trying to do. If it's just for you, you could always VPN into your home network as the only way anyone can get in. You could could firewall+whitelist all the places you or your friends use to access the internet, and if you need to add a place easily you could leave ssh up on a VPS with white-listed way into your firewall so you can add new IPs as needed.

I see what you mean, but the point of a website on the world wide web is to access it worldwide.

Glorious wrote:

It's not, but the security comes from the firewall.

Ah, perfect. What's the best option to set one up on the VPS then? Pfsense?

Glorious wrote:

Are you asking how to make your home connection canonical? That is, some way by which you can reliably address it from anywhere on the internet?

Yeah I guess so, though not my home connection but rather, services hosted in my home. I am familiar with no-ip's services and used them for several years before getting a static IP'd VPS.

Glorious wrote:

If we get to the point of layering against DoS, you're already in trouble with your ISP.

Right, that's half the point of the VPS: it has some built-in DoS protection, whereas my home services do not.

just brew it! wrote:

What you should be looking at is how to wall off the server so that if it gets compromised, it doesn't have access to the rest of your LAN.
When I was self-hosting I was fortunate enough to have two static IPs. I put my LAN router on one IP, and the server on the other -- outside my LAN. IOW, I treated my own server as potentially hostile/compromised.

Yes! Now we're talking! So because I only have one IP address (2 if you count ipv6, and up to 6 if you count the X1 box, but that's another story...) would something like a router that supports VLANs be safe enough? ie: confine all traffic from #1 to #4 to its own VLAN, and remote in to any machine in that chain to admin it?

just brew it! wrote:

If you've got Comcast for your broadband maybe you could connect the server via the public WiFi hotspot functionality to get some isolation from your LAN?

HAHA!! That is quite creative! The hotspots are pretty locked down and might be perfect for that sort of thing (assuming I don't host on port 80). I think I still have a few in range despite getting my own router.

just brew it! wrote:

Failing that, I'd probably run the server in a NATted VM, and set up the host's routing tables to restrict the host's access to the LAN. At least this way, an attacker would need to be able to compromise the web server and break out of the VM sandbox and find a privilege escalation exploit on the host to cause trouble.

Very sensible. I prefer running everything in a VM anyway, but could probably use some suggestions or guides on how to set up the routing specifically. I guess the idea would be to confine all web traffic to its own VLAN, firewall everything, then whitelist each connection as needed. How might one do that? pfsense? iptables?

Duct Tape Dude wrote:

A web request is to travel through the following chain. As safely as possible, solve for #3 in terms of software, protocols, and/or hardware:

1. Interwebs
2. Cheap cloud server with static IP and nginx or other routing software
3. ????
4. profit! TR Gerbil hardware

ie: What is the safest way to serve requests from #1 to #4 and back? And is this a viable/safe enough setup in the first place?

Fun! I like games like this. I'm going to assume that the "cheap cloud server" is being used as a simple frontend, like a "customer" interface (even if the only "customer" is you), and it is (retrieving data from / interacting with services on) systems located in your so-called basement.

I worked at a company that did something very similar - they had a website portal that was used by customer equipment to check for updates, etc. This lived off in the cloud for reasons. But it connected back to some internal systems that hosted the data. The internal systems pushed updates out to the cloud system, then customer equipment would check in with the cloud system and pull the update down from there.

In their case since they were pushing updates out to the cloud server they used certificate-based SSH connections, and they were only active when data was being pushed. But depending on the interactivity of what you are hosting I don't know if that would be feasible. If you're talking about hosting, say, a frontend for some compute power, and you need to be able to send data into the compute cluster and also retrieve real-time statistics from it, I think you would be best served with a VPN tunnel from the frontend in to your home systems.

I'd set the cloud system up as the "host" of the VPN connection and then set your home router/firewall (which ideally would have all of this server stuff on a separate VLAN / firewall zone from your normal home things) to connect as a client to that VPN. Home firewall gets configured to allow certain data in and out of the VPN tunnel based on whatever protocol your API / webservices require. This allows for any troubles that might arise from the dynamic IP that most home internet connections have.

I'd also take the step further that any internet-bound traffic from your basement servers (update checks, etc) go up through the tunnel and then out to the internet from there. The thinking is that this way you have control over traffic in and out of your home servers from both your cloud front-end and your home device. But that would probably require something more robust than a "cheap cloud server" if you're pushing a lot of traffic out of it. You could always split-tunnel your external traffic if the home servers are only doing automatic update checks.

As to "safe" I'm just working on the assumption that you mean "won't break my stuff at home". If your home firewall keeps your home stuff totally isolated from your basement server stuff, then even if someone pwned your front-end and got in to your servers, you wouldn't need to deal with cross-contamination of anything, and you could also just go into your home firewall and block all inbound/outbound traffic to the basement servers while you remediate, but crucially, you could do it without taking netflix offline.

As for "safe enough" well... that depends on what sort of services you host and what kind of visibility your front-end has. if it's just to host some stuff you're running for yourself the chances are it will be basically ignored (although in that case I would recommend a dynamic DNS service and just skipping the "cheap cloud server" altogether, using just your home firewall to secure connectivity inbound to a webserver that acts as your interface in lieu of the cloud system). But if it's something you're providing to customers or posting about on a community forum to offer a service to fellow users, that gets you much more exposure and increases risk of attack. That's something you'd need to decide for yourself.

I've been kicking around the idea of using my Synology NAS's backup capabilities while outside of the house; right now devices just back up photos etc when on the home wi-fi. I've even considered trying to host my own email from time to time. But I'm not yet entirely sold on risk vs. benefit vs. having to maintain it all myself. If I were doing something for a home business that would make life easier / save me money vs. hosting it all in the cloud, it'd be a much easier decision IMO.

[edit] um, I see many posts since I started typing this this morning. Feel free to ignore it if it turns out it wasn't relevant.

Is your API Token-based? Is it rate-limited? I'd worry some internet schmuk quickly abusing your data and exposing your scheme to your ISP when lots of data starts flowing to outbound requests.

deruberhanyok wrote:

I worked at a company that did something very similar - they had a website portal that was used by customer equipment to check for updates, etc. This lived off in the cloud for reasons. But it connected back to some internal systems that hosted the data. The internal systems pushed updates out to the cloud system, then customer equipment would check in with the cloud system and pull the update down from there.

...

Thanks so much, deruberhanyok. This is the kind of TR discussion I was looking for. To me, "cheap cloud server" means plenty of traffic but limited disk/RAM/CPU. It gets expensive to store things quickly in the cloud or do heavy computation, but traffic is measured in hundreds of gigs.

deruberhanyok wrote:

I'd also take the step further that any internet-bound traffic from your basement servers (update checks, etc) go up through the tunnel and then out to the internet from there.

That seems like a sufficiently paranoid suggestion to be worth using.

deruberhanyok wrote:

As to "safe" I'm just working on the assumption that you mean "won't break my stuff at home".

Spot on.
Lots of other great things in there but to save everyone's scroll wheels I won't requote it all. I very much appreciate the suggestions and hope I summed most of them up below. Thank you.

steelcity_ballin wrote:

Is your API Token-based? Is it rate-limited? I'd worry some internet schmuk quickly abusing your data and exposing your scheme to your ISP when lots of data starts flowing to outbound requests.

The VPS comes with some DoS mitigation and as for API token/size/rate limits, it depends on whatever personal project I'm working on. But both those things are worth implementing.

I think among everyone's suggestions I'm seeing that if I were to do this, I should:
-Whitelist all traffic required to function
-Encrypt all connections perhaps by key-based ssh tunneling or VPN
-Isolate the entire stack from the rest of my home connection via VLAN/NATted VMs
-Force all internet activity from the home servers through the frontend server
-Convince all clients to be good citizens with rate/token/size limits
-Consider a dynamic DNS and move the frontend server directly to the home connection

Anything else I'm missing or suggested tools to accomplish this?

I'm sure I'll get some advice from others, but ...

What do you want to do that a Linux box with Nginx installed won't do? Hang to linux box on your local lan, set your router to port forward 80 and 443 to the linux box local IP address, and you are done. If you want to SSH into the box externally, set it up the sshd configs to only accept certain IDs, domains, etc.

Most ISP never change your "dynamic" IP address, so in reality this is not an issue. You can spend $11.99/year at GoDaddy if you want "www.trgerbil.com" (it's available!) and just change the A records as required.

Most ISP will not care about the traffic, unless, as someone else noted, you are using the site to make money. Then you need to get Business Class.

There must be a bazillion articles on the interwebs about this...like this one
https://arstechnica.com/gadgets/2012/11 ... eb-server/

You won't be able to do an email server, since most ISPs block all the needed ports to prevent spam (again, you have to go Business Class).

Duct Tape Dude wrote:

Thanks so much, deruberhanyok. This is the kind of TR discussion I was looking for. To me, "cheap cloud server" means plenty of traffic but limited disk/RAM/CPU. It gets expensive to store things quickly in the cloud or do heavy computation, but traffic is measured in hundreds of gigs.

Depends what you mean by "limited", which in turn depends on what you're trying to store/compute. Linode's $5 plan includes a gig of RAM, 20GB of SSD, and one CPU core. Unless you're expecting a lot of traffic and/or planning to store a lot of multi-media, that's more than big/fast enough for a personal site. Unless you're planning to do on-the-fly media transcoding there's probably not much in the way of heavy computation either.

JBI wrote:

Depends what you mean by "limited", which in turn depends on what you're trying to store/compute. Linode's $5 plan includes a gig of RAM, 20GB of SSD, and one CPU core. Unless you're expecting a lot of traffic and/or planning to store a lot of multi-media, that's more than big/fast enough for a personal site. Unless you're planning to do on-the-fly media transcoding there's probably not much in the way of heavy computation either.

Yeah, I ran

`stress-ng --cpu 1 --cpu-method pi --metrics-brief -t 30`

on my digitalocean instance, which is provisioned directly equivalent to JBI's linode example, and it was only 50% of the performance of my 3.6 ghz skylake.

Depending on what you are doing you might be able to knock that down to 25%, maybe, but for per-core compute performance it clearly really isn't as if you have that much more of it available at home. The DO VPS /proc/cpuinfo reports a single core of a E5-2630Lv2 which I have to presume isn't exclusively provisioned to me, but I'd suspect if I did more rigorous spot-checking the performance likely wouldn't differ all that much even though I obviously have no SLA to that effect.

Ok so here's a revised setup draft I've come up with, yet to be implemented. Anyone care to give thoughts?

--Cloud VPS--
1. Multiple websites or services or APIs or whoknowswhats
2. Firewall
3. nginx reverse proxy, translates each service to a respective port on #5
--Home--
4. Cable modem
5. Firewall + router serving subnets A, B, and C. Inbound requests are routed to a respective server on #6 only if they are from #3.
6. Subnet A: Web server VMs, respond to requests from #5
7. Subnet B: Critical data VMs like databases or backups, respond to requests from #6
8. Subnet C: Home devices/wifi/etc, largely isolated from #6 and #7

--Subnet rules--
Subnet A is only allowed whitelisted inbound connections that originate from proxy in #3 or select SSH access from Subnet C.
Subnet A is only allowed whitelisted outbound access to the open internet (ex: Ubuntu package servers)
Subnet B is only allowed whitelisted inbound connections from Subnet A or select SSH access from Subnet C.
Subnet B is only allowed whitelisted outbound access to the open internet (ex: Ubuntu package servers)
Subnet C is allowed whitelisted inbound access and blacklisted outbound access to the internet.
Subnet C is not allowed any inbound access from Subnet A or B.

The biggest vulnerability I can think of is if something on Subnet C was compromised separately and somehow got to Subnet A or B. But for me and my personal projects, that appears to be nearly the same risk as without this crazy setup, especially if the web thinks my projects' IP is #2 (first firewall) instead of #4 (my cable modem).

I was thinking of using an intranet-only jump server to vet SSH access between subnets, but thought maybe that's overkill. I'd prefer key-based authentication wherever possible. I know the firewalls in #2 and #5 should really be from different vendors in case of attack.

Lastly, I'm not sure if it's a Good Idea^TM to host #1 and #2 on the same cloud VPS. Again, maybe it's overkill to separate them?

You are massively overthinking this. Unless you go around trolling you are not going to be the recipient of a targetted attack. What you are vulnerable to is exploits in your stack on the back end and those are likely to fly straight through your fancy nginx reverse proxy and firewall e.g. Little Bobby Tables

You might as well just host straight raw to step 5.

Well I am going to take a different argument then the rest of these guys.
What is your upstream on your internet?

Most home services are much slower upstream than downstream. i.e. 30/5. a typical business even doing minor hosting is 100/100 or greater.
also hosting on that 30/5 link users accessing data dig into your personal bandwidth.
Then take into account that some ISPs try to limit connections (not as big a deal was it was years ago, they had to loosen this one for modern gaming)

Over all your home internet link is not enough to host a website with more than a few users.

That's way too complicated, and now you have two points of failure: If either your home connection *OR* your VPS is unreachable/kaput, your system doesn't work.

It also does nothing from security, the first 3 steps do *literally* nothing: by running a reverse proxy on a VPS all you are doing is adding a hop and you are adding it on a range of addresses that's guaranteed to get more drive-by brute attempts.

This is the kind of thing where you are going to add a tremendous amount of work for yourself with no benefit, and because it's so complex, you're likely to misconfigure or overlook something that causes you problems or even unnecessary security holes.

Arvald wrote:

Well I am going to take a different argument then the rest of these guys.
What is your upstream on your internet?

Most home services are much slower upstream than downstream. i.e. 30/5. a typical business even doing minor hosting is 100/100 or greater.
also hosting on that 30/5 link users accessing data dig into your personal bandwidth.
Then take into account that some ISPs try to limit connections (not as big a deal was it was years ago, they had to loosen this one for modern gaming)

Over all your home internet link is not enough to host a website with more than a few users.

Unless he's trying to run a commercial site or host a lot of multimedia content, I don't see the bandwidth being a big deal. Not sure what his service is like, but my cable internet (Comcast) service has 25 mbit upload, which should be fine for a low-traffic site.

It's more a matter of what he expects to gain from this. If the required storage is less than what comes with a cheap VPS, then just host everything on a VPS and be done with it. If dynamic IP is acceptable and bandwidth needs will be modest, hosting it directly (without the extra VPS hop) makes sense.

The sort of thing he's proposing could make sense if he wants the fixed IP, and has a lot of content which he wants to make available, but which will be infrequently accessed (and therefore won't chew up his upstream bandwidth). Yes, it's a pretty narrow use case.

Glorious wrote:

That's way too complicated, and now you have two points of failure: If either your home connection *OR* your VPS is unreachable/kaput, your system doesn't work.

It also does nothing from security, the first 3 steps do *literally* nothing: by running a reverse proxy on a VPS all you are doing is adding a hop and you are adding it on a range of addresses that's guaranteed to get more drive-by brute attempts.

This is the kind of thing where you are going to add a tremendous amount of work for yourself with no benefit, and because it's so complex, you're likely to misconfigure or overlook something that causes you problems or even unnecessary security holes.

I agree... if your goal is to be more secure, the first 3 steps
1) create more attack surface
2) get you a crazy amount of "drive-by brute force attempts", likely multiple per minute, 24/7. You won't believe how many friends you have in China.
3) will make you maintain IPtable filters regardless

JBI wrote:

Unless he's trying to run a commercial site or host a lot of multimedia content, I don't see the bandwidth being a big deal. Not sure what his service is like, but my cable internet (Comcast) service has 25 mbit upload, which should be fine for a low-traffic site.

Even a 5mbit connection is fine for anything non-commercial and non-multimedia. Heck, you could run a Pandora quality "internet Radio" service for 20 users no problem on that, or stream 3 netflix-SD quality videos on that.

roncat wrote:

You won't believe how many friends you have in China.

It turns out that "root" is a REALLY common name over there!