Interesting bit on Netgear

Router Land

Sometimes there are folks who camp on ‘nearly right’ names with the intent of capturing your information. It’s very easy to type”FOO.com” when you ought to type “FOO.info” or “FOO.net” or “FOO.biz”. So I’m always a bit extra cautious about it, but even with that, I sometimes screw up too. Well, the Netgear WiFi router I sometimes use has a default login screen reached via a URL. I like to type it in as a number, like 192.168.1.1 (or whatever you set it to), but sometimes I use the default name. It knows this name and harvests it from any passing data stream to decide you want to log in to it (no DNS server config required…) That name? “www.routerlogin.net”

Well, being in a hurry, I’d typed “www.routerlogin.com”… Oops. At that point your login credentials can be compromised by someone giving you what looks like a valid login screen, but isn’t. I’d lost track of every prior login, so wasn’t sure if I had been spoofed… So who IS the one I typed?

67.222.132.213] returned a non-authoritative response in 141 ms:

Answer records
name	class	type	data	time to live
routerlogin.com	IN	SOA	
server:	nstwo.netgear.com
email:	dns@netgear.com
serial:	25
refresh:	10800
retry:	3600
expire:	2592000
minimum ttl:	900
900s	(15m)
routerlogin.com	IN	A	54.200.99.0	900s	(15m)
routerlogin.com	IN	A	54.218.118.186	900s	(15m)
routerlogin.com	IN	NS	nstwo.netgear.com	900s	(15m)
routerlogin.com	IN	NS	nsone.netgear.com	900s	(15m)
routerlogin.com	IN	NS	nsfour.netgear.com	900s	(15m)
routerlogin.com	IN	NS	nsfive.netgear.com	900s	(15m)

Looks like Netgear set up that address as a place to park Name Servers (as in ns as in nstwo, nsthree…)

Good job Netgear! So not only did they do a bit of ‘look ahead’ and assure that net address was theirs, but they put something useful there too. I’m no longer worried that I hit that link by mistake…

I do wonder if their gear is configured to look to their name servers as a ‘server of last resort’, or if it’s just a public service they are running. At some point I’ll need to trap those addresses and see if any traffic goes to them (other than my typos ;-)

It is also nice to have a set of 4 to 5 more name servers to add to my canonical list for “when all your usual name servers are down, what to try next?”. More than once I’ve had to pull that tattered bit of paper out of the binder to config a nameserver, any nameserver, so that I could get to the internet to find the nameservers I really wanted… Nothing like midnight at a down site with no services at all, trying to bring up internet service on fresh hardware, and not having a DNS server IP to put in for your first DNS lookups… (Much less of an issue now that Google has camped on some simple numbers like 8.8.8.8, but still… in a DDoS attack on them, or just because you don’t really like letting Google know what you are doing, it is nice to have alternatives.)

You can also look it up here:

http://www.whois.com/whois/routerlogin.com

That has a bit more information, like where Netgear is located:

Domain Name: ROUTERLOGIN.COM
Registry Domain ID: 110412749_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.networksolutions.com
Registrar URL: http://networksolutions.com
Updated Date: 2016-11-23T08:45:13Z
Creation Date: 2004-01-22T05:00:00Z
Registrar Registration Expiration Date: 2019-01-22T05:00:00Z
Registrar: NETWORK SOLUTIONS, LLC.
Registrar IANA ID: 2
[...]
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registry Registrant ID: 
Registrant Name: Netgear, Inc.
Registrant Organization: Netgear, Inc.
Registrant Street: 350 E PLUMERIA DR
Registrant City: SAN JOSE
Registrant State/Province: CA
Registrant Postal Code: 95134-1911
Registrant Country: US

Doing the lookup the other way is also interesting:

http://www.whois.com/whois/54.218.118.186

We got that IP number from the first lookup.

NetRange:       54.218.0.0 - 54.218.255.255
CIDR:           54.218.0.0/16
NetName:        AMAZO-ZPDX4
NetHandle:      NET-54-218-0-0-1
Parent:         AMAZON-2011L (NET-54-208-0-0-1)
NetType:        Reallocated
OriginAS:       AS16509
Organization:   Amazon.com, Inc. (AMAZO-47)
RegDate:        2013-05-22
Updated:        2013-05-22
Ref:            https://whois.arin.net/rest/net/NET-54-218-0-0-1
[...]
OrgName:        Amazon.com, Inc.
OrgId:          AMAZO-47
Address:        EC2, EC2 1200 12th Ave South
City:           Seattle
StateProv:      WA
PostalCode:     98144
Country:        US
RegDate:        2011-05-10
Updated:        2014-10-17
Ref:            https://whois.arin.net/rest/org/AMAZO-47
[...]
OrgName:        Amazon Technologies Inc.
OrgId:          AT-88-Z
Address:        410 Terry Ave N.
City:           Seattle
StateProv:      WA
PostalCode:     98109
Country:        US

