AT&T cablemodem port blockage survey

[jc at trillian.mit.edu (John Chambers)]

--------

Bill Horne asked:
| Please explain how bouncing GETS off the server affects it.
|
| From: "John Chambers" <jc at trillian.mit.edu>
| > Here in Waltham it's blocked, too.  Maybe I'll move my  server  to  a
| > higher port. As far as I know, I'm the only one using it, for testing
| > a bunch of CGI ideas.   That  would  probably  also  stop  the  silly
| > attempts  by  advertisers to bounce GETs off the server (all of which
| > are rejected, but I still get one or two an hour).

Well, it really doesn't except for using up a few ms now and then.
Here's the last one, before RCN blocked port 80:

202.155.70.9 - - [10/Aug/2001:19:18:55 -0400] "GET http://www.qksrv.net/click-785061-53501 HTTP/1.0" 403 303

The error_log contains the line:

[Fri Aug 10 19:18:55 2001] [error] [client 202.155.70.9] client denied by server configuration: proxy:http://www.qksrv.net/click-785061-53501

These requests, which seem to be mostly for ads, had been arriving at
a rate of 2-8 per hour.  The only real effect is to increase the size
of the log files.

There was actually another effect at  first,  which  I  considered  a
benefit:   When  I  first  set  up the proxy server (for our internal
machines), it also relayed these requests. Although it wasn't a load,
it  encouraged  me  to learn more about configuring apache as a proxy
server.  This included a few questions to a newsgroup, since some  of
the  info  in  the  documentation  was a bit sketchy, and some of the
examples just didn't work.  Mostly, the instructions for  adding  new
modules to apache didn't work, due to the difficulty of learning what
other modules are required by the ones you want.  The bottom line was
that  it's easier to recompile apache from scratch, because the build
scripts and Makefile know how to do it right.

I'm thinking of also playing with  apache's  site-blocking  features,
since my wife has been making unhappy sounds about the way that a lot
of her Windows software  keeps  making  network  connections  for  no
apparent  reason.   (She notices them because they often produce long
delays, during which the program pops up a Wait...  window that gives
away  what  it's  up  to.)  For  this task, it would be better if RCN
didn't block these attempted bounces.  Then I could test for apache's
ability  to  block  some  (but not all) of them, too.  I suppose this
isn't one of the great burning issues of the day, but I  do  like  to
learn about how well such things work.

I did ask an RCN support fellow about these messages, along with  the
same  question  to  the  newsgroup.  I didn't get much other than the
guess that it's an artifact of  RCN's  occasional  renumbering.   The
suggested  explanation  for the GETs is that the advertisers indirect
through proxies because of the filtering that's  done  by  a  lot  of
firewalls  and  proxy  servers.   This disguises the URL by hiding it
inside a message to another site that isn't being blocked. The reason
it  happens  even  when the server drops the request as above is that
most of the advertisers are basically not very competent.  They often
uses  addresses  of  proxy servers that worked, and don't notice when
the address changes.  And the repeat requests for the same site  show
that  they  aren't  seeing  that  their  ads  aren't getting to their
clients even though my server told them with error 403.

But since it's a trivial load on the machine, it's  not  worth  doing
any more about it.  And there's a minor entertainment value in seeing
all those bounced ads fail.  You get the feeling  that  you're  doing
your little bit to defeat the banner-ad crowd.

The RCN support guy did say that it was something they were  familiar
with, and he didn't seem to think it was a problem for anyone. Not at
the single-digit rate per hour, which  is  less  traffic  than,  say,
downloading the slashdot.com home page once a day.

You could make the argument that I wasted my time in learning how  to
block  something  so trivial.  But it could be a useful experience to
mention in interviews, so I consider it worthwhile.

I do wonder whether any of the advertisers have noticed that  RCN  is
blocking their proxy requests.

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).