DEV Community: VickkyKruz NetSec

IP Addressing and Subnetting: Every Device Needs an Address

VickkyKruz NetSec — Mon, 06 Jul 2026 21:50:38 +0000

This is Post 4 of my Networking Foundations series, originally published on my blog. Start from Post 1 there if you want the full series in order.

At the end of the last post, we zoomed out to see the whole OSI model, seven layers, each with one job. Then we promised to come back and zoom all the way into one of them: Layer 3, the network layer, the home of the thing that makes global communication possible in the first place.

That thing is the IP address.

Every device that speaks to another device across a network needs one. Your phone has one right now. So does the server hosting this page, the router in your home, and the laptop you might be reading this on. Without addresses, there is no way to say "send this here rather than there," and the entire idea of a network collapses. The IP address is the network layer's answer to a single question: on a planet with billions of connected devices, how does data find the one specific machine it is meant for?

This post answers that question completely. What an address actually is, why we nearly ran out of them, how your home network quietly shares a single public one, how the newer system fixes the shortage, and finally, subnetting: the skill that trips up more networking learners than any other, taught here in the order that actually makes it stick.

What an IP Address Actually Is

Let us start with the concept, before any notation.

An IP address is a numerical label assigned to every device on a network that uses the Internet Protocol. It does two jobs at once: it identifies the device, and it locates that device within the network. Those are subtly different things, and both matter. Identification says "this is who you are." Location says "this is where you are, so traffic can be routed to you."

Here is the important word: an IP address is a logical address, not a physical one. Remember from Post 3 that every device also has a MAC address, burned into its hardware at the data link layer. That MAC address is like a person's fingerprint. It never changes and it is tied to the physical device forever. An IP address is different. It is like a mailing address. It describes where you currently are on the network, and it can change when you move. Connect your laptop to a different network and it gets a different IP address, just as you would have a different postal address if you moved house. The laptop is the same laptop, its fingerprint is unchanged, but its location, its logical address, is now different.

This is the postal analogy we have been building since Post 2, and it holds all the way up. The MAC address is who you are. The IP address is where you live. Routing, the job of getting data across the world, depends entirely on the second one.

IPv4: The Original System, and Why We Ran Out

The version of IP addressing that built the internet is called IPv4, and it has been in use since 1983.

An IPv4 address is a 32-bit number. In practice you never see it as 32 raw bits, because that would be unreadable. Instead it is split into four groups of 8 bits, each group written as a decimal number from 0 to 255, joined by dots. That is why IP addresses look the way they do:

192.168.1.75

Each of those four numbers is called an octet, because it represents 8 bits. Eight bits can hold 2 to the power of 8, which is 256 values, giving the range 0 to 255 that you see in every octet. The same address in binary looks like this:

11000000.10101000.00000001.01001011

That is the exact same address, just shown as the bits the machine actually works with. We will need this binary view later for subnetting, so keep in the back of your mind that every dotted-decimal address is really just 32 ones and zeros wearing a friendlier costume.

Now the problem. If an IPv4 address is 32 bits, then the total number of possible addresses is 2 to the power of 32, which is about 4.3 billion. In 1983, when there were a few hundred computers on the entire network, 4.3 billion seemed limitless. But the internet grew into a world of billions of phones, laptops, servers, cameras, thermostats, cars, and sensors, and 4.3 billion stopped being nearly enough. This is called IPv4 address exhaustion, and it played out over the 2010s exactly as engineers had feared decades earlier.

The industry responded in three ways. Two were stopgaps to stretch IPv4 further: private addressing and NAT, which we will cover next. The third was the real long-term fix: a brand-new addressing system with a vastly larger space, called IPv6. Almost every strange or clever thing about modern addressing traces back to this one root cause, the slow exhaustion of a 4.3 billion address ceiling that was set in 1983.

Public vs Private Addressing, and the Trick That Saved IPv4

Here is a question that reveals how the stopgap works. You might have five, ten, or twenty devices connected to your home network right now. Each one has an IP address. Yet your entire home shows up to the outside internet as a single address. How?

The answer is the split between public and private addressing, joined by a translation trick called NAT.

Three ranges of IPv4 addresses are reserved for private use, meaning they are never routed on the public internet. They are defined in a standard called RFC 1918, and they are:

10.0.0.0        to  10.255.255.255
172.16.0.0      to  172.31.255.255
192.168.0.0     to  192.168.255.255

Anyone can use these ranges inside their own network without asking permission, because they are not globally unique. Millions of home networks around the world use 192.168.0.x at the same time, and that causes no conflict, precisely because these addresses never appear on the public internet. This is why, if you check your laptop's address at home, it very likely starts with 192.168 or 10. That is a private address, visible only inside your own network.

