Last updated: 23 August 2026

DirektSupport provides technical administration for production Linux servers and hosting infrastructure.

This often requires privileged access to systems containing websites, databases, email, configuration files and other business data.

This Security & Access Policy explains how DOW MEDIA SRL, operating the DirektSupport service, approaches administrative access, credentials, infrastructure security and customer data while providing technical services.

1. Our Security Approach

Our approach is based on a few practical principles:

• access only what is necessary;
• use secure administrative protocols;
• prefer temporary or revocable access;
• minimise unnecessary credential sharing;
• protect production data before higher-risk changes;
• avoid unnecessary exposure of services;
• preserve Customer control of infrastructure;
• investigate security incidents carefully rather than applying superficial fixes.

Security measures are adapted to the actual infrastructure rather than applied as a generic checklist.

2. Customer Infrastructure Remains Under Customer Control

DirektSupport is an independent technical support provider.

Your:

• hosting account;
• VPS;
• cloud server;
• dedicated server;
• domains;
• DNS;
• Cloudflare account;
• hosting control panel;
• WordPress installations;
• backup infrastructure;

remain under your ownership and control.

We do not require infrastructure to be transferred into an account controlled by DirektSupport unless this has been specifically agreed for a particular service.

Your server. Your provider. Our Linux expertise.

3. Administrative Access

Depending on the requested service, DirektSupport may require access to:

• SSH;
• root or sudo;
• hosting control panels;
• WordPress administration;
• MySQL or MariaDB;
• DNS management;
• Cloudflare;
• hosting provider consoles;
• backup systems.

We request only the level of access reasonably necessary to perform the agreed technical work.

Not every support request requires root access.

4. Temporary Access Is Preferred

For one-time interventions, we prefer access that can be revoked after the work is completed.

Where practical, this may include:

• temporary SSH users;
• temporary SSH keys;
• temporary passwords;
• restricted administrative accounts;
• temporary WordPress administrator accounts;
• time-limited provider access.

After a one-time intervention, Customers are encouraged to remove temporary accounts, revoke SSH keys or rotate credentials where appropriate.

5. SSH Key Authentication

Where practical, SSH key authentication is preferred over sharing permanent root passwords.

Benefits include:

• credentials can be revoked individually;
• the Customer does not need to disclose an existing root password;
• access can be attributed to a specific key;
• permanent server passwords do not need to be exchanged.

The exact access method depends on the server and the nature of the intervention.

6. Passwords & Credentials

Customers should not send passwords, private SSH keys or other sensitive credentials in the initial support request.

Initial requests should contain technical information such as:

• server IP or hostname;
• hosting provider;
• Linux distribution;
• hosting control panel;
• affected website or service;
• error messages;
• relevant screenshots or logs.

If privileged access is required, we will identify what access is needed after reviewing the request.

7. Private SSH Keys

We generally do not recommend sending an existing private SSH key belonging to the Customer or another administrator.

Where SSH access is required, it is normally better to add a dedicated public key for DirektSupport.

This allows access to be revoked without affecting other administrators.

8. Root Access

Some Linux interventions genuinely require root privileges.

Examples can include:

• operating system configuration;
• firewall changes;
• service recovery;
• package management;
• web server configuration;
• database recovery;
• email server administration;
• filesystem troubleshooting;
• security investigation.

Where root privileges are unnecessary, more restricted access may be sufficient.

9. Least-Privilege Access

Where practical, access should follow the least-privilege principle.

This means providing only the permissions necessary for the requested task.

For example:

• WordPress troubleshooting may only require WordPress and hosting access;
• DNS work may only require DNS management;
• Linux service recovery may require SSH and sudo;
• infrastructure recovery may require the hosting provider console.

The appropriate access level depends on the incident.

10. Multi-Factor Authentication

Where supported by the relevant platform, we recommend enabling multi-factor authentication for important administrative accounts.

This is particularly relevant for:

• hosting providers;
• Cloudflare;
• domain registrars;
• control panels;
• business email accounts;
• other infrastructure management systems.

Where a Customer account uses multi-factor authentication, we do not recommend disabling it simply to provide DirektSupport access.

A separate authorised user or temporary access method is preferable where available.

11. Hosting Provider Access

Some incidents require access to provider-level functions such as:

• Rescue System;
• Recovery Console;
• KVM;
• firewall configuration;
• server reboot;
• snapshots;
• networking;
• disk management.

Where possible, Customers should use provider features that allow separate users, delegated permissions or temporary access.

If the provider does not support delegated access, alternative secure arrangements may need to be agreed.

12. Hosting Control Panel Access

DirektSupport supports environments using:

• HestiaCP;
• DirectAdmin;
• cPanel & WHM;
• VestaCP.

