[Megoldva] Netre kitett Debian server megvédése

Fórumok

Sziasztok,

Fejlesztő vagyok, felhasználói szinten elboldogulok a linux-al, de nincs rendszergazda tapasztalatom.
Egy applikációt készítek, amelyhez szükségem van egy VPS beüzemelésére, ami Debian szerveren LAMP weboldalt (port 443) és egy hozzá tartozó REST Api-t szolgál ki.
Ezen kívül egy másik porton (9000) egy saját Go webszerver válaszolna szintén https kérésekre.

Az lenne a kérdésem, hogy milyen lépéseket tegyek, hogy ne váljon rövid időn belül átjáróházzá ez a szerver?
Elég lehet a rendszeres szoftver frissítés és iptablesben minden port letiltása (a két service által használt, valamint a bejutáshoz szükséges ssh porton kívül)?

Fontos lenne, hogy megmaradjon a VPS jó performanciája (1-3ezer lekérés / sec).

Köszönöm a válaszokat!

Szerk: köszönöm szépen a válaszokat! :) Elég jó kis wiki oldal gyűlt itt össze :)

Hozzászólások

Az ssh portot változtasd meg (nem muszáj a 22-n lennie).
A fail2ban használatát is javasolnám.

Frissítsd a rendszert gyakran.

Az ssh portot változtasd meg (nem muszáj a 22-n lennie).

Vagy látszatmegoldások helyett tiltsad le a jelszavas ssh belépést, és csak kulccsal engedd!

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Igen, a költő arra gondolt, hogy ha jelszavas belépés engedélyezett, akkor a 22-es portról máshová tenni meg failtoban az csak önmagunk megnyugtatása, nem lesz tőle biztonságos a rendszer.

Ha jelszóval nem lehet belépni, csak kulccsal, akkor nyugodtan maradhat 22-n, meg fail2ban se kell, a támadó belépni úgyse tud, csak néhány sort generál a logba.

Csodálkozom, hogy amit korábban írtam, az nem volt egyértelmű, de akkor majd most:

/etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
HostbasedAuthentication no

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ha jelszóval nem lehet belépni, csak kulccsal, akkor nyugodtan maradhat 22-n, meg fail2ban se kell, a támadó belépni úgyse tud, csak néhány sort generál a logba.

Ha jelszóval be lehet lépni és erős jelszód van, akkor mennyi a kockázata? És mennyiben segít az eltolt port és a fail2ban, ha elsőre "kitalálják" a jelszavad?

Azt szokták erre mondani, hogy erős jelszó is elbukik egy keyloggeren. Persze ha egy gépen a támadó már keyloggert tudott telepíteni az már réten rossz és akkor kulcsokhoz ugyanúgy hozzáférhet. A gyakorlatban a netkávézók aranykorában volt valódi kockázat az, hogy kissé felelőtlenül publikus számítógépekről ssh-tak be szerverekre, és abban a szituban valóban nem kellett nagy black hat tudás ahhoz, hogy keyloggert rakjon valaki a netkávézós gépekre. 

Másik érv az erős jelszó ellen az, hogy nem korlátlan egy ember memóriája, ezért kénytelen több szerverhez használni ugyanazt a bonyolult jelszót. Így ha egyik szerver bonyolult jelszava valahogy kitudódik, akkor onnantól ugyanazzal a jelszóval elérhetővé válik a többi szerver is. 

Ma, kizárólag saját eszközöket használva már szerintem teljesen jó az erős jelszó is, főleg ha tartozik hozzá valami gépenként egyedi jelszórész valami fejben működő "algoritmussal". Ez még jobb is lehet a kulcsnál, mert nem eszközhöz hanem emberhez kötődik. Ha  ellopják vagy otthon marad a gép, akkor sincs probléma. 

Ez még jobb is lehet a kulcsnál, mert nem eszközhöz hanem emberhez kötődik.

Biztonságilag ezért jobb a jelszavas kulcs, mert az eszközhöz ÉS emberhez IS kötődik.

