[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.

>>> Security by Obscurity nem működik.

>> Már miért ne működne?

>Már hogy micsoda? Security by Obscurity?

Mit írtam?

OK, feladom.

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.

Ez a másik portra rakás necces dolog. Voltam már olyan helyen, ahol kimenő portszűrés volt és sokan sírtak az egyedi portra rakott SSH eléréseik miatt.

„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Nem, félreértetted. A céges rendszergazda tette egyedi portra az SSH szervert, a felhasználók pedig szerették volna elérni, de nem tudták, mert olyan külső helyen voltak, ahol kimenő portszűrés volt és nem volt lehetőség a tűzfal-szabályok módosítására.

„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Gyakorlatilag nem, legalább három okból: Ehhez egyrészt a privát kulcsot tartalmazó állományt kéne általa módosíthatatlanná tenni - ezt még csak-csak lehet "trükkös" acl-ekkel meg nem helyi root jogot kikötve az adott usernél.
Másrészt az ssh parancsból kéne kiírtani a "-i" kapcsolót, hogy ne lehessen egy másik, jelszó nélküli kulcsot "megetetni" vele.
Harmadrészt meg a cél hoston az authorized_keys fájlnak a módosíthatatlanságát is meg kéne oldani, hogy másik tetszőleges, jelszó nélküli/akármilyen kulcspárt ne tudjon felvenni a user.
Hardvertoken, kötelező PIN lehet a megkerülő megoldás - de ekkor kell megfelelő olvasó/token az usernek ott, ahonnan be akar lépni.

 

Anno IPA-t használtam, az ugyebár Kerberosra épül, és igen jól hangolható HBAC-ot is tud mellé (a későbbi verziók már a sudo rule-okat is tudták kezelni). Épp mostanában sírtam vissza ezt a megoldást, mert lokális userek és AD-ből érkező userek kombinációjára kellett HBAC-ot csinálni egy szál sshd_config használatával :)

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

Ez gyakorlatban ugy szokott kinezni, hogy a script kiddie-k addig fossak tele a logodat fassaggal, amig van hely a diszken. Fail2ban ezen a reszen tud segiteni.

Masik port arra jo, hogy a "tamadasok" 90%-at kiszurje: a legtobb szkript nem szarozik teljes portscan-nel. Beprobal 20-30 default portot aztan megy tovabb.

Ez gyakorlatban ugy szokott kinezni, hogy a script kiddie-k addig fossak tele a logodat fassaggal, amig van hely a diszken. Fail2ban ezen a reszen tud segiteni.

Van jó pár nagyobb forgalom szerverem szerte a világban, de ezt én a gyakorlatban nem tapasztaltam, egy node-ra jellemzően óránként 20-60 ilyen kérés esik be.

Eddig négyféle jellemző támadást láttam:

1, SSH-n kipróbálnak 100-150 faék kombinációt. Nem fáj, nem jutnak be, nem okoz terhelést.

2, HTTP-n keresnek olyan szoftvereket, amelyeket jellemzően nem frissítenek a VPS-en, 404 megy vissza.

3, SMTP-n megpróbálnak open relay levelet feladni.

4, Nagy ritkán jön port scan, hogy milyen portok vannak nyitva.

Egyik se veszélyes, nem tudnak sehova jutni vele, nem én vagyok a célközönség, hanem olyan szerverek, ahol gyenge jelszót használnak, nem frissítenek időben és vannak nem túl jól karbantartott szolgáltatásaik. Semmivel se csökkentem a kockázatokat azzal, hogy feltolok egy fail2ban-t, csak növelem a rendszer komplexitását, adminisztrációs időt visz el és növekszik az üzemeltetési kockázat, mert időnként legális forgalmat blokkol.

Masik port arra jo, hogy a "tamadasok" 90%-at kiszurje: a legtobb szkript nem szarozik teljes portscan-nel. Beprobal 20-30 default portot aztan megy tovabb.

Ja, az ilyen "támadások" ellen "véd". Idézőjelben mind a két szó.

Nalam fent van a fail2ban mas szolgaltatasok miatt is. Tipikusan jelszavas auth-oknal: pop3/imap/smtp/http basic auth, stb. Annyival nem noveli a komplexitast, ha hozzaadom az ssh-t is. De ha csak emiatt lenne font sem okozna nagy megeroltetest beallitani.

En orulok neki, ha nem kell a logban 100-150 felesleges sort atszkrolloznom, hanem ehelyett megakadnak a tuzfalon.

időnként legális forgalmat blokkol

Ez igaz.

Nalam fent van a fail2ban mas szolgaltatasok miatt is. Tipikusan jelszavas auth-oknal: pop3/imap/smtp/http basic auth, stb. Annyival nem noveli a komplexitast, ha hozzaadom az ssh-t is. De ha csak emiatt lenne font sem okozna nagy megeroltetest beallitani.

Ja, nyilván. Ha már egyszer ott van, akkor ahhoz képest nem növeli a komplexitást, a kérdés az, hogy milyen objektív szempontok szerint van ott. Mert ha csökkenti a kockázatot, akkor lyukas a rendszered, foltozd be a lyukat. Ha meg nem csökkenti a kockázatot, mert amúgy sincs biztonsági résed, sőt, időnként legális forgalmat blokkol, akkor meg minimum felesleges dísz, de inkább kárt okoz.

En orulok neki, ha nem kell a logban 100-150 felesleges sort atszkrolloznom, hanem ehelyett megakadnak a tuzfalon.

Az előbb még arról volt szó, hogy "a script kiddie-k addig fossak tele a logodat fassaggal, amig van hely a diszken". Most kiderül, hogy 100-150 felesleges sortól elfogyna a hely?

 

Mert ha csökkenti a kockázatot, akkor lyukas a rendszered.

Nincs a ketto kozott ok-okozati osszefugges. De ha lenne is, nem allok neki patkolni vagy throttling-ot implementalni az imap szerverbe. :)

Most kiderül, hogy 100-150 felesleges sortól elfogyna a hely?

Nalam spec telifostak a logot. De ha csak orankent 100-150 sort sporolok meg vele, akkor is jo ha ott van.

Szarok a legalis forgalomra. Evente kapok 2 telefont, hogy sorry kizartam magam a pop3-rol, engedj vissza. :)

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.

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

