Transcript for:
Understanding Packets and Networking Protocols

Hey everyone, welcome back to another video here on TryHackMe. I'm John and today we're going to be taking a look at the room packets and frames. Understand how data is divided into smaller pieces and translated across the network to another device.

That being said, let's go ahead and dive right into task one, what are packets and frames? Packets and frames are small pieces of data that when forming formed together make a larger piece of information or a message. However, they are two different things in the OSI model.

A frame is at layer 2, the data link layer, meaning there's no such information as an IP address at that specific layer. Think of this as putting an envelope in or within an envelope and sending it away. That's the encapsulation process that we mentioned in a previous room.

The first envelope will be the packet that you mail, but once it is opened, the envelope within still exists and contains data. And this is called a frame. So you can see that we're taking the different data structures that are present at each layer.

and causing we have encapsulation and subsequent de-encapsulation breaking that down so that everything is processed correctly and here you can see again this process is called encapsulation which we discussed in room 3 the osi model at this stage it's safe to assume that when we are talking about anything ip addresses we're talking about packets when the encapsulating information is stripped away we're talking about the frame itself packets are an efficient way of communicating data across network devices such as those explained in task 1. Because this data is exchanged in small pieces, there is less chance of bottlenecking occurring across the network than large messages being sent at once. So, if we were trying to send a lot at once, we might slow down and potentially take down the network. That can happen. But by sending small packets, we have a far, far smaller chance of that actually occurring.

For example, when loading an image from a website, this image is not sent to your computer as a whole, but rather small pieces. where it is reconstructed on your computer. Take the image below as an illustration of this process.

The dog's picture is divided into three packets where it is reconstructed when it reaches the computer to form the final image. So here we can see it's broken down into smaller pieces of information and then it can be rebuilt back up into that big message or in this case the picture of the dog. Packets have different structures that are dependent upon the type of packet that is being sent. As we'll come on to discuss, networking is full of standards and protocols that act as a set of rules for how the specific packet in question is handled on a device.

With the internet predicted to have approximately 50 billion devices connected by the end of 2020, things quickly get out of hand if there are no standardization. Let's continue with our example of the internet protocol. This is something that we discussed in a previous room. If this is not necessarily making sense, I recommend backtracking and reviewing these concepts before continuing on. A packet using this protocol will have a set of headers that contain additional pieces of information to the data that is being sent across the network.

Some notable headers include time to live. This is the field that accepts an expiration timer for the packet to not clog up your network if the packet in question never manages to reach a host or escape. So if that goes down to zero...

it just is deleted or discarded by a router. This field provides integrity checking for protocols such as TCP IP. If any data is changed, this value will be different from what was expected and therefore corrupt. And that's a sign that it needs to be resent. The IP address of the device that the packet is being sent from so the data knows where to return to.

And then we have the destination address. The device's IP address that the packet is being sent to so the data knows where to travel next. Let's dive into the questions.

What is a name for a piece of data when it does not have IP addressing information? I believe that should be packet in this specific case. And there we go.

What is the name for a piece of data when it, rather this is when it does have the IP addressing information. How about when it does not? That would be a frame. And there we go. Let's move into task two, TCP IP with a three-way handshake.

TCP, or the Transmission Control Protocol for short, is another one of these rules used in networking. This protocol is very similar to the OSI model that we have previously discussed. in the room three of this module so far.

So just to break this down and take a step back, OSI model and the TCP IP model, they're two different ways of talking about how things happen on a network. So this is different from just TCP. This is a combination of the TCP IP protocols into another model.

So just taking a step back because this can be a little confusing when it's first approached. So the TCP IP model consists of four layers and is arguably just a summarized version of the OSI model. These layers are the application layer, so this is the top one, transport, internet, and then the network interface.

Very similar to how the OSI model works, information is added to each layer of the TCP model as the piece of data or packet traverses it. As you may recall, this process is known as encapsulation, where the reverse of this process is called deencapsulation. One defining feature of TCP is that it is connection-based.