Az ellopás/otthonmaradás egy másik téma, ha a biztonságosságra törekszünk, akkor ne gyengítsük már direkt a dolgokat azért, mert hátha otthon maradt a kulcs a jelszót meg épp elfelejtette de azért engedjük be mégis...

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

A jelszavas kulcs problémája a ló másik oldalára esés. Az sem tud belépni a végén akinek kellene. Épp újraindulnak a repülőjáratok, de még most is élnek a notebooktilalmi korlátozások sok célországnál terrorveszély miatt. Ez csak egy példa volt arra, hogy nem lehet vinni saját notebookot sem. Természetesen nem azt állítom, hogy rossz a jelszavas kulcs megoldás. Csak annyit állítok, hogy erős jelszónak is vannak előnyei, ha felelős (okos) emberek helyesen használják. Mugliknál valóban nem túl szerencsés mert másnap elfelejti és új jelszónak valami könnyen törhető szimpla jelszót fog utána beállítani. 

Az ésszerű vagy a központi azonosító rendszer használata lenne - például o2auth technológiával - vagy a kulcsos belépés. Az, ami most van, az teljesen fenntarthatatlan. Az összes szolgáltató jelszót regisztráltat. Ha valóban mind különböző, akkor képtelenség fejben tartani. Ha viszont ugyanazt adod meg mindenütt, akkor nem biztonságos. Nekem csakis a jelszókezelő működik. Pedig nem érzem magam muglinak, ha egy jelszót párszor beírok, akkor már rögzül is, pedig generáltakat használok. De így is csak a legfontosabb néhányat jegyzem meg fejből. Végigpörgettem, van vagy 100 bejegyzés a jelszókezelőmben. Ezek egy jórésze persze fiszfasz hülyeség, amire lehet bármikor új jelszót kérni emailen (ami LOLkategóriás védelmet jelent, ha belegondoltok, és valóban előfordultak már ezen keresztül törések...). De akkor is néha használni kell őket.

Ezzel szemben ha ssh kulccsal azonosíthatnám magam, vagy központi belépéssel, akkor töredéke jelszó elegendő volna. Erre kellene mozdulni a netnek, de nem látok törekvést rá.

A különböző jelszavak problémájára írtam korábban, hogy lehet szerverekhez kötődő egyedi jelszórészleteket használni, fejben is "működő algoritmussal". Olyanra gondolok, hogy van egy kemény jelszavad fejben és annak elejére, végére vagy közepére kapcsolsz például a szerver nevéből számított jelszórészt. Mondjuk a név karaktereit kettes blokkokra osztod, összeszorzod az két ascii kódot majd csinálsz egy modulo osztást, esetleg az így keletkezett számot visszakonvertálod karakterré permutációval. Erre tudsz írni magadnak mobilra appot, hogy könnyebb legyen számolni. De ha nincs nálad a mobilod akkor is ki tudod papíron számolni. Ez már elég biztonságos, ha az egyik szerver jelszava rossz kézbe kerülne ránézésre nem tudják kitalálni. Ha plaintext van ott a közepén a gépnév akkor azért rájöhetnek arra mit kell módosítani a jelszón, hogy a másik szerveren be tudjanak lépni. 

És mennyiben segít az eltolt port

Annyiban biztos, hogy nem lesz tele szeméttel az auth log és ha gond van akkor jobban átlátható / kereshető.

meg fail2ban se kell

nem csak ssh log van egy szerveren, sok minden mást is lehet figyeltetni a fail2bannal

csak néhány sort generál a logba

szerintem a néhány sor van hogy = több ezer sor / nap

elsőre "kitalálják" a jelszavad

ha "12345" meg "password" jelszavakat használsz, akkor ne csodálkozz ;) inkább generálj vmi hosszút és kulccsal lépj be

Meg lehet olyan egyéni trükköket is készíteni unalmas órákban, hogy más porton van az éles ssh még 22-es porton egy kamu ssh van, amely alap esetben feljegyzi a kapcsolódni próbáló gép ip címét. Ha az szervezeten kívüli ip tartomány akkor pár napra ban-ra rakja. Esetleg beengedi egy 22-esen egy honeypot szerverre és feljegyez minden tevékenységet. Sőt lehet pár malwares csalit is rakni arra a honeypot szerverre amivel utána a támadó gépén lehet átvenni a kontrollt. 