So how does your privately-addressed laptop reach a public website? Through Network Address Translation, or NAT. Your router holds one public address, the one your internet provider assigns you, and it sits at the boundary between your private network and the public internet. When your laptop sends a request out, the router rewrites the packet so that it appears to come from the router's single public address. When the reply comes back, the router remembers which internal device asked, and forwards it to the right place. Every device in your home shares that one public address, taking turns through the router's translation table.

NAT was one of the two great stopgaps that kept IPv4 alive far longer than its address count should have allowed. It also has a quiet security side effect worth naming: because your internal devices are not directly addressable from the public internet, they are somewhat shielded from direct inbound connection. NAT was never designed as a security control, and it should never be relied on as one, but the isolation it creates is a real and useful side effect. We will come back to that idea, deliberate isolation, when we reach the security section, because it is the heart of why subnetting matters.

IPv6: The Real Fix

Stopgaps buy time. IPv6 was built to end the shortage permanently.

Where an IPv4 address is 32 bits, an IPv6 address is 128 bits. That change sounds modest, four times the bits, but because each added bit doubles the space, the result is staggering. IPv4 offers about 4.3 billion addresses. IPv6 offers 2 to the power of 128, which is roughly 340 undecillion, a number so large it is effectively beyond exhaustion. To put it in perspective, the smallest standard IPv6 subnet allocation contains more addresses than the square of the entire IPv4 internet. We are not going to run out of IPv6 addresses.

Because 128 bits would be absurd to write in dotted decimal, IPv6 uses a different notation: eight groups of four hexadecimal digits, separated by colons. A full IPv6 address looks like this:

2001:0db8:0000:0000:0000:8a2e:0370:7334

There are shorthand rules to compress the long runs of zeros, so in practice you often see something much shorter, like 2001:db8::8a2e:370:7334. The double colon stands in for a run of zero groups.

Two honest points about IPv6. First, it is not a distant future thing, it is here and running now, and it has been deploying since the mid-2000s. Second, and just as honestly, IPv4 has not gone away. Both systems run side by side across the internet today, and they will for years to come. This is why a working engineer has to be fluent in both, not one or the other. IPv6 is the destination, IPv4 is the enormous installed base we still live with, and the reality on the ground is both at once.

Subnetting: The Part Everyone Dreads, Done in the Right Order

Now for the section that makes people give up on networking. We are going to make it stick by building the idea first and doing the maths second.

Why divide a network at all?

Imagine a single flat network with thousands of devices on it. Every device can talk directly to every other device. This sounds convenient, but it is a problem for two reasons.

The first is noise and performance. Some network traffic is a broadcast, a message sent to every device at once. On a huge flat network, broadcasts reach thousands of machines, and all that unnecessary chatter clogs the network. The second reason is the one this series cares about most: security. On a flat network, anything that gets in can reach everything. There are no internal walls. An attacker or a piece of malware that compromises one machine can move sideways to every other machine, because they are all on the same undivided space.

Subnetting is the solution to both problems. It is the practice of dividing one large network into smaller, self-contained sub-networks, called subnets. Each subnet is its own contained space. Broadcasts stay inside their own subnet instead of flooding everything, which fixes the performance problem. And traffic between subnets has to pass through a router, where it can be filtered and controlled, which fixes the security problem by creating exactly the kind of internal walls a flat network lacks.

That is the whole idea. Everything below is just how we express it precisely.

The network part and the host part

Every IP address is secretly divided into two sections. The first section identifies the network (or subnet) the device is on. The second section identifies the specific device, called the host, within that network.

Think of the postal analogy one more time. A full address like "12 Baker Street, London" has a part that identifies the area (London, the street) and a part that identifies the specific building (number 12). The network part of an IP address is the area. The host part is the specific building. Devices in the same area, on the same subnet, share the same network part and differ only in their host part.

The question is: where is the dividing line between the two parts? That line is set by something called the subnet mask.

The subnet mask and CIDR notation

A subnet mask is a 32-bit value that marks which bits of an address belong to the network part and which belong to the host part. Every bit set to 1 in the mask means "this bit is network." Every bit set to 0 means "this bit is host." The ones always come first, all together, followed by the zeros.

The most common subnet mask is:

255.255.255.0

In binary that is twenty-four 1s followed by eight 0s. It says the first 24 bits of the address are the network, and the last 8 bits are the host.

Writing out full subnet masks is tedious, so modern networking uses a shorthand called CIDR notation. You simply write the address, a slash, and the number of network bits. So instead of saying "192.168.1.0 with a mask of 255.255.255.0," you write:

192.168.1.0/24

The /24 means "the first 24 bits are the network part." This single number, the prefix length, tells you everything about how the address is divided. A larger number after the slash means more bits given to the network and fewer left for hosts, which means a smaller subnet with fewer devices. A smaller number means a bigger subnet. That inverse relationship trips people up at first, so hold onto it: bigger slash number, smaller network.

