DEV Community: Ethan

Building a Cybersecurity Lab: Project Overview 🗺️

Ethan — Sat, 25 Oct 2025 23:13:28 +0000

Throughout my cybersecurity journey I've heard the saying "hands-on experience beats theory," about a hundred times. I've always followed this principle when learning something new. Whether it be CTFs or small security related projects, I've had a blast taking on new challenges. However, there's one challenge that I've been eagerly waiting to take on until now.

After purchasing an old refurbished Dell tower desktop and installing Proxmox as my main OS, I'll finally be able to take on the unique challenge of building a home lab. To fully understand what it takes to secure a network, you've gotta do the real thing, and I have a feeling I'll end up learning a lot from this. Whether it be setting up a SIEM for SOC related purposes, simulating attacks, or practicing incident response, there's so much to learn when building and tinkering with a home lab.

📁 Cybersecurity Lab Architecture

Within this lab environment I plan on building out 5 separate networks:

Management Network - This is where my Proxmox administration and Internet access will sit.
Corporate Network - This will be a "production" environment with Active Directory. My main aim is to emulate a real corporate environment consisting of domain controllers, workstations, file servers, etc.
Security Tools Network - This is where most or all of my security tools will live. This network will include a SIEM, network monitoring, and my security infrastructure. I plan on incorporating tools such as Splunk, Wazuh, TheHive, MISP, and many more.
DMZ - This network segment will consist of vulnerable applications and exposed services. I'm thinking of introducing Metasploitable, DVWA, and exploitable web applications.
Red Team Network - This will be my isolated attack infrastructure, consisting of Kali Linux, attack tools, and C2 servers.

⚡ Data Flow

🎯 Project Goals

🛠️ Technical Skills

Configure enterprise security tools from scratch
Write detection rules (Sigma, SPL, YARA)
Analyze logs and network traffic for threats
Conduct digital forensics investigations
Automate security workflows with Python
Understand common attack techniques and how to detect them

📚 Analytical Skills

Threat hunting methodology and process
Incident investigation procedures
Root cause analysis and prioritization
Pattern recognition in security data

🤝 Soft Skills

Technical documentation and report writing
Communication of technical concepts

⭐ Next Steps

So far I've installed Proxmox and created network bridges for each of my segmented networks. Ontop of that, I've also downloaded the necessary ISOs for each operating system I plan on using in the lab.

Next up, I'll be installing pfsense for my firewall, which will allows me to understand how these segmented networks will communicate with each other.

If you'd like to follow along with my cybersecurity lab journey, please check out the Github repository I created for this project. There's not much in there right now, but I do plan on adding more as the project develops.

If you have any suggestions please leave them in the comments below!
Thanks for reading! 👋

Encrypting my HTTP server with OpenSSL in C 🔒

Ethan — Wed, 15 Oct 2025 01:41:49 +0000

Implementing TLS in My C HTTP Server

Quick Summary

After building my HTTP server in C, I was eager to start securing the site's traffic. I had heard a lot about SSL/TLS from studying for the CompTIA Security+ certification, but implementing it gave me a unique and more developed understanding of how it's actually integrated with network protocols.

How TLS Works

Before I dive into the code, it's important that we first understand the fundamentals.

The TLS handshake comes into play after the TCP three-way handshake and before any HTTP pages are served.

Here's a step-by-step overview of how the TLS 1.3 handshake unfolds:

The Client Hello Message. The client initiates the handshake by sending a "hello" message to the server. In this message the server will find:

The TLS version the client supports
The cipher suites supported
A string of random bytes known as "client random"
Parameters for calculating the premaster secret

Server Generates Master Secret. Server now has the following to create the master secret:

Client random
Client's parameters
Cipher suites

The Server Hello/Finished Message. The server's hello and finished messages include the following:

Server's certificate
Digital signature
Server random
Chosen cipher suite

Client Finished. The client verifies the validity of the signature and certificate, then generates the master secret, and sends a "Finished" message.

Last thing to note before we jump into the code implementation...

The TLS handshake utilizes asymmetric encryption. Asymmetric encryption is defined as a process of encryption that uses a pair of mathematically linked keys: a public key and a private key.

After the TLS handshake is completed, future traffic is encrypted using symmetric encryption. Symmetric encryption uses the same secret key to encrypt and decrypt data.

Code Implementation

OpenSSL is an open-source toolkit for cryptographic and secure communication. With OpenSSL we get access to two important libraries: libcrypto and libssl.

Cryptographic library (libcrypto): Contains a variety of cryptographic functions for symmetric encryption (like AES), asymmetric encryption (like RSA), as well as cryptographic hashing (like SHA256).