Oszt? Ha nem zombi és nem bot, akkor legalább szórakozik.

- a youtube-ot a felesleges kapcsolattal

Ha olyan hülye a bot, hogy követ egy redirect címet, ami a tecsőre mutat... :)

- a saját szerveredet

Mégis mivel szopatom? Egy Location fejléccel és egy 200-as válasszal? Ennél lényegesen több erőforrás egy decens 404 oldal.

- meg persze a hálózatot

Ne tegyünk már úgy, mintha épp ilyesmitől terhelődne szarrá a hálózat.

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.

Mégis minek tartsak state-et, adatbázist, toronyórát lánccal? Ártalmatlan tapogatózások ezek, placebo ilyenre a fail2ban, meg minden másra is.

Amúgy meg: https://stackoverflow.com/admin/login.php

De próbálkozó botok meg unatkozó  gyerekek ellen lehet jó., tehát van benne hatóanyag.

De mi a hatóanyag ilyenkor? Mi ellen véd? Szeretnék érveket látni a fail2ban mellett, de általában szubjektív érzések jönnek csak érvek helyett...

De nem vitatkozom,  csináld ahogy neked jólesik,  én is csinálom ahogy nekem jó. 

Ha nem törhető a rendszered, akkor teljesen felesleges. Ha törhető, akkor meg nem véd meg.

De mi a hatóanyag ilyenkor? Mi ellen véd? Szeretnék érveket látni a fail2ban mellett, de általában szubjektív érzések jönnek csak érvek helyett...

Ha a fail2ban ismert funkciója, és tulajdonságai -- mint hogy x helytelen próbálkozás után y időre ban, loggal, eszkalálhatóan, gyakorlatilag bármely log alapján éltalad is definiálható regexp szerint... -- mellé még további érveket szeretnél, akkor attól tartok nem lehet téged erről meggyőzni.

Viszont érdekelne, hogy van-e érved ellene? ;)

Ezek az "apró" kis biztonsági figyelmességek együtt adnak viszonylag jó biztonságot.
Ennek része a fail2ban. Ami megkímél a botoktól, és az amatőr hülyegyerekektől. Értsd: nem kell miattuk bogarászni a logokat, és nem kell energiát ölnöd a bannolgatásukba.

De ha a teljes biztonságra akarsz egy működő varázsigét, akkor ezt javaslom:
/etc/init.d/networking stop

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

Ha a fail2ban ismert funkciója, és tulajdonságai -- mint hogy x helytelen próbálkozás után y időre ban, loggal, eszkalálhatóan, gyakorlatilag bármely log alapján éltalad is definiálható regexp szerint... -- mellé még további érveket szeretnél, akkor attól tartok nem lehet téged erről meggyőzni.

El tudnád magyarázni, hogy ez mivel növeli a biztonságodat? Tehát x+1 helytelen próbálkozás és/vagy y-1 másodperc után sikerrel járna a támadó? Ha kikapcsolod a fail2ban szolgáltatást, akkor be tudnak jutni?

Viszont érdekelne, hogy van-e érved ellene? ;)

Legutóbb két hónapja nem értem el például a levelezésem miatta, mert túlbuzgott épp arrafelé a fail2ban, de korábbról is vannak személyes élményeim. Ha kicsit körülnézel, utánaolvasol, meglátod, hogy mennyi egyéb üzemeltetési kockázattal jár.

Ezek az "apró" kis biztonsági figyelmességek együtt adnak viszonylag jó biztonságot.

Nem, nem adnak jó biztonságot, ezek biztonságérzetet adnak, ráadásul legtöbbször hamis biztonságérzetet.

Ennek része a fail2ban. Ami megkímél a botoktól, és az amatőr hülyegyerekektől. Értsd: nem kell miattuk bogarászni a logokat, és nem kell energiát ölnöd a bannolgatásukba.

És miért kellene bannolni? Bannolás nélkül megtörnek? Ha úgy érzed, hogy fail2ban nélkül veszélyben van a rendszered, akkor fail2ban használatával is pont olyan veszélyben van.

El tudnád magyarázni, hogy ez mivel növeli a biztonságodat?

Például azzal, hogy ha egy bot találgatja a jelszavadat akkor a "secret"-re nem egy óra alatt jön rá, hanem egy év alatt.

Legutóbb két hónapja nem értem el például a levelezésem miatta, mert túlbuzgott épp arrafelé a fail2ban

Nem gondolnám, hogy ez a fail2ban hibája... Lehet azt finomhangolni.

Nem, nem adnak jó biztonságot, ezek biztonságérzetet adnak, ráadásul legtöbbször hamis biztonságérzetet.

A semminél sokkal jobb. A hamis biztonságérzetben pedig a naív emberek szenvednek. Reális biztonságérzet szükséges.

És miért kellene bannolni?

Azért, hogy pl az auth logban ne legyen nagy a "zaj".

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

És miért kellene bannolni?

Azért, hogy pl az auth logban ne legyen nagy a "zaj".

OK. És miért baj, ha zaj van az auth logban?

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.

Persze biztos mindenki másképp csinálja, és két módon szoktam logokat nézni:

1) valami konkrétat keresek, és akkor grep
2) csak meg akarom nézni, van-e valami különös, és akkor grep -v mindenre, ami nem különös. Pl. az ssh auth hibás jelszó mintájára.

Akkor a következő kérdésem (a 5 why-ból már a 3.-nál járunk, egész jó): miért nem jó az, hogy grep -v-vel kiszűri az érdeklődő a minden egyéb kiszűrt zaj mellett az ssh failed password auth mintákat is?

Amúgy a logwatch dolgok is úgy működnek (legalábbis az, amit használtam régebben, amikor ilyesmit használtam még), hogy beállítja az ember, hogy mi nem érdekli, és a maradékot elküldi email-ben. A zaj szűrése a mintákkal automatikusan működik.

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.

Például azzal, hogy ha egy bot találgatja a jelszavadat akkor a "secret"-re nem egy óra alatt jön rá, hanem egy év alatt.

Ez önmagában hiba, ha egy bot ki tudja találni x+1 próbálkozással a jelszót, de x próbálkozással még nem és x < 10, de még akkor is, ha x < 1000000.

Nem gondolnám, hogy ez a fail2ban hibája... Lehet azt finomhangolni.

