We were recently helping a client port some numbers from a traditional telecom carrier (Spectrum) to a VOIP carrier. The scheduled time for the transition came and the PBX was configured to receive calls from the new VOIP trunk. We tested calling the phone numbers and they showed up in the PBX as expected, so all seemed OK.
A few days later, the client (a medical imaging center) called and said “a referring physican is trying to fax something to us and they’re saying that our number is out of service. I called the number and got fax tones so I assumed the doctor’s office just made a mistake.
But – this kept happening. After days of troubleshooting (the client is successfully receiving faxes from other senders all during this time), I was finally able to reproduce the problem calling from one particular phone line. It finally occurred to me that the line I was calling from was a Spectrum line and we had just ported the number away from Spectrum. We checked with the location that was having trouble faxing our client, and – sure enough, they had Spectrum phone lines as well.
Apparently when Spectrum ported the number out, it worked for the rest of the world but if you were originating a call inside the Spectrum voice network – some configuration hadn’t been changed so from that point of view – it thought this was still an “internal” (to the Spectrum network) call but there was no active line there. Hence – the “this number is out of service” recording.
It took a couple of weeks of working with different people at Spectrum to get this corrected, but they finally did. This definitely falls in the Murphy’s Law category (“whatever can go wrong, will go wrong”). I didn’t even know this was a thing that could wrong.
I was helping a client with his web server that is hosted in AWS (Amazon Web Services) EC2. He had gotten a certificate to enable HTTPS but it wasn’t working.
AWS offers free certificates, but you can’t install them into the EC2 web server. In this case, he had set up a load balancer in front of the web server and the Certificate Manager certificate was set up there. This means that when the end user browses to this website, the browser is really talking to the load balancer and load balancer is talking to the web server and passing information back and forth.
I made some assumptions about how he had set up the load balancer forwarding so it took me awhile to get my arms around what was going on. I was configuring the Apache web server to do redirects in the .htaccess file. He wanted to force browsers to use HTTPS and wanted to make “www” his “authoritative URL”, meaning if someone typed “domain.com” into their browser, it would redirect them to “www.domain.com”. (This is a good idea for SEO. Google doesn’t assume/realize that domain.com and www.domain.com are the same website.)
http://domain.com was redirecting perfectly to https://www.domain.com, but http://www.domain.com was not redirecting to https://www.domain.com. I finally realized that the load balancer forwarder was configured via HTTPS and incoming HTTP and HTTPS traffic was forwarding to the webserver over HTTPS, but the load balancer was communicating back to the browser on whatever protocol they came in on. I set up the load balancer to communicate with web server using HTTP and then the redirects flowed properly back to the browser.
It’s easier to configure the load balancer to communicate with the web server using HTTP and just handle the encryption in front of the load balancer.
I’ve been working with a client who has moved to a cloud based VOIP PBX server. In general, I’m a fan of this (and just about anything “cloud”) – but, there are a lot of firewall configurations that need to be just right to make this work well.
This is particularly true if you only have a single server at the hosting data center. Multiple phones at your physical location talking to a server on the other side of your Internet connection is tricky.
A better configuration involves a secure VPN connection between your physical location and your hosting provider. If they’re offering is a single server, they may not be set up to do this. Take a look at setting up a small network inside Amazon Web Services (AWS), Microsoft Azure, or Google Cloud. You should be able to setup a VPN between your physical location and any of these. Once that’s done, from your PBX and phones’ point of view – they are communicating on the same network which is much more straightforward.
Explaining NAT (Network Address Translation) is beyond the scope of this article, but that’s the complicating difference that the VPN eliminates.
About a year ago, Google started flagging unencrypted (available using HTTP as opposed to HTTPS) websites as “Not Secure” in the Chrome address bar. They have also started taking into account whether or not a site has HTTPS for purposes of search rankings. In other words, lack of HTTPS will affect your SEO.
Side note: HTTPS encryption is frequently referred to as SSL and the certificates that allow this are almost always referred to as “SSL certificates”, but this term is not technically accurate any more. SSL was the original cryptographic protocol used for HTTPS but it is obsolete and not considered secure any longer. TLS is what’s used for HTTPS encryption now, but the term “SSL” stuck.
For years, the general consensus was that you needed HTTPS for sites where you entered a credit card or things like that, but that for general information sites (like blogs) there was no need to encrypt the information. That consensus has changed over the last few years.
Most people have historically bought “SSL certificates” from a vendor like GoDaddy with prices starting around $75/year. A few years ago, a service called Let’s Encrypt was introduced by the Internet Security Research Group. Basically – they offer free certificates to encourage people to use HTTPS.
It sounds too good to be true and I was skeptical when I first heard about it, but it’s legitimate. I’ve been using their certificates for about a year. I’ve used them for websites running in AWS and Azure. There’s a little bit of a learning curve in learning how to get them to issue the certificates for you but once you figure it out, you won’t ever need to pay for certificates any more. (Blatant commercial message – we can help you with this learning curve.)
Georgia Tech has suffered a data breach. I hadn’t heard about this until today, when my college age son received a letter from the school letting him know that his personal information (including date of birth and Social Security number) “may have been accessed”.
The Atlanta Journal-Constitution reported that “1.3 million current and former students, faculty and staff members” may have been affected. The article also notes the irony that this happened (twice) to the “world renowned university with lauded computer science programs”.
My son has never been a student at Georgia Tech. He did apply a couple of years ago but never enrolled. I can’t think of any reason why his personal information still needs to be in their systems.
It gets worse.
Two letters from Georgia Tech were in my mailbox today – the one addressed to my son, and one addressed to a former resident who I happen to know. (She taught one of my other sons in high school a couple of years ago.) Her letter was sent to where she lived in high school and used her maiden name, so I’m assuming she also applied to Georgia Tech. (I also know that she didn’t attend Georgia Tech.)
We’ve lived in this house for 16 years, so she applied at least that long ago but I’m betting it was closer to 20 years ago. I really can’t imagine that Georgia Tech needs personal information but applicants who didn’t enroll from 20 years ago.
Too many systems are designed with people thinking of how to get data into the system without any thought of purging it when it’s not needed anymore.
Georgia Tech’s enrollment is ~27,000. If you do some basic math, it’s hard to come up with a good reason for there to be 1.3 million people’s personal information in their systems.
Breaches happen, but I’d much rather do crisis management for a breach affecting 100,000 than 1 million.
Purge your data.
There’s a Windows Server (2012 R2 to be specific) at a client’s location that I occasionally have to login to via RDP. The last couple of months the UI performance was painfully slow. Because I usually just needed to get in, check something quickly, and get out – I hadn’t spent any time tracking down what was going on. (It was still performing its “server duties” adequately so this wasn’t a huge priority.)
The other day, I decided I would spend a few minutes tracking it down. It turned out that there were 51 jobs in a print queue for a printer that was no longer physically on the network, but the printer share was still available on the server.
As soon as I deleted these print jobs (and the printer share), the UI performance was dramatically better. Obviously the shared printer shouldn’t have been left there and I know that the print jobs were taking up RAM, but I was surprised at how drastic the effect on performance was.
I just figured this out yesterday and it’s probably obvious to most people, but since I hadn’t thought of it before – maybe this will help someone else.
You can use host headers to publish multiple websites on the same IP address, but this doesn’t work when using SSL because the host header is encrypted so the web server can’t route based on this value. This means you can only bind 1 web site to a given IP address using SSL.
You can publish Site1, Site2, and Site3 on the same IP address using http and then bind SSL to Site1 on the same IP address, so that all of these would work:
(In DNS, Site1, Site2, and Site3 all resolve to the same IP address.)
What just occurred to me yesterday (when a client of mine pointed it out) was that if you browse to https://Site2, you will get the standard certificate error that browsers give when something doesn’t look right with the certificate. In this case – the certificate is for Site1 but the user is browsing to Site2.
If the user clicks the button to proceed in spite of the error – now you’ve got a problem. They think they are at Site2, but what they are seeing is Site1.
It had just never occurred to me that someone would specifically type https to get to a site that wasn’t set up for SSL.
If you’re like me, it annoys me that Windows Server forces me to tell it why I’m rebooting my server. For years, I’ve thought “I bet there’s a way to turn that off” but just typed “a” in the comment textbox so the OK button would be enabled and kept going.
Today, I finally got around to searching for it. In Group Policy, go to Computer Configuration, Policies, Administrative Templates, System and look for the Display Shutdown Event Tracker. If you set it to Disabled, it won’t show the Shutdown Event Tracker.
P.S. – I have to confess – as I was typing this, I clicked Restart on my server to look at the Shutdown Event Tracker to see what the label on the textbox was (where I type “a”). As soon as I clicked Restart, the server rebooted – because I had just configured this setting. I had to laugh at myself for being annoyed that the Shutdown Event Tracker didn’t come up, when I had just turned it off and was writing a post about how to turn it off. 🙂