Annyiban biztos, hogy nem lesz tele szeméttel az auth log és ha gond van akkor jobban átlátható / kereshető.

Ja, csak nem az volt az OP problémája, hogy nem tud beállítani logrotate-et meg nem tudja a grep-et használni, hanem biztonságot szeretne.

Másik portra tenni az ssh-t, az biztonságot nem ad.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Gyanús, hogy ez vallási kérdés :) Szerintem is jobb máshova rakni... azért kényelmi szempontból is egy zenmap intense scan sokkal hosszabb, ha minden portot szeretne tesztelni a támadó. Nyilván az ellen nem véd, aki pont téged akar megtámadni... kicsit olyan ez, mint a váltózár... ha valaki el akarja lopni a kocsid, akkor ellopja... de ha látja, hogy a tiedet nehezebb ellopni, mint a mellette lévőt, akkor a másikat fogja ellopni.

...de a DDOS is pont erről szól, nem? Hogy hiába utasítasz el egy kérést, az neked energiába kerül. Minek terhelni ezzel pluszba akármelyik szervert? ...és amúgy is mi lesz a jegesmedvékkel? :)

Nem azt mondom, hogy ne rakja máshová, ha akarja.

Azt mondom, hogy máshová rakástól nem lesz biztonságosabb. Security by Obscurity nem működik. Ha biztonságos, akkor meg teljesen mindegy, hogy 22-es porton figyel-e vagy máshol, így se, úgy se lehet felnyomni.

Ha megcsináltad biztonságosra és utána el szeretnéd valahová dugni, hát csináld nyugodtan. Én csak azt nem szeretném, hogy valaki azt képzelje, hogy elraktam a 22-es portról a 2222-re, akkor mostantól biztonságban vagyok, és továbbra is beléphetek a root userrel jelszavas azonosítással, miközben a jelszavam az, hogy secret.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Érdekes, hogy port knocking még nem hangzott el.

Én inkább azon csodálkozom, hogy a legtöbben az SSH-val foglalkoznak, holott - szerintem (ha pár szabályt betartasz) - ott a legkisebb az esélye, hogy bejut valaki.

Egy HTTP szolgáltatás szerintem sérülékenyebb, könnyebb hibázni. De ez persze csak magánvélemény :).

Jogos. Ott van maga a webszerver, a nyelv esetleges implementációs hibái, maga a weblap kódjában a hibák, mögötte az esetleges adatbázis hibái, stb.

Á szerintem zárjuk be az egészet. :)

Egyébként ezért mondtam korábban, hogy ha csak kevés user van, akkor a webes szolgáltatás menjen kliens certificate-tel. De legalább https és basic auth (random usernevek, erős jelszó amit az admin oszt, jelszavak hetente változnak, de pl. apache összeköthető google auth-tal és tádám!).

Egyébként ezért mondtam korábban, hogy ha csak kevés user van, akkor a webes szolgáltatás menjen kliens certificate-tel. De legalább https és basic auth (random usernevek, erős jelszó amit az admin oszt, jelszavak hetente változnak, de pl. apache összeköthető google auth-tal és tádám!).

Nagy általánosságban a webszerver a nagyközönségnek szól, ahol ezek nem jönnek szóba és mégse törik halomra naponta a szolgáltatókat.

Már miért ne működne? Nyilván nem a port knock meg a 41245 port fogja megvédeni a rendszert, de sokkal kevesebb támadás fogja érni.

Ez tény, kár rajta vitatkozni. Mikor elraktam a 22-ről az ssh portot, utána kb. két hónapig egyetlen gyanús kísérletet sem láttam (utána nem néztem), előtte pedig naponta ~100-as nagyságrendben.

