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

 (roguesecurity.dev)
5 पॉइंट द्वारा GN⁺ 2025-08-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 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 के अनुरूप सीमित रूप में भी इसे लागू करने की सिफारिश की जाती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-20
Hacker News राय

  • मुझे यह दिलचस्प लगा कि automated systemd service hardening को strace profiling के ज़रिए लागू किया जा सकता है
    https://github.com/desbma/shh

    • मुझे एक अच्छा तरीका मिला: उदाहरण में ProtectSystem= का इस्तेमाल नहीं किया गया, लेकिन
      TemporaryFileSystem=/:ro, BindReadOnly=/usr/bin/binary /lib /lib64 /usr/lib usr/lib64 जैसा सेट करने पर
      आप सिर्फ़ मनचाही binary और जिन paths को पढ़ना है उन्हें ही शामिल कर सकते हैं
      ProtectSystem= फिलहाल इस व्यवहार के साथ compatible नहीं है
      ज़्यादा जानकारी के लिए यहाँ देखें

    • मुझे लगता है कि यह तरीका उन services के लिए समस्या बन सकता है जिन्हें error होने पर email भेजने जैसे अतिरिक्त actions की ज़रूरत होती है

  • कल आए systemd hardening वाले लेख की तुलना में यह काफ़ी ज़्यादा व्यावहारिक है और इसमें तुरंत लागू किए जा सकने वाले अच्छे tips हैं
    मैंने कल वाले लेख की comments में ज़्यादा वास्तविक examples देने की कोशिश की थी, लेकिन आज का लेख practical बातों को बहुत अच्छी तरह समेटता है और दिखाता है कि systemd के साथ isolation और security को तेज़ी और आसानी से कैसे मज़बूत किया जा सकता है
    मुझे यह शानदार लेख लगा
    संदर्भ के लिए कल वाला लेख भी छोड़ रहा हूँ
    https://us.jlcarveth.dev/post/hardening-systemd.md
    https://news.ycombinator.com/item?id=44928504

    • अच्छा होगा अगर site का certificate issue ठीक कर दिया जाए
      कुछ browsers में certificate error की वजह से access ही नहीं हो पाता

  • शेयर करने के लिए धन्यवाद
    systemd-analyze को --user flag के साथ इस्तेमाल करने पर systemd user units की security जाँची जा सकती है (systemd-analyze --user security)
    containers को Podman पर migrate करते समय मैंने systemd का ज़्यादा इस्तेमाल शुरू किया है, और यह tool systemd unit/container services की security बेहतर करने में बहुत मदद करेगा

  • पुराने init scripts सब अपनी-अपनी तरह के थे, इसलिए इस तरह का consistent hardening संभव नहीं था

    • बेशक, पुराने init scripts के साथ भी इस तरह का hardening किया जा सकता है, लेकिन systemd kernel की अच्छी features को एक standard और consistent तरीके से आसानी से इस्तेमाल करने देता है
      मैंने Linux में काफ़ी देर से शुरुआत की, इसलिए systemd के बिना system की कल्पना करना मुश्किल है, और systemd के बिना systems संभालना बहुत असुविधाजनक था
      हाल ही में मुझे unshare tool मिला, जिससे /nix को पूरे का पूरा RW में remount करने जैसे experiments दूसरे processes को प्रभावित किए बिना किए जा सके
      systemd की usability थोड़ी अनगढ़ है, लेकिन ईमानदारी से कहूँ तो मेरे लिए इसका विकल्प सिर्फ़ Windows ही लगता है

  • मैं सोच रहा हूँ कि Linux distros इन security switches को default रूप से ज़्यादा क्यों enable नहीं करते
    क्या conservative hardening के भी नुकसान हैं?
    बहुत से users के लिए settings बहुत ज़्यादा और जटिल हो सकती हैं

    • अगर settings को बहुत aggressively बदल दिया जाए, तो अनजाने में मौजूदा config टूट सकती है
      उदाहरण के लिए, अगर आपने NetworkManager को harden किया, तो आपको अलग-अलग जाँच करनी होगी कि IPv4 और IPv6 दोनों connect हो रहे हैं या नहीं, dns=systemd-resolved और dns=default modes सही काम कर रहे हैं या नहीं, ModemManager और cellular integration, openvpn या cisco anyconnect plugins, NetworkManager-dispatcher hooks वगैरह सब सही हैं या नहीं
      यह भी सवाल है कि कितने distro maintainers को इतना भरोसा होगा कि वे अपने managed packages के switches को किस हद तक बदल सकते हैं बिना users के 0.01% से ज़्यादा environments तोड़े
      अगर distros इन flags को manage करें, तो हर upstream release पर compatibility issues साथ आएँगे; और अगर upstream इन्हें सेट करे, तो backward compatibility की वजह से उन्हें और भी सावधानी से इस्तेमाल करना पड़ेगा

    • यह सवाल कुछ हद तक वैसा है जैसे, “distros default रूप से सख़्त MAC (SELinux आदि) क्यों नहीं इस्तेमाल करते?”
      sshd जैसी चीज़ों पर भी ज़्यादा restrictions होना अच्छा होगा, लेकिन

      1. लागू करने की शुरुआती development cost
      2. अलग-अलग user environments में आने वाली bug reports को संभालने की cost
      3. distro/upstream बदलावों के साथ लगातार maintenance cost
        इन वजहों से major distros के लिए यह भारी पड़ता है
        SELinux और AppArmor के मामले में भी maintainers को अक्सर investment के मुकाबले फायदा कम लगता है

    • एक बड़ा कारण यह भी है कि core system services के सामान्य व्यवहार को हर parameter के लिए अलग-अलग integration tests से जाँचने की क्षमता या resources नहीं होते
      संबंधित चर्चा
      https://news.ycombinator.com/item?id=29995566
      systemd-analyze security के results अलग-अलग distros में अलग होते हैं
      desbma/shh strace से इकट्ठा की गई जानकारी के आधार पर SyscallFilter जैसी unit-level rules अपने-आप generate करता है, जो SELinux के audit2allow जैसा है
      लेकिन production environment में strace install करना विवादास्पद हो सकता है
      https://github.com/desbma/shh

    • मुझे भी पूरी तरह नहीं पता, लेकिन कुछ settings नई जोड़ी गई हैं, इसलिए बहुत से users शायद उनसे परिचित नहीं हों
      हर कोई systemd expert नहीं होता, और settings enable करने पर पुराने systemd versions में सही न चलने का जोखिम भी रहता है
      SELinux, AppArmor जैसी कई features हैं, लेकिन बहुत से distros, developers और users को वे इतनी ज़रूरी नहीं लगतीं कि उन्हें automatic रूप से लागू किया जाए

  • hardening के लिए options इतने ज़्यादा हैं कि मुझे लगता है अलग-अलग सामान्य services के hardening examples का कोई repository होना चाहिए
    users अक्सर shared hardening scripts का इस्तेमाल करते हैं, लेकिन तब पता चलता है कि exceptions से बचने के लिए उम्मीद से ज़्यादा permissions देनी पड़ती हैं

    • nixpkgs जैसे, जहाँ upstream support कमज़ोर हो, ऐसे distros में packaging करते समय
      mainstream distros packages को कैसे package और harden करते हैं, यह देखना सबसे उपयोगी होता है
      ऐसे hardening तरीक़े आम तौर पर काफ़ी tested होते हैं, इसलिए अगर postgresql जैसी चीज़ों के hardening examples चाहिए हों, तो Debian, Ubuntu, RHEL packages से शुरुआत करना अच्छा रहेगा

  • systemd की बेहतरीन security features में से एक credentials management है
    इसकी मदद से applications को credentials environment variables या file system में store करने की तुलना में ज़्यादा सुरक्षित तरीके से दिए जा सकते हैं
    Vault वगैरह न होने वाले environments, जैसे personal projects में, मैं हमेशा यही तरीका पसंद करता हूँ
    मैंने इस feature के साथ काम करने के लिए एक Go package भी खुद बनाया
    systemd में credentials
    credential-go package

    • यह कुछ वैसा लगता है जैसे nodejs या npm में 2-line code के लिए भी package बना दिया जाता है
      असल में यह बस

      dir, err := os.Getenv("CREDENTIALS_DIRECTORY")
