Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Connections to Port 7?

3 views
Skip to first unread message

Brian Hampson

unread,
Sep 9, 1999, 3:00:00 AM9/9/99
to
My logs recently indicated a rash of attempted connections to port 7/tcp
on one of our hosts. It happened simultaneously from a few hosts. Seems
odd. Does anyone know what the reason for this might be? Prelude to an
attack attempt? Why did 3 hosts contact within the same second?

Thanks,

B.

--
Please send administrative requests to ad...@ASL.CA

Brian P. Hampson ASL Analytical Service Laboratories Ltd
System Administrator, Vancouver, BC (604)253-4188
----------------- http://www.ASL.CA/ ----------------------------

I'm not speaking for the company <- They made me say that.


Rich Wales

unread,
Sep 9, 1999, 3:00:00 AM9/9/99
to
Brian Hampson wrote:

> My logs recently indicated a rash of attempted connections
> to port 7/tcp on one of our hosts. It happened simultaneously
> from a few hosts. Seems odd. Does anyone know what the
> reason for this might be? Prelude to an attack attempt?
> Why did 3 hosts contact within the same second?

The same thing happened to me a few weeks ago. It turned out to have
come from DoubleClick (a company which manages ads on Web sites). They
are using a load-balancing software product called "Global Dispatch",
which ties into their DNS code, probes other hosts, and measures network
transmission delay times in order to figure out which of several Double-
Click machines happens to be closest to a given user's site.

The abstract idea is reasonable, but I have some gripes about the way it
is being implemented. First, network latency (transmission delay time)
really should not be measured using a high-overhead protocol like TCP.
Second, there is no reason (or excuse) to retry a connection attempt if
you get a "connection refused" error (as opposed to "timeout" or other
errors), since -- by definition -- "connection refused" means the target
host did respond, and you can use the time it took for you to get the
"connection refused" error for your network latency figure.

I brought up these points with DoubleClick's tech support people, and I
tried to explain how I felt it was in DoubleClick's best interests to
pressure the "Global Dispatch" vendor (a company called Resonate) to
modify their network probing code. I have no idea if anything will come
of my efforts, though.

Rich Wales ri...@webcom.com http://www.webcom.com/richw/

Atlacatl

unread,
Sep 9, 1999, 3:00:00 AM9/9/99
to
This may give a better idea:
http://www.isi.edu/in-notes/iana/assignments/port-numbers

Brian Hampson <br...@ASL.CA> wrote in message
news:7r8jtb$10b2$1...@spider.asl.ca...


> My logs recently indicated a rash of attempted connections to port 7/tcp
> on one of our hosts. It happened simultaneously from a few hosts. Seems
> odd. Does anyone know what the reason for this might be? Prelude to an
> attack attempt? Why did 3 hosts contact within the same second?
>

Brian Hampson

unread,
Sep 9, 1999, 3:00:00 AM9/9/99
to
Atlacatl (t...@FUSPAMmail.com) wrote:
: This may give a better idea:
: http://www.isi.edu/in-notes/iana/assignments/port-numbers

I know what the port is. (tcp/echo) It turns out that it was, as was
suggested, that it was the good folks at doubleclick.net wasting more
bandwidth.

Barry Margolin

unread,
Sep 9, 1999, 3:00:00 AM9/9/99
to
In article <1999090916072...@wyattearp.stanford.edu>,

Rich Wales <ri...@webcom.com> wrote:
>The abstract idea is reasonable, but I have some gripes about the way it
>is being implemented. First, network latency (transmission delay time)
>really should not be measured using a high-overhead protocol like TCP.

I suspect they use TCP because many sites filter out UDP and ICMP.
Although I think that most sites that do this will also filter out TCP
connections to low ports as well.

>Second, there is no reason (or excuse) to retry a connection attempt if
>you get a "connection refused" error (as opposed to "timeout" or other
>errors), since -- by definition -- "connection refused" means the target
>host did respond, and you can use the time it took for you to get the
>"connection refused" error for your network latency figure.

Quite true. And it also points to a way to get around the filter problem I
mentioned above. Many sites that filter TCP still allow it to high ports,
for the benefit of FTP's data connections (unless they force their users to
use passive mode or a proxy). So the product could attempt a TCP
connection to some unused high port and measure the response time of the
expected "connection refused" response. This is essentially the same
philosophy as traceroute, which uses high UDP ports.

BTW, at least Global Dispatch connects to the mostly innocuous Echo port.
Cisco Distributed Director, a similar type of product, makes a TCP
connection to the DNS port. We've gotten many complaints from people
asking why our DD's are trying to perform zone transfers from them.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

RobertGraham.com

unread,
Sep 9, 1999, 3:00:00 AM9/9/99
to
Brian Hampson wrote:
>
> My logs recently indicated a rash of attempted connections to port 7/tcp
> on one of our hosts. It happened simultaneously from a few hosts. Seems
> odd. Does anyone know what the reason for this might be? Prelude to an
> attack attempt? Why did 3 hosts contact within the same second?

For future reference, just questions are answered in my "firewall-seen FAQ":
http://www.robertgraham.com/pubs/firewall-seen.html#port7

--

Robert Graham
robn @ NetworkICE DOT com

Brian Hampson

unread,
Sep 9, 1999, 3:00:00 AM9/9/99
to
RobertGraham.com (not...@example.com) wrote:

Thanks. If you would like any additions, there's always TCP port
2064...distributed.net bovine client proxy port.

B.

0 new messages