ATTENZIONE: non sono interessato a trasformarlo in una guerra di fiamme! Comprendo che molte persone hanno fermamente convinto l'argomento, in gran parte perché hanno fatto molti sforzi nelle loro soluzioni di firewalling e anche perché sono stati indottrinati a credere nella loro necessità.

Tuttavia, cerco risposte da persone esperte di sicurezza. Credo che questa sia una domanda importante e la risposta trarrà beneficio più di me e della società per cui lavoro. Gestisco la nostra rete di server da diversi anni senza compromessi, senza alcun firewall. Nessuno dei compromessi di sicurezza che abbiamo abbiamo avuto avrebbe potuto essere evitata con un firewall.

Immagino di aver lavorato qui troppo a lungo, perché quando dico "server" intendo sempre "servizi offerti al pubblico", non "database di fatturazione interni segreti". Pertanto, qualsiasi regola che avremmo in qualsiasi firewall dovrebbe consentire l'accesso a tutta Internet. Inoltre, i nostri server di accesso pubblico sono tutti in un centro dati dedicato separato dal nostro ufficio.

Qualcun altro ha posto una domanda simile e la mia risposta è stata votata in numeri negativi. Questo mi porta a credere che o le persone che hanno votato per difetto non abbiano davvero capito la mia risposta, o non capisco abbastanza la sicurezza per fare quello che sto facendo.

Questo è il mio approccio alla sicurezza del server:

1. Seguire le linee guida di sicurezza del mio sistema operativo prima di connettere il mio server a Internet.

2. Utilizzare i wrapper TCP per limitare l'accesso a SSH (e altri servizi di gestione) a un numero limitato di indirizzi IP.

3. Monitora lo stato di questo server con Munin . E risolvi i notevoli problemi di sicurezza inerenti al nodo Munin nella sua configurazione predefinita.

4. Nmap il mio nuovo server (anche prima di connettere il mio server a Internet). Se dovessi firewall questo server, questo dovrebbe essere il set esatto di porte a cui dovrebbero essere limitate le connessioni in entrata.

5. Installa il server nella stanza del server e assegnagli un indirizzo IP pubblico.

6. Mantieni il sistema sicuro utilizzando la funzione degli aggiornamenti di sicurezza del mio sistema operativo.

La mia filosofia (e la base della domanda) è che una forte sicurezza basata su host rimuove la necessità di un firewall. La filosofia generale di sicurezza afferma che è necessaria una solida sicurezza basata su host anche se si dispone di un firewall (consultare le linee guida di sicurezza ). La ragione di ciò è che un firewall che inoltra i servizi pubblici a un server abilita un aggressore tanto quanto nessun firewall. È il servizio stesso a essere vulnerabile e poiché offrire tale servizio all'intera Internet è un requisito del suo funzionamento, limitare l'accesso ad esso non è il punto.

Se ci sono porte disponibili sul server a cui non è necessario accedere dall'intera Internet, quel software doveva essere chiuso nel passaggio 1 ed è stato verificato dal passaggio 4. Se un utente malintenzionato dovesse penetrare correttamente nel server attraverso un software vulnerabile e aprono una porta da soli, l'attaccante può (e fare) altrettanto facilmente sconfiggere qualsiasi firewall stabilendo invece una connessione in uscita su una porta casuale. Il punto di sicurezza non è difendersi dopo un attacco riuscito - che si è già dimostrato impossibile - è in primo luogo tenere fuori gli attaccanti.

È stato suggerito che ci sono altre considerazioni sulla sicurezza oltre alle porte aperte, ma per me sembra solo difendere la propria fede. Qualsiasi vulnerabilità del sistema operativo / stack TCP dovrebbe essere ugualmente vulnerabile indipendentemente dall'esistenza di un firewall, in base al fatto che le porte vengono inoltrate direttamente a quel sistema operativo / stack TCP. Allo stesso modo, eseguire il firewall sul server stesso anziché averlo sul router (o peggio, in entrambi i posti) sembra aggiungere livelli di complessità non necessari. Capisco la filosofia "la sicurezza arriva a strati", ma arriva un punto in cui è come costruire un tetto impilando X numero di strati di compensato uno sopra l'altro e poi praticando un foro attraverso tutti loro. Un altro strato di compensato non fermerà le perdite attraverso quel buco che

Ad essere onesti, l'unico modo in cui vedo che un firewall è utile per i server è se ha regole dinamiche che impediscono tutte le connessioni a tutti i server da attacchi noti - come gli RBL per lo spam (che per coincidenza, è praticamente ciò che fa il nostro server di posta) . Sfortunatamente, non riesco a trovare alcun firewall che lo faccia. La prossima cosa migliore è un server IDS, ma ciò presuppone che l'attaccante non attacca prima i tuoi server reali e che gli attaccanti si preoccupano di sondare l'intera rete prima di attaccare. Inoltre, questi sono noti per produrre un gran numero di falsi positivi.

Vantaggi del firewall:

1. Puoi filtrare il traffico in uscita.
2. I firewall di livello 7 (IPS) possono proteggere dalle vulnerabilità delle applicazioni conosciute.
3. È possibile bloccare un determinato intervallo di indirizzi IP e / o porta centralmente anziché tentare di garantire che non vi sia alcun servizio in ascolto su quella porta su ogni singolo computer o negando l'accesso tramite TCP Wrapper .
4. I firewall possono essere d'aiuto se si hanno a che fare con utenti / amministratori meno attenti alla sicurezza in quanto fornirebbero una seconda linea di difesa. Senza di essi si deve essere assolutamente sicuri che gli host siano sicuri, il che richiede una buona comprensione della sicurezza da parte di tutti gli amministratori.
5. I registri del firewall forniscono registri centrali e aiutano a rilevare le scansioni verticali. I log del firewall possono aiutare a determinare se alcuni utenti / client stanno tentando di connettersi periodicamente alla stessa porta di tutti i server. Per fare ciò senza un firewall, è necessario combinare i registri di vari server / host per ottenere una vista centralizzata.
6. I firewall sono inoltre dotati di moduli anti-spam / anti-virus che aumentano la protezione.
7. Sicurezza indipendente dal sistema operativo. In base al sistema operativo host, sono necessarie diverse tecniche / metodi per rendere sicuro l'host. Ad esempio, i wrapper TCP potrebbero non essere disponibili sui computer Windows.

Soprattutto se non si dispone di firewall e il sistema è compromesso, come lo rileveresti? Cercare di eseguire alcuni comandi 'ps', 'netstat', ecc. Sul sistema locale non può essere considerato attendibile in quanto tali binari possono essere sostituiti. La protezione 'nmap' da un sistema remoto non è garantita in quanto un utente malintenzionato può garantire che il root-kit accetti connessioni solo da indirizzi IP di origine selezionati in determinati orari.

I firewall hardware aiutano in tali scenari in quanto è estremamente difficile cambiare il sistema operativo / file del firewall rispetto al sistema operativo / file host.

Svantaggi del firewall:

1. Le persone ritengono che il firewall si occuperà della sicurezza e non aggiornerà i sistemi regolarmente e fermerà i servizi indesiderati.
2. Costano. A volte è necessario pagare il canone annuale. Soprattutto se il firewall ha moduli anti-virus e anti-spam.
3. Singolo punto di errore aggiuntivo. Se tutto il traffico passa attraverso un firewall e il firewall fallisce, la rete si fermerebbe. Possiamo avere firewall ridondanti, ma poi il punto precedente sui costi viene ulteriormente amplificato.
4. Il monitoraggio con stato non fornisce alcun valore sui sistemi rivolti al pubblico che accettano tutte le connessioni in entrata.
5. I firewall con stato sono un enorme collo di bottiglia durante un attacco DDoS e spesso sono la prima cosa a fallire, perché tentano di mantenere lo stato e ispezionare tutte le connessioni in entrata.
6. I firewall non possono vedere all'interno del traffico crittografato. Poiché tutto il traffico deve essere crittografato end-to-end, la maggior parte dei firewall aggiunge poco valore ai server pubblici. Ad alcuni firewall di prossima generazione possono essere fornite chiavi private per terminare TLS e vedere all'interno del traffico, tuttavia ciò aumenta ulteriormente la suscettibilità del firewall a DDoS e interrompe il modello di sicurezza end-to-end di TLS.
7. I sistemi operativi e le applicazioni sono patchati contro le vulnerabilità molto più rapidamente dei firewall. I fornitori di firewall spesso siedono su problemi noti per anni senza patch, e la patch di un cluster firewall in genere richiede tempi di inattività per molti servizi e connessioni in uscita.
8. I firewall sono tutt'altro che perfetti e molti sono notoriamente buggy. I firewall sono solo software in esecuzione su una qualche forma di sistema operativo, forse con un ASIC o FPGA aggiuntivo oltre a una CPU (solitamente lenta). I firewall hanno dei bug, ma sembrano fornire pochi strumenti per risolverli. Pertanto i firewall aggiungono complessità e un'ulteriore fonte di errori difficili da diagnosticare a uno stack di applicazioni.

I wrapper TCP potrebbero essere probabilmente chiamati un'implementazione del firewall basata su host; stai filtrando il traffico di rete.

Per quanto riguarda l'attaccante che effettua connessioni in uscita su una porta arbitraria, un firewall fornirebbe anche un mezzo per controllare il traffico in uscita; un firewall correttamente configurato gestisce l'ingresso e l'uscita in modo adeguato al rischio relativo al sistema.

Sul punto in cui una vulnerabilità TCP non è mitigata da un firewall, non si ha familiarità con il funzionamento dei firewall. Cisco ha un sacco di regole disponibili per il download che identificano i pacchetti costruiti in modo da causare particolari problemi del sistema operativo. Se prendi Snort e inizi a eseguirlo con il giusto set di regole, verrai anche avvisato di questo tipo di cose. E, naturalmente, iptables Linux può filtrare i pacchetti dannosi.

Fondamentalmente, un firewall è una protezione proattiva. Più ti allontani dall'essere proattivo, più è probabile che ti troverai in una situazione in cui stai reagendo a un problema piuttosto che prevenendolo. Concentrare la tua protezione alla frontiera, come con un firewall dedicato, semplifica la gestione delle cose perché hai un choke point centrale piuttosto che duplicare le regole ovunque.

Ma nessuna cosa è necessariamente una soluzione finale. Una buona soluzione di sicurezza è generalmente multi-layer, in cui hai un firewall al confine, wrapper TCP sul dispositivo e probabilmente anche alcune regole sui router interni. In genere, è necessario proteggere la rete da Internet e proteggere i nodi l'uno dall'altro. Questo approccio multistrato non è come praticare un foro attraverso più fogli di compensato, è più come montare un paio di porte, quindi un intruso ha due serrature da rompere invece di una sola; questa è chiamata una trappola per l'uomo nella sicurezza fisica e la maggior parte di ogni edificio ne ha una per una ragione. :)

(Potresti voler leggere " Vita senza firewall ")

