Hiding in Plain Sight: Building an OPSEC-Safe, Tor-Hidden Logging Fortress + Video

By /

Listen to this Post

Featured Image

Introduction:

In the silent seconds following a server compromise, the attacker’s first instinct isn’t to steal data—it’s to cover their tracks. They will immediately inspect the logging configuration (/etc/rsyslog.conf or /etc/syslog-ng/syslog-ng.conf) to locate your central log collector. If that collector is sitting on a cleartext IP address, you have just handed the adversary the keys to the evidence locker, allowing them to pivot, destroy logs, or inject false data. To counter this, we implement a zero-trust logging architecture where the log server exists on a Tor Hidden Service, rendering it invisible to network scanners and post-exploitation enumeration.

Learning Objectives:

  • Understand how to architect a logging system where the server’s network location is cryptographically hidden.
  • Learn to implement Tor v3 client authorization to restrict access at the network level.
  • Configure mutual TLS (mTLS) between `syslog-ng` instances to prevent log injection.
  • Implement disk-based buffering to maintain log integrity during network interruptions.

You Should Know:

1. Understanding the Threat: Why Clearnet Logging Fails

When an attacker gains root access, they run a series of discovery commands. They will look for outbound connections (ss -tupn), check running processes (ps aux), and grep configuration files for IP addresses. If they see a `syslog-ng` process sending data to 192.168.1.100:514, they now have a high-value target to attack next. Our solution abstracts the network layer entirely. By forcing all log traffic through the Tor network to a `.onion` address, the attacker only sees a local `socat` process talking to 127.0.0.1. There is no route to the real server, no DNS record to query, and no IP to scan.

2. The Foundation: Tor v3 with Client Authorization

Tor v3 Hidden Services offer significant improvements over v2, including better encryption and the ability to require client authentication. This means simply knowing the `.onion` address is not enough; the client must possess a specific private key to establish a connection.

Step-by-step (On the Logging Server – FreeBSD/Logger):

1. Install Tor: `pkg install tor`

2. Edit `/usr/local/etc/tor/torrc`:

HiddenServiceDir /var/db/tor/hidden_service_syslog/
HiddenServicePort 514 127.0.0.1:514
HiddenServiceVersion 3
HiddenServiceAuthorizeClient stealth client1,client2

3. Restart Tor: `service tor restart`

  1. Retrieve the hostname and the client keys: The `.onion` address is in /var/db/tor/hidden_service_syslog/hostname. The client authorization keys (for distribution to clients) will be generated in the same directory.

On the Client (Ubuntu/Linux):

  1. Install Tor: `sudo apt update && sudo apt install tor -y`

2. Edit `/etc/tor/torrc` to add the client key:

ClientOnionAuthDir /var/lib/tor/auth

3. Create the auth file: `sudo nano /var/lib/tor/auth/client1.auth_private`

Content: `<16-character-client-id>:descriptor:x25519:` (This key is generated on the server).

3. Tunneling Traffic: Socat as the Transporter

The client’s `syslog-ng` cannot speak the Tor protocol natively. We use `socat` to create a local tunnel that forwards traffic into the Tor network.

Step-by-step (On the Ubuntu Client):

1. Install socat: `sudo apt install socat -y`

  1. Create a systemd service to keep the tunnel alive: `/etc/systemd/system/socat-tor.logger.service` 
    [bash]
Description=Socat tunnel to Tor Hidden Service for Logging
After=network.target tor.service
Requires=tor.service</li>
</ol>

[bash]
Type=simple
User=root
ExecStart=/usr/bin/socat TCP4-LISTEN:10514,fork,reuseaddr SOCKS4A:127.0.0.1:yourhiddenaddress.onion:514,socksport=9050
Restart=always
RestartSec=10

[bash]
WantedBy=multi-user.target

    Replace `yourhiddenaddress.onion` with the actual address.

    1. Enable and start: `sudo systemctl daemon-reload && sudo systemctl enable socat-tor.logger.service && sudo systemctl start socat-tor.logger.service`

      Now, anything sent to `localhost:10514` on the client is automatically routed through Tor to the hidden server.

    4. Mutual TLS: Ensuring Identity, Not Just Anonymity

    Tor protects the transport, but we must also protect the data and verify the identity of the sender. Mutual TLS ensures the logging server only accepts connections from clients presenting a certificate signed by our private Certificate Authority (CA), preventing rogue servers or compromised clients from injecting data.

    Step-by-step (Creating the CA and Certs on a secure workstation):

    1. Generate CA private key and cert:

    openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/CN=LoggingCA"

    2. Generate server certificate (for the FreeBSD logger):

    openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=logger-hidden"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365

    3. Generate client certificates (for each Ubuntu client):

    openssl genrsa -out client1.key 2048