The maths, worked step by step

Now we do the actual calculation, and because you understand what you are calculating, it will make sense rather than feel like magic.

For any subnet, there are a few things you want to work out: how many devices it can hold, the network address, and the broadcast address. Here are the rules, then a full worked example.

Counting the hosts. If a subnet has some number of host bits, call it h, then the number of usable device addresses is 2 to the power of h, minus 2. The formula is:

usable hosts = 2^(32 - prefix) - 2

Why minus 2? Because two addresses in every subnet are reserved and cannot be given to a device. The very first address, where all host bits are 0, is the network address, which names the subnet itself. The very last address, where all host bits are 1, is the broadcast address, used to send to every device in the subnet at once. Neither can be assigned to a real device, so we subtract them.

A full worked example: 192.168.1.0/24

The prefix is /24, so 24 bits are network and 32 minus 24, which is 8, are host.

Usable hosts = 2^8 - 2 = 256 - 2 = 254
Network address   = 192.168.1.0     (all 8 host bits = 0)
First usable host = 192.168.1.1
Last usable host  = 192.168.1.254
Broadcast address = 192.168.1.255   (all 8 host bits = 1)

So a /24 gives you 254 usable addresses, from .1 to .254, with .0 and .255 reserved. This is the classic home and small office network.

Now let us actually subnet: splitting that /24 into four smaller networks

Suppose you have that one /24 and you want to divide it into four separate subnets, perhaps one each for staff, guests, servers, and IoT devices, so you can wall them off from one another. This is subnetting in action.

To make four subnets, you need to borrow bits from the host part and give them to the network part. Four subnets is 2 to the power of 2, so you borrow 2 bits. Your prefix grows from /24 to /26.

A /26 means 26 network bits and 6 host bits. Let us work out one subnet fully:

Prefix /26  ->  host bits = 32 - 26 = 6
Addresses per subnet = 2^6 = 64
Usable hosts = 64 - 2 = 62

And the four subnets carve up the original range like this:

192.168.1.0/26    hosts .1   to .62     (broadcast .63)
192.168.1.64/26   hosts .65  to .126    (broadcast .127)
192.168.1.128/26  hosts .129 to .190    (broadcast .191)
192.168.1.192/26  hosts .193 to .254    (broadcast .255)

Look at what happened. The one network that held 254 devices is now four separate networks holding 62 devices each. Each is its own broadcast domain, and traffic moving between them must cross a router, where it can be controlled. You did not add any hardware. You simply moved the dividing line two bits to the right, and in doing so you created internal walls where there were none.

The binary underneath

Here is the binary view that shows why the boundaries land where they do. Take the address 192.168.1.75 and the mask for /24. To find the network address, the router performs a bitwise AND: wherever the mask has a 1, it keeps the address bit; wherever the mask has a 0, it forces the bit to 0.

  11000000.10101000.00000001.01001011   (192.168.1.75, the address)
AND
  11111111.11111111.11111111.00000000   (255.255.255.0, the /24 mask)
= 11000000.10101000.00000001.00000000   (192.168.1.0, the network)

The mask's 1s preserve the network part exactly, and its 0s wipe the host part to zero, leaving the network address. This single operation, done in hardware billions of times a second, is how every router on earth decides which subnet an address belongs to. Every subnetting question you will ever face is, underneath, just this: line up the bits, apply the mask, read off the boundaries.

A note on IPv6 subnetting

IPv6 uses the exact same CIDR slash notation, so everything you just learned about prefixes transfers directly. The main practical difference is that IPv6 subnets are, by strong convention, a /64. That leaves 64 bits for hosts, which is 2 to the power of 64 addresses in a single subnet, about 18 quintillion. Because address space is no longer scarce, IPv6 subnetting is less about squeezing every address out of a tight block and more about clean, consistent structure. The maths is identical. The scarcity mindset is gone.

The Security Payoff: Subnetting Is a Security Control

Everything above was leading here, because subnetting is not only an addressing and performance tool. It is one of the most fundamental security controls in all of networking, and it connects directly to the earlier posts in this series.

Recall the firewall post Behind the Wall: What Firewalls Really See, Block, and Miss, where the real danger was not the attacker getting in, but the attacker moving sideways once inside, from a low-value machine to the crown jewels, across a flat internal network. Subnetting is the structural defence against exactly that. By dividing a network into segments, you limit the attack surface and obstruct lateral movement. If an attacker compromises one machine, they cannot automatically reach the rest, because the other subnets sit behind a router boundary where traffic can be filtered and blocked. A malware infection in one subnet does not spread to another. The internal walls contain it.

