Overkill di sicurezza del server Web?

9

Ho fatto ricerche "approfondite" sulla protezione di un server Web Linux. Oltre a ciò che è considerato il "principio di base" (rimozione di servizi inutilizzati, rafforzamento di ssh, iptables, ecc.) È saggio includere anti-rootkits (Tripwire) e un antivirus (ClamAV)? Questi sono solo eccessivi per un server web? So che questa è una domanda molto vaga, ma sono curioso delle opinioni degli altri.

Il mio ambiente futuro: - ubuntu 10.04 - fail2ban - nginx 0.8.x - php 5.3.x (suhosin, apc, memcached) - mongodb 1.6.x

Possibili applicazioni: - servizi Web - app Web con caricamenti dell'utente (immagini, pdf, ecc.) - siti Web tipici (moduli, ecc.)

Se hai altri suggerimenti, non esitare ad aggiungere!

Grazie

— Aaron
fonte

8

Per un server pubblico, direi che installare qualcosa come tripwire non è eccessivo.

ClamAV è una questione diversa. Vorrei prendere in considerazione l'idea che se i tuoi visitatori condivideranno file caricando e scaricando dal tuo sito web. I PDF possono contenere exploit.

Sui server pubblici, ho SSH che non consente l'autenticazione con password, ma solo l'autenticazione con chiave pubblica. Se SSH è possibile solo da una LAN interna, potresti rilassarlo.

Laddove possibile, posizionerei il server su una DMZ in modo che non possa originare connessioni ad altri computer sulle LAN interne.

— RedGrittyBrick
fonte

2

Non dimenticare LMD (Linux Malware Detection), rfxn.com/projects/linux-malware-detect : esegue la scansione del tipo di malware che infetta le applicazioni Web (HTML, PHP, modifiche ai file JavaScript) per utilizzare il tuo sito per Spamming SEO, phishing, infezione dei PC dei visitatori, ecc.

— RichVel,

3

No, non sei andato abbastanza lontano.

1) È necessario un firewall per applicazioni Web come mod_security e assicurarsi che sia configurato per bloccare gli attacchi, non solo per registrarli.

2) Blocca php con phpsecinfo .

3) Blocca l'account MySQL della tua applicazione web, assicurati che l'applicazione non abbia FILEprivilegi, è di gran lunga la più pericolosa di MySQL.

4) Firewall su UDP e TCP non necessari. Prendi in considerazione l'utilizzo port knocking per ssh. Non riuscire a bandire non è quasi buono come ottenere zero tentativi.

— Torre
fonte

1) Ho avuto l'impressione che ModSecurity potesse essere impacchettato solo con Apache (sto usando nginx). Ma a quanto pare può funzionare autonomamente? Dovrò esaminare questo grazie! Ho seguito calomel.org/nginx.html per alcune funzionalità.

— Aaron,

4) Uso iptables per bloccare tutto il traffico in entrata e in uscita a meno che non sia la mia porta ssh, https o https (in entrata, in uscita). Aprirò di più man mano che procederò. Port knocking è un'aggiunta interessante per ssh, però! Grazie ancora!.

— Aaron,

@Aaron non sono sicuro del perché dovresti usare nginx. Puoi usare apache + mod_security come proxy con qualsiasi httpd strano e privo di caratteristiche che richiedi di utilizzare.

— Torre del

2

Probabilmente puoi installare AIDE in sicurezza su un server web - l'aggiunta e la rimozione di clienti non modifica troppi file di configurazione e potresti probabilmente filtrare abbastanza facilmente le normali chiacchiere.

Ma qualcosa che molte guide sulla sicurezza del web server non menzionano è che dovresti attivare noexec sulla tua partizione / tmp in / etc / fstab. Se offri hosting al pubblico, molte persone installeranno applicazioni web non sicure a tua insaputa (e non avranno le conoscenze stesse per mantenere aggiornate le loro applicazioni), e praticamente inseguirai questi bug per sempre. Se ti assicuri che l'unico posto in cui un utente malintenzionato può salvare il software è la home directory del cliente e la directory / tmp, allora l'attaccante corre il rischio di mostrarti dove si sta intrufolando se non può usare la directory / tmp. A loro non piace farlo.

In questo modo è stata risolta la stragrande maggioranza dei problemi di sicurezza sul nostro server di web hosting.

— Ernie
fonte

2

"Benvenuto a bordo! A bordo del nostro nuovo aereo di linea puoi goderti il ristorante, il cinema, la palestra, la sauna e la piscina. Ora allaccia le cinture di sicurezza, il nostro capitano cercherà di far volare tutta questa merda."

mod_security è una seccatura sia per te che per il server. Ha fame di risorse e le sue regole hanno bisogno di un serio mantenimento e sarà un compito infinito. E no, non funziona da solo o con Nginx. Se ritieni di averne davvero bisogno, imposta un server proxy separato (Apache, mod_proxy, mod_security). Funziona anche come DMZ, i tuoi server reali possono essere chiusi completamente al mondo esterno e se il proxy viene violato, non c'è comunque nulla.
Anche ClamAV è molto pesante, se eseguito come demone. È meglio eseguire clamscan periodicamente durante le ore non attive da Cron.
Tripwire è eccessivo, IMHO. Ma sarebbe utile qualcosa in grado di dare la caccia ai rootkit, ci sono molti script (rkhunter, chkrootkit).
Credo che almeno il 90% dei rootkit ecc. Arrivi ai server tramite upload da macchine Windows sviluppatore. Non c'è davvero un buon modo per impedirlo, tranne forse costringere gli sviluppatori a non usare mai Windows. La maggior parte dei trojan cerca credenziali FTP, quindi non usare mai FTP.

— Moskit
fonte

Buono a sapersi ... Considerando che non ho intenzione di prendere la strada di Apache, mi atterrò a qualsiasi aspetto di sicurezza che posso trovare per nginx. Probabilmente finirò per prendere anche il percorso clamscan / rkhunter. Grazie per i suggerimenti!

— Aaron,

0

L'uso della protezione del modulo captcha nel popolare motore CMS (Wordpress, Jomlaa, Drupal) è considerato una pratica di sicurezza? Se sì, puoi usare questi:

— affanzbasalamah
fonte

Protezione anti spam ? Sì. Ma qui l'autore vuole bloccare il suo server contro utenti non autorizzati, di cui captcha non ha nulla a che fare.