Amennyiben úgy tapasztaljuk, hogy az egyik pillanatról a másikra megszűnt a phpMyAdmin elérhetősége, pedig korábban minden rendben működött, érdemes első körben körülnézni az Apache error.log naplófájljában. (/var/log/apache2/error.log)

Ha abban az alábbihoz hasonló hibaüzenetet találunk, akkor a probléma okát az inkompatibilis alapértelmezett PHP-verzió okozza:

[Sat Jun 18 15:38:38.906793 2022] [proxy_fcgi:error] [pid 657600] [client X.X.X.X:63235] AH01071: Got error 'PHP message: PHP Warning: Unsupported declare 'strict_types' in /usr/share/php/PhpMyAdmin/MoTranslator/Loader.php on line 23\nPHP message: PHP Parse error: syntax error, unexpected '?' in /usr/share/php/PhpMyAdmin/MoTranslator/Loader.php on line 116\n'

Ennek megoldása elég egyszerű, ugyanis a phpMyAdmin rendelkezik egy saját Apache conf-fájllal, amelyet módosítva megadhatjuk, hogy melyik PHP-verzióval fusson. Ehhez mindössze módosítanunk kell az /etc/phpmyadmin/apache.conf tartalmát, és beszúrnunk a következőt:

<Directory /usr/share/phpmyadmin>
    <FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php/php7.4-fpm.sock|fcgi://localhost/"
    </FilesMatch>
</Directory>

A fenti megoldással a PHP 7.4-es verzióját adjuk meg a phpMyAdmin futtatásához (jelenleg ezzel a verzióval biztosan működnie kell, ha ez volt a hiba oka).

Természetesen a módosítások életbe léptetéséhez újra kell indítanunk az Apache2-t. (/etc/init.d/apache2 restart)

Miért éppen WordPress-webhelyet válasszak a céges oldalamhoz?

Manapság a WordPress az egyik legnépszerűbb és leginkább elterjedt tartalomkezelő rendszer (CMS), ami nem véletlen. Először is vegyük sorra az előnyeit:

• Nagyon egyszerű és szinte minden szolgáltatóval kompatibilis az üzembe helyezése
• Nem igényel semmilyen programozói vagy rendszergazdai tudást
• Könnyen kezelhető az adminisztrációs felülete
• Teljes körű felhasználókezelést és különálló szerepköröket biztosít
• Teljes mértékben le van fordítva magyar nyelvre (igaz, számos hiba csúszott a közösségi fordításba, de ettől még jól használható magyarul)
• Minden tekintetben követi az éppen aktuálisan elvárt és használt szabványokat
• Automatikusan frissíthető (a bővítményeivel együtt), így mindig naprakész (és biztonságos) verziót használhatunk
• Rengeteg sablon és bővítmény érhető el hozzá (számos közülük teljesen ingyenesen), így minden céges igény kielégíthető
• A megfelelő bővítmények birtokában ugyanolyan jól használható blogként, magazinként, céges webhelyként vagy webáruházként
• Kiemelkedően jól teljesít a keresőoptimalizálás (SEO) terén
• Egy jó sablon birtokában könnyedén igazítható a céges arculathoz
• Ráadásul teljesen ingyenes

Rendszerkövetelmények

• PHP 7.4-es vagy magasabb verzió
• MySQL 5.7-es vagy magasabb VAGY MariaDB 10.2-es vagy magasabb verzió
• HTTPS-támogatás

A céges WordPress-webhely üzembe helyezésének költségei

Ha eldöntöttük, hogy szeretnénk egy biztonságos és szabványos webhelyet magunknak, akkor már csak az alapvető körülményeket kell megteremtenünk a sikeres beüzemeléséhez.

Dönthetünk úgy, hogy saját szervert üzemeltetünk, amennyiben a webhelyen kívül más szolgáltatásokat is elérhetővé szeretnénk tenni. Ebben az esetben nagy segítségünkre lehet a virtuális szerverek (VPS) kiválasztását elősegítő útmutatónk. Magának a rendszernek a kialakításához pedig érdemes elolvasni a tökéletes Ubuntu 20.04 LTS szerver telepítésének útmutatóját.

A saját szerver fenntartásának természetesen magasabbak a költségei, de érdemes megnézni a konkrét csomagjánlatokat, hiszen már havi 5 ezer forintért lehet egy minden alapvető igényt kielégítő VPS-ünk, ráadásul az egyes paramétereket mi magunk szabhatjuk meg, amihez az ár is azonnal igazodik, így csupán azért a kapacitásért kell fizetnünk, amelyre valóban szükségünk van.

A saját rendszer kialakításához és üzembe helyezéséhez igénybe veheti szakértő segítségünket, és mi a céges igényeihez igazítva hozzuk létre a gyors és biztonságos rendszert, amelyet akár saját maga is üzemeltethet az ISPConfiggal, vagy minket is felkérhet az üzemeltetési és karbantartási feladatokra.

Vagy a webhely üzemeltetésének feladatát másra is bízhatjuk, ebben az esetben webtárhelyet kell vásárolnunk, és itt helyezhetjük üzembe a WordPress-webhelyünket.

Webtárhely vásárlása esetén éves szinten akár 10 ezer forint alatti összeggel is számolhatunk, és a ténylegesen fizetendő ár az általunk igényelt tárhely méretétől függ. Amennyiben igencsak nagy méretű a céges oldalunk (pl. sok képet és videót szeretnénk elhelyezni rajta), akkor érdemesebb saját VPS-t vennünk, de ha megelégszünk néhány GB-tal is, akkor sokkal jobban járunk a webtárhellyel.

Cégünk kifejezetten a WordPress-webhelyek minél gyorsabb és stabilabb kiszolgálására és biztonságos üzemeltetésére kialakított szervereket tart fenn, amelyekkel nem csupán a legjobb felhasználó élményt tudjuk garantálni a látogatóknak, de arról is gondoskodunk, hogy a lehető legjobb pontszámot lehessen elérni a szabványosság, a válaszidő és számos más olyan tényező esetén, amelyek nagyban befolyásolják, hogy a webhelyünket milyen pozícióban jelenítik meg az egyes keresőmotorok.

Kiegészítő tanácsadás keretében további finomhangolással segítjük a képek méretének és megjelenítésének optimalizálását, a keresőoptimalizálást (SEO), valamint az oldalak gyorsítótárazását, a webáruházak létrehozását és a fizetési megoldások integrálását.

További információ kéréséhez vegye fel velünk a kapcsolatot!

És akkor nézzünk néhány konkrét példát!

Minimális céges webhelyigény (webtárhely)

Éves szinten egy átlagos, alapszintű céges WordPress-webhely minimális igényekkel évi 6300 Ft-ért tartalmazza a következőket:

• 500 MB SSD-tárhely
• 5 db e-mail-fiók (egyenként 500 MB tárhellyel)
• 1 db adatbázis
• WordPress + Divi sablon
• FTP-elérés
• Webmail
• Webhelystatisztika
• ISPConfig-elérés (webhely, e-mailek, adatbázis és egyebek kezelésére szolgáló önkiszolgáló felület)
• HTTPS-tanúsítvány (LetsEncrypt)
• PHP 7.x és 8.x (igény szerint választható verzió)
• DNS-szolgáltatás (1 domainhez)

A megrendeléséhez vegye fel velünk a kapcsolatot!

A nettó árak tájékoztató jelleggel lettek feltüntetve, a cikk írásának pillanatában érvényes állapotot tükrözik, és bármikor megváltozhatnak.

Közepes céges webhelyigény (webtárhely)

Éves szinten egy átlagos, közepes szintű céges WordPress-webhely évi 35 000 Ft-ért tartalmazza a következőket:

• 20 GB SSD-tárhely
• 10 db e-mail-fiók (egyenként 1 GB tárhellyel)
• 10 db adatbázis
• WordPress + Divi sablon
• FTP-elérés
• Webmail
• Webhelystatisztika
• Automatikus biztonsági mentés
• ISPConfig-elérés (webhely, e-mailek, adatbázis és egyebek kezelésére szolgáló önkiszolgáló felület)
• HTTPS-tanúsítvány (LetsEncrypt)
• PHP 7.x és 8.x (igény szerint választható verzió)
• DNS-szolgáltatás (10 domainhez)
• Segítségnyújtás a webhely kezdeti üzembe helyezéséhez (legfeljebb 2 munkaóra)

A megrendeléséhez vegye fel velünk a kapcsolatot!

A nettó árak tájékoztató jelleggel lettek feltüntetve, a cikk írásának pillanatában érvényes állapotot tükrözik, és bármikor megváltozhatnak.

Komolyabb céges webhelyigény (VPS)

Éves szinten egy magasabb szintű céges WordPress-webhely évi 65 000 Ft-ért + egyszeri 25 000 Ft-os üzembehelyezési díjért tartalmazza a következőket:

• 120 GB SSD-tárhelyű saját VPS
• Korlátlan e-mail-fiók, DNS, saját levelezés
  
• A tökéletes Ubuntu 20.04 LTS szerver (és annak minden szolgáltatása)
• WordPress
• ISPConfig
• HTTPS-tanúsítvány (LetsEncrypt)
• PHP 7.x és 8.x
• Alapszintű hardening (tűzfalbeállítások, értesítés SSH-bejelentkezésekről, fail2ban, .htaccess-védelem a nyilvánosan elérhető szolgáltatásoknál, DDoS-védelem)
• Segítségnyújtás a webhely kezdeti üzembe helyezéséhez (legfeljebb 2 munkaóra)

A megrendeléséhez vegye fel velünk a kapcsolatot!

A nettó árak tájékoztató jelleggel lettek feltüntetve, a cikk írásának pillanatában érvényes állapotot tükrözik, és bármikor megváltozhatnak.

Ebben az útmutatóban az Ubuntu 20.04 LTS (Focal Fossa) verzióra frissítünk a 18.04 LTS verzióról, a do-release-upgrade szkript használatával.

MEGJEGYZÉS

A művelet elkezdése előtt mindenképpen készítsünk a szerverünkről egy teljes értékű biztonsági mentést. Ez történhet egy snapshot vagy checkpoint (Hyper-V) létrehozásával, vagy egy ISO-fájlba történő mentéssel, illetve a rendszer klónozásával.

Ha elindítjuk a frissítést a do-release-upgrade szkripttel, és nem járunk sikerrel, manuálisan kell majd helyreállítanunk a működésképtelen rendszerünket!

Manuális biztonsági mentés

Amennyiben nem tudunk a teljes rendszerről biztonsági mentést készíteni a fenti lehetőségek egyikével sem, fájlszintű mentést is létrehozhatunk, amelynek segítségével kicsit ugyan nehezebben, de újra működőképessé tehetjük a rendszert egy sikertelen frissítést követően. Ennek lépései a következők:

/* fontos adatok mentése */ 
sudo -s cd /root tar -pczf ./completesystembackup.tar.gz /etc/letsencrypt /home/USER-DIRECTORY /var/vmail /var/log /var/www /etc/cron.d /etc/apache2 /etc/bind /usr/local/ispconfig/interface/lib /usr/local/ispconfig/server/lib /etc/postfix /etc/dovecot /etc/php* 
/* adatbázisok mentése */ 
mysqldump -u root -p --all-databases > all-databases.sql 
/* konfigurációs fájlok mentése (/etc) */
tar -pczf ./backup-etc.tar.gz /etc 

Felkészülés a frissítésre

Mielőtt belekezdenénk a frissítésbe, meg kell győződnünk arról, hogy minden frissítést telepítettünk a jelenlegi rendszerre:

sudo apt update
sudo apt upgrade
sudo apt dist-upgrade

Ha bármilyen frissítést telepíteni kellett, indítsuk újra a rendszert:

sudo reboot

A frissítés elindítása előtt győződjünk meg arról, hogy a műveletet a screen használatával futtatjuk, ebben az esetben ugyanis akkor is folytathatjuk majd a műveletet, ha véletlenül megszakadna az SSH-kapcsolatunk:

sudo apt install screen
screen

Ha valamilyen okból megszakadna a kapcsolat, akkor a következő paranccsal tudjuk folytatni a megkezdett munkamenetet:

screen -x

MEGJEGYZÉS

A frissítési folyamat során a szkript meg fog nyitni egy további SSH-kapcsolati portot is, a 1022-es porton. Ezt a portot a tűzfalon is érdemes megnyitni a frissítési művelet kezdetén, a szkript által megjelenített iptables-parancs futtatásával.

A frissítés elindítása (do-release-upgrade)

Amennyiben minden előkészülettel megvagyunk, adjuk ki a frissítési parancsot:

sudo do-release-upgrade

MEGJEGYZÉS

Amennyiben az első két kérdésnél a telepítés folytatását választjuk, onnantól nincs visszaút. Ha valami balul sül el, a biztonsági mentésből tudjuk csak helyreállítani a rendszerünket.

A felkínált lehetőségek mindegyikénél elfogadhatjuk az alapértelmezett értéket, az apt-listchangesből a legegyszerűbben a q billentyű lenyomásával tudunk kilépni, az LXD frissítését érintő kérdés után pedig egy ideig nem történik semmi, de nincs más dolgunk, mint várni türelemmel.

Előfordulhat, hogy a phpmyadmin és a roundcube adatbázisának újrakonfigurálására felszólító üzenetet kapunk a frissítés során, ám mivel egyes szolgáltatások a háttérben már nem futnak, a változtatásokat nem tudja a frissítési varázsló végrehajtani. Pánikra semmi ok, ezt a lépést nyugodtan kihagyhatjuk mindenféle változtatás nélkül.

Ugyanígy ügyeljünk arra is, hogy bármilyen konfigurációs fájlt szeretne a folyamat felülírni, mindig az alapértelmezett N választ adjuk, hiszen az összes érintett szolgáltatást vagy saját magunk konfiguráltuk, vagy az ISPConfig kezeli.

Ha sikerrel jártunk, akkor a gép újraindítását követően már a 20.04-es Ubuntu rendszerbe tudunk bejelentkezni. Ha valami mégsem stimmelt volna, akkor viszont érdemes visszaállni a korábbi rendszerre a biztonsági mentésből, és újból nekifutni a folyamatnak. Ha semmilyen konstellációban sem boldogulunk a frissítéssel, akkor érdemes egy tiszta telepítést végrehajtani, és a biztonsági mentésből helyreállítani a tartalmakat.

A frissítést követő lépések

Ugyan a rendszer már frissült az új verzióra, ám néhány további lépést még végre kell hajtanunk ahhoz, hogy minden működőképes legyen.

Elsőként is futtassuk az apparmor eltávolítási parancsát:

sudo service apparmor stop
sudo update-rc.d -f apparmor remove 
sudo apt-get purge apparmor apparmor-utils

Majd nézzük meg, hogy van-e olyan csomag, amelyet még frissíteni szükséges, és tegyünk egy kicsit rendet a már szükségtelenek eltávolításával:

sudo apt update
sudo apt upgrade
sudo apt dist-upgrade
sudo apt autoremove
sudo apt autoclean

Ha ez is megvan, akkor tegyük rendbe a dovecot levélkiszolgáló szolgáltatást, amelynek az új verziója a korábbinál szigorúbb követelményeket támaszt az általa használt tanúsítvánnyal szemben:

sudo openssl dhparam -out /etc/dovecot/dh.pem 4096
sudo systemctl restart dovecot

Ez a lépés eltarthat pár percig.

Ha befejeződött, akkor még végig kell mennünk a tökéletes Ubuntu 20.04 LTS szerver telepítésének lépésein, ugyanis egyes csomagok vagy konfigurációs beállítások még hiányozhatnak, többek között a postfixnél, a mariadb-nél  és az apache-nál.

Ha ez is megvan, akkor újrakonfigurálhatjuk az ISPConfigot az alábbi paranccsal:

ispconfig_update.sh --force

