Verizon clients DOS own site?

Mailman List Mirror (Read Only)
1

Anyone else seeing this, it started up a few weeks ago.

We have a number of home users that VPN to our corporate network who are
using Verizon DSL as their Internet provider. While they are connected to
the corporate network they are generating tons of hits to
'supportcenter.verizon.net' (206.46.187.54)

Here's a basic trace:

host.on.my.net -> 206.46.187.54 TCP 49980 > HTTP [ACK]
host.on.my.net -> 206.46.187.54 HTTP GET /sbconfigservlet/sbconfigservlet
HTTP/1.1

206.46.187.54 -> host.on.my.net HTTP HTTP/1.1 404 Not found

Here's the text of the transaction:

host.on.my.net

GET /sbconfigservlet/sbconfigservlet HTTP/1.1
Accept: */*
Accept-Language: en
If-Modified-Since: Mon, 09 Feb 2004 22:49:47 GMT
User-Agent: Motive HTTP Client
Host: supportcenter.verizon.net
Connection: Keep-Alive
Cache-Control: no-cache

reply from 206.46.187.54

HTTP/1.1 404 Not found
Server: Netscape-Enterprise/6.0
Content-type: text/html
Content-length: 292

<HEAD><META HTTP-EQUIV="Content-Type"
CONTENT="text/html;charset=ISO-8859-1"><TITLE>Not
Found</TITLE></HEAD><H1>Not Found</H1> The requested object does not exist
on this server. The link you followed is either outdated, inaccurate, or the
server has been instructed not to let you have it.

This repeates over and over again many times a second while the client is
connected.

My guess is that these client files are the ones that initiate the
conversation from the client:

C:\program files\verizon\online\supportcenter\bin\matcli.exe
C:\program files\verizon\online\supportcenter\bin\mpbtn.exe

I'm seeing millions of hits to this site from just our ~100 users using
Verizon per week. I have to think that world wide, Verizon clients are
generating enough traffic to DOS themselves.

I've tried contacting Verizon via email but I haven't received a response
and their tech support had no information on this. Although we're now
blocking this site and trying to clean up the clients, this is still
generation a lot of noise on our network. Any ideas on how to get Verizon to
take a look at this?

Any input is welcome.

Thanks,

Rob Elkind

  Information Security Engineer

2

this is part of the autodiag software installed by the VZ cd....you will need to go through your remotes and uninstall that stuffe..

Elkind_Rob@emc.com wrote:

3

Or add a
127.0.0.1 supportcenter.verizon.net
entry to the remotes hosts file. If and when they solve this or the software
is removed, remove the entry; traffic will be killed locally before entering
your VPN.

Rubens

4

From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On
Behalf Of Elkind_Rob@emc.com
Sent: Thursday, February 19, 2004 3:57 PM
To: nanog@merit.edu
Subject: Verizon clients DOS own site?

I've tried contacting Verizon via email but I haven't
received a response and their tech support had no information
on this. Although we're now blocking this site and trying to
clean up the clients, this is still generation a lot of noise
on our network. Any ideas on how to get Verizon to take a
look at this?

Calling the NOC numbers available via the puck.nether.net site would be a
good start (info recently updated from older Bell Atlantic references).

This sounds like part of the support tools installed as part of the VOL
setup discs. I'll fwd info onto VOL to confirm, though website IS valid
(perhaps there is an issue interacting w/ VPN setup).

Any input is welcome.

Thanks,

np

5

I have already claled VZ about htis issue as i see it tons here too..their response:
We only provide connectivity and we do not take actions in terms of port filtering or blocking.

Wayne Gustavus (nanog) wrote:

6

We had an attack here last night and the attack traffic was coming from an
IP address of x.x.255.x which isn't a valid IP address yet the traffic was
being routed over the internet (as far as I can tell anyway). When I
attempted to track down the source I found our cisco routers wouldn't accept
the address as valid so it was not possible to null route or trace the
traffic.

Has anyone else ever seen this before? Clue me in?

Geo.

7

x.x.255.x isn't a valid IP address

    > Clue me in?

Clue: it's a valid address.

                                -Bill

8

We had an attack here last night and the attack traffic was coming from an
IP address of x.x.255.x which isn't a valid IP address yet the traffic was
being routed over the internet (as far as I can tell anyway). When I
attempted to track down the source I found our cisco routers wouldn't accept
the address as valid so it was not possible to null route or trace the
traffic.

*GASP* Traffic with an invalid IP address being routed over the Internet?
Dear god NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! Please
say it isn't so. Oh the humanity.

Actually, it is a perfectly valid IP address. You just need to turn on ip
subnet-zero.

That means nothing however, as there is traffic with invalid source
addresses routed over the Internet all the time. Routing has nothing to do
with source IP, and everything to do with dest IP. If you want to filter
it, use an acl.

Has anyone else ever seen this before? Clue me in?

I don't think an ordinary clue stick will do... Hrm perhaps a stick of
clue dynamite is in order.

9

traceroute to 248.245.255.191, that's what made me think it was invalid.

I did get the answer, I was being stupid and trying to use IP route instead
of an acl. Thanks to everyone who replied, even the "nooooooooo" guy.

Geo. (I'm not the cisco guy, I was just the only one working last night)

10

Geo. wrote:

We had an attack here last night and the attack traffic was coming from an
IP address of x.x.255.x which isn't a valid IP address yet the traffic was
being routed over the internet (as far as I can tell anyway). When I
attempted to track down the source I found our cisco routers wouldn't accept
the address as valid so it was not possible to null route or trace the
traffic.

Has anyone else ever seen this before? Clue me in?

Invalid? Really? I used to manage a small collection of cisco routers
and I don't recall any of them complaining about such an address.

What color is the sky there?

11

Could be related to perhaps not having "ip subnet-zero"? (I have no idea,
but the old thingie about highest and lowest network being
broadcast/network address might be applicable in this case)

12

Mikael Abrahamsson wrote:

13

It has nothing to do with the x.y.255.z -- the 240.0.0.0/4 is IANA reserved
space. If you had given the whole IP in the first place you could have
saved yourself some abuse. :slight_smile:

You are right in the sense that it has been recommended for a while that ISP's
filter invalid traffic outbound from their network, to prevent their
customers from spoofing. However, given the number of incidents of
hijacking recently, it's entirely possible whoever is using this actually
has their own BGP feed.

[westnet]:~$ whois 248.245.255.191

BW whois 3.4 by Bill Weinman (http://whois.bw.org/)
Copyright 1999-2003 William E. Weinman
Request: 248.245.255.191
from whois.arin.net:43 [cached Sat Feb 21 16:18:16 2004 UTC]

OrgName: Internet Assigned Numbers Authority
OrgID: IANA
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
StateProv: CA
PostalCode: 90292-6695
Country: US

NetRange: 240.0.0.0 - 255.255.255.255
CIDR: 240.0.0.0/4
NetName: RESERVED-240
NetHandle: NET-240-0-0-0-0
Parent:
NetType: IANA Special Use
Comment: Please see RFC 3330 for additional information.
RegDate:
Updated: 2002-10-14

OrgAbuseHandle: IANA-IP-ARIN
OrgAbuseName: Internet Corporation for Assigned Names and Number
OrgAbusePhone: +1-310-301-5820
OrgAbuseEmail: abuse@iana.org

OrgTechHandle: IANA-IP-ARIN
OrgTechName: Internet Corporation for Assigned Names and Number
OrgTechPhone: +1-310-301-5820
OrgTechEmail: abuse@iana.org

# ARIN WHOIS database, last updated 2004-02-20 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.

14

If you had given the whole IP in the first place you could have

saved yourself some abuse. :-)<<

Now what fun would that have been? Ya gotta let these guys spit out abuse
once in a while, heck it's not often they know the right answer <g>...

Anyway, I'm currently investigating to see if it's possible the traffic was
coming from another local machine. The machine's admin mentioned a few
things that sounded to me like there were 2 way connections from this IP
involved instead of just spoofed UDP.

Geo.

15

248.x.x.x is in 'Class E' space which is invalid on the Internet...

x.x.255.x are perfectly valid addresses, indeed we have 193.0.255.0/24..

subnet-zero isnt relevant either, this would be for eg a class B using a
255.255.255.0 subnet mask, since we dont bother with classful addressing and
we're not talking about the local addressing policy this isnt of relevance.

you have some confusion with 'ip route' and acls, these do not fulfill the same
purpose.. ip route wont help yuo as that is used to control the route to the
destination and that would be your legitimate host. an acl could help tho, you
can safely deny 'access-l 100 den ip 240.0.0.0 15.255.255.255 any' to block
anything with a similar source address. just in case you get too excited with
your acls, dont go arbitrarily blocking other addresses (multicast, bogons,
rfc1918 [10.x.x.x, 192.168.x.x] else u may break some stuff!)

and just to clarify your problem of how these invalid addresses were 'routed' ..
as above packets are routeed based on destination only, you can spoof and put
junk in the source and it will still traverse the internet quite legitimately.

Steve

16

Anyway, I'm currently investigating to see if it's possible the traffic

was

coming from another local machine. The machine's admin mentioned a few
things that sounded to me like there were 2 way connections from this IP
involved instead of just spoofed UDP.

    Anybody hook up a new Macintosh lately? OS X seems to spew traffic in
that range. It appears to be some optional component as they don't all do
it, about half of ours do it. I haven't cared enough to track down what
exactly is doing it.

17

    Anybody hook up a new Macintosh lately? OS X seems to spew traffic in
that range. It appears to be some optional component as they don't all do
it, about half of ours do it. I haven't cared enough to track down what
exactly is doing it.

Not on this segment, only two linux boxes directly on the wire and two NT
boxes behind a Pix 506e. Whatever was going on has stopped now so I'm just
going from log fragments the admins are emailing me. It looks like someone
was trying to exploit apache/php on one of the linux boxes using spoofed udp
from that IP address I posted.

Geo.