Limitazione effettiva del traffico del firewall in uscita verso IP che cambiano frequentemente

Question

Limitazione effettiva del traffico del firewall in uscita verso IP che cambiano frequentemente

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

4

Gli stati di PCI DSS 1.2.1:

Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.

Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit "deny all" or an implicit deny after allow statement

I server nella nostra DMZ devono effettuare chiamate in uscita verso un numero di servizi esterni (principalmente tramite le API HTTPS). La maggior parte di questi servizi ha le proprie impostazioni di disponibilità elevata con record DNS TTL bassi e può aggiungere o modificare gli indirizzi IP in qualsiasi momento.

Quindi non sembra possibile limitare il traffico in uscita sul nostro firewall in base all'indirizzo IP, perché le regole sarebbero costantemente superate e un incubo da amministratore.

Ho visto che alcuni firewall supportano regole basate su FQDN, il che sembra che possa risolvere il problema, ma sfortunatamente né il nostro ISP né altri che ho visto (Rackspace, AWS, ecc.) supportano il firewall basato su FQDN regole. Preferiremmo non dover spostare i provider di hosting.

Un'altra soluzione è la creazione di un ambiente di hosting esterno completamente separato (completo di ridondanza e autenticazione) che viene semplicemente utilizzato per il proxy di tutto il traffico in uscita senza carta di credito. Quindi dovremmo solo consentire l'IP del nostro proxy. Mi sembra eccessivo, e faccio fatica a credere che sia la soluzione migliore.

Sicuramente non possiamo essere l'unica azienda compatibile PCI che deve gestire regole del traffico in uscita così dinamiche? Come stanno le altre aziende a risolvere questo problema?

firewalls pci-dss

posta realworldcoder 23.08.2012 - 18:08

fonte

3 risposte

Leggi altre domande sui tag firewalls pci-dss

Quanto vale la crittografia del disco? Minaccia di Bios, SMM, optionrom, TPM ecc.? Memorizzazione chiavi di licenza

score 2 · Answer 1

È possibile aggirare un tale scenario limitando gli indirizzi IP a un "range", normalmente un subnet block (dato che la società esterna aveva un blocco contiguo e quindi anche se c'era un TTL basso, le regole sarebbero comunque Essere a posto)? I fornitori di servizi esterni hanno un blocco contiguo o un intervallo noto di indirizzi IP? Nella mia esperienza, la maggior parte lo fa.

Dalla mia comprensione dei requisiti PCI (disco: sono un po 'arrugginito, è passato un po' di tempo), la soluzione summenzionata sarebbe sufficiente perché la destinazione è limitata e la tua base di regole avrà ancora un rifiuto esplicito.

Un'altra potenziale soluzione è avere un server proxy, internamente sulla LAN o in una zona quasi DMZ che il server DMZ può comunicare con i servizi esterni. Il criterio può essere realmente bloccato sul server proxy in modo tale che l'accesso esterno dal server DMZ possa essere limitato al sito, al protocollo, al tempo ecc. Il server proxy è progettato per gestire i nomi di dominio completi (mentre il firewall in genere non lo è e può risentirne degrado delle prestazioni come descritto da @JeffFerland) in modo da poter disporre di un criterio più rigoroso poiché si baserebbe sui nomi di dominio completi come destinazioni, non su intervalli IP.

Penso che molto dipenda dal QSA che si presenta il giorno:)

Inoltre, sono sicuro che lo sai, ma tutte le "best practice sulla sicurezza" (afaik) insistono fermamente sulla prevenzione delle chiamate in uscita dalla DMZ (periodo) in modo che se la casella sulla DMZ viene spuntata, l'attaccante non può facilmente caricare altri extra sul server o un malware possono chiamare casa molto più facilmente.

score 1 · Answer 2

Sembra un dolore giusto. Il problema con l'indirizzamento "FQDN" è che è richiesta una ricerca DNS e fare affidamento sui timeout può causare un ritardo nella reazione del firewall. Suggerirei di guardare in un altro modo.

Può essere gestito con una VPN? C'è un certo blocco di spazio degli indirizzi che puoi aspettarti di possedere per i tuoi server?

È possibile consentire esplicitamente una connessione a una porta su qualsiasi host e rimanere nella specifica (ad es. *: 80). Puoi anche usare SSL per autenticare le tue connessioni (anche se sarà difficile se non sono persistenti).

score 1 · Answer 3

Leggendo il tuo post, mi veniva in mente l'idea di usare il tuo proxy prima che arrivassi così lontano:

Another solution is to set up a completely separate external hosting environment (complete with it's own redundancy and authentication) that is simply used to proxy all non-credit-card outgoing traffic

In realtà non vedo che questo sia così oneroso: dovresti essere in grado di delegare il traffico crittografato (evitando così la perdita di dati dai tuoi server di elaborazione, senza problemi di riservatezza / integrità sul proxy). L'unico problema diventa quindi il traffico di terze parti che viene instradato attraverso il tuo proxy ed è accettato come se provenisse dai tuoi server - Mi piacerebbe pensare che i tuoi fornitori upstream usino più di un semplice indirizzo IP per identificare le tue legittime transazioni - ma tu potrebbe limitare ulteriormente l'accesso consentendo solo connessioni TCP in ingresso sul proxy tramite ipsec / vpn.

Quindi un dispositivo proxy, con un firewall leggero, richieste DNS in uscita, richieste HTTPS in uscita, richieste HTTPS in arrivo (su un canale limitato) e ssh per accesso remoto - non mi sembra troppo complesso.