Ασφάλεια στα άκρα: Hardening μιας υπηρεσίας με το systemd

Άρθρα και οδηγοί
, , , ,
1

Σε ένα προηγούμενο άρθρο μίλησα για το systemd-analyze security και πως μπορείς να δεις με μια μάτια πόσο ασφαλείς είναι οι υπηρεσίες που έχεις. Σήμερα θα δούμε ένα πρακτικό παράδειγμα.

Ένας απλός web server

Έφτιαξα μια πολύ απλή υπηρεσία που απλά τυπώνει ένα μήνυμα. Η γλώσσα προγραμματισμού είναι η Rust :rust: και θα βρείτε τον κώδικα στο παράρτημα. Χρησιμοποιεί socket activation αλλά μπορεί να δουλέψει σε οποιοδήποτε σύστημα init.

Θέλω δυο units για αυτή που θα πάνε (ή θα γίνουν symlink) στο /lib/systemd/system/. Αυτά είναι

# 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

και

# hello_server.socket
[Unit]
Description=Simple Rust Server socket

[Socket]
ListenStream=82

[Install]
WantedBy=sockets.target

αν ο χρήστης θέλει να κάνει αλλαγές, για παράδειγμα να το βάλει στην πόρτα 80, θα κάνει αλλαγές με αρχεία στο /etc/systemd/system. Αν θέλει να τις ακυρώσει απλά θα αφήσει τα αρχεία που έκανε. Κανένας λόγος να κρατάμε αντίγραφα, κανένας λόγος να δυσκολέψουμε την αναβάθμιση και ένας απλός τρόπος να ξέρεις τι αλλαγές έχουν γίνει. Ένας ωραίος stateless σχεδιασμός. Μου αρέσει :grin:

Όλα καλά και τίποτα δεν μπορεί να πάει στραβά. Ο κώδικας μου είναι τέλειος. Καλέ τι μου λέτε πως λέω ανοησίες. Να θα σας το αποδείξω. ΩΩΩΧ εντάξει μην βαράτε, είπα και κάτι να περάσει η ώρα :joy: :joy: :joy: :joy:

Ανάλυση ασφαλείας

Η εντολή

systemd-analyze --no-pager security hello_server

θα δώσει

→ Overall exposure level for hello_server.service: 9.6 UNSAFE 😨

1. Αλλάζοντας τον χρήστη που τρέχει την υπηρεσία

Δεν ξεκινάμε καθόλου ενθαρρυντικά, αλλά η τελευταία στήλη μας λέει που να δώσουμε βάρος. Κατ’ αρχάς θέλουμε να έχει άμεση πρόσβαση στο δίκτυο, οπότε το PrivateNetwork= το ξεχνάμε. Αλλά ας το κάνουμε να μην τρέχει σαν χρήστης root τουλάχιστον. Θα αλλάξουμε το unit και θα προσθέσουμε

[Service]
...
# Sandboxing
User=www-data
Group=www-data
#DynamicUser=yes

και οι εντολές

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] είναι ένας χρήστης που υπάρχει μόνον όσο τρέχει η υπηρεσία και θα δημιουργηθεί αυτόματα. Ένας “δυναμικός χρήστης” τρέχει σε ένα ποιο ασφαλές περιβάλλον.

  1. Τώρα αν τρέχει σαν χρήστης πως μπορεί να ανοίξει την προστατευμένη πόρτα ‘82’; Κανονικά θα έπρεπε να ξεκινάει σαν root για να μπορεί να το κάνει αυτό. Ναι αλλά η υπηρεσία είναι socket activated θυμάστε; Άρα δεν ανοίγει καμία πόρτα την παίρνει έτοιμη από το systemd :grin:
    Αλλά πειράξαμε τον κώδικα (μολύνοντας το με το libsystemd.so λολ ) για να γίνει αυτό. Αυτό δεν είναι πάντα δυνατόν. Σε αυτές τις περιπτώσεις θα προσθέσουμε ένα capability στο εκτελέσιμο
AmbientCapabilities=CAP_NET_BIND_SERVICE

