Chapter 11: Networking Basics

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replaced the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome back to the Deep Dive.

Today, we're jumping right into computer networks.

A huge topic.

Absolutely.

Because,

you know, almost nothing digital exists in a vacuum anymore.

Your phone, laptop, smart fridge.

Everything's connected.

And if you're involved in any kind of digital investigation, maybe a security breach or something,

understanding how these things talk to each other is, well, it's essential.

It really is.

So in this Deep Dive, we're going to unpack the fundamentals, drawing from the networking basics chapter.

Yeah.

The idea is to give you that core knowledge of device communication.

It's not just theory.

It's the practical foundation for, you know, figuring out what actually happened with the digital evidence.

Exactly.

We'll start with the frameworks, the OSI and TCP -IP models that kind of set the stage.

The blueprints.

Sort of.

Yeah.

Then we'll look at the actual hardware, the physical bits.

Yeah.

And finally, common ports and protocols the languages devices use online.

So by the end, you should have a much better handle on how this digital world connects, whether you're deep in tech or just curious.

OK.

Let's dive in.

Starting with those models, OSI and TCP -IP.

Right.

So first up is the OSI model, Open Systems Interconnection.

Think of it as a conceptual map for network communication.

It's conceptual.

Yeah.

It was designed way back to help different computer systems, you know, different brands, different types, talk to each other smoothly.

It does this by breaking communication down into seven layers.

Seven layers.

Sounds like a lot.

Is there an easy way to remember them?

There is.

If you're going from the bottom up, layer one to seven, try, please do not throw sausage pizza away.

OK.

Physical data link network transport session presentation application.

Got it.

And if you're thinking top down, layer seven to one, it's all people seem to need data processing.

Nice mnemonics.

They help.

And the beauty is each layer has a specific job.

Layer one, physical, that's the actual wires, the radio waves, the physical medium.

The tangible stuff.

Exactly.

Then layer two, data link, handles getting data between devices directly connected on that physical link.

It deals with like physical addresses, amass the addresses and basic error checking.

OK.

Then layer three network.

That's where IP addresses come in.

It's about logical addressing and figuring out the best path for data across different networks routing basically.

Right.

Finding the way.

Then layer four transport.

Make sure data gets there reliably.

It sets up connections, breaks data into pieces, manages flow,

uses port numbers to aim the data at the right application.

Port numbers.

We'll come back to those.

We will.

Moving up, layer five session, manages the actual conversation between applications, starting it, keeping it alive, ending it cleanly.

Like managing a phone call.

Sort of.

Layer six, presentation, is about the data format.

Is it encrypted?

Is it compressed?

Making sure both ends understand the data representation.

Translation layer almost.

You could think of it that way.

And finally, layer seven, application.

That's the layer we interact with directly, web browsers, email clients, file transfer programs.

The software we actually use.

OK.

So seven layers, each doing its part.

Why is this model useful, especially for, say, investigations?

Well, a few big reasons.

It makes troubleshooting way easier.

If something's broken, you can kind of pinpoint which layer might be the problem.

Instead of looking everywhere at once.

Exactly.

It also pushes interoperability because it's standardized.

Different vendors can make gear that works together.

Plus, layers are mostly independent, changing one doesn't break the others.

Ah, like modular design.

Right.

And as the source notes, that standardization is why Windows, Macs, Linux, they can all chat on the same network.

Being able to isolate issues at a specific layer, super useful when you're tracing a breach or data leak.

Makes a lot of sense.

A good structure for understanding.

But you said OSI is conceptual.

What's a practical model we actually use day to day?

That's TCPIP.

Precisely.

The TCPIP model, sometimes called the DoD model because the U .S.

Department of Defense helped create it.

For resilient networks, right?

Exactly.

That's the protocol suite that actually runs the internet in most networks today.

It's the practical implementation.

Okay, so how does TCPIP compare to the seven OSI layers?

Is it simpler?

It is, yeah.

It uses a four -layer structure.