Célzott támadást meg nagyon nehéz kivédeni, de az sem feltétlenül az ssh-n múlik. Ha valaki tudja miért megy be, a hogyant is meg fogja találni. Viszont ez csak az esetek elenyésző hányada.

Mit írtam? "nem ez fogja megvédeni a rendszert". Tessék értelmezni.

Azt felejtitek el mindig, hogy a Security by Obscurity az nem Security ONLY BY Obscurity :D Ettől még nyilván a többi intézkedést is meg kell tenni.

De itt egy példa: kijön egy új exploit, még nincs rá javítás. Na ekkor nem mindegy, hogy a gépedet mennyi támadás éri. Ez ellen pedig segít, ezért nem hagyom az ssh-t a 22-n.

Szerkesztve: 2020. 07. 30., cs - 18:38

Az lenne a kérdésem, hogy milyen lépéseket tegyek, hogy ne váljon rövid időn belül átjáróházzá ez a szerver?

Iratkozz fel a használt rendszer security értesítőire, ettől függetlenül frissíts rendszeresen, minden más csak placebo vagy security by obscurity és főképp üzemeltetési kockázat.

Fontos lenne, hogy megmaradjon a VPS jó performanciája (1-3ezer lekérés / sec).

Ha DDoS támadnak, akkor úgyis mindegy, amúgy nem szokták támadni, csak próbálkoznak 100-150 faék SSH név:jelszó párossal, meg keresnek HTTP/HTTPS-en néhány ismert sebezhetőségű törhető leginkább PHP-s dolgot.

Mondjuk szopatásképp én csináltam redirect a népszerű puhatolózásokra: https://iotguru.cloud/wp-login.php

> Mondjuk szopatásképp én csináltam redirect a népszerű puhatolózásokra: https://iotguru.cloud/wp-login.php

Ja, pontosan a következőket szopatod:

- a zombi gépet, ahol a bot fut és úgyse látja senki a redirect eredményét

- a youtube-ot a felesleges kapcsolattal

- a saját szerveredet

- meg persze a hálózatot

 

Miért nem jó egy fail2ban 5-10 napra? Az én szerveremen sehol nincs WP, ha vki rápróbál WP-s oldalra akkor a tűzfal lezárja az összes portot az adott kliens felől és kész.

Szerkesztve: 2020. 07. 30., cs - 18:57

Ha a LAMP-ban a P nem PHP hanem Python már sokkal biztonságosabb. Az sem baj ha az Apache helyett Nginx van. Bár ez szokott lenni a kisebbik probléma. Ha már kész rendszerről van szó amit sok munka lenne átírni, persze marad a hozott anyag. 
Ha mindenképp Apache van és a felhasználás módja ezt lehetővé teszi még ma is érdemes használni az old school .htaccess fájlokat a hozzáférés korlátozására. Így ha van is pl PHP sebezhetőség át sem jutva a htaccess-en nem tudják kihasználni. 

Ez nemcsak magán a programnyelven múlik, hanem a mögötte levő kerettrendszeren. Ebből a PHP egy hírhedten lyukas ementáli sajt volt. A Facebook utóbbi években elég sok pénzt nyomott, hogy biztonságosabbá tegyék. Szóval ma már lehet nem akkora a különbség. A Python hagyományosan biztonságosabb választás volt. 

webszervert, amit bárhonnan el kell érni hogy szoktak biztonságossá tenni? hasonló metodikával, sűrű frissítés? Varázsszer nincsen.

A jotanacsokhoz meg hozzaraknek egy ipset-alapu blacklistet, amit kulonbozo listakbol, illetve a szerveredet ero probalkozasokbol allitasz ossze.

Cloudflare vagy hasonló szolgáltatásokat nyújtó konkurensek használata javíthat a webszolgáltatás biztonságán.

Szerkesztve: 2020. 07. 30., cs - 21:36

AWS Beanstalk? (igaz, ha nincs aws ismeret, akkor át kell rágni egy csomó dolgot majd). A biztonság sok tekintetben gyárilag adott lesz (kezdésnek ott, hogy a gép egy private vpc subnetben, és nem az Interneten csücsül majd).

