Linux Servers

Project Overview

Welcome to this hands-on guide where we’ll explore how to identify servers running on a Linux system using the command line. This lab, based on Cisco’s CyberOps Workstation VM, focuses on understanding servers and clients in an IP network context. By the end, you’ll be able to use tools like `ps`, `netstat`, and `telnet` to inspect processes and test TCP services. Let’s dive in and uncover the hidden world of background services!

Before jumping into the steps, here’s a summary of the key concepts from the project. These provide the foundation for why we’re doing what we’re doing and how Linux handles servers.

Servers and Clients : Servers are programs designed to provide specific information upon request. Clients are programs that reach out to servers, make requests, and await responses. This lab emphasizes IP network-based interactions, where communication happens over networks using protocols like TCP or UDP.

Processes in Linux : Running programs in Linux are called processes. Many run in the background, invisible to users. Tools like `ps` help display these, showing details such as Process ID (PID), Parent Process ID (PPID), user ownership, and more.

Services : A service is the task performed by a server (e.g., a web server provides web services). Servers often start automatically at boot time.

Netstat Tool : netstat displays network connections, helping identify servers. Key columns include:
Protocol (e.g., TCP/UDP).
Local Address:Port (e.g., 0.0.0.0:80 means listening on all IPs on port 80).
Foreign Address:Port (e.g., 0.0.0.0:* indicates no active remote connection).
State (e.g., LISTEN for waiting connections).
PID/Program Name (links the connection to a process).

Telnet Basics : Telnet is a simple remote shell application operating on TCP port 23 by default, but it can connect to other ports. It’s insecure (no encryption, transmits in clear text) and not recommended for management use SSH instead. However, it’s useful for testing TCP services by directly communicating with servers.

Nginx Overview : Nginx (pronounced “engine x”) is an open-source web server that also functions as a reverse proxy, load balancer, content cache, and more. It’s known for high performance, low resource usage, and handling large numbers of concurrent connections efficiently.

Port Conventions : Ports are conventional; e.g., port 80 TCP is typically for HTTP (web services), port 22 for SSH, port 21 for FTP.

Process Hierarchy : Programs can spawn child processes. Tools like ps -ejH show this tree structure, with indents indicating parent-child relationships.

Servers

1. Access the Command Line.
Click the terminal icon in the Dock at the bottom of the VM screen to open the terminal emulator.

2. Display the Services Currently Running.
Use sudo ps -elf to list all running processes (requires sudo password). This shows background programs as processes. Note: Output varies based on VM state.

Why use sudo?

To view all processes, including those owned by root.

3. Display Process Hierarchy.
Start the nginx web serversudo /usr/sbin/nginx
Use sudo ps -ejH to show the process tree. Look for nginx (highlighted in examples).
Output shows hierarchy with PIDs, PGIDs, SIDs, and commands, indented for parent-child relations.

How is hierarchy represented?

Indentation shows child processes under parents.

4. Use Netstat to Identify Network Servers.
Run netstat without options to see active connections and sockets.
Shows TCP connections and UNIX domain sockets.

Refine with sudo netstat -tunap : Filters TCP/UDP, shows numeric addresses, all connections, and PIDs.
Look for services like nginx on port 80.

Meanings of the options used from man netstat:
-t: TCP.
-u: UDP.
-n: Numeric addresses/ports.
-a: All sockets (listening and non-listening).
-p: Show PID/program name.

Order of options doesn’t matter when using this command it can as well be sudo netstat -panut .

In this case we see that for port 80: Protocol TCP, State LISTEN, PID (e.g., 1706/nginx). Likely a web service (HTTP).

5. Cross-Reference with PS and Grep.
Use sudo ps -elf | grep [PID] (e.g., 1706) to filter details on the process.
Shows owner, start time, and command (e.g., nginx: master process).

In the output above, the ps command is piped through the grep command to filter for only the lines containing the number 1706 . The result is three lines with text wrapping.
The first line shows a process owned by the root user (third column), started by another process with PID 1 (fifth column), at 20:46 (twelfth column)
The second line shows a process with PID 1707, owned by the www-data user, started by process 1706, at 20:46.

The third line shows a process with PID 1708, owned by the www-data user, started by process 1706, at 20:46.

The fourth line shows a process owned by the analyst user, with PID 1730, started by a process with PID 1635 , as the grep 1706 command.

The process PID 1706 is nginx. How could that be concluded from the output above?

It can be concluded it’s nginx from the command field.

The second line shows that process 1707 is owned by a user named www-data and has process number 1706 as its parent process. What does that mean? Is this common behavior?

Child process (e.g., PID 1707 owned by www-data ) means its a worker spawned by its master it is a common behavior so as to allow for servers to handle requests.

Why is the last line showing grep 1706?

Grep line appears because it matches itself in the process list.

Using Telnet to Test TCP Services

Telnet is a simple remote shell application. Telnet is considered insecure because it does not provide encryption. Administrators who choose to use Telnet to remotely manage network devices and servers will expose login credentials to that server, as Telnet will transmit session data in clear text.

Get Elijah Chimera’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

While Telnet is not recommended as a remote shell application, it can be very useful for quickly testing or gathering information about TCP services.
The Telnet protocol operates on port 23 using TCP by default. The telnet client however, allows for a different port to be specified. By changing the port and connecting to a server, the telnet client allows for a network
analyst to quickly assess the nature of a specific server by communicating directly to it.
Note: It is strongly recommended that ssh be used as remote shell application instead of telnet

nginx was found to be running and assigned to port 80 TCP. Although a quick internet search revealed that nginx is a lightweight web server, how would an analyst be sure of that? What if an attacker changed the name of a malware program to nginx, just to make it look like the popular webserver?

1. Test Nginx on Port 80.
   Connect to the local host on port 80 using telnet : telnet 127.0.0.1 80.
   Type random keys (e.g., fdsafsdaf) and press ENTER.
   Server responds with HTTP error (400 Bad Request), revealing it’s nginx/1.18.0.

Reflection.

While the server reported an error and terminated the internet connection it ascertains that indeed nginx with PID 1706 is infact a webserver. The error was sent as a web page because it’s an HTTP server. Learned it’s a web server, nginx version 1.18.0, the network stack in our VM is fully functional all the way upto Layer 7 of the OSI model.

2. Test SSH on Port 22.
Connect to port 22 to see if there are any processes attached to it : telnet 127.0.0.1 22.
Type random input; gets “Invalid SSH identification string” and closes.

3. Test Port 68.
Connect to port 68 to see what happens : telnet 127.0.0.1 68.

Our attempt to connect to port 68 using Telnet failed with a “Connection refused” error.

Here is exactly what happened and why:

Targeting Localhost: We attempted to connect to 127.0.0.1, which is the loopback address for our own local machine. The machine is definitely online, so the network request reached the destination immediately.

TCP vs. UDP Mismatch: telnet is strictly a TCP (Transmission Control Protocol) diagnostic tool. When you run telnet 127.0.0.1 68, it attempts to initiate a TCP three-way handshake on TCP port 68.

The Role of Port 68: Port 68 is famously known for handling DHCP client traffic (Dynamic Host Configuration Protocol). However, DHCP relies on UDP (User Datagram Protocol), not TCP.

Connection Refused: Because Telnet is knocking on TCP port 68, and your system does not have any application listening on that specific TCP port, your operating system actively rejected the connection. It sent back a TCP RST (Reset) packet, which Telnet translates into the “Connection refused” message we see on the screen.

In short, we used a TCP tool to probe a port that is almost exclusively used for UDP traffic.

General Guidelines

Use the CyberOps Workstation VM as the recommended equipment.
Outputs may differ based on VM state — always note your actual results.
Run commands as root (with sudo) when necessary to access full system info.

Safety Notes
Telnet is insecure — no encryption, clear text transmission. Avoid for real management; use SSH instead.
When testing services, send minimal input to avoid disrupting them.
Be cautious with starting services like nginx — ensure no conflicts.

Conclusion

Congratulations! You’ve now navigated through identifying and testing Linux servers. Reflect on these questions to solidify your understanding:

1. What are the advantages of using netstat?

netstat (Network Statistics) is a foundational command-line tool used to monitor network connections and routing tables. It acts like an X-ray for your machine's network activity.

Its primary advantages include:

• Complete Visibility: It shows all active TCP and UDP connections, so you know exactly what your machine is communicating with and who is connecting to it.
• Identifying Open Ports: You can use it to list all “listening” ports. When configuring cloud infrastructure or auditing a system, this is essential for verifying that only the intended services (like a web server on port 80/443) are exposed, reducing the attack surface.
• Malware & Incident Response: If a system is compromised, netstat can help identify rogue connections communicating with external Command and Control (C2) servers.
• Troubleshooting: It helps diagnose networking issues by displaying routing tables and interface statistics, allowing you to see if traffic is being routed correctly.

(Note: While netstat is widely used, on modern Linux distributions, the ss (socket statistics) command is often recommended as its faster, more modern replacement.)

2. What are the advantages of using Telnet? Is it safe?

Telnet is one of the oldest network protocols, originally designed for remote terminal access to servers. Today, its role has shifted significantly.

Advantages of Telnet:

• Quick TCP Port Testing: As you saw in our previous test, telnet [IP] [Port] is a fast, built-in way to verify if a specific TCP port is open and accepting connections. This is incredibly useful for verifying firewall rules or cloud security group configurations.
• Banner Grabbing: When assessing target systems for vulnerabilities, Telnet can be used to connect to an open port and grab the “banner” (the welcome message the service sends). This often reveals the exact software and version running on that port (e.g., Apache 2.4.41 or OpenSSH 8.2), which is vital for penetration testing.
• Manual Protocol Interaction: Because Telnet just opens a raw text connection, you can use it to manually type out commands for plaintext protocols like HTTP, SMTP (email), or FTP to see exactly how the server responds.

Is Telnet Safe?

No, it is highly insecure for remote management.

Here is why you should never use Telnet to log into a system:

• Zero Encryption: Telnet sends absolutely everything in plaintext. This includes your username, your password, and every command you type.
• Susceptible to Sniffing: Anyone on the same network using a packet sniffer (like Wireshark) can capture your traffic and instantly read your credentials.
• Man-in-the-Middle (MitM) Attacks: Because the traffic is unencrypted and unauthenticated, an attacker can easily intercept and alter the communication between you and the server.

The Solution: For remote administration, always use SSH (Secure Shell). SSH provides the same terminal access as Telnet but encrypts the entire session, ensuring your credentials and data remain secure. Keep Telnet in your toolkit strictly as a diagnostic and testing tool.

This lab highlights the power of command-line tools in cybersecurity operations. Feel free to experiment further in your VM.