The bottom layer, link or network access, basically combines OSI's physical and data link layers, handles the physical connection and local delivery.

Okay, layers one and two combined.

Right.

Then the internet layer in TCPIP maps directly to OSI's network layer IP addresses, routing, finding paths.

Layer three, got it.

The transport layer is pretty much the same in both models, handling reliability, flow control using TCP or UDP.

Layer four.

And the top.

The application layer in TCPIP bundles together the functions of OSI session, presentation, and application layers.

It's the interface for all the network apps.

So layers five, six, and seven rolled into one.

Four layers seems a bit more manageable.

And the big protocols here are TCP, IP, and UDP.

Those are the core ones, yeah.

Let's start with TCP transmission control protocol.

It's connection -oriented, meaning before any data flows, it sets up a dedicated connection.

It uses something called a three -way handshake.

A handshake.

Like a secret code.

Huh.

Not quite secret, but it's a specific sequence.

The sender sends a SYN packet, synchronize.

If the receiver's listening, it sends back a SYNAC synchronize acknowledge.

Right.

Finally, the sender replies with an ACK acknowledge.

Boom.

Handshake complete, connection established, data can flow.

And that set -up process, that connection state, can leave digital footprints investigators might look for.

Okay.

So you there.

Yep.

Great.

Let's talk.

And TCP is known for being reliable, isn't it?

Absolutely.

That's its main job.

It guarantees delivery.

It numbers data packets, tracks them, and the receiver has to acknowledge getting them.

What if one gets lost?

The receiver notices the gap in sequence numbers and asks the sender to resend the missing piece.

So you get everything in order.

Crucial for things like web browsing, email, file downloads, but all that checking and potential resending takes time.

It adds overhead, can cause delays, not ideal if speed is the absolute top priority.

Ah.

Okay.

So that's where UDP comes in.

Yeah.

User -diddy -gram protocol.

Exactly.

UDP is TCP's counterpart.

It's connectionless.

No handshake.

Nope.

The sender just starts firing off data packets called datagrams.

No prior agreement, no tracking numbers, no acknowledgments from the receiver.

So it just hoped for the best.

Pretty much.

It's faster because there's none of TCP's overhead, but packets can get lost, arrive out of order, or be duplicated, and UDP won't fix it.

When would you want that trade -off?

Speed over perfect accuracy.

Think live video streaming, online gaming, maybe some voice calls over the internet.

Right, where a tiny glitch is better than a long pause waiting for a resend.

Precisely.

For forensics, UDP traffic might show real -time chats or streams that don't leave those persistent TCP connection logs.

Okay, models and core protocols make sense.

Let's talk hardware, the actual physical gear.

Sure.

We can group hardware by the OSI layer where it mainly operates.

Layer 1, physical, has things like repeaters, hubs, modems.

Repeaters and hubs sound a bit old school.

Still relevant.

Maybe not directly in your typical modern office network, but the concepts are still around.

A repeater just boosts the signal to make it go further.

A hub was like a simple central connector.

Data comes in one port, it blasts it out all other ports.

No intelligence.

Ah, noisy.

Unlike a switch.

Exactly.

Hubs create collision domains, which isn't efficient, we'll get to switches.

And modems modulator to modulator, they convert digital computer signals to analog for phone lines or cable lines and back again.

Still essential for many internet connections, even if they're built into your router now.

Okay, basic signal stuff, layer 2, pay the link.

Here we've got network adapters, the card or chip in your computer with the ethernet port or wifi antenna.

The actual connection point.

Right.

Also bridges, which connect two network segments at layer 2, forwarding based on MC addresses.

Yeah.

And wireless access points, or WAPs, they bridge wired networks to wireless devices.

So connecting devices locally, using those physical Marrakey addresses.

Yep, layer 2 is mostly about that local neighborhood communication.

MC addresses are key here for investigations within a single network segment.

Got it.

But to connect different networks, like connecting my home network to the internet, that's layer 3, routers.

That's the main job of routers, yes.

They operate at layer 3, the network layer.

