-
-
Notifications
You must be signed in to change notification settings - Fork 6
Investigate further system security hardening #479
Copy link
Copy link
Open
Labels
component: securityAn issue relating to host security (e.g. hardened security preferences). This is NOT critical bugs.An issue relating to host security (e.g. hardened security preferences). This is NOT critical bugs.component: servicesAn issue relating to a Python Discord service (e.g. Bot, Site, Lancebot)An issue relating to a Python Discord service (e.g. Bot, Site, Lancebot)group: ansibleIssues and pull requests related to the Ansible setupIssues and pull requests related to the Ansible setup
Metadata
Metadata
Assignees
Labels
component: securityAn issue relating to host security (e.g. hardened security preferences). This is NOT critical bugs.An issue relating to host security (e.g. hardened security preferences). This is NOT critical bugs.component: servicesAn issue relating to a Python Discord service (e.g. Bot, Site, Lancebot)An issue relating to a Python Discord service (e.g. Bot, Site, Lancebot)group: ansibleIssues and pull requests related to the Ansible setupIssues and pull requests related to the Ansible setup
Type
Projects
Status
Up next
Planning ticket to check out and investigate further possibilities at security
hardening. Ideally these should be contributed upstream if applicable.
Things to consider:
Of course, service-specific hardening strategies implemented in code also play a
role. For Postfix and OpenSSH for instance I am way less concerned than e.g. for
Jitsi. At the bare minimum, all services should run under a dedicated user.
This ticket is not for evaluating resource limits per service (e.g. to prevent
DoS on externally reachable services), although it might also be interesting to
evaluate that.