Akkor még pár dolog:

  • Érdemes feltenni még az unattended-upgrades csomagot, ezzel a fontosabb security frissítéseket automatizáltan és rendszeresen felteszi. Ettől még a többit neked kell rendszeresen frissíteni, de a kritikusabb dolgok gyorsan és maguktól frissülnek
  • fail2ban, amiben ha semmi mást nem csinálsz, mint bekapcsolod az elérhető szolgáltatásaidra vonatkozó filtereket (apache-*, php-*, ssh*, stb), akkor ez is nagyon sok próbálkozót meg tud fogni... Csak ne felejtsd el mindenek előtt ignoreip -nek megadni a saját IP címedet :) Ha nem túl hosszú időszakot monitorozol és nagyon sok időre tiltasz (akár örökre is), akkor nem annyira erőforrásigényes, mint elsőre gondolnád.
  • ssh-n kikapcsolni a jelszavas authentikációt, kizárólag kulcs alapú belépést engedni. 

http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

" Érdemes feltenni még az unattended-upgrades csomagot, ezzel a fontosabb security frissítéseket automatizáltan és rendszeresen felteszi. " - Kivéve, ha valami Java-s cuccod van, mert nekem már rottyantott mag alá wildfly, amikor a buguntu úgy gondolta, hogy ő mostan frissít egy openjdk-t... De ugyanígy lehet szolgáltatáskiesés/megállás más komponensek automatikus frissítése esetén is.

És hogy hozzárakjak valami pluszt, javasolnám a google authenticator használatát: ssh-kulcs plusz GA (tartalék/vészkulcsok papíron elrakni), a fail2ban és a geoip-s szűrés mellé.

De ugyanígy lehet szolgáltatáskiesés/megállás más komponensek automatikus frissítése esetén is.

Pontosan. Elég ha csak leszedi a frissítéseket, és mail-t küld róla. Te meg eldöntöd hogy mit frissítesz, és mit nem.

Vagy van a másik irány, hogy apt-ben visszatartasz olyan frissítéseket amik tudottan árthatnak (pl openjdk), a többit meg hagyod autómatikusan frissülni. Ebben is van kockázat, de kissebb.

Mondom ezt üzemeltetőként. Te sajád bevallásod szerint nem vagy az. Hogy neked ehhez, és a többi hozzászólásban írtakhoz (amik jórészt szintén jó dolgok) mennyire lesz türelmed, azt nem tudom.

Attól tartok párszor lerúgod majd a monitorodat. :)

"A megoldásra kell koncentrálni nem a problémára."

Amikor fejlesztő rak össze gépet, mert "csak", és az megy szerencsére "csak" UAT-ba, és utána nekem kell kitalálni, hogy a lomja (ami adott jdk-val megy, egy követlezővel meg nem) miért hasalt el, és kiderül(t), hogy az autoupdate default bekapcsolt bála, "mertazjó", akkor az üzemeltetői énem kellőképp haragosan tud gondolni egyrészt a fejlesztő felmenőire, másrészt meg a csomag karbantartójára, hogy sikeresen betolt valami inkompatibilitást az adott verzóba.
A kritikus komponensek "természtesen" apt-mark hold, a rendszeres frissítések idején ha ilyenre jelez, hogy kéne frissíteni, akkor changelog, tesztkörnyezetben frissít/tesztel, mentést csinál, frissít, és ha jó akkor megyünk tovább - ismét hold-ba rakott -mondjuk- openjdk-val.

Igaz. De a topicnyitó a saját vps-éről beszél, amivel azt nem csinál amit nem akar.

Megjegyzem, én is úgy vagyok vele, hogy ha valaki (bármely nem üzemeltető mugli, de üzemeltetőkből is a legtöbben) be akarná hozni az általam üzemeltetett rendszerbe a saját tákolt VM-jét, komolyan felmerülne bennem a tettlegesség.

És ha még az életemet is megkeserítené, és nekem kéne utána lapátolni a szart, akkor ez a tettlegesség túljutna a gondolati síkon, és konkrét veszélyt jelentene az illetőre. :)