They look at the destination IP address on a data packet and figure out the best path to send it across different networks.

They're the traffic directors of the internet.

Makes sense.

What about switches?

You mentioned they were different from hubs.

Right.

Switches are primarily layer 2 devices.

Unlike hubs, they learn which MC address lives on which physical port.

So when data comes in for a specific MC address, the switch sends it only out the port connected to that device.

Much more efficient.

Ah, targeted delivery within the local network.

Exactly.

Now, some more advanced switches called layer 3 switches or multi -layer switches can also do some basic IP routing, blurring the lines with routers a bit.

But routers are specialized for connecting distinct networks.

Knowing routing paths is often vital for tracing traffic origins.

Okay, routers between networks, switches mostly within a network.

Layer 4, transport.

Any specific hardware there.

Well, devices often use layer 4 information.

Gateways can operate here and above.

They translate between networks using totally different protocol stacks.

Think of them as interpreters.

And firewalls are crucial.

They're security devices that filter traffic based on rules.

While they look at multiple layers, they often make decisions based on layer 4 info, like TCP UDP port numbers.

Is traffic allowed to port 80?

Is traffic from this IP allowed to connect?

The network security guard checking IDs and destinations.

A good analogy, yeah.

They control access and are critical for security.

Analyzing firewall logs is a huge part of many investigations.

Definitely.

Okay, models, hardware.

Now let's get into those ports and protocols.

The language of the internet.

What are ports exactly?

So think of an IP address as the street address for a building, like a server.

Port numbers are like the specific apartment or office numbers within that building.

Ah, directing the traffic to the right application inside the computer.

Precisely.

They're 16 -bit numbers, so you get ports from 0 up to 65535.

They're used by both TCP and UDP.

There's a range of well -known ports, 0 to 1023, usually for standard services like web or email.

Like port 80 for web traffic.

Exactly.

Then there are registered ports, and finally, ephemeral or dynamic ports, usually above

49151, that client applications grab temporarily for outgoing connections.

Understanding ports is key, because specific ports often mean specific activity, potentially malicious if it's unexpected.

Makes sense.

Let's run through some common application layer protocols then.

FTP, file transfer.

Right, file transfer protocol.

Uses TCP ports 21 for control commands, login, and usually port 20 for the actual data transfer.

Old school, but still used for moving files around.

Important for data exfiltration investigations.

Okay.

SSH, secure shell.

TCP port 22.

This is a secure way to get a remote command line on another machine.

Everything's encrypted.

Login, commands, output.

Crucial for secure administration.

I'm like Telnet.

Exactly.

Telnet, TCP port 23 does the same remote command line thing, but sends everything in plain text.

Usernames, passwords, all visible if someone's listening in.

Huge security risk.

You should almost never use it nowadays.

SSH is the way.

Seeing Telnet traffic could be a red flag.

Good to know.

Avoid Telnet.

What about email?

SMTT.

Simple mail transfer protocol.

TCP port 25 is the traditional one, often unencrypted.

Ports 465 and 587 are commonly used for secure SMTP over SSL TLS.

It's how mail servers send emails to each other.

Analyzing SMTP logs helps track email flow, spam, phishing attacks.

And DNS, domain name system?

You said it was vital.

Totally.

The internet's phone book.

Uses UDP port 53 mostly for quick lookups, but can use TCP port 53 for bigger data transfers like zone files.

It translates names like the deepdivepodcast .com into IP addresses computers understand.

Way easier than remembering numbers.

DNS lookups show where users or malware might be going online.

Can't imagine the internet without it.

Okay, what about getting an IP address automatically?

DHCP.

Dynamic Host Configuration Protocol.

Uses UDP port 67 for the server and 68 for the client.

When your device joins a network, it shouts out a DHCP request, and the DHCP server replies with an IP address, subnet mask, gateway, DNS server info.

Automates network setup.

DHCP logs show when devices join or lift a network.

Super convenient.

And the big web protocols, HTTP and HTTPS.

The foundation of the web.

