Domanda:
Best practice per la protezione avanzata di Apache Server?
Eric Warriner
2010-11-12 05:08:13 UTC
view on stackexchange narkive permalink

Quali sono alcune best practice, consigli e letture obbligatorie per proteggere un server Apache?

Potresti anche voler controllare la [Configurazione sicura del server web Apache, Apache Server versione 1.3.3 su Red Hat Linux 5.1] (http://www.nsa.gov/ia/_files/webs/archived/apacheWS.pdf) . È una guida della NSA
"Proteggi il tuo apache così non possiamo rubare roba" articolo ehi? ; P
Sebbene questo collegamento possa rispondere alla domanda, è meglio includere le parti essenziali della risposta qui e fornire il collegamento come riferimento. Le risposte di solo collegamento possono diventare non valide se la pagina collegata cambia.
Dead-link! ... kinda ....
Undici risposte:
#1
+33
Tate Hansen
2010-11-12 05:43:50 UTC
view on stackexchange narkive permalink

Prendi la guida del Center for Internet Security (CIS) per proteggere Apache (descrive in dettaglio come migliorare la sicurezza):

Modifica: link aggiornato CIS Apache HTTP Server 2.2.x Benchmark

Se disponi di una licenza per Nessus, puoi eseguire un controllo automatico acquisendo il loro modello di audit:

alt text

Tutti i file PDF dei benchmark CIS sono disponibili su https://github.com/cismirror/benchmarks
#2
+12
Wyck
2011-07-17 21:52:29 UTC
view on stackexchange narkive permalink
  • Usa accessi basati su chiave SSH
  • Proteggi MySQL
  • Disabilita phpMyAdmin, webmin, ecc
  • Chiudi tutte le porte / processi che non sono necessari
  • Usa un controllo dell'integrità dei file
  • Usa mod_security
  • Imposta i permessi / gruppi appropriati

Questa è una buona guida:
https://serverfault.com/questions/212269/tips-for-securing-a-lamp-server

Guida di base per la protezione avanzata: http: //www.wpsecure.net/server-guide/

Se stai usando php: http://www.madirish.net/?article=229

Trova i 404 (o altri codici di stato) nel log di apache
awk '$ 9 == 404 {print $ 7}' access_log | uniq -c | sort -rn | head

Gli accessi basati su chiavi sono ottimi tranne quando ti chiedi dove tenere le chiavi.
#3
+7
Jeff Ferland
2012-01-12 04:46:39 UTC
view on stackexchange narkive permalink

La risposta originariamente molto votata a questa domanda che è stata accettata è stata eliminata perché era un plagio diretto di 20 modi per proteggere la tua configurazione di Apache. Quella pagina è una risorsa fantastica.

@RoryMcCune ha anche pubblicato questo come collegamento a quella risposta: C'è un progetto OWASP per sviluppare un ModSecurity Core Rule Set qui che potrebbe essere utile .

L'ultimo commento sul [collegamento in 20 modi] (http://www.petefreitag.com/item/505.cfm) risale al 2014 e conferma che si tratta di una buona informazione, quindi credo che le informazioni siano ancora aggiornate e buone pratiche?Ho appena iniziato con Apache qui ..
#4
+6
Marcin
2010-11-23 01:15:41 UTC
view on stackexchange narkive permalink

Si applicano tutti i principi generali di sicurezza: esegui solo i moduli di cui hai bisogno, disattiva le funzionalità che non ti servono, riordina i tuoi permessi / proprietà (la maggior parte dei contenuti è di sola lettura, quindi perché i file hanno bisogno di qualcosa di più di 400 perm ?).

Le cose che sono particolari per Apache, come i lavori CGI, o diversi vhost che servono due volte lo stesso contenuto con due diversi meccanismi di sicurezza sono molto più difficili da individuare; non esattamente un controllo automatico, in realtà devi conoscere Apache, il sistema operativo sottostante e cosa stanno facendo le applicazioni in esecuzione in Apache.

Per completezza, ecco un Apache 2.2 Security Checklist di DISA. AGGIORNAMENTO: ecco un collegamento alla loro intera raccolta di documenti di rafforzamento del server web.

Ciò restituisce 404 non trovato ora purtroppo. Ti capita di possederne una copia (supponendo che sia di dominio pubblico e che tu sia autorizzato a condividerlo)?
@sa289 buona cattura, link aggiornati
#5
+6
Ori
2011-07-18 00:17:42 UTC
view on stackexchange narkive permalink

Ci sono molti buoni consigli qui, quindi non ripeterò le cose già menzionate. Ma quello che dirò è:

Non dimenticare di sostituire le pagine di errore predefinite con cose che non rivelano la versione del server Web o la revisione del kernel. Tendo a sostituire ogni html predefinito con 1 liner che sono qualcosa come "Errore 400". Dà ben poco sul sistema. Questo principio si applica a tutti i server Web in grado di visualizzare pagine di errore personalizzate, praticamente tutti per impostazione predefinita forniscono troppe informazioni del necessario. Si potrebbe pensare che ServerSignature lo nasconda, ma in molti casi non lo fa.

Inoltre, non dimenticare di eliminare tutto il contenuto HTML predefinito (specifico della lingua, ecc.), Quindi l'impronta digitale è molto più difficile.

Per quanto riguarda le buone letture, c'era un white paper di Apcon 2008 che vale la pena leggere.

Mod_Security è menzionato come poche volte, questo è più adatto alle applicazioni web, quindi se stai servendo solo contenuto statico, non ti aiuterà troppo molto, sebbene ci siano alcuni attacchi da cui ti difendi durante la gestione delle richieste che potrebbero influenzare un server Web statico.

L'altra cosa che vorrei menzionare è una buona gestione dei log, se non stai coltivando i tuoi log e non stai tenendo d'occhio il sistema, corri il rischio che un utente malintenzionato lo attacchi senza averne consapevolezza di esso.

#6
+4
Mark Davidson
2010-11-12 05:22:28 UTC
view on stackexchange narkive permalink

Potrebbe valere la pena dare un'occhiata a mod_security di Apache.

Ultimamente ho provato alcuni dei miei server non solo esegue alcune modifiche alla configurazione di Apache stesso come la modifica del numero di versione ecc. ma funge anche da firewall per applicazioni web che aiuta a proteggersi da un un'ampia varietà di attacchi come SQL injection ecc.

#7
+2
symcbean
2012-01-13 20:03:47 UTC
view on stackexchange narkive permalink

Come posso proteggere il server Web Apache

Che risposta ti aspetteresti se chiedessi "Come faccio a pilotare un jumb-jet" o "Come faccio a fare un intervento chirurgico al cervello "- lo stesso vale per rendere sicuro un server web - devi fare migliaia di ore di formazione, pratica e ricerca. Ma poiché tutti devono iniziare da qualche parte ...

Ci sono molte liste di controllo di base su Internet su come rafforzare un server, ma secondo il mio commento altrove variano notevolmente in qualità.

Consiglierei sans one come buona fonte.

Dopo aver seguito l'elenco di controllo, devi stabilire i mezzi con cui può

  • verificare l'integrità del tuo server (hai sicuramente bisogno di un IDS basato su host come tripwire insieme a un rilevatore di rootkit)
  • essere consapevole e applicare le patch
  • Ripristina il tuo sistema a un buono stato noto

Non pianificare come affrontare un incidente di sicurezza se si verifica. Pianifica cosa fare quando accadrà.

Dopo aver impostato e configurato il tuo sistema, sostituisci il disco rigido e guarda quanto tempo ci vuole per ottenere il servizio di nuovo funzionante senza utilizzare il disco originale.

#8
+1
that guy from over there
2013-07-08 12:19:25 UTC
view on stackexchange narkive permalink

questo non è solo correlato ad apache (e conta anche per nginx + php-fpm), ma spesso dimenticato: php-eastereggs, che potrebbe essere disattivato tramite php.ini

  expose_php = off  

non è così terribile come lasciare un phpinfo.php alle spalle, ma di solito è un suggerimento per un'amministrazione del sistema molto pigra.

vedi pasqua -uova

#9
  0
Novice User
2012-01-12 01:50:10 UTC
view on stackexchange narkive permalink

Usa l'ultima versione di apache, patcha il tuo sistema operativo e anche di terze parti come openssl o qualsiasi altro.

Blocca le porte indesiderate.

Questo ti proteggerà da vulnerabilità, ma sarai sempre suscettibile a uno 0 giorni, ovviamente.

#10
  0
user29424
2013-08-12 12:42:56 UTC
view on stackexchange narkive permalink

Buon filo girato. Molte persone dicono la verità.

Ne hanno dimenticata una, a modo di OpenBSD:

In OpenBSD, il server Apache httpd (8) è stato chroot (2) ed predefinito

httpd (v.1 di Apache) incluso in OpenBSD per impostazione predefinita e chrootato per impostazione predefinita.

Puoi ripeterlo facilmente con apache2 o nginx su qualsiasi altro sistema operativo Unix.

#11
  0
Mike
2015-04-10 18:54:16 UTC
view on stackexchange narkive permalink

Ecco 6 passaggi chiave:

  1. Proteggi il codice dell'applicazione
  2. disabilita tutti i moduli non utilizzati. Prova a disabilitare tutto, quindi, uno per uno, aggiungi i moduli.
  3. rimuovi tutti gli script e i file di backup nella cartella web.
  4. disabilita l'elenco delle directory
  5. usa modsecurity per proteggere la tua applicazione da attacchi a livello di applicazione.
  6. Usa Fail2ban per attivare errori HTTP (403, 404).

non fare affidamento sul firewall di rete, è inutile quando si parla di sicurezza web.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...