A vonatkozó kérdéseknél a szolgáltatásokat és a master adatbázist is újra kell konfigurálnunk, ám ha nem tapasztalunk problémákat, akkor az ISPConfig által beállított tanúsítványokat nem szükséges újra létrehozni.

Végül pedig engedélyeznünk kell a frissítéssel együtt letiltott külső csomagforrásokat (pl. az alternatív PHP-verziókat).

És ha mindez megvan, akkor már csak annyi a feladatunk, hogy utánanézünk a naplófájlokban, hogy minden problémamentesen működik-e. Ha pedig nem, akkor célzott hibaelhárítást kell végeznünk az érintett szolgáltatáson.

Érdemes az ISPConfig adminfelületére is bejelentkezni, és megnézni, hogy ott is a megfelelő adatok látszanak-e. Többszerveres környezetben előfordult, hogy az alárendelt szerver verziószáma csak egy nappal később frissült, és voltak olyan webhelyek is, ahol a tárhelykvótát újra be kellett állítani ahhoz, hogy az áttekintő lapon ne korlátlanként szerepeljenek.

Összegzés

A fenti lépéseket követve egy biztonságos, éles üzemben is használható LAMP-kiszolgálót kapunk, amelyen az Ubuntu 20.04 LTS fut. Mindennek természetesen az alapfeltétele az, hogy a kiindulási alapként szolgáló Ubuntu 18.04 LTS is mindenben kövesse a tökéletes Ubuntu 18.04 LTS szerverre vonatkozó útmutató előírásait. Ha mégsem sikerülne megbirkózni a feladattal, akkor vegye fel velünk a kapcsolatot, és segítünk a frissítésben!

Ebben az útmutatóban sorra vesszük az Ubuntu 20.04 LTS (Focal Fossa) szolgáltatásainak üzembe helyezéséhez szükséges lépéseket, majd telepítjük az ISPConfigot, végül pedig elvégezzük a szerver biztonságossá tételét (hardening).

MEGJEGYZÉS

Az ISPConfig telepíthető többszerveres konfigurációban is, mi ebben az útmutatóban csak a főszerver (master) telepítését ismertetjük. Az ISPConfig telepítése ki is hagyható, ha nincs szükség webes kezelőfelületre a szerver és annak felhasználóinak adminisztrálásához (például egyfelhasználós környezetben, ha nem kell több webhelyet adminisztrálni). Ebben az esetben a megjegyzéseket követve néhány opcionális lépést ki lehet hagyni, végeredményül azonban továbbra is egy biztonságos szerverkörnyezet áll majd a rendelkezésünkre, amely éles üzemben is használható.

Az eredeti, angol nyelvű útmutató itt található: https://www.howtoforge.com/tutorial/perfect-server-ubuntu-20.04-with-apache-php-myqsl-pureftpd-bind-postfix-doveot-and-ispconfig/

Az alábbi, magyar nyelvű útmutató az következő plusz információt nyújtja az eredetihez képest:

• helyenként részletesebb magyarázatok
• az ext4 mellett az xfs fájlrendszer támogatása a kvóták beállításánál
• a pontos idő rendszeres szinkronizálása ntpdate segítségével
• jelszóval védett phpmyadmin
• e-mailes értesítés minden SSH-bejelentkezés és -kijelentkezés esetén
• mod_evasive Apache-modul a szigorúbb webes védelem és a DDoS-támadások megelőzése érdekében
• fail2ban-szabályok az Apache és a roundcube védelméhez

Előfeltételek

Az útmutatóban szereplő lépések feltételezik egy már telepített Ubuntu 20.04 LTS szerver meglétét, amelyhez a felhasználó root jogosultsággal rendelkezik. Ez VPS-szerverek esetén általában automatikusan megtörténik a VPS létrehozásakor, saját környezetben viszont egy telepítési adathordozóról kell először telepíteni az operációs rendszert. Ez az útmutató ezekkel a lépésekkel nem foglalkozik, csak a már müködő rendszer konfigurálásával. Ugyanígy nem tér ki arra sem, hogyan lehet bejelentkezni a frissen telepített rendszerre SSH-n keresztül.

FIGYELEM!

A sikeres konfigurálás érdekében érdemes egy teljesen újonnan telepített rendszert használni, mivel egyéb esetben a korábbi beállítások ütközést okozhatnak az egyes lépések utasításainak végrehajtása során.

Az összes használt parancs root jogosultságot igényel, ezért a konzolra történő bejelentkezést vagy az SSH-kapcsolat létrejöttét követően elsőként érdemes kiadni az alábbi parancsot:

sudo -s

Az egyes fájlok szerkesztéséhez a nano szerkesztőt használjuk a példákban. Érdemes megismerkedni a használatával és a benne elérhető parancsokkal, mindenesetre kezdőknek segítségül jelezzük, hogy a módosítások mentéséhez és a fájlok bezáráshoz a CTRL + X billentyűkombinációt kell lenyomni, majd az Y billentyűt.

Az /etc/apt/sources.list tartalmának ellenőrzése és a források frissítése

Amennyiben a telepítés valamilyen fizikai adathordozóról történt, előfordulhat, hogy az még szerepel a telepítési források között. Ennek ellenőrzéséhez érdemes megnyitni az /etc/apt/sources.list fájlt:

nano /etc/apt/sources.list

majd meggyőződni annak tartalmáról:

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://de.archive.ubuntu.com/ubuntu focal main restricted
# deb-src http://de.archive.ubuntu.com/ubuntu focal main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://de.archive.ubuntu.com/ubuntu focal-updates main restricted
# deb-src http://de.archive.ubuntu.com/ubuntu focal-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://de.archive.ubuntu.com/ubuntu focal universe
# deb-src http://de.archive.ubuntu.com/ubuntu focal universe
deb http://de.archive.ubuntu.com/ubuntu focal-updates universe
# deb-src http://de.archive.ubuntu.com/ubuntu focal-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://de.archive.ubuntu.com/ubuntu focal multiverse
# deb-src http://de.archive.ubuntu.com/ubuntu focal multiverse
deb http://de.archive.ubuntu.com/ubuntu focal-updates multiverse
# deb-src http://de.archive.ubuntu.com/ubuntu focal-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://de.archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
# deb-src http://de.archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu focal partner
# deb-src http://archive.canonical.com/ubuntu focal partner

deb http://de.archive.ubuntu.com/ubuntu focal-security main restricted
# deb-src http://de.archive.ubuntu.com/ubuntu focal-security main restricted
deb http://de.archive.ubuntu.com/ubuntu focal-security universe
# deb-src http://de.archive.ubuntu.com/ubuntu focal-security universe
deb http://de.archive.ubuntu.com/ubuntu focal-security multiverse
# deb-src http://de.archive.ubuntu.com/ubuntu focal-security multiverse

Ezt követően pedig jöhet a rendszer frissítése:

apt-get update

apt-get upgrade

Ha a frissítések között újabb kernelverziók is láthatók, akkor ezt követheti egy:

apt-get dist-upgrade

apt-get autoremove

majd pedig egy újraindítás:

reboot

Az alapértelmezett rendszerhéj beállítása

Az Ubuntu alapértelmezett rendszerhéja a dash, ám nekünk a bashre lesz szükségünk, ehhez pedig az alábbi parancsot kell kiadni:

dpkg-reconfigure dash
Use dash as the default system shell (/bin/sh)? <-- No

FIGYELEM!

Ennek a lépésnek az elmulasztása esetén az ISPConfig ugyan nem lesz telepíthető, de a rendszer ettől még használható lesz.

Az AppArmor letiltása

Az Ubuntu egyik beépített biztonsági szolgáltatása az AppArmor, ám általában inkább több problémát okoz, mint amennyit segítene a biztonság fokozása terén, ezért érdemes letiltani. Az általa biztosított biztonsági megoldásokat bőven pótoljuk majd a későbbiekben.

service apparmor stop
update-rc.d -f apparmor remove 
apt-get remove apparmor apparmor-utils

FIGYELEM!

Ennek a lépésnek az elmulasztása esetén az ISPConfig ugyan nem lesz telepíthető, de a rendszer ettől még használható lesz.

A rendszeróra szinkronizálása és naprakészen tartása (opcionális)

Minden rendszeren fontos, hogy pontos legyen a rendszeridő, ehhez pedig érdemes telepíteni az ntp nevű csomagot, illetve rendszeres időközönként szinkronizálni az egyik időkiszolgálóval.

apt-get -y install ntp ntpdate

Ezt követően szerkeszteni kell a crontabot, és be kell szúrni az alábbi sort.

nano /etc/crontab 

00 2 * * * root ntpdate time.kfki.hu

Ebben a példában minden nap hajnali 2-kor fut le a szinkronizálás a magyarországi time.kfki.hu szerverrel. Érdemes mindig egy közeli szervert kiválasztani a szinkronizáláshoz. Nemzetközi környezetben a pool.ntp.org használata javasolt.

A postfix, dovecot, mariaDB, rkhunter és binutils telepítése

A postfix telepítéséhez biztosnak kell lennünk abban, hogy nincs telepítve a sendmail:

service sendmail stop; update-rc.d -f sendmail remove

Ha nincs telepítve, az alábbi hibaüzenet jelenik meg:

Failed to stop sendmail.service: Unit sendmail.service not loaded.

Ekkor jöhet a többi csomag telepítése:

apt-get -y install postfix postfix-mysql postfix-doc mariadb-client mariadb-server openssl getmail4 rkhunter binutils dovecot-imapd dovecot-pop3d dovecot-mysql dovecot-sieve sudo patch

General type of mail configuration: <-- Internet Site
System mail name: <-- mail.sajatdomain.hu

A mail.sajatdomain.hu helyett egy olyan domainnevet kell megadni, amelyet éles rendszerek esetén aztán majd beállítunk a DNS-ben is. Soha ne olyan nevet adjunk itt meg, amely egyben weboldal címe is lesz, hanem egy technikai nevet, amelyet webes tartalom kiszolgálására biztosan nem használunk.

Ezt követően engedélyezzük a TLS és SASL működését:

nano /etc/postfix/master.cf

Ki kell szedni a megjegyzésből a submission és az smtp alábbi szakaszait, valamint be kell szúrni 1-1 sort is:

[...]
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
[...]

Fontos, hogy a -o előtti szóközök nem hagyhatók le.

Most újraindíthatjuk a szolgáltatást:

service postfix restart

