SystemD सेवा सुरक्षा सख्त करना (Hardening)

• systemd शक्तिशाली service management features प्रदान करता है, लेकिन इसकी default settings सुरक्षा की बजाय उपयोगिता के लिए optimized होती हैं, इसलिए अलग से hardening options लागू करना ज़रूरी है
• systemd-analyze security कमांड के जरिए पूरे service या किसी खास service की security exposure metrics का विश्लेषण करके priority तय की जा सकती है
• service unit स्तर पर लागू किए जा सकने वाले कई security options मौजूद हैं, और इन्हें /etc/systemd/system/ServiceName.service.d/override.conf आदि के जरिए अलग-अलग बदला जा सकता है
• मुख्य options में ProtectSystem, PrivateTmp, NoNewPrivileges, SystemCallFilter, MemoryDenyWriteExecute आदि शामिल हैं, जो process permissions और resource access को सीमित करते हैं
• perfect security को लक्ष्य बनाने की बजाय externally exposed services को पहले harden करके जोखिम घटाया जा सकता है, और self-hosting environments में भी इसका बड़ा असर होता है

---

systemd का अवलोकन

• systemd service management के लिए बहुत परिपक्व और मजबूत तरीका प्रदान करता है
• लेकिन सुरक्षा की बजाय तुरंत उपयोग में आसानी को प्राथमिकता देने के कारण इसकी default settings अपेक्षाकृत ढीली होती हैं
• यह दस्तावेज़ systemd service units और podman quadlet पर लागू किए जा सकने वाले कई security hardening options का परिचय देता है, ताकि compromise की संभावना घटे और compromise होने पर नुकसान का दायरा सीमित किया जा सके
• यह सभी services पर एक साथ लागू करने की guide नहीं है; हर service की प्रकृति और आवश्यक functionality के अनुसार अलग-अलग testing, log verification और tuning की ज़रूरत है
• infrastructure security की ज़िम्मेदारी पूरी तरह operator की है, और यह दस्तावेज़ केवल एक reference tool है

systemd सुरक्षा विश्लेषण

• systemd-analyze security कमांड से पूरे service security status की जाँच की जा सकती है या किसी specific service (जैसे sshd.service) की detailed settings का analysis किया जा सकता है
  • output में check status, feature name, description और Exposure score शामिल होते हैं; Exposure जितना अधिक होगा, जोखिम उतना बड़ा होगा
• security options को [Service] section (systemd) या [Container] section (podman quadlet) में अतिरिक्त रूप से सेट किया जा सकता है
• systemctl edit ServiceName.service के जरिए override file बनाना recommended है, और failure होने पर आवश्यक permissions की जाँच कर उन्हें adjust करना चाहिए

service security options

• systemd कई तरह के security option keywords प्रदान करता है, जिन्हें man systemd.exec 5, man capabilities 7 आदि में देखा जा सकता है
• प्रमुख security-related options
  • ProtectSystem → filesystem को read-only तक सीमित करने वाला option
  • ProtectHome → /home, /root, /run/user access block करने वाला option
  • PrivateDevices → physical devices तक access block करके केवल /dev/null जैसे virtual devices की अनुमति देने वाला option
  • ProtectKernelTunables, ProtectKernelModules, ProtectKernelLogs → kernel resources तक access block करने वाले options
  • NoNewPrivileges → setuid/setgid आदि के जरिए नए privileges हासिल करने से रोकने वाला option
  • MemoryDenyWriteExecute → writable और executable memory के simultaneous उपयोग को block करने वाला option; कुछ JIT languages में समस्या हो सकती है
  • SystemCallFilter → allowed system calls को सीमित करने वाला option; violation होने पर process terminate हो सकता है या EPERM लौटाया जा सकता है

प्रत्येक option का विवरण