cred, err := os.ReadFile(filepath.Join(dir, "name"))

      left-pad से भी ज़्यादा जटिल नहीं है
      जहाँ तक मुझे पता है, Go community में dependencies कम रखना और बेकार abstractions (जैसे function calls) से बचना एक गुण माना जाता था
      इस तरह के साधारण काम तो लोग आम तौर पर मौके पर खुद ही लिख लेते थे

    • मैं जानना चाहता हूँ कि credentials देने का यह तरीका fork किए गए child processes तक credentials inherit होने से कैसे रोकता है

  • यह सच में बहुत उपयोगी लेख है
    systemd के हर option की list, और “man देखो और शुभकामनाएँ” जैसी सलाह भी मुझे अच्छी लगी
    systemd वाकई शानदार है और मैं इसे अपने servers पर सक्रिय रूप से deploy करना चाहता हूँ

  • एक छोटी सी tip: title में systemd की सही spelling systemd ही है
    SystemD, system D, system d नहीं, बल्कि systemd सही है
    वजह यह है कि इसका मतलब system daemon है, इसलिए Unix/Linux परंपरा के मुताबिक नाम का अंत छोटे d से किया गया है

    • दिलचस्प बात है
      मैं आम तौर पर इसे systemD लिखते हुए देखता रहा हूँ, इसलिए सोचता हूँ कि यह इतना व्यापक कैसे हो गया

  • systemd में syscall issues debug करने वाली tip सच में बहुत उपयोगी है