In this final module, we're gonna have a look at the protocols in the transport layer of the TCP/IP model. We'll also start to cover the application layer which will continue in the next section of the course. At the end of this module, you should be able to understand the function of the transport protocols and identify the difference between TCP and UDP. You'll be able to define ports and sockets, understand packet filtering and stateful inspection firewalls, understand host and port scanning, and understand how we can secure communications with SSL and TLS, and also understand how VPNs work. So far we've looked at the purpose of the protocols in the lower two layers of the TCP/IP model. So, next, we're going to have an overview of what happens in the upper two layers, starting with the transport layer. There are two protocols in the transport layer, TCP and UDP, and their job is to control the flow of data in packets and make sure the data gets to the right application or service when it's sent. We've looked at how the IP protocol is responsible for addressing and rooting data, which is sent in packets, and there's a finite size of each packet which often means that all the data that needs to be sent won't fit in a single packet. In this case, the data needs to be split up into smaller parts and this is called segmentation, and this is one of the jobs of the transport protocols. Different network interface layer standards allow different amounts of data to be placed into a packet.

For Ethernet and Wi-Fi, this is just over 1,500 bytes and that's not a lot of data. So, when data has to be segmented, each segment is placed into a different packet, and this is a bit like sending a book by post and putting each page of the book in a different envelope. So, can you think of any challenges we'd have if we'd done things this way? The challenges will be the same on a network. How do we make sure the receiver knows what order the pieces of data go back together in? And what happens if one or more of the packets don't arrive? And this is where we see the difference between TCP and UDP. TCP stands for Transmission Control Protocol and it's a connection-oriented protocol. Now, this means that before any data's sent, the sender and the receiver agree on how they're gonna control the flow of the packets. And this is done through the exchange of a three-way handshake where the sender and the receiver exchange sequence numbers and agree on how much data's sent in one go and how to identify any errors. So, with TCP every packet's numbered sequentially. So, the receiver knows what order to use to reconstruct the data and it can also tell if any of the packets have gone missing and it can ask for them to be resent. TCP guarantees the delivery of data by doing this and that will be required by some applications such as file transfer apps, for example. On the other hand, UDP is connectionless.

UDP stands for User Datagram Protocol and it's a connectionless protocol. Now, this means that the packets are not sequenced and no agreements take place. So, UDP doesn't guarantee the delivery of packets and there's no error control, but it's faster. There are some apps that either don't need guaranteed delivery or they'll work out whether data needs to be resent themselves. As an example of this, we could consider music streaming. When we stream music over the internet the app might use UDP. The app itself can reconstruct the music data as it's sent, but if an odd packet goes missing, there's really no point in asking for it again because the music's playing and we don't really need it anymore. The app itself can iron out any errors in the data but we might hear a slight glitch in the music if there are too many packets that are missing. Think about how many applications there are running on your device at the same time that can send and receive data over the network. It's usually more than one. When IP assigns an IP address to a packet, this is only sufficient to get it to the right device. And this is a bit like putting an address on an envelope. It gets the letter to the right building, but once the letter's in the building, how do we know who it's for? The same thing happens with IP. So, we need a way to identify which app has sent the data and also which app or service needs to receive the data. Transport protocols do this with port numbers. A port number is a unique value assigned to each app that can send or receive data on the network.

When one app sends data to another, TCP or UDP adds the sending apps port and the receiving apps port to the data before it's put in the packet. So, when the packet arrives at the receiving device the transport protocols now know which app needs to receive the data and also which app on the sender it came from. Remember earlier we looked at client-server? In client-server communications, the client always starts the connection. In this case, the client needs to know what port number to add to the data to get it to the right service on the receiver. Now, to make this easier, we've got something called a set of well-known port numbers. So, port numbers can range from zero to 65,535 for both TCP and UDP. The numbers below 1,024 are reserved for well-known services. If these services always use the same port number, then the client can make an assumption and just add that port number to the data. When the client sends its request it can add its own port number so the server knows what port it needs to add to its reply. The graphic on the slide shows some of the common port numbers for well-known services. For example, web servers will usually use port 80 for HTTP connections and port 443 for secure HTTPS connections. SMTP, that's the protocol used by email servers and as we've seen, DNS, that's a service that resolves names. We could set a web server up to use a different port number. Say, for example, port 81. If we did this, though, the client would need to know this. So in our web browser, we'd have to include the port number in the URL.