For control-panel-specific work, administrative panel access may be required.

Where the issue extends below the control panel into Linux services such as NGINX, Apache, MySQL, Exim or Dovecot, SSH access may also be necessary.

13. WordPress Access

For WordPress-specific work, access may include:

• WordPress administrator;
• website files;
• database;
• hosting control panel;
• SSH.

The required level depends on the problem.

A plugin configuration issue may require only WordPress access, while malware, PHP failures or server performance problems may require access to the hosting infrastructure underneath it.

14. Customer Data

During server administration, DirektSupport may technically encounter:

• website files;
• databases;
• email metadata;
• user accounts;
• server logs;
• application data;
• backup files.

We do not intentionally access Customer content that is unrelated to the technical task.

Access to files, databases or logs occurs only where reasonably necessary to diagnose, administer, migrate, secure or recover the relevant system.

15. Confidentiality

Technical information obtained while providing services is treated as confidential.

This may include:

• IP addresses;
• server architecture;
• configuration;
• customer records;
• logs;
• credentials;
• database structure;
• security information;
• backup locations.

Information is used only where necessary to provide the service, comply with legal obligations or protect legitimate legal and security interests.

16. Credentials Are Not Used for Other Purposes

Credentials supplied for a DirektSupport intervention are used only for the authorised technical service.

They are not used to:

• access unrelated systems;
• inspect unrelated business information;
• create marketing profiles;
• transfer control of infrastructure;
• perform work outside the agreed scope without authorisation.

17. Access After One-Time Support

One-time technical support does not require DirektSupport to retain permanent administrative access.

After the intervention, Customers may:

• remove our SSH key;
• delete temporary users;
• change temporary passwords;
• revoke provider access;
• remove temporary WordPress accounts.

Where further work is expected shortly afterwards, the Customer may choose to keep access available.

18. Ongoing Managed Servers

For monthly managed-server customers, ongoing administrative access may be necessary.

This allows DirektSupport to perform agreed tasks such as:

• maintenance;
• security updates;
• monitoring investigation;
• backup checks;
• configuration changes;
• troubleshooting.

Access remains limited to the systems covered by the management arrangement.

19. Access Logging

Where supported by the infrastructure, administrative activity may be recorded by:

• SSH logs;
• authentication logs;
• hosting provider audit logs;
• control panel logs;
• firewall logs;
• operating system logs.

These records can be useful for security investigations and accountability.

DirektSupport does not disable normal security logging simply to hide administrative activity.

20. Secure Connections

Administrative access should use encrypted protocols wherever practical.

These typically include:

• SSH;
• HTTPS;
• TLS-secured services.

Unencrypted administrative protocols should be avoided where secure alternatives are available.

21. Firewall & Network Security

DirektSupport may assist with firewall configuration at multiple layers.

This can include:

• provider firewall;
• UFW;
• iptables;
• nftables;
• CSF;
• Fail2Ban;
• Cloudflare.

The objective is to expose only services that genuinely need to be accessible.

Provider-level firewalls and Linux firewalls can often be used together as complementary security layers.

22. SSH Security

Where appropriate, Linux server security may include measures such as:

• SSH key authentication;
• access restrictions;
• disabling unnecessary authentication methods;
• limiting exposed ports;
• Fail2Ban;
• administrative account review.

The correct configuration depends on how the server is administered.

Security changes should not unnecessarily make legitimate administration more difficult or create a risk of losing access.

23. Software Updates

Keeping software reasonably current is an important part of server security.

Depending on the service agreement, DirektSupport may assist with:

• Linux security updates;
• web server updates;
• PHP;
• database software;
• hosting control panels;
• WordPress.

Updates may occasionally introduce compatibility problems, so production changes should be approached with appropriate caution.

24. Changes to Production Servers

Linux administration can involve changes to critical production systems.

These may include:

• service configuration;
• firewall changes;
• PHP changes;
• database work;
• software updates;
• filesystem operations;
• migration;
• security remediation.

Before higher-risk operations, we may recommend or create an appropriate backup or snapshot where practical.

No production change can be guaranteed to carry zero risk.

25. Backups Before High-Risk Work

Where an intervention could materially affect production data or server availability, having a current backup is strongly recommended.

Depending on the environment, this may include:

• provider snapshot;
• website backup;
• database backup;
• hosting control panel backup;
• filesystem backup;
• offsite backup.

If no usable backup exists, we may recommend creating one before continuing.

26. Backup Independence

For important infrastructure, we generally recommend that the only backup should not reside on the same production server.

Where appropriate, backup architecture may include an independent destination.

This can provide additional protection against:

• server failure;
• filesystem corruption;
• accidental deletion;
• malware;
• compromised credentials;
• failed updates.

27. Security Incident Investigation

