Biztonsági vizsgálata egy webhelynek

Web, mail, IRC, IM, hálózatok

El fog jönni hamarosan az az idő, hogy hozzáértő szakemberrel kell átnézetnem a webhelyemet a biztonság tekintetében. Aki úgy érzi, hogy ebben kompetens, szívesen látok üzenetben erre jelentkezést. 

  • 1742 megtekintés

( djtacee | 2023. 02. 14., k – 12:43 )

Örülni fog a Contabo, ha penetrációs tesztekkel fogják támadni / terhelni a szervert. Úgy b*sznak majd ki mint Cirmit sz*rni... Még mindég nem érzed hogy fogalmad sincs hogyan működnek a dolgok?

Egészen addig, amíg egy közvetett vagy közvetlen károsult nem ír az abuse címükre. Egy ismerős Contabo-ján futó WP oldalt nyomtak fel, valamelyik nagy futárcég felületét hamisították és próbáltak behúzni embereket. Persze mail-t nem nézett, az oldallal szintén volt valami tengés-lengés, én csak a szervert adminisztráltam. A lényeg, hogy a Contabo nullroute-ra rakta a VPS-t és a visszakapcsolásért valami 39 Eurót követeltek az abuse dolog miatt, miután a gép gazdája 24 órán belül nem reagált a megkeresésükre. Itt lettem bevonva:D

 

Szerk: Bocs, djtacee-nek akartam reagálni a kommentjére link.

TheAdam

Tapasztalatom szerint nagy ívbe tesznek rá, januárban egy volt az ötből aki válaszra méltatott (pedig ez az easy mód megkapják a ruszki alexusmailer script helyét csak le kell törölni). Ők letörölték két nap múlva írhattam a levelet , hogy másik helyen ugyanazon a hoston, akkor úgy letiltották, hogy az ügyfelük nem tudta visszakapcsolni. 

A Contabo-s ipk nagy része hónapok óta ontja a szart mindenféle report nélkül fel kellett volna , hogy tünjön nekik. 

De amúgy kishazánkban is ez van:
https://www.abuseipdb.com/check/91.219.236.239 (2022. október)
https://www.abuseipdb.com/check/94.199.178.57 (2022. augusztus)
https://www.abuseipdb.com/check/185.33.55.101 (2022. december)

Azt, hogy irracionálisan nagy félelem van a nyitott SSH port kapcsán, miközben nem törnek halomra nyitott SSH-n keresztül jól beállított gépeket (tételezzük fel, mint minimum, hogy kell hozzá kulcs, jelszóval nem érhető el és root se érhető el). Az, hogy különféle kreatív módon eldugom az SSH-t, adott esetben magamat megszopatva, az nem csökkenti érdemben a _szofisztikált_ és célzott betörés kockázatát, az ilyen automatikus próbálkozások meg 0.000 százalék kockázattal járnak, ha jelszóval amúgy se lehet bejutni, mert csak azt próbálják. Ha nyitott SSH-n nem jutnak be, az biztonság. Az, hogy eldugom, az csak biztonságérzet.

https://iotguru.cloud

2004-től nagyjából pár évvel ezelőttig én is csak eldugott SSH portot használtam, kutya se kereste. Aztán pörgött az auth log  a sok próbálkozástól és zavart. Aztán itt is mondták többször, hogy azért előfordul ssh bug is. Szóval jobb félni, mint megijedni alapon inkább IP szűrést tettem rá, ami jellemzően egy VPN kijárat. Úgy látom ma már ez a tipikus megoldás. Nem láttatunk kintről szolgáltatásokat csak védett IP-ről vagy VPN-ről.

Az eltolt port tényleg álbiztonság, az IP szűrést már nem érzem annak. A teljes publikus IP tartományból engedek max 5 biztonságos IP-t. Nem tudják piszkálni manipulált csomagokkal, amik esetleg 0day sebezhetőséget tartogatnak. Oké, nem gyakori, de akkor se piszkálják, ha van rá gyors védelem: néhány IP-ről jövő csomagot engedek csak el a szolgáltatásig. Bízok a linuxban, kemény a linux, de azért szárazom tartom a puskaport :)