So, if we combine an IP address with a transport protocol’s port number, we get a socket and this is a unique endpoint which identifies exactly where the data needs to go, and on which device and to which application. Firewalls help keep networks and devices secure, but what exactly is a firewall and how do they work? Well, the job of a firewall is to allow or block packets coming into or going out of networks, and firewalls make decisions by using rules. With a basic firewall, the rules are based on the source and destination IP addresses and the source and destination port numbers. By default, a typical firewall will block everything coming into a network to protect that network. Now, let's say we've got a web server and we want to make that web server available on the internet. Web servers will usually use port 80 or port 443 depending on whether or not they're using secure connections. So, let's say we wanna allow access to a web server on a network through the firewall. We could create a rule to say that network traffic to port 80 on the IP address of the computer where the web server runs is allowed through. But we'd also need to create a rule to allow the web server to send its responses, and creating these rules for firewalls can actually be quite complicated. So, have a think about your home network. Do you have a firewall to protect it? Well, yes, you do. There's a firewall built into your home router and you've probably never set up any rules on your home firewall, though.

So, how come you can communicate on the internet? Well, the answer to this is that your home firewall is a Stateful Packet Inspection Firewall and this type of firewall protects your home network by blocking everything coming in. Now, usually, when you access the internet, your app's the client and that starts the connection, and when you make a connection out to the internet, your home firewall lets it out but it will keep track of the outbound traffic. Then when a server on the internet responds, the firewall knows its response to an outbound request and it lets it in. So, that way, you can communicate with the internet without having to set up any rules. You'd only need to create the rule if you wanted to host the server on your own network. Now, home routers normally have a basic interface to allow you to create these rules if you ever need to, but make sure you understand you're exposing something on your home network to the entire internet if you ever do this. And also, think about what happens when you take your devices away from your home network. So, the firewall's not protecting them anymore. Now, for this reason, you should also have a firewall on each device to protect it. Operating systems like Windows, macOS and Linux, they've got a host-based firewall built in. But they also have an allow and deny list that makes it easy for you to say what gets through and what gets blocked without having to create these complicated rules. So, make sure you know how to check that your firewall's on and how to allow things through. And this will make a big difference when you're using other networks.

Remember in the first section of the course, we covered one of the techniques used by cyber criminals in the stages of a cyber attack? And this was scanning. Now, although it's not required, many devices will respond to a ping request. Ping uses an internet layer ICMP request and response packet to check whether a device is active on the network. Imagine you were to ping every possible address on a network. The results would show which IP addresses have responded, and it could be used to work out how many machines there were and what addresses are being used on the network. We could then try to send some data to each individual port number on a particular IP address and those responses might show what services were waiting for connections on that IP, and this would give us a list of what services were available. Now, many services will respond in a standard way, with what we call a banner, and the banner often gives information about the software which is running the service. So, from the banner, we might be able to discover that there's a service such as a web server or an email server running, what operating system it's running on, and what software and even which version of the software is being used by the service. And this is the type of technique used by attackers in the service stage of a cyber attack. If an attacker knows what services can be accessed and what software they're using, they've got a good starting point to think how they might set up an attack.

