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?
188.8.131.52] 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: email@example.com serial: 25 refresh: 10800 retry: 3600 expire: 2592000 minimum ttl: 900 900s (15m) routerlogin.com IN A 184.108.40.206 900s (15m) routerlogin.com IN A 220.127.116.11 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 18.104.22.168, 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:
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:
We got that IP number from the first lookup.
NetRange: 22.214.171.124 - 126.96.36.199 CIDR: 188.8.131.52/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:
(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: 184.108.40.206 - 220.127.116.11 CIDR: 18.104.22.168/31, 22.214.171.124/29, 126.96.36.199/32, 188.8.131.52/29, 184.108.40.206/30, 220.127.116.11/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…
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…
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? :-)