2004-től nagyjából pár évvel ezelőttig én is csak eldugott SSH portot használtam, kutya se kereste. Aztán pörgött az auth log  a sok próbálkozástól és zavart. Aztán itt is mondták többször, hogy azért előfordul ssh bug is. Szóval jobb félni, mint megijedni alapon inkább IP szűrést tettem rá, ami jellemzően egy VPN kijárat. Úgy látom ma már ez a tipikus megoldás.

Oké, szóval kb. 90 százalékban zavar, hogy pörög a log és 10 százalékban félsz egy 0day sebezhetőségtől.

Nem láttatunk kintről szolgáltatásokat csak védett IP-ről vagy VPN-ről.

A többi 0day sebezhetőséggel mi van? Nem szolgál ki semmit a gép? Intraneten se?

Nginx-nek volt tavaly harmincvalahány security fix, ebből négy remote exploitable, OpenSSH-nak tavaly volt egy security fix, az is egy key parser segédprogramot érintett. Melyik a veszélyesebb, hogy ki van nyitva a port? El kell tenni a 80-as és 443-as portot a világ végére és VPN mögé kell tenni? Vagy, ami a legtöbb esetben történt: mindenki nyugodtan aludt, mert az SSH el volt téve a világ végére és be volt tapasztva sárral a kulcslyuk.

Bízok a linuxban, kemény a linux, de azért szárazom tartom a puskaport :)

Szerintem elpazarolsz egy csomó erőforrást és kognitív kapacitást olyan támadási vektorra, amin keresztül szinte 100 százalék, hogy nem fognak megtörni, aztán meg nyugodtan hátradőlsz és n+1 szolgáltatás pedig kinn van csupasz seggel és még csak végig se gondolod, hogy miképpen kellene azokat védeni vagy támadják-e épp valamivel, van-e napok vagy hetek óta ismert sebezhetőségük. Az a bajom, hogy sok esetben az SSH az alfa és omega, ha az el van rekkentve valahova vagy el van takarva a kulcslyuk, akkor biztonság van. Pedig lófaszt van biztonság ettől...

https://iotguru.cloud

A 90-10%-t arányt passzolom. Mint okokat felsoroltam.

A többi 0day sebezhetőséggel az van, hogy van és ez maradék kockázat. Viszont _amit_tudunk_ azt tegyük láthatatlanná. Az SSH-t és bizonyos kiszolgálás esetén FTP, különféle webadminok simán IP szűrhetőek, ha nem nagyközönségnek szolgálunk ki. Amik nem, ott marad a jó reménység meg a körbe bástyázás, a rendszeres frissítés, webre pl. mod-security

Nem mondtam, hogy ettől kezdve király atom tutkó minden és hátra lehet dőlni. De amit meg lehet tenni, miért ne tegyük meg? Itt a fókusz, most az SSH-n volt.
Én több erőforrás pazarlást érzek abban, hogy _feleslegesen_ pörög az auth.log. 1 okot kérek: miért pörögjön? Ezáltal felesleges I/O. Ha keresek valami hasznosat az auth.logban, akkor pedig zaj. Miért ne offoljam, ha kb 1 perc melóba kerül egy whitelist addolása? Több előnyt látok a szűrésben, mint a nem szűrésben.

"amin keresztül szinte 100 százalék, hogy nem fognak megtörni,"

Erről ment 1 hete pont kis parázsvita a biztonságos backup tárolás témában. Nagyon ment az aggyolás, hogy az SSH-n is bejöhetnek. Én nem merem 100-ra tenni a garanciát a védelemre, de valóban csekély, kb a legutolsó az esélye. Azért, amit lehet, úgy gondolom, megtesz az ember, főleg ha ez nem jár macerával. Nekem nem jár és aki kicsit szerverkedik, van már pár fix IP-je.

Itt a fókusz, most az SSH-n volt.

Igen, tudom. Én is azt írtam, hogy a fókusz az SSH-n van, irreálisan felnagyítva a kockázatot.

