[olug] Cox and Web Servers

[William E. Kempf]

From: "Daniel G. Linder" <dlinder at iprev.com>
William E. Kempf wrote:
[snip..]
> But the fact of the matter is, I have legitimate reasons to
> run a web server
> that are not business related in any way, so to require a
> business-account
> to do so is wrong.

Mr. Linder wrote:
>True, I would like to have the ability to setup the personal web server on
my wifes computer and have a' >static http://homecomputer.myhouse.com and
let her and my Mother-in-law view the latest photos of our
>daughter by just copying the files to a local directory.

This is half the purpose for running my own web server, yes.  They other
half is for educating myself, since I'm a professional in this field.  And
you can go only so far with this by accessing the site via localhost.

> Then they should revoke all of our e-mail accounts, since
> there's a larger
> danger for trojans there.  I'm sorry, but I don't buy this argument.


Mr. Linder wrote:
>True, but that is different.  If you were running an e-mail /server/ on
your home machine which was open as
>a relay then it could be churning up a lot of bandwidth.

Far less then the bandwidth people were using while, say, Napster was at its
height.  Or from people who use Netmeeting or other video conferencing
services.

Mr. Linder wrote:
>I will agree that e-mail Trojans/viruses are just as big of a problem but
there is only so much Cox can do
>before their security practices would start to border on illegle (scanning
of packets, checking the to/from
>fields, etc.).

I'd agree with this, but port blocking doesn't help them secure anything (at
least not much).  I can come up with several other practices that would be
far more beneficial to them and their customers as far as security is
concerned.  A simple example would be to provide their customers with
firewall software (the cost of which would be reclaimed after only 2-3
months of service, so loss of revenue shouldn't be a factor), which would by
default block port 80, as well as every other port, but would allow the
users who are educated enough to do so to open the ports they need back up.
Again, that's just one simple solution that would be more effective then
simple port blocking.

> The "BUSINESS ORIENTED" (shouting was yours) offerings are
> overpriced for
> the use I have here.  And the purposes for which I'd use a
> web site are
> unlikely to effect the amount of bandwidth I use in any
> significant way, and
> are valid "HOME-USER ORIENTED" tasks, not "BUSINESS ORIENTED"
> tasks for
> which I should be charged a higher premium.  Cox is certainly
> welcome to
> throttle my bandwidth consumptions in any way to ensure this,
> but simply
> blocking ports doesn't solve the issue of bandwidth (since
> users can use
> other ports, or run other servers that will be MUCH more
> bandwidth hungry
> than HTTP).  These arguments are cop outs, and not valid reasons for
> blocking ports.

Mr. Linder wrote:
>[Apology time: I forgot that ALL CAPS is shouting, I was using the caps to
ensure that people saw the
>differences between the two lines....  I wish /bolding/ would actually work
in ASCII e-mails, but that is a
>different thread! --Dan]

No problem... I just didn't want to be accused of shouting myself.

Mr. Linder wrote:
>I think that both of us have the same reason for wanting a web server /at
home/ -- to share files with friends
>and family.  And you're right, /this/ use is not nearly the load that a
e-commerce web site would be.  Again,
>it would be impossible/tough to have an automated process within Cox filter
"family photo" web sites out of
>the "e-commerce" web sites auto-magically...

I honestly don't think it needs to be done "auto-magically".  Cox isn't
preventing people from running e-commerce sites through any technical means
today.  If they are concerned about people doing this (which they should be)
then they need to take a proactive approach.  But by not blocking port 80
they make it a lot easier to determine if someone's doing so.  As it is,
they have no idea what port to scan to determine if I'm running an
e-commerce site.

Mr. Linder wrote:
>As a side note, the throttling bandwidth is a layer 2 level action that is
done at the /cablemodem/ level.
>Since the cablemodems can't see layer 3 and higher, it couln't throttle the
HTTP traffic while letting
>e-mail/websurfing/etc go through unthrottled.

1)  I didn't mean to imply that they should throttle HTTP specifically.  It
would be enough to throttle the entire bandwidth.

2)  When I say "throttle", I don't even necessarily mean to imply actually
controlling how much bandwidth I can use physically.  It would be enough to
monitor how much is used, and if it goes over a specified amount charging
the user for the extra bandwidth.

You see, I don't think that many people are actually going to abuse the
system and try and run an e-commerce site.  Even if they do, I don't see
port blocking as a means to curtail this.  Further, I don't think you can
universally apply "security" or "bandwidth" concerns as a reason to block
ports, since other services that are allowed can be much worse in these
regards, and your casual home user may actually use more bandwidth and have
a larger security risk then even an e-commerce user.

> In any event, the link to the dyndns FAQ looks like it will solve my
> problem.  So despite the blocking I'll be able to accomplish
> what I want.
> (Which, BTW, means that port blocking has addressed neither
> security nor
> bandwidth concerns, basically proving my stance here.)

Mr. Linder wrote:
>Keep us informed on the dyndns and tell us how it works.

Works like a charm.  If you've already got a custom DNS with them (I do)
it's an extremely trivial 30 second configuration done from their web site.
I didn't care for the cloaking features, since it causes my domain's URL to
be the URL displayed in the address bar no matter where the user navigates
through hyper links.  Even navigating outside of my domain leaves this URL
in the address bar.  But I don't have any real problems with not cloaking
the URL, so long as (computer illeterate) users can easily navigate to my
site through the friendly URL sans-port numbers.

Bill Kempf