Ora: che dire di avere un sistema legacy per il quale non vengono più pubblicate patch? Che dire di non essere in grado di applicare le patch alle macchine N nel momento in cui è necessario, mentre allo stesso tempo è possibile applicarle in un minor numero di nodi nella rete (firewall)?

Non ha senso discutere l'esistenza o la necessità del firewall. Ciò che conta davvero è che devi implementare una politica di sicurezza. Per fare ciò utilizzerai tutti gli strumenti che lo implementeranno e ti aiuteranno a gestirlo, espanderlo ed evolverlo. Se i firewall sono necessari per farlo, va bene. Se non sono necessari, va bene lo stesso. Ciò che conta davvero è avere un'implementazione funzionante e verificabile della vostra politica di sicurezza.

La maggior parte delle tue spiegazioni sembrano confutare la necessità di un firewall, ma non vedo una truffa per averne uno, a parte il poco tempo a disposizione per installarne uno.

Poche cose sono una "necessità" nel senso stretto della parola. La sicurezza riguarda soprattutto l'impostazione di tutti i blocchi che puoi. Più lavoro è necessario per irrompere nel tuo server significa meno possibilità di un attacco riuscito. Volete rendere più efficace il rodaggio delle vostre macchine che da qualche altra parte. L'aggiunta di un firewall rende più lavoro.

Penso che un uso chiave sia la ridondanza nella sicurezza. Un altro vantaggio dei firewall è che puoi semplicemente abbandonare i tentativi di connessione a qualsiasi porta piuttosto che rispondere alle richieste respinte - questo renderà nmapping un po 'più scomodo per un attaccante.

La cosa più importante per me sulla nota pratica della tua domanda è che puoi bloccare SSH, ICMP e altri servizi interni su sottoreti locali, nonché limitare le connessioni in entrata per limitare gli attacchi DOS.

"Il punto di sicurezza non è difendersi dopo un attacco riuscito - che si è già dimostrato impossibile - è in primo luogo tenere fuori gli aggressori".

Non sono d'accordo. Limitare i danni può essere altrettanto importante. (in base a questo ideale perché le password hash? o attaccare il software del database su un server diverso rispetto alle applicazioni Web?) Penso che il vecchio detto "Non mettere tutte le uova nello stesso paniere" sia applicabile qui.

Should I firewall my server?Buona domanda. Sembrerebbe poco utile schiaffeggiare un firewall sopra uno stack di rete che rifiuta già i tentativi di connessione a tutti tranne che alle poche porte che sono legittimamente aperte. Se esiste una vulnerabilità nel sistema operativo che consente a pacchetti creati in modo pericoloso di interrompere / sfruttare un host, un firewall in esecuzione sullo stesso host impedirebbe l'exploit? Beh, forse ...

E questa è probabilmente la ragione più forte per eseguire un firewall su ogni host: un firewall potrebbe impedire lo sfruttamento di una vulnerabilità dello stack di rete. È una ragione abbastanza forte? Non lo so, ma suppongo che si possa dire "Nessuno è mai stato licenziato per aver installato un firewall".

Un altro motivo per eseguire un firewall su un server è disaccoppiare queste due preoccupazioni altrimenti fortemente correlate:

1. Da dove, e su quali porte, accetto le connessioni?
2. Quali servizi sono in esecuzione e in ascolto delle connessioni?

Senza un firewall, l'insieme di servizi in esecuzione (insieme alle configurazioni per tcpwrappers e simili) determina completamente l'insieme di porte che il server avrà aperto e da cui verranno accettate le connessioni. Un firewall basato su host offre all'amministratore ulteriore flessibilità per installare e testare nuovi servizi in modo controllato prima di renderli più ampiamente disponibili. Se tale flessibilità non è richiesta, allora ci sono meno motivi per installare un firewall su un server.

In una nota finale, c'è un elemento non menzionato nella tua lista di controllo di sicurezza che aggiungo sempre e che è un sistema di rilevamento delle intrusioni (HIDS) basato su host, come AIDE o samhain . Un buon HIDS rende estremamente difficile per un intruso apportare modifiche indesiderate al sistema e rimanere inosservato. Credo che tutti i server dovrebbero eseguire un tipo di HIDS.

Un firewall è uno strumento. Non rende le cose sicure in sé e per sé, ma può dare un contributo come strato in una rete sicura. Ciò non significa che tu ne abbia bisogno, e certamente mi preoccupo delle persone che dicono ciecamente "Devo ottenere un firewall" senza capire perché la pensano così e che non comprendono i punti di forza e di debolezza dei firewall.

Ci sono molti strumenti che possiamo dire che non abbiamo bisogno ... È possibile eseguire un computer Windows senza Antivirus? Sì lo è ... ma è un buon livello di assicurazione averne uno.

Direi lo stesso dei firewall: qualsiasi altra cosa tu possa dire su di loro, sono un buon livello di assicurazione. Non sostituiscono il patching, il blocco delle macchine, la disabilitazione dei servizi non utilizzati, la registrazione, ecc ... ma possono essere un utile supplemento.

Suggerirei anche che l'equazione cambi in qualche modo a seconda che tu stia parlando o meno di mettere un firewall di fronte a un gruppo di server attentamente curati, come sembri essere, o una tipica LAN con un mix di workstation e server , alcuni dei quali potrebbero eseguire alcune cose piuttosto pelose nonostante i migliori sforzi e desideri del team IT.