So it looks like the Silicon Valley company Netgear is doing business with Amazon out of Washington State in Seattle. Using their AWS cloud server for their DNS provider. Or something like that. So if I’m looking to diversify my DNS providers “upstream”, I’d like to know if they are all running on AWS out of Seattle or not…

(Why I don’t have a Vanity Site Name all my own… I don’t particularly want all my PII in a globally searched public database… remember than when thinking of registering for a domain name. FIRST get your ‘corporate identity and P.O.Box’ lined up along with your personal redirection mailbox for the Corp reg and your burner phone and… Sigh. And they wonder why companies get hacked so easily… maybe because we put absolutely everything on line when it ought not be? )

Note that they used their own server for the IP lookup in that first name lookup link, so we can find out about them, too:

http://www.whois.com/whois/67.222.132.213

(You can get this same information with Unix / Linux commands like nslookup, dig, etc. but I’m showing web pages so everyone has a source they can use from any machine).

NetRange:       67.222.132.193 - 67.222.132.216
CIDR:           67.222.132.194/31, 67.222.132.208/29, 67.222.132.193/32, 67.222.132.200/29, 67.222.132.196/30, 67.222.132.216/32
NetName:        HELP-ORG--LLCNET
NetHandle:      NET-67-222-132-193-1
Parent:         DFW-DATACENTER (NET-67-222-128-0-1)
NetType:        Reassigned
OriginAS:       AS30277
Customer:       HELP-org- LLC (C02959243)
RegDate:        2012-04-13
Updated:        2012-04-13
Ref:            https://whois.arin.net/rest/net/NET-67-222-132-193-1


CustName:       HELP-org- LLC
Address:        PO Box 1860
City:           Ocean City
StateProv:      NJ
PostalCode:     08226
Country:        US
RegDate:        2012-04-13
Updated:        2012-04-13
Ref:            https://whois.arin.net/rest/customer/C02959243

OrgAbuseHandle: DFWDA-ARIN
OrgAbuseName:   DFW Datacenter

[...]
OrgName:        DFW Datacenter
OrgId:          TMS-52
Address:        3000 Irving Blvd
City:           Dallas
StateProv:      TX
PostalCode:     75247
Country:        US
RegDate:        2003-08-19
Updated:        2012-06-05

That web page (“network-tools.com”) is in HQ in New Jersey, but running a data center in Dallas Fort Worth.

This kind of “Digging In” is valuable when setting up your DNS “upstream” provider list. You want real geographic diversification and real network diversification and real data center diversification, not just different names all running on the same Cloud Service in the same data center when the Richter 9+ quake sends a 200 foot tsunami over Redmond…

Pi Ville

FWIW, I’ve now got most of my internal machines and routers ONLY pointing at my Raspberry Pi B+ Alpine as my caching DNS server. It is barely showing any load from that plus occasional squid proxy work. Some things still point to the Telco box directly, so get it’s DNS server list (if brought up on that subnet / WiFi and not on the private side). Oh, and it’s my internal Time server too. So lots of time (ntp), DNS, web page cache hits, and Advertising killed via DNS traffic is no longer going out the wire to the Big Bad World.

My little Pi sits in the middle, caching and sharing and blocking the crap. On 24 x 7 x 365 with no issues to speak of. It sits, caseless at the moment, on the wooden desktop, sporadically blinking at me ;-) It’s been running for a couple of years now, and shows no signs of getting tired. (The first year+ on Debian, now Alpine). I’ve thrown some powerfails at it, and many restarts. Just keeps going.

I’ve added a USB Thumb drive / stick, just to see if it would take the added power draw. It did, but on reboot didn’t. Taking the WiFi Dongle out left enough power to get through the boot phase, but clearly to make it a WiFi Access Point AND file server will take either a larger more proper power supply (it is on a cheap $2 USB square thing, the same one that undervolted the M2 on full 4 core use…) or perhaps a Powered USB Hub for more devices.

For now, I’m just sporadically adding services to it, and it keeps taking them.

Well, back to the real world…

Me, lately?