This practice, dividing a network into isolated segments to control traffic and contain breaches, is called network segmentation, and subnetting is its foundation. It is why you put IoT devices, those cheap cameras and thermostats with weak security, on their own separate subnet, so that if one is compromised, the attacker is trapped in a segment with nothing valuable, unable to reach your servers or workstations.

There is a second security angle worth understanding, from the attacker's side. When a penetration tester or a real attacker gains a foothold in a network, one of the very first things they do is reconnaissance: mapping the network to find out what else is reachable. They use tools like Nmap to scan address ranges and discover live hosts and open services. The subnet structure is one of the first things this reconnaissance reveals, because the subnet mask tells an attacker how many other devices share the segment and where the boundaries are. A tester can only test what they can reach, and an attacker can only attack what they can reach. Good segmentation directly shrinks the internal attack surface by shrinking what any single compromised position can see. This is the network layer's version of the same lesson the whole series keeps returning to: control, and the lack of it, is structural. It lives in how the system is divided.

Commands to See Your Own Addressing

Everything here is visible on your own machine right now.

See your own IP address, subnet mask, and gateway:

ipconfig            (Windows, look for IPv4 Address and Subnet Mask)
ip a                (modern Linux)
ifconfig            (macOS and older Linux)

Look at the address. If it begins with 192.168 or 10, you are looking at a private RFC 1918 address, and NAT is translating for you every time you reach the internet. Note the subnet mask too, very often 255.255.255.0, your /24.

See the difference between your private and public address:

Your machine knows only its private address. To see the single public address your whole network shares, you can search "what is my IP address" in a browser. Compare the two. The private one is what your laptop calls itself. The public one is what the entire internet sees. The gap between them is NAT at work.

See your route to a destination, and the addresses along the way:

traceroute google.com     (tracert on Windows)

As in Post 2, every hop is a real router with its own address. Now you can read those addresses with understanding, spotting private ranges near your end and public ranges further out.

What You Now Understand

You started this post with a simple truth, that every device needs an address, and you now understand what that address actually is: a logical, changeable location marker at Layer 3, distinct from the fixed physical MAC address, exactly the mailing-address-versus-fingerprint split.

You know why the original IPv4 system, with its 4.3 billion address ceiling set in 1983, ran short, and the three responses that followed: private addressing, NAT, and ultimately IPv6 with its effectively limitless 128-bit space. You understand why your home network shares one public address, and you can now read your own private address and know what it means.

Most importantly, you did the thing most people give up on. You subnetted, in the right order. You understand why we divide networks before you memorised how, and then you did the how anyway: the network and host split, the subnet mask, CIDR notation, the host-counting formula, a full worked division of a /24 into four /26 subnets, and the bitwise AND underneath it all. And you saw that IPv6 uses the very same notation, just without the scarcity.

And you connected it back to the thread of the series: subnetting is not just plumbing, it is a security control. It is the structural foundation of network segmentation, the thing that contains breaches and obstructs the lateral movement that the firewall post warned about. Control lives in how a network is divided.

In the next post, we follow the address one step further. You now know how a device is located by its IP address, but you have never once typed an IP address to visit a website. You type a name, like google.com. The system that translates that human name into a machine address is DNS, the internet's phone book, and it is one of the oldest, most essential, and most quietly abused systems on the network. That is Post 5.

networking #security #beginners #tutorial

The Infrastructure Lens: Why Control of AI Lives in the Layers Underneath

VickkyKruz NetSec — Mon, 22 Jun 2026 23:07:39 +0000

Hi everyone 👋

I want to share a standalone piece I just published. It is a short detour from my Networking Foundations series, but it comes from the same instinct, so it felt worth writing.

Here is the idea.

As an infrastructure engineer, you learn not to start with the application a user sees. You start at the bottom of the stack and work up, because that is where the real constraints live. A website is only as available as the server beneath it. A server is only as reachable as the network beneath that. Control, capability, and failure all originate in the lower layers and cascade upward.

I took that exact instinct and pointed it at artificial intelligence. And through an infrastructure lens rather than a software one, something becomes clear that the louder conversations tend to miss.

AI is not really a software story. It is an infrastructure story.

Underneath every weightless little AI prompt sits a very physical stack: chips, data centres, electricity, cooling, water, land, and grid capacity. And each of those layers has a chokepoint, a place where a small number of actors control something everyone else depends on.

Consider just the energy layer. The single biggest constraint in the AI buildout right now is not chips or capital. It is electricity. In the largest data-centre hub on earth, some new projects have been warned they could wait up to seven years for a full grid connection. A single AI server rack can draw as much continuous power as a small building. The binding limit on AI is becoming physical.