Finomhangolni, ja. Na, amíg finomhangolod, addig mindig belefutsz egy csomó üzemeltetési problémába és kockázatba, hogy nem mennek dolgok, amelyeknek amúgy menniük kellene, de egy generikus rule miatt elakadnak.

A semminél sokkal jobb. A hamis biztonságérzetben pedig a naív emberek szenvednek. Reális biztonságérzet szükséges.

Mi a lófasz az, hogy reális biztonságérzet? Ha van biztonság, akkor van biztonság, akkor is, ha nincs biztonságérzeted, mert elvonási tüneteid vannak fail2ban nélkül. Ha meg nincs biztonság, akkor a fail2ban adta biztonságérzetedtől nem lesz jobb a helyzet.

Azért, hogy pl az auth logban ne legyen nagy a "zaj".

A zaj ott lesz és nézned kell.

" A zaj ott lesz és nézned kell. " - csak az nem mindegy, hogy a loggyűjtő és elemző motyóba mennyi szemetet kell betolni - akár humán időt, akár tárhylet, akár - mondjuk Splunk esetén - licenszet (mert ez utóbbi ugyebár napi feldolgozható logmennyiség alapján licenszelődik). És ha csökkenthető a zaj, akor az azt is jelenti, hogy a korábban felhazsnált idő egy része másra is fordítható.

Az f2b logból _is_ csak a szűrt, érdemi információt tartalmazó sorokat kell elemzésre beküldeni - de tudjuk, te a fail2ban-t már-már vallásossági szinten nem tartod hasznosnak - más meg mondjuk portkopogtatásra mondja azt, hogy nem biztos, hogy a használati kockázata pariban van a hasznosságával. Aki úgy gondolja, a drótkerítés elé/müögé még odarak egy tüskés sövényt is, aki meg nem, az nem. Egyik esetben sem lesz sokkal nehezebb annak a dolga, aki ténylegesen be akar menni, de ad-hoz behatolók esetén a tüskés sövénnyel kiegészített kerítés naygobb visszatartó erővel bír, mint a sima.

Az f2b logból _is_ csak a szűrt, érdemi információt tartalmazó sorokat kell elemzésre beküldeni

Ha automatikus szűrsz, akkor ugyanezt meg tudod tenni fail2ban nélkül is.

de tudjuk, te a fail2ban-t már-már vallásossági szinten nem tartod hasznosnak

Innen nézve te tartod vallásossági szinten hasznosnak. Logikusan felépített láncolatot még nem sikerült prezentálni, csak olyanokat, mint amit most is írtál, hogy "ad-hoz behatolók esetén a tüskés sövénnyel kiegészített kerítés naygobb visszatartó erővel bír, mint a sima", holott nagyon jól tudod, hogy ad-hoc jelleggel nyugodtan próbálkozhatnak, ha meg ezzel az ad-hoc próbálgatással tényleg kockázatos az üzemeltetés, akkor a fail2ban lófaszt nem ér. Placebo.

Ha ez a placebo n darab támadási kísérletet megfog már tcp connect szinten, akkor nem placebo.

Nem támadási kísérletet fog meg, mert az nem támadási kísérlet, hogy nincs olyan szolgáltatásod, amit keres. Támadási kísérlet az, amikor potenciálisan sikerrel jár a végén. Amiket a fail2ban megfog, azok nem járnak sikerrel akkor se, ha nincs fail2ban, ergo nem támadási kísérlet, semmivel se vagy nagyobb biztonságban, ha ezeket blokkolod és semmivel se vagy nagyobb veszélyben, ha ezeket nem blokkolod.

Az ad-hoc támadgatás ellen valóban nem jó, de nem csak olyan van.

Más ellen meg pláne nem véd.

" Támadási kísérlet az, amikor potenciálisan sikerrel jár a végén. " - szerintem meg az is támadási kísérlet, ha ismert hibák után kutat valaki módszeresen a webszerveren - tapasztalat, hogy nem csak egy (mondjuk phpmyadmin) alkalmazásra "lőnek" ilyenkor, hanem n+1-re, amikről feltételezik, hogy sérülékeny és célzottan támadható. Ha pechem van, akkor elsőre "eltalálják", ha meg szerencsém, akkor mire oda jutna a keresgélés, már le vannak tiltva a francba. És ha ezzel a módszerrel csak egy célzott támadást elhárítok, akkor szerintem javítottam a rendszer biztonságán.

Ha pechem van, akkor elsőre "eltalálják", ha meg szerencsém, akkor mire oda jutna a keresgélés, már le vannak tiltva a francba. És ha ezzel a módszerrel csak egy célzott támadást elhárítok, akkor szerintem javítottam a rendszer biztonságán.

Aham, tehát van egy minimum pár napos, de általában minimum 1-6 hónapos biztonsági résed és a fail2ban sikerén múlik, hogy bejönnek-e rajta? Miért van közkézen forgó biztonsági résed? Van még ilyen hülye érved?

Tehát x+1 helytelen próbálkozás és/vagy y-1 másodperc után sikerrel járna a támadó?

Ez az álláspont meglehetősen arra fókuszál, hogy a támadó megszerzi a jelszavad, vagy sem.

A fail2ban szerintem egészen másra való - nyilván erre rá lehet húzni, hogy jó, de alapvetően az adminisztrátor mondja meg, hogy milyen mintákra mi legyen az adott válasz. Lehet pl arra is használni, hogy ha wp-admin.php mintákat talál a http szerver logjában, és tudod, hogy nincs olyan, akkor azt elsőre kitiltsd. De nyilván ez csak egy példa, tényleg nem akarlak meggyőzni semmiről.

Legutóbb két hónapja nem értem el például a levelezésem miatta,

Egyel feljebb ezt írtad: de általában szubjektív érzések jönnek csak érvek helyett... - no offense, de ez mi, ha nem szubjektív érzés? :)

És miért kellene bannolni? Bannolás nélkül megtörnek?

Itt is érzek egy kis félreértelmezést. A bannolással nem azt éred el, hogy ne törjenek meg, hanem hogy csökkentsd a lehetőségét, hogy bármit kiderítsenek. Pl. nézzünk egy olyan esetet, hogy IMAP/SMTP kiszolgáló, felhasználói authentikáció. Tfh. elő van írva, hogy 3 havonta jelszót kell váltania a usernek, valamilyen policy-t is rákényszerítve. Szerintem egy ilyen helyzetben igenis van létjogosultsága egy IDS-nek, ahol adott esetben eléggé meg tudod nehezíteni a támadók dolgát. És nem arról van szó, hogy a user leveleit el tudják olvasni (arról is), hanem arról, hogy a spammerek "áldásos" tevékenységét elkerüld.

