Debian szerver általános biztonsági beállításai (Stretch)

Innen: AdminWiki
A lap korábbi változatát látod, amilyen KZoli (vitalap | szerkesztései) 2018. május 29., 21:03-kor történt szerkesztése után volt. (Új oldal, tartalma: „Ez a fejezet egy Debian Stretch 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…”)
(eltér) ← Régebbi változat | Aktuális változat (eltér) | Újabb változat→ (eltér)

Ez a fejezet egy Debian Stretch 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 reboot után lépnének érvénybe.

A su szigorítása

A root jogosultság távolról történő megszerzését az admin group tagjaira érdemes korlátozni. Ehhez először az admin és a root felhasználót explicit be kell tenni az admin group-ba (a default group tagság nem elég!):

adduser admin admin
adduser root admin

utána fel kell venni a korlátozó szabályt:

-rw-r--r-- root root /etc/pam.d/su

[...]
auth required pam_wheel.so group=admin
[...]

Így az admin group tagjain (praktikusan az admin felhasználón) kívül más nem tud su-zni, konzolról azonban közvetlenül megszerezhető a root jogosultság.

Megjegyzés: a root-ot azért érdemes felvenni az admin group-ba, mert az olyan scriptek, amelyek su-t tartalmaznak, a korlátozás után root-ként indítva sem futnak le. A konfiguráció megváltoztatása után még azelőtt teszteljünk, mielőtt root-ként kijelentkeznénk, különben marad a konzol...

Az alapértelmezett umask szigorítása

A Debian alapértelmezett umask-ja 022 (vagyis az újonnan létrehozott file-ok 644-es [rwxr--r--] jogokkal jönnek létre), ami túl engedékeny (640-et szeretnénk). 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 vegyük fel a pam_umask meghívását a /etc/pam.d/common-session állomány legvégén:
-rw-r--r-- root root /etc/pam.d/common-session

[...]
# manually defined
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 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-get install után a /var-ra nem lesz semmilyen other's jog. Ezért most, egy reboot után gondosan ellenőrizzük a su - előtti (0027) és utáni (0022) umask értéket és a továbbiakban sose hagyjuk el a - jelet ennél a parancsnál!

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

A Jessie óta már a systemd system and service manager az alapértelmezett eszköz a szolgáltatások kezelésére, emiatt - a korábbi Debian 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 -tanu | 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.
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

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-get 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           

Jogi csűrcsavar

Talán nevetségesnek tűnik, de a Bastille Linux szerzői azt ajánlják, hogy írjunk egy figyelmeztetést, amely minden Linux login esetén megjelenik. Így ha valaki helyi vagy távoli konzolos belépéssel kerül a rendszerbe, akkor találkozik ezzel a figyelmeztetéssel, és utóbb nem mondhatja azt, hogy nem tudta, hogy tilosban jár, valamint nem panaszkodhat, hogy tevékenységét megfigyeltük, és ezzel megsértettük a személyiségi jogait. Tudom, hogy ez nagyon amerikai gondolkodás, de hátha (Al Caponét is adócsalásért sikerült, ugyebár)... A fentiek érdekében:

  • Belépés előtt egy rövid, angol nyelvű figyelmeztetést adunk (egy régi hiba miatt, SSH belépéskor ékezetes szöveg itt nem használható). Ennek tartalmát konzolos belépéshez a /etc/issue, SSH belépéshez a /etc/issue.net állományban adhatjuk meg; ebben a leírásban mindkettőnél azonos szöveget használunk:
-rw-r--r-- root root /etc/issue
-rw-r--r-- root root /etc/issue.net

********************************************************************************
NOTICE TO USERS

This computer system is the property of [OWNER].
It is for authorized use only. Users (authorized or unauthorized) may not have
any expectations - explicit or implicit - of privacy.

********************************************************************************

Az sshd beállításaiban a banner szöveg megjelenítése alapértelmezetten ki van kapcsolva, ezért (a beállító állományban a vonatkozó sor kommentezésének megszüntetésével) ezt kapcsoljuk be:

-rw-r--r-- root root /etc/ssh/sshd_config

[...]
Banner /etc/issue.net
[...]

és az sshd újtaindításával érvényesítsük a beállítást:

systemctl restart sshd
  • Belépés után egy hosszabb, két nyelvű figyelmeztetést jelenítünk meg (technikailag a message of the day szolgáltatással):
-rw-r--r-- root root /etc/motd

********************************************************************************
FIGYELMEZTETÉS A FELHASZNÁLÓKNAK

Ez a számítógépes rendszer a [TULAJDONOS] tulajdonát képezi.
A rendszert csak a megfelelő felhatalmazás birtokában lehet használni.
A rendszer jogosulatlan, illetve nem megfelelő használata munkajogi, polgári
jogi és büntetőjogi felelősségre vonást vonhat maga után.

A rendszerbe való belépést, a rendszer bármilyen módon történő használatát
a tulajdonos megfigyeli, rögzíti, ellenőrzi és erről szükség esetén tájékoztatja
a munkaadót, az intézkedésre jogosult hatóságokat, kormányzati és nyomozati
szerveket, ügyészséget, bíróságot, az illetékes hatóságok hivatalnokait, továbbá
a jogosulatlan használattal érintett magánszemélyeket, társaságokat és egyéb
szervezeteket.

A rendszerbe való belépéssel a Felhasználó hozzájárul az ily módon történő
megfigyeléshez, rögzítéshez, ellenőrzéshez, az adatok – ide értve a felhasználó
által megadott személyes adatokat is – tárolásához, továbbadásához, célhoz
kötött felhasználásához. Az adatok kezelése a mindenkor hatályos adatvédelmi
jogszabályoknak megfelelően történik.

A Felhasználónak sem implicit, sem explicit elvárásai, követelései, kártérítési
igényei nem lehetnek a titoktartással és a fentiekkel összefüggésben.

A Felhasználó a belépéssel a fentieket elfogadja és magára nézve kötelezőnek
ismeri el.

********************************************************************************
NOTICE TO USERS

This computer system is the property of [OWNER].
It is for authorized use only. Unauthorized or inappropriate use of this
system may result in labor law procedures, administrative or disciplinary
action and might induce civil and criminal liability.

Access to this system is monitored, recorded, and checked by the owner of the
system who might disclose it to the employer, law enforcement authorities,
government agencies and investigative, prosecutorial, judicial, officials of
the competent authorities, as well as to private individuals, companies and
other organizations involved.

By access to this system, Users consent to such monitoring, recording, checking
and also to the storing, forwarding and utilizing data – including the Users'
personal data. Data management is performed according to the effective
regulations on the protection of personal data.

Users may not have any expectations (explicit or implicit) of privacy.

By access to this system Users indicate awareness of and consent to these
terms and conditions.

********************************************************************************
  • Gyorsteszt: a következő belépés során a név és jelszó vagy kulcs megadása előtt a rövidebb, sikeres belépés esetén a hosszabb szövegváltozat is megjelenik.


Publikus környezetbe kihelyezés

A biztonsági megerősítést követően a szerver publikus környezetbe (DMZ, production) kihelyezhető. A kihelyezésnél figyeljünk:

  • a statikus IP megadására (/etc/network/interfaces);
  • a /etc/resolv.conf-beli nameserver megadására (127.0.0.1 ha fut rajta cacheing DNS), a belső hálózati nameserver bejegyzés kommentezésére (vigyázat, ha nem védjük meg, a DHCP kliens ezt periodikusan felülírja!);
  • a domain név esetleges megváltoztatására (/etc/hosts);
  • a levelezés átkonfigurálására:
mount -o remount,exec /var # Szigorú csatolás esetén
dpkg-reconfigure exim4-config

átállítása "internetes gép" konfigurációra (minden más maradhat). Ezután ellenőrizzük, hogy a szerver milyen FQHN-vel (Fully Qualified HostName) jelentkezik be levélküldéskor:

echo "Teszt" | mail -s Teszt helocheck@cbl.abuseat.org; tail -f /var/log/exim4/mainlog

Ez egy azonnal visszapattanó levelet eredményez, amelybe a helocheck beleírja az általunk ténylegesen használt FQHN-et. Ha ez nem egyezne meg a

dig -x IP.IP.IP.IP # szerver publikus IP címe

paranccsal megtudható reverse-zel, akkor manuálisan állítsuk be a helyes (reverse) FQHN-et. Ennek Exim-barát módja az alábbi extra konfigurációs állomány használata:

-rw-r--r-- root root  /etc/exim4/conf.d/main/99_exim4-config_custom_settings
[...]
# Custom settings - nor provided by maintainer,
# nor customizable by Debian automagic

[...]
REMOTE_SMTP_HELO_DATA = "helyes.reverse.FQHN"

Érvényesítsük a beállításokat:

/usr/sbin/update-exim4.conf; systemctl reload exim4

és ismételjük meg a helocheck tesztet. Siker esetén állítsuk helyre a /var szigorú csatolását:

mount -o remount /var
  • szigorú partíció-csatolásra (/etc/fstab.secure).
  • Ha a gép előtt valamilyen hálózati forgalomszűrés történik (DMZ) azt is be kell állítani.
  • Ügyeljünk arra, hogy nyilvánosan elérhető gépeken mindig erős (lehetőleg generált) jelszavak legyenek!


Olvasnivaló