Here is why that matters beyond the engineering. Because the layers are stacked, control of a lower layer cascades upward. Restrict who can buy advanced chips, and you have indirectly decided who can build data centres, which decides who can train models, which decides who can ship applications. You do not need to regulate a thousand applications if you control the one resource they all depend on.

The post also looks at the long history of critical infrastructure, railroads, steel, nuclear, the internet itself, and the consistent pattern of what happens once a technology becomes essential enough that a society cannot function without it.

I kept it deliberately structural rather than political. The point is not who is right or wrong. It is that infrastructure shapes what is possible, and that is an engineering truth, not a partisan one.

It also connects back to something personal. I once wrote about hitting paid usage limits on an AI tool and asking whether the pricing was exploiting how dependent I had become. This post is the structural answer to that frustration: the wall I kept hitting was placed several layers down the stack, in a room I would never see.

📖 Read it here: https://vickkykruzprogramming.dev/blog/the-infrastructure-lens-why-control-of-ai-lives-in-the-layers-underneath

It comes with four original diagrams, including the full five-layer AI infrastructure stack. Subscribe to my newsletter for more analysis that looks underneath the headlines.

AI #Infrastructure #CyberSecurity #DataCenters #CloudComputing #TechAnalysis #Engineering #DevOps

The OSI Model: Demystified, Not Memorised

VickkyKruz NetSec — Mon, 22 Jun 2026 22:35:19 +0000

Hi everyone 👋

Let me say something that might be controversial in tech education circles.

The way the OSI model is normally taught is the reason most people never actually understand it.

You know the drill. Seven layers, memorise them in order, use a mnemonic like "Please Do Not Throw Sausage Pizza Away," answer the exam question, and forget the whole thing within a week. You technically "learned" it, but you could not explain what it actually does or why it exists.

In Post 3 of my Networking Foundations series, I set out to fix that by teaching it the opposite way.

Here is the core idea: if you have followed the series so far, you already understand the hard part. You have already met packets, headers, encapsulation, IP addresses, and MAC addresses. The OSI model is simply the formal name for that structure. It is not new information to memorise. It is a label for something you already understand.

So the post does not ask you to memorise seven names. It teaches you seven jobs.

It covers:

→ Why the OSI model exists at all (the early networking world was a chaos of incompatible systems, and the industry needed a shared reference)
→ All seven layers explained as jobs, not names, each with its real-world protocols, devices, and data unit
→ The honest truth most tutorials skip: the internet does not actually run on OSI. It runs on the simpler four-layer TCP/IP model. The post includes a full side-by-side showing exactly how the two map together.
→ The security payoff that makes the whole model worth knowing

That last point is the one I care about most. When you understand the layers, you understand where in the stack any given attack operates, and therefore what kind of defence can possibly stop it.

A TCP SYN flood is a Layer 4 attack. No web application firewall (Layer 7) will stop it.

ARP poisoning is a Layer 2 attack. It happens below the level a traditional IP firewall even looks.

SQL injection is a Layer 7 attack. Your network firewall passes it happily, because to the network it looks like ordinary web traffic.

Match the defence to the layer, or it does nothing. That single skill, placing an attack on a layer and reasoning about the right defence, is worth more than any mnemonic.

The post includes four original diagrams: the full seven-layer stack, the encapsulation flow, a per-layer attack map, and the OSI vs TCP/IP comparison.

📖 Read Post 3 here: https://vickkykruzprogramming.dev/blog/the-osi-model-demystified-not-memorised

This is part of an ongoing 14-post series taking readers from the basics of networking through to Zero Trust security. Subscribe to our newsletter to get each new post as it publishes. 🔔

Networking #CyberSecurity #OSIModel #CCNA #NetworkSecurity #InfoSec #TechEducation #ITCareer #DevOps #LearnNetworking

How Data Actually Travels: Packets, Protocols, and the Postal Service Analogy

VickkyKruz NetSec — Wed, 17 Jun 2026 10:53:51 +0000

Hi everyone 👋

Here is something that sounds impossible but happens billions of times a second.

The email you sent this morning never travelled as a single message. Neither did this post. Neither did the last video call you were on.

Every one of them was torn into small pieces first.

Those pieces, called packets, were each stamped with an address, sent out individually (often by completely different routes through different cities and even different countries), and then reassembled at the destination into something that looked exactly like the original. All in a fraction of a second. All completely invisibly.

This is the single most important mechanism in all of networking. And once it clicks, almost everything else in the field starts to make sense.

So in Post 2 of my Networking Foundations series, I set out to make it click, using something everyone already understands: the postal service.

Here is the core idea.

Imagine posting a 500-page manuscript. You cannot fit it in one envelope, so you split it into 500 numbered pages, put each in its own envelope, and post them all. They travel by different routes, arrive out of order, and get sorted back into sequence on arrival using their page numbers.