• ProtectSystem: strict सेट करने पर पूरे filesystem को read-only mount करता है; /dev, /proc, /sys के लिए अलग protection options चाहिए
• ReadWritePaths: केवल कुछ paths को फिर से writable बनाने के लिए सेट किया जाता है
• ProtectHome: /home, /root, /run/user access block करता है
• PrivateDevices: physical devices तक access disable करता है और केवल /dev/null जैसे pseudo devices की अनुमति देता है
• ProtectKernelTunables: /proc, /sys को read-only बनाता है
• ProtectControlGroups: cgroup के लिए केवल read-only access की अनुमति देता है
• ProtectKernelModules: kernel modules को explicit रूप से load करने पर रोक लगाता है
• ProtectKernelLogs: kernel log buffer तक access सीमित करता है
• ProtectProc: invisible सेट करने पर दूसरे users के processes को /proc/ में छिपा देता है
• ProcSubset: विशेष PID-संबंधित items के अलावा /proc की अन्य सामग्री को block करता है
• NoNewPrivileges: setuid, setgid, filesystem capability के जरिए नए privilege escalation को block करता है
• ProtectClock: system/hardware clock में write को block करता है
• SystemCallArchitectures: native सेट करने पर केवल native syscalls जैसे x86-64 की अनुमति देता है
• RestrictNamespaces: container-specific namespaces को सीमित करता है
• RestrictSUIDSGID: file setuid, setgid bits सेट करने पर रोक लगाता है
• LockPersonality: execution domain बदलने से रोकता है (आमतौर पर केवल legacy applications में ज़रूरी)
• RestrictRealtime: real-time scheduling को सीमित करता है (सिर्फ कुछ विशेष-purpose services के लिए ज़रूरी)
• RestrictAddressFamilies: allowed socket address families को सीमित करता है (जैसे AF_INET, AF_INET6, AF_UNIX आदि)
• MemoryDenyWriteExecute: writable+executable memory regions के नए निर्माण को block करता है (JIT इस्तेमाल करने वाली services सावधानी बरतें)
• ProtectHostname: sethostname, setdomainname syscalls के उपयोग पर रोक लगाता है
• SystemCallFilter: service-दर-service syscall allow/block सेटिंग देता है, जिससे fine-grained filtering संभव है
  • groups, individual syscalls, allow/block modes आदि को adjust किया जा सकता है
  • violation होने पर terminate करने की बजाय EPERM जैसे error code लौटाने की setting भी supported है
  • पूरी सूची systemd-analyze syscall-filter या man systemd.exec(5) में देखी जा सकती है
  • ~ prefix से पूरी list को negate किया जा सकता है (उदाहरण: CapabilityBoundingSet=~CAP_SETUID आदि)

SystemCallFilter प्रतिबंधों को समायोजित करने की प्रक्रिया

• auditd का उपयोग करके service failure के समय कौन-सा syscall block हुआ, यह logs में देखा जा सकता है
  • sudo ausearch -i -m SECCOMP -ts recent चलाने के बाद syscall value की जाँच करें
  • संबंधित syscall या group को SystemCallFilter में जोड़कर क्रमशः समस्या हल की जा सकती है

hardening लागू करने की प्राथमिकता और संचालन संबंधी सुझाव

• सभी services पर सब कुछ लागू करना ज़रूरी नहीं है
• threat model और risk management सबसे महत्वपूर्ण हैं, खासकर externally exposed services (httpd, nginx, ssh आदि) पर इसे ज़रूर विचार करना चाहिए
• custom commands, timer units (cron के पुराने विकल्प) आदि पर भी इसे पहले से लागू करना प्रभावी हो सकता है
• जितनी कम जटिल service होगी, उतनी अधिक संभावना है कि उसमें fine tuning आसानी से की जा सके

चेकलिस्ट: recommended security option combination (प्रारंभिक लागू करने की प्राथमिकता)

• ProtectSystem=strict
• PrivateTmp=yes
• ProtectHome=yes या ProtectHome=tmpfs
• ProtectClock=yes, ProtectKernelLogs=yes, ProtectKernelModules=yes
• RestrictSUIDGUID=yes
• UMask=0077
• LockPersonality=yes
• RestrictRealtime=yes
• MemoryDenyWriteExecute=yes
• DynamicUser=yes या User को root के अलावा किसी specific user पर सेट करना

• ऊपर दिए गए items आम तौर पर ऐसे combinations हैं जिन्हें services पर लगभग बिना असर के इस्तेमाल किया जा सकता है
• अतिरिक्त रूप से syscall filtering (SystemCallFilter) लागू करनी हो तो detailed testing ज़रूरी है

Traefik उदाहरण configuration

• यह container-based Traefik service को systemd quadlet से चलाने और उस पर कई security options लागू करने का एक उदाहरण है
  • ProtectSystem=full, ProtectHome=yes, SystemCallFilter=@system-service @mount @privileged आदि लागू किए गए हैं
  • CapabilityBoundingSet=~CAP_SETUID CAP_SETPCAP के जरिए कुछ specific capabilities हटाई गई हैं
  • RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK आदि के जरिए network access restrictions लागू की गई हैं

निष्कर्ष

• systemd security hardening options Unix-परिवार के system administrators के toolbox में रखने लायक व्यावहारिक साधन हैं
• इन्हें perfect security solution नहीं, बल्कि risk कम करने वाले tool के रूप में उपयोग करना चाहिए, और हर service पर बिना सोचे-समझे security settings लागू करने की ज़रूरत नहीं है
• खासकर self-hosting environments के administrators के लिए यह security level बेहतर बनाने में बहुत मददगार हो सकता है
• "पूर्णता से अधिक व्यावहारिकता" को प्राथमिकता देते हुए, अपने काम और environment के अनुरूप सीमित रूप में भी इसे लागू करने की सिफारिश की जाती है