A fail2ban szerintem egészen másra való - nyilván erre rá lehet húzni, hogy jó, de alapvetően az adminisztrátor mondja meg, hogy milyen mintákra mi legyen az adott válasz. Lehet pl arra is használni, hogy ha wp-admin.php mintákat talál a http szerver logjában, és tudod, hogy nincs olyan, akkor azt elsőre kitiltsd. De nyilván ez csak egy példa, tényleg nem akarlak meggyőzni semmiről.

Oké, és konkrétan mi ellen véd?

Egyel feljebb ezt írtad: de általában szubjektív érzések jönnek csak érvek helyett... - no offense, de ez mi, ha nem szubjektív érzés? :)

Ez nem szubjektív érzés, ez egy egészen jól körülhatárolt SLA sértés volt egy olyan komponens miatt, aminek amúgy semmi hozzáadott értéke nem volt. Nettó üzemeltetési kockázat.

Itt is érzek egy kis félreértelmezést. A bannolással nem azt éred el, hogy ne törjenek meg, hanem hogy csökkentsd a lehetőségét, hogy bármit kiderítsenek. Pl. nézzünk egy olyan esetet, hogy IMAP/SMTP kiszolgáló, felhasználói authentikáció. Tfh. elő van írva, hogy 3 havonta jelszót kell váltania a usernek, valamilyen policy-t is rákényszerítve. Szerintem egy ilyen helyzetben igenis van létjogosultsága egy IDS-nek, ahol adott esetben eléggé meg tudod nehezíteni a támadók dolgát. És nem arról van szó, hogy a user leveleit el tudják olvasni (arról is), hanem arról, hogy a spammerek "áldásos" tevékenységét elkerüld.

Megnehezíteni? Ha célzottan támadnak, akkor lófasz tejszínhabba a fail2ban, mert röhögve kikerülik. Ha nem célzottan támadnak, akkor meg semmi védelmet nem ad. De ezt már írtam.

Ami megkímél a botoktól, és az amatőr hülyegyerekektől.

Miért kellene megkímélni a botoktól és az amatőr hülyegyerekektől, ha biztonságos a rendszer és úgyse tudnak bejutni?

Értsd: nem kell miattuk bogarászni a logokat, és nem kell energiát ölnöd a bannolgatásukba.

Ha a botok és az amatőr hülyegyerekek próbálkoznak és lepattannak, de nincs fail2ban, akkor miért kell bogarászni miattuk a logot, és miért kell bannolgatni őket?

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 biztonságos a rendszer és úgyse tudnak bejutni?

Mikor mondható egy rendszer biztonságosnak? Honnan tudod, hogy biztosan nem jutnak be? Tényleg van ilyen? :)

Szerk: miért csak az a gond, ha bejutnak? Ha egy felhasználó hozzáférését szerzik meg, amivel nekiállnak spammelni, adatokat módosítani a CMS-ben, stb... az nem annyira nagy gond?

Mikor mondható egy rendszer biztonságosnak? Honnan tudod, hogy biztosan nem jutnak be? Tényleg van ilyen? :)

Ezen mit segít a fail2ban?

Szerk: miért csak az a gond, ha bejutnak? Ha egy felhasználó hozzáférését szerzik meg, amivel nekiállnak spammelni, adatokat módosítani a CMS-ben, stb... az nem annyira nagy gond?

Ez ugyanúgy törésnek számít és semmit nem javít rajta a fail2ban, főleg, ha nem javított ismert hibát használnak ki. A fail2ban egy placebo, amitől jobban alszol, mert biztonságérzetet növel, de többlet biztonságot nem ad.

Ezen mit segít a fail2ban?

Ennek a kérdésnek semmi köze a fail2ban-hoz. Általánosságban tettem fel.

semmit nem javít rajta a fail2ban, főleg, ha nem javított ismert hibát használnak ki

Ez így van. Megint olyat akarsz a fail2ban-ra erőltetni, amihez semmi köze.

A fail2ban egy placebo, amitől jobban alszol, mert biztonságérzetet növel, de többlet biztonságot nem ad.

Nem alszok tőle jobban, és szerintem valamennyi többletbiztonságot ad. Tisztában vagyok vele, hogy egy telepített és beállított f2b mellett is törhető a rendszer (sőt, nem nagyon hiszek a törhetetlen rendszer fogalmában - lásd a kérdésem), de szerintem az esetek többségében csökkenthető az incidensek száma. De ez legyen az én bajom :).

Ennek a kérdésnek semmi köze a fail2ban-hoz. Általánosságban tettem fel.

Ja, egy fail2ban szálban.

Nem alszok tőle jobban, és szerintem valamennyi többletbiztonságot ad.

Milyen többletbiztonságot? Miből adódóan?

Tisztában vagyok vele, hogy egy telepített és beállított f2b mellett is törhető a rendszer (sőt, nem nagyon hiszek a törhetetlen rendszer fogalmában - lásd a kérdésem), de szerintem az esetek többségében csökkenthető az incidensek száma.

Ha fail2ban nélkül törhető a rendszer, akkor fail2ban esetén is törhető. Ha a brutal force törés valószínűségét értékelhető mértékben csökkenti a fail2ban, akkor ott komoly biztonsági lyuk van, amire maximum szépségtapasz a fail2ban.

Az a nagy félreértésetek, hogy ami belekerül a fail2ban logba, mint szabály alapján blokkolt kérés, az nem egy elhárított kockázat vagy elhárított támadás, ha pedig eddig öt hibás kérés után blokkoltad és ezek után négy után blokkolod, azzal nem növelted semmivel a rendszer biztonságát.

Ja, egy fail2ban szálban.

Meeert... azt nem lehet?

Milyen többletbiztonságot? Miből adódóan?

Hogy a kísérletek egy jelentős részét kizárja. Nem tudom ennél jobban elmagyarázni (én sem).

Ha fail2ban nélkül törhető a rendszer, akkor fail2ban esetén is törhető. Ha a brutal force törés valószínűségét értékelhető mértékben csökkenti a fail2ban...