which means that TCP must establish a connection between both a client and a device acting as a server before data is sent, because that session needs to be built up. Because of this, TCP guarantees that any data will be received on the other end. This process is known as the three-way handshake, which is something we'll come to discuss shortly.

A table comparing the disadvantages and advantages of TCP is located below. And I won't go into this, this was covered in a previous room, just know that TCP does... Uh, it's gonna... It... Ensure that your data that is sent and received is accurate and what you're getting is what you were promised But it can have a bottleneck because of that TCP packets contain various sections of information Known as headers that are added from encapsulation.

Let's explain some of the crucial headers in this table below So first we have the source port The source port rather this is the value the port opened by the sender to send the TCP packet from This value is chosen randomly out of the parts 0 to 6, 65,535 that aren't already in use in that time. And then we have the destination port. This value is the port number of an application or service that is running on the remote host.

The one receiving the actual data, so the server in this case. For example, a web server running on port 80. Note, this isn't necessarily always a server. This can go back and forth. Just know that the server is within our... general metaphor that we're using right now.

Unlike the source port, this value is not chosen at random. We have our source IP, which we covered previously. This is the IP that's sending the data in the way of destination, which is where it's going to go. Next, we have the sequence number. When a connection occurs, the first piece of data transmitted is given a random number.

We'll explain this more in depth further on. And then we have the acknowledgement number. After a piece of data has been given a sequence number, The number for the next piece of data will have the sequence number plus one.

We'll explain this more again further on in the room. Next, we have the checksum, which we've covered previously. This is a number that is used by a mathematical formula that guarantees that the data in the packet has not been corrupted.

If it doesn't match what it should match, then the packet needs to be resent. Then we have the data, which is where the data, i.e. the bytes of the file, is being transmitted and stored. And then we have flags.

This header determines how the packet should be handled by other device during the handshake process. Specific flags will determine specific behaviors, and we'll talk about that here in just a little bit. Next, we'll come on to discuss the three-way handshake, the term used for the process used to establish a connection between two devices.

The three-way handshake communicates using a few special messages. The table below highlights the main ones. First, we have SYN, or step one, A SYN message is the initial packet sent by a client during the handshake.

This packet is used to initiate a connection and synchronize the two devices together. We'll explain this more further on. Next, we have the SYN ACK step. This packet is sent by the receiving device or the server, in the case of the metaphor that we're using, to acknowledge that the synchronization attempt from the client has succeeded. And then we have the ACK step.

The acknowledgement packet can be used by either the client or server to receive or to acknowledge that a series of messages slash packets have been successfully received. So what we're doing here is we're setting up the handshake. First we have, and we'll go down to the actual setting up the connection.

this diagram here. We have Alice that wants to talk to Bob. First, Alice is going to send a SYN packet, which is requesting to synchronize and open the connection.

And then Bob sends back a SYN, which is the synchronization number. Again, this is just so that we know that our packets are going in order because it's going to increment by one. And we're also going to acknowledge that we've received that SYN packet.

So we have SYN and ACK sent back. And then Alice needs to acknowledge that we have received that SYN packet setting up. the actual synchronization of the packets there and confirming that the connection is active by sending another acknowledgement packet. Let's go ahead and talk about the other few flags here. Number four, we have the data, which is once the session has actually been established, the data is sent via data message.

So that's the actual flow of information back and forth. Once we're done sending data, we'll send a FIN packet, which is used to cleanly or properly close the connection after it has been complete. So say I'm done with my video call with you.

and you want to, we want to close the connection. We'll send a FIN packet, and then we end it with a RESET packet. Or this packet, it's another way of breaking down the communication. It abruptly ends all communication.

This is the last resort and indicates there was some problem during the process. For example, if the service or application is not working correctly, or the system has faults such as low resources. So typically, we're going to send this FIN packet to end the actual connection, but if there are problems, we'll send a RESET packet. Again, this is how the uh...

