# Ασφάλεια στα άκρα: Hardening μιας υπηρεσίας με το systemd **URL:** \ **Category:** Άρθρα και οδηγοί\ **Tags:** hardening, sysadmin, systemd, seccomp, planet\ **Created:** [Ιούλιος 24, 2020, 11:01πμ UTC](https://linux-user.gr/t/asfaleia-sta-akra-hardening-mias-yphresias-me-to-systemd/2303 "2020-07-24T11:01:08Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![Asfodelus](https://linux-user.gr/user_avatar/linux-user.gr/asfodelus/32/11_2.png) [@Asfodelus](https://linux-user.gr/u/Asfodelus)\ **Post date:** [Ιούλιος 24, 2020, 11:01πμ UTC](https://linux-user.gr/t/asfaleia-sta-akra-hardening-mias-yphresias-me-to-systemd/2303/1 "2020-07-24T11:01:08Z")
Σε ένα προηγούμενο άρθρο μίλησα για το `systemd-analyze security` και πως μπορείς να δεις με μια μάτια πόσο ασφαλείς είναι οι υπηρεσίες που έχεις. Σήμερα θα δούμε ένα πρακτικό παράδειγμα. ## Ένας απλός web server Έφτιαξα μια πολύ απλή υπηρεσία που απλά τυπώνει ένα μήνυμα. Η γλώσσα προγραμματισμού είναι η Rust :rust: και θα βρείτε τον κώδικα στο παράρτημα. Χρησιμοποιεί `socket activation` αλλά μπορεί να δουλέψει σε οποιοδήποτε σύστημα `init`. Θέλω δυο `units` για αυτή που θα πάνε (ή θα γίνουν symlink) στο `/lib/systemd/system/`. Αυτά είναι ```ini # hello_service.service [Unit] Description=Simple Rust Server Wants=hello_server.socket After=hello_server.socket [Service] ExecStart=/home/talos/Projects/Rust/hello_server/target/release/hello_server ``` και ```auto # hello_server.socket [Unit] Description=Simple Rust Server socket [Socket] ListenStream=82 [Install] WantedBy=sockets.target ``` αν ο χρήστης θέλει να κάνει αλλαγές, για παράδειγμα να το βάλει στην πόρτα `80`, θα κάνει αλλαγές με αρχεία στο `/etc/systemd/system`. Αν θέλει να τις ακυρώσει απλά θα αφήσει τα αρχεία που έκανε. Κανένας λόγος να κρατάμε αντίγραφα, κανένας λόγος να δυσκολέψουμε την αναβάθμιση και ένας απλός τρόπος να ξέρεις τι αλλαγές έχουν γίνει. Ένας ωραίος `stateless` σχεδιασμός. Μου αρέσει 😁 Όλα καλά και τίποτα δεν μπορεί να πάει στραβά. Ο κώδικας μου είναι τέλειος. Καλέ τι μου λέτε πως λέω ανοησίες. Να θα σας το αποδείξω. ΩΩΩΧ εντάξει μην βαράτε, είπα και κάτι να περάσει η ώρα 😂 😂 😂 😂 ## Ανάλυση ασφαλείας Η εντολή ```plaintext systemd-analyze --no-pager security hello_server ``` θα δώσει ``` → **Overall exposure level for** **hello\_server.service** : **9.6 UNSAFE** 😨 ``` ## 1. Αλλάζοντας τον χρήστη που τρέχει την υπηρεσία Δεν ξεκινάμε καθόλου ενθαρρυντικά, αλλά η τελευταία στήλη μας λέει που να δώσουμε βάρος. Κατ’ αρχάς θέλουμε να έχει άμεση πρόσβαση στο δίκτυο, οπότε το `PrivateNetwork=` το ξεχνάμε. Αλλά ας το κάνουμε να μην τρέχει σαν χρήστης `root` τουλάχιστον. Θα αλλάξουμε το `unit` και θα προσθέσουμε ```auto [Service] ... # Sandboxing User=www-data Group=www-data #DynamicUser=yes ``` και οι εντολές ```plaintext sudo systemctl daemon-reload systemd-analyze --no-pager security hello_server ``` θα δώσουν ``` → **Overall exposure level for** **hello\_server.service** : **8.2 EXPOSED** 🙁 ``` Είναι μια καλή αρχή. **Παρατηρήσεις** : 1. Το συγκεκριμένο `service` δεν κάνει πολλά, δεν διαβάζει αρχεία, ούτε γράφει αρχεία που παραμένουν μετά που θα σταματήσει. Σε μια τέτοια περίπτωση θα άξιζε τον κόπο να φτιάξεις έναν χρήστη ειδικά για το `service` όπως τον `www-data`. Αλλά εδώ καλύτερα είναι ένας **δυναμικός χρήστης**. Αλλά θα πάρουμε τον δύσκολο δρόμο και θα φτιάξουμε τις επιπλέον ασφάλειες με το χέρι, κάτι ποιο χρήσιμο όπως όταν θέλεις να κάνεις `hardening` κάτι σαν το `nginx`. > Ένας **δυναμικός χρήστης** [[link](http://0pointer.net/blog/dynamic-users-with-systemd.html)] είναι ένας χρήστης που υπάρχει μόνον όσο τρέχει η υπηρεσία και θα δημιουργηθεί αυτόματα. Ένας “δυναμικός χρήστης” τρέχει σε ένα ποιο ασφαλές περιβάλλον. 1. Τώρα αν τρέχει σαν χρήστης πως μπορεί να ανοίξει την προστατευμένη πόρτα ‘82’; Κανονικά θα έπρεπε να ξεκινάει σαν `root` για να μπορεί να το κάνει αυτό. Ναι αλλά η υπηρεσία είναι `socket activated` θυμάστε; Άρα δεν ανοίγει καμία πόρτα την παίρνει έτοιμη από το `systemd` 😁 Αλλά πειράξαμε τον κώδικα (μολύνοντας το με το `libsystemd.so` λολ ) για να γίνει αυτό. Αυτό δεν είναι πάντα δυνατόν. Σε αυτές τις περιπτώσεις θα προσθέσουμε ένα `capability` στο εκτελέσιμο ```auto AmbientCapabilities=CAP_NET_BIND_SERVICE ``` > Τα `capabilities` [[link](https://man7.org/linux/man-pages/man7/capabilities.7.html)] είναι ένας τρόπος να επιτρέψουμε σε ένα εκτελέσιμο που δεν τρέχει σαν `root` να έχει επιπλέον δικαιώματα. Στο παραδοσιακό `UNIX` θα έπρεπε να είχε το `suid bit` και ήταν ή όλα ή τίποτα. ## 2. Περιορίζοντας την πρόσβαση στο σύστημα αρχείων Μια παραδοσιακή υπηρεσία συνήθως θέλει κάποιο `runtime directory` όπου βάζει ένα `PID` αρχείο. Η απλή μας υπηρεσία δεν έχει ανάγκη κάτι τέτοιο, αλλά ας της δώσουμε το `/var/run/hello_server` αν στο μέλλον χρειαστεί να βάλει εκεί κάτι ```auto [service] RuntimeDirectory=hello_server #PIDFile=/run/hello_server/hello_server.pid ``` και με αυτήν την αλλαγή έχουμε ``` → **Overall exposure level for** **hello\_server.service** : 6.7 MEDIUM 😐 ``` Ας το περιορίσουμε λίγο ακόμα δίδοντας της ένα δικό της `/tmp` για προσωρινά αρχεία και περιορίζοντας την πρόσβαση αλλού εκτώς απο εκεί που πρέπει ```auto PrivateTmp=yes ProtectHome=yes ``` και ``` → **Overall exposure level for** **hello\_server.service** : 6.2 MEDIUM 😐 ``` ## 3. Περιορίζοντας την πρόσβαση στις υπηρεσίες του kernel Μια πονηρή υπηρεσία μπορεί να καλέσει ένα άλλο πρόγραμμα που να έχει το `suid bit` και να κάνει ότι θέλει ουπς!. Η να καλέσει την κληση [personality](https://man7.org/linux/man-pages/man2/personality.2.html) ή πονηρούλα. Αλλού αυτά! ```auto ProtectSystem=strict LockPersonality=true NoNewPrivileges=true ``` ``` → **Overall exposure level for** **hello\_server.service** : 5.8 MEDIUM 😐 ``` Θα βάλουμε επιπλέον ```auto SystemCallFilter=@system-service SystemCallErrorNumber=EPERM ``` Ζήτω!! !Hip hip hooray!! Επιτέλους ``` → **Overall exposure level for** **hello\_server.service** : **4.4 OK** 🙂 ``` > Προσθέσαμε ένα έτοιμο φίλτρο του `systemd` που [περιορίζει](https://linux-user.gr/t/periorismos-toy-ti-mporei-na-kanei-mia-efarmogh-chwris-kwdika/2243) την πρόσβαση σε συνήθεις υπηρεσίες συστήματος που τυπικά χρησιμοποιεί ένα service. Ένα έτοιμο φίλτρο μπορεί να είναι είτε πολύ σφικτό είτε πολύ ελεύθερο. Σε ένα μελλοντικό άρθρο θα δούμε πως μπορούμε να βρούμε τι υπηρεσίες συστήματος χρησιμοποιεί ένα πρόγραμμα και να το περιορίσουμε στα απολύτως απαραίτητα. ## 4. Πρόσθετοι περιορισμοί Ας περιορίσουμε τα `namespaces` που χρησιμοποιεί (θέλουμε μόνο το `net`) καθώς και κάποια άλλα πράγματα ```auto RestrictNamespaces=~net ProtectHostname=yes RestrictAddressFamilies=yes ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectClock=yes PrivateDevices=yes RestrictSUIDSGID=true ``` Με αυτές τις αλλαγές ``` → **Overall exposure level for** **hello\_server.service** : **2.6 OK** 🙂 ``` # Το `systemd` ενισχει την ασφάλεια του συστήματος Πήραμε μια υπηρεσία και την κάναμε πολύ ποιο ασφαλή από ότι ήταν. [color=“red”] **Όλα αυτά χωρίς να προσθέσουμε ούτε μια γραμμή κώδικα!** [/color]. Πλέον μπορούμε να κοιμόμαστε λίγο ποιο ήσυχοι αν κάποιος βρεις κάποιο κενό ασφαλείας σε αυτήν. Μπορείς να τα κάνεις αυτά χωρίς το `systemd`; Αν έχεις πρόσβαση στον κώδικά και ξέρεις ναι, αλλά είναι πολύ ποιο δύσκολο. Για κάποια από αυτά έχω παρουσιάσει και ένα άλλο [εργαλείο](https://linux-user.gr/t/periorismos-toy-ti-mporei-na-kanei-mia-efarmogh-chwris-kwdika/2243). Μπορείς να τα κάνεις αυτά με κάποιο άλλο `init` σύστημα; Πιθανά να μπορείς αν ξέρεις και συνδιάσεις πολλά διαφορετικά εργαλεία. Δεν γνωρίζω αν υπάρχει κάποια διανομή που να μην έχει `systemd` να είναι προσανατολισμένη σε `server` και που να έχει κάνει δώσει βάρος σε `hardening`, αλλά και να έχει τεκμηριώσει την διαδικασία. Αν υπάρχει γράψτε την στα σχόλια. Θα εκπλαγώ πολύ όμως αν έχει ένα εργαλείο σαν το `systemd-analyze security` και που να σε καθοδηγεί τόσο καλά. Ο πυρήνας έχει πολλές δυνατότητες που ελάχιστοι τις χρησιμοποιούν. Κάνοντας τες εύκολα προσβάσιμες, είναι εύκολο να έχουμε ένα πολύ ποιο ασφαλές σύστημα. Οι διανομές που έχουμε είναι φτιαγμένες για γενική χρήση και δεν κάνουν χρήση όλων των δυνατοτήτων, συχνά για λόγους συμβατότητας, για λόγους τεμπελιάς ή άγνοιας ή γιατί θέλουν να υποστηρίξουν κάποιο άλλο σύστημα `init`. Άλλα η πικρή αλήθεια είναι πως αν μια διανομή ασφαλίσει πλήρως μια υπηρεσία θα υπάρχουν σενάρια χρήσης που δεν θα δουλεύει. Οπότε αφήνει αυτή την εργασία στους διαχειρηστές που ξέρουν για την κάθε περίπτωση καλύτερα τι θέλουν και τι όχι. Ελπίζω αυτό το να αποτελέσει ένα καλό ξεκίνημα αν έχεις κάποιο σύστημα να διαχειριστείς. Πείτε μας στα σχόλια πως κάνατε Hardening μια άλλη υπηρεσία ή αν κάνατε αυτήν εδώ καλύτερα. Αν επεκτείνετε τις δυνατότητες του κώδικα ακόμα καλύτερα 😛. Αν το κάνετε χωρίς την χρήση του `systemd` ακόμα καλύτερα. ### Διαβάστε: 1. [https://medium.com/@nickodell/sandboxing-nginx-with-systemd-80441923c555](https://medium.com/@nickodell/sandboxing-nginx-with-systemd-80441923c555) 2. [GitHub - alegrey91/systemd-service-hardening: Basic guide to harden systemd services · GitHub](https://github.com/alegrey91/systemd-service-hardening) 3. [Using systemd features to secure services](https://www.redhat.com/sysadmin/systemd-secure-services) 4. [Securing systemd services with seccomp profiles -- Prefetch Technologies](https://prefetch.net/blog/2017/11/27/securing-systemd-services-with-seccomp-profiles/) 5. [Sandboxing in Linux with zero lines of code](https://blog.cloudflare.com/sandboxing-in-linux-with-zero-lines-of-code/) ### Δείτε: 1. [FOSDEM 2020 - Using systemd security features to build a more secure distro](https://fosdem.org/2020/schedule/event/ussftbasd/) ### Ακούστε: [![](https://img.youtube.com/vi/tBvAxSx0nAM/maxresdefault.jpg "Welcome To The Machine") ](https://www.youtube.com/watch?v=tBvAxSx0nAM) # Παράρτημα: ## 1. 'Ο κώδικας της υπηρεσίας ```rust use actix_web::{web, App, HttpRequest, HttpServer}; use listenfd::ListenFd; async fn index(_req: HttpRequest) -> &'static str { "Welcome, my son, Welcome to the machine. Where have you been? It's alright, we know where you've been" } #[actix_rt::main] async fn main() -> std::io::Result<()> { let mut server = HttpServer::new(|| { App::new().service(web::resource("/").to(index)) }); // systemfd --no-pid -s http::2020 -- cargo watch -x run let mut listenfd = ListenFd::from_env(); // Init Freedom server = match listenfd.take_tcp_listener(0)? { Some(listener) => server.listen(listener)?, None => server.bind("127.0.0.1:82")?, }; server.run().await?; Ok(()) } ``` ## 2. Οι εξαρτήσεις ```ini [dependencies] actix-web = "2.0.0" actix-rt = "1.1.1" listenfd = "0.3.3" ``` ## 3. Η αρχική αναφορά | NAME | DESCRIPTION | EXPOSURE | | --- | --- | --- | | [color=“red”]✗[/color] PrivateNetwork= | Service has access to the host’s network | 0.5 | | [color=“red”]✗[/color] User=/DynamicUser= | Service runs as root user | 0.4 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SET(UID|GID|PCAP) | Service may change UID/GID identities/capabilities | 0.3 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_ADMIN | Service has administrator privileges | 0.3 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_PTRACE | Service has ptrace() debugging abilities | 0.3 | | [color=“red”]✗[/color] RestrictAddressFamilies=~AF\_(INET|INET6) | Service may allocate Internet sockets | 0.3 | | [color=“red”]✗[/color] RestrictNamespaces=~CLONE\_NEWUSER | Service may create user namespaces | 0.3 | | [color=“red”]✗[/color] RestrictAddressFamilies=~… | Service may allocate exotic sockets | 0.3 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_(CHOWN|FSETID|SETFCAP) | Service may change file ownership/access mode/capabilities unrestricted | 0.2 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_(DAC\_\*|FOWNER|IPC\_OWNER) | Service may override UNIX file/IPC permission checks | 0.2 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_NET\_ADMIN | Service has network configuration privileges | 0.2 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_RAWIO | Service has raw I/O access | 0.2 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_MODULE | Service may load kernel modules | 0.2 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_TIME | Service processes may change the system clock | 0.2 | | [color=“red”]✗[/color] DeviceAllow= | Service has no device ACL | 0.2 | | [color=“red”]✗[/color] IPAddressDeny= | Service does not define an IP address whitelist | 0.2 | | [color=“green”]✓[/color] KeyringMode= | Service doesn’t share key material with other services | | | [color=“red”]✗[/color] NoNewPrivileges= | Service processes may acquire new privileges | 0.2 | | [color=“green”]✓[/color] NotifyAccess= | Service child processes cannot alter service state | | | [color=“red”]✗[/color] PrivateDevices= | Service potentially has access to hardware devices | 0.2 | | [color=“red”]✗[/color] PrivateMounts= | Service may install system mounts | 0.2 | | [color=“red”]✗[/color] PrivateTmp= | Service has access to other software’s temporary files | 0.2 | | [color=“red”]✗[/color] PrivateUsers= | Service has access to other users | 0.2 | | [color=“red”]✗[/color] ProtectClock= | Service may write to the hardware clock or system clock | 0.2 | | [color=“red”]✗[/color] ProtectControlGroups= | Service may modify the control group file system | 0.2 | | [color=“red”]✗[/color] ProtectHome= | Service has full access to home directories | 0.2 | | [color=“red”]✗[/color] ProtectKernelLogs= | Service may read from or write to the kernel log ring buffer | 0.2 | | [color=“red”]✗[/color] ProtectKernelModules= | Service may load or read kernel modules | 0.2 | | [color=“red”]✗[/color] ProtectKernelTunables= | Service may alter kernel tunables | 0.2 | | [color=“red”]✗[/color] ProtectSystem= | Service has full access to the OS file hierarchy | 0.2 | | [color=“red”]✗[/color] RestrictAddressFamilies=~AF\_PACKET | Service may allocate packet sockets | 0.2 | | [color=“red”]✗[/color] RestrictSUIDSGID= | Service may create SUID/SGID files | 0.2 | | [color=“red”]✗[/color] SystemCallArchitectures= | Service may execute system calls with all ABIs | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@clock | Service does not filter system calls | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@debug | Service does not filter system calls | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@module | Service does not filter system calls | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@mount | Service does not filter system calls | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@raw-io | Service does not filter system calls | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@reboot | Service does not filter system calls | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@swap | Service does not filter system calls | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@privileged | Service does not filter system calls | 0.2 | | [color=“red”]✗[/color] SystemCallFilter=~@resources | Service does not filter system calls | 0.2 | | [color=“green”]✓[/color] AmbientCapabilities= | Service process does not receive ambient capabilities | | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_AUDIT\_\* | Service has audit subsystem access | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_KILL | Service may send UNIX signals to arbitrary processes | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_MKNOD | Service may create device nodes | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_NET\_(BIND\_SERVICE|BROADCAST|RAW) | Service has elevated networking privileges | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYSLOG | Service has access to kernel logging | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_(NICE|RESOURCE) | Service has privileges to change resource use parameters | 0.1 | | [color=“red”]✗[/color] RestrictNamespaces=~CLONE\_NEWCGROUP | Service may create cgroup namespaces | 0.1 | | [color=“red”]✗[/color] RestrictNamespaces=~CLONE\_NEWIPC | Service may create IPC namespaces | 0.1 | | [color=“red”]✗[/color] RestrictNamespaces=~CLONE\_NEWNET | Service may create network namespaces | 0.1 | | [color=“red”]✗[/color] RestrictNamespaces=~CLONE\_NEWNS | Service may create file system namespaces | 0.1 | | [color=“red”]✗[/color] RestrictNamespaces=~CLONE\_NEWPID | Service may create process namespaces | 0.1 | | [color=“red”]✗[/color] RestrictRealtime= | Service may acquire realtime scheduling | 0.1 | | [color=“red”]✗[/color] SystemCallFilter=~@cpu-emulation | Service does not filter system calls | 0.1 | | [color=“red”]✗[/color] SystemCallFilter=~@obsolete | Service does not filter system calls | 0.1 | | [color=“red”]✗[/color] RestrictAddressFamilies=~AF\_NETLINK | Service may allocate netlink sockets | 0.1 | | [color=“red”]✗[/color] RootDirectory=/RootImage= | Service runs within the host’s root directory | 0.1 | | SupplementaryGroups= | Service runs as root, option does not matter | | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_MAC\_\* | Service may adjust SMACK MAC | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_BOOT | Service may issue reboot() | 0.1 | | [color=“green”]✓[/color] Delegate= | Service does not maintain its own delegated control group subtree | | | [color=“red”]✗[/color] LockPersonality= | Service may change ABI personality | 0.1 | | [color=“red”]✗[/color] MemoryDenyWriteExecute= | Service may create writable executable memory mappings | 0.1 | | RemoveIPC= | Service runs as root, option does not apply | | | [color=“red”]✗[/color] RestrictNamespaces=~CLONE\_NEWUTS | Service may create hostname namespaces | 0.1 | | [color=“red”]✗[/color] UMask= | Files created by service are world-readable by default | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_LINUX\_IMMUTABLE | Service may mark files immutable | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_IPC\_LOCK | Service may lock memory into RAM | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_CHROOT | Service may issue chroot() | 0.1 | | [color=“red”]✗[/color] ProtectHostname= | Service may change system host/domainname | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_BLOCK\_SUSPEND | Service may establish wake locks | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_LEASE | Service may create file leases | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_PACCT | Service may use acct() | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_SYS\_TTY\_CONFIG | Service may issue vhangup() | 0.1 | | [color=“red”]✗[/color] CapabilityBoundingSet=~CAP\_WAKE\_ALARM | Service may program timers that wake up the system | 0.1 | | [color=“red”]✗[/color] RestrictAddressFamilies=~AF\_UNIX | Service may allocate local sockets | 0.1 | Ένα ποιο πολύπλοκο παράδειγμα αν θέλεις να παίξεις με golang > **[Integration of a Go service with systemd: socket activation](https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation)** > > Using systemd's socket activation, you can achieve zero-downtime deployment for your Go service with a few lines of code. --- _[View the full topic](https://linux-user.gr/t/asfaleia-sta-akra-hardening-mias-yphresias-me-to-systemd/2303)._