Majd beállítjuk, hogy a MariaDB a kívülről jövő kapcsolatokat is engedélyezze:

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Ehhez megjegyzésbe (#) kell tenni a localhostra (127.0.0.1-re) vonatkozó alábbi sort:

[...]
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address           = 127.0.0.1

[...]

Ezt követően jelszóval kell ellátnunk az adatbáziskiszolgáló root jogosultságú felhasználóját, letiltjuk az anonim felhasználókat, illetve a távoli bejelentkezést root jogosultságokkal:

mysql_secure_installation

Enter current password for root (enter for none): <-- Enter billentyű szöveg beírása nélkül
Set root password? [Y/n] <-- y
New password: <-- A MariaDB root jelszava
Re-enter new password: <-- A jelszó még egyzer
Remove anonymous users? [Y/n] <-- y
Disallow root login remotely? [Y/n] <-- y
Reload privilege tables now? [Y/n] <-- y

Beállítjuk a phpmyadmin használatához a megfelelő azonosítási módot:

echo "update mysql.user set plugin = 'mysql_native_password' where user='root';" | mysql -u root

Majd az előbb beállított jelszót megadjuk a rendszer karbantartási feladatai számára:

nano /etc/mysql/debian.cnf

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = root
password = a_root_felhasználó_jelszava
socket = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = root
password = a_root_felhasználó_jelszava
socket = /var/run/mysqld/mysqld.sock
basedir = /usr

Szerkesszük az /etc/security/limits.conf fájlt, és adjuk a következő sorokat a fájl végéhez:

nano /etc/security/limits.conf

mysql soft nofile 65535
mysql hard nofile 65535

Hozzunk létre egy új könyvtárat, benne egy fájllal és az alábbi tartalommal:

mkdir /etc/systemd/system/mysql.service.d/

nano /etc/systemd/system/mysql.service.d/limits.conf

[Service]
LimitNOFILE=infinity

Végül pedig indítsuk újra a szolgáltatást a változtatások életbe léptetéséhez:

systemctl daemon-reload
service mariadb restart

Az amavisd-new, spamassassin és clamav telepítése

A vírusok és a kéretlen levelek kiszűréséhez telepítsük az alábbi csomagokat:

apt-get -y install amavisd-new spamassassin clamav clamav-daemon unzip bzip2 arj nomarch lzop cabextract apt-listchanges libnet-ldap-perl libauthen-sasl-perl clamav-docs daemon libio-string-perl libio-socket-ssl-perl libnet-ident-perl zip libnet-dns-perl postgrey

Az ISPConfig használata esetén nincs szükség arra, hogy a spamassassin külön fusson:

service spamassassin stop
update-rc.d -f spamassassin remove

Indítsuk el a clamavot (ha egy hibaüzenet jelenik meg a parancs futtatásakor, azzal most nem kell foglalkoznunk):

freshclam
service clamav-daemon start

Az apache, php, phpmyadmin, fcgi, suexec és pear telepítése

A weboldalak kiszolgálásához telepítsük az alábbi csomagokat:

apt-get -y install apache2 apache2-doc apache2-utils libapache2-mod-php php7.4 php7.4-common php7.4-gd php7.4-mysql php7.4-imap phpmyadmin php7.4-cli php7.4-cgi libapache2-mod-fcgid apache2-suexec-pristine php-pear libruby libapache2-mod-python php7.4-curl php7.4-intl php7.4-pspell php7.4-sqlite3 php7.4-tidy php7.4-xmlrpc php7.4-xsl memcached php-memcache php-imagick php7.4-zip php7.4-mbstring php-soap php7.4-soap php7.4-opcache php-apcu php7.4-fpm libapache2-reload-perl

Web server to reconfigure automatically: <-- apache2 
Configure database for phpmyadmin with dbconfig-common? <-- Yes
MySQL application password for phpmyadmin: <-- Enter billentyű lenyomása szöveg bevitele nélkül

Ezt követően engedélyezzük a szükséges modulokat:

a2enmod suexec rewrite ssl actions include cgi alias proxy_fcgi
a2enmod dav_fs dav auth_digest headers

Majd pedig bebiztosítjuk a kiszolgálót a HTTPOXY-támadásokkal szemben:

nano /etc/apache2/conf-available/httpoxy.conf

Ennek új tartalma ez lesz:

<IfModule mod_headers.c>
    RequestHeader unset Proxy early
</IfModule>

MEGJEGYZÉS

Ez egy viszonylag régi támadástípus, amelyet 2016 közepén fedeztek fel, és a legnagyobb veszélyt a CGI-környezetekben folytatott PHP-s kódfuttatásra jelenti, ám mivel LTS rendszert használunk, így érdemes duplán bebiztosítani magunkat. (További információ: https://httpoxy.org/.)

Majd engedélyezzük a szabályzatot:

a2enconf httpoxy

És ezt követően újraindítjuk a szolgáltatást:

service apache2 restart

A hhvm telepítése (opcionális)

A Facebook által létrehozott HipHop Virtual Machine segít felgyorsítani a PHP-kódok futását. A telepítése a következő paranccsal történik:

apt-get -y install hhvm

A mod_evasive telepítése (opcionális)

A mod_evasive segít megakadályozni a szolgáltatásmegtagadásos támadásokat (DoS, DDoS) és a vég nélküli jelszókitalálásos próbálkozásokat, ugyanis korlátozza, hogy egy felhasználó egy adott időintervallumon belül hány oldalt kérhet le. Önmagában nem nyújt elegendő védelmet, azonban tökéletes kiegészítése a fail2ban működésének, mivel az főként csak a hitelesítésre összpontosít.

A telepítése a következő paranccsal történik:

apt-get -y install libapache2-mod-evasive

Ha esetleg rákérdez a telepítő bármire, akkor az alapértelmezett beállítást kell elfogadni. A következő paranccsal lehet ellenőrizni a sikeres telepítését:

apachectl -M | grep evasive

Erre egy ehhez hasonló választ kapunk:

 evasive20_module (shared)

Alapértelmezés szerint a konfiguráció nincs élesen üzembe helyezve, ezért most ezt kell módosítanunk:

nano /etc/apache2/mods-enabled/evasive.conf

Éles üzemben használt szervereken az alábbi értékek használata a javasolt:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10

    DOSEmailNotify      root@mail.sajatdomain.hu
    DOSSystemCommand    "su - someuser -c '/sbin/... %s ...'"
    DOSLogDir           "/var/log/mod_evasive"
</IfModule>

Értelemszerűen a fenti példában lévő root@mail.sajatdomain.hu címet egy saját használatú e-mail-címre kell lecserélni. Ezt követően még létre kell hoznunk a naplózáshoz szükséges mappát, megfelelő jogosultságot kell adnunk annak, majd újra kell indítanunk az apache szolgáltatást:

mkdir /var/log/mod_evasive
chown -R www-data:www-data /var/log/mod_evasive

systemctl restart apache2

A phpmyadmin jelszavas védelme

Bármilyen hihetetlen is, de a phpmyadmin alapértelmezett konfigurációban csak egy olyan jelszavas mezőt tesz elérhetővé, amellyel magához a MySQL szolgáltatáshoz lehet csatlakozni. Ez nem túl biztonságos megoldás, hiszen bárki elkezdhet próbálkozni a jelszavakkal. Szerencsére nem kell túl sok erőfeszítést tennünk ahhoz, hogy az Apache segítségével egy olyan jelszavas bejelentkezést hozzunk létre még ezt megelőzően, amelynél a sikertelen próbálkozásokat már a fail2ban kezeli, így a megadott számú téves próbálkozás után le is tiltja a próbálkozó szellemű támadót.

Ehhez első körben módosítanunk kell az alábbi konfigurációs fájlt, és engedélyeznünk kell a beállítások .htaccess általi módosítását (AllowOverride All):

nano /etc/apache2/conf-available/phpmyadmin.conf

# phpMyAdmin default Apache configuration

Alias /phpmyadmin /usr/share/phpmyadmin

<Directory /usr/share/phpmyadmin>
    Options SymLinksIfOwnerMatch
    DirectoryIndex index.php
    AllowOverride All
[...]

Ezt követően létrehozzuk a bejelentkezést megkövetelő fájl:

nano /usr/share/phpmyadmin/.htaccess

És beleírjuk az alábbi tartalmat:

AuthType Basic
AuthName "Restricted Files"
AuthUserFile /etc/phpmyadmin/.htpasswd
Require valid-user

Majd létrehozunk egy phpmyadmin nevű felhasználót a belépéshez:

htpasswd -c /etc/phpmyadmin/.htpasswd phpmyadmin

Ha további felhasználókat szeretnénk hozzáadni ehhez a fájlhoz, akkor az alábbi parancsot kell használnunk:

htpasswd /etc/phpmyadmin/.htpasswd felhasznalonev

A felhasznalonev helyére az adott felhasználó nevét írjuk. Végül pedig indítsuk újra a szolgáltatást a változtatások életbe léptetéséhez:

systemctl restart apache2

A Let's Encrypt telepítése

Napjaink webhelyei szinte kizárólag HTTPS-kapcsolaton keresztül érhetők el, és az olyan oldalak esetén, amelyeknél ez a feltétel nem teljesül, a böngésző biztonsági értesítést jelenít meg, és egyben nem is tanácsolja annak felkeresését. Régen az ehhez szükséges tanúsítványok csak fizetős verzióban voltak elérhetők (jó drágán), az önaláírt tanúsítványokat pedig szintén nem részesítik előnyben a böngészők. Szerencsére manapság már elérhető a Let's Encrypt, amely ugyan nem veheti fel a versenyt a komolyabb tanúsítványokkal, az alapfunkciókat tökéletesen ellátja, és minden böngésző biztonságosként fogja feltüntetni a nálunk tárolt webhelyeket. És ami a legfontosabb, teszi mindezt teljesen ingyenesen és automatikusan.

Így telepíthetjük:

apt-get -y install certbot

A pureftpd és quota telepítése

A szerverhez engedélyezhetünk FTP-kapcsolatot (és SSH-kapcsolatot is, de utóbbi használatát nehezebb lesz egyes felhasználóinknak elmagyarázni), és természetesen lehetőségünk nyílik arra, hogy elejét vegyük felhasználóink korlátlan terjeszkedésének, azaz mindenkinek beállíthatunk egy kvótát a webes, adatbázisban tárolt és levelezési tartalmak tárhelyhasználatára vonatkozóan.

Elsőként is telepítsük a szükséges csomagokat:

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

Ezt követően ellenőrizzük, hogy standalone módban fut-e a démon, és a felhasználókat bezárja-e a saját könyvtárukba:

nano /etc/default/pure-ftpd-common

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

Mivel a pureftpd alapesetben titkosítatlan kapcsolatokat is engedélyez, itt az ideje, hogy konfiguráljuk hozzá a TLS-kapcsolatokat és létrehozzunk egy (önaláírt) tanúsítványt, mivel nem szeretnénk, hogy a jelszavak sima szövegként utazgassanak az interneten:

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

mkdir -p /etc/ssl/private/

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

Country Name (2 letter code) [AU]: <-- HU
State or Province Name (full name) [Some-State]:<-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []:<-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []:<-- Részleg neve (pl.: informatikai részleg)
Common Name (eg, YOUR name) []:<-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []:<-- A webmester vagy a rendszergazda e-mail-címe

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

Majd indítsuk újra a szolgáltatást:

service pure-ftpd-mysql restart

Ezt követően a kvótarendszer aktiválásához módosítanunk kell a következő fájlt:

nano /etc/fstab

Minden rendszernél más lehet az egyes csatolt fájlrendszerek elnevezése, mindenesetre nekünk a root fájlrendszert kell megkeresnünk, amit a sima perjel ("/") jelöl, és ehhez kell hozzáadnunk a megfelelő plusz paramétereket.

Néhány példa erre:

ext4 fájlrendszer esetén: (,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0)

# /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>
/dev/mapper/server1--vg-root / ext4 errors=remount-ro,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0 0 1
/dev/mapper/server1--vg-swap_1 none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0

Vagy ext4 és UUID használata esetén: (,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0)

UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / ext4 defaults,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0 0 0
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /boot ext4 defaults 0 0
/swap.img       none    swap    sw      0       0

xfs fájlrendszer esetén: (,uquota,gquota)

proc            /proc   proc    defaults        0 0
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / xfs defaults,uquota,gquota 1 1
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX none swap sw 0 0

Ezt követően a módosítások életbe léptetéséhez a következők parancsok kiadására van szükség:

mount -o remount /

quotacheck -avugm
quotaon -avug

FIGYELEM!
xfs fájlrendszer esetén további lépésekre van szükség, ugyanis a kernelben is engedélyezni kell (rootflags=uquota,gquota) a kvótát. Ennek lépéseit lásd alább:

nano /etc/default/grub

[...]
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 net.ifnames=0 rootflags=uquota,gquota"
[...]

grub-mkconfig -o /boot/grub/grub.cfg

A végén pedig újra is kell indítanunk a rendszert a változtatások életbe léptetéséhez, hiszen a kernelt paramétereztük fel a rootflags=uquota,gquota attribútumokkal, így azt is újra be kell tölteni:

reboot

A kernel által nem támogatott kvótaformátum hiba

Előfordulhat, hogy a kernelben még ext4 fájlrendszer esetén sem érhetők el a megfelelő modulok, ebben az esetben a következő hiba jelenik meg:

quotaon: cannot find //aquota.group on /dev/vda1 [/]
quotaon: using //aquota.user on /dev/vda1 [/]: No such process
quotaon: Quota format not supported in kernel.

Szerencsére ennek a megoldása nagyon egyszerű, csak az alábbi parancsokat kell futtatnunk:

apt-get install linux-image-extra-virtual

echo quota_v1 >> /etc/modules
echo quota_v2 >> /etc/modules

Ha ezzel megvagyunk, akkor már csak újra kell indítanunk a szervert, és máris aktiválni tudjuk a kvótánkat.

A bind telepítése

A DNS-rendszerünket és -kéréseinket kiszolgáló szolgáltatás a manapság iparági szabványnak tekinthető bind lesz, amelynek kísérőjeként egy véletlenszám-generátort is telepítünk. Ennek lépései:

apt-get -y install bind9 dnsutils haveged

systemctl enable haveged
systemctl start haveged

A vlogger, webalizer és awstats telepítése

A nálunk elhelyezett egyes webhelyekhez statisztikákat is elérhetővé tehetünk, amelyek segítségével jobban nyomon követhető a forgalom, illetve a látogatók statisztikái:

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

echo "deb https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list.d/goaccess.list
wget -O - https://deb.goaccess.io/gnugpg.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/goaccess.gpg add -
sudo apt-get update
sudo apt-get install goaccess

nano /etc/cron.d/awstats

Majd itt az összes sort megjegyzésbe kell tenni:

#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

A jailkit telepítése

A jailkit segítségével lehet a saját könyvtárukra korlátozni az SSH-val bejelentkező felhasználókat:

apt-get -y install jailkit

A fail2ban és ufw telepítése

A fail2ban abban segít minket, hogy az egyes szolgáltatások használatakor korlátozza az azonosítási kísérletek számát, így a rosszindulatú támadók nem tudnak egy-egy szolgáltatásnál végtelen alkalommal próbálkozni, amíg ki nem találják a helyes jelszót.

apt-get -y install fail2ban

nano /etc/fail2ban/jail.local

(ez egy újonnan létrehozott fáj, így az alábbi teljes tartalmat bele kell másolni)

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

[dovecot]
enabled = true
filter = dovecot
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,pop3s,imap,imaps", protocol=tcp]
logpath = /var/log/mail.log
maxretry = 5

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 3

[apache]
enabled  = true
port     = http,https
filter   = apache-auth
# logpath  = /var/log/apache*/*error.log
logpath  = /var/log/ispconfig/httpd/*/error.log
findtime = 3600
maxretry = 3
bantime  = 86400

[roundcube]
enabled  = true
port     = http,https
filter   = roundcube
logpath  = /var/log/roundcube/userlogins
maxretry = 5

service fail2ban restart

Az ufw egy alapszintű tűzfal, amely kompatibilis az ISPConfiggal, így annak webes felületén lehet konfigurálni a megnyitni kívánt portokat. Mivel nem túl kifinomult, így általában nem szoktuk használni, hanem saját tűzfalszabályokat szoktunk alkalmazni az adott környezetnek megfelelően, viszont ha valaki csak egy egyszerű környezetben szeretné biztonságosabbá tenni a rendszerét, annak az ufw által nyújtott lehetőségek (az egyes szolgáltatások portjainak engedélyezése vagy letiltása) is elegendőek lehetnek. Akárhogyan is, telepíteni azért érdemes, mert a működése a webes felületről teljes mértékben irányítható (és ki is kapcsolható).

apt-get install ufw

A roundcube webmail telepítése

Levelezésünket ugyan teljes mértékben kezelni tudjuk a különböző levelezőkliensekből, mégis egyes felhasználók előnyben részesítik néha a webes kezelőfelület használatát. Arról nem is beszélve, hogy a spamszűrést és egyéb, a levelezéssel kapcsolatos beállítási lehetőséget csak a webmailen keresztül tudjuk elérhetővé tenni a számukra (ezzel egy külön cikkben foglalkozunk). Ehhez a roundcube-ot hívjuk segítségül:

apt-get -y install roundcube roundcube-core roundcube-mysql roundcube-plugins roundcube-plugins-extra javascript-common libjs-jquery-mousewheel php-net-sieve tinymce

Configure database for roundcube with dbconfig-common? <-- Yes
MySQL application password for roundcube: <-- Enter billentyű szöveg beírása nélkül

nano /etc/apache2/conf-enabled/roundcube.conf

Itt engedélyeznünk kell a roundcube aliasait (az egyiknél csak a megjegyzést kell eltávolítani, a másikat újonnan kell beírni), illetve engedélyezni kell a .php kiterjesztést is.

# Those aliases do not work properly with several hosts on your apache server
# Uncomment them to use it or adapt them to your configuration
    Alias /roundcube /var/lib/roundcube
    Alias /webmail /var/lib/roundcube

<Directory /var/lib/roundcube/>
  AddType application/x-httpd-php .php
  Options +FollowSymLinks
  # This is needed to parse /var/lib/roundcube/.htaccess. See its
  # content before setting AllowOverride to None.
  AllowOverride All
[...]

Majd újraindítjuk a szolgáltatást:

service apache2 restart

Végül pedig csak a helyi gép levelezéséhez engedélyezzük a csatlakozást:

nano /etc/roundcube/config.inc.php

[...]
$config['default_host'] = 'localhost';
[...]
$config['smtp_server'] = 'localhost';
$config['smtp_port']  = 25;
[...]

Az ISPconfig telepítése

A legújabb verzió a következő parancsokkal telepíthető:

cd /tmp 
wget -O ispconfig.tar.gz https://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz
tar xfz ispconfig.tar.gz
cd ispconfig3*/install/

php -q install.php

A telepítő gyakorlatilag minden szolgáltatást konfigurál nekünk, csupán néhány kérdésre kell választ adnunk.

FONTOS!
Az alábbiakban a főkiszolgáló (master) beállításait tüntetjük fel. Többkiszolgálós környezetben a többi szerver telepítésénél más beállításokat kell kiválasztani!

--------------------------------------------------------------------------------

>> Initial configuration
Operating System: Ubuntu 18.04 (Bionic Beaver)
Following will be a few questions for primary configuration so be careful.
Default values are in [brackets] and can be accepted with <enter>.
Tap in "quit" (without the quotes) to stop the installer.

Select language (en,de) [en]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Installation mode (standard,expert) [standard]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Full qualified hostname (FQDN) of the server, eg server1.domain.tld [mail.sajatdomain.hu]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL server hostname [localhost]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL server port [3306]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL root username [root]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL root password []: <-- A MySQL-nél megadott rootjelszó
MySQL database to create [dbispconfig]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL charset [utf8]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Configuring Postgrey
Configuring Postfix
Generating a 4096 bit RSA private key
.......................................................................++
........................................................................................................................................++
writing new private key to 'smtpd.key'
-----
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]: <-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) []: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy a rendszergazda e-mail-címe
Configuring Mailman
Configuring Dovecot
Configuring Spamassassin
Configuring Amavisd
Configuring Getmail
Configuring BIND
Configuring Jailkit
Configuring Pureftpd
Configuring Apache
Configuring vlogger
Configuring Metronome XMPP Server
writing new private key to 'localhost.key'
-----
Country Name (2 letter code) [AU]: <-- HU
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) [server1.canomi.com]: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy a rendszergazda e-mail-címe
Configuring Ubuntu Firewall
Configuring Fail2ban
[INFO] service OpenVZ not detected
Configuring Apps vhost
Installing ISPConfig
ISPConfig Port [8080]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Admin password [admin]: <-- Enter billentyű lenyomása szöveg bevitele nélkül (a jelszót a webes felületen érdemes módosítani, az első bejelentkezés után)
Do you want a secure (SSL) connection to the ISPConfig web interface (y,n) [y]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Generating RSA private key, 4096 bit long modulus
.......................++
................................................................................................................................++
e is 65537 (0x10001)
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]: <-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) []: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy rendszergazda e-mail-címe
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: <-- Enter billentyű lenyomása szöveg bevitele nélkül
An optional company name []: <-- Enter billentyű lenyomása szöveg bevitele nélkül
writing RSA key

