Qualunque valore in un web server che chiude le connessioni su richieste non valide (o pagine non valide)?

Il valore sta nell'evitare di avere software applicativo di livello superiore (php, wordpress, qualunque) che funzioni e possibilmente gestisca erroneamente le richieste malformate. Poiché il livello nginx sta valutando la correttezza del protocollo e non sta tentando di fare effettivamente alcunché con la richiesta, fornisce un pre-filtro.

Terminare bruscamente la connessione non ti fa guadagnare molto. Indica all'attaccante quale sistema difensivo stai usando, e lo stesso mezzo sarebbe raggiunto con una risposta generica 404 con meno utilità per l'attaccante. Ma è il genere di drammatico teatro della sicurezza che si ripete di tanto in tanto, e non arreca alcun danno reale a nessuno.

Penso che gowenfawr e George Bailey abbiano ragione.

La chiusura di una connessione del protocollo HTTP invece di restituire una risposta di errore è un meccanismo di livello molto basso. Come perenne evasione delle conseguenze indesiderate bestia, raccomando di non implementare un meccanismo senza uno scopo chiaro. Gli esseri umani sono soggetti a errori e si potrebbe per caso impedire l'invio di un messaggio di errore valido. Tenere traccia di un errore senza una risposta normale è solo il modo sbagliato di trascorrere qualche sera tardi, seguito da mattinate mattutine, seguite da mattinate tarde e così via. Scrivi i tuoi obiettivi di sicurezza quindi individua i meccanismi per soddisfarli.

So is there any value in closing the connection to all the requests that are valid HTTP, but for non-existent pages?

Sarebbe una configurazione insolita, con poco profitto. Vorrei suggerire di rivedere le intestazioni HTTP per vedere se perdono informazioni come la versione server e attenersi a 404 su pagine inesistenti, il che è meno confuso. Non riesco a pensare a nessun valore di sicurezza per chiudere la connessione se non come un aumento molto leggero delle prestazioni. (Sarebbe in realtà contro-atto keep-alive, ma non credo che importi molto per il traffico che probabilmente porterà 404)

Questo leggero aumento delle prestazioni potrebbe iniziare a fare la differenza in un attacco DoS, non so quanto costose possano essere le tue 404 pagine. Ma anche in questo caso, un attacco DoS sarebbe più efficace sulle pagine più grandi del tuo sito, quindi probabilmente questo non è un obiettivo probabile.

Ma poi di nuovo, potrei mancare qualcosa.

Riduce la possibilità di perdite di informazioni.

Se faccio una richiesta malformata, c'è la possibilità che riprenderai qualcosa di interessante sul sistema.

Se la risposta restituisce sempre lo stesso valore a prescindere dalla richiesta, allora non è possibile scoprire nulla sul sistema attraverso richieste malformate.

Il merito di tutto ciò è relativo al sistema che stai cercando di proteggere e in che misura stai cercando di proteggere. Non l'ho mai impostato, quindi non posso parlare dello sforzo richiesto.

"Security theatre" non ha nulla a che fare con la tua domanda. Sei caduto nella trappola di usarlo come attacco ad hominem contro qualsiasi procedura di sicurezza che non sei d'accordo con te.

Una sicurezza corretta è per evitare la perdita di informazioni. Se l'URL non viene trovato, il comportamento corretto è di dare un 404 non trovato. Se il protocollo HTTP è malformato, un buon comportamento è semplicemente chiudere la connessione (non so cosa dice lo standard, ma so che è il comportamento della maggior parte dei server).