Szerintem neked pedig az a nagy félreértésed, hogy egy rendszer vagy törhető, vagy nem. Mindegyik rendszer törhető, a kockázatot lehet csökkenteni.

ami belekerül a fail2ban logba, mint szabály alapján blokkolt kérés, az nem egy elhárított kockázat vagy elhárított támadás

Ha egy webszerver logjában azt látom, hogy valahonnan a phpmyadmin-t próbálják elérni úgy, hogy tudom, nincs phpmyadmin a szerveren, akkor azt én támadásnak veszem (szívem joga szerintem). Ha az IP-t, ahonnan ez a kérés érkezik blokkolom az n. próbálkozás után, az szerintem az általam feltételezett támadás blokkolása.

Szerintem neked pedig az a nagy félreértésed, hogy egy rendszer vagy törhető, vagy nem. Mindegyik rendszer törhető, a kockázatot lehet csökkenteni.

Egyáltalán nem mondom azt, hogy 0 vagy 1 a törés valószínűsége, azt mondom, hogy ezzel, amit itt például leírtál, egyáltalán nem csökkented a kockázatot. Cserébe viszont behozol komplexitást, üzemeltetési kockázatot és adminisztrációs overhead is hozzákerül.

Ha egy webszerver logjában azt látom, hogy valahonnan a phpmyadmin-t próbálják elérni úgy, hogy tudom, nincs phpmyadmin a szerveren, akkor azt én támadásnak veszem (szívem joga szerintem). Ha az IP-t, ahonnan ez a kérés érkezik blokkolom az n. próbálkozás után, az szerintem az általam feltételezett támadás blokkolása.

Ne röhögtess már, hogy szerinted elhárított (!) támadás (!) egy olyan HTTP kérés blokkolása, ami amúgy nincs is a szervereden.

Ne röhögtess már, hogy szerinted elhárított (!) támadás (!) egy olyan HTTP kérés blokkolása, ami amúgy nincs is a szervereden.

Egy ilyen IP címről több száz url-t is megnéznek, amiből viszont lehet hogy a 42-ik van a szervereden.
Viszont így hogy már frankón :) blokkolod az IP-t az elején nem fog tudni odáig eljutni vagy csak olyan sokára (mondjuk 42 nap múlva), hogy addigra 
- lehet nem is lesz ilyen url-ed
- felraktad a PHP javítást hozzá
- frissítette a fejlesztő a PHP csomagot amiben a rés volt
- stb.

Továbbá így erről az IP címről, ha ez mondjuk egy zombi gép, akkor a SPAM-ek sem fognak érkezni vagy bármi más egyéb próbálkozás.
Szerintem a log fájlok "tisztán" tartása fontos, főleg hogy nem kíván sok tudást és erőforrást.
No persze vannak a "zsenik", akik minden káosz-on és szemétdombon átlátnak. ;)

Egy ilyen IP címről több száz url-t is megnéznek, amiből viszont lehet hogy a 42-ik van a szervereden.

Oszt akkor mi van? Ha azon keresztül sebezhető a rendszered (és ezek nem zero day sebezhetőségek, hanem általában hetek és hónapok sebezhetőségeit kutatják), akkor fail2ban szabályaidon is simán keresztülmegy egy elosztott tapogatózás, másrészt meg célzottan támadható vagy és meg fogják tudni, hogy mid van, mert legálisan kiszolgálod a dolgokat a sebezhető szoftvereddel. Amúgy mi a helyzet azzal, hogy rotálják a kéréseket és hiába kitiltottál ki egy IP-t, visszajön egy másik bot úgy, hogy elsőre azt kérdezi le, ami a sebezhető?

Amit felsoroltál, az színtiszta placebo és az a veszélye van, hogy szarni fogsz a gyakori frissítésre, mert van fail2ban.

Szerintem a log fájlok "tisztán" tartása fontos, főleg hogy nem kíván sok tudást és erőforrást.

Tisztán. Mert szemmel kell verni a logfájlokat, arra valók.

Szerintem a log fájlok "tisztán" tartása fontos, főleg hogy nem kíván sok tudást és erőforrást.
No persze vannak a "zsenik", akik minden káosz-on és szemétdombon átlátnak. ;)

Meg vannak a nem zsenik, csak normális emberek, akik kiszűrik azt, amire nem kíváncsiak a logból.

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.

egyáltalán nem csökkented a kockázatot.

Ez is egy nézőpont.

elhárított (!) támadás (!) egy olyan HTTP kérés blokkolása, ami amúgy nincs is a szervereden.

Kicsit kiforgatod a szavaimat (vagy tényleg nem érted). Én arra utaltam, hogy ha valaki nyilvánvalóan rossz szándékkal érkezik, mert egy minta alapján én úgy döntök, és ha azt kitiltom, akkor azzal megnehezítem (és nem elhárítom) a dolgát. Nyilván sok támadónak komplex infrastruktúrája van arra, hogy ezt kivédje, de hidd el, a többség feladja.

Ahogy itt írtam, szíved joga azt használni/nem használni, amit akarsz. És másnak ugyanúgy.

Ez is egy nézőpont.

Ez nem nézőpont kérdése.

Kicsit kiforgatod a szavaimat (vagy tényleg nem érted). Én arra utaltam, hogy ha valaki nyilvánvalóan rossz szándékkal érkezik, mert egy minta alapján én úgy döntök, és ha azt kitiltom, akkor azzal megnehezítem (és nem elhárítom) a dolgát. Nyilván sok támadónak komplex infrastruktúrája van arra, hogy ezt kivédje, de hidd el, a többség feladja.

Ez nem szavak kiforgatása, te egy fail2ban által elhárított támadásnak vélsz egy kutyaközönséges 404-es hibával végződő HTTP kérést. Mert csak, mert úgy döntesz, mert ettől jobban érzed magad. Placebo.

Nyilván sok támadónak komplex infrastruktúrája van arra, hogy ezt kivédje, de hidd el, a többség feladja.

Nézd, nem használok fail2ban-t és hidd el, hogy akkor is feladják, ha 404-et kapnak arra, amit keresnek. Ha meg célzottan próbálnak egy-egy sebezhetőséget, akkor annak csak egyszer futnak neki, az meg úgy megy át a fail2ban szabályokon, mint forró kés a vajon.