Symlink ISPConfig LE SSL certs to postfix? (y,n) [y]:  <-- Enter billentyű lenyomása szöveg bevitele nélkül
Symlink ISPConfig LE SSL certs to pureftpd? Creating dhparam file takes some times. (y,n) [y]:  <-- Enter billentyű lenyomása szöveg bevitele nélkül

Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
.............................................................+.........................................................................................................................................................................+...................

Configuring DBServer
Installing ISPConfig crontab
no crontab for root
no crontab for getmail
Detect IP addresses
Restarting services ...
Installation completed.

Ezt követően pedig a 8080-as porton máris be tudunk jelentkezni az ISPConfigba. A felhasználónév és a jelszó azonos (admin), ám a jelszót az első bejelentkezés után erősen javasolt megváltoztatni!

https://mail.sajatdomain.hu:8080

E-mailes értesítés az SSH-bejelentkezésekről

Egy nyilvános szerver esetén érdemes minden óvintézkedést megtenni annak érdekében, hogy minden furcsa eseményről értesüljünk. A parancssori (SSH-) bejelentkezés egy kiemelten kritikus pontja a rendszerünknek, még akkor is, ha a korábbi lépéseket követve mindenkit bezártunk a saját könyvtárába. Az események nyomon követését segíti, ha e-mailes értesítést kapunk az SSH-s bejelentkezésekről. Ehhez először is hozzuk létre a figyelést végző szkriptet:

nano /usr/sbin/user-monitor.pl

#!/usr/bin/perl
# user_monitor.pl v0.4 :: keep track on who's logged in
# Written by Stephan Schmieder - http://www.unix-geek.info, 2003
# Usage: ./user-monitor.pl&

use strict;
use warnings;
use diagnostics;
use Net::SMTP;

#configuration
my $server =`uname -a|cut -d" " -f2`;
my $smtp_server ='localhost';
my $mail_to     ='root@mail.sajatdomain.hu';
my $mail_from   ='root@' . $server;
my $subject     ="$server :: User login monitor";
#configuration

my @old_users=split(/n/, qx/who/);
while(sleep(60))
{
        my @users=split(/n/, qx/who/);
        if(@users ne @old_users)
        {
                my $smtp = Net::SMTP->new($smtp_server);
                die "Couldn't connect to server" unless $smtp;
                $smtp->mail( $mail_from );
                $smtp->to( $mail_to );
                $smtp->data();
                $smtp->datasend("Subject: $subjectnn");
                foreach my $user (@users)
                {
                        $smtp->datasend("$usern");
                }
                $smtp->dataend();
                $smtp->quit();
        }
        @old_users=@users;
}

A root@mail.sajatdomain.hu helyére azt az e-mail-címet írjuk, ahová az értesítéseket kérjük.

FONTOS!
A szkript a rendszer saját postfix szolgáltatását használja a kimenő levelekhez, és elég kevés információt tesz bele a levélbe, ezért könnyen lehet, hogy az olyan nagyobb rendszerek, mint a gmail, levélszemétként észlelik az így küldött üzeneteket. Érdemes engedélyezési listára (whitelist) tenni a feladót, de a fenti szkriptet át is lehet írni igény szerint (akár egy külső SMTP-szolgáltatás, például a Postmark használatára).

Ezután módosítjuk a futtatási engedélyeket:

chmod 755 /usr/sbin/user-monitor.pl

Ahhoz, hogy a szkript minden rendszerindításkor elinduljon a háttérben, felvesszük a crontab bejegyzései közé a következő sor beszúrásával:

nano /etc/crontab

@reboot root    /usr/sbin/./user-monitor.pl&

Most pedig elindítjuk kézzel:

/usr/sbin/./user-monitor.pl&

A sikeres indítást követően meg kell jelennie a futó folyamatok listájában:

ps aux | grep monitor.pl

root      1026  0.0  0.2  59548 11380 ?        S    Aug09   0:22 /usr/bin/perl /usr/sbin/./user-monitor.pl

Összegzés

A fenti lépéseket követve egy biztonságos, éles üzemben is használható LAMP-kiszolgálót kapunk, amely ráadásul egy webes kezelőfelületen keresztül menedzselhető. Akár késznek is nyilváníthatjuk, ha az alapfunkciókon felül különösebb igényeink nincsenek, de alapul is szolgálhat a további testreszabásokhoz.

Miért van szükség az rspamd-re a kéretlen levelek szűréséhez?

A tökéletes Ubuntu-szerver telepítését ismertető útmutatónkban alapvető vírus- és spamszűrést helyeztünk üzembe a szerverünkön az amavis képében, ám ha nagyon sok kéretlen levelet kapunk, akkor a védelmünk és a tisztább postafiókunk érdekében sokkal jobban járunk, ha az rspamd-t választjuk. Szerencsére ez utóbbi is élvezi az ISPConfig teljes támogatását, ráadásul még a felhasználóinknak is lehetőséget adhatunk arra, hogy saját maguk szabják meg, mennyire szigorú szűrési szabályok legyenek érvényben a saját levelezésüknél.

Külön előny, hogy az rspamd saját webes felülettel is rendelkezik, ahol nyomon követhetjük a levelek pontozását és szűrését, és gyakorlatilag áttekinthetjük a teljes levelezésünket, valamint az ISPConfig adminfelületén domainek, kliensek és egyéni e-mail-fiókok szintjén is konfigurálhatjuk az alapértelmezett beállításokat.

Nézzük tehát, milyen lépésekre van szükségünk ahhoz, hogy üzembe helyezzünk egy hatékonyabb és szofisztikáltabb levélszemétszűrőt!

MEGJEGYZÉS

Az alábbi lépések feltételezik, hogy root jogosultsággal rendelkezünk a rendszeren. Szóval ha még nem tettük meg, adjuk ki a következő parancsot:

sudo su

A redis-server telepítése

Első lépésként telepítenünk kell néhány csomagot, elsőként a Redist, amely az adatainkat fogja tárolni a memóriában:
apt-get install redis-server lsb-release

Az unbound telepítése (amennyiben a BIND nincs telepítve)

Abban az esetben, ha a BIND nem lenne telepítve a szerverünkre, mindenképpen szükségünk van egy névfeloldást elvégző szolgáltatásra.

Elsőként is ellenőrizzük, hogy telepítve van-e a BIND:
which named

Ha erre válaszul valami ilyesmit kapunk, akkor folytassuk a következő lépéssel, mivel a BIND-ot már sikeresen telepítettük a gépre:
/usr/sbin/named

Amennyiben nem kapjuk meg a named elérési útját, úgy telepítenünk kell az unbound nevű csomagot:
apt-get install unbound

Az rspamd telepítése

A telepítés első lépése, hogy hozzáadjuk a csomagtárhoz az rspamd forrásait. Ehhez a következő parancsokat kell kiadnunk:
CODENAME=`lsb_release -c -s`
wget -O- https://rspamd.com/apt-stable/gpg.key | apt-key add -
echo "deb [arch=amd64] http://rspamd.com/apt-stable/ $CODENAME main" > /etc/apt/sources.list.d/rspamd.list
echo "deb-src [arch=amd64] http://rspamd.com/apt-stable/ $CODENAME main" >> /etc/apt/sources.list.d/rspamd.list

Majd frissíthetjük a csomaglistát:
apt-get update

És telepíthetjük a csomagunkat:
apt-get install rspamd

Ezután aktiválhatjuk a redis használatát:
echo 'servers = "127.0.0.1";' > /etc/rspamd/local.d/redis.conf

[OPCIONÁLIS] lépésként megnövelhetjük a megjelenített elemek számát, engedélyezhetjük a tömörítést, illetve megjeleníthetjük az üzenetek tárgyát:
echo "nrows = 2500;" > /etc/rspamd/local.d/history_redis.conf
echo "compress = true;" >> /etc/rspamd/local.d/history_redis.conf<
echo "subject_privacy = false;" >> /etc/rspamd/local.d/history_redis.conf

Végül pedig újra kell indítanunk a démont:
systemctl restart rspamd

Az ISPConfig frissítése

Ahhoz, hogy az rspamd kezelése is elérhetővé váljon (az amavis helyett) a felügyeleti rendszerünkben, frissítenünk kell az ISPConfigot. Ezt a következő paranccsal tehetjük meg:
cd /tmp
wget http://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz
tar xvfz ISPConfig-3-stable.tar.gz
cd ispconfig3_install/install
php -q update.php

A szolgáltatások újrakonfigurálására vonatkozó (reconfigure services) kérdésnél adjuk az igen (yes) választ.

Ezt követően be kell jelentkeznünk az ISPConfig adminfelületére az adminfelhasználóval, és a System > Server Config > Mail alatt a Content Filter legördülő menüjében az Amavisd helyett az Rspamd lehetőséget kell kiválasztanunk.

Az oldal mentése után végbemegy a levelezés átkonfigurálása, majd ha ez befejeződött, látogassunk vissza ugyanerre az oldalra, és megjelenik az rspamd-be történő bejelentkezéshez használatos jelszó.

Az rspamd webes felületének elérhetővé tétele

Alapértelmezés szerint az rspamd webes felülete csak a helyi gépről érhető el, ezért ha szeretnénk távolról is elérhetővé tenni, konfigurálnunk kell hozzá egy domaint vagy subdomaint az Apache-ban, és azon kell beállítanunk egy proxys elérést.

Először is engedélyezzük a szükséges modult, majd indítsuk újra a démont:

a2enmod proxy

systemctl restart apache2

Ezt követően az IPSConfig webes adminfelületén hozzunk létre egy új webhelyet. A nevet mi választhatjuk meg a rendelkezésre álló domainek alapján (pl. rspamd.example.com), a beállításokat pedig nem érdemes az alapértelemezésről másra átállítani, kivéve a Let's Encrypt esetén, mivel azt kifejezetten ajánlott bekapcsolni ahhoz, hogy az adatok ne titkosítatlan kapcsolaton keresztól utazzanak.

Ha kész az új webhely, akkor az Options lap Apache Directives mezőjébe írjuk be az alábbi sorokat:

<Location /rspamd>

RewriteRule ^/rspamd/(.*) http://127.0.0.1:11334/$1 [P]

Innetől kezdve az rspamd.example.com/rspamd elérési úton tudjuk majd megnyitni a webes felületet, és a fentiekben jelzett helyen található jelszóval tudunk belépni.

Az amavisd letiltása

Mivel már nincs rá szükségünk, tiltsuk le az amavist:

systemctl stop amavisd-new
systemctl disable amavisd-new

És készen is vagyunk!

A levélszűrési szabályok konfigurálása az ISPConfigban

Az ISPConfigban be tudjuk konfigurálni az egyes felhasználóknál beállított levélszűrési pontszámokat. Ehhez az Email > Policy menüpontot kell megnyitnunk, és itt tudjuk konfigurálni a már meglévő rekordokat, vagy akár újat is létrehozhatunk. Az Rspamd lapon három kategóriában pontozhatunk: a gyanús e-maileket (greylisting), a potenciális spameket (SPAM tag), illetve a biztosan kéretlen leveleket (SPAM reject) adhatjuk meg az általunk választott pontszámmal. Továbbá kiválaszthatjuk, hogy a potenciálisan spamként megjelölt leveleknél a levél fejlécében legyen ez a megjelölés vagy a tárgymezőben.

A pontozást nagyjából úgy kell elképzelni, hogy minél inkább hasonlít egy e-mail a kéretlen üzenetekre, és minél kevésbé felel meg az elvárt szabványoknak (pl. meghamisított a feladója, nem szabványos levelezőprogramból küldték, domainnév nélküli vagy ismeretlen helyről érkezett, trükközéssel próbálják megjeleníteni a szövegtörzs tartalmát stb.), annál több pontot fog kapni a szűrés során. Ha valamelyik kategóriát le szeretnénk tiltani, akkor a 999-es értéket kell megadni, ezt ugyanis egyik levél sem éri el a pontozás során.

A már készen elérhető sablonok jók lehetnek kiindulási pontként a saját rekordjaink létrehozásánál. A Permissive egy arany középútnak tekinthető, a Permissive - noreject akkor jöhet jól, ha biztosan nem akarjuk eldobni egyik levelet sem, átlagos felhasználóknál, legitim levelezés mellett pedig a Non-paying lehet a jó választás.

Nincs olyan beállítás, amely 100%-os módon garantálja, hogy sosem jut át a rostán olyasmi, aminek nem kellene, vagy éppen nem akad fenn rajta hasznos tartalommal rendelkező levél. Viszont az alapértelmezett sablont az e-mailek domainjeinek létrehozásakor is beállíthatjuk, és az egyes felhasználók szintjén is módosíthatjuk a Spamfilter mezőben. Ha a felhasználónál nincs semmi beállítva, akkor a domainnél megadott beállítások lesznek érvényben. (Azaz a domain összes felhasználója alapértelmezés szerint a domain beállítását örökli. Ha viszont meg lett adva másik beállítás általunk vagy a felhasználó által, akkor az lesz érvényben.)

Az alábbiakban azt is bemutatjuk, maguk a felhasználók hogyan tudják beállítani a kívánt szintet a webes levelezőben.

A levélszűrési szabályok felhasználói konfigurálása a roundcube-ban

Felhasználóinknak lehetőséget biztosíthatunk arra, hogy saját szabályokat adjanak meg a levélszemét szűrésével kapcsolatban. Például könnyen lehet, hogy valaki olyan e-maileket kap, amelyeket tévesen jelöl meg a rendszer spamként, vagy éppen szeret sok hírlevelet kapni, és ezek az üzenetek határesetnek számítanak a szűrőprogram szemében.

Szerencsére ezt könnyedén megtehetik, ha bejelentkeznek a webes levelezőfelületre, a roundcube-ba.

A beállítások elérési útja a következő: Beállítások > Profil > Spam-védelem. Itt láthatjuk a rendelkezésünkre álló lehetőségeket (azonosak az ISPConfigban konfigurált, fent ismertetett értékekkel), és kiválaszthatjuk a számunkra kedvező beállítást. Minél magasabb pontszámot adunk meg az egyes kategóriákban (gyanús levél, spamként megjelölt levél, elutasított levél), annál kisebb a valószínűsége, hogy egy adott levél kipontozódik. Ha valamelyik kategória alkalmazását le szeretnénk tiltani, akkor a 999-es értéket kell választanunk.

Az ISPConfig 3.2-re frissítés előfeltételei

Ahhoz, hogy frissíteni tudjunk a 3.2-es verzióra, 3.1.x-es verziójú rendszerrel kell rendelkeznünk. Továbbá az alábbi operációs rendszerek valamelyikét kell futtatnunk:

• CentOS 7
• CentOS 8
• Debian 9
• Debian 10
• Ubuntu 16.04 LTS
• Ubuntu 18.04 LTS
• Ubuntu 20.04 LTS

A szükséges szoftverek telepítése

Az új verzió igényel néhány új szoftvercsomagot is. Ezeket az alábbi paranccsal tudjuk telepíteni Debian/Ubuntu esetén:

sudo apt-get install bzip2 p7zip xz-utils lzip rar unrar-free goaccess dovecot-lmtpd

Illetve CentOS 7 esetén:

sudo yum -y install ncurses-devel gcc geoip-devel tokyocabinet-devel lbzip2 p7zip xz-libs lzip
cd /tmp
wget http://tar.goaccess.io/goaccess-1.4.tar.gz
tar xfz goaccess-1.4.tar.gz
cd goaccess-1.4
sudo ./configure --enable-utf8 --enable-geoip=legacy
sudo make
sudo make install
sudo ln -s /usr/local/bin/goaccess /usr/bin/goaccess

És CentOS 8 esetén:

dnf install ncurses-devel gcc geoip-devel tokyocabinet-devel lbzip2 p7zip p7zip-plugins xz-libs lzip
cd /tmp
wget http://tar.goaccess.io/goaccess-1.4.tar.gz
tar xfz goaccess-1.4.tar.gz
cd goaccess-1.4
sudo ./configure --enable-utf8 --enable-geoip=legacy
sudo make
sudo make install
sudo ln -s /usr/local/bin/goaccess /usr/bin/goaccess

Az utóbbi két rendszernél egy további lépésre is szükség van abban az esetben, ha a RAR használatát is elérhetővé szeretnénk tenni a biztonsági mentéseknél:

cd /tmp
wget https://www.rarlab.com/rar/rarlinux-x64-5.9.1.tar.gz
tar -zxvf rarlinux-x64-5.9.1.tar.gz
cd rar
sudo cp -v rar unrar /usr/local/bin/

Egyéni konfigurációs sablonok törlése

Amennyiben egyéni sablonokat használtunk a 3.1-es verzió alatt, ezeket vagy törölnünk kell, vagy ismételten létre kell hoznunk az új sablonformátum alapján. Első lépésben mindenesetre nézzük meg, hogy van-e ilyen sablonunk:

sudo ls -la /usr/local/ispconfig/server/conf-custom/

Ha itt a rendszer alapértelmezett fájljain kívül (empty.dir, error, index, install, mail) mást nem találunk, akkor nincsenek további teendőink.

Ugyanígy ellenőrizhetjük az install mappát is:

sudo ls -la /usr/local/ispconfig/server/conf-custom/install/

Ha ebben sincs semmi, akkor nem használtunk ilyen sablonokat. Ha mégis, akkor készítsünk róluk biztonsági másolatot, töröljük, majd a 3.2-es verzió telepítése után újra létre kell hoznunk őket.

A 8080-as porton elérhető ISPConfig, a Postfix, a Dovecot és a pure-ftpd Let's Encrypt-tanúsítványai

Amennyiben korábban manuálisan hoztunk létre Let's Encrypt-tanúsítványt a fenti szolgáltatásokhoz, most döntés előtt állunk: vagy töröljük ezeket a tanúsítványokat, vagy megtartjuk, és a telepítő erre vonatkozó kérdésénél a „no” választ adjuk meg. Ez a lépés azért fontos, mert ellenkező esetben az általunk beállított konfiguráció és frissítési szkript ütközhet az ISPConfig ütemezett feladataival. Értelemszerűen hosszabb távon úgy járunk el a leghelyesebben, ha az ISPConfigra bízzuk a feladatot, de lehetnek olyan helyzetek, amikor valamiért mi szeretnénk gondoskodni a tanúsítványokról.

Előkészületek multiserver környezetben

Ha több szervert is kezelünk az ISPConfiggal, akkor elsőként is a frissítés megkezdése előtt kapcsoljuk be a Maintenance Mode-ot (System -> Main Config -> Misc -> Maintenance Mode). Így gondoskodhatunk arról, hogy a frissítés alatt nem történik olyan módosítás, amely esetleg nem szinkronizálódik.

Ezt követően a szokásos sorrendhez képest most pont ellenkezőleg, a master szerver frissítésével kell kezdenünk a folyamatot, majd ezt követheti(k) a slave(-ek).

Ha készen van az összes szerver frissítése, ne felejtsük el kikapcsolni a Maintenance Mode-ot!

A frissítési folyamat elindítása

Ha készen vagyunk az előkészületekkel, itt az ideje elindítani a frissítési folyamatot. Először is váltsunk root felhasználóra. Debian esetén:

su -

Ubuntu és CentOS esetén:

sudo -s

Ezt követően indítsuk el a telepítési folyamatot:

ispconfig_update.sh

A frissítés forrásaként a „stable” lehetőséget adjuk meg. Ezt követően az alábbi kérdésekre kell válaszolnunk:

--------------------------------------------------------------------------------
 _____ ___________   _____              __ _         ____
|_   _/  ___| ___ \ /  __ \            / _(_)       /__  \
  | | \ `--.| |_/ / | /  \/ ___  _ __ | |_ _  __ _    _/ /
  | |  `--. \  __/  | |    / _ \| '_ \|  _| |/ _` |  |_ |
 _| |_/\__/ / |     | \__/\ (_) | | | | | | | (_| | ___\ \
 \___/\____/\_|      \____/\___/|_| |_|_| |_|\__, | \____/
                                              __/ |
                                             |___/
--------------------------------------------------------------------------------


>> Update

Operating System: Ubuntu 20.04.1 LTS (Focal Fossa)

This application will update ISPConfig 3 on your server.

Shall the script create a ISPConfig backup in /var/backup/ now? (yes,no) [yes]: yes

Creating backup of "/usr/local/ispconfig" directory...
Creating backup of "/etc" directory...
Checking ISPConfig database .. OK
Starting incremental database update.
Loading SQL patch file: /tmp/ispconfig3_install/install/sql/incremental/upd_dev_collection.sql
Reconfigure Permissions in master database? (yes,no) [no]: <-- Többkiszolgálós rendszereken „yes”, egykiszolgálós rendszeren „no”

Reconfigure Services? (yes,no,selected) [yes]: yes

Configuring Postfix
Configuring Dovecot
Configuring Mailman
Configuring Spamassassin
Configuring Amavisd
Configuring Getmail
Configuring BIND
Configuring Pureftpd
Configuring Apache
Configuring vlogger
Configuring Apps vhost
Configuring Jailkit
Configuring Ubuntu Firewall
Configuring Database
Updating ISPConfig
ISPConfig Port [8080]: <-- Az Enter lenyomásával fogadjuk el az alapértelmezett értéket

Create new ISPConfig SSL certificate (yes,no) [no]: <-- A „no” kiválasztásával őrizhetjük meg a meglévő SSL-tanúsítványokat, a „yes” kiválasztásával pedig új Let's Encrypt-tanúsítványokat telepíthetünk

Reconfigure Crontab? (yes,no) [yes]: yes

Updating Crontab
Restarting services ...
Update finished.

Ha problémába ütköztünk a telepítés során...

Ha valami problémába ütköztünk, és vissza kell állnunk a korábbi verzióra, akkor az ehhez szükséges fájlokat és biztonsági mentést a /var/backup mappában találjuk meg.

ls /var/backup/

Ha pedig a közösség segítségére van szükségünk, vagy csak a telepítés előtt szeretnénk meggyőződni arról, hogy mások tapasztaltak-e olyan problémát, amely miatt még el kellene halasztanunk a frissítést, akkor a támogatási fórumot kell felkeresnünk.

Mint látható, hacsak nem variáltunk valami óriásit a rendszerünkön, néhány lépést követve pillanatok alatt frissíthetünk az új verzióra, és máris igénybe vehetjük az általa nyújtott legújabb funkciókat.

Pár napja röppent fel a hír, miszerint a tervek szerint október 1-jén elérhetővé válik az ISPConfig 3.2-es verzió, amely már támogatni fogja az Ubuntu 20.04 és a CentOS 8 operációs rendszer használatát is.

FRISSÍTÉS: október 1-jén csak a 3. nyilvános bétaverzió látott napvilágot, és a jelenlegi tervek szerint október 12-én várható a végleges kiadás.

Az alábbiakban gyorsan összefoglaljuk a főbb változásokat:

• CentOS 8 és Ubuntu 20.04 támogatása
• A Courier levelezőszolgáltatás támogatása megszűnik, csak a Dovecot használata lesz támogatott

Általános változások:

• Megszűnik az elavult TLSv1 és TLSv1.1 támogatása
• A Let's Encrypt-tanúsítványok immáron az irányítópulthoz. a Postfixhez, a Dovecothoz és a PureFTPd-hez is automatikusan igényelhetők és frissíthetők
• Lehetővé válik gyakorlatilag az összes felhasználói felületi elem más nyelvre történő fordítása
• Számos új fordítással bővül a rendszer

Webhelyek:

• Megszűnt az APS támogatottsága, mivel a projekt sem él már
• Alapértelmezés szerint engedélyezve lesz a HTTP/2
• Directive snippetek módosítása esetén végre automatikusan életbe lépnek a változtatások a snippetet használó összes webhelynél is
• A webhelyek alias- és subdomain-függőségei mostantól láthatók lesznek a felületen
• Számos új biztonsági mentési lehetőség válik elérhetővé (titkosítás, új tömörítési formátumok, manuális backup)
• GoAccess-támogatás

E-mailek:

• Automatikusan be lehet állítani a levélszemét (spam) és a kuka X napnál régebbi üzeneteinek törlését
• A levélszemét mostantól automatikusan a kukába kerül az újonnan létrehozott postafiókoknál 
• A beállítások széles köre elérhetővé vált a felhasználóknak is

DNS:

• Számos apróbb változtatás mellett elérhetővé vált az SSHFP- és DNAME-rekordok használata

Monitorozás:

• Végre a Let's Encrypt logja is nyomon követhető a felületről

És még számos hibajavítás, felhasználói élményt fokozó változtatás, valamint konkrét használati eseteket érintő módosítások. A teljes listát a változásnapló tartalmazza.

A zanzásított, de a fentieknél kicsit bővebb lista pedig megtalálható az ISPConfig 3.2 Beta 2 megjelenését ismertető blogbejegyzésben.

Bizonyos területeken elég komoly, de időszerű változások jönnek, ráadásul az Ubuntu 20.04-es verzió támogatottságának elérhetővé válásával lassan érdemes lesz megtervezni az átállást is az új LTS-verzióra.

FONTOS!

A bétaverziós szoftver használata éles üzemben működő kiszolgálókon nem javasolt. A bétaverziós használatot elkülönített fejlesztői környezetben érdemes tesztelni, a 3.2-es verzióra pedig majd akkor érdemes áttérni, ha megjelent a végleges kiadás. (Erre várhatóan október 1-jén kerülhet sor.)

A kisebb forgalmú WordPress-oldalak egyik gyakori problémája, hogy az ütemezett WordPress-bejegyzések nem jelennek meg a megfelelő időpontban. Ennek oka elsődlegesen az, hogy a WordPress egy saját cront (feladatidőzítőt) tart fenn az ütemezett feladatok végrehajtásához, és hacsak nem gondoskodunk ennek rendszeres időközönként történő futtatásáról, könnyen előfordulhat, hogy pl. egy 10:00 időpontra beütemezett feladat azért nem tud kikerülni az internetre, mert ekkor éppen senki sem kereste fel az oldalunkat, így ezt a feladatot sem tudta az adott időpontban triggerelni a WordPress. Ilyenkor sikertelen időzítés állapotba kerül a bejegyzés, ami azért is bosszantó, mert azon túl, hogy semmi sem történik majd vele automatikusan, és erről még csak értesítést sem kapunk, nekünk kézzel kell újra közzétennünk a bejegyzést a szerkesztőből.

Szerencsére, mint mindenre, erre is létezik megoldás, méghozzá nem is egy. Lássuk a részleteket!

Feladatok ütemezése bővítménnyel

Ahogy az a WordPress esetén szinte mindenre igaz, itt is érvényes, hogy erre a problémára is létezik egy bővítmény! Nem is egy, hanem rögtön kettő. Az egyik a Scheduled Post Trigger névre hallgat, és a telepítésén és aktiválásán kívül semmi más teendőnk nincs. Állítólag sokaknak működik, mi kipróbáltuk az egyik oldalunkon, és egy, a bővítmény telepítése előtt ütemezett WordPress-bejegyzés esetén semmi változást nem tapasztaltunk. Azaz továbbra is sikertelen időzítéses állapotban maradt. Ez lenne a legegyszerűbb módja a probléma megoldásának, de úgy tűnik, nem 100%-ban működőképes. Mindenesetre érdemes vele tenni egy próbát, és ha beválik, akkor le is zárhatjuk a problémamegoldást. Ha nem, akkor érdemes telepíteni a következő bővítményt.

Ha esetleg mégsem működne, akkor viszont van egy tuti tippünk, amelynek csak egy picit körülményesebb a telepítése. Ez a WP Missed Schedule névre hallgat, és a készítőjének kérésére nem érhető el a WP kereshető bővítménykatalógusában. A GitHub-oldalról viszont könnyedén le tudjuk tölteni ZIP formátumban (lásd az alábbi képen), és ezt már a Bővítmények oldalán csak fel kell töltenünk a saját oldalunkra. Az aktiválását követően ezzel sincs semmi dolgunk, és ez a bővítmény nálunk minden oldal esetében probléma nélkül működött, még akkor is, ha a telepítését megelőzően időzített bejegyzésről volt szó.

Egyedül arra kell figyelni, ha esetleg alapvetően megváltozik a WordPress működése (például 5.x-esről 6-os verzióra kell frissíteni), mert akkor könnyedén működésképtelenné válhat ez a bővítmény, és mivel nem szerepel a bővítménytárban, így a frissítéséről is nekünk kell majd gondoskodnunk. Mivel a WP egy alapvető, központi funkciójáról van szó, ezért nem valószínű, hogy ez a közeljövőben problémát okozna, de nem árt észben tartani, ha egyszer csak megint meghiúsul egy időzített bejegyzés közzététele.

A cron futtatása rendszeres időközönként

Természetesen létezik másik megoldás is arra, hogy az alacsonyabb látogatói forgalmat kompenzáljuk. Mi magunk is gondoskodhatunk arról, hogy minden percben legyen forgalom az oldalunkon. Amennyiben a webhelyszolgáltatást béreljük egy szolgáltatótól, úgy az ő felületünkön kell utánanéznünk, hogy az alábbiakban leírtakra lehetőségünk nyílik-e. Ha a saját szerverünket használjuk, akkor pedig lehetőségünk nyílik a rendszer-crontab használatával gondoskodni a megfelelő oldal rendszeres lekéréséről.

A WordPress beépített cronjának letiltása

Első lépésként le kell tiltanunk a WordPress saját, beépített cronját, mivel innentől kezdve nem a külső (látogatói) oldallekérések alapján fogjuk futtatni a tervezett feladatokat. Ehhez szerkeszteni kell a WP gyökérkönyvtárában található wp-config.php fájlt, és el kell helyezni benne az alábbi sort:

 define('DISABLE_WP_CRON', true);

ISPConfig használata esetén

Amennyiben a tökéletes Ubuntu szerverünket használjuk, és telepítettük rá az ISPConfig nevű webes irányítópultot, akkor a Sites -> Cron Jobs alatt tudunk új cron-feladatot létrehozni. Itt adhatjuk meg, hogy melyik webhelyről van szó, valamint a feladat időzítését. Ha minden percben szeretnénk futtatni a fealadatokat (bejegyzések közzétételéhez erre lesz szükségünk, más karbantartási feladatok végrehajtása esetén elegendő lehet 5 percenként is futtatni a cront), akkor az összes időzítős időegységhez csak egy csillagot kell írnunk.

A Command to run mezőben pedig azt az URL-címet kell megadnunk, amellyel a WP cronját tudjuk meghívni: https://sajatdomain.hu/wp-cron.php?doing_wp_cron

És már készen is vagyunk!

Rendszerszintű cron-faladat használata esetén

Ha nincs webes vezérlőpultunk, de van SSH-hozzáfésérünk az Ubuntu- vagy Debian-rendszerünkhöz, akkor a crontab -e parancs kiadásával tudjuk szerkeszteni a rendszer aktuálisan bejelentkezett felhasználójának crontabját. Ide kell felvennünk új sorként a következő kifejezést:

* * * * * wget http://sajatdomain.hu/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Vagy csak karbantartási feladatok esetén, ha elegendő az 5 perces időköz:

*/5 * * * * wget http://sajatdomain.hu/wp-cron.php?doing_wp_cron > /dev/null 2>&1

A mentést követően máris élesedik a feladat, és a rendszer minden percben (vagy ötödik percben) lefuttatja a parancsot.

Ha esetleg a wget nem lenne telepítve a rendszerre, akkor a sudo apt-get install wget paranccsal tudjuk telepíteni.

Egy szerver rendszergazdai feladatainak ellátása elég összetett feladatot jelent, hiszen rengeteg paramétert kell szem előtt tartani, számos szolgáltatást kell összehangolt módon működtetni, és időről időre olyan változásokat kell életbe léptetni, mint új felhasználók vagy webhelyek felvétele, illetve régebbiek törlése. És akkor még nem is beszéltünk az egyes kritikus riasztásokról, például akkor, ha elfogyott a memória vagy egy szolgáltatás leállt, vagy a rendszerfrissítések automatikus telepítéséről. 

Pontosan ilyenkor jönnek jól a webes vezérlőpultok, melyek közül a legismertebbek a Plesk, az ISPConfig, illetve a cPanel. Mi az utóbbival most nem foglalkozunk, mivel munkánk során nem sűrűn találkozunk vele, lévén nem támogatja az általunk előnyben részesített linuxos disztribúciót (Ubuntu), ám az első két választási lehetőség is tökéletesen elegendő ahhoz, hogy lefedjük majdnem a teljes spektrumot. Azonban azt nem árt szem előtt tartani, hogy a két termék teljesen más megközelítést nyújt, és bár a végeredményt tekintve ugyanazt teszik – felügyeletet és monitorozást nyújtanak a kiszolgálónkhoz –, kissé eltérő célközönség számára készültek. Az alábbiakban sorra vesszük azokat a szempontokat, amelyeket érdemes figyelembe venni a számunkra ideális megoldás kiválasztása során.

Mire jó egy webes vezérlőpult?

Elsőként érdemes azt tisztázni, milyen célra szolgál egy ilyen termék (nem csupán az általunk most ismertetett kettő, hanem gyakorlatilag az összes hasonszőrű megoldás), illetve milyen műveleteket lehet automatizálni a segítségével. Általánosságban elmondható, hogy mindegyik képes az alábbi alapfeladatok ellátására:

• Webhelyek és domainek (DNS) kezelése, HTTPS-kapcsolat (SSL-tanúsítványok beszerzésének, megújításának és kezelésének) biztosítása
• Felhasználók, webhelyek, adatbázisok, FTP-kapcsolatok és egyéb elérések hozzáadása, módosítása és törlése
• Kvóták érvénybe léptetése (azaz pl. a tárhelyhasználat vagy a hálózati forgalom mennyiség- és időalapú, pl. havi korlátozása)
• E-mail-címek teljes körű kezelése (hozzáadás, módosítás, átirányítás, eltávolítás)
• Adatbázisok kezelése (létrehozás, módosítás, törlés, hozzáférések beállítása)
• Spamszűrés és más biztonsági funkciók biztosítása a szerver védelméhez
• A kiszolgáló állapotának figyelése és értesítések küldése bizonyos rendszeresemények vagy hibák bekövetkezésekor

Ki a célközönség?

Érdemes szem előtt tartani, hogy mindegyik webes vezérlőpult rendszergazdáknak, és nem végfelhasználóknak készült. Egyrészt nem helyettesítik a rendszer alapos ismeretének meglétét, másrészt pedig ugyanúgy működésképtelenné tehetjük vele a szerverünket, mint amikor valaki a parancssorban ad ki parancsot egy visszavonhatatlan műveletre. Gyakorlatilag úgy kell elképzelnünk, mint a legtöbb felhasználói felületet – ugyanazokat a feladatokat tudjuk elvégezni, mint a parancssorban, csak éppen kapcsolókkal, legördülő menükkel és számos automatizált könnyítéssel. Talán egy kicsit kisebb a hibázás lehetősége, hiszen a nagyon rossz beállítási kombinációkra felhívják a figyelmünket, az igazán végzeteseket pedig végrehajtani sem tudjuk, de minden más tekintetben szinte teljes vezérlést kapunk a szerverünk beállításai felett.

Azt is fontos tudni, hogy ezek a rendszerek elsődlegesen azoknak nyújtanak segítséget, akik több felhasználót, webhelyet, adatbázist és e-mail-címet kezelnek. Azoknak nem sokban könnyítik meg az életét, akik egyetlen gépen egyetlen webhelyet állítanak be, majd gyakorlatilag a rendszerfrissítések telepítésén kívül hozzá sem akarnak nyúlni ahhoz. Egy-két dolog automatizálásával ugyan előnyökhöz juthatnak, de ha havonta 2-3 parancssori parancsot kell csak kiadniuk, akkor könnyedén érezhetik azt, hogy felesleges volt ezért a webes felülethez folyamodniuk. Akinek azonban több felhasználója, ügyfele, webhelye és adatbázisa, valamint rengeteg e-mail-címe van, áldásként tekinthet arra, hogy ezek kezelését a több helyen történő manuális adminisztrálás helyett csupán pár kattintással elvégezheti.

A számítástechnikában (és az élet számos területén) vannak klikkesedések és egymással szemben álló felek. Természetesen itt is találkozhatunk olyannal, aki erre vagy arra a termékre esküszik, és a véleménye szerint minden más használhatatlan hulladék vagy felesleges pénzkidobás. A valóság azonban ennél sokkal árnyaltabb, kicsit ahhoz hasonlatos, mint az Android és az iOS esete. Mindkettő operációs rendszer teljes mértékben ellátja a feladatát, lehet a segítségével telefonálni, SMS-t küldeni, naptárat használni és különböző alkalmazásokat futtatni, mégis alapvetően kicsit más elképzelést szem előtt tartva lettek felépítve. Az iOS szereti vezetni a felhasználók kezét, és feltételezi, hogy a rendszer biztonságát és mélyebb működését illetően jobban tudja, mi a jó a használójának, míg az Android nagyobb teret enged a testreszabásoknak, és mélyebb szinten módosíthatja a felhasználó annak működését.

Ha ezt az analógiát követjük, akkor a Plesk az iOS-nek felel meg, ugyanis nem szereti, ha felülbíráljuk a webes felület beállításait, és inkább az általa javasolt módszerek használatát részesíti előnyben az egyedi megoldásokkal szemben, cserébe viszont a szűkebb választási lehetőségeknek hála könnyebben képes gondoskodni a rendszer integritásáról és problémamentes működéséről. (Érdemes kihangsúlyozni, hogy itt a teljes rendszerről van szó, a webhelyeket ugyanúgy 2 kattintással működésképtelenné teheti bárki, ha rossz beállításokat ad meg az adminfelületen.)

Az ISPConfig pedig inkább az Androidra hasonlít, mivel nagyobb teret enged a felhasználó egyéni megoldásainak, viszont bizonyos pontokon szigorúan megköveteli bizonyos iparági sztenderdek betartását. Emiatt lehet az, hogy utóbbinál először telepítenünk kell A tökéletes Ubuntu szervert, és konfigurálnunk kell számos dolgot, majd csak ezt követően ültetjük mindennek a tetejére az ISPConfigot. (Ehhez képest a Plesket egy tiszta telepítést (vagy egy VPS létrehozását) követően már rögtön üzembe helyezhetjük, és minden beállítást már a webes felületen adhatunk meg.) Ez viszont óriási előny lehet azoknak, akik nem szeretik, ha megkötik a kezüket, viszont mégis szeretnék élvezni az automatizálások és az átfogó rendszerfelügyelet előnyeit.

Leegyszerűsítve a kérdést mondhatjuk, hogy a Plesk a kényelmesebb vagy a kevesebb egyedi megoldást használó rendszergazdáknak készült, míg az ISPConfig inkább a tapasztaltabb és a kezük bepiszkolásától nem ódzkodóknak.

Fontos szempont még az árképzés, ugyanis ez is döntő szempont lehet a választásnál. A Plesk havi (vagy éves) licencdíj ellenében vehető igénybe, amely szerverenként fizetendő, és lépcsőzetesen növekszik attól függően, hogy a szolgáltatások teljes körét szeretnénk-e igénybe venni, vagy csak egy részhalmazát. Az ISPConfig viszont egy teljesen ingyenes, nyílt forráskódú szoftver, és csupán a részletes dokumentáció beszerzéséért kell egy névleges támogatási összeget kifizetnünk. (A rendszer használatát e nélkül is el tudjuk sajátítani, mi azonban minden ügyfelünk után meg szoktuk venni a dokumentációt, hogy ezzel is támogassuk a készítőjét és a jövőben kiadandó fejlesztéseket.) Sokhelyütt olvashatunk olyan véleményeket, hogy ennek megfelelően alakul a terméktámogatás, azaz a support kérdése is, avagy a fizetős termék mögött egy teljes ügyfélszolgálati rendszer áll, az ingyenesnél viszont a kérdéseinkre a legkönnyebben fórumokat bogarászva vagy a készítőnek küldött e-mailre érkezett válasz útján kaphatunk választ. Ezt a tévhitet itt és most megcáfolnánk, mert bár való igaz a kettő közötti jelentős különbség, az ISPConfig közössége kifejezetten aktívnak mondható, és a készítő is minden megkeresésre szívesen és készségesen reagál (bár előbb érdemes megnézni a korábban már feltett kérdéseket és a dokumentációt, mivel a legtöbb kérdésünkre már ott a válasz), így gyakorlatilag semmilyen hátrányba nem kerülünk a fizetős szoftverekkel szemben.

Milyen főbb elönyei és hátrányai vannak a Plesknek és az ISPConfignak?

A legjobban talán táblázatos formában lehet áttekinteni az eddig leírtakat:

Van-e átjárhatóság a különböző rendszerek között?

A jó hír és a rövid válasz az, hogy igen, de természetesen vannak bizonyos megkötések. A Plesk a cikk írásának pillanatában a következő rendszerekről teszi elérhetővé a migrálást:

• korábbi Plesk-verziók (Linux és Windows egyaránt)
• cPanel
• Confixx
• Helm
• Parallels Pro Control Panel
• DirectAdmin

Mint jól látható, az ISPConfig nem szerepel a lehetőségek között, és talán nem véletlenül. A használata során ugyanis megannyi egyéni módosítás történik a rendszeren, és ezt elég nehéz lenne átültetni a Pleskbe (jelentős részük az áttelepítés során egyszerűen elveszne, és az alapértékre állna át). Meg ahogy korábban írtuk, a mögöttes filozófia is teljesen más.

Az ISPConfig a cikk írásának pillanatában a következő rendszerekről teszi elérhetővé a migrálást:

• korábbi ISPConfig-verziók
• Plesk 10-12.5
• Plesk Onyx
• cPanel
• Confixx 3

Itt egy kicsit jobb már a helyzet, tehát Pleskről például könnyedén áttérhetünk ISPConfigra, de a cPanel is támogatott. Hátulütője a dolognak, hogy ehhez meg kell vásárolnunk az ISPConfig Migration Toolkitet, amely viszont egyben tartalmazza a migráláshoz szükséges kódot és az ISPConfig-szerverek üzemszünet nélküli áthelyezéséhez szükséges ISPCopy eszközt is. Ennek ára jelenleg 59 euró, ami még mindig messze elmarad a Plesk (vagy bármely másik vezérlőpanel) éves licencdíjától.

A támogatott nyelvek listája

Még egy fontos szempontot érdemes figyelembe venni a választás során, és ez a támogatott nyelvek listája. Szerencsére mindkét termék elég jól áll ezen a téren, ugyanis mind az ISPConfig, mind a Plesk számos nyelven beszél, többek között magyarul is tud mindkettő. És hogy ez miért is olyan különösen fontos?

Bár feltételezhetjük, hogy a rendszergazda tud angolul (legalább olyan szinten, hogy egy ilyen webes felületen el tudja végezni a szükséges feladatokat), ezeknek a termékeknek az egyik fő előnyük, hogy a saját webhelyeik menedzselését rábízhatjuk az ügyfelekre is. Azaz például a segítségükkel módosítani tudják a webhelybeállításokat, az e-mailes dolgaikat, vagy éppen kezelni tudják a DNS-eiket. És mindig szigorúan csak olyan keretek között, amit mi a kvótájuknál beállítottunk.

Gondolom, az önkiszolgáló felület használatának előnyeit nem kell részleteznünk (főleg olyankor, ha egy ügyfélhez több domain is tartozik, ráadásul hetente szeretne új e-mail-címeket létrehozni), de persze, ehhez az is szükséges, hogy az ügyfél tisztában legyen azzal, milyen műveletet végez éppen a felületen, ellenkező esetben csak a telefonhívásokat kapjuk majd, hogy sürgősen orvosoljuk az elérhetetlen webhelyük problémáját.

Az ISPConfig által támogatott nyelvek listája itt érhető el.

Ebben az útmutatóban sorra vesszük az Ubuntu 18.04 LTS (Bionic Beaver) szolgáltatásainak üzembe helyezéséhez szükséges lépéseket, majd telepítjük az ISPConfigot, végül pedig elvégezzük a szerver biztonságossá tételét (hardening).

MEGJEGYZÉS

Az ISPConfig telepíthető többszerveres konfigurációban is, mi ebben az útmutatóban csak a főszerver (master) telepítését ismertetjük. Az ISPConfig telepítése ki is hagyható, ha nincs szükség webes kezelőfelületre a szerver és annak felhasználóinak adminisztrálásához (például egyfelhasználós környezetben, ha nem kell több webhelyet adminisztrálni). Ebben az esetben a megjegyzéseket követve néhány opcionális lépést ki lehet hagyni, végeredményül azonban továbbra is egy biztonságos szerverkörnyezet áll majd a rendelkezésünkre, amely éles üzemben is használható.

Az eredeti, angol nyelvű útmutató itt található: https://www.howtoforge.com/tutorial/perfect-server-ubuntu-18.04-with-apache-php-myqsl-pureftpd-bind-postfix-doveot-and-ispconfig/

Az alábbi, magyar nyelvű útmutató az következő plusz információt nyújtja az eredetihez képest:

• helyenként részletesebb magyarázatok
• az ext4 mellett az xfs fájlrendszer támogatása a kvóták beállításánál
• a pontos idő rendszeres szinkronizálása ntpdate segítségével
• jelszóval védett phpmyadmin
• e-mailes értesítés minden SSH-bejelentkezés és -kijelentkezés esetén
• mod_evasive Apache-modul a szigorúbb webes védelem és a DDoS-támadások megelőzése érdekében
• fail2ban-szabályok az Apache és a roundcube védelméhez

Előfeltételek

Az útmutatóban szereplő lépések feltételezik egy már telepített Ubuntu 18.04 LTS szerver meglétét, amelyhez a felhasználó root jogosultsággal rendelkezik. Ez VPS-szerverek esetén általában automatikusan megtörténik a VPS létrehozásakor, saját környezetben viszont egy telepítési adathordozóról kell először telepíteni az operációs rendszert. Ez az útmutató ezekkel a lépésekkel nem foglalkozik, csak a már müködő rendszer konfigurálásával. Ugyanígy nem tér ki arra sem, hogyan lehet bejelentkezni a frissen telepített rendszerre SSH-n keresztül.

FIGYELEM!

A sikeres konfigurálás érdekében érdemes egy teljesen újonnan telepített rendszert használni, mivel egyéb esetben a korábbi beállítások ütközést okozhatnak az egyes lépések utasításainak végrehajtása során.

Az összes használt parancs root jogosultságot igényel, ezért a konzolra történő bejelentkezést vagy az SSH-kapcsolat létrejöttét követően elsőként érdemes kiadni az alábbi parancsot:

sudo -s

Az egyes fájlok szerkesztéséhez a nano szerkesztőt használjuk a példákban. Érdemes megismerkedni a használatával és a benne elérhető parancsokkal, mindenesetre kezdőknek segítségül jelezzük, hogy a módosítások mentéséhez és a fájlok bezáráshoz a CTRL + X billentyűkombinációt kell lenyomni, majd az Y billentyűt.

Az /etc/apt/sources.list tartalmának ellenőrzése és a források frissítése

Amennyiben a telepítés valamilyen fizikai adathordozóról történt, előfordulhat, hogy az még szerepel a telepítési források között. Ennek ellenőrzéséhez érdemes megnyitni az /etc/apt/sources.list fájlt:

nano /etc/apt/sources.list

majd meggyőződni annak tartalmáról:

## Note, this file is written by cloud-init on first boot of an instance
## modifications made here will not survive a re-bundle.
## if you wish to make changes you can:
## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/cloud.cfg
## or do the same in user-data
## b.) add sources in /etc/apt/sources.list.d
## c.) make changes to template file /etc/cloud/templates/sources.list.tmpl

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://archive.ubuntu.com/ubuntu bionic main restricted
deb-src http://archive.ubuntu.com/ubuntu bionic main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://archive.ubuntu.com/ubuntu bionic-updates main restricted
deb-src http://archive.ubuntu.com/ubuntu bionic-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu bionic universe
deb-src http://archive.ubuntu.com/ubuntu bionic universe
deb http://archive.ubuntu.com/ubuntu bionic-updates universe
deb-src http://archive.ubuntu.com/ubuntu bionic-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://archive.ubuntu.com/ubuntu bionic multiverse
deb-src http://archive.ubuntu.com/ubuntu bionic multiverse
deb http://archive.ubuntu.com/ubuntu bionic-updates multiverse
deb-src http://archive.ubuntu.com/ubuntu bionic-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse

deb http://security.ubuntu.com/ubuntu bionic-security main restricted
deb-src http://security.ubuntu.com/ubuntu bionic-security main restricted
deb http://security.ubuntu.com/ubuntu bionic-security universe
deb-src http://security.ubuntu.com/ubuntu bionic-security universe
deb http://security.ubuntu.com/ubuntu bionic-security multiverse
deb-src http://security.ubuntu.com/ubuntu bionic-security multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu bionic partner
# deb-src http://archive.canonical.com/ubuntu bionic partner

Ezt követően pedig jöhet a rendszer frissítése:

apt-get update

apt-get upgrade

Ha a frissítések között újabb kernelverziók is láthatók, akkor ezt követheti egy:

apt-get dist-upgrade

apt-get autoremove

majd pedig egy újraindítás:

reboot

Az alapértelmezett rendszerhéj beállítása

Az Ubuntu alapértelmezett rendszerhéja a dash, ám nekünk a bashre lesz szükségünk, ehhez pedig az alábbi parancsot kell kiadni:

dpkg-reconfigure dash
Use dash as the default system shell (/bin/sh)? <-- No

FIGYELEM!

Ennek a lépésnek az elmulasztása esetén az ISPConfig ugyan nem lesz telepíthető, de a rendszer ettől még használható lesz.

Az AppArmor letiltása

Az Ubuntu egyik beépített biztonsági szolgáltatása az AppArmor, ám általában inkább több problémát okoz, mint amennyit segítene a biztonság fokozása terén, ezért érdemes letiltani. Az általa biztosított biztonsági megoldásokat bőven pótoljuk majd a későbbiekben.

service apparmor stop
update-rc.d -f apparmor remove 
apt-get remove apparmor apparmor-utils

FIGYELEM!

Ennek a lépésnek az elmulasztása esetén az ISPConfig ugyan nem lesz telepíthető, de a rendszer ettől még használható lesz.

A rendszeróra szinkronizálása és naprakészen tartása (opcionális)

Minden rendszeren fontos, hogy pontos legyen a rendszeridő, ehhez pedig érdemes telepíteni az ntp nevű csomagot, illetve rendszeres időközönként szinkronizálni az egyik időkiszolgálóval.

apt-get -y install ntp ntpdate

Ezt követően szerkeszteni kell a crontabot, és be kell szúrni az alábbi sort.

nano /etc/crontab 

00 2 * * * root ntpdate time.kfki.hu

Ebben a példában minden nap hajnali 2-kor fut le a szinkronizálás a magyarországi time.kfki.hu szerverrel. Érdemes mindig egy közeli szervert kiválasztani a szinkronizáláshoz. Nemzetközi környezetben a pool.ntp.org használata javasolt.

A postfix, dovecot, mariaDB, rkhunter és binutils telepítése

A postfix telepítéséhez biztosnak kell lennünk abban, hogy nincs telepítve a sendmail:

service sendmail stop; update-rc.d -f sendmail remove

Ha nincs telepítve, az alábbi hibaüzenet jelenik meg:

Failed to stop sendmail.service: Unit sendmail.service not loaded.

Ekkor jöhet a többi csomag telepítése:

apt-get -y install postfix postfix-mysql postfix-doc mariadb-client mariadb-server openssl getmail4 rkhunter binutils dovecot-imapd dovecot-pop3d dovecot-mysql dovecot-sieve dovecot-lmtpd sudo

General type of mail configuration: <-- Internet Site
System mail name: <-- mail.sajatdomain.hu

A mail.sajatdomain.hu helyett egy olyan domainnevet kell megadni, amelyet éles rendszerek esetén aztán majd beállítunk a DNS-ben is. Soha ne olyan nevet adjunk itt meg, amely egyben weboldal címe is lesz, hanem egy technikai nevet, amelyet webes tartalom kiszolgálására biztosan nem használunk.

Ezt követően engedélyezzük a TLS és SASL működését:

nano /etc/postfix/master.cf

Ki kell szedni a megjegyzésből a submission és az smtp alábbi szakaszait, valamint be kell szúrni 1-1 sort is:

[...]
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
[...]

Fontos, hogy a -o előtti szóközök nem hagyhatók le.

Most újraindíthatjuk a szolgáltatást:

service postfix restart

Majd beállítjuk, hogy a MariaDB a kívülről jövő kapcsolatokat is engedélyezze:

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Ehhez megjegyzésbe (#) kell tenni a localhostra (127.0.0.1-re) vonatkozó alábbi sort:

[...]
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address           = 127.0.0.1

[...]

Ezt követően jelszóval kell ellátnunk az adatbáziskiszolgáló root jogosultságú felhasználóját, letiltjuk az anonim felhasználókat, illetve a távoli bejelentkezést root jogosultságokkal:

mysql_secure_installation

Enter current password for root (enter for none): <-- Enter billentyű szöveg beírása nélkül
Set root password? [Y/n] <-- y
New password: <-- A MariaDB root jelszava
Re-enter new password: <-- A jelszó még egyzer
Remove anonymous users? [Y/n] <-- y
Disallow root login remotely? [Y/n] <-- y
Reload privilege tables now? [Y/n] <-- y

Beállítjuk a phpmyadmin használatához a megfelelő azonosítási módot:

echo "update mysql.user set plugin = 'mysql_native_password' where user='root';" | mysql -u root

Majd az előbb beállított jelszót megadjuk a rendszer karbantartási feladatai számára:

nano /etc/mysql/debian.cnf

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = root
password = a_root_felhasználó_jelszava
socket = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = root
password = a_root_felhasználó_jelszava
socket = /var/run/mysqld/mysqld.sock
basedir = /usr

Végül pedig indítsuk újra a szolgáltatást a változtatások életbe léptetéséhez:

service mysql restart

Az amavisd-new, spamassassin és clamav telepítése

A vírusok és a kéretlen levelek kiszűréséhez telepítsük az alábbi csomagokat:

apt-get -y install amavisd-new spamassassin clamav clamav-daemon unzip bzip2 arj nomarch lzop cabextract apt-listchanges libnet-ldap-perl libauthen-sasl-perl clamav-docs daemon libio-string-perl libio-socket-ssl-perl libnet-ident-perl zip libnet-dns-perl libdbd-mysql-perl postgrey

Az ISPConfig használata esetén nincs szükség arra, hogy a spamassassin külön fusson:

service spamassassin stop
update-rc.d -f spamassassin remove

Indítsuk el a clamavot (ha egy hibaüzenet jelenik meg a parancs futtatásakor, azzal most nem kell foglalkoznunk):

freshclam
service clamav-daemon start

Az e-mailek DKIM-aláírásának biztosításához alkalmaznunk kell egy patchet: (Az új ISPConfig (3.2.x) megjelenése óta erre nincs szükség.)

cd /tmp
wget https://git.ispconfig.org/ispconfig/ispconfig3/raw/stable-3.1/helper_scripts/ubuntu-amavisd-new-2.11.patch
cd /usr/sbin
cp -pf amavisd-new amavisd-new_bak
patch < /tmp/ubuntu-amavisd-new-2.11.patch

Az apache, php, phpmyadmin, fcgi, suexec, pear és mcrypt telepítése

A weboldalak kiszolgálásához telepítsük az alábbi csomagokat:

apt-get -y install apache2 apache2-doc apache2-utils libapache2-mod-php php7.2 php7.2-common php7.2-gd php7.2-mysql php7.2-imap phpmyadmin php7.2-cli php7.2-cgi libapache2-mod-fcgid apache2-suexec-pristine php-pear mcrypt  imagemagick libruby libapache2-mod-python php7.2-curl php7.2-intl php7.2-pspell php7.2-recode php7.2-sqlite3 php7.2-tidy php7.2-xmlrpc php7.2-xsl memcached php-memcache php-imagick php-gettext php7.2-zip php7.2-mbstring php-soap php7.2-soap

Web server to reconfigure automatically: <-- apache2 
Configure database for phpmyadmin with dbconfig-common? <-- Yes
MySQL application password for phpmyadmin: <-- Enter billentyű lenyomása szöveg bevitele nélkül

Ezt követően engedélyezzük a szükséges modulokat:

a2enmod suexec rewrite ssl actions include cgi

Majd pedig bebiztosítjuk a kiszolgálót a HTTPOXY-támadásokkal szemben:

nano /etc/apache2/conf-available/httpoxy.conf

Ennek új tartalma ez lesz:

<IfModule mod_headers.c>
    RequestHeader unset Proxy early
</IfModule>

MEGJEGYZÉS

Ez egy viszonylag régi támadástípus, amelyet 2016 közepén fedeztek fel, és a legnagyobb veszélyt a CGI-környezetekben folytatott PHP-s kódfuttatásra jelenti, ám mivel LTS rendszert használunk, így érdemes duplán bebiztosítani magunkat. (További információ: https://httpoxy.org/.)

Majd engedélyezzük a szabályzatot:

a2enconf httpoxy

És ezt követően újraindítjuk a szolgáltatást:

service apache2 restart

A php-apcu telepítése (opcionális)

A PHP-oldalak kiszolgálásának gyorsításához telepítsük az alábbi csomagokat:

apt-get -y install php7.2-opcache php-apcu

Ezt követően újraindítjuk az apache2 szolgáltatást:

service apache2 restart

A php-fpm telepítése

A legtöbb PHP-oldal esetén érdemes a PHP-FPM-et választani, mivel ezt lehet a legjobban optimalizálni a teljesítmény szempontjából Ehhez a következő parancsokat kell futtatnunk:

apt-get -y install php7.2-fpm

a2enmod actions proxy_fcgi alias

MEGJEGYZÉS

A rendszer alapértelmezett verziója a 7.2-es, ami kissé elavultnak számít manapság, viszont mivel LTS rendszert használunk, ezen nem érdemes meglepődni. Amennyiben szeretnénk több verzió (pl.: 7.3, 7.4) futtatását is elérhetővé tenni a rendszeren, erre is lehetőségünk nyílik, de ennek módját egy másik bejegyzésben részletezzük.

Ezt követően újraindítjuk az apache2 szolgáltatást:

service apache2 restart

A hhvm telepítése (opcionális)

A Facebook által létrehozott HipHop Virtual Machine segít felgyorsítani a PHP-kódok futását. A telepítése a következő paranccsal történik:

apt-get -y install hhvm

A mod_evasive telepítése (opcionális)

A mod_evasive segít megakadályozni a szolgáltatásmegtagadásos támadásokat (DoS, DDoS) és a vég nélküli jelszókitalálásos próbálkozásokat, ugyanis korlátozza, hogy egy felhasználó egy adott időintervallumon belül hány oldalt kérhet le. Önmagában nem nyújt elegendő védelmet, azonban tökéletes kiegészítése a fail2ban működésének, mivel az főként csak a hitelesítésre összpontosít.

A telepítése a következő paranccsal történik:

apt-get -y install libapache2-mod-evasive

Ha esetleg rákérdez a telepítő bármire, akkor az alapértelmezett beállítást kell elfogadni. A következő paranccsal lehet ellenőrizni a sikeres telepítését:

apachectl -M | grep evasive

Erre egy ehhez hasonló választ kapunk:

 evasive20_module (shared)

Alapértelmezés szerint a konfiguráció nincs élesen üzembe helyezve, ezért most ezt kell módosítanunk:

nano /etc/apache2/mods-enabled/evasive.conf

Éles üzemben használt szervereken az alábbi értékek használata a javasolt:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10

    DOSEmailNotify      root@mail.sajatdomain.hu
    DOSSystemCommand    "su - someuser -c '/sbin/... %s ...'"
    DOSLogDir           "/var/log/mod_evasive"
</IfModule>

Értelemszerűen a fenti példában lévő root@mail.sajatdomain.hu címet egy saját használatú e-mail-címre kell lecserélni. Ezt követően még létre kell hoznunk a naplózáshoz szükséges mappát, megfelelő jogosultságot kell adnunk annak, majd újra kell indítanunk az apache szolgáltatást:

mkdir /var/log/mod_evasive
chown -R www-data:www-data /var/log/mod_evasive

systemctl restart apache2

A phpmyadmin jelszavas védelme

Bármilyen hihetetlen is, de a phpmyadmin alapértelmezett konfigurációban csak egy olyan jelszavas mezőt tesz elérhetővé, amellyel magához a MySQL szolgáltatáshoz lehet csatlakozni. Ez nem túl biztonságos megoldás, hiszen bárki elkezdhet próbálkozni a jelszavakkal. Szerencsére nem kell túl sok erőfeszítést tennünk ahhoz, hogy az Apache segítségével egy olyan jelszavas bejelentkezést hozzunk létre még ezt megelőzően, amelynél a sikertelen próbálkozásokat már a fail2ban kezeli, így a megadott számú téves próbálkozás után le is tiltja a próbálkozó szellemű támadót.

Ehhez első körben módosítanunk kell az alábbi konfigurációs fájlt, és engedélyeznünk kell a beállítások .htaccess általi módosítását (AllowOverride All):

nano /etc/apache2/conf-available/phpmyadmin.conf

# phpMyAdmin default Apache configuration

Alias /phpmyadmin /usr/share/phpmyadmin

<Directory /usr/share/phpmyadmin>
    Options SymLinksIfOwnerMatch
    DirectoryIndex index.php
    AllowOverride All
[...]

Ezt követően létrehozzuk a bejelentkezést megkövetelő fájl:

nano /usr/share/phpmyadmin/.htaccess

És beleírjuk az alábbi tartalmat:

AuthType Basic
AuthName "Restricted Files"
AuthUserFile /etc/phpmyadmin/.htpasswd
Require valid-user

Majd létrehozunk egy phpmyadmin nevű felhasználót a belépéshez:

htpasswd -c /etc/phpmyadmin/.htpasswd phpmyadmin

Ha további felhasználókat szeretnénk hozzáadni ehhez a fájlhoz, akkor az alábbi parancsot kell használnunk:

htpasswd /etc/phpmyadmin/.htpasswd felhasznalonev

A felhasznalonev helyére az adott felhasználó nevét írjuk. Végül pedig indítsuk újra a szolgáltatást a változtatások életbe léptetéséhez:

systemctl restart apache2

A Let's Encrypt telepítése

Napjaink webhelyei szinte kizárólag HTTPS-kapcsolaton keresztül érhetők el, és az olyan oldalak esetén, amelyeknél ez a feltétel nem teljesül, a böngésző biztonsági értesítést jelenít meg, és egyben nem is tanácsolja annak felkeresését. Régen az ehhez szükséges tanúsítványok csak fizetős verzióban voltak elérhetők (jó drágán), az önaláírt tanúsítványokat pedig szintén nem részesítik előnyben a böngészők. Szerencsére manapság már elérhető a Let's Encrypt, amely ugyan nem veheti fel a versenyt a komolyabb tanúsítványokkal, az alapfunkciókat tökéletesen ellátja, és minden böngésző biztonságosként fogja feltüntetni a nálunk tárolt webhelyeket. És ami a legfontosabb, teszi mindezt teljesen ingyenesen és automatikusan.

Így telepíthetjük:

apt-get -y install certbot

A pureftpd és quota telepítése

A szerverhez engedélyezhetünk FTP-kapcsolatot (és SSH-kapcsolatot is, de utóbbi használatát nehezebb lesz egyes felhasználóinknak elmagyarázni), és természetesen lehetőségünk nyílik arra, hogy elejét vegyük felhasználóink korlátlan terjeszkedésének, azaz mindenkinek beállíthatunk egy kvótát a webes, adatbázisban tárolt és levelezési tartalmak tárhelyhasználatára vonatkozóan.

Elsőként is telepítsük a szükséges csomagokat:

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

Ezt követően ellenőrizzük, hogy standalone módban fut-e a démon, és a felhasználókat bezárja-e a saját könyvtárukba:

nano /etc/default/pure-ftpd-common

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

Mivel a pureftpd alapesetben titkosítatlan kapcsolatokat is engedélyez, itt az ideje, hogy konfiguráljuk hozzá a TLS-kapcsolatokat és létrehozzunk egy (önaláírt) tanúsítványt, mivel nem szeretnénk, hogy a jelszavak sima szövegként utazgassanak az interneten:

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

mkdir -p /etc/ssl/private/

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

Country Name (2 letter code) [AU]: <-- HU
State or Province Name (full name) [Some-State]:<-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []:<-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []:<-- Részleg neve (pl.: informatikai részleg)
Common Name (eg, YOUR name) []:<-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []:<-- A webmester vagy a rendszergazda e-mail-címe

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

Majd indítsuk újra a szolgáltatást:

service pure-ftpd-mysql restart

Ezt követően a kvótarendszer aktiválásához módosítanunk kell a következő fájlt:

nano /etc/fstab

Minden rendszernél más lehet az egyes csatolt fájlrendszerek elnevezése, mindenesetre nekünk a root fájlrendszert kell megkeresnünk, amit a sima perjel ("/") jelöl, és ehhez kell hozzáadnunk a megfelelő plusz paramétereket.

Néhány példa erre:

ext4 fájlrendszer esetén: (,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0)

# /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>
/dev/mapper/server1--vg-root / ext4 errors=remount-ro,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0 0 1
/dev/mapper/server1--vg-swap_1 none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0

Vagy ext4 és UUID használata esetén: (,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0)

UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / ext4 defaults,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0 0 0
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /boot ext4 defaults 0 0
/swap.img       none    swap    sw      0       0

xfs fájlrendszer esetén: (,uquota,gquota)

proc            /proc   proc    defaults        0 0
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / xfs defaults,uquota,gquota 1 1
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX none swap sw 0 0

Ezt követően a módosítások életbe léptetéséhez a következők parancsok kiadására van szükség:

mount -o remount /

quotacheck -avugm
quotaon -avug

FIGYELEM!
xfs fájlrendszer esetén további lépésekre van szükség, ugyanis a kernelben is engedélyezni kell (rootflags=uquota,gquota) a kvótát. Ennek lépéseit lásd alább:

nano /etc/default/grub

[...]
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 net.ifnames=0 rootflags=uquota,gquota"
[...]

grub-mkconfig -o /boot/grub/grub.cfg

A végén pedig újra is kell indítanunk a rendszert a változtatások életbe léptetéséhez, hiszen a kernelt paramétereztük fel a rootflags=uquota,gquota attribútumokkal, így azt is újra be kell tölteni:

reboot

A bind telepítése

A DNS-rendszerünket és -kéréseinket kiszolgáló szolgáltatás a manapság iparági szabványnak tekinthető bind lesz, amelynek kísérőjeként egy véletlenszám-generátort is telepítünk. Ennek lépései:

apt-get -y install bind9 dnsutils haveged

systemctl enable haveged
systemctl start haveged

A vlogger, webalizer és awstats telepítése

A nálunk elhelyezett egyes webhelyekhez statisztikákat is elérhetővé tehetünk, amelyek segítségével jobban nyomon követhető a forgalom, illetve a látogatók statisztikái:

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

nano /etc/cron.d/awstats

Majd itt az összes sort megjegyzésbe kell tenni:

#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

A jailkit telepítése

A jailkit segítségével lehet a saját könyvtárukra korlátozni az SSH-val bejelentkező felhasználókat:

apt-get -y install build-essential autoconf automake1.11 libtool flex bison debhelper binutils

cd /tmp 
wget http://olivier.sessink.nl/jailkit/jailkit-2.19.tar.gz
tar xvfz jailkit-2.19.tar.gz
cd jailkit-2.19
echo 5 > debian/compat

Az így beszerzett forrás buildeléséhez a következő parancsot kell kiadnunk:

./debian/rules binary

Végül pedig telepíthetjük a kész csomagot:

cd ..
dpkg -i jailkit_2.19-1_*.deb
rm -rf jailkit-2.19*

A fail2ban és ufw telepítése

A fail2ban abban segít minket, hogy az egyes szolgáltatások használatakor korlátozza az azonosítási kísérletek számát, így a rosszindulatú támadók nem tudnak egy-egy szolgáltatásnál végtelen alkalommal próbálkozni, amíg ki nem találják a helyes jelszót.

apt-get -y install fail2ban

nano /etc/fail2ban/jail.local

(ez egy újonnan létrehozott fáj, így az alábbi teljes tartalmat bele kell másolni)

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

[dovecot]
enabled = true
filter = dovecot
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,pop3s,imap,imaps", protocol=tcp]
logpath = /var/log/mail.log
maxretry = 5

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 3

[apache]
enabled  = true
port     = http,https
filter   = apache-auth
# logpath  = /var/log/apache*/*error.log
logpath  = /var/log/ispconfig/httpd/*/error.log
findtime = 3600
maxretry = 3
bantime  = 86400

[roundcube]
enabled  = true
port     = http,https
filter   = roundcube
logpath  = /var/log/roundcube/userlogins
maxretry = 5

service fail2ban restart

Az ufw egy alapszintű tűzfal, amely kompatibilis az ISPConfiggal, így annak webes felületén lehet konfigurálni a megnyitni kívánt portokat. Mivel nem túl kifinomult, így általában nem szoktuk használni, hanem saját tűzfalszabályokat szoktunk alkalmazni az adott környezetnek megfelelően, viszont ha valaki csak egy egyszerű környezetben szeretné biztonságosabbá tenni a rendszerét, annak az ufw által nyújtott lehetőségek (az egyes szolgáltatások portjainak engedélyezése vagy letiltása) is elegendőek lehetnek. Akárhogyan is, telepíteni azért érdemes, mert a működése a webes felületről teljes mértékben irányítható (és ki is kapcsolható).

apt-get install ufw

A roundcube webmail telepítése

Levelezésünket ugyan teljes mértékben kezelni tudjuk a különböző levelezőkliensekből, mégis egyes felhasználók előnyben részesítik néha a webes kezelőfelület használatát. Arról nem is beszélve, hogy a spamszűrést és egyéb, a levelezéssel kapcsolatos beállítási lehetőséget csak a webmailen keresztül tudjuk elérhetővé tenni a számukra (ezzel egy külön cikkben foglalkozunk). Ehhez a roundcube-ot hívjuk segítségül:

apt-get -y install roundcube roundcube-core roundcube-mysql roundcube-plugins javascript-common libjs-jquery-mousewheel php-net-sieve tinymce

Configure database for roundcube with dbconfig-common? <-- Yes
MySQL application password for roundcube: <-- Enter billentyű szöveg beírása nélkül

nano /etc/apache2/conf-enabled/roundcube.conf

Itt engedélyeznünk kell a roundcube aliasait (az egyiknél csak a megjegyzést kell eltávolítani, a másikat újonnan kell beírni), illetve engedélyezni kell a .php kiterjesztést is.

# Those aliases do not work properly with several hosts on your apache server
# Uncomment them to use it or adapt them to your configuration
    Alias /roundcube /var/lib/roundcube
    Alias /webmail /var/lib/roundcube

<Directory /var/lib/roundcube/>
  AddType application/x-httpd-php .php
  Options +FollowSymLinks
  # This is needed to parse /var/lib/roundcube/.htaccess. See its
  # content before setting AllowOverride to None.
  AllowOverride All
[...]

Majd újraindítjuk a szolgáltatást:

service apache2 restart

Végül pedig csak a helyi gép levelezéséhez engedélyezzük a csatlakozást:

nano /etc/roundcube/config.inc.php

[...]
$config['default_host'] = 'localhost';
[...]

Az ISPconfig telepítése

A legújabb verzió a következő parancsokkal telepíthető:

cd /tmp 
wget -O ispconfig.tar.gz https://git.ispconfig.org/ispconfig/ispconfig3/repository/archive.tar.gz?ref=stable-3.1
tar xfz ispconfig.tar.gz
cd ispconfig3*/install/

php -q install.php

A telepítő gyakorlatilag minden szolgáltatást konfigurál nekünk, csupán néhány kérdésre kell választ adnunk.

FONTOS!
Az alábbiakban a főkiszolgáló (master) beállításait tüntetjük fel. Többkiszolgálós környezetben a többi szerver telepítésénél más beállításokat kell kiválasztani!

--------------------------------------------------------------------------------

>> Initial configuration
Operating System: Ubuntu 18.04 (Bionic Beaver)
Following will be a few questions for primary configuration so be careful.
Default values are in [brackets] and can be accepted with <enter>.
Tap in "quit" (without the quotes) to stop the installer.

Select language (en,de) [en]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Installation mode (standard,expert) [standard]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Full qualified hostname (FQDN) of the server, eg server1.domain.tld [mail.sajatdomain.hu]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL server hostname [localhost]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL server port [3306]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL root username [root]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL root password []: <-- A MySQL-nél megadott rootjelszó
MySQL database to create [dbispconfig]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL charset [utf8]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Configuring Postgrey
Configuring Postfix
Generating a 4096 bit RSA private key
.......................................................................++
........................................................................................................................................++
writing new private key to 'smtpd.key'
-----
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]: <-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) []: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy a rendszergazda e-mail-címe
Configuring Mailman
Configuring Dovecot
Configuring Spamassassin
Configuring Amavisd
Configuring Getmail
Configuring BIND
Configuring Jailkit
Configuring Pureftpd
Configuring Apache
Configuring vlogger
Configuring Metronome XMPP Server
writing new private key to 'localhost.key'
-----
Country Name (2 letter code) [AU]: <-- HU
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) [server1.canomi.com]: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy a rendszergazda e-mail-címe
Configuring Ubuntu Firewall
Configuring Fail2ban
[INFO] service OpenVZ not detected
Configuring Apps vhost
Installing ISPConfig
ISPConfig Port [8080]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Admin password [admin]: <-- Enter billentyű lenyomása szöveg bevitele nélkül (a jelszót a webes felületen érdemes módosítani, az első bejelentkezés után)
Do you want a secure (SSL) connection to the ISPConfig web interface (y,n) [y]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Generating RSA private key, 4096 bit long modulus
.......................++
................................................................................................................................++
e is 65537 (0x10001)
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]: <-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) []: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy rendszergazda e-mail-címe
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: <-- Enter billentyű lenyomása szöveg bevitele nélkül
An optional company name []: <-- Enter billentyű lenyomása szöveg bevitele nélkül
writing RSA key

