There are zillions of internet services out there. And if you're going to harden them Well, the main thing you're going to be doing is use a secure protocol. So if you run into questions on the exam, always think in terms of security. So don't use regular FTP, use a secure FTP, if you're doing some kind of file transfer. If you're going to be using terminals, don't use telnet. Use SSH, if you're going to be doing web stuff, use HTTPS, don't use HTTP.
And by the way, I've got entire episodes that cover these and their port numbers, in particular, the port numbers, so you might want to refer back to those. So you're going to run into lots of questions on the exam. And there's going to be like log files and stuff like that, and you're going to be looking for problems. In general, insecure protocols are always a bad idea. So when you're going through this stuff, make sure when you get questions like this, that you're looking for insecure protocols, and there's nothing better you can do toward any service. Then to dump the insecure and go with the secure.
However, there are two protocols. In particular one, two services in particular that I don't really cover well enough. And I want to take a moment to do that right now. So let's start with good old DNS. DNS has been around since pretty much almost the beginnings of the internet. Now, DNS runs on port 53.
Remember that. And DNS from the beginning has been a completely insecure protocol. I mean, there is absolutely nothing there at all. So let's make sure we understand how DNS works. So here's my computer over here and he needs the IP address for something. So this computer over here goes up to his DNS server.
Every computer has got a DNS server. Now this DNS server is going to march through the DNS hierarchy. I don't want to go through all that let's just add one DNS server up. So this DNS server will then talk to his upstream DNS server in an attempt to resolve Now it could go higher from there. But eventually this DNS server is going to come back with the IP information which is then passed down to the client. The problem here is that it's trivial for let's put another computer in here that acts as a Spoofer.
So he's in essence doing a man in the middle attack, and is intercepting these DNS requests and sending my poor client off to some scary strange place. In the late 1990s, DNS sec was forwarded as a tool to force authentication of DNS servers. To make this work, a DNS sec capable server generates a key pair and it has upstream DNS servers signed them creating new DNS records for each zone. So you'll get records like this. Now, what's important is you'll notice this one is a public signing key. So let's watch how all this works together.
So now once again, the little individual client is going to go up to his DNS sec capable DNS server Make a request. This time the DNS server is going to go ahead and make a request to the upstream server just like he did before. But he's also going to ask for the key from that upstream server. That way he can go ahead and authenticate to verify that he really is getting DNS information from that upstream server. No man in the middle attack fears. There's two things I need you to know about DNS sec.
Number one, DNS SEC is not an encryption. It's purely an authentication tool. So it doesn't hide the DNS requests. It just prevents man in the middle. Also, DNS SEC has become quite popular on public DNS servers. A lot of the most famous DNS servers out there like Google's famous eight dot 888 are fully DNS sec capable.
Okay, the next thing I want to take a quick look at his email Email, at least the original SMTP pop an iMac protocols have always been totally insecure. And this has always been a big issue now. Not that terribly long ago, we came up with secure versions of I'm app, pop an SMTP. So let's go through all of these. Let's start with smtp. Here I have my computer that is local with some email client on it.
And way over here is the SMTP server for the person I want to send email to. Now I'll use DNS to get the IP address of this SMTP server. But once I have that, once I make that connection, all the data that I'm sending is completely in the clear with secure smtp. All we're doing is we're creating a TLS connection between my client system and the SMTP server. So the data is sent with authentication and encryption. Now SMTP by itself will just use Port 25.
But if you're using SSL slash TLS encrypted SMTP, it's going to be either using Port 465 or 587. That was so much fun. Let's do it again. Except this time, let's do it with a map and pop. So here's my individual client system. And here's my I map or pop server, they work equally the same.
Now normally, I would just log in in the clear to my iMac, repop server and get my email. So everything's in the clear, even my passwords in the clear here. Now what we'll use instead is something called start TLS. Start TLS is just an extension to IMAP and pop protocols. All that does is basically my client will sit there and say, Hey, can we make a start TLS connection, my server will respond yes, and it will immediately be put into a TLS encrypted tunnel. Now normally I'm going to use Port 143.
But if we're using SSL TLS encrypted I map it's going to be using Port 993. Pop would normally use 110 but encrypted pop uses port nine 995 the big takeaway here when it comes to internet service hardening is use secure protocols. Make sure that you always know that there's a secure protocol option one available and also make sure you're comfortable with the terminology here. Make sure you know about DNS sec make sure you know about start TLS and the different types of protocols. They are attributed to