A fail2ban kurva jól néz ki és biztos kurva jó érzés, hogy egy külön logba mennek a saját kis szabályaid alapján a kérések, biztos kurva jó érzés külön grafikonozni, és biztos jó érzés, hogy kitiltottad a kis genyát, de kockázatot bizony lófaszt se csökkentettél ezzel. A biztonságérzeted lett nagyobb.

" fail2ban által elhárított támadásnak vélsz egy kutyaközönséges 404-es hibával végződő HTTP kérést. " - ha adott forrásból olyan kérés(ek) érkeznek, amik nincsenek az adott szerveren, _és_ valamilyen webes alkalmazás sérülékenységet tartalmazó részét szeretnék próbálgatni, az nem a kutyaközönséges 404, úgyhogy teljesen jogos, ha támadási mintának tekinti, és már IP-szinten tiltja a forrást. Ráadásul ezzel azoknak a kutya közönséges 404-gyel végződő kéréseket sem kell feldolgozni a szervernek.

Egyébként meg fordítsuk meg a kérdést: Ha logban látsz (szemmel, splunk kiböki, stb) támadásra utaló kérések sorozatát, akkor mit teszel? Reaktívan elkezdet a támadást valahol megfogni egy szűréssel, nem? Vagy azt mondod, hogy elég figyelni rá, mert úgyis sok erőforrás vana támadói oldalon, fölösleges bármilyen módon szűrni a forgalmat?

Egyébként meg fordítsuk meg a kérdést: Ha logban látsz (szemmel, splunk kiböki, stb) támadásra utaló kérések sorozatát, akkor mit teszel? Reaktívan elkezdet a támadást valahol megfogni egy szűréssel, nem? Vagy azt mondod, hogy elég figyelni rá, mert úgyis sok erőforrás vana támadói oldalon, fölösleges bármilyen módon szűrni a forgalmat?

Szarok rá általában, ha tudom, hogy nincs publikus zero day sebezhetőségem, a normál forgalomhoz képest annyira lófasz se, hogy nincs értelme reagálni rá. A DDoS-t megfogja a szolgáltató, a célzott támadáshoz meg úgyse ér semmit a fail2ban. Kár rá akár egy percet is pazarolni, hogy false negative és false positive kéréseket adminisztráljak, és foglalkozzak azzal, hogy egy-egy furcsa hibát vajon a fail2ban okoz, mert általában okoz, ha van.

Ha van publikus zero day sebezhetőségem, ami pillanatnyilag nem javítható, de van rá workaround, akkor azt alkalmazom, amíg a javítás meg nem történik.

Ha van nem publikus zero day sebezhetőségem, akkor nyilván nem tudok róla, megtörnek mit a szart, ha van fail2ban, ha nincs.

Én nem látok értelmes helyet a fail2ban számára. DDoS ellen nem véd. Ad-hoc puhatolózások ellen nem véd, mert ezek nem potenciális támadások. Célzott támadás ellen nem véd, mert könnyen kikerülhető. Placebo.

" Szarok rá általában, ha tudom, hogy nincs publikus zero day sebezhetőségem " - ez is egy hozzáállás - aztán lehet, hogy pont befigyel olyan sérülékenységed, amiről te még nem tudsz, de a patternje már ott van a keresgélő gépen, és a 123. kérésben betalálnak. Miközben az előző 122-ből látszik, hogy támadást készít elő az adott gép.

ez is egy hozzáállás - aztán lehet, hogy pont befigyel olyan sérülékenységed, amiről te még nem tudsz, de a patternje már ott van a keresgélő gépen, és a 123. kérésben betalálnak

Vagy az elsőben. Vagy elosztva keresik és szintén az elsőben ott van. Miért van egy olyan sérülékenység a gépemen, amiről a fél világ hülyegyerekei tudnak és már botok keresik, csak én nem tudok róla? Én itt erős ellentmondást látok a felelős üzemeltetés terén.

Miközben az előző 122-ből látszik, hogy támadást készít elő az adott gép.

Ha támadható a géped, akkor az elsőből is betalálnak. Miért támadható a géped publikus sebezhetőséggel? Miért hagyod támadható állapotban? Ha tudod, hogy támadható, akkor miért nincs workaround arra a támadási vektorra?

Megnéztem most az utolsó egy óra .php végű kérések számát olyan gépen, ahol nincs PHP, íme:

1 103.21.116.77
1 109.237.108.24
1 116.202.35.123
1 157.181.183.93
1 158.116.225.51
1 159.203.241.101
1 159.89.172.219
1 160.114.36.201
1 176.63.213.190
1 185.180.88.5
1 188.157.254.196
1 188.165.211.206
1 192.95.30.59
1 195.228.228.125
1 195.54.160.65
1 195.54.160.68
1 2001:7d0:4d02:4c00:4c91:dc85:db03:9bd
1 213.181.220.170
1 2a00:23c5:311b:7300:164:a1ad:a323:15da
1 2a01:36d:400:29a8:dca0:3e19:ade2:6c16
1 31.171.237.206
1 31.46.86.255
1 37.191.12.134
1 45.122.223.198
1 46.139.160.49
1 46.35.192.110
1 5.204.40.104
1 62.165.210.226
1 84.206.25.236
1 86.101.191.6
1 89.132.139.25
1 89.135.126.181
1 89.163.255.226
1 92.249.176.202
1 95.216.46.77
2 132.232.213.228
2 13.234.187.56
2 142.93.124.210
2 151.80.45.51
2 192.99.200.69
2 2a01:4f8:141:6034::2
4 118.184.171.175
4 121.89.204.243
8 129.158.122.65
8 195.54.160.21

Ebből a 45 IP-ből mennyit zártál volna ki és mennyi talált volna be elsőre a sebezhetőségedbe?

A logot is látni kéne, hogy mit szerettek volna.

Ha boldoggá tesz:

/adminer-4.2.5.php
/caiyuan/login.php
/elrekt.php
/html/public/index.php
/prox_ch.php
/include/dialog/select_soft_post.php
/index.php
/phpminiadmin.php
/phpmyadmin/index.php
/public/index.php
/thinkphp/html/public/index.php
/TP/html/public/index.php
/TP/index.php
/TP/public/index.php
/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/wp-login.php