Az van, hogy az ilyen helyeken gyakori, hogy az SSH port a világ végén van, egész komoly rituáléval lehet elérni, hogy nyíljon, az is IP szűrve... az nginx meg 2021 végén frissült utoljára, amikor az egész gép telepítve lett, újraindítva nincs, mert uptime-fétis van és különben is kiesés van az újraindítás idejére, meg félünk az újraindítástól, mert mi lesz, ha valami nem indul el vagy nem lesz jó, satöbbi. Nincs nagy mintás reprezentatív felmérésem, de több tucatnyi helyen jártam, ahol különösen védett volt az SSH port, a rendszer többi része meg mind le volt szarva, aztán csak azon múlt az, hogy nem járt ki-be a fél internet a gépeken, mert a kutya nem volt rá kíváncsi különösebben, de ha egy gyakornok hekker ránéz szombat délelőtt másnaposan, akkor is átmegy a rendszeren, mint forró kés a vajon.

Igen, fontos az SSH védelme, de súlyozzuk a kockázattal a védelmét és ezt végezzük el az egész rendszeren, aztán lépegessünk végig a listán és ha eljutunk az SSH-ig, akkor védjük meg, addig meg foglalkozzunk a többi kockázatosabb vektorral. Na, ez az, ami a legtöbb helyen hiányzik, SSH pipa, a többi le van szarva, aztán néznek, mint a kiszántott egér, hogy megtörték a szervert, pedig az SSH az védett.

Igen, lehet, hogy te kivétel vagy és az SSH védelme már csak a cseresznye a torta tetején, minden más kockázatosabb támadási vektor már blokkolva van.

https://iotguru.cloud

Igen, egyetértünk. Egyen szilárdságra kell törekedni, anélkül önámítás az egész.

Ha van web oldali védelmi tipped, szívesen fogadom (legalább ontopic leszünk:) ). Nálam egyébként az nginx biztonságosabb az apace és főleg a windowsos IIS-hez képest. mondjuk úgy, az értelmesebb webszerver/proxy-k közül a legbiztonságosabb.(Tényleg, van jobb?)  Ha bármelyiket, főleg ha IIS-t kell kirakni webre, szívesen teszek elé nginx-t mod-security kiegészítéssel, mint egy WAF. Tudtommal nem csak php által értelmezhető csúnyaságokat fog meg, hanem a backend webszervert is bevédi a rá veszélyes manipulált csomagoktól....aztán lehet, hogy ez csak urban legend.

Jaj, az újraindítástól való félelem az egyik nagy kedvencem. Igaz, hogy éjjel 2--3 körül a kutya sem használja a szolgáltatást, de három tiszteletkört futunk, mert 'jaj, mi van, ha nem indulnak el a szolgáltatások'... A frissítés miatti szolgáltatásújraindítás is ilyen, de ha az egész rendszert kell, na ott aztán minden meggyőzőképességre szükség van.

 

Ha egy szolgáltatás újraindítás után nem indul el hiba miatt, az futva is hibás és csak idő kérdése, mikor bukik ki.

 

Az SSH portátrakosgatása tényleg nem ér valami sokat, kizárólag a logok mennyiségét lehet vele ideig-óráig redukálni, de amúgy kulcsos belépés és a portmozgatás helyett VPN, bár ennek is csak akkor van gyakorlati haszna, ha a gép nem nyújt publikus szolgáltatást, mert ha figyel rajta egy webszerver, akkor azért feltételezhető, hogy manage-elik valahogy és ha az SSH rejtve is van, vannak szép számmal szoftverek, amit nem lehet eldugni mert nem éri el a nyilvánosság akiknek szól. Ha van kellő motiváció, úgy is lesznek próbálkozók és nem az SSH portján fog múlni az esetleges behatolás, emiatt a komplex védelem fontosabb mint egy szolgáltatásra kihegyezni.

 

( andrej_ V | 2023. 02. 14., k – 16:39 ) Permalink

Üzemeltetek shared hosting-ot, illetve besegítek. Az ügyfelek nem szeretik frissíteni a WP-t és a bővítményeket mert 'elromlik'. Én még nem mondanám magam nagyágyúnak a témában, néhány éve tanulom :), de felnyomott SSH-t még nem láttam (illetve de, a root és az 1234 jelszóval), de felnyomott WP-oldalak tucatjával találkoztam és ebben főleg az a veszélyes, hogy sokszor ki sem bukik, hogy adott oldalt esetleg nem csak a gazdája használja, hanem felnyomták és esetleg kártékony tartalmat terjesztenek róla. A cPanel IMUNIFY360-asa csuda dolgokat szokott mutatni, ezt jelzem az adminnak meg esetleg az ügyfélnek  és semmi sem változik:). Rengeteg WP-oldalt hanyagolnak és hagynak magára később, viszont a népszerűsége miatt úgy törik mint a lyukas sajtot.

TheAdam

Az újraindítástól való félelemhez:

- Egyrészről nem hajnali 2-3-kor kell kitalálni, hogy egy szolgáltatást / szervert újra kell indítani - kivéve vészhelyzetben. Egy normális helyen alkalmazzák az ITIL-t. Van change mgmt, van valamiféle change approval flow, amin végig kell menni, vannak approverek, van change approval meeting, ahol a change ownernek prezentálnia kell a change-t, van risk mgmt, van key account manager, aki szintén rábólint a change-re stb. Ideális esetben a teljes process végigfut 1-2 nap alatt.

- Láttam már olyat, hogy azért nem merték újraindítani a Linux/Unix gépeket (Windowsoknál valamilyen rejtélyes okból nem volt ilyen gond), mert nagy (90%) valószínűséggel a gépek nem bootoltak be rendesen, nem volt hálózat, hiányoztak route útvonalak, szolgáltatások nem éledtek fel stb. Egyszerűen mindenki félt a helyzettől, mert az incidens után a change owner megkapta a kínos kérdéseket a risk / change / incident / problem mgmt teamtől / ügyféltől, hogy "Ezeket miért nem láttátok előre? Hogy fordulhatott elő?" stb. Továbbá jöttek az "okos" javaslatok, hogy legközelebb hogyan kerülhetjük el ezeket. Aztán amikor ezek alapján egy egyszerű gép újraindításhoz is 10 csapat, 10 ember kell a change window időtartamára (mert mi van, ha beüt a krach), akkor meg azért sírt a mgmt, ügyfél.
Nyilván kis cégnél, kkv-nél vagy a saját szerverednél, amit ismersz, mint a tenyered és nem matat rajta 500+ másik sysadmin, ott egyszerűbb a helyzet. Elviekben.

- Vannak olyan kollégák, akik imádják a másikra áttolni a problémát. Csinálnak valamit, valahogyan, majd ha összedől a gép például reboot alatt, akkor felteszik a kezüket ("Én nem csináltam semmit.", "Nem az én change-m okozta a galibát...", "Majd az XY team megoldja."). Minden csapatban van ilyen felelősséget hárító személy. És ha tudom, hogy ilyen kolléga matatott a szerveren, akkor 2-3-szor is le kell ellenőriznem, hogy minden oké lesz-e újraindítás után. Plusz stresszfaktor az ilyen kolléga. Ezt a plusz stresszt pedig senki se szereti.

Így van, szoktam mondani, hogy

1, ha félsz valamitől, csináld gyakrabban,

2, ha meg már gyakran csinálod, akkor automatizáld.

--

Ha egy újraindítás hibát okoz, akkor az ott egy üzemeltetési kockázat, addig kell javítani a gépeken, amíg egy újraindítás teljesen rutinná nem válik, amit bármikor meg mernek lépni. Ha a munkaidő elején, kipihent fejjel nem lehet megoldani, akkor éjjel háromkor vagy akár a munkaidő végén egy üzemzavar után pláne nem lehet megoldani.

https://iotguru.cloud

Félig off, de ebben maximálisan Frankoval értek egyet. Nincsen fix IP-m (a szerveren túl, ahova pont belépek publikus ssh-n..), de a vasamra belépek otthonról, a cégtől, mobilnetről, innen-onnan még, felesleges időpazarlás lenne szűrögetni, magammal szúrnék ki. Jó magas port, root tiltva, csak kulcsos auth, innentől kezdve nincs miről beszélni.

Azért, mert több tucat szerverhez elég 1-2 bevált VPN és bejárom vele a kezem alá tartozó szervereket :)
Másik esetben meg mindig másik VPN-re kellene felmennem. Van 1-2 olyan VPN, ami a teljes forgalmat VPN-be tereli, így a random IP-mből mindjárt fix IP lesz.

De igazad van, ha csomagban nézzük, egy céges szerverpark elé céges VPN dukál és csak azon belül van terülj-terülj asztalkám :)
Csak nekem több ilyen céges szerverpark van kezelésben, így egyszerűsítek. Mielőtt félreértés történik: VPN után is legalább olyan szigorú auth van, mint ha neten lenne kint. CHS és UNIX óta főleg tudjuk, hogy ami bent van még nem feltétlen biztonságos. A trójai faló manapság nagyon falánk :)

Korántsem ugyanakkora. Áthelyezett port estében pont ugyanannyi IP-cím számára elérhető a szolgáltatás, míg tűzfal esetén jelentősen csökkenthető azon IP címek száma, amelyek egyáltalán próbálkozni tudnak. Vagy szerinted a tűzfal ha egy IP-t beenged, akkor mindegyiket be kéne? Ha nem, akkor nem ugyanaz a biztonsági lépcső.

Ha más a lépcső magassága, akkor nem ugyanakkora.

Kezdtek óta ezt írtam.

És továbbra sem security by obscurity.

De, ez az. Ha attól gondolod biztonságosabbnak, hogy bizonyos irányokból eltakarod, hogy abból az irányból ne látszódjon, akkor az security by obscurity. Ha eltakarva és nyíltan is ugyanannyira biztonságos, akkor az biztonságos. Akkor viszont teljesen felesleges takargatni. Ha azért rejtegeted, mert nem tartod biztonságosnak, akkor nem biztonságos és a rejtegetéstől nem lesz biztonságosabb, csak a biztonságérzeted lesz nagyobb.

Még mindig az a bajom, hogy egy viszonylag minimális erőfeszítéssel (= default telepítés) kb. feltörhetetlen SSH porton figyel egy faék egyszerű szolgáltatás, amit mindenki kurva kritikusnak tart, hogy rejtegesse és takargassa kreatív módszerekkel, aztán meg ugyanazon a gépen ott van egy nagyvilágba nyitott HTTP/HTTPS, mögötte egy kurva komplex rendszer és igazából senkinek halvány lövése nincs arról, hogy mennyire védett a rendszere ezen a portokon keresztül, viszont általában root jogot lehet szerezni exploit-on keresztül és/vagy minden adatot ki lehet pakolni, mert nincs semmilyen demarkációs vonal, ami ezt megakadályozná. De legalább az SSH az védett.

https://iotguru.cloud

Szerződéses szinten kell bizonyítanod, hogy a környezetben a szolgáltató engedi ezt (és pontosan mikor és milyen típusú teszteket). Egyébként a tesztelő cég (már ha a jogi hátérrel is tisztában vannak) neki sem áll, mert őket fogják "elvinni". Főleg ha shared infrán futtatják a site-odat, nagy seggberúgás lesz mindkettőtöknek.

Kíváncsi vagyok hány helyen van rászabadítva az NKI ASR-je shared hosting szolgáltatókra, egyszer jól összevitáztam az akkori biztonsági prütypürüttyel, hogy minek tesztre beírni egy pusztán információs honlapot ha nem nálunk van hostolva.  ;)

Megállapítják , hogy ez meg ez szar/critical a versenyszféra 10k/év shared hostján azzal én mit kezdjek, deakkorizbekellirni.

Nem tisztem a shared hostokat védeni, de jellemzően nem a shared alatti bármi lesz a sebezhetőség fő forrása, hanem az 1758-ban felszórt CMS, és a "jajjkipróbáljukjólesz" bővítmények garmadája. Egy Joomlát vagy WP-t igen hamar megnyomnak, hogy ha csak elavult a verzió. (A többi sem sokkal jobb ha elfelejtik, de a Joomla és WP a fő célpont jelenleg.) Egyébként látok NKI ASR szken url-eket néha az access logban ittott, és mosolygok is, hogy tényleg a 4.x Wordpressen csekkolnak le bármit?

Azt is látom, hogy sokszor a bővítmények könyvtárában talán a bővítménnyel letöltött! malware file kerül meghívásra 2-3 évvel az oldal indítása után.

Értelem szerűen a konkrét biztonsági beállításokon túl (amit speciel nem lehet túlzásba vinni a csodálatos igényekkel rendelkező felhasználók miatt, lásd egy erősebb WAF) egy Linux disztró frissen tartása nem egy veszedelmes feladat. A támadóknak sokkal jobban megéri a CMS specifikus bugokat keresni, mert az hiába vaktában lövöldözés, valami frenetikus a találati arányuk.

Nem is a shared hostokat szándékoztam bántani, csak felesleges beírni szerintem (és ismerős a valaki jópénzért "lefejlesztette" és azóta is ott rohad témakör is), utána meg engem zaklat, hogy miért van nyitva (nem hozzám tartozik nem érdekel) ez meg az (mondjuk router webadmin port kinn figyel tényleg durva, de nem ismerem és nem is tisztem ismerni, hogy kinek milyen jó biznisze ez ha zavarja hívja fel őket ;)) Hagyjuk meg a versenyt a szférának.

Ami szintén érdekelne, hogy ilyenkor tök védtelen rendszert akarnak tesztelni vagy a védelem maradhat-e, mármint, hogy normális esetben ilyenkor azokat az IP-k amiket az ellenőrzésre használnak whitelistelve vannak a tűzfalon (most is úgy van)/IDS-en/waf-on (könnyített pálya), vagy a valóvilág kellene, hogy legyen az ellenőrzött környezet.  

Hát ez sajnos a elég sok ügyfélnél nem alap.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Ez is alap, hogy bármilyen vizsgálatot és szerverterhelő tevékenységet végeznénk, előtte szolgáltatóval egyeztetés.

Szépen kérlek ne nézz minket hülyének. A Te szinteden teljesen egyértelmű hogy eszedbe sem jutott ilyen egyeztetés, ha én nem hívom rá fel a figyelmed. Pláne, hogy az az IP cím amin a tákolmányod jelenleg lakik egy sharded hosting szerveré, nyilvános adatbázis szerint közel 200 aktív weboldallal. Senki nem fogja neked engedélyezni, és itt kellett volna kezdeni ha valamit is értenél hozzá.

A Te szinteden teljesen egyértelmű hogy eszedbe sem jutott ilyen egyeztetés, ha én nem hívom rá fel a figyelmed. 

A te szinteden viszont lehetnél szerényebb is.

Fogalmad sincs arról, hogy milyen egyezség van közöttünk a szolgáltatóval. Ne legyél már szerencsétlen kérlek.

"https://hunvagyok.hu "

Mondjuk az is sokat segít, hogy egy legalább OWASP TOP10-t kezelő WAF mögé teszed a site-odat. Ez nem egy eget verő összeg.

Időszakosan egy PT és pl egy heti automata web application scan is mehet rá, de ezeknek azért szemmel látható költsége lesz, de van ahol ezt igénylik (és megfizetik). Mi pl InsightAppSec-et használunk az automata scannelésre.

( neutrino v | 2023. 02. 14., k – 13:23 )

Tessék, itt van pár cég:

https://www.alef.com/hu/penetration-teszttel-es-serulekenysegi-vizsgala…

https://zeroitlab.com/hu/penetration-teszt

https://trinity-service.hu/szolgaltatasok/ethikus-hackeles-penetration-…

 

De ami még jobb és hasznosabb, az a pentest tanfolyam!

https://masterfield.hu/hu/tanfolyamok/penetration-tester-tanfolyam

Szerintem itt az utóbbival mennél a legtöbbre, elvégre te vagy egy személyben a marketinges, a fejlesztő, az üzemeltető. Legyen mellé egy tesztelő titulus is, mindenképp jól mutatna!

1904.04.08.
RIP Jákub.
neut @

( kikepzo | 2023. 02. 14., k – 14:08 )

Szerkesztve: 2023. 02. 14., k – 14:09

Értelemszerűen nem ingyen kérek szakemberes segítséget, remélem ez alapból érthető :)

"https://hunvagyok.hu "

( Tom | 2023. 02. 14., k – 14:31 )

Szerkesztve: 2023. 02. 14., k – 14:45

Van egyátalán elképzelésed mennyibe kerül egy ilyen, ez nem "hamm cipó, megeszlek".

Hajlandó vagy kifizetni alaphangon 500k HUF összeget csak a tesztelönek ? Ha szolgáltató meg is engedné (kétlem) akkor ö is szeretne fájdalomdíjat, a jogi dolgokról nem is beszélve, mert az ügyvéd sem kifliért dolgozik.

Ha ez mind megvan és beleöltél sok milliót, tudod meddig lesz érvényes a "nem vagy támadható" cetlid, kb 15 másodpercig, de maximum az elsö bárminemü kód/beállítás változtatásig vagy telepítésig.

A Penetration Test-et felejtsd el, max annyit tudsz garantálni amit az OSSN vagy az egyéb feltett cucc ad: "nincs ismert támadási felület" ami addig jó ami nem találnak 1-et, akkor meg rajtad áll hogy frissítesz-e, ha nem akkor mégy annyid sincs hogy "bakfitty".

Ha nincs nagy igény, tényleg a html egy jó irány. Pl. Publii

Nekem is tele a csukám, hogy állandóan védeni kell a várat. Saját oldalam is drupalról html-re fog költözni. Hosszabb távon kevesebb macera. Ritka frissítésekre meg elő kell venni a Publiit és feltölteni a változást (program helyből megoldja).

tudod meddig lesz érvényes a "nem vagy támadható" cetlid

Komolyanvehető pentester nem ad ilyen cetlit. Olyan cetlit ad, amiben tételesen fel vannak sorolva a feltárt problémák, súlyosság, kockázat, stb. szerint, esetleg iránymutatással a megoldásukra.

Ha szolgáltató meg is engedné (kétlem)

Akkor szolgáltatót is kell váltani.

Értelmesebb helyen ezt úgy szokás megoldani, hogy a szolgáltató megcsináltatja a független auditot azokra a rétegekre, amit te nem tesztelhetsz (nem tudsz, nem szabad, stb.), ennek a jegyzőkönyvét odaadja az ügyfeleknek, a többire pedig megmondja, hogy mit szabad és mit nem. Például így.

Ezt a threadet olvasva (és ne vedd magadra, az egésznek a hangulata ilyen) az jön le egy laikusnak, hogy a pentesting az, amikor az auditor egy légzsilippel elzárt szobában elolvassa a papírra nyomtatott forráskódot. :)

Nem veszem magamra.

Ezt a threadet olvasva (és ne vedd magadra, az egésznek a hangulata ilyen) az jön le egy laikusnak, hogy a pentesting az, amikor az auditor egy légzsilippel elzárt szobában elolvassa a papírra nyomtatott forráskódot. :)

/vicc on

Ez a Readtest lenne, a Pentest az lenne ha tollal vonalakat huzogatna a papírra :)

/vicc off

Neki se állnék ilyennek, józan paraszti ésszel próbáltam megközelíteni a témát.

nyilván nem ad ki olyan "cetlit", ez csak egy nagyon leegyszerüsített zanzásítása a lehetséges kívánalomnak.

( _Franko_ v | 2023. 02. 14., k – 15:02 )

Publikáld, aztán észreveszed, ha feltörték. Vagy nem.

Amúgy, amennyire látom, minden fillért egyesével külön-külön megbaszol, szóval szerintem nem fogsz egy ilyen tesztre minimum 1-1,5 milliót kidobni. Az alatt pedig értelmes etikus hacker nem fog a dologgal foglalkozni... már az 100-150 ezer lesz, hogy beszéltek a feladatról, $100-$150 körüli óradíjak vannak ezen a területen.

https://iotguru.cloud

Bizonyos szint felett az ilyen milliós pentestek aprópénznek számítanak, sőt, az alkalmazás üzembe helyezésének kötelező elemei. Amíg nem érkezik rá áldás a független pentester cégtől, addig nem helyezhető üzembe. Nyugi, többen is dolgoztunk ilyen helyeken, szóval nem a levegőbe beszélünk.

Ha naponta nem is, de az utóbbi két évben kb. öt cégnél vettem részt ilyen tesztek megtervezésében és megrendelésében, ilyen árak voltak, gondoltam leírom, hogy mire számíts.

A fillérbaszás meg látszik az eddigi hozzászólásaidból, őszintén szólva fogalmam nincs, hogy miből lenne pénzed egy ilyen biztonsági vizsgálatra, de terítsd ki nyugodtan a lapjaid: mennyi pénzt szánnál rá?

https://iotguru.cloud

Ha naponta nem is, de az utóbbi két évben kb. öt cégnél vettem részt ilyen tesztek megtervezésében és megrendelésében, ilyen árak voltak, gondoltam leírom, hogy mire számíts.

Könnyű arcoskodni a cég pénzén. Csinálj ilyen vizsgálatot a saját zsebedre, utána nyomd beképzelt dumádat.

de terítsd ki nyugodtan a lapjaid: mennyi pénzt szánnál rá?

Ez az amit te nem fogsz megtudni tőlem soha sem.

"https://hunvagyok.hu "

Könnyű arcoskodni a cég pénzén. Csinálj ilyen vizsgálatot a saját zsebedre, utána nyomd beképzelt dumádat.

Baszki, te akarsz ilyen vizsgálatot, nem? Leírtam, mennyibe kerül. Jobb cégeknél több hónapos várólista van arra, hogy sorra kerülj, mit gondolsz, adnak majd kedvezményt, hogy leteszteljenek egy ki tudja hogy módosított sokezredik WP shared hosting szolgáltatást?

Ez az amit te nem fogsz megtudni tőlem soha sem.

Akkor nem lesz a webhelyednek biztonsági vizsgálata...

https://iotguru.cloud

Továbbra is arra próbaltak (tunk...) fentebb rávilágítani, hogy ez igencsak zsebbenyúlós. Ahol ilyen auditra szükség van, az jellemzően céges környezet, abból is a nagycéges. Ennek egyik oka a seggvédés, hogy óhát nézzétek 2 audit volt, mindkettő által talált hibát javítottuk, és azóta is hudeszekjúr minden. A másik ok, hogy egyszerűen ellenőrzik, hogy hogyan dolgozik az ájti, vagy esetleg jogszabályi (akár belső céges szabályzat) előírás.

Alap esetben egy szokásos CMS-sel összerakott oldalra különösebben nincs értelme auditot kérni, mert olyan amilyen. Ha frissíted (és frissen tartod), rendesen beállítod, akkor nagyjából jó leszel. Ha saját hatáskörű szerveren fut, akkor valamilyen WAF jellegű szabálycsomaggal lehet jobban védeni, illetve még shared hostingon is vannak lehetőségek egy kis erősítésre. Innentől egy audit nem fog neked érdemi plusz infót adni, esetleg valami fals pozitivot, vagy amit úgy sem tudsz javítani.

Minden esetre ha esetleg a publikummal megosztható, akár általánosságban szerintem érdeklődésre tarthat számot az audit által feltárt sebezhetőségek logikája, mibenléte.

Jahm, a szokásos reakciók. Előbb-utóbb senki sem fog hozzád szólni. Tulajdonképpen a legtöbben már most sem nagyon hozzád szólnak, inkább a problémára kíváncsiak (néha még azt is úgy kell kisakkozni, nehezített pálya..) és egymással beszélgetnek, de nem veled.

A kürtőskalács egy nagy lyuk, tésztával faszán körbetekerve.

( tibyke | 2023. 02. 14., k – 17:11 )

ooo, b*szki, most latom csak, hogy ki a szerzo......

( kruska v | 2023. 02. 14., k – 18:17 )

Szerkesztve: 2023. 02. 14., k – 18:17

Többen javasolták a WAF használatát.

A Cloudflare Pro csomag (20 USD / hó) ad neked egy menedzselt WAF szolgáltatást, amiben a szabályrendszert folyamatosan frissítik, benne vannak az elterjedt CMS-ek - így a WP - védelmére szolgáló szabályok a Cloudflare-től, OWASP ajánlások akár zero-day sérülékenységek ellen. Szóval minden, ami egy egyszerűsített de jól működő megoldáshoz kell, ha nincs erre komolyabb rendszer helyben.

Kapsz mellé egy CDN-t, DDOS védelmet is.

( uid_3194 | 2023. 02. 14., k – 18:47 )

Szerkesztve: 2023. 02. 14., k – 18:50

Csak neked kedvezményesen másfél milla (euróban). ...de mivel rólad van szó, így természetesen csak előre! ;)

( kisbetu v | 2023. 02. 14., k – 19:16 )

"Biztonsági vizsgálata egy webhelynek"

Ezt mi itt Hunniában úgy mondjuk hunul, hogy "Egy webhely biztonsági vizsgálata".

 

Köszönöm, hogy segíthettem.

"Normális ember már nem kommentel sehol." (c) Poli