Τα capabilities [link] είναι ένας τρόπος να επιτρέψουμε σε ένα εκτελέσιμο που δεν τρέχει σαν root να έχει επιπλέον δικαιώματα. Στο παραδοσιακό UNIX θα έπρεπε να είχε το suid bit και ήταν ή όλα ή τίποτα.

2. Περιορίζοντας την πρόσβαση στο σύστημα αρχείων

Μια παραδοσιακή υπηρεσία συνήθως θέλει κάποιο runtime directory όπου βάζει ένα PID αρχείο. Η απλή μας υπηρεσία δεν έχει ανάγκη κάτι τέτοιο, αλλά ας της δώσουμε το /var/run/hello_server αν στο μέλλον χρειαστεί να βάλει εκεί κάτι

[service]
RuntimeDirectory=hello_server
#PIDFile=/run/hello_server/hello_server.pid

και με αυτήν την αλλαγή έχουμε

→ Overall exposure level for hello_server.service: 6.7 MEDIUM 😐

Ας το περιορίσουμε λίγο ακόμα δίδοντας της ένα δικό της /tmp για προσωρινά αρχεία και περιορίζοντας την πρόσβαση αλλού εκτώς απο εκεί που πρέπει

PrivateTmp=yes
ProtectHome=yes

και

→ Overall exposure level for hello_server.service: 6.2 MEDIUM 😐

3. Περιορίζοντας την πρόσβαση στις υπηρεσίες του kernel

Μια πονηρή υπηρεσία μπορεί να καλέσει ένα άλλο πρόγραμμα που να έχει το suid bit και να κάνει ότι θέλει ουπς!. Η να καλέσει την κληση personality ή πονηρούλα. Αλλού αυτά!

ProtectSystem=strict
LockPersonality=true
NoNewPrivileges=true

→ Overall exposure level for hello_server.service: 5.8 MEDIUM 😐

Θα βάλουμε επιπλέον

SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

Ζήτω!! !Hip hip hooray!! Επιτέλους

→ Overall exposure level for hello_server.service: 4.4 OK 🙂

Προσθέσαμε ένα έτοιμο φίλτρο του systemd που περιορίζει την πρόσβαση σε συνήθεις υπηρεσίες συστήματος που τυπικά χρησιμοποιεί ένα service. Ένα έτοιμο φίλτρο μπορεί να είναι είτε πολύ σφικτό είτε πολύ ελεύθερο. Σε ένα μελλοντικό άρθρο θα δούμε πως μπορούμε να βρούμε τι υπηρεσίες συστήματος χρησιμοποιεί ένα πρόγραμμα και να το περιορίσουμε στα απολύτως απαραίτητα.

4. Πρόσθετοι περιορισμοί

Ας περιορίσουμε τα namespaces που χρησιμοποιεί (θέλουμε μόνο το net) καθώς και κάποια άλλα πράγματα

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 ενισχει την ασφάλεια του συστήματος

Πήραμε μια υπηρεσία και την κάναμε πολύ ποιο ασφαλή από ότι ήταν. Όλα αυτά χωρίς να προσθέσουμε ούτε μια γραμμή κώδικα!. Πλέον μπορούμε να κοιμόμαστε λίγο ποιο ήσυχοι αν κάποιος βρεις κάποιο κενό ασφαλείας σε αυτήν.

Μπορείς να τα κάνεις αυτά χωρίς το systemd; Αν έχεις πρόσβαση στον κώδικά και ξέρεις ναι, αλλά είναι πολύ ποιο δύσκολο. Για κάποια από αυτά έχω παρουσιάσει και ένα άλλο εργαλείο. Μπορείς να τα κάνεις αυτά με κάποιο άλλο init σύστημα; Πιθανά να μπορείς αν ξέρεις και συνδιάσεις πολλά διαφορετικά εργαλεία. Δεν γνωρίζω αν υπάρχει κάποια διανομή που να μην έχει systemd να είναι προσανατολισμένη σε server και που να έχει κάνει δώσει βάρος σε hardening, αλλά και να έχει τεκμηριώσει την διαδικασία. Αν υπάρχει γράψτε την στα σχόλια.

Θα εκπλαγώ πολύ όμως αν έχει ένα εργαλείο σαν το systemd-analyze security και που να σε καθοδηγεί τόσο καλά. Ο πυρήνας έχει πολλές δυνατότητες που ελάχιστοι τις χρησιμοποιούν. Κάνοντας τες εύκολα προσβάσιμες, είναι εύκολο να έχουμε ένα πολύ ποιο ασφαλές σύστημα. Οι διανομές που έχουμε είναι φτιαγμένες για γενική χρήση και δεν κάνουν χρήση όλων των δυνατοτήτων, συχνά για λόγους συμβατότητας, για λόγους τεμπελιάς ή άγνοιας ή γιατί θέλουν να υποστηρίξουν κάποιο άλλο σύστημα init. Άλλα η πικρή αλήθεια είναι πως αν μια διανομή ασφαλίσει πλήρως μια υπηρεσία θα υπάρχουν σενάρια χρήσης που δεν θα δουλεύει. Οπότε αφήνει αυτή την εργασία στους διαχειρηστές που ξέρουν για την κάθε περίπτωση καλύτερα τι θέλουν και τι όχι. Ελπίζω αυτό το να αποτελέσει ένα καλό ξεκίνημα αν έχεις κάποιο σύστημα να διαχειριστείς.

Πείτε μας στα σχόλια πως κάνατε Hardening μια άλλη υπηρεσία ή αν κάνατε αυτήν εδώ καλύτερα. Αν επεκτείνετε τις δυνατότητες του κώδικα ακόμα καλύτερα :stuck_out_tongue:. Αν το κάνετε χωρίς την χρήση του systemd ακόμα καλύτερα.

Διαβάστε:

  1. https://medium.com/@nickodell/sandboxing-nginx-with-systemd-80441923c555
  2. GitHub - alegrey91/systemd-service-hardening: Basic guide to harden systemd services
  3. Using systemd features to secure services
  4. Securing systemd services with seccomp profiles -- Prefetch Technologies
  5. 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

Ακούστε:

Παράρτημα:

1. 'Ο κώδικας της υπηρεσίας

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. Οι εξαρτήσεις

[dependencies]
actix-web = "2.0.0"
actix-rt = "1.1.1"
listenfd = "0.3.3"

3. Η αρχική αναφορά