De ha per definitem nincs php, akkor akár valamennyi ment volna pihenni nem túl sok kérés után (kérése válogatja, hogy mire "ugrik" a fail2ban, és az is, hogy mi az, ami sérülékenységet találhatott volna).

Mondd már, mégis mi a retkes lófasznak van értelme behozni erre egy plusz szoftvert? Azon kívül, hogy ha nincs, akkor éjjel riadtan felébredsz. Milyen sérülékenységről beszélsz?

Igaza volt, nem vagyok álszent, a balfasz és a lófasz pedig kettő igen gyakran használt kifejezésem, mind szóban, mind írásban, úgy nagyjából a harmadik értetlenkedés után szoktam használni. És bizony ezzel együtt álszentnek gondolom azokat, akiket ez a két kifejezés írásban használva teátrálisan megbotránkoztat.

Volt a thread-ben más, kulturált írásos kommunikációban kevésbé tolerálható megfogalmazásod is.

Mint például? :)

Szóban még akár ráhúzható az "elmegy" kategória, de írásban én illendőnek tartom választékosan fogalmazni, és az alpáribb kifejezéseket kerülni.

Akkor ne olvass olyan szépirodalmi műveket, amelyekben vannak alpári kifejezések - pedig vannak szép számmal ilyenek - és tartsd magad mindettől távol eltartott kisujjal és megjátszott sértődéssel, biztos jobb lesz a világ.

Az írásban kommunikálás amúgy nem egy nemesebb módja a kommunikációnak és főleg írásban van értelme ezeket a szavakat használni, mert az összes metakommunikációs csatorna zárva van.

Valakinek ez persze biztos belefer es nem zavarja, de ha mondjuk velem elkezdesz akar szoban, akar irasban kurvaanyazni es egyeb modokon kulturalatlanul megnyilvanulni, akkor en is leszarlak es otthagylak. Teged egyaltaln nem fog zavarni, kiveve ha akarsz is valamit a beszelgetessel, mert nem fogsz lofaszt sem elerni. ;)

Amugy mi a cukros faszert kampanyolsz te itt ennyire a fail2ban ellen?  Ha nincs szukseged ra, ne hasznald, mas meg hagyj csinaljon amit akar.

Amugy mi a cukros faszert kampanyolsz te itt ennyire a fail2ban ellen?

Mert onnan indultunk, hogy elég sokan ajánlják, és érdekel, hogy mivel indokolják az ilyen placebo és homeopátia-szerű dolgok használatát egy mérnöki területen, ahol általában azért használunk dolgokat, mert objektív szempontok szerint van értelme. Az, hogy nagyobb a biztonságérzet, meg az, hogy ártani nem árt (pedig de), az nem objektív szempont, az egy szubjektum.

Ha nincs szukseged ra, ne hasznald, mas meg hagyj csinaljon amit akar.

Akkor minek szállsz bele egy olyan témába, ahol kétségbe vonják a létjogosultságát? Ha szükséged van rá, használd, mást meg had csináljon, amit akar. Nem?

Valakinek ez persze biztos belefer es nem zavarja, de ha mondjuk velem elkezdesz akar szoban, akar irasban kurvaanyazni es egyeb modokon kulturalatlanul megnyilvanulni, akkor en is leszarlak es otthagylak.

FYI: abban a szálban, amivel veled tárgyaltam, te írtad le először ezeket a szavakat: "fossak tele a logodat fassaggal", "nem szarozik", szóval kissé hipokrita dolog ezek után kikérni magadnak a "lófasz" szót leírva látni.

Amugy mi a cukros faszert kampanyolsz te itt ennyire a fail2ban ellen?

Én pl. nem a fail2ban ellen, hanem a security by obscurity ellen kampányolok. Miért? Mert minél többen hiszik azt, hogy a rendszerüket nyugodtan lukasan hagyhatják, majd a titkolózás megvédi őket, annál több eleme lesz a botneteknek, annál több kártékony szeméttel lesz tele az az infrastruktúra, amit én is használni szeretnék.

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.

Így valahogy. A botok és bekérdezések nem azért vannak, mert a sok önérzetes köcsög nem használ fail2ban-t és ha mindenki használna, akkor megszűnnének ezek a kéretlen kérések, hanem azért, mert tonnányi gazda nélküli szerver van magára hagyott biztonsági hibás szoftverekkel, amelyeket a fail2ban nem véd meg.

Korrekt üzemeltetéssel a fail2ban, portknock és társai feleslegesek. Hanyag üzemeltetésnél pedig nem védelmi eszközök.

Szerk: miért csak az a gond, ha bejutnak? Ha egy felhasználó hozzáférését szerzik meg, amivel nekiállnak spammelni, adatokat módosítani a CMS-ben, stb... az nem annyira nagy gond?

Írd le, légy szíves, hogy ettől hogyan véd meg a fail2ban, mert nem nem sikerült követnem a gondolatmenetedet!

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 a támadó 1000 mintájából te a 123.-kal vagy felnyomható, és az már nem jut el a kiszolgálószoftverig, mert valamilyen folyamat már előtte elkezdte szűrni/tiltani az adott támadótól érkező forgalmat, akkor attól a 123. minta alapján történő töréstől nagyobb biztonságban vagy, mintha semmit nem tennél.

Ha a támadó 1000 mintájából te a 123.-kal vagy felnyomható, és az már nem jut el a kiszolgálószoftverig, mert valamilyen folyamat már előtte elkezdte szűrni/tiltani az adott támadótól érkező forgalmat, akkor attól a 123. minta alapján történő töréstől nagyobb biztonságban vagy, mintha semmit nem tennél.

Mi van, ha nem a 123. a listájában, hanem az első? Mi van, ha rotálják véletlenszerűen a puhatolózást? Mi van, ha azt látod, hogy elosztott puhatolózás jön be, a szokásos 50-60 elemű PHP listát 50-60 IP címről látod beesni nagyjából egy időben? Mi van, ha nem egyszerre esik be, hanem egyesével t idő múlva, ugyanarról az IP-ről? Mindegyikre tudok példát mutatni.

nagyobb biztonságban vagy

NEM VAGY NAGYOBB BIZTONSÁGBAN PONT

