strumenti di gestione di iptables per ambienti su larga scala


15

L'ambiente in cui opero è un'operazione di web hosting su larga scala (diverse centinaia di server gestiti, indirizzamento quasi pubblico, ecc. Quindi è improbabile che tutto ciò che parla della gestione dei collegamenti ADSL funzioni bene), e noi " stai cercando qualcosa che possa essere comodo per gestire sia il set di regole di base (circa 12.000 voci in iptables al conteggio corrente) sia i set di regole basati su host che gestiamo per i clienti. Il nostro set di regole del router principale cambia alcune volte al giorno e i set di regole basati sull'host cambiano forse 50 volte al mese (su tutti i server, quindi forse una modifica ogni cinque server al mese).

Attualmente stiamo usando filtergen (che è in genere palle e super-palle alla nostra scala di operazioni), e in passato ho usato shorewall in altri lavori (che sarebbe preferibile a filtergen, ma immagino che ci debba essere essere qualcosa là fuori che è meglio di così).

I "mosti" che abbiamo creato per qualsiasi sistema di sostituzione sono:

  • Deve generare un set di regole abbastanza rapidamente (una corsa filtergen sul nostro set di regole richiede 15-20 minuti; questo è semplicemente folle) - questo è legato al punto successivo:
  • È necessario generare un file di stile iptables-restore e caricarlo in un colpo solo, non chiamare iptables per ogni inserimento di regole
  • Non è necessario disattivare il firewall per un periodo prolungato durante il ricaricamento del set di regole (di nuovo, questa è una conseguenza del punto precedente)
  • Deve supportare IPv6 (non stiamo implementando nulla di nuovo che non sia compatibile con IPv6)
  • Deve essere privo di DFSG
  • È necessario utilizzare file di configurazione in testo normale (poiché eseguiamo tutto attraverso il controllo di revisione e l'utilizzo degli strumenti di manipolazione del testo Unix standard è il nostro SOP)
  • Deve supportare sia RedHat che Debian (pacchetto preferito, ma almeno non deve essere apertamente ostile agli standard di entrambe le distribuzioni)
  • Deve supportare la capacità di eseguire comandi iptables arbitrari per supportare funzionalità che non fanno parte della "lingua madre" del sistema

Tutto ciò che non soddisfa tutti questi criteri non verrà preso in considerazione. I seguenti sono i nostri "simpatici":

  • Dovrebbe supportare i "frammenti" di file di configurazione (vale a dire, è possibile eliminare un mucchio di file in una directory e dire al firewall "includere tutto in questa directory nel set di regole"; usiamo ampiamente la gestione della configurazione e vorremmo usare questa funzione per fornire automaticamente regole specifiche del servizio)
  • Dovrebbe supportare tabelle non elaborate
  • Dovrebbe consentire all'utente di specificare ICMP particolari sia nei pacchetti in arrivo che nelle regole REJECT
  • Dovrebbe supportare con grazia i nomi host che si risolvono in più di un indirizzo IP (siamo stati catturati da questo un paio di volte con filtergen; è un dolore piuttosto reale nel culo)
  • Più caratteristiche iptable opzionali / bizzarre sono supportate dallo strumento (nativamente o tramite plugin esistenti o facilmente scrivibili), meglio è. Di tanto in tanto usiamo strane funzionalità di iptables, e più di quelle che "funzionano", meglio è per tutti.

Mi mordo-- cosa significano i termini "palline" e "super palline" nel tuo post? Immagino che tu non stia parlando di sfere di gomma gonfiabili, ma non posso dedurre se il contesto significhi "buono" o "cattivo".
Evan Anderson,

palle == cattivo. Super palline == extra male.
womble

Con così tante regole, assicurati di avere una regola ACCEPT in alto che accetti connessioni stabilite e correlate. I PC non hanno un TCAM e che molte regole influenzano le prestazioni. Un sacco.
Thomas,

@thomas: Sì, c'è una certa quantità di ottimizzazione che va nel set di regole. Avere quella "conoscenza" sull'ottimizzazione in qualunque strumento firewall sia scelto sarebbe ovviamente un bonus.
womble

Risposte:


4

Se forse vuoi passare da un approccio guidato dalle regole a un modo di "descrivere lo stato finale richiesto" di fare le cose, dai un'occhiata a fwbuilder.

Professionisti:

  • sono supportati più firewall - le tue regole core + basate su host - da 1 set di oggetti
  • SQL-esque approccio "dimmi quello che vuoi" piuttosto che "dimmi come farlo" (NB non sto dicendo che ci sia qualche SQL lì dentro! Solo che è descrittivo Vs procedurale :-)
  • È una GUI, un po 'come l'hardware commerciale per le interfacce dei fornitori, quindi è possibile spingere alcune attività verso il basso nello stack di dipendenti / competenze
  • supporta la maggior parte dell'utilizzo "strano" che ho provato
  • può generare regole per una varietà di implementazioni a / i - BSD / cicso / iptables / etc
  • separa il front-end dal compilatore di regole, il che mi fa sperare che la velocità sia una preoccupazione per gli autori. NB Non ho nulla vicino alla scala a cui alludi
  • Il formato del file non è binario
  • fa IPv6
  • Crea una configurazione di stile iptables-save per caricamento atomico e veloce

Contro:

  • È una GUI
  • È improbabile che lo spostamento del set di regole esistente sia indolore
  • Mentre GPL e in Debian, i client Windows + OSX sono valutati per 30 giorni, dato che nessuno ha ancora compilato una versione gratuita per quei sistemi operativi; quindi il braccio commerciale degli sviluppatori ha il monopolio di quei binari
  • Il formato del file è tecnicamente XML; NB non lasciarti scoraggiare: dai un'occhiata agli strumenti che forniscono (puoi usare il binario gui per manipolarlo tramite la CLI per esempio), gli strumenti XML della CLI che già esistono, e ricorda che - al tuo scala - alcune sembianze di metadati + struttura non sono un / cattivo / cosa! Differisce abbastanza bene tra le modifiche, IIRC.

Link: http://www.fwbuilder.org


Hrm ... darò un'occhiata. L'esistenza di una GUI (per non parlare dell'XML) mi fa contrarre piuttosto violentemente, ma tu sollevi alcune idee interessanti (singolo set di regole per l'intera infrastruttura). La cosa di OS X non sarà un problema.
Womble

Sono d'accordo, una GUI mi ha reso WTF in origine, ma sono stato contento anche di quello che ho visto dal lato CLI. Quanto è dinamica la tua configurazione, comunque? Sarebbero 10 cambi al giorno o 10 cambi all'anno? Questo potrebbe essere un fattore utile per i dettagli qui. Inoltre, una buona funzione del formato di file XML potrebbe essere che, utilizzando strumenti compatibili con XML, potresti avere l'intera configurazione in un file, usando oggetti a definizione singola, ma produrre un log delle modifiche specifico al nodo per documentare le configurazioni e i changeset dei singoli server . Solo un pensiero ...
Jonathan Matthews il

@Jonathan: hai ragione, il dinamismo del set di regole è importante da sapere. Ho modificato la domanda; sono alcune volte al giorno quasi tutti i giorni lavorativi per il set di regole di base.
womble

3

scrivi il tuo. seriamente - su questa scala è ragionevole.

usa ipset e / o molti tavoli / tabelle secondarie iptable. quando possibile ricaricare solo alcuni sottotitoli / alcuni set di ipset - questo accelererà la riconfigurazione.

probabilmente lo hai già fatto, ma vale comunque la pena menzionare: utilizzare le tabelle nidificate per ridurre il carico sul router e il numero medio di ricerche necessarie per i pacchetti che creano nuove connessioni. ovviamente -A AVANTI -m state --state STABILITO, CORRELATO è la tua regola più alta.


"Scrivi il nostro" non è fuori dal comune, ma è ciò che ci ha portato Filtergen in primo luogo - è stato scritto da un ex-dipendente. Preferiremmo non produrre ancora un altro strumento di gestione del firewall, se possibile.
womble

IPSET è velocissimo per grandi set di regole. "memorizzare più indirizzi IP o numeri di porta e confrontarli con la raccolta da parte di iptables in un colpo solo; aggiornare dinamicamente le regole di iptables contro indirizzi o porte IP senza penalità di prestazione; esprimere indirizzi IP complessi e set di regole basati su porte con una sola regola di iptables e beneficiare della velocità di set IP "Lo uso con shorewall. Non ho idea di come si comporterebbe la riva alla tua scala.
artifex,

2

palle sante (mantenendo vivo il tema!) amico ... 12.000 regole fondamentali?

Suppongo che tu abbia preso in considerazione tutte le opzioni facili come semplicemente far cadere i set in CVS? Puppet o CFengine?

Onestamente, dall'ampia panoramica che hai fornito, ti consiglio vivamente di rivalutare il design della tua rete. Probabilmente sono un po 'troppo semplicistico, ma semplicemente non riesco a capire un progetto che richiederebbe regole 12k iptables. Sembra davvero qualcosa che trarrebbe beneficio da una soluzione di tipo SLB piuttosto che un modo migliore per gestire le regole del firewall.

In una nota a margine, come si fa ad aggiungere un commento rispetto ad aggiungere una "risposta"?


È necessario un minimo di reputazione per commentare. Quando lo fai apparirà un link.
jay_dubya,

Probabilmente c'è una certa ridondanza nelle nostre regole di iptables, ma questa è in gran parte una funzione di filtergen forse non essere il più efficiente possibile. Abbiamo un / 19 di spazio IP, tuttavia, e VLAN per cliente e una "politica di default" piuttosto restrittiva (che richiede eccezioni per IP per aprire le porte come richiesto dai clienti). Certamente non saremo in grado di sbarazzarci di più di alcune di quelle regole. Oh, e sì, usiamo già Puppet e non stiamo per iniziare a scrivere set di regole a mano nella nostra scala di operazioni.
Womble

bene, tu certamente mantieni uno spazio IP più grande di me, ma trovo ancora difficile giustificare in qualche modo che molte regole. Hai mai pensato di suddividerli in una struttura ad albero in cui potresti utilizzare le impostazioni fall-thru di regole nei chokepoints? vale a dire, tutti i server solo web nella sottorete X, tutti i server web + smtp nella sottorete Y? Non dovresti effettivamente sottorizzarli, raggrupparli logicamente dietro un firewall a più livelli ... scusa se sto solo aggiungendo rumore a questo punto ... Potrei semplicemente non essere abbastanza sofisticato per questo. Mi piacciono le mie regole del firewall brevi e brutali =)
Greeblesnort il

Non siamo davvero in grado di "sistemare" le cose in quel modo; siamo in gran parte un fornitore di hosting di server dedicato, quindi ciò che i nostri clienti decidono di fare con le loro macchine di giorno in giorno potrebbe cambiare, richiedendo molta più danza in giro che se stessimo solo facendo un'infrastruttura dedicata per un servizio interno.
womble

0

12000 regole? sei pazzo? Non si verificano problemi di prestazioni con questa quantità di filtri in corso? Non riesco a capire perché avresti bisogno di 12.000 regole? Come si verifica che il proprio set di regole stia effettivamente applicando la politica?

Qual è la politica?

Come testate la vostra politica?

12.000 regole probabilmente infrangono ogni regola di sicurezza nel libro.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.