Opening that handshake, the three-way handshake actually happens in diagram form. Any data sent is given a random number. And again, this is what I broke it down before.

So we're going to start with a random number, and it's going to be incremented by one each time we move through this step. And that's just confirming that the data sent and received has been done so in the correct order. And you can see that broken down here as well. TCP closing a connection. Let's quickly explain the process behind TCP closing a connection.

So, first TCP will close a connection once a device has determined that the other device has successfully received all of the data. Again, I briefly touched on this before, but we can see how we're sending the FIN packet here and then we're acknowledging it, sending another FIN packet MAC, and then sending another acknowledgement packet. So, very similar to the three-way handshake, except these are two separate requests that happen here. But, again, we're just breaking down that communication very much in the same way that we set it up. Let's go ahead and dive into the questions.

What is the header in the TCP packet that ensures the integrity of data? That is the checksum. There we go.

Provide the order of a normal three-way handshake. That is going to be SYN, SYN, ACK, and then ACK. There we go.

Let's move into task three, practical handshake. Help Alice and Bob communicate by reassembling the TCP handshake in the correct order in the static lab attached to this task. Enter the value of the flag given by completing this task. Let's go ahead and dive in.

So first off we're going to use sin to set that up and then sin act to confirm it and then we send another act to confirm that we've set this up. Let's see, I'm not quite sure what's going on here. We want to send our data. and then we acknowledge that we've received that data and then we are going to let's see i'm going to guess can close our connection here and then we're confirming that we're done and then we're acknowledging that we're all done there we go so you can see that we started our communication there and then we went ahead sending our data confirmed that we were done sending our data and then tore down the connection and there we go let's move it to task 4 udp ip The User Datagram Protocol is another protocol used to communicate data between the devices. Unlike its brother TCP, UDP is a stateless protocol that doesn't require a constant connection between two devices for data to be sent.

For example, the three-way handshake doesn't occur in this case, nor is there any synchronization between the devices. Recall some of the comparisons made between these two protocols in Room 3, the OSI model. I'm going to go ahead and skip past this since we've gone ahead and already covered this.

If you want to, make sure that this is in your notes, but otherwise we'll continue on. As mentioned, no processes can take place and they don't actually set up a communication or connection rather between the two devices, meaning there is no regard for whether or not the data is received and there are no safeguards such as those offered by TCP, such as data integrity. UDP packets are much simpler than TCP packets and have fewer headers. However, both protocols share some standard headers, which are what is annotated in the table below.

So, we've talked about these before. We have time to live, source address, destination address, source port, destination port, and then the actual data. So, pretty simple, much, much simpler than the TCP packet because we don't have checksums and we don't have other things that are at play.

Next, we'll come on to discuss how the process of a connection via UDP differs from that of something such as a TCP connection. We should recall that UDP is stateless. No acknowledgement is sent during a connection.

The diagram below shows a normal UDP connection between Alice and Bob. In real life, this would be between two devices. So we're requesting that data and then all the data just keeps getting sent back.

What does the term UDP stand for? That is User Datagram Protocol. What type of connection is UDP?

That is stateless. What protocol would you use to transfer a file? Hopefully TCP.

And then what protocol would you use to have a video call? Hopefully UDP. Let's move into task 5, ports 101 practical.

Let's go ahead and load the site. Perhaps aptly titled by their name, ports are an essential point in which data can be exchanged. Think of a harbor and a port.

Ships wishing to... Ships! wishing to dock at a harbor will have to go to a port compatible with the dimensions and facilities facilities located on the ship. When the ship lines up, it will connect to a port at the harbor.

Take for instance that a cruise liner cannot dock at a port made for a fishing vessel and vice versa because they're just not the right size. These ports enforce what can park and where. If it isn't compatible, it cannot park here.

Networking devices also use ports to enforce strict rules when communicating with one another. When a connection has been established, recalling from the OSI Models Room, any data sent or received by a device will be sent through these ports. In computing, ports are a numerical value between 0 and 65,535. Because ports can range from anywhere between 0 and 65,535, there quickly runs a risk of losing track of what application is using what port.

A busy harbor is chaos. Thankfully, we associate applications, software, and behaviors with a standard set of rules. For example, by enforcing that any web browser data is sent over port 80 or 443, software developers can assign a web browser such as Google Chrome or Firefox to interpret the data the same way as another.

This means that all web browsers now share one common rule, data is sent over port 80 or 443. How browsers look? feel and easy to use is up to the designer of the or the user's decision so we can customize it on that end but we're using these ports as a standard rule while the standard rule for web data is port 80 or 443 for secure communication a few other protocols have been allocated a standard rule any port that is within 0 and 1024 is known as a common port let's explore some of the other protocols below for So first we have FTP or file transfer protocol, which is port number 21. By the way, as I go throughout these, these are worth committing to memory. It's something that you will memorize as you go throughout them.

Don't worry about having them memorized right away, but I do recommend adding these to your notes. This protocol is used by a file sharing application built on a client server model, meaning you can download files from a central location. Next we have secure shell or SSH, which is on port 22. This protocol is used to securely log into systems via a text-based interface for management. Next we have HTTP or Hyper Text Transfer Protocol. This is the World Wide Web and it lives on port 80 or 443, which we'll get into in just a moment.

So this is just for web browser things. So your browser uses this to download text, images, and videos of web pages. Next, as I mentioned before, we have HTTPS or Hypertext Transfer Protocol secure, which is on port 443. This protocol does the exact same thing as above, however, securely using encryption in this case.

And most of the time when you're talking to a website, you're going to be using this rather than HTTP. Next, we have Server Message Block or SMB. This is on port 445. This protocol is similar to File Transfer Protocol. However, As well as files, SMB allows you to share devices like printers.

And then last but not least, we have the Remote Desktop Protocol or RDP. This lives on port 3389. This protocol is a secure means of logging into a system using a visual desktop interface as opposed to a text based limitations of the SSH protocol. One other cool port that lives in this common ports range is port 666. That is actually for a doom server very cool little tidbit not very important to know but there you go We have only briefly covered the more common protocols and cyber security You can find a table of the 1024 common ports listed here for more information and definitely worth taking a look at and I recommend Saving this link in your notes as you're likely refer to it a lot as you get started What is worth noting here is that these protocols follow the standards?

So for example, you can only You can administer applications that interact with these protocols on a different port other than what is the standard. So, for example, you could run a web server on port 8080 instead of the standard port of 80. Note, however, applications will presume that the standard is being followed, so if you wanted to navigate to a web server that's on a different port, you need to provide the port with a colon number, which we'll get into maybe here in just a bit. Let's move on to the practical.

Open the site attached to this task. and connect to the IP address 8888 on port 1234 and you'll receive a flag. So here we're using the protocol or the application netcat on a simulated terminal. Don't worry too much if this is overwhelming, all we need to do is type in a couple pieces of information up here above. So first we have the IP address which is 8888 and then next we have the port 1234. We can go ahead and click connect which will issue the command.

And we have confirmed that the connection has actually happened. We can go ahead and copy that flag out. And there we go. Let's move into task six, continue your learning, extending your network.

Join the final room of this networking module, extending your network, to continue your learning and complete this module. Terminate the static site deployed in tasks five and three, which we can go ahead and do. Closing out of the room should do it automatically, so don't worry too much about that.

We'll go ahead and mark that as completed. and then make sure you join this next room in the module to finish it up. There we go. We've kind of completed the room. As always, the TryHackMe Discord and subreddit will be linked in the video description below.

And otherwise, I will see you in the next video. But until next time, happy hacking!