Ubuntu szerver általános biztonsági beállításai (Fossa)

Ez a fejezet egy Ubuntu Fossa szervergép nyilvános elérésűvé tételéhez minimálisan szükséges beállításokkal foglalkozik. Feltételezzük, hogy a szerver saját csomagszűrő tűzfallal már rendelkezik.

TODO: SELinux, PaX, grsecurity

Általános szigorítások, beállítások

Az alábbi beállítások jó része a Securing Debian Manual illetve a közismert Zákány-dolgozat alapján készült.

Kernel paraméterek

Célszerű lehet a syn flood elleni védelem beállítása, esetleges kernel pánik esetén az automatikus reboot kérése, illetve hasznos lehet az alapértelmezésben 5 napos established connection tracking time lecsökkentése 0,5 napra (paranoid beállítás esetén 10 percre).

Mindezeket egy, az alapértelmezett kernel paramétereket felülbíráló állományban lehet előírni:

-rw-r--r-- root root /etc/sysctl.d/local.conf

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
net.ipv4.tcp_syncookies=1

###################################################################
# Extra settings

# Reboot after 1 minute on kernel panic
kernel.panic=60

# reduce TCP conntrack time
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=43200
# paranoid restriction
# net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=600

A beállított paraméterek az alábbi paranccsal (vagy a számítógép újraindításával) érvényesíthetőek:

deb-systemd-invoke restart procps.service

A sudo és az umask beállításai

Az Ubuntu alapértelmezett umask-ja 002 (vagyis az újonnan létrehozott file-ok 664-es [rwxrw-r--] jogokkal jönnek létre), ami nézetem szerint nagyon engedékeny (640-et [rw-r--r--] szeretnénk). A root számára szeretnénk meghagyni a 644-es [rw-r--r--] alapértelmezett jogokat (akár sudo-val, akár su-val tettünk szert a root jogosultságra).

Az umask system-wide beállításához

• egyrészt a /etc/login.defs-ben módosítsuk az UMASK értékét:

-rw-r--r-- root root /etc/login.defs

[...]
UMASK 027
[...]

• másrészt a PAM beállítások között módosítsuk a pam_umask meghívását a /etc/pam.d/common-session állomány vége felé:

-rw-r--r-- root root /etc/pam.d/common-session

[...]

#session optional                       pam_umask.so
session optional                        pam_umask.so debug umask=027

• Ez a beállítás valamennyi (ezután bejelentkező, shell, system, stb.) felhasználóra érvényes lesz (a root-ra is - korábban kivétel volt), ezért speciálisan a root login shelljénél hagyjuk meg a megszokott 022-t:

-rw-r----- root root /root/.profile

[...]
umask 022
[...]

Így ha a virtuális root konzolt a su - paranccsal indítjuk vagy valódi konzolon root-ként jelentkezünk be (de csak ekkor!) az umask értéke 022 lesz.

• A sudo módosításához a visudo paranccsal szerkesszük meg a /etc/sudoers állományt, adjuk hozzá ezt a két paramétert:

[...]
Defaults        umask_override
Defaults        umask=0022
[...]

A beállítások a következő újraindításkor lépnek életbe.

Figyelem: ezt ne toljuk el! - root-ként a 027-es umask pl. azt eredményezheti, hogy szerencsétlen esetben egy apt install után a /var-ra nem lesz semmilyen other's jog. Ezért most, egy reboot után, sysadmin felhasználóként végezzük el az alábbi tesztet:

touch user-test
sudo touch sudo-test
sudo -i
touch /home/$SUDO_USER/root-test
exit
ls -l *-test

Az elvárt eredmény:

-rw-r--r-- 1 root     root     [...] root-test
-rw-r--r-- 1 root     root     [...] sudo-test
-rw-r----- 1 sysadmin sysadmin [...] user-test

Sikeres teszt esetén takarítsuk el a teszt állományokat:

sudo rm *-test

Ügyeljünk arra, hogy ha valamiért a későbbiekben a su-t használnánk, azt mindig su - formában tegyük!

File jogosultságok szigorítása

Az alábbi script lefuttatásával megszüntetjük a worldwide olvasható home könyvtárakat, másolatot készítünk a master boot record-ról, és megszigorítjuk néhány fontos könyvtár és file elérhetőségét. Célszerű ezt a scriptet futtatási jog nélkül (pl. chmod 600) a /root/install/security.sh állományba tenni, és indirekt lefuttatni:

mkdir /root/install/
touch /root/install/security.sh
chmod 600 /root/install/security.sh
mcedit /root/install/security.sh
[...]
/bin/bash /root/install/security.sh

#!/bin/sh
# Checklist to set up some security settings.
# From Linux Security Quick Reference Guide - http://www.LinuxSecurity.com
# https://github.com/shadowbq/Cheat-Sheets/blob/master/posix/Linux%20Security%20Quick%20Reference%20Guide.pdf

BOOTDEV=/dev/sda        # Modify, if you boot from another device

chmod -R o-rwx /root    # Hide root's home dir
chmod -R o-rwx /home/*  # Hide user's home dirs

# Save MBR to file - keep a backup on floppy disk or CD!
dd if=$BOOTDEV of=/root/mbr.`hostname`.`date +%Y%m%d` bs=512 count=1

# Permissions for critical system files
chmod 751 /var/log              # Logfile directory
chmod 750 /etc/syslog-ng        # Syslog (ng) daemon config files
chmod 600 /etc/crontab          # System-wide crontab
chmod 640 /etc/logrotate.conf   # Controls rotating of system log files
chmod 750 /etc/logrotate.d      # Controls rotating of system log files
chmod 660 /var/log/wtmp         # Who is logged in now. Use who to view
chmod 660 /var/log/lastlog      # Who has logged in before. Use last to view
chmod 600 /etc/ftpusers         # List of users that cannot(!) FTP
chmod 600 /etc/securetty        # TTY interfaces that allow root logins
chmod 700 /etc/security         # System access security policy files
chmod 750 /etc/init.d           # Program start-up files
chmod 600 /etc/inetd.conf       # Internet Superserver config file
chmod 400 /etc/cron.allow       # List of users permitted to use cron
chmod 400 /etc/cron.deny        # List of users denied access to cron
chmod 750 /etc/ssh              # Secure shell config files
chmod 600 /etc/sysctl.conf      # Contains kernel tunable options
chmod 700 /etc/sysctl.d         # Contains kernel tunable options (includes)

Megjegyzés: Nem biztos, hogy minden, a scriptben hivatkozott file létezik, ez indokolja az esetleges hibaüzeneteket.

Megjegyzés: Erre a scriptre ráférne egy frissítés! - TODO!

Partíciók csatolásának szigorítása

A partíciókat úgy csatoljuk fel, hogy csak a / (esetleg még a /srv vagy /srv/chroot) partíció legyen írható és futtatható egyszerre. Célszerű a telepítő által létrehozott /etc/fstab file-t két példányban lemásolni:

cp /etc/fstab /etc/fstab.secure
cp /etc/fstab /etc/fstab.unsecure

és az alábbi táblázat szerint kitölteni (a táblázat forrása a Zákány-dolgozatban található):

partíció	fstab.secure	fstab.unsecure
root	acl,defaults,errors=remount-ro	acl,defaults,errors=remount-ro
srv/chroot	acl,defaults	acl,defaults
boot	ro,nosuid,noexec,nodev,acl,defaults	acl,defaults
tmp	nosuid,noexec,nodev,acl,defaults	acl,defaults
usr	ro,nodev,acl,defaults	acl,defaults
var	nosuid,noexec,nodev,user_xattr,acl,defaults	user_xattr,acl,defaults
var/www	nosuid,noexec,nodev,user_xattr,acl,defaults	user_xattr,acl,defaults

Megjegyzés: a táblázat szerinti beállításokkal engedélyezzük a Posix ACL-ek és a /var jellegű partíciókon a kiterjesztett fájlattribútumok használatát is.

Megjegyzés: SSD meghajtó esetén célszerű a discard opcióval engedélyezni a TRIM használatát minden partíción (a swap partíción is!).

Ezt követően, a mindenkori fstab felülírása után, egy partícióra vonatkozóan a biztonságos és az engedékeny konfiguráció között a

mount -o remount /XXX

paranccsal válthatunk.

Ahhoz, hogy biztonságos konfigurációban is lehessen csomagot telepíteni, illetve rendszert frissíteni, hozzunk létre egy bejegyzést az apt.conf.d könyvtárban (ügyeljünk arra, hogy a shell scripttől eltérően a megjegyzés jele a //):

mcedit /etc/apt/apt.conf.d/10security

-rw-r--r-- root root /etc/apt/apt.conf.d/10security

// Lehetove teszi az apt hasznalatat szigoruan csatolt particiok eseten.
// garancsi.attila@mimoza.hu 2005-04-07

DPkg::Pre-Invoke {
        "/bin/mount -o remount,rw /boot";
        "/bin/mount -o remount,exec,suid /tmp";
        "/bin/mount -o remount,rw /usr";
        "/bin/mount -o remount,exec /var";
};

DPkg::Post-Invoke {
        "/bin/mount -o remount /boot";
        "/bin/mount -o remount /tmp";
        "/bin/mount -o remount /usr";
        "/bin/mount -o remount /var";
};

Ezután az apt használatához már nem kell remountolni (de a szimpla dpkg-hoz - pl. kernel frissítés - vagy tarball-ból telepítéshez igen!)

Felesleges szolgáltatások leállítása

Az Ubutu Fossa-ban a systemd system and service manager az alapértelmezett eszköz a szolgáltatások kezelésére, emiatt - a korábbi Debian/Ubuntu kiadásokkal ellentétben - a /etc/rc${runlevel}.d/ illetve /etc/init.d/ alatti állományok és linkek szerkesztése, illetve a sysv-rc-conf használata elavult. Így a

systemctl list-unit-files --type=service
systemctl enable  SERVICE
systemctl disable SERVICE

parancsok szolgálnak a telepített szolgáltatások listázására, illetve egy-egy szolgáltatás permanens engedélyezésére vagy letiltására (bővebben ld. pl. itt vagy itt). Igyekezzünk tehát a fentieket kizárólag a systemctl használatával megoldani.

Publikus TCP/IP szolgáltatások feltérképezése

A nyitott portokról és az azokon figyelő szolgáltatásokról az alábbi parancsok adnak közelítő tájékoztatást:

netstat -tanulp | egrep '(LISTEN)|(ESTAB)' | less
lsof -i | grep 'LISTEN' | less

A listázott szolgáltatásokról egyenként kell eldönteni, hogy van-e velük teendő. A netstat szerint, a leírt alaptelepítés után az alábbi, potenciálisan távolról is elérhető szolgáltatások futnak:

Szolgáltatás	Port	Leírás	Teendő
exim4	TCP:25	SMTP szerver (levélküldés és -fogadás).	Szükséges. Kihelyezés után a szervernek tudnia kell levelet fogadni, így ellenőrzendő, hogy ezt a forgalmat a tűzfalon beengedjük-e.
systemd- resolved	TCP:53 UDP:53	cache-only DNS szerver helyi szolgáltatásoknak	Szükséges. Mivel csak helyi szolgáltatást nyújt, a tűzfalon át nem kell hozzá kapcsolódást engedni.
sshd	TCP:22 (vagy ahova konfiguráltuk)	Biztonságos távoli shell.	Szükséges, ellenőrizni kell, hogy a tűzfalon beengedjük-e.

Megjegyzés: a fenti lista változhat, a netstat eredményét minden esetben egyedileg kell kiértékelni!

Egyéb eszközök, scriptek

A Tiger telepítése

Elavultságára tekintettel a Tiger telepítése opcionális!

Hagyományosan minden rendszergazda ír egy halom ravasz, cron-ból futtatott scriptet a biztonsági problémák felderítésére, monitorozására. Egy ilyen gyűjtemény a TAMU Security Tools: Tiger, amelyet Javier Fernández-Sanguino Pena, a Debian Security Audit Team egyik tagja (és a Securing Debian Manual szerzője) portolt Debianra. Egyetlen hátulütője, hogy ősrégi; 2008-as verzió szerepel a csomagban (sajnos újabb nem létezik).

Érdemes a Tigert a rootkit-ek keresésére szakosodott chkrootkit csomaggal együtt telepíteni:

apt install --no-install-recommends chkrootkit tiger  # mert a Tripwire most nem kell

A Debian tiger csomagja recommends függőségként hozná magával a Tripwire IDS csomagot, amit egyelőre nem használunk (TODO!), valamint a John the Ripper jelszótörőt, amire (nem lévén interaktív felhasználóink) nincs szükségünk, ezért ezeket a telepítésből kihagyjuk.

A Tiger moduláris felépítésű, a futtatandó modulok a /etc/tigerrc állományban vannak felsorolva. Az alapértelmezések megfelelnek, azonban a kifelé szolgáltatást nyújtó processzek listáját, a kifelé szolgáltatást nyújtó processzek felhasználóinak listáját és kötelezően futtatandó processzek listáját karban kell tartani. Emellett érdemes érvényes e-mail címként beállítani a Tiger levelek feladóját is. Alaptelepítés esetén az alábbiak tűnnek jó beállításnak:

-rw-r--r-- root root /etc/tiger/tigerrc
[...]
Tiger_Mail_FROM="root@`/bin/hostname --fqdn`"
[...]
Tiger_Listening_ValidUsers='Debian-exim|root'
[...]
Tiger_Listening_ValidProcs='dhclient|exim4|inetd|ntpd|ntpdate|snmpd|sshd'
[...]
Tiger_Running_Procs='/usr/sbin/acpid /usr/sbin/atd /usr/sbin/cron /usr/sbin/exim4 /usr/sbin/ntpd /usr/sbin/sshd /usr/sbin/snmpd /usr/sbin/syslog-ng'

A Tiger modulok futtatását nem közvetlenül a crontab ütemezi, hanem van egy indirekció: a /etc/cron.d-ben elhelyezett bejegyzés minden egész órában végrehajtja a /etc/tiger/cronrc-ben előírt vizsgálatokat (gyakrabbra ütemezni nem lehet). Ezt az állományt szabadon át lehet szerkeszteni, én a következőket állítottam be (nagyjából ezek az alapértelmezések - részletesen ld. a commentekben):

• 4 óránként netstat, futó processzek ellenőrzése;
• 8 óránként behatolás nyomainak kutatása;
• naponta egyszer system check (sokmindent ellenőriz);
• naponta egyszer account-ok ellenőrzése;
• naponta egyszer rendszerfile-ok tulajdonosainak és engedélyeinek ellenőrzése.

A többi ellenőrzés ritkábban fut le.

mv /etc/tiger/cronrc /etc/tiger/cronrc.bak
mcedit /etc/tiger/cronrc

-rw-r--r-- root root /etc/tiger/cronrc

# Tiger's cronrc - hourly scan schedule
# Parsed by tigercron called hourly from cron.d
#
# H D DOW       whitespace-separated Tiger's script list (no line wrap!)

# Checking listening processes and "must-be" running processes.
0,4,6,10,14,18,20 * *           check_listeningprocs check_runprocs

# Checking for known intrusion signs, rootkits, logfiles persistence and rights,
# /root directory ownership and rights, root user's common access.
0,8,16 * *      check_known check_rootkit check_logfiles check_rootdir check_root

# Checks performed once a day

# Checking single user-mode password, boot loader file permissions, vulnerabilities
# in inittab configuration, correct umask settings for init scripts, logins not used
# on the system, network configuration. Verifying system specific password checks.
# Checking OS release, then installed packages vs Debian Security Advisories.
# Checking md5sums of installed files and installed files against packages.
1 * *           check_system

# Checking accounts from /etc/passwd, /etc/hosts.equiv and .rhosts files, .netrc files,
# group files, entries from /etc/passwd and the format of passwd and group files.
2 * *           check_accounts check_rhosts check_netrc check_group check_passwd check_passwdformat

# Checking system file permissions.
5 * *           check_perms

# Checks performed once a week

# Checking inetd entries from /etc/inetd.conf, NFS exports, aliases from /etc/aliases,
# PATH components, crontabs and cron entries, anonymous FTP capabilities,  printer configuration
# files, services with tcp wrappers. Analysing inetd entries from /etc/inetd.conf
3 * Mon         check_inetd check_exports check_aliases check_path check_crontabs check_anonftp check_printcap check_tcpd

# Checks performed once a month

# Checking filesystem (TODO).
2 1 *           find_files

# Checking services from /etc/services, correct umask settings, ftpusers(?),
# embedded pathnames(?), .exrc files.
1 2 *           check_services check_umask check_ftpusers check_embedded check_exrc

# Checking device permissions.
2 3 *           check_devices

Telepítés után érdemes lefuttatni egy komplett ellenőrzést:

tiger

az eredmény a /var/log/tiger alatt található (nem kell rotálni, a Tiger megteszi). A jelzett problémákat érdemes kijavítani. Ezután a Tiger cron-ból fut, és ha új eltérést talál, levelet küld.

A fail2ban telepítése

A fail2ban egy framework, amely hálózati szolgáltatások naplóinak figyelésére, és a szolgáltatással visszaélés (abuse, pl. SSH brute force vagy dictionary attack) jeleit mutató távoli kliensek ideiglenes kitiltására szolgál a csomagszűrő tűzfal (netfilter) átmeneti átkonfigurálásával.

apt-get install fail2ban # Függőségként hozza magával a python-t

Alapértelmezésben a fail2ban közvetlenül az iptables paranccsal módosítja a netfilter táblázatait. Célszerű ezt úgy módosítani, hogy tevékenysége a csomagszűrésért egyébként felelős Shorewall-on keresztül történjen (erre a csomagból telepített fail2ban fel van készítve). Ehhez készítsünk egy overlay konfigurációs állományt:

-rw-r--r-- root root /etc/fail2ban/jail.local

# Integrated with Shorewall.
# http://rsabalburo.blogspot.hu/2014/07/fail2ban-with-shorewall.html

[DEFAULT]
banaction = shorewall

valamint definiáljuk felül a maintainer által biztosított akciódefiníciós állományt úgy, hogy ban esetén a Shorewall ne reject, hanem logdrop szűrést használjon:

-rw-r--r-- root root /etc/fail2ban/action.d/shorewall.local

# Action override to Shorewall integration.
# http://rsabalburo.blogspot.hu/2014/07/fail2ban-with-shorewall.html

[Init]
#blocktype = reject
blocktype = logdrop

A beállítást a fail2ban újraindításával érvényesítsük:

systemctl restart fail2ban; tail -f /var/log/fail2ban.log  # Jail 'sshd' started

Telepítés után a fail2ban csak az SSH-t védi (ami nekünk egyelőre meg is felel). Ha van megbízható (trusted) IP címünk vagy tartományunk, amellyel szemben az SSH védelmet szeretnénk mellőzni (célszerűen megegyezhet a /etc/shorewall/hosts trs zónájával), készítsünk egy overlay állományt ennek megadására:

touch /etc/fail2ban/jail.d/sshd.conf; chmod 600 /etc/fail2ban/jail.d/sshd.conf
mcedit /etc/fail2ban/jail.d/sshd.conf

-rw-------  root root /etc/fail2ban/jail.d/sshd.conf

[sshd]
enabled = true
ignoreip = IP.IP.IP.IP IP.IP.IP.IP/MASK

A beállítást a fail2ban újraindításával érvényesítsük:

systemctl restart fail2ban; tail -f /var/log/fail2ban.log  # Jail 'sshd' started

A későbbiekben a védendő, egyéb szolgáltatások helyi beállításait is az ssh.conf-hoz hasonlóan létrehozandó, /etc/fail2ban/jail.d/*.conf beállító állományokban adhatjuk meg.

Opcionális gyors tesztként egy, a telepítés alatt álló szervert TCP-n keresztül elérő gépről (ne a saját munkaállomásunkról!) próbáljunk SSH-n sikertelenül bejelentkezni, és figyeljük a /var/log/fail2ban.log állományban az IP kitiltását, illetve 10 perc utáni újraengedélyezését. Ha megadtunk megbízható IP-t vagy tartományt, ellenőrizhetjük, hogy az innen indított sikertelen lekérésekre a kitiltás nem történik meg.

A fail2ban által beírt szabályokat a Shorewall a dynamic iptables láncba veszi fel:

shorewall show dynamic  # csak akkor tartalmaz szabályt, ha van aktív ban

[...]
 Chain dynamic (2 references)
  pkts bytes target     prot opt in     out     source               destination         
     0     0 logdrop    all  --  *      *       IP.IP.IP.IP          0.0.0.0/0