That is exactly how data moves across a network. The manuscript is your email. The envelopes are packets. The sorting offices are routers.

From that one analogy, the post builds up every core concept:

→ What is actually inside a packet (header, payload, and trailer)
→ Encapsulation, the nested-envelope structure that wraps your data in layers
→ How routers move packets without any single one knowing the full route
→ How TTL stops packets from looping around the internet forever
→ How TCP uses sequence numbers and acknowledgements to recover lost packets and reorder them, turning an unreliable system into one that feels perfectly reliable

And then the part that matters most for anyone thinking about security.

A large amount of network traffic does not travel as a sealed letter. It travels as a postcard. The address has to be visible for routing to work, but on a postcard, so is the message. Anyone positioned along the route, on the same Wi-Fi, the same office network, the same coffee shop hotspot, can potentially read it using free, widely available tools.

This is why the difference between http and https is not a technicality. It is the difference between a postcard and a sealed envelope. On public Wi-Fi especially, it is the difference between your data being private and your data being readable by anyone nearby with five minutes and a laptop.

The post includes six original diagrams built specifically for it, including a full breakdown of packet anatomy, the encapsulation layers, and a side-by-side of what a packet sniffer sees with http versus https.

It is written for a mixed audience. Whether you are completely new to networking, a developer filling in the gaps, or someone studying towards a certification, it is built to meet you where you are.

📦 Read Post 2 here: https://vickkykruzprogramming.dev/blog/how-data-actually-travels-packets-protocols-and-the-postal-service-analogy

This is part of an ongoing 14-post series taking readers from the very basics of networking through to Zero Trust security. Subscribe to our newsletter to get each new post delivered as it publishes. 🔔

Networking #CyberSecurity #CCNA #NetworkSecurity #InfoSec #TechEducation #DevOps #ITCareer #LearnNetworking #DataPrivacy

What Is a Network? The Why Before the How

VickkyKruz NetSec — Tue, 12 May 2026 20:05:39 +0000

Hi everyone 👋

Now, before we dive into the nitty-gritty of things such as IP addresses, subnets, firewalls, and protocols, I have one question to start off with you.

What, according to you, was the first-ever message ever communicated through a computer network?

No, not "Hello, world."
And not something deep, either.
Quite simply, it was "LO".

One of the researchers at UCLA was typing the word "LOGIN" to the computer at the Stanford Research Institute, located about 350 miles away. The L arrived. The O arrived. He typed the G, and the system at Stanford crashed.

The message that was sent for the first time through a computer network was a sign of an inevitable failure. The two letters that emerged from that failure, however, have changed the entire history of networking.

That happened on October 29, 1969.

Recently, I have uploaded a premiere post for a new series: Networking Foundations, a 14-post series that covers you from the very first step in computer networking to Zero Trust security, cloud infrastructure, and packet analysis.

Post 1 is called: What is a network? The why before the how. And the "why" is a story most guides skip entirely.

Here’s‍‌‍‍‌ the blog talks about:
🔹 The comprehensive origin tale: from Cold War tensions to the very first four nodes of ARPANET
🔹 What exactly is a network: the proper definition starting from basics
🔹 The four kinds of networks (PAN, LAN, MAN, WAN) and how their security differ
🔹 What goes on when you input a URL: the whole process, each one of the attack surfaces
🔹 The trust issue: how the design of the internet is the main cause of most security problems
🔹 Useful commands: ping, traceroute, ipconfig, check out your network right ‍‌‍‍‌now

This supplement comprises four original diagrams crafted exclusively for the blog post, which include a geographic ARPANET map that depicts the initial four nodes and the first connection.

This is Post 1 of 14. The complete series will take you through topics such as IP addressing, DNS, cloud networking, packet analysis with Wireshark, and Zero Trust architecture, all the while incorporating security at every stage.

If you have ever desired a solid groundwork in networking, not a mere overview of the surface but an insightful, well-connected comprehension, this series has been designed for you.

📖 Read Post 1 here: https://vickkykruzprogramming.dev/blog/what-is-a-network-the-why-before-the-how

Also, get a subscription to our newsletter to have each new installment of the series straight into your inbox right when it gets published. 🔔

Networking #CyberSecurity #CCNA #NetworkingFoundations #InfoSec #TechLearning #ARPANET #ZeroTrust #ITCareer #DevOp

Behind the Wall: What Firewalls Really See, Block, and Miss

VickkyKruz NetSec — Fri, 01 May 2026 21:24:35 +0000

Hi everyone 👋

Just a quick question to you.

You have a firewall, right?

Well, your IT team has probably done the setup. It's gone live. And now you think you're protected.

But when was the last time you actually asked: what are the firewall's limitations?

This is what a majority of security presentations won't disclose:

→ According to statistics, more than 90% of online traffic is encrypted and most of the time firewalls are not able to access it.

→ Firewalls are designed to regulate the flow of data primarily between the internal network and the internet (north-south). So intruders can freely move around within your network (east-west) without being detected.

→ According to research, 95% of the cases where unauthorized access to firewalls take place happen due to errors in the configuration and not because of highly skilled hackers.

→ In the incident of Capital One data breach in 2019, here were more than 100 million customer records compromised due to a single misconfigured rule.

It's not that the firewall failed. The failure was the notion that just installing a firewall will be sufficient.

I've done a comprehensive research starting from the first firewall US prototype (UC Davis, 1988) and leading up to Zero Trust security concept, which fundamentally does away with the idea of a perimeter in security.

📌 Behind the Wall: What Firewalls Really See, Block, and Miss
🔗 Full article: https://vickkykruzprogramming.dev/blog/behind-the-wall-what-firewalls-really-see-block-and-miss

This post will definitely be helpful for those working in IT, security, networking, or generally handling any business infrastructure.

And if this has resulted in you questioning some of your assumptions, then sign up for our newsletter. We regularly publish cybersecurity and networking articles that go in-depth beyond the surface.

CyberSecurity #NetworkSecurity #Firewall #ZeroTrust #InfoSec #ITSecurity #NGFW #DataProtection

Why ‍UK Businesses Choose .co.uk Domain: The Untold ‍ ‌‍ ‍‌Story

VickkyKruz NetSec — Wed, 29 Apr 2026 11:37:36 +0000

Hey everyone 👋

I've got a little secret for you:

UK businesses didn't switch to .co.uk because they liked it over .com. 😊

For almost 30 years, it was the only commercial domain available under the .uk namespace. Businesses didn't pick it, the internet's design handed it to them.

The tale starts in 1985, when the UK was only the second country in the world to get its own domain. It continues with JANET UK's academic-only internet of the 80s the structural decision to designate .co.uk as the commercial-tier, and Nominet's establishment in 1996 that led to commercial registrations opening up.

I just put out the detailed explanation:

📌 Why UK Businesses Choose.co.uk, The Untold Story

Topics it touches on:

→ The full history from 1985 to present day

→ The reason.co.uk still retains 40 years of brand trust

→.com vs.co.uk vs.uk, when to go for each

→ A hands-on guide to all the major domain extensions

→ A 4-question framework to help you choose the right domain for your brand

Be it you are starting a new venture, doing rebranding, or just wondering, this article is a good read.

🔗 Full article: https://vickkykruzprogramming.dev/blog/why-uk-businesses-choose-co-uk-domain-the-untold-story

Do you find it helpful? Pass it on to a founder or business owner who is about to register a domain. Also, subscribe to our newsletter if you want to receive more practical business and digital guides. 🔔

UKBusiness #Domains #DigitalStrategy #StartupUK #SmallBusiness #Branding #WebDevelopment

Why SIM Cloning Isn't Used Anymore, And What Changed It

VickkyKruz NetSec — Fri, 17 Apr 2026 12:41:49 +0000

Hey all 👋

Many people think that hackers make a copy of your SIM card to steal your phone number. Actually? That method is mostly a historical technique from the 1990s.

The thing which superseded it is quite straightforward and even more frightening.

I have recently shared a blog post in which I explain it all:

📌 Why SIM Cloning Is No Longer Used, And What Changed It
Here I explain:

→ The real definition of SIM cloning (and why it is no longer working on today's networks)
→ SIM swapping, the social engineering strike that took over from the original
→ SS7 exploitation, the telecom door that most people are oblivious to
→ 5 easy defensive measures you can take right now

If you are relying on SMS for your 2FA, then this is definitely one for you.

🔗 Complete article: https://vickkykruzprogramming.dev/blog/why-sim-cloning-isn-t-used-anymore-and-what-changed-it

Like‍‌‍‍‌ and follow for more security-related content.
And if you want, you can subscribe to our newsletter to receive breakdowns just like this one directly in your ‍‌‍‍‌mailbox.

CyberSecurity #InfoSec #SIMSwap #DataPrivacy #DigitalSafety

StackSentry Is Now Installable — And We Need You to Break It

VickkyKruz NetSec — Sat, 11 Apr 2026 04:08:12 +0000

Hi everyone 👋

I've spent the last several weeks detailing everything about StackSentry, how it works, what it scans, how it auto-fixes security issues, and what you can expect from it across different stacks. Now it's time for the most important part: I need you to test it and tell me what breaks.

🛡️ StackSentry v1.0.0 is officially live on PyPI.

In one command, it scanned my own VPS, auto-fixed six security issues via SSH, and took the security grade from F (16.7%) to C (72.7%) — with zero attack paths detected after fixes.

pip install stacksentry

I'm looking for testers across all stacks: Flask, Django, PHP, WordPress, shared hosting, VPS. If you have a web app running anywhere, run it, open issues, and tell me what's wrong. Your feedback at this stage is everything.

I've written up the full story, what it does, how it works, and the proof in my latest article. Go through it and share your thoughts: 👉 https://vickkykruzprogramming.dev/blog/stacksentry-is-now-installable-and-we-need-you-to-break-it

Also, the full project README is on GitHub, it can be access here: 👉 https://github.com/vickkykruz/stacksentry

⭐ on GitHub helps it reach more people. Thank you in advance.

DevOps #Security #Python #OpenSource #WebDev

Are AI Companies Monetising Our Desperation? My Honest Claude Experience

VickkyKruz NetSec — Wed, 08 Apr 2026 01:47:09 +0000

8 years as a software engineer. I've tried ChatGPT, DeepSeek, Perplexity and Claude felt the best.

But I kept hitting usage walls. So I wrote about it and the uncomfortable question it raised.

What do you think? Drop your thoughts below 👇

https://vickkykruzprogramming.dev/blog/are-ai-companies-monetising-our-desperation-my-honest-claude-experience

Your Cache Is Lying to You, Here's How to Reveal the Truth

VickkyKruz NetSec — Fri, 03 Apr 2026 12:38:14 +0000

Hello folks 👋

This is a topic that doesn't get discussed much in engineering communities: caching is probably one of the most hazardous implements in your toolset, not because setting it up correctly is difficult but because it is capable of failing silently, and the worst part is the timing of such failure.

There were instances when I saw production systems shut down simply because a cache key got expired at the wrong time. There were also moments when bugged pricing showed incorrect data to thousands of people throughout several minutes just because no one doubted the cache result. Distributed systems constituted another source of problem two users accessing the same endpoint getting two entirely different results simply because distinct instances maintained different cached data.

Such situations are not rare at all. They are recurring issues. And even the best engineers making these mistakes may be those who really know better in actuality.

Therefore, I decided to put together a comprehensive, research-supported exposition of the six most risky cache memory problems in sophisticated software illustrating each challenge with documented failure scenarios, runnable code snippets, and even the exact engineering tactics employed for their resolution.
👉 "Your Cache Is Lying to You: Here's How to Reveal the Truth"

https://vickkykruzprogramming.dev/blog/your-cache-is-lying-to-you-the-hidden-problems-of-cache-memory-in-complex-applications-and-the-engineering-discipline-to-fix-them

This article details the following: Cache Stampede · Cache Invalidation · Cache Penetration · Cache Avalanche · Distributed Inconsistency · Memory Pressure & Eviction

Featuring real-life case studies including how Facebook managed to reduce its peak database querying by 92% with just one caching tweak.
It would be great to get your perspective, have you ever encountered any caching issue that affected production? Why not share your experience with us here? Also, if this sort of hardcore engineering material is something you're interested in, consider hitting the follow button or subscribing.

SoftwareEngineering #SystemDesign #Caching #Redis #BackendDevelopment #TechBlog #Developer

From ATMs to WhatsApp: The Old Programming Languages Behind Your Everyday Tech

VickkyKruz NetSec — Wed, 01 Apr 2026 23:58:21 +0000

Hello👋 everyone

I was halfway through a thought when something hit me and stopped me dead in my tracks: the software running your ATM machine was coded even before your parents were born. The code forecasting the weather of tomorrow is older than the internet. The backend delivering your WhatsApp messages is built using a programming language that most developers have not even heard of.

We often discuss what the latest tech things are. Languages like #Python, #Rust, and #TypeScript, the shiny tools that everyone is learning. However, very few talk about the real factors that are holding all these up.

Hence, I followed a trail down the hole. I looked into 7 programming languages that the world had declared as old and no longer of use, and yet I discovered them quietly running global banking, space missions, aircraft avionics, and real-time communication of billions of people.

Here is the first piece of my blog:
👉 "From ATMs to WhatsApp: The Old Programming Languages Behind Your Everyday Tech"

https://vickkykruzprogramming.dev/blog/from-atms-to-whatsapp-the-old-programming-languages-behind-your-everyday-tech

It delves into COBOL, FORTRAN, Assembly, LISP, Erlang, Ada, and Prolog, complete with actual statistics, real companies, and the honest reasons why nobody has yet replaced them.

Let me know what you think, have you ever worked with any of these languages? Leave a message below and share your experience.

And if you like content that digs deeper than the headlines, don't hesitate to hit the follow or subscribe button. There's a lot more coming. 🙏

Programming #TechHistory #COBOL #SoftwareDevelopment #LegacyCode #Developer #TechBlog