Szerencsére nálunk ilyen veszély nincs. Az üzemeltetők üzemeltetnek, a programozók programoznak.

"A megoldásra kell koncentrálni nem a problémára."

Sokat fogok írni, de ne ijedj meg, kicsit magamnak is írom :)
- ssh másik porton legyen (bár idővel megtalálhatják)
- ssh AllowUsers [felsorolás kik léphetnek be ssh-val]
- fail2ban és ha nem félsz hogy kizárod magad (mert másik IP-ről is be tudsz lépni), akkor a bantime legyen nagyobb és a maxretry meg kisebb
- php beállítások alapos átnézése (szerintem ez az egyik gyenge pont, pl. open_basedir, form POST, file upload)
- composer outdated ellenőrzés és npm audit (ezek a másik gyenge pontok, a sok külső csomag)
- VPN kiépítése és akkor ssh-zni csak a belső IP-ről engeded
- Apache és Nginx javasolt biztonsági beállítások (rá kell keresni a neten)
- HTTPS használata (bár ezt írtad is)
- a nem használt szolgáltatásokat állítsd le (pl. FTP, SMTP, POP3, IMAP)
- levelek küldését ne a szerverről intézd, használj külső SMTP szervert (pl. mailgun)
- tűzfal használata
- erős jelszavak vagy SSH kulcs használata javasolt
- docker / konténer környezet (így ha bejut mondjuk a PHP-n keresztül, akkor a VPS rendszerét nem igazán / nehezen fogja elérni)
- logwatch beállítása és a kapott levelek időszakos átnézése
- security frissítések telepítése minél hamarabb
- ja és a saját kódod tesztelése :), API végpontok vizsgálatára is vannak szolgáltatók
- a fail2ban-ban egyedileg figyelem a wp-login, wp-content próbálkozásokat és mivel tudom hogy nincs WP oldalam, letiltom ezeket az IP-ket is

+1

általánosságok (bocs, ha túl általános):

- ami nem kell ne fusson pl. phpadmin

- elvek: mindent tiltsunk le és csak ami kell azt kell engedélyezni pl. portok.

- ne az alkalmazással kapott konfigot használjuk, írjunk újat és jó ha tudjuk melyik sort mit csinál..

- ssh-t ne minden honnét, csak egy IP-ről engedjünk be.

- nem lehetsz eléggé paranoid - használd rkhunter -t 

Nem vagyok meggyőzve (de meggyőzhető vagyok), hogy az ssh over vpn mennyivel biztonságosabb, mint a sima ssh csak public key auth-al.

Tény hogy az ssh portot rengeteg támadás éri, de ha ezt az ember elteszi, nagyságrendekkel csökken a próbálkozások száma. Nálam az iptables-ben van egy limit, hogy egy percenként egyszer enged új kapcsolatot nyitni az ssh portra (egy 5-ös burst után, és a port nem a 22).

kiegészítve a fenti listámat bedobok ide pár sort, hogy milyen próbálkozások vannak a feltörésekre
újabban a phpunit-ot kezdték el keresni, gondolom valamelyik verzióban van valami rés
modern PHP framework használata esetén általában nem érhető el kintről a phpunit, de van hogy "ügyesek" a fejlesztők
nginx-ben lehetne egyből 404-re tenni ezeket, de talán jobb ha a fail2ban-ban csinálsz rá jail-t, mert akkor az összes többi próbálkozását is visszafogod egy időre

       /admin.sql: 1 Time(s)
       /admin/.env: 1 Time(s)
       /admin/ckeditor/plugins/ajaxplorer/phpunit ... /eval-stdin.php: 1 Time(s)
       /admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php: 1 Time(s)
       /api/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php: 1 Time(s)
       /api1/vendor/phpunit/phpunit/src/Util/PHP/ ... /eval-stdin.php: 1 Time(s)
       /api2/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php: 1 Time(s)
       /api5/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php: 1 Time(s)
       /api_source/firebase/vendor/phpunit/phpuni ... /eval-stdin.php: 1 Time(s)
       /api_source/webservice/firebase/vendor/php ... /eval-stdin.php: 1 Time(s)
       /apimotor/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php: 1 Time(s)
       /app/.env: 1 Time(s)
       /app/.git/config: 1 Time(s)
       /app/.hg/requires: 1 Time(s)
       /app/.svn/entries: 1 Time(s)
       /app/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php: 1 Time(s)
       /application/.env: 1 Time(s)
       /apps/.env: 1 Time(s)
       /appserv.php: 1 Time(s)
       /assets/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php: 1 Time(s)
       /auth/.env: 1 Time(s)
       /auth/saml/extlib/simplesamlphp/vendor/php ... /eval-stdin.php: 1 Time(s)
       /authenticate/vendor/phpunit/phpunit/src/U ... /eval-stdin.php: 1 Time(s)
       /b.php: 1 Time(s)

