Tartalom
- oldal: Rendszer frissítése és az alapvető kiegészítők telepítése, beállítása
- oldal: Let's Encrypt, FTP, DNS kiszolgáló, webstatisztikák, Jailkit és Fail2Ban telepítése
- 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.
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
A 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
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
A 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]
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:
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.
- Tökéletes szerver: Debian 8 (Jessie) V1.0
- Tökéletes szerver: Debian 9 (stretch) V1.0
- Tökéletes szerver: Debian 11 (Bullseye) v1.0
- Hogyan építhetjük meg és élesíthetjük ISPConfig3 szerverünket, valamint hogyan biztosíthatjuk a Let's Encrypt SSL-el kezelőpanelünket, főbb szolgáltatásainkat és weboldalainkat
- Debian 10 (Buster) LAMP szerver v1.0 telepítése
- Debian 11 (Bullseye) LAMP szerver v1.0 telepítése
- Let's Encrypt ingyenes SSL telepítése ISPConfig3-as szerverkörnyezetre
- Fail2Ban (manual és súgó oldal)
- Hogyan engedélyezzük a Fail2Ban program szűrőit az ISPConfig-os szerverkörnyezetben
- Hogyan oldjuk fel blokkolt IP címünket, ha kitiltottuk magunkat szerverünk valamelyik szolgáltatásából
- SSH védelem erősítése további Fail2Ban szűrőmintával a Debian 8 (Jessie) rendszeren
- Hogyan tartsuk távol szerverünk weboldalaitól a nem kívánatos robotokat
- The Perfect Server - Debian 10 (Buster) with Apache, BIND, Dovecot, PureFTPD and ISPConfig 3.1
- Hogyan állíthatunk be egyedi PHP verziókat ISPConfig rendszerű szerverünkön
- Hogyan telepíthetjük fel a PHP 8-at Debian vagy Ubuntu rendszerű szerverünkre
- Tökéletes szerver letöltése: Debian 10 (Buster) v1.1
- Hogyan állítsuk be ISPConfig szerverünkön az alapértelmezett weboldalt, hogy ne az Apache2 Debian Default oldala kerüljön betöltésre a szerver IP-címének vagy teljes hosztnevének elérésekor
- Hogyan frissítsük Debian 10 (Buster) alapú tökéletes szerverünket Debian 11 (Bullseye) rendszerre
Lapozó
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
- 1271 megtekintés