Link alla notizia: http://www.hwupgrade.it/news/sicurezza-software/3-milioni-di-server-a-rischio-ransomware-per-via-di-software-non-aggiornato_62166.html

Le vulnerabilità delle versioni non aggiornate dell'applicativo server JBoss mettono a rischio molti server esposti sulla rete che possono essere sfruttati per eseguire attacchi ransomware

Click sul link per visualizzare la notizia.

"... è allora utile ripristinare un backup precedente alla compromissione e installare tutti gli aggiornamenti prima di riportare la macchina in produzione."

se il backup non è pure lui già stato infettato...

Ma questa non è una vulnerabilità del prodotto, è una vulnerabilità nella testa della gente che usa il prodotto...

Se qualcuno espone a web un intero application server senza filtri (o con filtri inutili e insufficienti, es un reverse proxy totale senza alcun filtro) e senza preoccuparsi di cosa gira su quel servizio è un incosciente o un ignorante, e non serve essere un esperto di sicurezza per arrivarci, basta il comune buon senso.

Esistono modi molto semplici e assolutamente economici (non dico gratuiti perchè anche i 5 minuti che servono per implementarli costano, seppur un'inezia...) per esporre solo il context di una applicazione deployata su un application server o un servlet container j2ee, basta una banale istanza apache con mod_proxy e un semplice proxypass.
Poi se uno vuol mascherare anche il prodotto nell'header http o implementare chissà quale altra misura di sicurezza ben venga, ma esporre a web il context di un servizio è il minimo sindacale, per il resto console (web o jmx) sono strumenti utilissimi, anzi indispensabili per il monitoraggio e il problem solving, quindi eliminarli mi pare una soluzione inutile e controproducente a prescindere... :rolleyes:

Ma questa non è una vulnerabilità del prodotto, è una vulnerabilità nella testa della gente che usa il prodotto...

Se qualcuno espone a web un intero application server senza filtri (o con filtri inutili e insufficienti, es un reverse proxy totale senza alcun filtro) e senza preoccuparsi di cosa gira su quel servizio è un incosciente o un ignorante, e non serve essere un esperto di sicurezza per arrivarci, basta il comune buon senso.

Esistono modi molto semplici e assolutamente economici (non dico gratuiti perchè anche i 5 minuti che servono per implementarli costano, seppur un'inezia...) per esporre solo il context di una applicazione deployata su un application server o un servlet container j2ee, basta una banale istanza apache con mod_proxy e un semplice proxypass.
Poi se uno vuol mascherare anche il prodotto nell'header http o implementare chissà quale altra misura di sicurezza ben venga, ma esporre a web il context di un servizio è il minimo sindacale, per il resto console (web o jmx) sono strumenti utilissimi, anzi indispensabili per il monitoraggio e il problem solving, quindi eliminarli mi pare una soluzione inutile e controproducente a prescindere... :rolleyes:

ehm... che sarebbe mod_proxy e proxypass?
mi informo..........

quoto tasselhoff..

ehm... che sarebbe mod_proxy e proxypass?
mi informo..........

appunto :sofico:

ehm... che sarebbe mod_proxy e proxypass?
mi informo..........Si tratta di un modulo di apache (e di una delle direttive da usare con questo modulo) per usare il webserver come reverse proxy, ovvero fare in modo che il webserver riceva la richiesta dal client e la inoltri all'application server.
Questo è utile per diversi motivi, es:

scaricare l'application server da un carico non necessario (es risorse statiche, lasciando gestire all'application server solo le componenti dinamiche o più in generale "applicative")
gestire le richieste in modo flessibile (es tramite regole di rewrite e regular expression)
bilanciare le richieste su più application server per garantire continuità di servizio e/o bilanciamento di carico
filtrare le richieste esponendo solo quello che gli utenti devono vedere, quindi riducendo il più possibile l'eventuale finestra di attacco


Non fraintendermi, non voglio sembrarti arrogante o supponente, quando parlavo di ignoranza intendevo in senso letterale.
E' normale che per un utente generico o specialistico ma che si occupa di altro (es uno sviluppatore, un analista, un commerciale) queste cose siano sconosciute o non chiare, ma se una persona gestisce un application server e ha i permessi per poterlo esporre a web allora deve conoscere questi strumenti che esistono dalla notte dei tempi, e con questo mi riferisco in generale ai reverse proxy, poi uno può usare Nginx, haproxy, oppure apparati superfighi e costosi tipo F5, l'importante è usarli.

Se uno si trova in queste condizioni e non li conosce allora è un problema, magari non è colpa sua ma di chi l'ha messo in questa condizione e gli ha sbolognato servizi e sistemi che non è in grado di gestire (con le competenze che ha in quel momento, poi chiunque si può formare per fare una cosa del genere); e qui ci ricolleghiamo a un discorso ben più ampio che riguarda il pressapochismo e la corsa al risparmio (non per stare nei costi ma per massimizzare il margine di guadagno che non può mai essere in qualche modo eroso per nessun motivo :doh: ) che caratterizza il mondo dell'IT in Italia :rolleyes:

[EDIT]
Dimenticavo una cosa, mi aspetto anche che un sito che si considera una "testata giornalistica tecnica e specialistica" (che oltretutto possiede anche una sezione "business" analizzi un tema del genere anzichè limitarsi a fare un copia e incolla becero, che oltretutto veicola una informazione tecnicamente errata e controproducente, senza nemmeno citare la vera soluzione.

mmmh... onestamente il webserver apache, in senso stretto, non l'ho mai usato. Sono programmatore java, e uso molto tomcat (che sempre apache è..., ma non è la stessa cosa :D).

Pensavo comunque che le direttive di cui parlavi sopra fossero già attive di default

mmmh... onestamente il webserver apache, in senso stretto, non l'ho mai usato. Sono programmatore java, e uso molto tomcat (che sempre apache è..., ma non è la stessa cosa :D).

Pensavo comunque che le direttive di cui parlavi sopra fossero già attive di defaultE' possibile che il mod_proxy sia attivo di default con la configurazione di default di diverse distribuzioni GNU/Linux, però per utilizzarlo devi comunque configurare un ProxyPass usando l'opportuna sintassi.

Comunque per chiarezza queste direttive e moduli sono dell'http server dell'apache software foundation (comunemente detto "apache" perchè è oggettivamente il progetto più rilevante della fondazione), in Tomcat non credo ci sia nulla del genere. Puoi gestire i permessi sulle varie applicazioni deployate, ma è certamente un modo meno flessibile e sicuro per implementare un controllo del genere, non esporre qualcosa è sempre più sicuro che esporlo protetto da autenticazione. ;)

Se cerchi su google "apache proxypass" troverai l'infinito in termini di guide e howto per farlo.