Un'altra cosa da considerare è il vantaggio di creare un obiettivo ovviamente indurito. Sicurezza visibile, che si tratti di luci brillanti, serrature pesanti e una scatola di allarme evidente su un edificio; o un firewall ovvio su una gamma di indirizzi IP aziendali può scoraggiare l'intruso occasionale: cercheranno prede più facili. Ciò non scoraggia l'intruso determinato che sa che hai le informazioni che desidera ed è determinato a ottenerle, ma vale comunque la pena dissuadere gli intrusi occasionali, soprattutto se sai che qualsiasi intruso le cui sonde persiste oltre il deterrente deve essere preso particolarmente sul serio .

Tutte grandi domande. MA - Sono molto sorpreso che PERFORMANCE non sia stato portato al tavolo.

Per i front-end Web molto utilizzati (per quanto riguarda la CPU), il firewall locale degrada davvero le prestazioni, il periodo. Prova un test di carico e vedi. L'ho visto un sacco di volte. La disattivazione del firewall ha migliorato le prestazioni (richiesta al secondo) del 70% o più.

Questo compromesso deve essere considerato.

Un firewall è una protezione aggiuntiva. Tre scenari particolari da cui protegge sono gli attacchi allo stack di rete (ovvero il sistema operativo del tuo server presenta una vulnerabilità su pacchetti appositamente predisposti che non raggiungono mai il livello di porte), un'intrusione riuscita che effettua una connessione a "telefono di casa" (o invia spam, o altro ) o un'intrusione riuscita che apre una porta del server o, meno rilevabile, cerca una sequenza di bussare alla porta prima di aprire una porta. Certo, gli ultimi due hanno a che fare con la mitigazione del danno di un'intrusione piuttosto che prevenirla, ma ciò non significa che sia inutile. Ricorda che la sicurezza non è una proposta del tutto o niente; uno ha un approccio stratificato, cintura e bretelle, per raggiungere un livello di sicurezza sufficiente per le tue esigenze.

Non sono affatto un esperto di sicurezza, ma sembra che tu sia protetto da firewall. Sembra che tu abbia preso alcune delle funzionalità principali di un firewall e le abbia rese parte delle tue politiche e procedure. No, non è necessario un firewall se si intende eseguire lo stesso lavoro di un firewall. Per quanto mi riguarda, preferirei fare del mio meglio per mantenere la sicurezza, ma ho un firewall che mi guarda alle spalle, ma a un certo punto quando puoi fare tutto ciò che fa il firewall, inizia a diventare irrilevante.

Un firewall non è certamente necessario per configurazioni più piccole. Se si dispone di uno o due server, i firewall software sono gestibili. Detto questo, non corriamo senza firewall dedicati e ci sono alcuni motivi per cui mantengo questa filosofia:

Separazione dei ruoli

I server sono per applicazioni. I firewall sono per l'ispezione dei pacchetti, il filtro e le politiche. Un web server dovrebbe preoccuparsi di servire le pagine web, e basta. Mettere entrambi i ruoli in un dispositivo è come chiedere al tuo commercialista di essere anche la tua guardia di sicurezza.

Il software è un bersaglio mobile

Il software sull'host è in continua evoluzione. Le applicazioni possono creare le proprie eccezioni del firewall. Il sistema operativo è aggiornato e patchato. I server sono un'area "admin" ad alto traffico e le politiche del firewall / politiche di sicurezza sono spesso molto più importanti per la sicurezza rispetto alle configurazioni dell'applicazione. In un ambiente Windows, supponiamo che qualcuno commetta un errore a livello di Criteri di gruppo e spenga Windows Firewall sui PC desktop e non si renda conto che verrà applicato ai server. Sei aperto in una questione di clic.

Parlando solo di aggiornamenti, gli aggiornamenti del firmware del firewall vengono generalmente pubblicati una o due volte l'anno, mentre gli aggiornamenti del sistema operativo e dei servizi sono un flusso costante.

Servizi / politiche / regole riutilizzabili, gestibilità

Se ho impostato un servizio / criterio chiamato "Web Server" una volta (ad esempio TCP 80 e TCP 443) e lo applico al "gruppo di server Web" a livello di firewall, sarebbe molto più efficiente (un paio di modifiche alla configurazione) e esponenzialmente meno soggetto a errori umani rispetto alla configurazione di servizi firewall su 10 box e all'apertura di 2 porte x 10 volte. Quando tale politica deve cambiare, è 1 cambio contro 10.

Posso ancora gestire un firewall durante un attacco o dopo un compromesso

Supponiamo che il mio firewall + server applicazioni basato su host venga attaccato e che la CPU sia fuori scala. Per persino iniziare a capire cosa sta succedendo, sono in balia del mio carico di essere meno dell'attaccante di persino entrare e guardarlo.

Un'esperienza reale: una volta ho incasinato una regola del firewall (lasciato le porte a QUALSIASI invece di una specifica e il server aveva un servizio vulnerabile) e l'attaccante aveva effettivamente una sessione di Desktop remoto in diretta sulla scatola. Ogni volta che iniziavo a ricevere una sessione, l'attaccante uccideva / disconnetteva la mia sessione. Se non fosse stato per poter bloccare quell'attacco da un dispositivo firewall indipendente, sarebbe potuto andare molto peggio.

Monitoraggio indipendente

La registrazione in unità firewall dedicate è in genere molto superiore ai firewall software basati su host. Alcuni sono abbastanza buoni da non aver nemmeno bisogno di un software di monitoraggio SNMP / NetFlow esterno per ottenere un'immagine precisa.

Conservazione IPv4

Non c'è motivo di avere due indirizzi IP se uno è per il web e uno per la posta. Conservare i servizi su scatole separate e instradare le porte in modo appropriato tramite il dispositivo progettato per farlo.