TLS/SSL library (libssl): Gives us access to the SSL and TLS protocols, which are used for secure connections.

#include <openssl/ssl.h>    // libssl
#include <openssl/err.h>    // openssl errors
#include <openssl/crypto.h> // libcrypto

OpenSSL in Action

Before, my HTTP server used POSIX functions to establish a basic connection. In order to create a secure connection, we'll need some additional functionality working around those POSIX functions.

setup_tls()

SSL_CTX *setup_tls() {
  SSL_library_init();
  OpenSSL_add_all_algorithms();
  SSL_load_error_strings();

  SSL_CTX *ctx = SSL_CTX_new(TLS_server_method());
  if (!ctx) {
    perror("Unable to create SSL context");
    ERR_print_errors_fp(stderr);
    exit(EXIT_FAILURE);
  }

  if (SSL_CTX_set_cipher_list(ctx, "DEFAULT:!aNULL:!eNULL") == -1) {
    fprintf(stderr, "failed to set cipher list\n");
    ERR_print_errors_fp(stderr);
    exit(EXIT_FAILURE);
  }

  if (SSL_CTX_set_ciphersuites(ctx, "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256") == -1) {
    fprintf(stderr, "Failed to set TLS 1.3 cipher suites\n");
    ERR_print_errors_fp(stderr);
    exit(EXIT_FAILURE);
  }

  if (SSL_CTX_use_certificate_file(ctx, "certs/cert.pem", SSL_FILETYPE_PEM) == -1) {
    perror("Unable to use cert file");
    ERR_print_errors_fp(stderr);
    exit(EXIT_FAILURE);
  }

  if (SSL_CTX_use_PrivateKey_file(ctx, "certs/key.pem", SSL_FILETYPE_PEM) == -1) {
    perror("Unable to use private key file");
    ERR_print_errors_fp(stderr);
    exit(EXIT_FAILURE);
  }

  if (SSL_CTX_check_private_key(ctx) == -1) {
    fprintf(stderr, "Private Key does not match certificate\n");
    exit(EXIT_FAILURE);
  }

  printf("✅ TLS Configured Successfully\n");

  return ctx;
}

There's a lot to unpack here. Let me break down the key components:

Initialization Functions

SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();

These three function calls initialize the OpenSSL library, register all available encryption algorithms, and load human-readable error messages that we can use for debugging.

Creating the SSL Context

The SSL_CTX structure holds all the configuration for our TLS implementation. We create it using TLS_server_method(), which automatically selects the highest TLS version supported by both client and server.

Configuring Cipher Suites

if (SSL_CTX_set_cipher_list(ctx, "DEFAULT:!aNULL:!eNULL") == -1) {
    fprintf(stderr, "failed to set cipher list\n");
    ERR_print_errors_fp(stderr);
    exit(EXIT_FAILURE);
  }

  if (SSL_CTX_set_ciphersuites(ctx, "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256")  == -1) {
    fprintf(stderr, "Failed to set TLS 1.3 cipher suites");
    ERR_print_errors_fp(stderr);
    exit(EXIT_FAILURE);
  }

The first function configures cipher suites for TLS 1.2 and earlier, excluding any that don't provide authentication or encryption. The second function specifically sets cipher suites for TLS 1.3, prioritizing AES-256 for maximum security.

Loading Certificates and Private Keys

The certificate and private key are essential for the TLS handshake. The certificate contains the server's public key and is sent to clients during the handshake. The private key remains on the server and is used to decrypt data encrypted with the public key. The SSL_CTX_check_private_key() function verifies that the private key corresponds to the certificate.

Integrating TLS into the Server Loop

With our TLS context set up, we need to modify how we handle client connections:

// After accepting a connection
    client_len = sizeof(client_addr);
    new_fd = accept(sockfd, (struct sockaddr *)&client_addr, &client_len);
    if (new_fd == -1) {
      perror("accept");
      continue;
    }

    // TLS handshake per connection
    SSL *ssl = SSL_new(ssl_ctx);
    if (!ssl) {
      perror("TLS handshake failed");
      continue;
    }

    if (SSL_set_fd(ssl, new_fd) == -1) {
      perror("Failed to set fd with SSL");
      continue;
    }

    printf("Performing TLS handshake...\n");

    if (SSL_accept(ssl) == -1) {
      fprintf(stderr, "SSL_accept failed\n");
      ERR_print_errors_fp(stderr);
      SSL_free(ssl);
      close(new_fd);
      continue;
    }


// Now use SSL_read() and SSL_write() instead of read() and write()
char buffer[4096];
bytes_received = SSL_read(ssl, buffer, sizeof(buffer) - 1);


