Protezione del server PHP Apache Debian

Naviga le tue risposte
8

Ho un server PHP Apache Debian. Voglio proteggerlo dopo il classico processo di installazione.

I miei soliti passaggi sono:

  • elenca gli elementi
  • aggiorna tutti i pacchetti
  • rimuovi tutti i servizi non necessari come named, portmap, lwresd ...
  • aggiungi uno script di iptables di avvio: blocca tutto tranne 22 e 80 all'interno e consenti a tutti all'esterno. Forza i pacchetti SYN, forza i pacchetti dei frammenti di controllo, elimina i pacchetti XMAS, rilascia Elimina tutti i pacchetti NULL, elimina l'ip locale su wan, tutto solo icmp tipo 0 e 8.
  • SSH: rimuove l'autenticazione di accesso e password di root. Utilizzare invece le chiavi. Consenti solo il nome utente valido. Solo protocollo 2
  • PHP: expose_php=Off , limita i moduli PHP a quelli usati, non mostra errori al visitatore: display_errors=Off e log_errors=On , allow_url_fopen=Off , allow_url_include=Off e rimuovi pericolose funzioni
  • Apache: ServerSignature Off , ServerTokens Prod
  • Installa pacchetto aggiuntivo: fail2ban (protezione bruteforce SSH), chkrootkit (rilevamento rootkit), logwatch (cura registro giorno per giorno), munin (monitoraggio risorse), apticron (guarda per il nuovo aggiornamento)

Vedi qualcos'altro?

    
posta hotips 18.09.2012 - 10:38
fonte

5 risposte

3

Suggerirei di ottenere un IDS basato sull'host configurato e il database delle firme è popolato, rimuovendo qualsiasi contenuto fornito con Apache. Esegui anche il controllo del modello delle autorizzazioni in relazione alla registrazione, in modo che non sia necessario essere root per leggere i file.

Ci sono anche molte cose che potresti voler fare a seconda di cosa fai con il server - controlla il timeout e la dimensione massima del post per apache, imposta un open_basedir per PHP (insieme ai soliti miglioramenti delle prestazioni).

    
risposta data 18.09.2012 - 10:49
fonte
1

Oltre a tutto ciò che hai già fatto, ci sono repository Debian ausiliari che potresti trovare utili da usare se preferisci mantenere l'installazione più vicina a bleeding:

Il link è un buon esempio

Questi repository non sono affatto una sostituzione per le distribuzioni ufficiali di Debian; essere più vicino al lato sanguinante ti dà aggiornamenti più veloci, ma potrebbe non essere stato testato con gli stessi rigorosi standard che i manutentori dei pacchetti Debian sostengono. Come sempre, è un compromesso.

Se hai bisogno di bloccare gli spammer, moblock può aiutarti con questo a livello IP, e c'è una buona selezione di elenchi gestiti (Bluetack, spamhaus ecc.)

    
risposta data 18.09.2012 - 12:44
fonte
1

Anche se è per Ubuntu, dovrebbe aiutare a cogliere il punto: link

    
risposta data 26.09.2012 - 20:50
fonte
1

Non dimenticare di modificare le autorizzazioni per www-data e per il tuo utente SSH all'interno della web root.

Se si tratta di una sorta di webapp e gli utenti finali sono autorizzati a caricare file, ti consigliamo di assicurarti che nulla di quello che caricano sia eseguibile. Alcuni hack intelligenti comportano il caricamento di file binari mascherati da immagini jpg su server con permessi non validi.

Questo è un post eccellente (vedi la risposta migliore) sulle autorizzazioni: link

    
risposta data 30.11.2012 - 07:00
fonte
0

SELinux , se sei incline a configurarlo. La Guida di Red Hat è quasi completamente compatibile con come è configurato su Debian.

    
risposta data 30.11.2012 - 10:31
fonte

Leggi altre domande sui tag

Algoritmi di crittografia con un codice di errore per la password errata Rischi di esecuzione di Honeypot [configurazione specifica]