Configuring DBServer
Installing ISPConfig crontab
no crontab for root
no crontab for getmail
Detect IP addresses
Restarting services ...
Installation completed.

Ezt követően pedig a 8080-as porton máris be tudunk jelentkezni az ISPConfigba. A felhasználónév és a jelszó azonos (admin), ám a jelszót az első bejelentkezés után erősen javasolt megváltoztatni!

https://mail.sajatdomain.hu:8080

E-mailes értesítés az SSH-bejelentkezésekről

Egy nyilvános szerver esetén érdemes minden óvintézkedést megtenni annak érdekében, hogy minden furcsa eseményről értesüljünk. A parancssori (SSH-) bejelentkezés egy kiemelten kritikus pontja a rendszerünknek, még akkor is, ha a korábbi lépéseket követve mindenkit bezártunk a saját könyvtárába. Az események nyomon követését segíti, ha e-mailes értesítést kapunk az SSH-s bejelentkezésekről. Ehhez először is hozzuk létre a figyelést végző szkriptet:

nano /usr/sbin/user-monitor.pl

#!/usr/bin/perl
# user_monitor.pl v0.4 :: keep track on who's logged in
# Written by Stephan Schmieder - http://www.unix-geek.info, 2003
# Usage: ./user-monitor.pl&

use strict;
use warnings;
use diagnostics;
use Net::SMTP;