Tudsz olyan példát mutatni, amire nem jó - ezt elfogadom, én meg tudok olyanra, amire igen. Nem mindenható, nem univerzális eszköz - de van olyan, amikor az egyszerű logsorok mintaillesztésével működő megoldás is elegendő bizonyos keresgélések kizárására. És mint írtam, ha legalább egy puhatolózást meghiusítok vele, már jó.

Tehát nyugodtan szaglásszon bárki, bármennyit szabadon, azzal, hogy a szaglászónak nem koppintok az elején az orrára, azzal nem veszélyeztet senkit... Aha. Tehát ha egy gyártelep környékén kóválygok folyamatosan, és nézegetem a zárakat, a nyílászárókat/rácsokat/ezt-azt, azzal nem csinálok semmi rosszat, sőt a biztonsági szolgálat se zavarjon el, mert csak.

A szervered nem egy gyártelep, nem fognak pusztán attól bejutni, hogy tudják, konkrétan mi nem fut a szervereden, ezek ellen semmit nem véd a fail2ban.

Ha meg éppen fut olyan, ami sebezhető, azt meg nem tudod megkülönböztetni a legális kérésektől, az ellen szintén nem véd a fail2ban.

És korábban hoztam példát arra, hogy a szaglászás jó része faszán egy-egy kérés különböző IP címekről, ami ellen szintén nem véd a fail2ban.

Nézd, ha brutal force bármit el lehet rontani a rendszereden, akkor azt javítsd meg inkább. Még tüneti kezelésnek se jó, pláne, ha a szűkös IPv4 tartományból jól kizárod egy szolgáltató fél ügyfélkörét, mert a közös NAT mögötti gépről egy bot próbálkozik 100-150 kéréssel. Ennél több nem "brutal force", ha nevezhetjük így, nem hülyék, hogy pazarolják az erőforrásaikat, az ilyesmi inkább technikai klienshiba.

Egy esteben vagy nagyobb biztonságban: ha kihúzod a hálózati kábelt (adat- és elektromos egyaránt) a gépből. Az összeset. Is. :-D

Ja, és persze leöntöd benzinnel, és jól felgyújtod az egészet :-D És mellé hülyére iszod magad, hogy a kritikus adatokat afejedből se lehessen semmilyen módon kidumpolni :-D
 

ez itt egy fail2ban létjogosultságáról szóló vita. éppen attól meddő, hogy olyanokat írsz, hogy "Ennek a kérdésnek semmi köze a fail2ban-hoz. Általánosságban tettem fel.", "szíved joga azt használni/nem használni, amit akarsz." vagy "ha nem akarsz f2b-t használni, nem használsz. Aki akar, az pedig használ."

ezekkel szerinted érvek egy szakmai vitában?

Ennek a kérdésnek semmi köze a fail2ban-hoz. Általánosságban tettem fel.

Láttad az előzményt is? Ezt kérdeztem: Mikor mondható egy rendszer biztonságosnak? Honnan tudod, hogy biztosan nem jutnak be? Azért bátorkodtam megkérdezni, mert próbáltam megérteni a szemléletét. Szerintem ez simán egy szakmai vita, csak egy lépéssel hátrébb állva.

A következő idézett rész pedig nyilván azért íródott, mert  már nem látom azt, hogy közelednének az álláspontok, mondhatni meddővé vált, tehát ezek a mondatok kvázi következmények, nem okok.

Ez lehet pár perc is, meg lehet sokok perc is, ha tele van hányva minden hülyegyerek többszáz próbálkozásával.

A telehányást ugyanazokkal a feltételekkel tudod szűrni, mint amit a fail2ban is megkapna, de amúgy ezekkel együtt teljes a kép, hogy támadják-e a szervert, illetve nem volt-e false positive fail2ban, ami biztos, hogy lesz, csak sok esetben nem tudsz róla.

Nekem a fail2ban például ott bűzlik, hogy manapság a szolgáltatók egy rakás klienst benatolnak egyetlen IP mögé. Ezek tipikusan low-cost nem tech-savvy userek - például mobiltelefonok vagy otthoni netelérések. Közöttük simán lehet felnyomott telefonos, akin éppen megy a kiddie script, ami miatt kizárod az IP-t. A másik pedig épp a fizetős ügyfél lenne, akit így elbuksz... Ez a baj a fail2ban-nel.

 

Hasonlatos ahhoz, hogy a spamek miatt a szolgáltatók mindenféle feketelistákat tartanak karban, amire akár véletlenül is fel lehet kerülni, aztán napokig nem működik a céges levelezés... Erre is normális megoldást kellene adni feketelisták helyett, de egyelőre ez van.

Amire válaszoltál, abban ez a két kérdés volt:

1) Miért kellene megkímélni a botoktól és az amatőr hülyegyerekektől, ha biztonságos a rendszer és úgyse tudnak bejutni?

2) Ha a botok és az amatőr hülyegyerekek próbálkoznak és lepattannak, de nincs fail2ban, akkor miért kell bogarászni miattuk a logot, és miért kell bannolgatni őket?

Légy szíves, írd meg, hogy a válaszod szerinted melyik kérdésre válaszol, mert nem vagyok benne biztos. (Az 1-esre tippelek egyébként)

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.

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.

Ja, ha Debian/Buguntu, akkor az sshd_config-ba: DebianBanner no

Van valami konkrét oka, vagy csak az általános elővigyázatosság, hogy a másik oldalnak nem kötjük az orrára azt, ami nem tartozik rá?

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.

Minél kevesebb explixit információt adunk, annál kevesebb alapján lehet célzottan támadni. Tehát például az e-mail borítékból a hálózatunk utolsó smtp-t kezelő eszközén a kifelé menő levelekből a belső kézbesítési láncot kidobjuk, az MTA-ta jellemző header-eket dettó, ahogy webszervernél péládul az X-Powered-by headert sem engedjük ki a végfelhazsnálóig, és a Server-t is illik valami semlegesre átírni, vagy mondjuk ha névszerverként bind van felhúzva, akkor ott illendő a named.conf.options fájlba begyógyítani, hogy ,,version "BIND"; '' - ekkor nem csacsogja el magáról, hogymilyen verzió... és még lehetne sorolni az infrastruktúráról árulkodó apróságoknak a gyomlálását :-)

Igen, erre a gyakorlatra utaltam, amikor az általános elővigyázatosságot kérdeztem.

Akkor átfogalmazom a kérdést: van oka, hogy a Debian/Buguntu-t kiemelted?

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.