HTTP Hypertext Transfer Protocol is on TCP port 80.

That's how your browser requests web pages from servers, but it's plain text.

Not secure.

Right.

Which is why we have HTTPS, secure HTTP on TCP port 443.

It's just HTTP wrapped in encryption, usually TLS, SSL, protects your browsing, logins, credit card numbers online.

Always look for that padlock.

Analyzing web traffic is obviously huge in investigations.

Absolutely.

One more RDP for remote desktops.

Right.

Remote desktop protocol.

Microsoft's thing.

Typically, TCP port 3389 lets you see and control the graphical desktop of a remote Windows machine.

Very useful, but also a massive target for attackers, so it needs careful securing and monitoring.

Okay.

That's a lot of application protocols.

Yeah.

And they rely on TCP or UDP at the transport layer, as we discussed.

Correct.

TCP for the reliable ones like HTTP, FTP, SSH.

UDP for the faster, less reliable ones, like maybe some DNS queries, streaming.

And below transport, at the internet layer, we have IP itself.

Yep.

Internet protocol.

Does the addressing and routing, getting packets across networks using those IP addresses?

Connectionless itself.

IPv4 and IPv6 are the main versions, essential for tracking source and destination.

And ICMP, Internet Control Message Protocol.

That's like the messaging service for IP, used for error reporting, hey, that network is unreachable.

And diagnostics.

The ping tool uses ICMP echo request and echo reply messages to test connectivity.

Ah, ping.

I use that.

It's handy, but firewalls often block ICMP, so no reply doesn't always mean the host is down.

ICMP messages can give clues about network problems, though.

Okay.

What about ARP, Address Resolution Protocol?

ARP links layer 3 and layer 2 within a local network.

It answers the question, I have this IP address, but what's the physical MC address for it on this specific network segment?

It broadcasts the question the owner of the IP replies with its MAC.

Crucial for local delivery.

ARP traffic is only local, not routed.

ARP spoofing is a common attack investigators look for.

The local address book, essentially.

And lastly, IPsec.

Sounds secure.

Internet Protocol Security.

It's a suite of protocols that adds encryption and authentication directly at the IP layer, often used to build VPNs, virtual private networks, creating secure tunnels over insecure networks like the internet.

Analyzing IPsec traffic relates to secure communications and VPN usage.

Wow.

Okay.

Complex ecosystem of protocols.

Let's pivot to the addresses themselves.

IPv4 and IPv6.

We mostly see IPv4 now, right?

The four numbers?

Yes.

IPv4 is still dominant.

It's a 32 -bit address written as four numbers, 0 to 255, separated by dots, like 192 .168 .1 .1 or 8 .8 .8 .8.

That 32 -bit space gives about 4 .3 billion addresses, which sounded like a lot.

But isn't enough anymore.

Not nearly.

With all the phones, laptops, IoT gadgets coming online.

Originally, IPv4 addresses were split into classes A, B, C, which defined how many bits were for the network part and how many for the host part.

Class A had few networks, but loads of hosts.

Class C had many networks, but fewer hosts each.

Exactly.

Class A used the first number for the network, the rest for hosts.

Class B used the first two for network, last two for hosts.

Class C used the first three for network, last one for hosts.

This class system is less rigid now with CIDR, classless inter -domain routing, but the concept helps understand network sizes.

And there are several private ranges within those.

Yes, very important.

Ranges like 10 .0 .0 to 10 .255 .0 .0 to 172 .255 .255, class A, and 102 .168 .168 .255 .255, class SD, are reserved for private use inside your home, your office.

They aren't routed on the public internet.

So if I see one of those, it's an internal address.

But how do those devices reach Google or other internet sites that's net -nate?

Network address translation, exactly.

Your home router usually does this.

It takes all the traffic from your private 192 .168 .x .x devices and sends it out to the internet using its one public IP address given by your ISP.

Ah, it translates.

Right.

It swaps the source private IP for its public IP, keeps track of which internal device made which request, usually using port numbers, and when the reply comes back it translates it back and sends it to the correct internal device.

