Switch Hardening: Why It Always Takes a Backseat in Side Projects?

While recently reviewing the infrastructure of my side project, a set of financial calculators, I noticed that despite being meticulous about basic network security in large corporate structures, I struggle to show the same diligence in my "hobby" or "side" projects. This isn't just a personal failing; it's a reflection of a general "it'll do" approach I've observed across different teams and projects for years. Topics like switch hardening, which don't add a visible feature but form the foundation of the system, are often relegated to the back burner with a "let's leave it for now" attitude.

This situation is actually a consequence of a general mindset: quickly building something, delivering value to the user, and getting it working first. In corporate life, when working on an internal platform for a bank or an ERP for a large manufacturing firm, even the slightest security vulnerability is unacceptable. Yet, in our own small worlds, we operate with the thought, "Who would bother with my tiny system?" In this post, I want to discuss why switch hardening is so often overlooked, the risks it entails, and how I've approached this topic in my own experiences.

The 'Start Fast, Finish Fast' Mentality in Side Projects and Security

Side projects are inherently built on rapid prototyping and quick iteration. People want to bring an idea to life, get feedback, and ideally, monetize it. In this process, the concept of a "minimum viable product" (MVP) comes into play, which often leads to the neglect of "invisible" layers like security. When I was developing the first versions of my Android spam blocker app, I focused on the core functionality, always postponing security layers with a "I'll handle it later" mindset.

Several factors underlie this mentality: time constraints, cost, and lack of knowledge. Most side projects are run by individuals or very small teams. In a limited timeframe, writing code while also considering every detail of the network infrastructure, or even diving into the switch's CLI to learn complex commands, isn't usually among the priorities for most developers or entrepreneurs. For instance, I saw a friend spend hours on topics like "how to improve the performance of the product listing page" for his e-commerce site project, rather than on segmenting servers into VLANs or configuring port security settings. He admitted that even though he knew basic network principles, he couldn't find the extra motivation to apply this depth in practice.

⚠️ The Priority Fallacy

The "get it working first, then think about security" approach in side projects often results in "never thinking about security." A security vulnerability encountered in production can lead to costs and reputational damage far beyond the few hours spent upfront. In my experience, even a small vulnerability can turn into a major headache.

This situation is essentially a trade-off. On one hand, you want to produce something quickly; on the other, you need to consider the system's robustness and security. In the corporate world, this balance is usually struck with more resources and expertise. However, in side projects, this burden falls entirely on the individual. Therefore, we often tend to overlook risks with a "it'll do" attitude. While inspecting the network infrastructure of a client's small office, I noticed that even basic switch hardening settings were missing, and the network had serious vulnerabilities. This was a manifestation of the "small fish" syndrome: "Who would target us anyway?"

The Importance of Basic Network Security in Bare-Metal and Container Environments

I'm a fan of the bare-metal + container hybrid deployment model. This means the servers are physical, but the applications run within Docker or similar container orchestration tools. This approach provides me with both flexibility and performance. However, even in this setup, the security of the basic network infrastructure is critically important. Because no matter how isolated containers are, if the underlying physical network layer harbors a vulnerability, the entire system can be compromised. In one of my client's production environments, while there were very strict rules for security between containers, port security settings on the physical switches were neglected. This was a point that weakened the entire architecture.

Let's consider this: you have an application running in a container, tightly isolated with network policies. Great! But what if another server connected to the same physical switch initiates an attack within the network? For example, what if it tries to reroute traffic through itself using ARP spoofing? This is precisely where switch hardening comes into play. While container security provides significant protection at the L7 layer, switch hardening forms a fundamental defense line at the L2/L3 layers. Considering these two layers independently would be a big mistake.

In my own systems, I try to adhere to these principles even on the VPS hosting the backend of one of my side projects. Although I don't have direct access to the physical switch in a VPS environment, I try to apply this principle by creating VLAN-like segmentations within my own virtual network architecture and enforcing strict firewall rules. However, in environments where we have physical switches, this responsibility falls directly on us. When designing the infrastructure for a production ERP, I mandated that the database servers and application servers be on separate VLANs, and that traffic between these VLANs pass through a firewall. This was not just about software security, but also about ensuring isolation at the physical network layer.