Blockquote Bene, hai ragione, non ho messo alcun contro. Contro: maggiore complessità della rete, singolo punto di errore, singola interfaccia di rete attraverso la quale viene strozzata la larghezza di banda. Allo stesso modo, gli errori amministrativi commessi su un firewall possono uccidere l'intera rete. E gli dei vietano di chiuderti fuori nel frattempo, quando è un viaggio di 20 minuti nella sala server.

Innanzitutto, l'aggiunta di un ulteriore hop indirizzato attraverso la rete non è complessa. In secondo luogo, nessuna soluzione firewall implementata con un singolo punto di errore è completamente inutile. Proprio come il clustering di server o servizi importanti e l'utilizzo di schede di rete collegate, si implementano firewall a disponibilità elevata. Non farlo, o non riconoscere e sapere che lo faresti è molto miope. Il semplice fatto di affermare che esiste un'unica interfaccia non rende automaticamente qualcosa un collo di bottiglia. Questa affermazione mostra che non hai idea di come pianificare e distribuire correttamente un firewall dimensionato per gestire il traffico che fluirebbe attraverso la tua rete. Hai ragione nel dire che un errore nella politica può causare danni a tutta la tua rete, ma direi che il mantenimento di singole politiche su tutti i tuoi server è molto più incline all'errore di un singolo posto.

Per quanto riguarda l'argomento che stai al passo con le patch di sicurezza e segui le guide di sicurezza; questa è una discussione traballante nella migliore delle ipotesi. In genere le patch di sicurezza non sono disponibili fino a quando non viene rilevata una vulnerabilità. Ciò significa che per tutto il tempo in cui esegui server indirizzabili pubblicamente sono vulnerabili fino a quando non vengono patchati. Come altri hanno sottolineato, i sistemi IPS possono aiutare a prevenire compromessi da tali vulnerabilità.

Se pensi che i tuoi sistemi siano il più sicuri possibile, è una buona sicurezza avere. Tuttavia, ti consiglierei di eseguire un controllo di sicurezza professionale sulla tua rete. Potrebbe solo aprire gli occhi.

In generale, la sicurezza è una cosa fondamentale, come già accennato. Ci sono ragioni per cui esistono firewall e non sono solo gli altri lemming ad essere stupidi idioti.

Questa risposta arriva, poiché la ricerca di "fail2ban" in questa pagina non mi ha dato alcun risultato. Quindi, se raddoppio altri contenuti, abbi pazienza. E mi scusi, se ho un po 'di rabbia, fornisco un'esperienza semplice in quanto ciò potrebbe tornare utile per gli altri. :)

Considerazioni sulla rete, locale o esterna

Questo è piuttosto specifico per Linux e si concentra sul firewall basato su host, che di solito è il caso d'uso. Il firewall esterno va di pari passo con un'adeguata struttura di rete e altre considerazioni sulla sicurezza di solito vanno in quella direzione. O sai cosa è implicito qui, quindi probabilmente non avrai bisogno di questo post. Oppure no, quindi continua a leggere.

L'esecuzione di firewall esternamente e localmente può sembrare un lavoro controintuitivo e doppio. Ma questo dà anche la possibilità di cambiare le regole su quello esterno, senza compromettere la sicurezza di tutti gli altri host. La necessità potrebbe derivare da motivi di debug o perché qualcuno ha appena fatto una cazzata. Un altro caso d'uso arriverà nella sezione "Firewall globale adattivo", per il quale occorreranno anche firewall sia globali che locali.

Costo e disponibilità e la stessa storia per tutto il tempo:

Il firewall è solo un aspetto di un sistema sicuro adeguato. Non installare un firewall in quanto "costa" denaro, introduce uno SPOF o qualunque altra cosa sia una cazzata, scusate il mio francese qui. Basta impostare un cluster. Oh, ma cosa succede se la cella di fuoco ha un'interruzione? Quindi impostare il cluster su due o più compartimenti antincendio.

Ma cosa succede se l'intero datacenter non è raggiungibile, poiché entrambi i vettori esterni sono fuori servizio (l'escavatore ha ucciso la tua fibra)? Quindi, fai in modo che il tuo cluster si estenda su più datacenter.

È caro? I cluster sono troppo complessi? Bene, la paranoia deve essere pagata.

Solo lamentarsi degli SPOF, ma non voler pagare più soldi o creare configurazioni un po 'più complesse è un chiaro caso di doppi standard o solo un piccolo portafoglio sul lato dell'azienda o del cliente.

Questo modello si applica a TUTTE queste discussioni, indipendentemente dal servizio che è al momento attuale. Non importa se si tratta di un gateway VPN, un Cisco ASA utilizzato solo per il firewall, un database MySQL o PostgreSQL, un sistema virtuale o hardware del server, un back-end di archiviazione, switch / router, ...

Ormai dovresti avere l'idea.

Perché preoccuparsi del firewall?

In teoria il tuo ragionamento è valido. (È possibile sfruttare solo i servizi in esecuzione.)

Ma questa è solo metà della verità. Il firewall, in particolare il firewall stateful, può fare molto di più per te. I firewall senza stato sono importanti solo se si verificano problemi di prestazioni come altri già menzionati.

Controllo degli accessi semplice, centrale e discreto

Hai citato i wrapper TCP che implementano sostanzialmente le stesse funzionalità per proteggere il tuo. Per il bene dell'argomento, supponiamo che qualcuno non lo sappia tcpde gli piaccia usare il mouse? fwbuilderpotrebbe venire in mente.