A konfig kódból legyen előállítható, az adatokat sűrűn mentsd off-site. 

Ha nem kritikus szolgáltatás, akkor az előttem szólók listái jó alap. Ha kritikus, keress fedő szolgáltatást mint a fent említett cloudflare. Ekkor ők védik a publikus részt,a menedzsmentet meg le tudod tűzfalazni, hogy csak fix ip-ről menjen. Ha még kritikusabb, akkor keress egy pentesztert, megmondja hol van még rajta lyuk.

Frissíteni 2 hetente, és legyen terved a gyors helyreállításra.

A 10-es Debianban alapértelmezetten be van kapcsolva az AppArmor, az apache-nak van hozzá modulja (libapache2-mod-apparmor), vhostonként tudod szabályozni, hogy mely fájlokhoz hogy férjen hozzá. Így ha az alkalmazásnak nem kell shell, Python, Perl, akármi... azokat nem kell felvenni ehhez a listához. Sok kellemetlenségtől meg tudod kímélni magad.

Ha van bármilyen mail küldés, lehetőleg lokális MTA-n keresztül küldd (ha van/kell smarthost, ott állítsd be azt is). IPtables-ben meg tudod adni, hogy csak az MTA küldhessen e-mailt, az MTA-ban pedig tudsz szűrni címzettre, feladóra, esetleg küldési quota limitet állítasz be.

Fail2ban-t írták sokan, érdemes beállítani a log figyelését az alkalmazás logjára (ha van), pl sikertelen belépések után bannolni az IP-t. De az error.log-ból is sok hasznos infót gyűjthetsz: wp-login.php, phpmyadmin és hasonló próbálkozások, amikről tudod, hogy nincsenek, gyak, azonnal bannolható.

A jelen helyzetben a szükségtelen kiszolgálók eltávolítása (pl. MTA), portok letiltása, a szükségesek engedélyezése, Fail2Ban. Mivel VPS-en fejlesztesz, nagyon nem kell aggódnod a DDoS miatt, egy tisztességes VPS szolgáltató megteszi helyetted és gondoskodik a géped védelméről. (A gugli segít ilyet találni, nagyon nem kell messzire menni.)

Szerkesztve: 2020. 07. 31., p - 12:50

Ahogy én csináltam - szintén zenész, azaz programozó vagyok üzemeltetői tapasztalat nélkül - játszós cuccal:

 * nginx fogadja a bejövő kéréseket, de ezen valódi tartalom kiszolgálás nincsen, hanem csak átirányítások.

 * nginx auth request module be van állítva: http://nginx.org/en/docs/http/ngx_http_auth_request_module.htm Úgy van bekonfigurálva, hogy egy http szerver processznek csak az authentikáció a dolga. Ez lesz tehát kitéve csak a jöttmentek piszkálódásának.

 ** Az autentikátor O2auth protokoll szerint authentikál gulág usereket. (Ugyanez összerakható github userekkel is és van több ilyen szolgáltató, vagy persze saját user kezelést is írhatnánk, de így legalább jelszavakat egyáltalán nem kell kezelni.)

 ** Az authentikált email címhez vannak rendelve a jogok és csoportok. Az autentikátor a path alapján eldönti, hogy az adott user az adott querire kaphat-e érdemi választ. Amennyiben az autentikátor nem engedi át, akkor a valódi kiszolgáló processzig el sem jut a kérés. Így akrámilyen lyukas szart is mögé tehetnék elvileg (persze nem teszek, csupa minőségi holmit hosztolok csak :-), csak a saját autentikált usereim támadhatnák.

 ** Az authentikált usert és annak a csoportjait az autentikátor átadja az alkalmazásnak, így az finomabb léptékben is kezelheti, hogy kinek mit szabad csinálni. De akinek semmit sem szabad, az oda sem érhet.

 ** Authentikálatlan query a login oldalra irányítódik át.

 * Az nginx a már authentikált queryket passzolgatja a valódi kiszolgálók felé.