ℹ️ Security Integrity in Hybrid Environments

In bare-metal + container hybrid deployments, security must be considered end-to-end, not just at the software layer but also at the physical network layer. A vulnerability in one layer can negate all efforts in other layers. While trying to ensure this integrity in my own systems, I've repeatedly seen how even a small vulnerability can affect the entire structure.

So, whether you use containers or virtual machines, if the underlying physical network backbone isn't robust, your security architecture is like a castle made of sand. Therefore, switch hardening is an "essential" step, especially in hybrid environments, and should never be overlooked.

DHCP Snooping and ARP Inspection: The Neglected First Lines of Defense

Two of the most overlooked, yet fundamental, network security features in side projects are DHCP Snooping and Dynamic ARP Inspection (DAI). These form the first and most critical lines of defense against especially Layer 2 (data link layer) attacks. These settings, which are standard in corporate networks, are generally not enabled in side projects with the thought, "I already have a small network, who would care?" However, in my own experiences, I've seen how these simple settings can prevent major problems.

DHCP Snooping prevents unauthorized DHCP servers on the network from distributing traffic. Imagine an attacker plugging their own DHCP server into the network and distributing their own IP addresses to all devices. In this scenario, all network traffic could pass through the attacker (a man-in-the-middle attack). I witnessed a similar scenario in a client project where an unwitting "guest" device from within the office, with its own DHCP server, disrupted the IP addresses of other devices on the network. This caused major chaos even in a small network. DHCP Snooping would have prevented this situation from the outset.

# Example configuration of DHCP Snooping on a Cisco Switch
# Enable DHCP snooping globally
ip dhcp snooping

# Enable for VLANs (e.g., VLAN 10 and 20)
ip dhcp snooping vlan 10,20

# Define the trusted port (the port connected to the DHCP server)
interface GigabitEthernet0/1
 ip dhcp snooping trust

# Set a rate limit for other ports (maximum 10 DHCP packets per second)
interface GigabitEthernet0/2
 ip dhcp snooping limit rate 10

Dynamic ARP Inspection (DAI) protects against ARP spoofing attacks. ARP (Address Resolution Protocol) is used to map IP addresses to MAC addresses. In ARP spoofing, an attacker sends incorrect ARP responses, causing traffic to be routed through them. DAI validates IP-MAC mappings through the switch's DHCP snooping table or static ARP entries and drops invalid ARP packets. This is essential, especially in an environment where critical servers are located within the same VLAN. I once saw in a small office environment where my own web server was located, such an attack was tested, and because DAI was not enabled, the traffic was easily intercepted. I never repeated this mistake, made as a student, in my subsequent projects.

🔥 Basic Security Vulnerabilities and Their Consequences

The lack of basic Layer 2 security measures like DHCP Snooping and DAI invites attacks such as man-in-the-middle and IP/MAC spoofing on the network. These attacks can lead not only to data theft but also to operational disruptions on the network. Last month, when I forgot to disable these settings in a test environment and performed an ARP spoofing simulation, the test network was completely paralyzed.

These two features significantly enhance the basic security of your system, even in a small side project network. Although their setup is relatively simple, they are often bypassed with the "it's not necessary" mindset. However, in my experience, these small steps prevent major problems that could arise later.

VLAN Segmentation and Adapting the Zero-Trust Approach to Side Projects

In corporate networks, VLAN (Virtual Local Area Network) segmentation is now standard. Separating network traffic for different departments, servers, and user groups enhances security and simplifies network management. However, in side projects or small-scale ventures, this topic is generally approached with reluctance with the thought, "We're only 5 people, why do we need VLANs?" I, on the other hand, try to implement at least a basic level of segmentation even in environments hosting the backends of my side projects. The philosophy behind this is my belief in the Zero-Trust architecture.

