Research 2026-04-05 @reeshasx

GHOST_SERVERS: Implementing HTTP via SystemD Sockets & Bash

[ 0x00 ] A PEGADA DOS DAEMONS MODERNOS

Tornou-se padrão na arquitetura web moderna subir stacks complexas como containers de Node.js, instâncias Apache ou servidores Nginx completos apenas para expor um endpoint simples de monitoramento, servir um JSON estático de status ou responder a webhooks simples de C2. Cada processo ativo consome megabytes de RAM na tabela de processos do kernel, expõe dependências e deixa uma pegada forense perceptível.

Para cenários minimalistas ou de alta restrição, é possível erguer um serviço HTTP funcional e isolado aproveitando recursos nativos do sistema operacional Linux: o gerenciador SystemD e o interpretador Bash.

[ 0x01 ] SYSTEMD SOCKET ACTIVATION

O mecanismo baseia-se na funcionalidade de Socket Activation do SystemD. Em vez de manter um interpretador ou binário em loop infinito consumindo CPU e memória aguardando conexões (como em um loop listen), delegamos a escuta da porta de rede diretamente ao daemon de init do kernel (SystemD).

Quando um pacote TCP atinge a porta monitorada, o SystemD intercepta o evento, instancia (fork) o script Bash correspondente em tempo de execução e repassa o descritor de conexão diretamente via entrada e saída padrão (stdin/stdout). Ao encerrar a conexão, o processo do shell é finalizado, retornando a zero o consumo de memória do serviço.

Crie o arquivo de escuta do socket em /etc/systemd/system/ghost-http.socket:

[Unit]
Description=Ghost HTTP Socket Activation Service

[Socket]
ListenStream=8080
Accept=yes

[Install]
WantedBy=sockets.target

A diretiva Accept=yes instrui o SystemD a spawnar uma instância isolada do serviço para cada conexão concorrente estabelecida na porta 8080.

[ 0x02 ] A UNIDADE DE SERVIÇO TEMPLATE

Crie o arquivo de definição do serviço /etc/systemd/system/ghost-http@.service. O caractere @ no nome identifica que este é um serviço template, permitindo que o SystemD spawne instâncias dinâmicas (ex: ghost-http@1-127.0.0.1:8080.service) para cada socket aceito.

[Unit]
Description=Ghost HTTP Ephemeral Instance
Requires=ghost-http.socket

[Service]
StandardInput=socket
StandardOutput=socket
ExecStart=/usr/local/bin/ghost-server.sh

[ 0x03 ] O BACKEND EM SHELL SCRIPT

Abaixo está o script que manipula o tráfego HTTP. Note a presença obrigatória de aspas duplas nas variáveis para evitar problemas de segurança associados à expansão de caminhos (globbing) e word-splitting, além do uso de read -r para tratamento correto de barras invertidas.

/usr/local/bin/ghost-server.sh:

#!/bin/bash

# 1. Lê a primeira linha da requisição HTTP (Request-Line) de forma segura (sai em caso de EOF precoce)
read -r request || exit 1

# Remove quebras de linha CRLF (
)
request=$(echo "$request" | tr -d '
')

# 2. Loop para exaurir os cabeçalhos restantes da requisição (impede quebras de pipe)
while read -r line; do
    line=$(echo "$line" | tr -d '
')
    [ -z "$line" ] && break
done

# 3. Processamento de rota básica via awk
route=$(echo "$request" | awk '{print $2}')

# 4. Geração de resposta HTTP válida e cabeçalhos obrigatórios
if [ "$route" == "/api/status" ]; then
    # Responde com JSON dinâmico baseado em métricas de processamento reais
    load_avg=$(cat /proc/loadavg | awk '{print $1}')
    echo -e "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nConnection: close\r\n\r\n"
    echo -e "{\"status\": \"active\", \"load_1m\": $load_avg}"
else
    # Responde com HTML estático convencional
    echo -e "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nConnection: close\r\n\r\n"
    echo -e "<html><body><h1>Ghost Server</h1><p>Operando via Socket Activation.</p></body></html>"
fi

Habilite o socket no sistema operacional:

chmod +x /usr/local/bin/ghost-server.sh
systemctl daemon-reload
systemctl enable --now ghost-http.socket

[ 0x04 ] VULNERABILIDADE A DOS (FORK BOMBING) E HARDENING DE UNIDADES

Embora seja uma solução extremamente elegante e silenciosa, a configuração descrita anteriormente expõe o servidor a ataques de Negação de Serviço (DoS) simples por exaustão de PIDs. Como cada conexão concorrente inicia um processo Bash em user-space, um ataque volumoso estourará o limite máximo de PIDs do kernel (/proc/sys/kernel/pid_max), travando todo o sistema operacional.

Para mitigar este vetor de ataque e assegurar a robustez do ambiente, é obrigatório enriquecer as configurações de limites de recursos diretamente nas diretivas do SystemD:

No arquivo /etc/systemd/system/ghost-http.socket (Limitação ao nível do driver de rede do SystemD):

[Socket]
ListenStream=8080
Accept=yes
# Limite máximo de conexões concorrentes ativas
MaxConnections=100
# Limite de conexões simultâneas originadas de um único endereço IP
MaxConnectionsPerSource=5

No arquivo /etc/systemd/system/ghost-http@.service (Limitação ao nível do cgroup do processo):

[Service]
StandardInput=socket
StandardOutput=socket
ExecStart=/usr/local/bin/ghost-server.sh
# Limita o número máximo de processos que a unidade pode instanciar (cgroup fork limit)
LimitNPROC=10
# Evita esgotamento estrito de tasks
TasksMax=5

[ 0x00 ] THE FOOTPRINT OF MODERN DAEMONS

Modern web architectures frequently deploy heavy application stacks—like Node.js runtimes, Apache servers, or full Nginx daemons—just to expose a simple health-check endpoint, serve static system telemetry, or process simple C2 webhooks. Each active daemon consumes valuable system memory in the kernel process table, introduces external library dependencies, and leaves a noticeable forensic trace.

For minimal footprint deployment or restricted environments, operators can establish a functional, isolated HTTP server utilizing native Linux system interfaces: the SystemD service manager and the Bash shell interpreter.

[ 0x01 ] SYSTEMD SOCKET ACTIVATION

The primary mechanism relies on SystemD's Socket Activation feature. Instead of executing a background loop consuming CPU and memory waiting for incoming network traffic (such as a standard socket listen call), we delegate the network interface listening to the system's initialization daemon (SystemD).

When a TCP packet reaches the designated port, SystemD intercepts the socket event, forks the designated Bash script at runtime, and forwards the socket connection descriptor directly through standard input and output (stdin/stdout). Once the connection closes, the shell process terminates, returning the service's memory usage back to zero.

Create the socket configuration unit at /etc/systemd/system/ghost-http.socket:

[Unit]
Description=Ghost HTTP Socket Activation Service

[Socket]
ListenStream=8080
Accept=yes

[Install]
WantedBy=sockets.target

Setting Accept=yes tells SystemD to spawn an isolated instance of the template service for every concurrent connection established on port 8080.

[ 0x02 ] TEMPLATE SERVICE UNIT DEFINITION

Create the template service unit file /etc/systemd/system/ghost-http@.service. The @ symbol in the filename designates this unit as a template, allowing SystemD to spawn dynamic transient instances (e.g., ghost-http@1-127.0.0.1:8080.service) for each accepted socket connection.

[Unit]
Description=Ghost HTTP Ephemeral Instance
Requires=ghost-http.socket

[Service]
StandardInput=socket
StandardOutput=socket
ExecStart=/usr/local/bin/ghost-server.sh

[ 0x03 ] THE SHELL BACKEND IMPLEMENTATION

Below is the shell code to process incoming HTTP requests. Note the strict use of double quotes on variables to prevent path expansion (globbing) and word-splitting issues, alongside read -r for safe backslash character handling.

/usr/local/bin/ghost-server.sh:

#!/bin/bash

# 1. Read the HTTP Request-Line safely (exit immediately if EOF occurs)
read -r request || exit 1

# Remove carriage returns (
)
request=$(echo "$request" | tr -d '
')

# 2. Loop to clear the remaining HTTP header block to prevent pipe crashes
while read -r line; do
    line=$(echo "$line" | tr -d '
')
    [ -z "$line" ] && break
done

# 3. Basic route extraction using awk
route=$(echo "$request" | awk '{print $2}')

# 4. Generate compliant HTTP response lines and headers
if [ "$route" == "/api/status" ]; then
    # Return a dynamic JSON body utilizing kernel metrics
    load_avg=$(cat /proc/loadavg | awk '{print $1}')
    echo -e "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nConnection: close\r\n\r\n"
    echo -e "{\"status\": \"active\", \"load_1m\": $load_avg}"
else
    # Return standard static HTML content
    echo -e "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nConnection: close\r\n\r\n"
    echo -e "<html><body><h1>Ghost Server</h1><p>Operating via SystemD Socket Activation.</p></body></html>"
fi

Enable the socket unit within the operating system:

chmod +x /usr/local/bin/ghost-server.sh
systemctl daemon-reload
systemctl enable --now ghost-http.socket

[ 0x04 ] DOS VULNERABILITY (FORK BOMBING) AND SYSTEMD HARDENING

While highly efficient and stealthy, the basic configuration described above leaves the server vulnerable to standard Denial of Service (DoS) attacks by PID exhaustion. Because each concurrent connection spawns a new user-space shell process, a packet flood will quickly exceed the kernel's max PID limit (/proc/sys/kernel/pid_max), crashing the operating system.

To mitigate this attack surface and ensure operational resilience, resource limits must be configured directly within the SystemD units:

In the socket file /etc/systemd/system/ghost-http.socket (SystemD connection throttling):

[Socket]
ListenStream=8080
Accept=yes
# Limit total concurrent active connections
MaxConnections=100
# Limit concurrent connections from a single IP address
MaxConnectionsPerSource=5

In the template service file /etc/systemd/system/ghost-http@.service (cgroup process throttling):

[Service]
StandardInput=socket
StandardOutput=socket
ExecStart=/usr/local/bin/ghost-server.sh
# Restrict the maximum number of processes the unit cgroup can create
LimitNPROC=10
# Limit total tasks within the cgroup to prevent resource starvation
TasksMax=5