They could research the services they've found and find out if there are any known vulnerabilities for the particular version of the software that's being used. They might also look at default settings and other information to see if they can find anything useful which might help them to get access to the service. The final layer of the TCP/IP model at the top is the application layer and this layer defines the protocols that applications use so they can understand each other's messages. Think about what happens when we speak to each other on the phone. We've got a huge network in place to transfer our voices as data from one phone to the other, but if you think of each other as the applications, we also need to understand what each other are saying. And we do this with an agreed set of commands and a language. The same thing happens when applications send data to each other over the network. They need to have some sort of rules that say how they talk to each other, and these are our application layer protocols. One of the most popular protocols we use on the internet is the Hypertext Transfer Protocol or HTTP. HTTP was invented as part of the World Wide Web and it defines the language that your web browser uses to talk to the web server over the network. HTTP was first used on the web, but it's used in many other applications these days. When we load a web page in a web browser, the browser sends a GET request with the URL telling the server what it wants. The server will send the content or it will display an error message, and you might have seen the common 404 message before.

This is a message that's normally returned by a web server when the content your browsers asked for isn't actually on the web server. If we send information, for example, when we fill in a form, your browser would use a POST or a PUT command to tell the web server it's sending information. To keep our communication secure we'd normally use HTTPS rather than HTTP. The S means that the communications are secure and this is done by another protocol called the Transport Layer Security protocol or TLS. Before TLS we used to use Secure Socket Layer, SSL. Now, although many people still refer to SSL, it's actually outdated and it's been replaced with TLS. The job of TLS is to encrypt the application's data before it's sent and then decrypt it before it passes to the receiving application. So, whenever you access a web page, always check the address bar to ensure that it shows a padlock and an HTTPS connection. Unless you're just doing public things like the weather, it's really important to use a secure connection but especially if you're sending any information that is sensitive. And even when we're using secure connections there is a possibility that the security's been tampered with. If you receive any notifications from your browser about problems with the secure connection, it's normally best to be cautious.

If you need to access or send any secure information on a web page and there are things that don't look right, it's a good idea not to use the site. Another way that we can secure our communications over the internet is to use a Virtual Private Network, or VPN. When we use a VPN all of our communications are encrypted to protect them from prying eyes. So, this can be really useful if you're connecting to public networks. When you use a VPN your network traffic's secured between your device and the VPN server in what's called a tunnel. Imagine it's like a secure communications channel that protects everything that's passing through it. Now, we should understand, though, that once your network traffic reaches the VPN server it will then be sent on its way to the destination as normal traffic. So, you still need to make sure you're using secure connections in your applications. Also, because your traffic gets onto the internet from the VPN server, it appears to have come from the network that the VPN server's attached to. And some people use this to make it appear that they're connected to the internet in a different part of the world. There are lots of commercial VPN companies and some of them offer VPN connections for free. If you're going to use a VPN, do some research to find out what they offer and whether the services are considered as safe. Some free VPN providers might not have good enough security to protect you, or they might make their money by logging your online activity and selling it on to advertising companies.

We're going to finish off this section with another lab session. In this session, you've got Labs 16, 17 and 18. In Lab 16, you're going to use Zenmap to do some network scanning. To do this lab, your student computer needs to be connected to the lab network. Zenmap is the graphical version of a free tool called Nmap and it's used for scanning networks. It's a very powerful tool that can do basic scans like ping scans, all the way through to complex port scans that can reveal a list of services on a device, and it can even identify known vulnerabilities in that service. You're going to use Nmap to try out some of the different types of scans to see what they can reveal about the network. In Lab 17 you'll configure the Windows firewall and investigate how it can be set up to protect the computer. You'll see how the firewall can be used to control access to the file and printer sharing service over the network and also in this lab, you'll investigate port phoning. Remember that we've said that your firewall usually blocks anything coming into your network. If you wanted to make a service on your home network available from the internet, you'd need to configure a rule on the firewall, but also because your router's performing that, you'll also need to do port phoning. So, you'll investigate what this is and have a look at an example of how to set it up on a typical router. And earlier we talked about URLs and how they direct your web browser to a particular file or a location on the internet. And we've mentioned that you should avoid clicking on suspicious links and emails and on websites. So, in Lab 18, you'll investigate how to check suspicious links without having to visit them.

Module 3: Transport protocols

About