Avere pieno accesso dalla rete di gestione è qualcosa che avresti dovuto abilitare, che è qualcosa dei primi casi d'uso del firewall basato su host.

Che ne dite di una configurazione multi-server, in cui il database viene eseguito altrove e non è possibile inserire entrambi / tutti i computer in una sottorete condivisa (privata) per qualsiasi motivo? Utilizzare il firewall per consentire l'accesso MySQL sulla porta 3306 solo per il singolo indirizzo IP fornito dell'altro server, fatto, semplice.

E questo funziona perfettamente anche per UDP. O qualunque protocollo. I firewall possono essere così dannatamente flessibili. ;)

Mitigazione di Portscan

Inoltre, con il firewall, è possibile rilevare e mitigare i portcan generali in quanto la quantità di connessioni per periodo di tempo può essere monitorata tramite il kernel e il suo stack di rete e il firewall può agire su questo.

Inoltre, i pacchetti non validi o oscuri possono essere gestiti prima che raggiungano l'applicazione.

Limitazione del traffico in uscita

Filtrare il traffico in uscita è di solito un dolore nel culo. Ma può essere un must, a seconda del contratto.

statistica

Un'altra cosa che un firewall può darti è la statistica. (Pensa watch -n1 -d iptables -vnxL INPUTdi aver aggiunto alcune regole per gli indirizzi IP speciali proprio in alto per vedere se i pacchetti stanno arrivando.)

Puoi vedere alla luce del giorno se le cose funzionano o no. Il che è MOLTO utile quando si risolvono i problemi di connessione e si è in grado di dire all'altra persona al telefono che non si ricevono pacchetti, senza ricorrere a chat tcpdump. Il networking è divertente, la maggior parte delle persone ora sa cosa sta facendo e tutto ciò a volte si tratta solo di semplici errori di routing. Diavolo, anche io non so sempre cosa sto facendo. Anche se ho lavorato con dozzine di sistemi ed elettrodomestici complessi, spesso anche con tunneling ormai.

IDS / IPS

Il firewalling Layer7 è di solito olio di serpente (IPS / IDS), se non viene seguito correttamente e aggiornato regolarmente. Inoltre le licenze sono dannatamente costose, quindi risparmierò a prenderne una se non avessi davvero bisogno di ottenere tutto ciò che il denaro può comprarti.

Masqerading

Facile, prova questo con i tuoi wrapper. : D

Port forwarding locale

Vedi il travestimento.

Protezione dei canali di accesso con password con indirizzi IP dinamici

Che dire se i clienti hanno indirizzi IP dinamici e non è stata distribuita una configurazione VPN? O altri approcci dinamici al firewalling? Questo è già accennato alla domanda, e qui arriverà un caso d'uso per Sfortunatamente, non riesco a trovare alcun firewall che lo faccia. parte.

È necessario aver disabilitato l'accesso all'account root tramite una password. Anche se l'accesso è limitato a determinati indirizzi IP.

Inoltre, avere ancora un altro account blanko pronto con un accesso con password se le chiavi ssh vengono perse o la distribuzione fallisce è molto utile se qualcosa va davvero storto (un utente ha accesso amministrativo alla macchina e "cose ​​accadute"?). È la stessa idea per l'accesso alla rete in quanto ha modalità single-user su Linux o utilizza init=/bin/bashvia grubper l'accesso locale davvero male e non può usare un disco live per qualsiasi motivo. Non ridere, ci sono prodotti di virtualizzazione che lo vietano. Anche se la funzionalità esiste, cosa succede se una versione software obsoleta viene eseguita priva della funzionalità?

Ad ogni modo, anche se esegui il tuo demone ssh su una porta esoterica e non su 22, se non hai implementato cose come il port knocking (per aprire anche un'altra porta e mitigare così i portcan, al limite lentamente di essere troppo poco pratico), le scansioni delle porte rileveranno il tuo servizio alla fine.

Di solito si configurano anche tutti i server con la stessa configurazione, con le stesse porte e servizi per motivi di efficienza. Non è possibile impostare ssh su una porta diversa su ogni macchina. Inoltre, non è possibile modificarlo su tutte le macchine ogni volta che lo si considera un'informazione "pubblica", perché è già dopo una scansione. La questione di nmapessere legali o meno non è un problema quando si dispone di una connessione Wi-Fi compromessa.

Se questo account non è denominato "root", le persone potrebbero non essere in grado di indovinare il nome dell'account utente della "backdoor". Ma lo sapranno, se ottengono un altro server dalla tua azienda, o semplicemente acquistano un po 'di spazio web e hanno uno sguardo senza root / senza jail / senza contenuto /etc/passwd.

Per un'illustrazione puramente teorica ora, potrebbero utilizzare un sito Web hackerabile lì per ottenere l'accesso al tuo server e cercare come le cose di solito vengono eseguite al tuo posto. I tuoi strumenti di ricerca per hacker potrebbero non funzionare 24 ore su 24, 7 giorni su 7 (di solito lo fanno di notte per motivi di prestazioni del disco per le scansioni del filesystem?) E i tuoi antivirus non vengono aggiornati nel secondo in cui un nuovo zero-day vede la luce del giorno, quindi lo farà non rilevare questi eventi in una volta, e senza altre misure di protezione potresti non sapere nemmeno cosa è successo. Per tornare alla realtà, se qualcuno ha accesso a exploit zero-day, è molto probabile che non prenderà di mira i tuoi server in quanto questi sono solo costosi. Questo è solo per illustrare che c'è sempre un modo per entrare in un sistema in caso di "necessità".

Ma di nuovo sull'argomento, non usare un account con password extra e non preoccuparti? Per favore, continua a leggere.

Anche se gli aggressori ottengono il nome e la porta di questo account aggiuntivo, una combinazione fail2ban+ iptablesli interromperà, anche se hai utilizzato solo una password di otto lettere. Inoltre fail2ban può essere implementato anche per altri servizi, ampliando l'orizzonte di monitoraggio!

Per i tuoi servizi, se mai se ne presentasse la necessità: praticamente tutti i servizi che registrano errori su un file possono ottenere supporto fail2ban fornendo un file, quale regex corrispondere e quanti errori sono consentiti e il firewall vieterà felicemente ogni indirizzo IP viene detto a.

Non sto dicendo di usare password a 8 cifre! Ma se vengono banditi per 24 ore per cinque tentativi di password errati, puoi indovinare per quanto tempo dovranno provare se non hanno una botnet a disposizione anche con una sicurezza così scadente. E rimarrai stupito dalle password che i clienti tendono a usare, non solo per ssh. Dando un'occhiata alle password di posta delle persone tramite Plesk ti dice tutto ciò che preferiresti non voler sapere, se mai lo facessi, ma cosa non sto cercando di implicare qui, ovviamente. :)

Firewall globale adattivo

fail2banè solo un'applicazione che usa qualcosa del genere iptables -I <chain_name> 1 -s <IP> -j DROP, ma puoi facilmente creare queste cose da solo con un po 'di magia Bash abbastanza velocemente.

Per espandere ulteriormente qualcosa del genere, aggregare tutti gli indirizzi IP fail2ban dai server all'interno della rete su un server aggiuntivo, che cura tutti gli elenchi e li passa a sua volta ai firewall principali bloccando tutto il traffico già ai margini della rete.

Tale funzionalità non può essere venduta (certo che può, ma sarà solo un sistema fragile e succherà), ma deve essere intrecciata nella tua infrastruttura.

Mentre ci sei, puoi anche usare gli indirizzi IP della blacklist o gli elenchi da altre fonti, sia che tu sia aggregato da te stesso o da quelli esterni.

Nel mondo fisico, le persone si assicurano oggetti di valore mettendoli in cassaforte. Ma non c'è sicurezza in cui non si possa entrare. Le cassette di sicurezza o contenitori di sicurezza sono classificate in base al tempo impiegato per forzare l'ingresso. Lo scopo della cassaforte è ritardare l'attaccante abbastanza a lungo da essere rilevato e le misure attive quindi fermare l'attacco.

Allo stesso modo, il presupposto di sicurezza appropriato è che le macchine esposte verranno eventualmente compromesse. I firewall e gli host bastion non sono configurati per impedire al server (con i tuoi dati preziosi) di compromettersi, ma per forzare un attaccante a comprometterli prima e consentire di rilevare (e scoraggiare) l'attacco prima che gli oggetti di valore vadano persi.

Si noti che né i firewall né i depositi bancari proteggono dalle minacce interne. Questo è uno dei motivi per cui i contabili bancari si concedono due settimane di ferie consecutivamente e per i server di avere precauzioni di sicurezza interne complete anche se protette dagli host bastion.

Sembrerebbe implicare nel post originale che stai inoltrando pacchetti "fuori dal mondo" attraverso il tuo firewall direttamente al tuo server. In tal caso, sì, il tuo firewall non sta facendo molto. Una migliore difesa perimetrale viene eseguita con due firewall e un host bastione, dove non esiste una connessione logica diretta dall'esterno all'interno: ogni connessione termina nell'host del bastione DMZ; ogni pacchetto viene esaminato in modo appropriato (ed eventualmente analizzato) prima dell'inoltro.

Le vulnerabilità sono difficili da prevedere. È praticamente impossibile prevedere in che modo verrà sfruttata la tua infrastruttura. Avere un firewall "alza il tiro" per un utente malintenzionato che desidera sfruttare una vulnerabilità, e questa è la parte importante, PRIMA di sapere cos'è quella vulnerabilità. Inoltre, le ramificazioni del firewall possono essere facilmente comprese in anticipo, quindi è improbabile che CAUSE si verifichino problemi con un firewall più gravi di quelli che è probabile che si evitino.

Ecco perché "nessuno è mai stato licenziato per l'installazione di un firewall". La loro implementazione ha un rischio molto basso e ha un'alta probabilità di prevenire o mitigare un exploit. Inoltre, le vulnerabilità più brutte finiscono per essere sfruttate dall'automazione, quindi qualsiasi cosa "insolita" finirà per rompere un bot, o almeno farlo saltare per favorire un obiettivo più semplice.

Nota a margine; i firewall non sono solo per Internet. Il tuo ufficio contabilità. non ha bisogno di ssh / qualunque cosa al tuo server ldap, quindi non darlo a loro. La compartimentazione dei servizi interni può fare una grande differenza per il lavoro di pulizia nel caso in cui qualcosa rompa le mura del castello.

Devo dire a Ernie che mentre sembri fare molto per rafforzare i tuoi server e mitigare attacchi e vulnerabilità, non sono d'accordo con la tua posizione sui firewall.

Tratto la sicurezza un po 'come una cipolla in quanto idealmente hai livelli che devi superare prima di arrivare al nocciolo, e personalmente penso che sia gravemente fuorviato non avere qualche forma di firewall hardware sul tuo perimetro di rete.

Devo ammettere che sto arrivando da questo punto di vista "quello a cui sono abituato", ma so che ogni singolo mese ricevo un piccolo elenco di patch di quei mesi da Microsoft, molte delle quali sfruttate in natura . Immagino che lo stesso accada per quasi tutti i sistemi operativi e le serie di applicazioni che ti interessano.

Ora non sto suggerendo che i firewall lo eliminino, né i firewall sono immuni da bug / vulnerabilità, ovviamente un firewall "hardware" è solo un software in esecuzione su uno stack hardware.

Detto questo, dormo molto più sicuro sapendo che se ho un server che necessita solo della porta 443 per essere accessibile dal web, il mio perimetro Juniper assicura che solo la porta 443 sia accessibile dal web. Non solo, ma il mio Palo Alto assicura che il traffico in arrivo sia decrittografato, ispezionato, registrato e sottoposto a scansione per IPS / IDS, non che elimini la necessità di mantenere i server sicuri e aggiornati, ma perché NON dovresti trovare un vantaggio dato che può mitigare gli exploit zero-day e il buon vecchio errore umano?

Prima di tutto, dai tuoi discorsi sul port forwarding, penso che stai fondendo il firewalling con NATing. Mentre oggigiorno i NAT spesso funzionano come firewall di fatto, non è lo scopo per cui sono stati progettati. NAT è uno strumento di routing. I firewall servono per regolare l'accesso. È importante per chiarezza di pensiero mantenere distinti questi concetti.

È ovviamente vero che mettere un server dietro una NAT box e quindi configurare il NAT per inoltrare qualsiasi cosa a quel server, non è più sicuro che mettere il server direttamente su Internet. Non credo che qualcuno avrebbe discusso con questo.

Allo stesso modo, un firewall configurato per consentire tutto il traffico non è affatto un firewall.

Ma "consentire tutto il traffico" è davvero la politica che desideri? Qualcuno ha mai bisogno di inviare a qualcuno dei tuoi server un indirizzo IP russo? Mentre stai armeggiando con la configurazione di un nuovo demone di rete sperimentale, il mondo intero ha davvero bisogno di accedervi?

Il potere di un firewall è che ti consente di mantenere aperti solo quei servizi che conosci devono essere aperti e mantenere un unico punto di controllo per l'implementazione di questo criterio.

I firewall di ispezione dei pacchetti con stato NON appartengono ai server pubblici. Stai accettando tutte le connessioni, quindi il monitoraggio dello stato è piuttosto inutile. I firewall tradizionali sono una grande responsabilità negli attacchi DDoS e in genere sono la prima cosa a fallire sotto l'attacco DDoS, anche prima che la larghezza di banda del collegamento o le risorse del server vengano completamente consumate.

I filtri di pacchetti senza stato sui router hanno senso davanti ai server pubblici, ma solo se sono in grado di gestire la velocità di linea di tutto il traffico in ingresso e in uscita (come un ACL hardware in un router).

Google, Facebook e persino Microsoft non mettono i tradizionali "firewall" davanti ai server pubblici. Chiunque abbia eseguito servizi web pubblici su scala "più di un server" dovrebbe saperlo.

Altre funzioni presenti nei firewall tradizionali come Cisco ASA o qualsiasi altra cosa siano meglio implementate sugli host stessi, dove possono essere ridimensionate in modo efficace. Registrazione, IDS, ecc. Sono comunque tutte le funzionalità software nei firewall, quindi diventano solo un enorme collo di bottiglia e target DDoS se messi di fronte a server accessibili al pubblico.

Perché tutti i tuoi server hanno bisogno di un indirizzo pubblico?

Installa il server nella stanza del server e assegnagli un indirizzo IP pubblico.

Su circa 14 server che eseguo regolarmente, solo 2 hanno interfacce accessibili al pubblico.

Modificato per aggiungere : in altre reti che ho avuto una mano nella gestione, abbiamo avuto la possibilità di attivare / disattivare i servizi a piacimento, mentre non avevamo accesso per gestire il firewall. Non posso nemmeno iniziare a dirti quante volte, inavvertitamente ovviamente, un servizio non necessario (SMTP) è stato attivato e lasciato attivo e l'unica cosa che ci ha salvato dal diventare una discarica di spam e essere inserito nella lista nera nel processo, è stato un firewall.

Inoltre, tutto il traffico che passa tra i server è completamente crittografato?

Puoi certamente guidare una macchina a 100 mph senza cinture di sicurezza, senza airbag e pneumatici calvi, ma perché dovresti ??

I firewall possono impedire agli utenti del sistema di aprire servizi accessibili in rete di cui gli amministratori non sono a conoscenza o di eseguire il port forwarding verso altre macchine. Utilizzando il modulo hashlimit, i firewall possono anche limitare la velocità degli utenti in base all'IP remoto.

Un firewall è un'altra rete di sicurezza che garantisce il rispetto delle politiche. Certo, non eseguire servizi che non ti aspetti.

Consiglio vivamente che gli aggiornamenti software vengano applicati in modo tempestivo, ad esempio, ma consiglio anche i firewall su tutte le macchine. È come quando guido: cerco di evitare ostacoli e altre macchine, ma indosso anche una cintura di sicurezza e ho airbag nel caso in cui si verifichi l'inaspettato.

Potresti non renderti conto di quanto stai beneficiando dei firewall semplicemente perché tutti gli altri li stanno usando. In un giorno in cui letteralmente tutti, fino agli utenti DSL di casa hanno installato dei firewall, l'annusamento delle porte è stato praticamente abbandonato come un vettore di attacco fattibile. Un hacker decente non sta per perdere tempo a cercare tali cose.