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 Date: Tue, 10 Feb 2004 19:37:05 GMT 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 EMC² where information lives
Email: elkind_rob@emc.com
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:
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 Date: Tue, 10 Feb 2004 19:37:05 GMT 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
EMC² where information lives
Email: elkind_rob@emc.com
-- May God Bless you and everything you touch. My "foundation" verse: Isaiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.
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 Date: Tue, 10 Feb 2004 19:37:05 GMT 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
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 ----- Original Message ----- From: "William Warren" <hescominsoon@emmanuelcomputerconsulting.com> To: <Elkind_Rob@emc.com> Cc: <nanog@merit.edu> Sent: Thursday, February 19, 2004 6:48 PM Subject: Re: Verizon clients DOS own site? 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: 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
EMC² where information lives
Email: elkind_rob@emc.com
-- May God Bless you and everything you touch. My "foundation" verse: Isaiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.
-----Original Message----- 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 ___________________________________________________________ Wayne Gustavus, CCIE #7426 Operations Engineering Verizon Internet Services ___________________________________________________________
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:
-----Original Message----- 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
___________________________________________________________ Wayne Gustavus, CCIE #7426 Operations Engineering Verizon Internet Services ___________________________________________________________
-- May God Bless you and everything you touch. My "foundation" verse: Isaiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.
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.
> x.x.255.x isn't a valid IP address > Clue me in? Clue: it's a valid address. -Bill
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) ----- Original Message ----- From: "Bill Woodcock" <woody@pch.net> To: "Geo." <georger@getinfo.net> Cc: <nanog@merit.edu> Sent: Saturday, February 21, 2004 8:03 AM Subject: Re: routing invalid IP addresses
> x.x.255.x isn't a valid IP address > Clue me in?
Clue: it's a valid address.
-Bill
On Sat, 21 Feb 2004, Geo. wrote:
traceroute to 248.245.255.191, that's what made me think it was invalid.
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. :-) 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. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
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.
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. __________________________________________________________ This message was scanned by GatewayDefender 9:19:20 PM ET - 2/21/2004
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.
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 On Sat, 21 Feb 2004, Geo. wrote:
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)
----- Original Message ----- From: "Bill Woodcock" <woody@pch.net> To: "Geo." <georger@getinfo.net> Cc: <nanog@merit.edu> Sent: Saturday, February 21, 2004 8:03 AM Subject: Re: routing invalid IP addresses
> x.x.255.x isn't a valid IP address > Clue me in?
Clue: it's a valid address.
-Bill
On Sat, Feb 21, 2004 at 07:47:46AM -0500, 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.
*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. http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080... 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. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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?
On Sat, 21 Feb 2004, Laurence F. Sheldon, Jr. wrote:
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.
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) -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
On Sat, 21 Feb 2004, Laurence F. Sheldon, Jr. wrote:
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.
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)
Could be. There are a number of things that don't work right if they are not configured correctly.
participants (13)
-
bill -
Bill Woodcock -
Brian Knoblauch -
Christopher X. Candreva -
Elkind_Rob＠emc.com -
Geo. -
Laurence F. Sheldon, Jr. -
Mikael Abrahamsson -
Richard A Steenbergen -
Rubens Kuhl Jr. -
Stephen J. Wilcox -
Wayne Gustavus (nanog) -
William Warren