NAME DESCRIPTION EXPOSURE
✗ PrivateNetwork= Service has access to the host’s network 0.5
✗ User=/DynamicUser= Service runs as root user 0.4
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities 0.3
✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges 0.3
✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities 0.3
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3
✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces 0.3
✗ RestrictAddressFamilies=~… Service may allocate exotic sockets 0.3
✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unrestricted 0.2
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks 0.2
✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges 0.2
✗ CapabilityBoundingSet=~CAP_RAWIO Service has raw I/O access 0.2
✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules 0.2
✗ CapabilityBoundingSet=~CAP_SYS_TIME Service processes may change the system clock 0.2
✗ DeviceAllow= Service has no device ACL 0.2
✗ IPAddressDeny= Service does not define an IP address whitelist 0.2
✓ KeyringMode= Service doesn’t share key material with other services
✗ NoNewPrivileges= Service processes may acquire new privileges 0.2
✓ NotifyAccess= Service child processes cannot alter service state
✗ PrivateDevices= Service potentially has access to hardware devices 0.2
✗ PrivateMounts= Service may install system mounts 0.2
✗ PrivateTmp= Service has access to other software’s temporary files 0.2
✗ PrivateUsers= Service has access to other users 0.2
✗ ProtectClock= Service may write to the hardware clock or system clock 0.2
✗ ProtectControlGroups= Service may modify the control group file system 0.2
✗ ProtectHome= Service has full access to home directories 0.2
✗ ProtectKernelLogs= Service may read from or write to the kernel log ring buffer 0.2
✗ ProtectKernelModules= Service may load or read kernel modules 0.2
✗ ProtectKernelTunables= Service may alter kernel tunables 0.2
✗ ProtectSystem= Service has full access to the OS file hierarchy 0.2
✗ RestrictAddressFamilies=~AF_PACKET Service may allocate packet sockets 0.2
✗ RestrictSUIDSGID= Service may create SUID/SGID files 0.2
✗ SystemCallArchitectures= Service may execute system calls with all ABIs 0.2
✗ SystemCallFilter=~@clock Service does not filter system calls 0.2
✗ SystemCallFilter=~@debug Service does not filter system calls 0.2
✗ SystemCallFilter=~@module Service does not filter system calls 0.2
✗ SystemCallFilter=~@mount Service does not filter system calls 0.2
✗ SystemCallFilter=~@raw-io Service does not filter system calls 0.2
✗ SystemCallFilter=~@reboot Service does not filter system calls 0.2
✗ SystemCallFilter=~@swap Service does not filter system calls 0.2
✗ SystemCallFilter=~@privileged Service does not filter system calls 0.2
✗ SystemCallFilter=~@resources Service does not filter system calls 0.2
✓ AmbientCapabilities= Service process does not receive ambient capabilities
✗ CapabilityBoundingSet=~CAP_AUDIT_* Service has audit subsystem access 0.1
✗ CapabilityBoundingSet=~CAP_KILL Service may send UNIX signals to arbitrary processes 0.1
✗ CapabilityBoundingSet=~CAP_MKNOD Service may create device nodes 0.1
✗ CapabilityBoundingSet=~CAP_NET_(BIND_SERVICE|BROADCAST|RAW) Service has elevated networking privileges 0.1
✗ CapabilityBoundingSet=~CAP_SYSLOG Service has access to kernel logging 0.1
✗ CapabilityBoundingSet=~CAP_SYS_(NICE|RESOURCE) Service has privileges to change resource use parameters 0.1
✗ RestrictNamespaces=~CLONE_NEWCGROUP Service may create cgroup namespaces 0.1
✗ RestrictNamespaces=~CLONE_NEWIPC Service may create IPC namespaces 0.1
✗ RestrictNamespaces=~CLONE_NEWNET Service may create network namespaces 0.1
✗ RestrictNamespaces=~CLONE_NEWNS Service may create file system namespaces 0.1
✗ RestrictNamespaces=~CLONE_NEWPID Service may create process namespaces 0.1
✗ RestrictRealtime= Service may acquire realtime scheduling 0.1
✗ SystemCallFilter=~@cpu-emulation Service does not filter system calls 0.1
✗ SystemCallFilter=~@obsolete Service does not filter system calls 0.1
✗ RestrictAddressFamilies=~AF_NETLINK Service may allocate netlink sockets 0.1
✗ RootDirectory=/RootImage= Service runs within the host’s root directory 0.1
SupplementaryGroups= Service runs as root, option does not matter
✗ CapabilityBoundingSet=~CAP_MAC_* Service may adjust SMACK MAC 0.1
✗ CapabilityBoundingSet=~CAP_SYS_BOOT Service may issue reboot() 0.1
✓ Delegate= Service does not maintain its own delegated control group subtree
✗ LockPersonality= Service may change ABI personality 0.1
✗ MemoryDenyWriteExecute= Service may create writable executable memory mappings 0.1
RemoveIPC= Service runs as root, option does not apply
✗ RestrictNamespaces=~CLONE_NEWUTS Service may create hostname namespaces 0.1
✗ UMask= Files created by service are world-readable by default 0.1
✗ CapabilityBoundingSet=~CAP_LINUX_IMMUTABLE Service may mark files immutable 0.1
✗ CapabilityBoundingSet=~CAP_IPC_LOCK Service may lock memory into RAM 0.1
✗ CapabilityBoundingSet=~CAP_SYS_CHROOT Service may issue chroot() 0.1
✗ ProtectHostname= Service may change system host/domainname 0.1
✗ CapabilityBoundingSet=~CAP_BLOCK_SUSPEND Service may establish wake locks 0.1
✗ CapabilityBoundingSet=~CAP_LEASE Service may create file leases 0.1
✗ CapabilityBoundingSet=~CAP_SYS_PACCT Service may use acct() 0.1
✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() 0.1
✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system 0.1
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets 0.1

Ένα ποιο πολύπλοκο παράδειγμα αν θέλεις να παίξεις με golang

2 «Μου αρέσει»