Quote:
Originariamente inviato da Tasslehoff
Sul traffico in outbound io onestamente sono molto più rigido, se sta a me decidere io non lasciarei aperto nulla in outbound.
|
Già, la penso allo stesso modo, solo che i clienti generalmente la vedono diversamente. E non hanno tutti i torti... con lo smartworking forzato degli ultimi due anni, chi aveva regole in uscita molto specifiche si è dovuto piegare ad aprire vasti range IP per i vari Teams/Meet/Zoom/ecc. Come avrai avuto modo di vedere anche tu, questi servizi poggiano interamente sui cloud di Microsoft/Amazon/Google e, dovendo aprire i loro range, si aprono anche una marea di server malevoli che girano allegramente su quegli stessi cloud (giusto recentemente ho tracciato un corposo range di Google Compute Engines da cui provenivano attacchi a un server Jira già compromesso da precedenti cryptominer).
Oggi comunque ho convito diversi clienti a chiudere quanto meno i protocolli LDAP, LDAPS e RMI. Chiaramente possono essere fatti girare su porte diverse da quelle standard; è solo per sfoltire un po' e guadagnare tempo per aggiornare gli applicativi.
Quote:
Devi accedere a un servizio di terze parti? Lo fai tramite proxy (ormai di fatto si tratta di ws nel 100% dei casi, non esiste più nessuno che usa protocolli proprietari che non passino via http),
|
Per audio/video molti usano protocolli diversi dall'http (per esempio Google Meet ha un bel po' di porte da aprire, oppure pensa all'RTSP). Questi generalmente non girano proprio dietro proxy "classico" (cioè quello che possiamo impostare a livello di OS).
Quote:
ma come dicevo il proxy non deve essere configurato a livello di sistema operativo o direttamente nella configurazione dell'application server (o a livello di parametro della jvm, giusto per restare in tema java), ma la chiamata http tramite proxy deve essere implementata a livello di codice (chiaramente definendo in modo parametrico le variabili che permettono di usare il proxy).
In caso contrario salta tutto, se si sfrutta una vulnerabilità RCE e il processo vulnerabile ha già il suo bel proxy pronto all'uso non serve a nulla (o quasi).
|
Certo, questa è un'ottima idea, ma se dobbiamo dipendere dagli sviluppatori stiamo freschi
Considera anche che una RCE in grado di leggere la configurazione dell'applicativo (o avviare qualche tipo di debug dell'applicativo stesso) potrebbe tranquillamente fare il discovery del proxy e iniziare usarlo...
Quote:
Il resto come DNS e NTP imho va chiuso a prescindere, farsi un dns o un server ntp interno è questione di 5 minuti, alla peggio si mitiga aprendo a livello perimetrale solo verso gli ip specifico del dns o del server ntp che si vuole utilizzare.
|
Vero, però è anche vero che spesso per svariati motivi può esserci bisogno di un server DNS o NTP raggiungibile. Chiaro che se poi si controlla al 100% la rete allora è un altro paio di maniche
Quote:
Grazie dell'aggiornamento
|
Di nulla figurati