Felhasználóként futó NodeJS szolgáltatás 443-as portra

Linux-haladó

Sziasztok!

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.

  • 362 megtekintés

( ggallo | 2021. 01. 25., h – 16:51 )

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.

( kicca | 2021. 01. 25., h – 19:08 )

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

( Elbandi v | 2021. 01. 25., h – 20:14 )

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!

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

( kumgabor v | 2021. 01. 26., k – 09:55 )

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

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.