2009-04-03 13 views
5

Capisco la necessità di mettere un server web in una DMZ e bloccare il traffico in entrata verso tutte le porte tranne 80 e 443. Posso anche capire perché probabilmente dovresti anche bloccare la maggior parte del traffico in uscita nel caso in cui il server sia compromesso.Il firewall di un server web potrebbe bloccare il traffico HTTP in uscita sulla porta 80?

Ma è necessario bloccare il traffico HTTP in uscita sulla porta 80? Se è così, perché? Molte applicazioni Web in questi giorni si basano sull'invio/recupero di dati da servizi Web esterni e API, quindi il blocco del traffico in uscita sulla porta 80 impedirebbe questa possibilità. C'è un problema di sicurezza che è abbastanza valido per giustificare questo?

risposta

7

L'unico motivo per cui posso pensare è se la tua macchina è in qualche modo compromessa da remoto, quindi non sarà in grado di DDoS un altro sito sulla porta 80. Non è qualcosa che normalmente faccio però.

-2

che cosa si intende con il blocco del traffico in uscita sulla porta 80.

avete due possibilità. Regole dinamiche di Gernerate che consentono la comunicazione dal client al server web per questa sessione. Cerca regole firewall stateful.

O generalmente si consente a Connessioni stabilite di comunicare tra loro e in uscita.

Se generalmente si blocca tutto il traffico in uscita sulla porta 80, il server Web non è in grado di rispondere a nessun client.

Al contrario, se il server Web deve ottenere alcune API, ad es. una libreria jquery non userà la porta 80 come sua porta per comunicare con il server Web che detiene l'API.

Il server Web dovrebbe normalmente scegliere una porta> 1024 e utilizzarlo per la sua richiesta per ottenere l'API dal server remoto.

Quindi bloccare tutto il traffico sulla porta 80 (come la porta da cui si effettua la connessione) non impedisce al server di inviare richieste di apis e cose simili. perché non usa la porta 80 quando agisce come cliente.

+0

Sto parlando di consentire al server Web di avviare connessioni HTTP in uscita (porta 80) ad altri server su Internet. Ad esempio, potresti avere una pagina PHP che contiene un widget meteo. Tale script avrebbe bisogno di richiedere i dati meteo da un servizio web esterno. –

+0

ah ok, pensavo volessi dire bloccare la porta 80 come porta di avvio. Se si blocca questo, non è possibile caricare apis e cose simili da altre pagine. Probabilmente puoi aggiungere alcuni siti di cui ti fidi alle tue regole. Ma direi che bloccare Port 80 generalmente non ha molto senso. – evildead

+0

da un altro punto di vista, se il tuo server viene hackerato e blocchi quel traffico non può caricare codice abituale da altri siti. Ma chi garantisce che l'hacker/robot/qualunque cosa stia usando la porta 80 per la sua richiesta :) – evildead

0

Piuttosto che bloccarlo, strozzarlo. Usa il limite di iptables -m.

0

Possiedo diverse app Web che invocano servizi Web esterni, quindi direi che è una cattiva idea bloccare il traffico HTTP in uscita. Se si è interessati alla sicurezza, è possibile bloccarlo e consentire solo determinate destinazioni.

+0

Una lista bianca è un buon suggerimento, ma non funzionerà con OpenID, che richiede che il server web sia in grado di richiedere qualsiasi URL usato come un OpenID. –

+0

Non solo, non funzionerà con nessun sito Web che cambierà mai l'indirizzo IP. Questo è il modo in cui il firewall di cui ho bisogno per richiedere modifiche per funzionare - a livello IP, non a livello di dominio (lo considero a fini di efficienza?) È un vero problema dato che alcuni IP cambiano molto. –

+0

Inoltre, non ci sarà sempre qualche servizio che potrebbe, in teoria, essere usato per DDOS un altro host? Ad esempio, sul mio host HTTP bloccato in uscita, ping può ancora contattare qualsiasi host. –

0

seconda della versione di SQL, si potrebbe avere il certificato di autenticazione tempo fuori problemi con SQL Server 2005.

0

In primo luogo - sono d'accordo con @vartec sulla strozzatura "Invece di bloccarlo, acceleratore è limitare l'uso iptables -m. "come almeno parte della soluzione.

Tuttavia, posso offrire un altro motivo per non bloccare la porta 80 in uscita in qualsiasi momento. Se si dispone di aggiornamenti di sicurezza automatici attivati, il server non può raggiungere i PPA sulla porta 80 per avviare un aggiornamento di sicurezza. Pertanto, se si dispone di aggiornamenti di sicurezza automatici, non verranno eseguiti. Su Ubuntu auto-aggiornamenti di sicurezza sono attivate in 14.04 LTS con:

sudo apt-get install unattended-upgrades update-notifier-common && \ 
sudo dpkg-reconfigure -plow unattended-upgrades 
(then select "YES") 

soluzioni più aggraziato sarebbe script ansible aprono automaticamente la porta, eventualmente anche modificare una regola di gruppo di protezione AWS tramite la CLI, oltre a iptables se sono ad AWS. Preferisco modificare temporaneamente le mie regole in uscita tramite la CLI di AWS avviata da una casella invisibile. Ciò impone la registrazione dell'aggiornamento nei bucket di log di AWS S3, ma non compare mai nei log del server stesso.Inoltre il server che avvia l'aggiornamento non deve nemmeno essere nella ACL della subnet privata.

Forse entrambi? Devi capire a volte che un attacco rilascerà un IP interno nella tua sottorete, quindi c'è il merito di raddoppiare mentre preserva la capacità di automatizzare i backup e gli aggiornamenti di sicurezza.

Spero che questo aiuti. Se non rispondete e fornite più esempi di codice per essere più specifici ed esatti. #Rimanga sicuro !

0

Se la macchina è compromessa e il traffico in uscita sulla porta 80 è consentito, renderebbe più semplice per gli intrusi inviare di nuovo i dati raccolti. Consentire il traffico in uscita significa che puoi avviare una connessione dalla tua macchina al mondo esterno. Un approccio migliore sarebbe consentire il traffico in uscita solo verso determinati siti Web/indirizzi di cui ti fidi (ad esempio Microsoft Windows Update, Google reCAPTCHA) piuttosto che qualsiasi destinazione nel mondo.