It saves IPv4 addresses and adds a layer of security by hiding internal IPs.

Makes sense.

The router acts as the single gateway.

But since we're running out of IPv4 addresses, even with NAT, we need IPv6.

That's the main driver.

IPv4 exhaustion, IPv6 uses 128 -bit addresses.

128 bits?

That's way more than 32.

Massively more.

The number of possible IPv6 addresses is astronomical.

Something like 340 undecillion.

We will essentially never run out.

It's designed for the future internet of everything.

Okay, so what does an IPv6 address look like?

Not four numbers, I guess.

No.

It's eight groups of four hexadecimal characters separated by colons.

Hexadecimal uses numbers 09 and letters AF.

So an example might be something like 2001 .0db8 .858500 .82e .82e .0370 .7334.

Much longer.

Yeah, yeah, that's longer.

Is there a structure to it like the network host split in IPv4?

Yes.

Typically, the first 64 bits are the network prefix, identifying the network.

And the last 64 bits are the interface identifier, identifying the specific device on that network.

The interface ID is often automatically generated from the device's MAC address.

Okay, 64 for network, 64 for host, half and half.

Generally, yes.

And that 64 -bit network part is often further split, maybe 48 bits for the global prefix assigned by the ISP and 16 bits for subnetting within the organization.

Are there different types of IPv6 addresses like the private ranges in IPv4?

There are different scopes, yes.

Global unicast addresses are the public, internet -routable ones, often starting with 2001.

Unique local addresses, starting with FC0 or FD00, are for internal networks like IPv4 private addresses, not meant to be routed globally.

And link local addresses, starting with FE80, are only used for communication on the same physical link, for neighbor discovery and auto configuration.

Global local and link local, got it.

Any other types?

You mentioned multicast earlier.

Right.

IPv6 has strong support for multicast addresses, starting with FF, sending one packet to many subscribed devices efficiently.

And anycast, where an address represents multiple devices, but a packet sent to it, goes to only the nearest one, useful for load -balancing services like DNS.

Those long hex addresses seem painful to type.

Any shortcuts?

Thankfully, yes.

Two main rules.

First, you can drop leading zeros within any group of four hex digits.

So .0db8 becomes .db8.

Okay, shaves off a bit.

The bigger one is that you can replace one sequence of consecutive groups containing only zeros with a double colon graph, just once per address though, or it's ambiguous.

So that example, 2001 .0db8 .8583 .0000 .882e .882e .0370 .0 .7334 could become?

2001 .0db8 .8583 .82e .0370 .0 .7334.

Much cleaner.

Definitely better.

Okay, we have covered a ton of ground.

The OSI and TCPIP models, the hardware, all those protocols and ports, and now IPv4 and IPv6 addressing, it really highlights how layered and complex networking is.

It really does.

And hopefully it also highlights why understanding these basics is so crucial for digital investigations.

Analyzing traffic, tracing connections, understanding data flow, it all comes back to these fundamentals.

Absolutely.

And the source material made a great point near the end about communication.

It's not just about knowing the tech stuff.

Right.

It's about being able to explain it clearly, especially to people who aren't network engineers.

Writing reports, presenting findings that translation skill is vital.

So true.

Making the complex understandable is key.

Well, this has been a really comprehensive deep dive into networking basics.

We hit the OSI and DoD models, the hardware layers, common ports and protocols like TCP, UDP, HTTP, DNS, and the addressing schemes of IPv4 and IPv6.

A solid foundation for anyone needing to understand how our digital world is wired together.

Indeed.

And maybe a final thought for you, the listener.

Think about how that layered OSI model, with its separation of concerns,

might reflect complexity in other systems, maybe even biological or social systems.

Or how the big shift from IPv4 to IPv6, driven by scale and necessity, mirrors other major technological transitions we see happening.

How do these foundational network ideas echo elsewhere?

Something to chew on.

With that, we've covered the core concepts for the networking basics chapter.

Thanks for joining us on the deep dive.