Proteggere Apache mod_status e interpretare correttamente i valori di stato

Cosa rende visibile mod_status

Il modulo Apache mod_status fornisce informazioni sul server web in esecuzione. Aiuta, ad esempio, a capire quanti worker sono attualmente attivi e quali richieste vengono elaborate. Le spiegazioni che seguono si riferiscono ad Apache HTTP Server 2.4; la documentazione relativa al ramo di sviluppo è separata e non è trasferibile a questa versione senza previa verifica.

A gestore genera l'output di stato per un percorso URL configurato. Una sezione "Location" può passare questo percorso all'handler server-status assegnare; non è necessario che esista un file con lo stesso nome nella directory DocumentRoot. Il percorso costituisce quindi un accesso alla diagnostica del server e non una normale pagina fornita dal file system.

Per la diagnosi manuale è indicata la visualizzazione HTML. La variante con ?auto fornisce una rappresentazione leggibile da macchina che un sistema di monitoraggio può recuperare regolarmente. I dettagli disponibili dipendono, tra l’altro, dalla configurazione del server. Il parametro non trasforma l’endpoint in un servizio separato: anche i suoi dati in uscita devono essere protetti da accessi non autorizzati.

È necessario che mod_status sia caricato e che tu abbia i permessi per modificare la configurazione di Apache. Per le restrizioni di accesso devono inoltre essere disponibili i moduli di autorizzazione necessari. Le modalità di attivazione di un modulo e i file necessari a tale scopo variano a seconda della distribuzione e dell'installazione; pertanto, un singolo percorso di file non costituisce un punto di partenza universalmente valido.

Per Monitoraggio di Apache L'output costituisce una fonte di diagnosi, ma non rappresenta un monitoraggio completo delle prestazioni dell'applicazione. Ad esempio, mostra che i worker sono occupati, ma non spiega di per sé se sia un database, un backend o un client lento a causare il ritardo nell'elaborazione. Per individuare le cause, sono necessari anche dati adeguati relativi all'applicazione, al sistema e ai log.

Dati di stato e relative implicazioni in materia di sicurezza

La pagina di stato mostra, tra le altre cose, i worker occupati e quelli liberi, nonché informazioni sull'ora di avvio o riavvio e sul tempo di esecuzione. I worker occupati non sono disponibili come capacità libera al momento della richiesta. È possibile valutare quanto sia critico il rapporto tra worker occupati e liberi solo considerando l'andamento nel tempo e il limite dei worker effettivamente configurato.

Il periodo di tempo aiuta a contestualizzare i valori aggregati nel tempo: una media calcolata dall'inizio può nascondere brevi picchi di carico. Allo stesso modo, una richiesta con pochi worker disponibili rappresenta inizialmente solo un'istantanea. Richieste ripetute, insieme ai tempi di risposta e agli errori, forniscono una base migliore per analizzare una possibile carenza.

Con Stato esteso Apache registra ulteriori dettagli, tra cui il numero complessivo di accessi e i volumi di dati, nonché informazioni sugli host e sulle richieste correnti. Quando si carica mod_status, questa funzione di registrazione è attivata per impostazione predefinita in Apache 2.4. Tuttavia, una scelta esplicita in fase di configurazione consente di determinare il livello di dettaglio previsto per il funzionamento specifico.

Una registrazione più dettagliata ha il suo prezzo: comporta un carico di lavoro aggiuntivo e può rallentare il server. Valuta quindi l’utilità diagnostica rispetto a tale carico di lavoro, invece di considerare automaticamente i maggiori dettagli come un miglioramento gratuito. D’altra parte, senza ExtendedStatus mancano informazioni che potrebbero essere utili per l’assegnazione delle richieste in corso.

L'output può rivelare le richieste in corso e le informazioni sul client. Trattalo quindi come dati operativi sensibili e non come controllo dello stato di salute pubblico. La visualizzazione HTML e ?auto richiedono lo stesso livello di protezione dell'accesso; un percorso difficile da indovinare non impedisce l'accesso a chi lo conosce o lo scopre.

Verificare i percorsi di accesso e il modello dei worker

Prima di apportare qualsiasi modifica, individua la versione di Apache installata e il modulo di multiprocessing attivo, in breve MPM. Verifica inoltre quali host virtuali servono il listener in questione, se i proxy inversi inoltrano le richieste e quali regole di accesso sono già in vigore. Solo con questa panoramica è possibile valutare dove avrà effetto una nuova regola e quali configurazioni esistenti potrebbero essere influenzate da essa.

Un agente di monitoraggio locale potrebbe recuperare lo stato tramite un indirizzo loopback. Tuttavia, un recupero locale riuscito dimostra solo che quel percorso specifico, con l'indirizzo, la porta e l'host virtuale selezionati, funziona. Non dimostra né che gli altri host siano protetti, né che un accesso esterno fallisca.

Un secondo approccio può passare attraverso un proxy inverso e un altro host virtuale. In questo caso possono essere applicati altri reindirizzamenti o regole di accesso; inoltre, è necessario verificare quale indirizzo client Apache utilizzi effettivamente per l'autorizzazione. Considera il Percorso di accesso pertanto, includendo proxy, selezione dell'host e regole Apache, anziché trasferire il test locale all'intera topologia.

L'MPM determina il modo in cui Apache impiega i processi e, se del caso, i thread per l'elaborazione. Un processo è un'unità del sistema operativo; i thread vengono eseguiti all'interno di un processo e possono elaborare attività al suo interno. L'importanza del numero di worker dipende quindi dal modello utilizzato. Il Confronto tra i modelli di worker di Apache spiega le differenze tra Prefork, Worker ed Event.

Proprio nel caso del event-MPM Le connessioni aperte non equivalgono automaticamente a thread di lavoro occupati in modo permanente. Alcuni stati di attesa possono essere gestiti in modo diverso rispetto all'elaborazione attiva di una richiesta. Prendi quindi nota dell'MPM attivo prima di trarre conclusioni sulla capacità basandoti sul numero di connessioni e di thread di lavoro.

Configurazione dell'endpoint di stato locale

Prima di apportare la modifica, verifica se è in esecuzione Apache HTTP Server 2.4, mod_status sia stato caricato e che i moduli di autorizzazione necessari siano disponibili. Registra inoltre gli host virtuali esistenti e le regole di accesso. L’attivazione dei moduli e i percorsi di configurazione variano a seconda della distribuzione; l’esempio seguente va inserito nel file di configurazione di Apache corrispondente, non in un file generico predefinito.

L'esempio si attiva Stato esteso lo specifica espressamente e assegna il percorso allo status handler. Require local limita l'accesso in base alle regole di Apache per le connessioni locali. La direttiva per la registrazione dettagliata si trova al di fuori della sezione `Location`. Prima di applicarla, devi verificare come questa sezione interagisce con la tua configurazione esistente.

ExtendedStatus On

<Location "/server-status">
    SetHandler server-status
    Require local
</Location>

Fai verificare e approvare la modifica in base alla tua procedura operativa prima di applicarla. L'esempio è un punto di partenza, non una garanzia valida per tutti gli host virtuali o i percorsi proxy. In particolare, le sezioni di autorizzazione esistenti possono influire sulla regola applicabile a una richiesta specifica.

Dopo l'esecuzione, puoi recuperare localmente l'output leggibile dalla macchina utilizzando il seguente comando di lettura. Il comando presuppone la presenza di un listener sull'indirizzo loopback selezionato e sulla porta predefinita 80. Verifica inoltre che la richiesta raggiunga l’host virtuale previsto; se necessario, dovrai adattare la porta e la selezione dell’host al tuo ambiente.

curl --fail --silent --show-error 'http://127.0.0.1/server-status?auto'

Un recupero non riuscito è, in un primo momento, solo un’indicazione, non una diagnosi univoca dell’errore. Oltre all’autorizzazione, potrebbero essere in gioco, ad esempio, un altro listener, un’assegnazione dell’host diversa o un reindirizzamento. Un recupero locale riuscito, d’altra parte, non garantisce che anche altre vie di accesso siano protette.

Estendere in modo sicuro l'accesso al monitoraggio

Scegli la modalità di accesso in base a dove viene eseguito il monitoraggio e a chi necessita dei risultati. Un agente sullo stesso host può avvalersi della limitazione locale. Se deve accedervi un sistema esterno, l'autorizzazione dovrebbe essere limitata alle fonti effettivamente necessarie e successivamente verificata tramite il percorso di rete previsto.

All'indirizzo Require ip Non è determinante solo l'indirizzo che il server di monitoraggio vede dal proprio punto di vista. Dietro un proxy inverso, la configurazione installata deve fornire l'indirizzo che Apache utilizza effettivamente per l'autorizzazione. Verifica questa corrispondenza lungo il percorso effettivo prima di autorizzare l’accesso a una rete; un indirizzo client presunto non costituisce un controllo degli accessi affidabile.

Diversi Require-Le direttive all'interno di una sezione, in assenza di un contenitore adeguato, si comportano fondamentalmente come una Operatore "o": Se una richiesta soddisfa una delle condizioni, ciò può già essere sufficiente. Se un client deve provenire dalla rete autorizzata ed effettuare inoltre l'accesso, è necessario specificare espressamente le condizioni in un <RequireAll>-Metti insieme i container e verifica entrambi i requisiti separatamente.

Nel caso dell'autenticazione di base, solo un protocollo di trasporto adeguato, come il TLS, protegge le credenziali durante la trasmissione. Una rete di gestione separata può limitare ulteriormente l'accessibilità, ma non sostituisce un'efficace autorizzazione Apache. Anche in questo caso, solo i sistemi autorizzati dovrebbero poter recuperare l'output HTML e quello leggibile dal computer.

Classificare correttamente i valori di stato

La pagina di stato fornisce risposte diverse a diverse domande di diagnostica in base ai dati disponibili. Leggi la Assegnazione dei lavoratori Pertanto non è isolata: descrive lo stato al momento della richiesta. Ulteriori dettagli sulla richiesta dipendono dalla configurazione e, in particolare, da ExtendedStatus; i campi visualizzati possono variare a seconda del server e dell’MPM.

Supponiamo che una query mostri molti worker occupati e solo pochi liberi. Ciò potrebbe essere un breve picco di carico oppure indicare una pressione prolungata. Ripeti la query e confronta l’andamento con i tempi di risposta, gli errori e il limite effettivo dei worker prima di prendere in considerazione una modifica della capacità.

All'indirizzo event-MPM alcuni stati di attesa possono essere gestiti dal listener anziché da thread di lavoro associati in modo permanente. I processi di scrittura e keep-alive vanno quindi interpretati come stati di connessione, non genericamente come un numero di thread occupati. Anche i processi in fase di terminazione e le generazioni precedenti dopo un riavvio graduale possono influenzare il quadro; verifica i dettagli relativi alla versione 2.4 installata.

Per la classificazione dell'architettura, il Confronto tra Event MPM e Worker MPM L'indicatore di stato. La scelta dell'MPM spiega come Apache organizza le connessioni e il lavoro; tuttavia, non sostituisce l'osservazione del server specifico e della sua applicazione.

Monitorare i dati di stato nel tempo

Per Apache Monitoring, una singola pagina di stato rappresenta solo una parte del quadro complessivo. Ottieni l'output leggibile dal sistema tramite ?auto Recupera regolarmente i valori da un agente autorizzato e salvali con un timestamp. In questo modo potrai, ad esempio, capire se il numero ridotto di worker disponibili è un fenomeno momentaneo o se persiste nel corso di più query.

Per un Frequenza degli intervalli Si confronta un contatore cumulativo con il suo valore precedente e si divide la differenza per il tempo trascorso. Se, ad esempio, il numero di accessi aumenta di 120 in 60 secondi, ciò corrisponde a una media di due accessi al secondo per quell’intervallo. Questo valore medio non fornisce ancora alcuna indicazione sulla distribuzione all’interno del minuto.

Prima di calcolare la differenza, verifica le informazioni relative all’avvio o al riavvio e il valore del contatore. Se il server è stato riavviato o se un contatore è diminuito rispetto alla lettura precedente, considera la situazione come un reset e avvia una nuova serie di confronti. Un tasso di traffico negativo derivante da due valori del contatore risulterebbe in questo caso fuorviante; anche le richieste non andate a buon fine dovrebbero rimanere riconoscibili nella cronologia.

Le medie relative al tempo di funzionamento del server fornite da mod_status attenuano i brevi picchi di carico. Una serie temporale con un intervallo di interrogazione opportunamente scelto mostra le variazioni in modo più preciso, ma può comunque tralasciare eventi verificatisi tra due interrogazioni. Scegli quindi l'intervallo in base alla questione diagnostica da risolvere e tieni conto dell'onere legato alla raccolta e all'archiviazione dei dati.

Anche i dati di stato archiviati devono essere protetti: a seconda dell'output, possono contenere informazioni relative alle richieste e ai client. Limita l'accesso all'agente, all'archivio e all'analisi alle sole persone e ai soli sistemi autorizzati. Stabilisci inoltre per quanto tempo i dati grezzi e gli indicatori derivati devono essere conservati per il rispettivo scopo operativo.

Verifica dell'accesso e dei messaggi di errore

Dopo aver approvato una modifica, verifica innanzitutto l'accesso autorizzato previsto, ad esempio da parte dell'agente di monitoraggio locale. Successivamente, controlla sia la pagina HTML che la variante da una postazione di rete espressamente non autorizzata ?auto. Nessuno dei due deve fornire dati di stato in quel contesto. Un test effettuato su una sola sede o su un solo percorso di accesso non è sufficiente.

Ripeti il test per gli host virtuali effettivamente raggiungibili e, se del caso, per le connessioni dirette e quelle gestite tramite un proxy inverso. Il fatto che il test abbia esito positivo a livello locale non garantisce che il proxy garantisca lo stesso livello di protezione. Presta attenzione anche ai reindirizzamenti: ciò che conta è se, alla fine di un percorso di accesso, vengono restituiti dati sensibili relativi allo stato.

Se un’interrogazione consentita non va a buon fine, verifica, oltre alla Autorizzazione anche il listener, l'indirizzo e la porta, nonché la selezione dell'host virtuale. Anche le regole proxy e di reindirizzamento possono deviare la richiesta in modo diverso dal previsto. Un singolo errore non permette quindi di dedurre con certezza né l'esistenza di una regola di accesso errata né la presenza di un handler difettoso.

Verifica che le configurazioni esistenti non contengano vecchie direttive di accesso come Order e Deny. La loro combinazione avventata con i più recenti Require-Le regole possono portare a risultati inaspettati. Verifica la combinazione effettivamente valida, invece di dedurre l'accesso finale sulla base di una singola regola che lo consente.

Inoltre, una location protetta non è necessariamente l'unico stato finale possibile. Se mod_status è caricato, il suo handler può essere specificato anche nelle configurazioni per directory, incluse .htaccess essere disponibili. Verifica quindi le voci esistenti e le deleghe consentite, in particolare sui server condivisi, in modo che non sia possibile configurare ulteriori handler non protetti.

Dalle indicazioni alle decisioni aziendali

Se si riscontra ripetutamente che molti worker sono occupati e solo pochi sono liberi, ciò costituisce un’indicazione di una possibile pressione sulle capacità, ma non costituisce ancora una prova della causa. Confronta l'andamento con i tempi di risposta, i tassi di errore e il limite effettivo dei worker. Solo il quadro complessivo mostra se l'occupazione coincide con problemi tangibili e quanto questi siano persistenti.

Prima di aumentare un limite, verifica la memoria disponibile e il fabbisogno aggiuntivo dei processi o dei thread previsti. Allo stesso tempo, analizza i motivi per cui le elaborazioni richiedono molto tempo: un maggiore parallelismo potrebbe non risolvere la causa effettiva del problema e impegnare ulteriori risorse. Le modifiche devono quindi essere inserite in un processo operativo controllato, seguito da un’attenta monitoraggio.

In caso di richieste lente, le ripetute verifiche dello stato aiutano a individuare le richieste attuali e i processi associati. Confronta gli orari con i log di accesso e di errore, nonché con i dati dell’applicazione e dei suoi backend. Una richiesta fugace può scomparire tra due interrogazioni; una singola segnalazione non identifica in modo affidabile una determinata applicazione come causa né dimostra che si tratti di un attacco.

Per un look che non passa inosservato ID processo Puoi inoltre verificare i dati del sistema operativo, come l'utilizzo della CPU e della memoria. Questa correlazione costituisce un ulteriore indizio, ma non sostituisce il confronto temporale con le richieste e i log. Soprattutto in caso di osservazioni ripetute, dovresti tenere presente che i processi e le richieste che stanno elaborando in quel momento possono cambiare.

Nel caso dell’event-MPM, presta inoltre attenzione ai processi in fase di terminazione e alle vecchie generazioni dopo un riavvio graduale. Questi possono influenzare il quadro generale durante la transizione; le connessioni aperte non sono da equiparare in modo generalizzato a thread di lavoro occupati in modo permanente. Verifica le peculiarità della versione di Apache 2.4 installata prima di trarre conclusioni definitive sulla capacità da assegnare sulla base di una fase di transizione di questo tipo.