// ... process request ...

SSL_write(ssl, file_content, size);

// Clean up
SSL_shutdown(ssl);
SSL_free(ssl);
close(new_fd);

The key difference is that we wrap the standard socket file descriptor with an SSL structure using SSL_new() and SSL_set_fd(). The SSL_accept() function performs the entire TLS handshake we discussed earlier. After that, we use SSL_read() and SSL_write() instead of the standard POSIX equivalents.

Key Takeaways

Implementing TLS from scratch gave me several important insights:

The abstraction is powerful but complex. OpenSSL handles an enormous amount of complexity behind relatively simple function calls. Understanding what happens during SSL_accept() helps appreciate the engineering that goes into secure communications.

Certificate management matters. In production, you'll need properly signed certificates from a Certificate Authority. For development, self-signed certificates work fine, but browsers will show security warnings.

Performance considerations are real. The TLS handshake adds latency to each new connection. This is why HTTP/2 and HTTP/3 emphasize connection reuse and why session resumption exists in TLS.

Error handling is critical. OpenSSL provides detailed error information through ERR_print_errors_fp(), which was invaluable during debugging.

What's Next

Now that the server supports TLS, I'm planning to take security further with:

Security Scanner: Build a tool to test my server against common vulnerabilities like weak cipher suites, certificate validation issues, and protocol downgrade attacks.

HTTP Fuzzer: Create a fuzzer to send malformed requests and edge cases to ensure the server handles unexpected input gracefully without crashes or security issues.

Vulnerability Analysis: Implement security headers (HSTS, CSP, X-Frame-Options) and test against tools like Nikto and OWASP ZAP to identify any remaining vulnerabilities.

Try it Yourself

If you want to experiment with TLS implementation, checkout out my project on Github!

Building a TLS-enabled server from scratch has been one of the most educational projects I've undertaken. It transformed my theoretical knowledge of cryptography and network security into practical, hands-on experience. I highly recommend trying it yourself if you want to deepen your understanding of how secure communications work at a fundamental level.

Have questions or suggestions? Feel free to reach out or leave a comment below!

Building an HTTP Server from Scratch in C: A Journey into Network Programming

Ethan — Fri, 10 Oct 2025 18:43:17 +0000

When you type a URL into your browser and hit enter, a complex dance of network protocols springs into action. But how many developers actually understand what's happening under the hood? I decided to find out by building a bare-metal HTTP/1.1 server in C—no frameworks, no libraries, just sockets and the HTTP specification.

Why Build This?

I had three main motivations for this project:

Learning by doing. Reading about TCP sockets and HTTP is one thing; implementing them yourself is entirely different. You discover edge cases the documentation never mentions and develop an intuition for how these fundamental protocols actually work.

Preparing for security work. My ultimate goal is to add TLS encryption and build security testing tools (scanner, fuzzer, analyzer) on top of this server. You can't secure what you don't understand, and understanding starts at the lowest level.

The satisfaction of first principles. There's something deeply satisfying about writing socket(), bind(), and listen() yourself and watching your browser successfully connect to your creation.

What I Built

The server currently supports:

HTTP/1.1 protocol with proper socket programming
GET requests for static file serving
POST requests with form data parsing
Multiple route support (/, /about, /submit)
Proper HTTP status codes (200, 404, 400, 405, 500)

The server listens on port 8080 and handles one connection at a time (yes, I know—more on that later).

The Technical Deep Dive

Setting Up the Socket

The foundation of any network server is the socket. Here's the basic flow I implemented:

Create address info structure using getaddrinfo() to handle both IPv4 and IPv6
Create the socket with socket()
Set socket options with SO_REUSEADDR to avoid "Address already in use" errors during development
Bind to a port so the OS knows which port belongs to our server
Listen for connections with a backlog of 1 (handling one connection at a time)

The beauty of using getaddrinfo() is that it makes the code protocol-agnostic. The same code works for IPv4 and IPv6 without modification.

Parsing HTTP Requests

Once a connection arrives via accept(), I receive the raw HTTP request into a buffer:

bytes_received = recv(new_fd, buffer, sizeof(buffer) - 1, 0);
buffer[bytes_received] = '\0';

The request comes in as plain text that looks like this:

GET /about HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0...

I parse the request line using sscanf() to extract the method, path, and HTTP version. Simple, but effective for this learning project.

Serving Static Files

For GET requests, the server maps URLs to files and serves them. The routing logic is straightforward—special paths like / map to index.html, while other paths are treated as literal filenames.

The file serving function handles several scenarios:

Success case (200 OK): Read the file, calculate its size, send proper headers with Content-Length, then send the file content.

File not found (404): Return an HTML error page explaining the file doesn't exist.

Memory allocation failure (500): Return an internal server error if we can't allocate memory for the file content.

One interesting challenge here was getting the Content-Length header right. Browsers need to know how many bytes to expect, so I use ftell() after seeking to the end of the file to get the exact size.

Handling POST Requests

POST request handling is significantly more complex than GET. Here's why:

The HTTP request body might not arrive all at once. The headers come first, terminated by \r\n\r\n, and then the body follows. The body might be small enough to arrive in the same TCP packet, or it might require multiple recv() calls.

My approach:

Extract Content-Length from the headers to know how many body bytes to expect
Find the body start by locating the \r\n\r\n delimiter
Calculate partial body bytes already received in the initial buffer
Loop and receive additional data until we have the full content length
Parse the form data (key=value pairs separated by &)
Write to output.txt for persistence

Here's the loop that ensures we get the complete body:

while(body_bytes_received < content_length) {
    ssize_t new_bytes = recv(new_fd, full_body + body_bytes_received, 
                            content_length - body_bytes_received, 0);
    if (new_bytes > 0) {
        body_bytes_received += new_bytes;
    }
}

This was crucial to learn—network programming is fundamentally asynchronous, and you can't assume data arrives all at once.

Challenges and Lessons Learned

Memory Management in C is Unforgiving

Coming from higher-level languages, C's manual memory management was a wake-up call. Every malloc() needs a corresponding free(), and forgetting one creates a memory leak. I use Valgrind during development to catch these issues.

For the file content and POST body, I dynamically allocate based on the size:

char *file_content = malloc(size + 1);  // +1 for null terminator
// ... use it ...
free(file_content);  // must not forget!

Buffer Overflows Are Real

With a fixed BUFFER_SIZE of 8192 bytes, I had to be careful about buffer overflows. Using sizeof(buffer) - 1 when receiving data and properly null-terminating strings became second nature. One typo using strcpy() instead of strncpy() could lead to security vulnerabilities.

HTTP Parsing Edge Cases

The HTTP specification has many edge cases I didn't initially consider:

What if there's no Content-Length header in a POST request?
What if the request is malformed with no \r\n\r\n delimiter?
What if the Content-Length value isn't a valid integer?

Each of these required adding defensive checks and returning proper 400 Bad Request responses.

The Debug Printf Dilemma

You'll notice the code has many printf() statements with "DEBUG:" prefixes. During development, these were invaluable for understanding the flow of data. In a production server, these would be replaced with a proper logging framework, but for learning purposes, seeing the raw data flow in the terminal was incredibly educational.

Concurrency (or Lack Thereof)

The biggest limitation of my current implementation is that it handles only one connection at a time with BACKLOG 1. While one client is being served, others must wait. The traditional solutions are:

Fork a new process for each connection (the Apache model)
Use threads with pthread
Implement non-blocking I/O with select/poll/epoll (the nginx model)

I plan to explore these approaches as the project evolves.

What's Next: Security Focus

The natural next step is adding TLS/SSL encryption, but I'm taking this further by building a security testing suite:

TLS 1.2/1.3 Implementation: Understanding encryption protocols from the ground up using OpenSSL or mbedTLS.

Security Scanner: A tool to scan web servers for common vulnerabilities (missing headers, outdated protocols, weak ciphers).

HTTP Fuzzer: Automated testing that sends malformed requests to find parsing bugs and potential crashes.

Vulnerability Analysis: Documentation of common web server vulnerabilities and how to prevent them.

The goal is to understand not just how to build a server, but how attackers might exploit one and how to defend against those attacks.

Key Takeaways

Building this HTTP server taught me more about networking in a week than years of using high-level frameworks:

Abstractions hide complexity. Express.js and Flask make web development easy, but they obscure the fundamental protocols. Understanding the foundation makes you a better developer at every level.

C demands precision. Every byte matters. Every pointer must be valid. Every buffer must be sized correctly. This discipline translates to better code in any language.

Network programming is asynchronous by nature. You can't assume data arrives all at once or in the order you expect.

Security starts at the design level. Every parsing decision, every buffer allocation, every user input is a potential vulnerability if not handled carefully.

Try It Yourself

If you're interested in learning network programming, I highly recommend building your own server. Start simple with a hello-world HTTP response, then gradually add features. The Beej's Guide to Network Programming is an excellent resource for learning socket programming in C.

The complete source code for this project is available on my GitHub, and I'll be documenting the security additions in future posts.

What low-level project are you working on? I'd love to hear about your experience in the comments below.

This is part of my journey into network security. Follow along as I add TLS encryption and build security testing tools on top of this foundation.