Előnyök:

 * Egyetlen ssl certet elegendő beállítani, maguk a kiszolgálók már sima http-t beszélnek, persze csak localhoston érhetők el és a nginx szólítgatja meg őket.

 * A különböző kiszolgálók a path rész szerint ágaznak el: https://mydomain/szolgáltatás1/, stb.

 * A belépés nélkül is használható szolgáltatások akár külön processzben is futhatnak.

 * Nem kell jelszavakat kezelned a webes ügyfeleidnek (ha 3rd party o2auth-ot használsz ugye). Ha valakinek jogot akarsz adni, akkor beírod az email címét az autentikátor konfjába a megfelelő groupokkal, és készen is vagy.

 * A védtelen nginx alatt semmilyen tartalom nincsen, így csak az alap rendszer sebezhetőségein keresztül támadható.

Hátrányok:

 * Egyik oldal sem a gyökér path-tól indul. Ez gagyin összetákolt oldalak esetén okozhat gondot, ha a HTML-be abszolút path-ok úgy vannak bedobálva, hogy nem konfigurálható a context path, akkor azok nem fognak működni. (Saját játszós oldalaimon ezen jó sokat kellett gondolkodnom mire minden flottul ment :-)

 * Némi overhead, hogy átmegy minden a nginx-en. Nyilván netflix streameket nem így kell kiszolgálni.

 

Amit még össze akarok majd rakni, hogy kliens oldali cert authentikáció is működjön, illetve függetleníteni akarom a jelszavas user kezelést a 3rd partytól, csak azzal kényelmet fogok veszíteni.

Szerk.: Ja, és a +1: aminek nagyon eltérő a biztonsági szintje érzésre, azokat külön VPS-re tettem fel. Például a privát jitsi szerveremnek egy saját VPS-e van, ami ha vírusos lesz, hát vírusos lesz. Nincs rajta semmilyen védendő adat. Leírások alapján telepítettem, elvileg biztonságos, de mit lehet biztosan tudni manapság?

Szerk.2: Feltettem egy példa nginx beállítást. Egy működő confot anonimizáltam. Ha szarvashibát találtok benne, akkor lécci priváton szóljatok, ne a szerveremet megtörve és azon keresztül :-) https://pastebin.com/BhD6TE3w

Ami nálam, eddig, bevált... ssh feltolva másik portra, privát kulcsos auth az ssh-n és fail2ban.

Ezen felül napi szinten frissítve.

A tehén egy bonyolult állat, de én megfejtem.

Még az jutott eszembe, hogy ha tényleg nagyon figyelni szeretnél mindenre, és ha már Apache-ot használsz, akkor egy ModSecurity+CRS is nagy segítség lehet.

Nem tudom, a weboldal működése mennyire egyedi, de ha tudod specifikálni a kliensek felé az elvárásokat, akkor akár PL4-el (Paranoia Level 4) is futtathatod. A proxy mögé amúgy berakhatod a Go webszervert is.

Hátránya, hogy a performancia kicsit romlik. Nem tudom, a mostani HW (mármint a VPS) mire képes, írtad az elvárt értéket, ha úgy döntesz használod, akkor picit erősebb gép kell.