Sandbox99 Chronicles

Introduction

In our previous blog post, we explored the fundamentals and features of Cockpit, a lightweight web-based server management tool designed for Linux systems. We discussed its architecture, benefits, and why it has become an essential tool for system administrators who prefer simplicity without sacrificing control.

In this article, we’ll dive deeper into a practical aspect of Cockpit: binding its services. By default, Cockpit listens on all network interfaces (0.0.0.0:9090). While this simplifies accessibility, it can introduce security concerns in multi-user or exposed environments. Binding Cockpit to a specific network interface or restricting access via firewall rules ensures that only trusted hosts can reach the service.

Why Binding Cockpit Matters

• Security 🔒 – Limit exposure to only required interfaces. For instance If you have Linux server running with vlan or sub-interface by default it will advertised to all interface, you only need to make this accessible to management interface vlan
• Compliance 📜 – Aligns with organizational access control policies.
• Performance ⚡ – Reduces unnecessary network traffic on untrusted interfaces.

Methods for Binding Cockpit

1. Bind via systemd Override

Cockpit is managed by systemd as a socket-activated service. You can create an override file to bind it to a specific IP address.

sudo systemctl edit cockpit.socket

Add the following under [Socket]:

[Socket]
ListenStream=
ListenStream=192.168.1.100:9090

# If you're running this in Linux Desktop I would recommend to set in localhost
# ListenStream=127.0.0.1:9090

• The empty ListenStream= clears the default 0.0.0.0:9090 binding.
• Replace 192.168.1.100 with your desired network interface.

Apply changes:

sudo systemctl daemon-reexec
sudo systemctl restart cockpit.socket

Verify:

ss -tlnp | grep 9090

2. Restrict via firewalld

Instead of modifying systemd configs, you can keep Cockpit listening on all interfaces but restrict access through firewalld rules.

Example – Allow only from a trusted subnet (192.168.1.0/24):

# Allow Cockpit only from LAN
sudo firewall-cmd --permanent --add-rich-rule='
  rule family="ipv4"
  source address="192.168.1.0/24"
  port protocol="tcp" port="9090" accept'

# Deny everything else to port 9090
sudo firewall-cmd --permanent --add-rich-rule='
  rule family="ipv4"
  port protocol="tcp" port="9090" drop'

# Reload firewalld to apply changes
sudo firewall-cmd --reload

3. Restrict via ufw or iptables

For environments without firewalld, ufw and iptables can provide fine-grained control.

#############
# ufw
#############
sudo ufw allow from 192.168.1.0/24 to any port 9090
sudo ufw deny 9090


#############
# iptables
#############
# Flush any existing Cockpit rules (optional cleanup)
sudo iptables -D INPUT -p tcp --dport 9090 -j ACCEPT 2>/dev/null

# Allow Cockpit only from LAN
sudo iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 9090 -j ACCEPT

# Drop everything else to port 9090
sudo iptables -A INPUT -p tcp --dport 9090 -j DROP

Best Practices

• Combine systemd binding with firewall rules for layered security.
• Use TLS certificates (Cockpit supports them natively).
• Restrict access to management networks only, never the public internet.
• Monitor logs under /var/log/cockpit/ to audit connection attempts.

Final Thoughts

Binding Cockpit services is a simple yet crucial step in securing Linux web-based administration. Whether you use systemd overrides, firewalld, ufw or iptables, the goal remains the same: minimize the attack surface while keeping management accessible only to trusted networks.

By applying these methods, IT professionals can integrate Cockpit into their workflows with confidence, knowing that its accessibility is tightly controlled.