For anyone wondering, I’ve been having an infrastructure day or two. The 3? “blown boot” BerryBoot chips (where I’d updated a kernel and discovered once again that BerryBoot has “special” kernel handling and that bricks the chip) finally got a ’round tuit’ and were restored from backup images on disk. I took the 4? newer chips without backups, and made backups. Etc. etc.

The WD 111 MB disk with UFS file systems on it is not recognized by the Pi at all!.

I was going to just use gparted to make it a Linux disk, but the MBR / boot blocks / whatever are not seen as anything, so it doesn’t even get a /dev/FOO name. Looks like I’ll have to plug it into a FreeBSD box, or maybe even (GASP!) MS Windows to get something that just blasts it back to Fat32 for me. (Had something like this once before, and IIRC, XP was happy to nuke it to fresh… Linux not so much… BSD wants to leave it BSD…) One more reason not to do much with BSD. Disks just don’t play well with others once they have “gone there” via partd on BSD / making UFS file systems.

I saved off the blown chip contents, so “someday” I can compare them with the originals and see what gets busted in a kernel update on BerryBoot systems. (They don’t boot, but the file system is fine – it’s some config thing.) Just be advised that any “update” or “upgrade” that changes the kernel will blow your BerryBoot boot. (The actual squashfs BB kernels and Data Files look intact, so you out to be able to suck those off to a different BB chip and recover. I’m going to test that thesis sometime too… but not now.)

Bottom Line is just this: Use a NOOBS installed direct boot chip if you expect to do things like Kernel Upgrades and / or convert one to Devuan. I’ve got a 1/2 finished posting on that, just up to the “brick the chip” step… The other 1/2 to be done once I get a NOOBS chip build with Debian and get the Debian to Devuan convert to work…(which prompted the ‘backup / recover’ chips so I can use one process…) Do Not Update A BerryBoot Kernel In Place. You must create the kernel, make it a squashfs format, then manually put it into the BerryBoot structure on the chip. A process I’ve not done yet, but have read up on (now… after the fact…). It doesn’t look too hard, but it isn’t what “scripts you find on the internet” expect unless explicitly BerryBoot.

OK, I’ve also now got 75 tabs of “interesting things” open in my Tablet browser (starting to slow it down as memory swap to chip sets in…) and I need to clear about a dozen of them out. So expect a few “quick postings” on small things, or maybe another Grab Bag posting. Guess what I’m doing the rest of the evening? :-)

Subscribe to feed

Advertisements

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits and tagged , , , , . Bookmark the permalink.

7 Responses to Interesting bit on Netgear

  1. Training technicians to set up routers was a concern for me given my limited software skills. It was a great day when Verizon provided me with a flash drive containing programs that automated the router set up.

    Back in 2005 it took a Verizon technician 15 minutes to set up a router to support a FTTH (Fiber To The Home) system. With the flash drive the set up took one minute!

  2. philjourdan says:

    The “routerlogin” DNS name is a recent addition I think. I do not recall it 16 years ago when I got my first one (it still works – off name brand that probably is no longer made – it only did 10mb Ethernet). So I always type in the IP. But that is good to know about perhaps going to the wrong site. Also good to know netgear is on top of it (I only do netgear and Belkin – Hate linksys and D-link is just too flaky).

  3. Gail Combs says:

    E.M. Tips – November now crashes my system if I try o load it.

    Time for December me thinks….

  4. Gail Combs says:

    O/T
    A bit of chasing Geomagnetic and climate papers. link
    Some rather interesting bits and pieces in that ignored subject.

  5. llanfar says:

    @Gail since this morning, also causing my iPad to error/reload on the page (works if I cancel reload once the text is in…guess there’s too many embeds).

  6. Larry Ledwick says:

    On the changing magnetic declination:
    Yes magnetic drift in declination is moving fast enough that it is noticeable over a few decades. I have old USGS maps of locations in Colorado (1955 series) which showed a magnetic declination of 12 degrees east. The current values on maps produced over the last decade show it as about 8 degrees. A local USGS map produced in 2011 shows a magnetic declination of 8 deg 46 min east of north.

    This handy calculator from NOAA shows that for the same USGS quad the declination is currently 8 deg 24 min east of north changing at a rate of 6 minutes west per year.

    https://www.ngdc.noaa.gov/geomag-web/

  7. Gail Combs says:

    Larry, the subject tickled my curiosity bump. Especially the paper showing correlation between salt water currents and Geomagnetic.

    It looks like a nice ‘Dig Here’ rabbit hole for when I have a lot of time on my hands.

Anything to say?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s