Tökéletes szerver: Debian 10 (Buster) V1.0 (2. oldal)

botond küldte be 2020. 01. 02., cs – 17:17 időpontban

Tartalom

  1. oldal: Rendszer frissítése és az alapvető kiegészítők telepítése, beállítása
  2. oldal: Let's Encrypt, FTP, DNS kiszolgáló, webstatisztikák, Jailkit és Fail2Ban telepítése
  3. oldal: RoundCube webmail kliens és ISPConfig3 kezelőpanel telepítése

 

A 2. oldal tartalma

 

Folytatás

A leírás első oldalán elkezdtük a szerver telepítését a levelezőrendszer, MariaDB és Apache beállításával, valamint feltelepítettünk pár fontos kiegészítőt, ezen az oldalon folytatjuk a szerver építését, kezdve a Let's Encrypt ingyenes SSL telepítésével.

 

 

Let's Encrypt telepítése

A Let's Encrypt segítségével ingyenes SSL tanúsítványokkal láthatjuk el a szerveren lévő weboldalakat, aminek köszönhetően a biztonságos HTTPS kapcsolaton keresztül érhetjük el őket.

Frissítés 2021-02-25:
Az ISPConfig már az acme.sh scriptet használja Let's Encrypt kliensként a régebben használt Certbot helyett, amit az alábbi paranccsal telepíthetünk. Forrás.
curl https://get.acme.sh | sh -s

Ezzel további dolgunk nincsen, a Let's Encrypt integrálódik az ISPConfig kezelőpanelbe, amit aztán az teljesen automatikusan fog kezelni.

 

FTP kiszolgáló telepítése és beállítása

FTP kiszolgálónak a PureFTPd-t fogjuk használni. Telepítéséhez futtassuk a következő parancsot:

apt-get -y install pure-ftpd-common pure-ftpd-mysql

Hozzunk létre egy dhparam fájlt a PureFTPd számára: 

openssl dhparam -out /etc/ssl/private/pure-ftpd-dhparams.pem 2048

Körülbelül 0,5-1 percen át megy a generálás (gép teljesítményétől függően), közben pontokat és plusz jeleket ír ki, ne állítsuk meg. Ha lefutott, nyissuk meg a /etc/default/pure-ftpd-common fájlt szerkesztésre:

nano /etc/default/pure-ftpd-common

És gondoskodjunk róla, hogy a STANDALONE_OR_INETD és a VIRTUALCHROOT beállítások az alábbi értékeket kapják:

[...]
STANDALONE_OR_INETD=standalone
[...]
VIRTUALCHROOT=true
[...]

Majd mentsük le.

Alapból az FTP egy nem titkosított csatorna, a rajta átküldött adatok sima szövegként vándorolnak a felek között. Ezért titkosítani kell a TLS/SSL protokollal, hogy a fájlok fel/letöltése kódolt formában történjen a szerver és az FTP kliens között.

Ennek a beállításához adjuk ki a következő parancsot:

echo 1 > /etc/pure-ftpd/conf/TLS

Ezután hozzunk létre egy könyvtárat az utána elkészítendő tanúsítványunknak:

mkdir -p /etc/ssl/private/

És hozzuk létre a saját (self-signed) tanúsítványunkat:

openssl req \
    -x509 -nodes -days 7300 \
    -newkey rsa:2048 \
    -keyout /etc/ssl/private/pure-ftpd.pem \
    -out /etc/ssl/private/pure-ftpd.pem

A a tanúsítvány létrehozásához szükség van néhány adatra, ezeket bekéri tőlünk az openssl program.

Tehát a teljes kimenet, és benne zöld színnel a beadandó adatok:

pem -out /etc/ssl/private/pure-ftpd.pem
Generating a RSA private key
...+++++.....................................++...................................................+++++
....................+++.....++...
writing new private key to '/etc/ssl/private/pure-ftpd.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:HU
State or Province Name (full name) [Some-State]:Magyarország
Locality Name (eg, city) []:Budapest
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linuxportal
Organizational Unit Name (eg, section) []:IT Department
Common Name (e.g. server FQDN or YOUR name) []:debian10.linuxportal.vm
Email Address []:email címem

Itt akár üresen is hagyhatjuk a mezőket, nincs jelentőségük. Ezután állítsuk be a generált pem fájlunk jogosultságát a chmod paranccsal, hogy más felhasználók ne férhessenek hozzá a szerveren:

chmod 600 /etc/ssl/private/pure-ftpd.pem

Ezután indítsuk újra a PureFTPd-t:

service pure-ftpd-mysql restart

 

 

Quota telepítése és beállítása

A Quota segítségével szabályozhatjuk a tárhely kvótákat, így a weboldalak nem tudják túllépni a beállított tárhely korlátaikat.

A kvótarendszer az alábbi külön szabályozható területeken működik:

  • Webtárhely kvóta
  • Adatbázis tárhely kvóta
  • Email tárhely kvóta

Telepítéséhez futtassuk az alábbi parancsot:

apt-get -y install quota quotatool

A tárhely korlátok szabályozását a fájlrendszerben tudjuk érvénybe léptetni, ehhez nyissuk meg a /etc/fstab fájlt:

nano /etc/fstab

És illesszük bele pontosan a következő részt:

,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0

az alábbi módon, hogy utána így nézzen ki a /etc/fstab fájlunk:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=1937031d-39a3-4c74-8420-6ad213f7c104 / ext4 errors=remount-ro,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0 0  1
# swap was on /dev/sda5 during installation
UUID=1020a50b-c32f-4443-8fbc-f98e4620f506 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Ez az fstab fájl egy egypartíciós alaprendszer telepítésből származik, ahol minden a root partíción van. Amennyiben a /var könyvtárstruktúra külön partícióról van becsatolva, abban az esetben annak a csatolási sorába kell beilleszteni ezt a részt, tehát a lényeg, hogy ahol a webtárhelyek vannak (/var/www/... struktúra), ott kell érvényesíteni a kvótarendszert.

Ezután az  engedélyezéséhez újra kell csatolni az érintett tárolóeszközt, ahova beillesztettük a fenti részt. Ennek a példának megfelelően tehát:

mount -o remount /

Ha máshova került becsatolásra a webgyökér struktúra, akkor természetesen azt a csatolási pontot használjuk.

Ellenőrizzük a kvóta rendszert még a bekapcsolás előtt:

quotacheck -avugm

Normál esetben a kimenet ilyesmi:

quotacheck: Scanning /dev/sda1 [/] done
quotacheck: Cannot stat old user quota file //quota.user: Nincs ilyen fájl vagy könyvtár. Usage will not be subtracted.
quotacheck: Cannot stat old group quota file //quota.group: Nincs ilyen fájl vagy könyvtár. Usage will not be subtracted.
quotacheck: Cannot stat old user quota file //quota.user: Nincs ilyen fájl vagy könyvtár. Usage will not be subtracted.
quotacheck: Cannot stat old group quota file //quota.group: Nincs ilyen fájl vagy könyvtár. Usage will not be subtracted.
quotacheck: Checked 6052 directories and 58069 files
quotacheck: Old file not found.
quotacheck: Old file not found.

Elsőre hibának tűnhet, de még nincs bekapcsolva a rendszer. Kapcsoljuk be:

quotaon -avug
/dev/sda1 [/]: group quotas turned on
/dev/sda1 [/]: user quotas turned on

Innentől majd az ISPConfig intézi a továbbiakat...

 

BIND DNS szerver telepítése

DNS szerver lehetőséget biztosít, hogy a domain neveket ne csak egy "A" rekorddal irányíthassuk a szerveren lévő tárhelyre, hanem névszerver átirányítással a teljes DNS zóna rekordjainak kezelését helyben végezhessük. Ennek köszönhetően az ISPConfig felületén tudjuk majd kezelni ezeket a rekordokat, és nem utolsó sorban a teljes levelezést is a szerveren bonyolíthatjuk le. Valamint alapfeltétele a Let's Encrypt működésének is, hogy a zóna kezelés is a szerveren történjen.

A BIND DNS szervert az alábbi paranccsal telepíthetjük:

apt-get -y install bind9 dnsutils haveged
A haveged csomag segítségével magasabb entropy értéket érhetünk el a szerveren, ami kriptográfia szempontjából fontos. Érdekességképpen erről részletesebben a korábbi, Debian 9 (Stretch) tökéletes szerver telepítő útmutatójában írtam.

 

 

Webstatisztikák telepítése

A Webalizer and AWStats webstatisztikák az Apache által felhalmozott naplófájlok elemzéséből készít kimutatásokat a webhelyeken történt látogatásokról. Ellentétben weboldal forráskódjába illeszthető mérőkódokkal – amik többnyire csak JavaScript-et is futtató látogatásokat képesek mérni –, ezek a statisztikák a szerver oldali naplófájlokból ki tudják gyűjteni például a különböző robot látogatásokat, valamint az egyes HTTP erőforrások lekéréseit is, mint például a weboldalon lévő képek, JS, CSS és egyéb letölthető fájlok letöltéseit is. Telepítésükhöz futtassuk a következő parancsot:

apt-get -y install \
    webalizer awstats geoip-database \
    libclass-dbi-mysql-perl libtimedate-perl

Ezután nyissuk meg a /etc/cron.d/awstats fájlt:

nano /etc/cron.d/awstats

És kommentezzük ki a két sort, amit a telepítő létrehozott:

MAILTO=root

# */10 * * * * www-data [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh

# Generate static reports:
# 10 03 * * * www-data [ -x /usr/share/awstats/tools/buildstatic.sh ] && /usr/share/awstats/tools/buildstatic.sh

Mentsük le.

Az elkészült szerveren már az ISPConfig fogja kezelni ezeknek is a háttérben végzendő műveleteit, ezért itt nincs külön szükség rájuk.

 

Jailkit telepítése

A chroot-olt felhasználók teljesen elkülönítve dolgozhatnak a szerveren, anélkül, hogy hozzáférhetnének egymás dolgaihoz. Ez akkor hasznos, például ha rajtunk kívül másnak is adunk tárhelyet a szerverünkön. A Jailkit programmal pedig a chroot-olt shell felhasználók számára tudunk megfelelő munkakörnyezetet (könyvtárstruktúrát) biztosítani, így egy (majdnem) teljes  Linux rendszert használhatnak.

Ennek az ISPConfigban lesz jelentősége, amikor létrehozunk egy Shell felhasználót. Ilyenkor ki tudjuk majd választani, hogy szeretnénk-e chroot-olni a frissen létrehozott felhasználót.

A korábbi Debian 9 (Stretch) tökéletes szerver készítésekor forráskódból kellett lefordítanunk a Jailkit programot, mert nem szerepelt a Debian 9 csomagtárában. Ugyan a Debian 10 (Buster) alap csomagtárában sincs benne, viszont a Debian 10 backports-ban igen. Tehát eldönthetjük, hogy a korábbi módszerrel telepítjük a programot a forráskódjából, vagy a Debian 10 backports tárolójából. Én az utóbbit javaslom, mert ennek meg lesz az az előnye, hogy frissülni fog a csomagtáron keresztül. Így évek múlva is naprakész marad a Jailkit csomagunk – ellentétben a forráskódból lefordított változattal, ami végig ugyanaz a verzió marad, mint amit egyszer lefordítottunk. Biztonság szempontjából ez igen fontos tényező.

Itt tehát most a backports-ból történő telepítéssel fogjuk folytatni, de ha valaki ragaszkodik a korábbi módszerhez, ugyanúgy megteheti a fentebbi linken leírtaknak megfelelően, csak ügyelni kell rá, hogy ekkor is keressük ki a legfrissebb verziót, és azzal dolgozzunk.

Debian 10 backports tároló beállítása

A backports tárolót az APT csomagkezelő forrásfájl-jához kell hozzáadni. Ehhez nyissuk meg a /etc/apt/sources.list fájlt:

nano /etc/apt/sources.list

Majd adjuk hozzá a következő sort:

deb https://deb.debian.org/debian buster-backports main contrib non-free

Mentsük le, majd frissítsük a csomagtár adatbázist:

apt-get update

A jailkit csomag telepítése

Most, hogy már beállítottuk a Debian 10 backports tárolóját, telepítsük a jailkit csomagot az alábbi paranccsal:

apt-get install jailkit

Ezzel meg is vagyunk, a Jailkit-et az ISPConfig fogja kezelni.

 

 

Fail2ban és UFW tűzfal telepítése

Fail2Ban programmal és az UFW tűzfallal hatékony védelmet biztosíthatunk szerverünknek. Telepítésükhöz futtassuk a következő parancsot:

apt-get -y install fail2ban ufw

Alapvető Fail2Ban jail-ok beállítása

A Fail2Ban megfelelő működéséhez be kell állítanunk az ún. jail-okat, amik figyelik a különböző szolgáltatások által generált naplófájlokban előforduló blokkolandó tevékenységeket. A Fail2Ban részletesebb működésére most nem térünk ki, erről bővebben olvashatunk ennek az oldalnak az alján lévő kapcsolódó tartalom résznél.

Hozzuk létre a /etc/fail2ban/jail.local fájlt:

nano /etc/fail2ban/jail.local

És tegyük bele az alábbi jail-okat:

[pure-ftpd]
enabled = true
port = ftp
filter = pure-ftpd
logpath = /var/log/syslog
findtime = 3600
maxretry = 2

[dovecot]
enabled = true
filter = dovecot
logpath = /var/log/mail.log
findtime = 3600
maxretry = 2

[postfix-sasl-normal]
enabled = true
port = smtp
filter = postfix[mode=normal]
logpath = /var/log/mail.log
findtime = 3600
maxretry = 2

[postfix-sasl-auth]
enabled = true
port = smtp
filter = postfix[mode=auth]
logpath = /var/log/mail.log
findtime = 3600
maxretry = 2

[postfix-auth-fail]
enabled = true
port = smtp
filter = postfix-auth-fail
logpath = /var/log/mail.log
findtime = 3600
maxretry = 2

Mentsük le.

Az első 4 jail a gyári csomag része, így ezeket csak be kell kapcsolnunk. Viszont az utolsó, "postfix-auth-fail" nevű jail-t a neten találtam, és saját, több hónapos használat után melegen tudom ajánlani, sok Postfix-et ért próbálkozást fog meg. Ezt a jail-t tehát külön létre kell hoznunk:

nano /etc/fail2ban/filter.d/postfix-auth-fail.conf

Majd ebbe tegyük bele az alábbi tartalmat:

# Fail2Ban filter for Postfix SMTP auth failures
#
# see: http://www.postfix.org/announcements/postfix-3.0.0.html:
#  'a password-guessing bot is logged as "disconnect from name[addr] ehlo=1 auth=0/1 commands=1/2",
#   meaning that the client sent one EHLO command that worked, one AUTH command that failed, and
#   hung up without sending a QUIT command. This information is always logged, and can help to
#   solve puzzles without verbose logging or network sniffers.'
#
[INCLUDES]

# Read common prefixes. Get any customizations from common.local
before = common.conf

[Definition]

_daemon = postfix(-\w+)?/(?:submission/|smtps/)?smtp[ds]

#  cautious regex: strict match to messages per postfix announcement above:
#failregex = ^%(__prefix_line)sdisconnect from \S+\[<HOST>\] ehlo=1 auth=0/1 commands=1/2$

#  aggressive regex: match any auth failure (unless from whitelisted ip),
#  picks up a *lot* more bots than the 'cautious' regex, can ban bots
#  that send HELO as well as EHLO and bots that send QUIT.
#  Note 1: if a legit connector is trying to remember a login or password
#          and gets it wrong it gets banned - unless whitelisted
#  Note 2: this is triggered for every disconnect with failed auth. Some bots try multiple
#          passwords on a single connection - I use dovecot jail to pick these up
failregex = ^%(__prefix_line)sdisconnect from \S+\[<HOST>\] (ehlo|helo)=\d+ .*auth=0/\d

ignoreregex =

[Init]

journalmatch = _SYSTEMD_UNIT=postfix.service

# Author: Dominic Raferd [03 Jan 2017, 29 Mar 2017]
A forrás címet sajnos az első saját használat óta elkevertem, jelenleg nem találom, még a szerzője neve alapján sem, de ha újra rábukkanok, pótolni fogom. Az eredeti szűrőtartalmat tettem ide be, amit anno találtam, így ha valakinek sikerül rákeresnie a részletek segítségével a neten, talán még több hasznos szűrőt is találhat ettől a szerzőtől. Ez a szűrő nálam nagyon bevált a több hónapnyi éles használata során.

Mentsük le ezt a fájlt is, és indítsuk újra a Fail2Ban-t:

systemctl restart fail2ban

 

 

Fail2Ban és a jail-ok ellenőrzése

Ha gondoljuk, a biztonság kedvéért ráellenőrizhetünk, hogy megfelelően elindult-e a Fail2Ban, valamint a jail-ok is. Elég ha valamelyik szűrőben van egy elgépelés, és nem indul el az adott jail, vagy rosszabb esetben a Fail2Ban sem. Ráadásul ezt sunyi módon teszi, mert nem mindig ad erről hibaüzenetet. Ellenőrizzük tehát a Fail2Ban szolgáltatás és a jail-ok működését:

systemctl status fail2ban.service
cat /var/log/fail2ban.log | tail -15

A parancsok normál esetben ilyen kimenetet kell hogy adjanak:

Fail2Ban állapot ellenőrzése

Maga a szolgáltatás fut szépen, és a jail-ok is elindultak hiba nélkül.

A szerver elkészítésének végén még bővíteni fogjuk két további jail-al, de ezeket már csak az ISPConfig telepítése után fogjuk megtenni, mert az újabb szűrők által figyelt naplófájlok – és az őket tartalmazó könyvtárak is – csak az ISPConfig beüzemelése után fognak létrejönni. Addig pedig nem tudnának elindulni a jail-ok, amíg nem találják meg a beállított naplófájlokat.

 

A következő oldalon folytatjuk a RoundCube webmail kliens telepítésével.

 

Kapcsolódó tartalom, hasznos linkek:

 

Lapozó

Ez a leírás több oldalból áll: