Tudtok a fentire valamilyen szép, szabványos és biztonságos megoldást?
Semmilyen többletjogosultságot nem szeretnék adni a NodeJS-es szolgáltatásnak, ezt leszámítva.
Hozzászólások
Miért nem teszel elé egy reverse proxy-t? Azt Te felügyeled, futtatod a megfelelő módon, jogokkal. A NodeJS meg csinál amit akar (tud) az user jogaival mögötte.
+1 a reverse proxyra, de ha mindenáron direktben akarod, akkor tegyél fel egy DNAT szabályt, ami a 443-as portra érkező kéréseket átírja a kívánatos 1024 feletti portra.
És még az ssl kulcsokat is vegzodtetheted nginx-Ben, onnan sima http megy bármely porton: certbot könnyebben futtatható, ssl műveletek natív kódban vannak, nem egy js lib-Ben.
Illetve ha systemdvel hasznalod, a socketek is jok lehetnek, de azt meg kell neki tanitani.
Persze most még a priviledge dropot is, de az kicsit generikusabb. Cserébe a systemd abból a szempontból tisztább, hogy egyáltalán nem kell extra privilege a processnek
Nodejs kevésbé támadható, nincs benne véletlenül otthagyott myadmin path vagy egy char2000 sebezhetőség. De mivel a http részét nem felugyeled, barmi lehet benne. Deno projekt pont erre épült, alapból minden tiltott.
Simán csak összehasonlítottam két eltérő felépítést (apache by me + alatta alkalmazás vs. alkalmazás beépített webszerverrel)
Szoktam nézni évente, amikor megjelenik az új változata ennek: https://perishablepress.com/7g-firewall/ Elég sok regex kifejezés van benne, a felét nem értem, de jó látni, hogy ennyi mindennel lehet betámadni egy httpd+php kombót alapból/félretelepítve. NodeJs ezek ellen védettebb, de nem tudod az express.js-en kívül még mi van benne (a forrást megnézheted azért, az jó).
Ne haragudj, nehéz ezzel vitaktozni, mert teljesen irreleváns dolgokról beszélsz.
Hogy jön ide bármilyen php? Hogy jön ide bármilyen sql? Hogy jön ide bármi egy konkrét reverse proxy konfiguráción túl, amit a világ azért szokott kvázi defacto standard odatenni a nodejs elé, hogy egyrészt legyen ami skáláz, másrészt meg mert valamiért nem hiszik el a nodenak, hogy valóban jól beszél httpül :)
Az egyetlen dolog, ami kiderült a mondókádból, hogy nem nagyon érted miről beszélsz, de legalább teljesen irreleváns dolgokat hasonlítgatsz.
hacsak nincs abban a httpserverben valami mas kello ficsor (load balance, static fajl kiszolgalas, ssl, vhost, redirect, rewrite), hanem csak 1:1-ben proxy akkor ezt egy kicsit overengineered megoldasnak erzem. meg aztan a http parse+http build is felesleges eroforras zabaalas pl egy arm procin.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Hát, ebből az SSL kb mindig szokott kelleni, a static fileok szintén elég gyakran kellenek. Hamar ki szokott derülni, hogy redirect/rewrite kell, esetleg egy kis vhostolás, "szabvány" loggolás, header baszkurálás, CORSolás, franc se tudja ki szokott derülni, hogy kell. LBre nem tudom, hogy a node mennyire jól skálázódik magától horizontálisan, de ez az ilyen async alapú cuccoknál azért véleményes (ugye ha van is, mindenképp külön réteg), hogy nem jobb-e külső. Szóval nem szokott véletlen ott lenni valami. És értem én, hogy erőforrás, de azért egy nginxet zabálásnak nevezni egy node mellett, hát, megmosolyogtató.
Értem, így már valóban nem tűnik olyan jónak.
Csak szimpla érdeklődésképpen: ha foglalt már az adott (22) port, akkor ez nem fenyeget, ha jól értem. Jól látom?
Nagyjából. Simán net_bind_service capabilityvel nem nagyon fog tudni agyonverni másik processzt, anélkül meg listening portot lopni imho nem nagyon lehet.
Mondjuk azért ha elég türelmes a támadó, azt játszhatja, hogy árgus szemekkel figyel, hogy mikor engedi el az sshd pl egy service restart miatt, és lecsap rá, szóval azért nem teljesen esélytelen.
Ahogy krozoo is mondja, van benne kockázat éppen elég. De nem értem miért nem lehet felhúzni elég egy reverse proxy-t, csomagtelepítéssel együtt is megvan 5 perc alatt, ha ráérősen csinálod, egyszerű, tiszta, kényelmes megoldás, ennél bármi csak rosszabb lesz, tényleg nem látom mi az akadálya.
Hozzászólások
Miért nem teszel elé egy reverse proxy-t? Azt Te felügyeled, futtatod a megfelelő módon, jogokkal. A NodeJS meg csinál amit akar (tud) az user jogaival mögötte.
én is ezt tenném. Ez a szabványos, szokásos módszer.
Lehet hogy van privilégium-eldobásos módszer valahogy mint ahogy az apache indul, de én még nem találkoztam ezzel sehol.
Gábriel Ákos
+1 a reverse proxyra, de ha mindenáron direktben akarod, akkor tegyél fel egy DNAT szabályt, ami a 443-as portra érkező kéréseket átírja a kívánatos 1024 feletti portra.
És még az ssl kulcsokat is vegzodtetheted nginx-Ben, onnan sima http megy bármely porton: certbot könnyebben futtatható, ssl műveletek natív kódban vannak, nem egy js lib-Ben.
+1 egyetlen domain alá több processzben futó szolgáltatásokat is be lehet tenni.
A legalacsonyabb szintjén az is natív kód.
van csomo megoldas.
- rootkent inditod programod, bindolsz 443on, majd lefokozza sajat magat olyan userre amivel futnia kell.
- cap_net_bind_service=+ep
- reverse proxy
- iptables dnat
Illetve ha systemdvel hasznalod, a socketek is jok lehetnek, de azt meg kell neki tanitani.
Persze most még a priviledge dropot is, de az kicsit generikusabb. Cserébe a systemd abból a szempontból tisztább, hogy egyáltalán nem kell extra privilege a processnek
bindeled akarmelyik portra, es iptables redirect. a proxyt csak akkor ha valami extra is kell. iptables egyszeru keves eroforrast eszik
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Nodejst (meg bármi hasonlót) nem feltétlen tennék ki valami normális http server nélkül direktben.
Nodejs kevésbé támadható, nincs benne véletlenül otthagyott myadmin path vagy egy char2000 sebezhetőség. De mivel a http részét nem felugyeled, barmi lehet benne. Deno projekt pont erre épült, alapból minden tiltott.
Kac kac.
Mi a tökömért lenne bármi myadmin path ottfelejtve, meg hogy jön ide valami sql sebezhetőség.
Simán csak összehasonlítottam két eltérő felépítést (apache by me + alatta alkalmazás vs. alkalmazás beépített webszerverrel)
Szoktam nézni évente, amikor megjelenik az új változata ennek: https://perishablepress.com/7g-firewall/ Elég sok regex kifejezés van benne, a felét nem értem, de jó látni, hogy ennyi mindennel lehet betámadni egy httpd+php kombót alapból/félretelepítve. NodeJs ezek ellen védettebb, de nem tudod az express.js-en kívül még mi van benne (a forrást megnézheted azért, az jó).
Ne haragudj, nehéz ezzel vitaktozni, mert teljesen irreleváns dolgokról beszélsz.
Hogy jön ide bármilyen php? Hogy jön ide bármilyen sql? Hogy jön ide bármi egy konkrét reverse proxy konfiguráción túl, amit a világ azért szokott kvázi defacto standard odatenni a nodejs elé, hogy egyrészt legyen ami skáláz, másrészt meg mert valamiért nem hiszik el a nodenak, hogy valóban jól beszél httpül :)
Az egyetlen dolog, ami kiderült a mondókádból, hogy nem nagyon érted miről beszélsz, de legalább teljesen irreleváns dolgokat hasonlítgatsz.
Jóvanna
nodejs-ben ugye csak az npm által behúzott csillió dependency van benne amit a legritkább esetben ellenőriznek.
Gábriel Ákos
Így van. És a saját kód sem valószínű, hogy tökéletes.
Kum Gábor
Az akkor is probléma ha reverse proxyt használsz. Saját kódra én a Fortify-t használtam korábban, de JavaScript/TypeScript nem volt az erőssége.
Egyébként van npm audit, tessék használni.
hacsak nincs abban a httpserverben valami mas kello ficsor (load balance, static fajl kiszolgalas, ssl, vhost, redirect, rewrite), hanem csak 1:1-ben proxy akkor ezt egy kicsit overengineered megoldasnak erzem. meg aztan a http parse+http build is felesleges eroforras zabaalas pl egy arm procin.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Hát, ebből az SSL kb mindig szokott kelleni, a static fileok szintén elég gyakran kellenek. Hamar ki szokott derülni, hogy redirect/rewrite kell, esetleg egy kis vhostolás, "szabvány" loggolás, header baszkurálás, CORSolás, franc se tudja ki szokott derülni, hogy kell. LBre nem tudom, hogy a node mennyire jól skálázódik magától horizontálisan, de ez az ilyen async alapú cuccoknál azért véleményes (ugye ha van is, mindenképp külön réteg), hogy nem jobb-e külső. Szóval nem szokott véletlen ott lenni valami. És értem én, hogy erőforrás, de azért egy nginxet zabálásnak nevezni egy node mellett, hát, megmosolyogtató.
Köszönöm mindenkinek.
Egyelőre a cap_net_bind_service=+ep módszerrel próbálkozom.
Van ennek komolyabb kockázata?
Kum Gábor
Ha megtörik, fel tudnak bindelni más 1024 alatti portot is, és tudnak futtatni mondjuk egy kamu ssh servert, vagy dnst, vagy akármit rajta.
Értem, így már valóban nem tűnik olyan jónak.
Csak szimpla érdeklődésképpen: ha foglalt már az adott (22) port, akkor ez nem fenyeget, ha jól értem. Jól látom?
Kum Gábor
ha feltörte és root joga van akkor miért ne tudná a mögöttes szolgáltatást leállítani/arrébrakni?
Gábriel Ákos
Mert a CAP_NET_BIND_SERVICE csak port nyitást engedélyez, ha jól értem.
Mitől lehet itt root joga?
Kum Gábor
Nem lesz neki root joga, hiszen a szolgáltatás nem rootként fut. Jó eséllyel lesz egy shellje, amiben lesz net_bind_service capabilityje.
Az persze más kérdés, hogy ha már van shellje, akkor local exploitot sokkal könnyebb találni, hogy valóban root legyen. De ezen nem változtat a cap.
Nagyjából. Simán net_bind_service capabilityvel nem nagyon fog tudni agyonverni másik processzt, anélkül meg listening portot lopni imho nem nagyon lehet.
Mondjuk azért ha elég türelmes a támadó, azt játszhatja, hogy árgus szemekkel figyel, hogy mikor engedi el az sshd pl egy service restart miatt, és lecsap rá, szóval azért nem teljesen esélytelen.
Ahogy krozoo is mondja, van benne kockázat éppen elég. De nem értem miért nem lehet felhúzni elég egy reverse proxy-t, csomagtelepítéssel együtt is megvan 5 perc alatt, ha ráérősen csinálod, egyszerű, tiszta, kényelmes megoldás, ennél bármi csak rosszabb lesz, tényleg nem látom mi az akadálya.
szeret veszélyesen élni.
Gábriel Ákos
Ott a pont. Valami izgalom kell ebben az ingerszegény világban :-)
Kum Gábor
nginx ele, es supervisor ami ujrarugdalja a node-t ha kell
http://szoftvervasarlas.co.hu - szoftverek legjobb áron