The Zero-Trust approach is based on the principle, "Everyone inside the network is untrusted." This means that when a device or user joins the network, they are automatically considered untrusted and must pass authentication and authorization to gain access. This, unlike the traditional "perimeter security" model, also provides protection against threats originating from within the network. While working on a manufacturing company's ERP, I saw that the PLCs on the production lines, operator screens, and servers were all on separate VLANs. This segmentation significantly limited the spread of potential cyberattacks.

# Example of VLAN configuration on a simple Cisco switch
# Create VLAN 10 (Server Network)
vlan 10
 name Servers

# Create VLAN 20 (Management Network)
vlan 20
 name Management

# Assign port GigabitEthernet0/1 to VLAN 10 (Access Port)
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 10

# Assign port GigabitEthernet0/2 to VLAN 20 (Access Port)
interface GigabitEthernet0/2
 switchport mode access
 switchport access vlan 20

While expecting this level of complexity in side projects might not be realistic, even a basic segmentation like "management network" (for switch, router access), "server network," and "user/guest network" can make a big difference. For example, some of the automation I've implemented for my own site runs in its own separate VLAN or an isolated network segment. This way, if an automation machine is compromised, it doesn't directly affect my main servers.

💡 Zero-Trust with Small Steps

Implementing a full-fledged Zero-Trust architecture in side projects can be challenging, but you can start with small steps. At the very least, moving your management traffic to a separate VLAN or isolating your servers from user devices is a great starting point. I experienced a similar trade-off during my own VPS migration process; I achieved significant security gains with simple segmentation.

This type of basic VLAN structure significantly enhances the security level in side projects. At one point, I realized that all the servers in the test environment of my own side project were on the same flat network. A vulnerability on one test server had the potential to easily spread to all other servers. This situation once again showed me how important Zero-Trust is, not just for corporate but also for small-scale setups.

Port Security and MAC Address Security: Physical Access Control

When we talk about network security, we often think of firewalls, IDS/IPS, or software vulnerabilities. However, physical access control, especially security on switch ports, is often overlooked. In side projects, switches used at home or in small office environments are usually left in "plug and play" mode. This means anyone can plug a device into a switch port and gain access to the network. This is where Port Security and MAC Address Security come into play.

Port Security allows you to limit the number of MAC addresses that can connect to a switch port and even lock specific MAC addresses to that port. This prevents unauthorized devices from connecting to the network. For example, a port can be configured to accept only the MAC address of my server. If another device is plugged in, that port will automatically shut down or trigger an alarm. I implemented this on the switches used for operator screens in a manufacturing firm. Each screen's MAC address was defined, and an alarm would immediately trigger if another device was plugged in. This was critical for the security of the production line.

# Example of Port Security configuration on a Cisco Switch
interface GigabitEthernet0/3
 switchport mode access
 switchport port-security
 switchport port-security maximum 1           # Allow only 1 MAC address
 switchport port-security mac-address sticky  # Stick the first learned MAC address
 switchport port-security violation restrict # In case of violation, drop packet and log

The sticky MAC feature automatically saves the first MAC address learned by a port into the configuration. This is much more practical than manually entering MAC addresses for each port. In case of a violation, the restrict mode drops the packet and generates a log message but does not shut down the port. The shutdown mode completely disables the port and requires manual intervention. I generally prefer the restrict mode because I prefer to receive a warning rather than the port shutting down completely in an emergency.

In my own side projects, especially in the small infrastructure hosting my backend servers, I apply Port Security to critical ports. This provides an additional layer of security, even if my physical access is limited. Once, in an environment where the server hosting the backend of a management application I developed was located, I accidentally plugged a test device into the main network. Thanks to Port Security, this device was prevented from gaining full network access, and I received an immediate alert. Even small "accident" moments like these show how valuable such security measures are.

⚠️ Physical Security and Remote Access

Remember, network security isn't just about cyberattacks. Physical access control is as important as cybersecurity. If you live in an environment where someone can physically access your switch, features like Port Security are essential. While managing some of my side projects from my home office, I did not underestimate these physical security measures.