DirektSupport can investigate incidents involving:

• compromised servers;
• hacked WordPress installations;
• malware;
• suspicious SSH access;
• spam;
• malicious cron jobs;
• unknown processes;
• unexpected network activity;
• provider abuse notifications.

The objective is to determine the likely extent of the incident rather than simply remove the first suspicious file found.

28. Compromised Servers

If there is evidence that the Linux operating system itself has been seriously compromised, we may recommend rebuilding the server.

A clean rebuild may be safer where there is evidence of:

• root-level compromise;
• persistent unauthorised access;
• unknown system modifications;
• stolen administrative credentials;
• widespread malware.

Cleaning an individual website does not automatically make a compromised operating system trustworthy again.

29. Credential Rotation After Security Incidents

Following a significant security incident, we may recommend rotating credentials such as:

• root passwords;
• SSH keys;
• hosting panel passwords;
• WordPress administrator passwords;
• database passwords;
• SMTP credentials;
• provider account credentials.

The necessary scope depends on the extent of the compromise.

30. Third-Party Infrastructure

DirektSupport does not control the security of third-party infrastructure providers.

This includes providers such as:

• Hetzner;
• OVHcloud;
• Netcup;
• Contabo;
• IONOS;
• Scaleway;
• DigitalOcean;
• Vultr.

Provider security controls, account permissions and infrastructure features remain subject to the respective provider.

DirektSupport can configure and advise on available features but cannot guarantee the security or availability of third-party infrastructure.

31. Access by Third Parties

DirektSupport does not intentionally share Customer administrative credentials with unrelated third parties.

Where another specialist or service provider needs access as part of an authorised service, appropriate confidentiality and data protection requirements apply.

Where GDPR processing relationships are involved, our Data Processing Agreement also applies as appropriate.

32. Customer Responsibilities

Customers also play an important role in infrastructure security.

We recommend that Customers:

• protect provider accounts;
• enable multi-factor authentication where available;
• avoid sharing administrator credentials unnecessarily;
• remove access belonging to former staff or contractors;
• maintain appropriate backups;
• keep applications updated;
• notify DirektSupport of known security incidents;
• revoke temporary access when it is no longer required.

Security is a shared operational responsibility.

33. No Absolute Security Guarantee

No internet-connected system can be guaranteed to remain completely secure.

Firewalls, updates, strong authentication and good administration can significantly reduce risk, but they cannot eliminate every vulnerability or attack.

DirektSupport therefore does not promise that:

• a server can never be compromised;
• every attack can be prevented;
• every security incident can be fully reconstructed;
• every compromised system can be safely cleaned.

Our responsibility is to apply appropriate technical care within the agreed service scope.

34. Emergency Access

During a critical production incident, the fastest recovery path may require privileged access.

Examples include:

• server down;
• database down;
• email server down;
• filesystem failure;
• compromised server;
• failed firewall configuration.

Even during an emergency, we aim to request only the access reasonably necessary to investigate and recover the affected infrastructure.

35. Removing DirektSupport Access

Customers remain free to revoke DirektSupport access to their infrastructure.

For one-time support, this can normally be done immediately after completion.

For managed services, removing necessary administrative access may prevent us from performing some or all of the contracted management services.

36. Privacy & Data Protection

Where administrative work provides DirektSupport with access to Personal Data stored on Customer infrastructure, processing is handled in accordance with:

• our Privacy Policy;
• our Data Processing Agreement, where applicable;
• applicable data protection law.

For Customer-hosted Personal Data processed on the Customer’s instructions, DOW MEDIA SRL may act as a data processor while the Customer remains the data controller.

37. Reporting a Security Concern

If you believe that:

• your server has been compromised;
• unauthorised access has occurred;
• credentials may have been exposed;
• malware is present;
• your infrastructure is behaving suspiciously;

please provide as much technical information as possible.

Security-related technical requests can be sent to:

help@direktsupport.eu

Do not include passwords or private SSH keys in the initial message.

38. Security Contact

For security concerns relating specifically to DirektSupport services or access:

help@direktsupport.eu

For contractual, privacy or administrative matters:

office@direktsupport.eu

DOW MEDIA SRL
Strada Johann Heinrich Pestalozzi, Nr. 3-5
Timișoara, Romania
European Union

Trade Register: J35/3199/03.11.2004
VAT / Tax ID: RO16906010

Security & Infrastructure Experience Since 2004

The company behind DirektSupport has been established and continuously operational since 2004.

Our security approach comes from practical administration of Linux servers, hosting infrastructure, websites, databases, email and production systems.

The principle behind our access policy is straightforward:

Your infrastructure remains under your control. We request the access necessary to perform the work, use it only for that purpose and minimise unnecessary exposure of credentials and data.