#configuration
my $server =`uname -a|cut -d" " -f2`;
my $smtp_server ='localhost';
my $mail_to     ='root@mail.sajatdomain.hu';
my $mail_from   ='root@' . $server;
my $subject     ="$server :: User login monitor";
#configuration

my @old_users=split(/\n/, qx/who/);
while(sleep(60))
{
        my @users=split(/\n/, qx/who/);
        if(@users ne @old_users)
        {
                my $smtp = Net::SMTP->new($smtp_server);
                die "Couldn't connect to server" unless $smtp;
                $smtp->mail( $mail_from );
                $smtp->to( $mail_to );
                $smtp->data();
                $smtp->datasend("Subject: $subject\n\n");
                foreach my $user (@users)
                {
                        $smtp->datasend("$user\n");
                }
                $smtp->dataend();
                $smtp->quit();
        }
        @old_users=@users;
}

A root@mail.sajatdomain.hu helyére azt az e-mail-címet írjuk, ahová az értesítéseket kérjük.

FONTOS!
A szkript a rendszer saját postfix szolgáltatását használja a kimenő levelekhez, és elég kevés információt tesz bele a levélbe, ezért könnyen lehet, hogy az olyan nagyobb rendszerek, mint a gmail, levélszemétként észlelik az így küldött üzeneteket. Érdemes engedélyezési listára (whitelist) tenni a feladót, de a fenti szkriptet át is lehet írni igény szerint (akár egy külső SMTP-szolgáltatás, például a Postmark használatára).

Ezután módosítjuk a futtatási engedélyeket:

chmod 755 /usr/sbin/user-monitor.pl

Ahhoz, hogy a szkript minden rendszerindításkor elinduljon a háttérben, felvesszük a crontab bejegyzései közé a következő sor beszúrásával:

nano /etc/crontab

@reboot root    /usr/sbin/./user-monitor.pl&

Most pedig elindítjuk kézzel:

/usr/sbin/./user-monitor.pl&

A sikeres indítást követően meg kell jelennie a futó folyamatok listájában:

ps aux | grep monitor.pl

root      1026  0.0  0.2  59548 11380 ?        S    Aug09   0:22 /usr/bin/perl /usr/sbin/./user-monitor.pl

Összegzés

A fenti lépéseket követve egy biztonságos, éles üzemben is használható LAMP-kiszolgálót kapunk, amely ráadásul egy webes kezelőfelületen keresztül menedzselhető. Akár késznek is nyilváníthatjuk, ha az alapfunkciókon felül különösebb igényeink nincsenek, de alapul is szolgálhat a további testreszabásokhoz.