Port Security and MAC Address Security are features that are often considered "unnecessary" but are critically important for preventing unauthorized access and attacks on the physical network. In side projects, even these simple settings can significantly improve your network's security.

Monitoring and Anomaly Detection: Before Saying "It'll Do"

Configuring switch hardening settings is, of course, an important step, but the work doesn't end there. Continuous monitoring is essential to ensure our configurations are working correctly and to detect potential anomalies in the network. We often overlook this aspect in side projects. We think, "I've made the settings, it's done." However, with years of experience, I know that even the best-configured system will eventually surprise us if it's not monitored. Last month, when I wrote sleep 360 on my own system and got OOM-killed, if I hadn't been regularly monitoring logs, I would have noticed the problem much later.

Regularly checking switch logs, monitoring port statuses, and tracking unexpected traffic spikes or drops allow us to catch potential issues early on. For example, a port consistently giving a port-security violation warning might indicate that an unauthorized device is trying to connect to that port or an attack attempt is underway. In my own systems, I've set up a simple log collection and alerting system to receive such warnings instantly. Although this is a much simpler version of the predictive/anomaly-based monitoring systems in large corporate structures, it gets the job done.

# Command to monitor logs from a Cisco Switch
show logging

# To view port security violations
show port-security interface GigabitEthernet0/3

# To view interface status and errors
show interface GigabitEthernet0/3 status
show interface GigabitEthernet0/3 errors

The information we obtain with these commands gives us important clues about the network's status. For instance, an increase in CRC errors in the output of show interface errors might indicate a physical cable issue. Or, seeing an unexpectedly high amount of broadcast traffic on a port could indicate a loop or a device malfunction. In a client project, I noticed excessive packet drops on a server's network interface. Upon examining the logs, I saw a port-security violation on the switch side, followed by the port entering a shutdown state. This was a problem quickly resolved thanks to early monitoring.

ℹ️ Monitoring and Anomaly Detection Solutions

For side projects, there's no need for complex SIEM solutions. A simple syslog server, analyzing logs with tools like fail2ban, or even periodically saving the show logging command output can be sufficient to start. The important thing is to be able to catch signals that "something is going wrong." In one of my side projects, while dealing with Redis OOM eviction policy choices, if I hadn't monitored memory usage, I would have noticed the performance regression much later.

In summary, making switch hardening configurations is a start, but continuous monitoring and anomaly detection are vital for maintaining the effectiveness of these settings and proactively resolving potential issues. Before saying "it'll do," knowing the system's condition has always protected me from major surprises.

Conclusion: Ignoring Basic Network Security Is Not an Option

Through years of experience in both corporate and personal projects, I've come to understand that overlooking fundamental network security topics like switch hardening in side projects creates more headaches for us in the long run. Factors like the "start fast, finish fast" mentality, cost concerns, and lack of knowledge, while triggering this situation, have repeatedly proven to be no excuse. Just as a delayed shipment report issue in a production ERP can occur, sometimes the most basic vulnerabilities can lead to the most complex problems.

Even in bare-metal and container hybrid deployments, the security of the physical network layer is critical for the robustness of the entire system. Simple yet effective measures like DHCP Snooping and Dynamic ARP Inspection prevent basic network attacks. Adapting VLAN segmentation and the Zero-Trust approach to side projects provides significant security gains even with limited resources. Physical access control with Port Security is a vital layer that is often overlooked. And on top of all this, regular monitoring and anomaly detection ensure the system remains secure at all times.

Let's not forget that cybersecurity is like the links in a chain. The weakest link determines the strength of the entire chain. Often, these weakest links are the "most basic" and "most tedious" parts. I continue to apply these principles for my side project with financial calculators and my Android spam blocker app. Perhaps not as detailed and strict as in corporate projects, but at a "good enough" level.

My firm position: do not underestimate basic network security, even in side projects. Invest time, learn, and implement. Believe me, these small investments will save you from much bigger problems in the future.