Deaddrop is either installed from an ISO-file or by using a VHD-file for an Azure installation.
The installation is largely unattended—only the root password needs to be set manually.
If installing in a virtualized environment, set the guest operating system type to Linux or Fedora for optimal compatibility.
Once the system reboots, log in to the console to perform the remaining configuration steps.
To manually configure the IP address, edit the connection profile for the network interface using the vi text editor. The default file path is:
/etc/NetworkManager/system-connections/enp1s0.nmconnection
Note: The interface name (enp1s0) may vary depending on your hardware. Use ip a or nmcli device to confirm the correct interface name.
Open the connection file in vi:
vi /etc/NetworkManager/system-connections/enp1s0.nmconnection
Locate and edit the [ipv4] and [ipv6] sections:
[ipv4]
method=manual
address=1.2.3.4/24
gateway=1.2.3.1
dns=8.8.8.8;8.8.4.4
[ipv6]
method=disabled
Apply changes:
systemctl restart network
Verify that the server is reachable with SSH.
The default partition layout may vary depending on the installation. To determine the current disk usage and layout, start by inspecting the partition table.
Use the following command to view the current mounted filesystems and their usage:
df -h
Look for the partition associated with /var mount point.
The setup uses LVM and you need to increase the size of the /var partition, you can extend it as needed. The following example expands /var by 100 GB:
/usr/sbin/lvextend -r -L+100G /dev/mapper/root_vg-lv_var
Note: -L+100G: Increases the logical volume by 100 GB.
The server must be configured with a fully qualified domain name (FQDN). This FQDN should match the Subject Alternative Name (SAN) specified in the TLS certificate used for the ICC and Repo server installation.
Configure the Hostname
Use the following command to set the system’s hostname:
/usr/bin/hostnamectl set-hostname servername.domain.tld
Replace servername.domain.tld with the actual FQDN assigned to the server.
To enable secure communication, a valid TLS certificate signed by a trusted Certificate Authority (CA) must be installed.
Create a private key and generate a certificate signing request (CSR). The CSR should then be signed by a trusted CA (internal or external).
Example command to generate key and CSR:
openssl req -new -newkey rsa:4096 -nodes -keyout FQDN.key -out FQDN.csr
Replace FQDN with the fully qualified domain name of the server.
/opt/sysctl/deaddrop/etc/deaddrop/certs/FQDN.key
/opt/sysctl/deaddrop/etc/deaddrop/certs/FQDN.crt
Append the intermediate CA and root CA certificates to the same .crt file, in that order, to complete the certificate chain.
Ensure that the certificate configuration file reflects the correct paths to the certificate and key:
/opt/sysctl/deaddrop/etc/deaddrop/conf.d/cert.d/cert.conf
Verify that it includes the following directives:
SSLCertificateFile /opt/sysctl/deaddrop/etc/deaddrop/certs/FQDN.crt
SSLCertificateKeyFile /opt/sysctl/deaddrop/etc/deaddrop/certs/FQDN.key
Note: Replace FQDN with your server’s actual fully qualified domain name.
The default (out-of-the-box) configuration of DeadDrop is designed with a strong emphasis on security. All parameters are preconfigured to prioritize secure defaults and minimize attack surfaces.
At the same time, the setup provides flexibility for administrators to adjust key system and application parameters. This allows the deployment to be aligned with organizational policies and compliance requirements, without compromising the system’s core security posture.
The following settings are considered static, meaning they are not intended to be modified through the standard user interface. However, this configuration may evolve over time as future platform releases introduce new web-based configuration options within core system components (e.g., Apache).
The Deaddrop service, including its graphical administration interface, utilizes HTTPS (HTTP over TLS) to secure all communication between clients and the server.
TLS Cipher Suites
By default, DeadDrop is configured to accept only a limited set of secure and modern TLS cipher suites:
This curated list represents a security-focused subset of the full cipher suite selection available in TLS. It has been narrowed down to include only strong and widely supported options, ensuring both robust encryption and compatibility with modern web browsers.
Supported TLS Versions
The following protocol versions are supported by default:
Note: Older and insecure protocol versions—including TLS 1.1, TLS 1.0, and SSL—are explicitly disabled in the default configuration to reduce exposure to known vulnerabilities.
Security Enhancements
The system includes a preconfigured local firewall that restricts inbound traffic to a limited set of essential ports, enhancing the overall security posture.
The following inbound ports are allowed:
It is strongly recommended to restrict external access to the following TCP/IP ports, allowing connections only for trusted internal administrators:
It’s strongly recommended to block access, besides for the internal administrators access, to the following TCP/IP ports
These ports should not be exposed to the public internet unless absolutely necessary and properly secured (e.g., via VPN, jump hosts, or IP whitelisting).
Note: For a complete overview of all required firewall rules, refer to the Deaddrop network architecture diagram.
The following parameters are, or should be, configured to ensure secure and reliable operation of the DeadDrop platform. These settings may include defaults, recommended adjustments, or mandatory values based on your deployment environment and organizational policies.
All core service settings can be managed through the administrative web interface. This interface provides access to configuration options necessary for operating and securing the Deaddrop platform.
Note: Some advanced or low-level parameters may still require manual editing of configuration files, depending on deployment requirements.
All SMS-related settings can be managed directly through the administrative web interface. This includes configuring SMS gateways, authentication credentials, message templates, and delivery rules.
Note: Ensure that the configured SMS provider supports secure communication and complies with applicable data protection regulations.
To configure Deaddrop with SAML authentication or X.509 certificate-based access, please refer to the separate documentation provided by Sysctl.
By default, Deaddrop uses a preconfigured repository for receiving system and application updates. If a custom repository is required—such as for offline environments, staging workflows, or policy compliance—the default repository must be cloned and made accessible to the DeadDrop system.
Additionally, the package ddplugin-upgrade must be installed to support upgrades from a custom repository.
Configuring a Custom Repository
To enable DeadDrop to use a custom repository:
Set the configuration parameter local_repo to point to the desired repository configuration file.
Ensure that the specified file is correctly formatted and accessible.
Confirm that the repository mirror is complete and up-to-date.
Note: Once a custom repository is activated, all system updates must be performed via upgrade.service to ensure consistency and correct repository usage.
© Copyright sysctl Aktiebolag 2013-2025. All rights reserved
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security ↩