openssl req -new -key client1.key -out client1.csr -subj "/CN=client1"
openssl x509 -req -in client1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client1.crt -days 365

    Configure syslog-ng on the Logger (FreeBSD):

    Edit `/usr/local/etc/syslog-ng.conf`:

    source s_tls {
network(
ip(127.0.0.1) port(514)
transport("tls")
tls(
key-file("/etc/ssl/private/server.key")
cert-file("/etc/ssl/certs/server.crt")
ca-dir("/etc/ssl/certs")
peer-verify("required-untrusted")
)
);
};

    Note: `required-untrusted` forces the client to present a cert, but doesn’t require it to be signed by a public CA.

    Configure syslog-ng on the Client (Ubuntu):

    Edit `/etc/syslog-ng/syslog-ng.conf`:

    destination d_tor_hidden {
network(
"127.0.0.1" port(10514)
transport("tls")
tls(
key-file("/etc/ssl/private/client1.key")
cert-file("/etc/ssl/certs/client1.crt")
ca-file("/etc/ssl/certs/ca.crt")
peer-verify("required-trusted")
)
);
};

log {
source(s_src);
destination(d_tor_hidden);
};

    5. Reliability: Disk Buffering and Flow Control

    Tor can be slow or occasionally drop circuits. To prevent log loss, `syslog-ng` must buffer logs to disk when the destination is unavailable.

    On the Ubuntu Client (syslog-ng.conf):

    Modify the destination to include disk buffering:

    destination d_tor_hidden {
network(
"127.0.0.1" port(10514)
transport("tls")
tls( ... )
disk-buffer(
disk-buf-size(2000000)
mem-buf-size(10000)
reliable(yes)
)
);
};

    The `reliable(yes)` option ensures that messages are written to disk before they are acknowledged to the application, creating a zero-data-loss queue even during a system crash or network outage.

    6. Hardening and Firewalling

    To prevent the attacker from using the compromised client as a Tor relay or proxy, restrict the local `socat` process.

    On the Ubuntu Client (UFW/nftables):

    1. Ensure the client cannot act as a Tor exit. Block outbound non-Tor traffic to the internet, except for essential updates.

    2. Use `nftables` to restrict the `socat` user:

    nft add table inet filter
nft add chain inet filter output { type filter hook output priority 0\; }
nft add rule inet filter output meta skuid your_socat_user uid tcp dport 9050 accept
nft add rule inet filter output meta skuid your_socat_user reject

    This ensures the socat process can only talk to the local Tor SOCKS port (9050) and cannot make any other network connections.

    7. Operational Security: Verification

    After the compromise, verify the attacker cannot see the true destination.
    1. On the compromised client, run: ss -tupn | grep 10514. They will see a connection to 127.0.0.1:10514.
    2. Check the process list: ps aux | grep socat. They see the command connecting to the `.onion` address, but that address provides no geolocation, no IP, and no ownership data.
    3. Check iptables: They will find no rules allowing outbound traffic to the logging server, because the traffic is tunneled.

    What Undercode Say:

    • Network Anonymity is not enough; Identity is required: Hiding the server’s IP via Tor is a powerful first step, but without mTLS, any compromised client on the internet could theoretically send logs to your hidden server, potentially exhausting resources or injecting noise. The combination of “who you are” (mTLS) and “where you are” (Tor) creates a robust defense.
    • Assume Compromise, Plan for Visibility: This architecture is built on the assumption that the client will be compromised. By removing any identifiable information about the logging infrastructure from the client, we turn a post-breach enumeration win for the attacker into a dead end. The logs remain safe because the attacker cannot find them to destroy them.
    • Complexity is the Price of Stealth: This setup requires maintaining a private CA, managing Tor client keys, and configuring both `syslog-ng` and socat. However, for high-value assets (domain controllers, financial transaction servers, critical infrastructure), the operational overhead is justified to ensure an immutable audit trail exists outside the attacker’s reach.

    Prediction:

    As EDR (Endpoint Detection and Response) tools become better at detecting beaconing to known C2 (Command and Control) infrastructure, we will see a rise in defenders “going dark” to protect their own telemetry. Conversely, sophisticated attackers will begin to actively hunt for local Tor processes and certificate files as indicators of a hidden logging infrastructure. The cat-and-mouse game will shift from simply deleting logs to compromising the certificate authority or performing traffic analysis on the Tor network itself to deanonymize the logging server’s guard node.

    ▶️ Related Video (88% Match):

    🎯Let’s Practice For Free:

    IT/Security Reporter URL:

    Reported By: Dustin Hargrove – Hackers Feeds
    Extra Hub: Undercode MoN
    Basic Verification: Pass ✅

    🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

    💬 Whatsapp | 💬 Telegram

    📢 Follow UndercodeTesting & Stay Tuned:

    𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: