Guida alla protezione e alla protezione del server Web Apache

Una guida pratica per proteggere e rafforzare il server HTTP Apache.


Il Web Server è una parte cruciale delle applicazioni basate sul Web. Apache Web Server è spesso posizionato ai margini della rete, quindi diventa uno dei servizi più vulnerabili agli attacchi.

La configurazione predefinita fornisce molte informazioni sensibili che possono aiutare gli hacker a prepararsi per un attacco alle applicazioni. La maggior parte degli attacchi alle applicazioni Web avviene attraverso XSS, perdite di informazioni, gestione delle sessioni e attacchi SQL Injection dovuti a codice di programmazione debole e alla mancata sanificazione dell’infrastruttura delle applicazioni Web.

Ricerche interessanti di Tecnologie positive rivela che il 52% dell’applicazione scansionata presentava vulnerabilità elevate.

In questo articolo, parlerò di alcune delle migliori pratiche per proteggere il server HTTP Apache su piattaforma Linux.

Di seguito sono testati sulla versione Apache 2.4.x..

  • Questo presuppone che tu abbia installato Apache sulla piattaforma UNIX. In caso contrario, è possibile consultare la guida all’installazione.
  • Chiamerò la directory di installazione di Apache / opt / apache come $ Web_Server in questa guida.
  • Si consiglia di eseguire un backup del file di configurazione esistente prima di qualsiasi modifica.

Pubblico

Questo è progettato per l’amministratore del middleware, il supporto delle applicazioni, l’analista di sistema o chiunque lavori o sia desideroso di imparare l’indurimento & Linee guida sulla sicurezza.

Discreta conoscenza di Apache Web Server & Il comando UNIX è obbligatorio.

Appunti

È necessario qualche strumento per esaminare le intestazioni HTTP per alcune delle verifiche dell’implementazione. Ci sono due modi per farlo.

  1. Utilizza gli strumenti di sviluppo integrati nel browser per ispezionare le intestazioni HTTP. Di solito, è nella scheda Rete
  2. Utilizza lo strumento di verifica dell’intestazione della risposta HTTP online

Rimuovi banner versione server

Direi che questa è una delle prime cose da considerare, poiché non vuoi esporre la versione del server web che stai utilizzando. Esporre la versione significa che stai aiutando gli hacker a velocizzare il processo di ricognizione.

La configurazione predefinita espone la versione di Apache e il tipo di sistema operativo come mostrato di seguito.

  • Vai alla cartella $ Web_Server / conf
  • Modifica httpd.conf usando l’editor vi
  • Aggiungi la seguente direttiva e salva httpd.conf

ServerTokens Prod
Firma server disattivata

  • Riavvia apache

ServerSignature rimuoverà le informazioni sulla versione dalla pagina generata da Apache.

ServerTokens cambierà l’intestazione solo in produzione, ovvero Apache

Come puoi vedere di seguito, versione & Le informazioni sul sistema operativo sono sparite.

Disabilita l’elenco del browser di directory

Disattiva l’elenco delle directory in un browser, quindi il visitatore non vede quali file e cartelle hai sotto la directory principale o secondaria.

Testiamo come appare nelle impostazioni predefinite.

  • Vai alla directory $ Web_Server / htdocs
  • Crea una cartella e alcuni file al suo interno

# test mkdir
# tocca ciao
# tocca ciao

Ora proviamo ad accedere ad Apache da http: // localhost / test

Come puoi vedere, rivela quali file / cartelle hai e sono sicuro che non vorrai esporlo.

  • Vai alla directory $ Web_Server / conf
  •  Apri httpd.conf usando vi
  •  Cerca la directory e modifica la direttiva delle opzioni su None o –Indexes

Opzioni -Index

(o)

Opzioni Nessuna

  • Riavvia Apache

Nota: se nel tuo ambiente sono presenti più direttive Directory, dovresti considerare di fare lo stesso per tutti.

Ora proviamo ad accedere ad Apache da http: // localhost / test

Come puoi vedere, mostra un errore proibito invece di mostrare l’elenco delle cartelle di prova.

ETAG

Consente agli aggressori remoti di ottenere informazioni sensibili come il numero di inode, il limite MIME multipart e il processo figlio tramite l’intestazione Etag.

Per prevenire questa vulnerabilità, implementiamola come di seguito. Questo è necessario per correggere la conformità PCI.

  • Vai alla directory $ Web_Server / conf
  • Aggiungi la seguente direttiva e salva httpd.conf

FileETag Nessuno

  • Riavvia apache

Esegui Apache da un account senza privilegi

Un’installazione predefinita viene eseguita come nessuno o daemon. L’uso di un utente non privilegiato separato per Apache è buono.

L’idea qui è di proteggere altri servizi in esecuzione in caso di problemi di sicurezza.

  • Crea un utente e un gruppo chiamato apache

# groupadd apache
# useradd –G apache apache

  • Cambia la proprietà della directory di installazione di apache in un utente non privilegiato appena creato

# chown –R apache: apache / opt / apache

  •  Vai a $ Web_Server / conf
  •  Modifica httpd.conf usando vi
  •  Cerca utente & Direttiva gruppo e modifica come apache account non privilegiato

Apache utente
Apache di gruppo

  •  Salva httpd.conf
  •  Riavvia Apache

grep per l’esecuzione del processo http e assicurarsi che sia in esecuzione con l’utente apache

# ps –ef | grep http

Dovresti vedere un processo in esecuzione con root. Questo perché Apache è in ascolto sulla porta 80 e deve essere avviato con root.

Proteggi l’autorizzazione della directory binaria e di configurazione

Per impostazione predefinita, l’autorizzazione per binario e configurazione è 755, il che significa che qualsiasi utente su un server può visualizzare la configurazione. Puoi impedire a un altro utente di accedere alla cartella conf e bin.

  • Vai alla directory $ Web_Server
  • Modifica l’autorizzazione della cartella bin e conf

# chmod –R 750 bin conf

Protezione delle impostazioni di sistema

In un’installazione predefinita, gli utenti possono sovrascrivere la configurazione di apache utilizzando .htaccess. Se vuoi impedire agli utenti di modificare le impostazioni del tuo server Apache, puoi aggiungere AllowOverride a None come mostrato di seguito.

Questo deve essere fatto a livello di root.

  • Vai alla directory $ Web_Server / conf
  •  Apri httpd.conf usando vi
  •  Cerca Directory a livello di root

Opzioni -Index
AllowOverride Nessuno

  •  Salva httpd.conf
  •  Riavvia Apache

Metodi di richiesta HTTP

Il protocollo HTTP 1.1 supporta molti metodi di richiesta che potrebbero non essere richiesti e alcuni di essi presentano rischi potenziali.

In genere potresti aver bisogno dei metodi di richiesta GET, HEAD, POST in un’applicazione web, che può essere configurata nella rispettiva direttiva Directory.

Supporto per la configurazione predefinita OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT nel protocollo HTTP 1.1.

  •  Vai alla directory $ Web_Server / conf
  •  Apri httpd.conf usando vi
  • Cerca la Directory e aggiungi quanto segue

negato da tutti

  • Riavvia Apache

Disabilita Trace HTTP Request

Per impostazione predefinita, il metodo di traccia è abilitato nel server Web Apache.

Se questa opzione è abilitata, puoi consentire l’attacco di Cross Site Tracing e potenzialmente dare un’opzione a un hacker per rubare informazioni sui cookie. Vediamo come appare nella configurazione predefinita.

  •  Esegui un IP server web telnet con porta di ascolto
  •  Invia una richiesta TRACE come mostrato di seguito

#telnet localhost 80
Prova 127.0.0.1…
Connesso a localhost.
Il carattere di escape è ‘^]’.
Host TRACE / HTTP / 1.1: test
HTTP / 1.1 200 OK
Data: sabato 31 agosto 2013 02:13:24 GMT
Server: Apache
Transfer-Encoding: chunked
Tipo di contenuto: messaggio / http 20
TRACE / HTTP / 1.1
Host: test
0
Connessione chiusa da host straniero.
#

Come puoi vedere nella richiesta TRACE sopra, ha risposto alla mia domanda. Disabilitiamolo e testalo.

  •  Vai alla directory $ Web_Server / conf
  • Aggiungi la seguente direttiva e salva httpd.conf

TraceEnable off

  •  Riavvia apache

Esegui un IP del server web telnet con la porta di ascolto ed effettua una richiesta TRACE come mostrato di seguito

#telnet localhost 80
Prova 127.0.0.1…
Connesso a localhost.
Il carattere di escape è ‘^]’.
Host TRACE / HTTP / 1.1: test
Metodo HTTP / 1.1 405 non consentito
Data: sabato 31 agosto 2013 02:18:27 GMT
Server: Apache Consenti: Lunghezza contenuto: 223 Tipo di contenuto: testo / HTML; charset = iso-8859-1
405 Metodo non consentito

operazione non permessa

Il metodo richiesto TRACE non è consentito per l’URL /.

Connessione chiusa da host straniero.
#

Come puoi vedere nella richiesta TRACE sopra, ha bloccato la mia richiesta con il metodo HTTP 405 non consentito.

Ora, questo server web non consente la richiesta TRACE e aiuta a bloccare l’attacco di Cross Site Tracing.

Imposta cookie con flag HttpOnly e Secure

È possibile mitigare la maggior parte dell’attacco cross-site scripting comune utilizzando il flag HttpOnly e Secure in un cookie. Senza avere HttpOnly e Secure, è possibile rubare o manipolare la sessione dell’applicazione Web e i cookie, ed è pericoloso.

  •  Assicurati che mod_headers.so sia abilitato nel tuo httpd.conf
  •  Vai alla directory $ Web_Server / conf
  •  Aggiungi la seguente direttiva e salva httpd.conf

Modifica intestazione Set-Cookie ^ (. *) $ $ 1; HttpOnly; Sicuro

  •  Riavvia apache

Clickjacking Attack

Il clickjacking è una nota vulnerabilità dell’applicazione web.

  •  Assicurati che mod_headers.so sia abilitato nel tuo httpd.conf
  •  Vai alla directory $ Web_Server / conf
  •  Aggiungi la seguente direttiva e salva httpd.conf

L’intestazione aggiunge sempre X-Frame-Options SAMEORIGIN

  •  Riavvia apache

X-Frame-Options supporta anche altre due opzioni che ho spiegato qui.

Includi lato server

Server Side Include (SSI) ha il rischio di aumentare il carico sul server. Se hai condiviso l’ambiente e le applicazioni web a traffico intenso dovresti considerare di disabilitare SSI aggiungendo la direttiva Include in Options.

L’attacco SSI consente lo sfruttamento di un’applicazione Web iniettando script nelle pagine HTML o eseguendo codici in remoto.

  • Vai alla directory $ Web_Server / conf
  •  Apri httpd.conf usando vi
  •  Cerca la directory e aggiungi la direttiva Include in Options

Opzioni –Index -Includes
Ordine consentire, negare Consenti a tutti

  • Riavvia Apache

Nota: se nel tuo ambiente sono presenti più direttive Directory, dovresti considerare di fare lo stesso per tutti.

Protezione X-XSS

La protezione Cross Site Scripting (XSS) può essere esclusa in molti browser. È possibile applicare questa protezione per un’applicazione Web se è stata disabilitata dall’utente. Questo è usato dalla maggior parte delle società web giganti come Facebook, Twitter, Google, ecc.

  • Vai alla directory $ Web_Server / conf
  • Apri httpd.conf usando vi e aggiungi la seguente direttiva Header

Set di intestazioni X-XSS-Protection "1; mode = block"

  •  Riavvia Apache

Come puoi vedere, XSS-Protection è l’iniezione nell’intestazione della risposta.

Disabilita il protocollo HTTP 1.0

Quando parliamo di sicurezza, dovremmo proteggere il più possibile. Quindi perché utilizziamo una versione HTTP precedente del protocollo, disabilitiamoli anche noi?

HTTP 1.0 presenta punti deboli di sicurezza correlati al dirottamento della sessione. Possiamo disabilitarlo usando il modulo mod_rewrite.

  • Assicurarsi di caricare il modulo mod_rewrite nel file httpd.conf
  •  Abilitare la direttiva RewriteEngine come segue e aggiungere la condizione di riscrittura per consentire solo HTTP 1.1

RewriteEngine On
RewriteCond% {THE_REQUEST}! HTTP / 1.1 $
RewriteRule. * – [F]

Configurazione del valore di timeout

Per impostazione predefinita, il valore di timeout di Apache è di 300 secondi, che può essere vittima di un attacco Slow Loris e DoS. Per mitigare ciò, è possibile ridurre il valore di timeout a forse 60 secondi.

  • Vai alla directory $ Web_Server / conf
  • Apri httpd.conf usando vi
  •  Aggiungi quanto segue in httpd.conf

Timeout 60

SSL

Avere SSL è un ulteriore livello di sicurezza che si sta aggiungendo nell’applicazione Web. Tuttavia, la configurazione SSL predefinita comporta alcune vulnerabilità e dovresti considerare di modificare tali configurazioni.

Chiave SSL

La violazione della chiave SSL è difficile, ma non impossibile. È solo una questione di potenza computazionale e di tempo.

Come forse saprai, è possibile utilizzare un PC dell’era del 2009 per circa 73 giorni decodificare una chiave a 512 bit.

Quindi, maggiore è la lunghezza della chiave, più complicata diventa la violazione della chiave SSL. La maggior parte delle società Web giganti utilizza la chiave a 2048 bit, come di seguito, quindi perché non lo facciamo?

  •  Outlook.com
  •  Microsoft.com
  •   Live.com
  •  Skype.com
  •  Apple.com
  •  Yahoo.com
  •  Bing.com
  •  Hotmail.com
  •  Twitter.com

Puoi usare OpenSSL per generare CSR con 2048 bit come di seguito.

openssl req -out geekflare.csr -newkey rsa: 2048 -nodes -keyout geekflare.key

Genererà un CSR che dovrai inviare a autorità di certificazione per firmarlo. Dopo aver ricevuto il file del certificato firmato, è possibile aggiungerli nel file httpd-ssl.conf

SSLCertificateFile #Certificate firmato dall’autorità
SSLCertificateChainFile #Certificato del certificato fornito dall’autorità
File SSLCertificateKeyFile #Key generato in precedenza

  • Riavvia il server Web Apache e prova ad accedere all’URL con https

Cifratura SSL

SSL Cipher è un algoritmo di crittografia, che viene utilizzato come chiave tra due computer su Internet. La crittografia dei dati è il processo di conversione del testo semplice in codici cifrati segreti.

È basato sulla configurazione del tuo cifratura SSL del tuo web server e la crittografia dei dati avrà luogo. Quindi è importante configurare SSL Cipher, che è più forte e non vulnerabile.

  • Vai alla cartella $ Web_Server / conf / extra
  •  Modificare la direttiva SSLCipherSuite in httpd-ssl.conf come di seguito per accettare solo algoritmi di crittografia più elevati

SSLCipherSuite HIGH:! MEDIUM:! ANULL:! MD5:! RC4

  •  Salva il file di configurazione e riavvia il server apache

Nota: se nel report di controllo SSL sono presenti molte cifre deboli, è possibile rifiutarle rapidamente aggiungendole! all’inizio.

Disabilita SSL v2 & v3

SSL v2 & v3 presenta molti difetti di sicurezza e, se si sta lavorando al test di penetrazione o alla conformità PCI, è necessario chiudere i risultati della sicurezza per disabilitare SSL v2 / v3.

Qualsiasi comunicazione SSL v2 / v3 può essere vulnerabile a un attacco Man-in-The-Middle che potrebbe consentire la manomissione o la divulgazione dei dati.

Implementiamo il web server apache per accettare solo gli ultimi TLS e rifiutare la richiesta di connessione SSL v2 / v3.

  • Vai alla cartella $ Web_Server / conf / extra
  • Modifica la direttiva SSLProtocol in httpd-ssl.conf come di seguito per accettare solo TLS 1.2+

Protocollo SSL –ALL + TLSv1.2

Una volta terminata la configurazione SSL, è consigliabile testare l’applicazione Web con lo strumento di certificato SSL / TLS online per individuare eventuali errori di configurazione.

Sicurezza Mod

Mod Security è un Web Application Firewall open source, che puoi usare con Apache.

Viene fornito come un modulo che devi compilare e installare. Se non puoi permetterti un firewall per applicazioni web commerciali, questa sarebbe un’ottima scelta.

Per fornire una protezione generica delle applicazioni Web, le Regole di base utilizzano le seguenti tecniche:

  • Protezione HTTP: rilevamento di violazioni del protocollo HTTP e una politica di utilizzo definita localmente
  • Ricerche in blacklist in tempo reale: utilizza la reputazione IP di terze parti
  • Rilevamento malware basato sul Web: identifica i contenuti Web dannosi mediante un controllo sull’API di navigazione sicura di Google.
  • Protezioni HTTP Denial of Service: difesa contro allagamenti HTTP e attacchi DoS HTTP lenti.
  • Protezione dagli attacchi Web comuni: rilevamento di attacchi alla sicurezza delle applicazioni Web comuni
  • Rilevamento dell’automazione: rilevamento di robot, crawler, scanner e un’altra attività superficiale dannosa
  • Integrazione con Scansione AV per caricamenti di file: identifica i file dannosi caricati tramite l’applicazione Web.
  • Tracciamento di dati sensibili: tiene traccia dell’utilizzo della carta di credito e blocca le perdite.
  • Protezione Trojan: rilevamento dell’accesso ai cavalli di Troia.
  • Identificazione dei difetti dell’applicazione – avvisi su errate configurazioni dell’applicazione.
  • Rilevamento e nascondere errori – Nascondere i messaggi di errore inviati dal server.

Scarica & Installazione

I seguenti prerequisiti devono essere installati sul server in cui si desidera utilizzare Mod Security con Apache. Se uno di questi non esiste, la compilazione di Mod Security fallirà. È possibile utilizzare yum install su Linux o Centos per installare questi pacchetti.

  • apache 2.xo superiore
  • pacchetto libpcre
  •  pacchetto libxml2
  • pacchetto liblua
  • pacchetto libcurl
  •  pacchetto libapr e libapr-util
  •  modulo mod_unique_id in bundle con il web server Apache

Ora, scarichiamo l’ultima versione stabile di Mod Security 2.7.5 da Qui

  • Trasferisci il file scaricato in / opt / apache
  • Estrai modsecurity-apache_2.7.5.tar.gz

# gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –

  • Vai alla cartella estratta modsecurity-apache_2.7.5

# cd modsecurity-apache_2.7.5

  • Esegui lo script di configurazione incluso il percorso apxs per Apache esistente

# ./configure –with-apxs = / opt / apache / bin / apxs

  • Compilare & installa con make script

# rendere
# make install

  • Al termine dell’installazione, vedrai mod_security2.so nella cartella dei moduli in / opt / apache

A questo punto, hai installato il modulo Mod Security nel web server Apache esistente.

Configurazione

Per utilizzare la funzione di sicurezza Mod con Apache, dobbiamo caricare il modulo di sicurezza mod in httpd.conf. Il modulo mod_unique_id è pre-requisito per Mod Security.

Questo modulo fornisce una variabile di ambiente con un identificatore univoco per ogni richiesta, che viene tracciata e utilizzata da Mod Security.

  • Aggiungi seguendo una riga per caricare il modulo per Mod Security in httpd.conf e salvare il file di configurazione

LoadModule unique_id_module modules / mod_unique_id.so
LoadModule security2_module modules / mod_security2.so

  •  Riavvia il web server apache

Mod Security è ora installato!

La prossima cosa che devi fare è installare la regola di base di Mod Security per sfruttare appieno la sua funzionalità.

L’ultima regola di base può essere scaricata dal seguente link, che è gratuito. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

  • Copia zip della regola principale scaricata nella cartella / opt / apache / conf
  • Decomprimi il file della regola principale
  • Potresti voler rinominare la cartella in qualcosa di breve e facile da ricordare. In questo esempio, rinominerò crs.
  • Vai alla cartella crs e rinomina modsecurity_crs10_setup.conf.example in modsecurity_crs10_setup.conf

Ora abilitiamo queste regole per farlo funzionare con il web server Apache.

  •  Aggiungi quanto segue in httpd.conf

Includi conf / crs / modsecurity_crs_10_setup.conf Includi conf / crs / base_rules / *. Conf

Nella configurazione sopra, stiamo caricando il file di configurazione principale di Mod Security modsecurity_crs_10_setup.conf e le regole di base base_rules / *. Conf fornite da Mod Security Core Rules per proteggere le applicazioni web.

  •  Riavvia il web server apache

Mod Security è stato configurato correttamente con Apache!

Molto bene. Ora, il server Web Apache è protetto dal firewall dell’applicazione Web Mod Security.

Iniziare

Cominciamo con alcune delle configurazioni critiche di Mod Security da rafforzare & applicazioni Web sicure.

In questa sezione, eseguiremo tutte le modifiche alla configurazione in /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

Faremo riferimento a /opt/apache/conf/crs/modsecurity_crs_10_setup.conf come setup.conf in questa sezione a scopo esemplificativo.

È importante capire quali sono le regole OWASP fornite gratuitamente. Esistono due tipi di regole fornite da OWASP.

Regole di base – queste regole sono pesantemente testate e probabilmente il rapporto di falsi allarmi è inferiore.

Regole Sperimentali – queste regole sono a scopo sperimentale e potresti avere un falso allarme elevato. È importante configurare, testare e implementare in UAT prima di utilizzarli in un ambiente di produzione.

Regole opzionali – queste regole opzionali potrebbero non essere adatte all’intero ambiente. In base alle tue esigenze puoi usarli.

Se stai cercando protezione CSRF, tracciamento utente, dirottamento sessione, ecc., Puoi prendere in considerazione l’utilizzo di regole opzionali. Abbiamo le regole di base, facoltative e sperimentali dopo aver estratto il file zip crs scaricato dalla pagina di download di OWASP.

Il file di configurazione di queste regole è disponibile nella cartella crs / base_rules, crs / optional_rules e crs / experimental_rules. Familiarizziamo con alcune delle regole di base.

  • modsecurity_crs_20_protocol_violations.conf: questa regola protegge dalle vulnerabilità del protocollo come la suddivisione della risposta, il contrabbando di richieste, l’utilizzo di un protocollo non consentito (HTTP 1.0).
  • modsecurity_crs_21_protocol_anomalies.conf: questo è per proteggere da una richiesta, che manca con Host, Accept, User-Agent nell’intestazione.
  • modsecurity_crs_23_request_limits.conf: questa regola ha la dipendenza specifica dall’applicazione come dimensione della richiesta, dimensione del caricamento, lunghezza di un parametro, ecc..
  • modsecurity_crs_30_http_policy.conf: serve per configurare e proteggere metodi consentiti o non consentiti come CONNECT, TRACE, PUT, DELETE, ecc..
  • modsecurity_crs_35_bad_robots.conf: rileva robot dannosi
  • modsecurity_crs_40_generic_attacks.conf: protegge dall’iniezione di comandi del sistema operativo, dall’inclusione remota dei file, ecc..
  • modsecurity_crs_41_sql_injection_attacks.conf: questa regola per proteggere la richiesta SQL e SQL Inject.
  • modsecurity_crs_41_xss_attacks.conf: protezione dalla richiesta di scripting tra siti.
  • modsecurity_crs_42_tight_security.conf: rilevamento e protezione degli attraversamenti delle directory.
  • modsecurity_crs_45_trojans.conf: questa regola per rilevare l’output di gestione dei file generici, caricamento della pagina backdoor HTTP, firma nota.
  • modsecurity_crs_47_common_exceptions.conf: viene utilizzato come meccanismo di eccezione per rimuovere i falsi positivi comuni che possono essere rilevati come connessione fittizia interna Apache, pinger SSL, ecc..

Registrazione

La registrazione è una delle prime cose da configurare in modo da poter creare registri per ciò che sta facendo Mod Security. Sono disponibili due tipi di registrazione; mettere a punto & Registro di audizione.

Registro di debug: serve per duplicare l’errore Apache, i messaggi di avviso e avviso dal registro degli errori.

Registro di controllo: per scrivere i registri delle transazioni contrassegnati dalla regola Mod Security, Mod Security offre la flessibilità di configurare Audit, Debug o entrambi i registri.

Per impostazione predefinita, la configurazione scriverà entrambi i registri. Tuttavia, è possibile modificare in base alle proprie esigenze. Il registro è controllato nella direttiva SecDefaultAction. Diamo un’occhiata alla configurazione di registrazione predefinita in setup.conf

SecDefaultAction “phase: 1, deny, log”

Per registrare il debug, registro di controllo – utilizzare “registro” Per registrare solo il registro di controllo – utilizzare “nolog, auditlog” Per registrare solo il registro di debug – utilizzare “registro, noauditlog” È possibile specificare la posizione del registro di controllo da memorizzare che è controllata da SecAuditLog direttiva.

Scriviamo il log di controllo in /opt/apache/logs/modsec_audit.log aggiungendo come mostrato di seguito.

  • Aggiungi la direttiva SecAuditLog in setup.conf e riavvia Apache Web Server

SecAuditLog /opt/apache/logs/modsec_audit.log

  • Dopo il riavvio, dovresti vedere modsec_audit.log generato

Abilita Rule Engine

Per impostazione predefinita, Engine Rule è disattivato, ciò significa che se non abiliti Rule Engine non stai utilizzando tutti i vantaggi di Mod Security.

L’abilitazione o la disabilitazione di Rule Engine è controllata dalla direttiva SecRuleEngine.

  • Aggiungi la direttiva SecRuleEngine in setup.conf e riavvia Apache Web Server

SecRuleEngine On

Esistono tre valori per SecRuleEngine:

  • On – per abilitare Rule Engine
  • Off – per disabilitare Rule Engine
  • DetectionOnly: abilita Rule Engine ma non esegue mai azioni come blocco, rifiuto, eliminazione, autorizzazione, proxy o reindirizzamento

Una volta attivato Rule Engine, Mod Security è pronto per la protezione con alcuni dei tipi di attacco più comuni.

Protezione del tipo di attacco comune

Ora il web server è pronto per la protezione con tipi di attacco comuni come XSS, SQL Injection, Protocol Violation, ecc. Poiché abbiamo installato Core Rule e acceso Rule Engine. Proviamo alcuni di loro.

Attacco XSS

  •  Apri Firefox e accedi all’applicazione e inserisci il tag alla fine o all’URL
  •  Monitora modsec_audit.log nella cartella apache / logs

Noterai la richiesta di blocchi di sicurezza Mod in quanto contiene tag che è la radice dell’attacco XSS.

Attacco di attraversamento di directory: – Gli attacchi di attraversamento di directory possono creare molti danni sfruttando questa vulnerabilità e accedendo al file relativo al sistema. Ex – / etc / passwd, .htaccess, ecc.

  •  Apri Firefox e accedi alla tua applicazione con l’attraversamento delle directory
  •  Monitora modsec_audit.log nella cartella apache / logs

http: // localhost / ../…/boot

  • Noterai la richiesta di blocchi di sicurezza Mod in quanto contiene l’attraversamento della directory.

Cambia banner server

In precedenza in questa guida, hai imparato come rimuovere Apache e il tipo di sistema operativo, guida della versione della direttiva ServerTokens.

Facciamo un passo avanti, che ne dici di mantenere il nome del server come preferisci? È possibile con la direttiva SecServerSignature in Mod Security. Vedi che è interessante.

Nota: per utilizzare Mod Security per manipolare Banner server da un’intestazione, è necessario impostare ServerTokesn su Completo in httpd.conf del server Web Apache.

  • Aggiungi la direttiva SecServerSignature con il nome del server desiderato in setup.conf e riavvia Apache Web Server

SecServerSignature YourServerName

Ex:

[/ opt / apache / conf / crs] #grep SecServer modsecurity_crs_10_setup.conf
SecServerSignature geekflare.com
[/ opt / apache / conf / crs] #

Configurazione generale

Diamo un’occhiata ad alcune delle configurazioni generali come best practice.

Configura Ascolta

Quando si hanno più interfacce e IP su un singolo server, si consiglia di configurare la direttiva Listen con IP assoluto e numero di porta.

Quando lasci la configurazione di Apache per l’ascolto su tutti gli IP con un certo numero di porta, ciò potrebbe creare il problema nell’inoltro della richiesta HTTP a qualche altro server web. Questo è abbastanza comune nell’ambiente condiviso.

  • Configurare la direttiva Listen in httpd.conf con IP e porta assoluti come nell’esempio mostrato di seguito

Ascolta il 10.10.10.1:80

Accedi alla registrazione

È essenziale configurare correttamente il registro degli accessi nel tuo server web. Alcuni dei parametri importanti da acquisire nel registro sarebbero il tempo impiegato per servire la richiesta, ID SESSIONE.

Per impostazione predefinita, Apache non è configurato per acquisire questi dati. Devi configurarli manualmente come segue.

  • Per acquisire il tempo impiegato per servire la richiesta e l’ID SESSIONE in un registro di accesso
  •  Aggiungi% T & % sessionID in httpd.conf sotto la direttiva LogFormat

LogFormat "% h% l% u% t "% {} SessionID C" "% r" %>s% b% T" Comune

Puoi fare riferimento http://httpd.apache.org/docs/2.2/mod/mod_log_config.html per un elenco completo dei parametri supportati nella direttiva LogFormat in Apache Web Server.

Disabilita caricamento di moduli indesiderati

Se hai compilato e installato con tutti i moduli, allora ci sono molte probabilità che avrai molti moduli caricati in Apache, che potrebbe non essere necessario.

La migliore pratica è configurare Apache con i moduli richiesti nelle tue applicazioni web. I seguenti moduli presentano problemi di sicurezza e potresti essere interessato a disabilitare in httpd.conf di Apache Web Server.

WebDAV (Distributed Authoring and Versioning basato sul Web) Questo modulo consente ai client remoti di manipolare i file sul server e soggetti a vari attacchi denial-of-service. Per disabilitare i commenti seguenti in httpd.conf

#LoadModule dav_module modules / mod_dav.so
#LoadModule dav_fs_module modules / mod_dav_fs.so
#Includi conf / extra / httpd-dav.conf

Modulo Info Il modulo mod_info può perdere informazioni sensibili usando .htaccess una volta caricato questo modulo. Per disabilitare i commenti seguenti in httpd.conf

#LoadModule info_module modules / mod_info.so

Riferimento: questo non sarebbe possibile senza una guida dal seguente link:

Quindi quelle erano alcune delle migliori pratiche che puoi usare per proteggere il tuo server web Apache.

Se non conosci Apache HTTP, ti consiglio di prenderlo il corso di amministrazione HTTP di Apache.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map