Domanda:
Quanto è importante il NAT come livello di sicurezza?
iainlbc
2011-11-09 09:29:34 UTC
view on stackexchange narkive permalink

Mi sono iscritto per aiutare un dipartimento a spostare edifici e aggiornare la loro vecchia infrastruttura. Questo reparto ha circa 40 dipendenti, 25 desktop, un vecchio server Novell e una manciata di macchine di elaborazione di laboratorio con sistemi collegati. Nella vecchia sede, questo reparto aveva due reti: una LAN senza alcun accesso esterno su uno switch completamente separato e alcune macchine con accesso esterno.

Stiamo cercando di modernizzare un po 'questa configurazione poiché praticamente ogni utente deve accedere alla posta elettronica e al sistema di monitoraggio del tempo.

L'organizzazione madre (~ 10.000 dipendenti) dispone di un ampio reparto IT che si occupa della connessione e del sistema telefonico nella nuova sede fuori sede. Il reparto IT Uverse è entrato e ha impostato una VPN sulla propria rete centrale. Ogni desktop deve essere registrato nel sistema / sito Web del reparto IT per ottenere un indirizzo IP (statico). Ciascun indirizzo IP fornito è accessibile dall'esterno su qualsiasi porta che abbia un servizio in ascolto sulla macchina client.

Il server ha dati confidenziali (HIPPA) su di esso, i desktop hanno unità di rete mappate per accedere (alcuni) a questi dati. Esiste anche un LIS client / server.

La mia domanda è questa: vale la pena far schifo che tutte queste macchine siano accessibili dall'esterno?

Dobbiamo:

  • Richiedere al NAT di astrarre l'esterno dall'interno, oltre a un firewall che blocchi tutto il traffico non esplicitamente definito come consentito? Se è così, quali argomenti posso fare per NAT / firewall che superano i vantaggi di avere ciascuna macchina registrata nel proprio sistema? In entrambi i casi, inoltrerei tutte le richieste relative all'IT dagli utenti finali al reparto IT, quindi non sembra molto necessario averle legate a indirizzi specifici nel loro sistema. Ancora più importante, sembra un incubo gestire firewall separati su ogni desktop (piattaforme / generazioni diverse) e sul server.
  • Richiedi il reparto IT. blocca tutto il traffico in entrata a ogni IP Wan accessibile su qualsiasi firewall esistente in loro presenza
  • Mantieni la LAN dei reparti completamente isolata da Internet. Gli utenti devono condividere macchine dedicate per accedere alla posta elettronica, a Internet e al sistema di monitoraggio del tempo.

Grazie in anticipo per eventuali commenti o consigli su questo.

Questa è una buona domanda su cui le persone di solito si confondono. Personalmente mi piace il NAT solo per scopi organizzativi, non per la sicurezza. Se guardi IPv6, non c'è davvero NAT. Hai solo bisogno di impostare il valore predefinito per negare sul firewall e andare da lì.
È improbabile che l'abbiano impostato come pensi che abbiano fatto. Probabilmente sei appena stato bloccato dalla loro rete principale e tutta la tua connessione Internet ora passa attraverso di loro tramite la nuova VPN. Sebbene i PC siano accessibili da loro tramite la VPN dai loro indirizzi interni, non è possibile un effettivo accesso esterno da Internet. Il firewall si trova nella sede principale.
Se la conformità HIPAA è qualcosa di simile al PCI, immagino che ci sia qualcosa sulla segregazione delle reti che ti consente di separare le reti conformi HIPAA, rispetto a una rete standard.
Nove risposte:
#1
+55
David Schwartz
2011-11-09 09:41:22 UTC
view on stackexchange narkive permalink

NAT e firewall sono concetti completamente ortogonali che non hanno nulla a che fare l'uno con l'altro. Poiché alcune implementazioni NAT forniscono accidentalmente alcuni firewall, esiste un mito persistente che NAT fornisce sicurezza. Non fornisce nessuna sicurezza di sorta. Nessuna. Zero.

Ad esempio, un'implementazione NAT perfettamente ragionevole potrebbe, se avesse un solo client, inoltrare tutti i pacchetti TCP e UDP in entrata a quel client. L'effetto netto sarebbe esattamente lo stesso come se il client avesse l'indirizzo esterno del dispositivo NAT.

Non pensarlo, poiché la maggior parte dei dispositivi NAT ha un firewall integrato per progettazione o lo fa per sbaglio questo significa che NAT stesso fornisce qualsiasi sicurezza. È il firewall che fornisce la sicurezza, non il NAT. Lo scopo del NAT è far funzionare le cose.

Non devi presumere che una macchina non sia accessibile dall'esterno solo perché si trova dietro un dispositivo NAT. Non è accessibile dall'esterno se un dispositivo è specificamente configurato per non consentire l'accesso dall'esterno, indipendentemente dal fatto che quel dispositivo abbia NAT o meno.

Ogni macchina ha un indirizzo esterno ma con un firewall stateful configurato correttamente , gestito e monitorato è di gran lunga superiore a una scatola NAT SoHo economica.

Molte scatole NAT SoHo effettive inoltrano il traffico agli host interni nonostante nessun host interno abbia mai inviato traffico alla sorgente del traffico inoltrato. Il NAT permissivo esiste davvero.

Bella risposta. Qualsiasi sicurezza percepita fornita da NAT è un effetto collaterale puramente non intenzionale di RFC1918. NAT non è un meccanismo di sicurezza, è un meccanismo di traduzione. Può astrarre o oscurare i sistemi dietro di esso, ma non fornisce sicurezza per quei sistemi.
Capisco che c'è una differenza tra NAT e firewall. Non sono sicuro di dove abbia avuto l'impressione della mia domanda altrimenti. "Richiedere al NAT di astrarre l'esterno dall'interno, oltre a un firewall che blocchi tutto il traffico non esplicitamente definito come consentito?" Questo non implica che lo capisca? NAT per natura dell'astrazione di indirizzi interni da indirizzi accessibili esterni fornisce sicurezza dal mio punto di vista. Come può qualcuno, ad esempio, forzare un account sa di SQL Server su un host a cui non possono accedere, perché l'indirizzo non è accessibile / instradabile pubblicamente?
@iainlbc Sono entrato in alcuni dettagli su NAT, isolamento di rete e posizione di sicurezza qui: http://serverfault.com/questions/184524/switch-to-ipv6-and-get-rid-of-nat-are-you-kidding / 184535 # 184535
@DavidSchwarts "Non devi presumere che una macchina non sia accessibile dall'esterno solo perché si trova dietro un dispositivo NAT." tuttavia, sysadmin1148 dice nella sua risposta collegata "L'unico grande vantaggio in termini di sicurezza che ottieni con NAT è che ti costringe a una configurazione di negazione predefinita. Per ottenere qualsiasi servizio attraverso di esso, devi esplicitamente perforare i buchi." Quindi è lecito presumere, a meno che non faccia un buco nella configurazione NAT predefinita abilitando esattamente la cosa che voglio impedire, NAT fornisce una certa misura di sicurezza?
@iainlbc: Se per "NAT" intendi "NAT stesso", allora * no *. NAT non fornisce alcuna sicurezza. Ancora una volta, leggi il secondo paragrafo della mia risposta. Se per "NAT" intendi una scatola che fornisce NAT e anche un firewall, allora * sì *. I firewall forniscono sicurezza. La parte su "default deny" è tecnicamente vera, ma priva di significato. * Everything * fornisce la negazione predefinita in questo senso sciocco e vacuo poiché ti viene spedito scollegato.
Penso che ci stiamo avvicinando a me per capire questo. Perdona la mia testardaggine .. Diciamo che ho un singolo server che esegue SQL su 1433. Lo collego direttamente a un router con un indirizzo IPV4 pubblico. Puoi premerlo da qualsiasi luogo e provare a inserire la password. Ora posiziono questo server dietro il dispositivo NAT più semplice mai creato e gli do un indirizzo 192.168.10.1. Non faccio una sola cosa in termini di prevenzione o autorizzazione del traffico su 1433 su un firewall o sul dispositivo nat. Come farai ad accedere alla mia macchina, una volta dietro nat, sulla porta 1433, per tentare la password, avendo solo l'indirizzo del router?
@iainlbc: Raggiungerò la porta 1433 sull'indirizzo IP pubblico della casella NAT e la inoltrerò al server SQL (poiché il server SQL è il suo unico client, sa che deve essere il destinatario previsto). In caso contrario, è perché è anche un firewall, nel qual caso lo filtrerà / lo eliminerà. Ma non è a causa del NAT, è a causa del suo firewall che rifiuta i pacchetti in entrata che non corrispondono a una regola riflessiva esistente anche se potrebbe NAT. In altre parole, poiché è * anche * un firewall, fornisce una certa sicurezza. Un semplice firewall che interrompesse il traffico fornirebbe la stessa sicurezza, giusto?
Lo scopo del NAT è quello di far "funzionare" le macchine anche se non ci sono indirizzi IP pubblici sufficienti per loro. A causa del modo in cui il NAT è tipicamente implementato, i box NAT tendono a implementare anche alcuni firewall. Ma un firewall farebbe la stessa cosa e fornirebbe gli stessi vantaggi. Il NAT è superfluo per la sicurezza. Se disabiliti il ​​NAT ma mantieni il firewall riflessivo e con stato, otterrai la stessa sicurezza. E una scatola NAT senza un firewall reflextive e stateful non fornirebbe alcuna sicurezza. (E ci sono sicuramente alcuni dispositivi NAT "permissivi" che forniscono * molto * poco!)
Penso di aver bisogno di un buon libro consigliato su reti / sicurezza. Penso anche che forse sto usando nat per riferirmi a qualche altra tecnologia o mi manca un concetto estremamente fondamentale qui. Quindi un router e un firewall sono tutto ciò che è necessario per creare una rete privata di diciamo 192.168.10.1 - 192.168.10.250, che può accedere e comunicare con reti esterne, con un'unica interfaccia esterna diciamo 10.1.1.1?
lasciaci [continuare questa discussione in chat] (http://chat.stackexchange.com/rooms/1749/discussion-between-david-schwartz-and-iainlbc)
Se mantieni chiusi i socket per l'accesso pubblico, cioè per il tuo server sql, sei al sicuro con NAT. Ma sarebbe così anche se il server sql avesse un IP pubblico. NAT è, come detto, un meccanismo. Le tue impostazioni fw sono la tua sicurezza. Tuttavia, la maggior parte dei FW NAT offre un comportamento predefinito di negazione plug n run. Penso che IPv6 ci darà più di quella natura predefinita per l'indirizzamento pubblico.
"fornire accidentalmente un firewall" - non sono d'accordo. Sebbene le mappature statiche forniscano poca protezione, il mascheramento è esplicitamente inteso a risolvere entrambi i problemi di riduzione dell'impronta dello spazio degli indirizzi, ma agisce intrinsecamente come un firewall con stato. D'accordo che non è un sostituto per un firewall però.
@symcbean: Non agisce intrinsecamente come un firewall con stato a meno che non sia progettato / configurato per. In tal caso, è quel design / configurazione che è il firewall, non la parte NAT. Leggi il mio secondo paragrafo. Ho visto caselle NAT mascherate che inoltreranno il traffico che non è una risposta. (Vedi il mio secondo e ultimo paragrafo.)
@David Schwartz: "mascheramento di caselle NAT che inoltreranno traffico che non è una risposta" - IMHO è un ossimoro - per definizione il dispositivo non è mascherato. Come fa a sapere a quale box interno inviare il traffico?
@symcbean: Ci sono molti modi in cui può saperlo. Ad esempio, potrebbe avere un solo client. Può inoltrarlo al nodo interno che ha inviato il traffico "più simile" anche se il pacchetto non è una risposta.
Citazione @David Schwartz: per favore?
@symcbean: Per cosa vuoi esattamente una citazione? Credi che quelle cose siano impossibili? Credi che in qualche modo impediscano al dispositivo di smettere di mascherarsi? (Se non credi che nessun dispositivo lo faccia effettivamente, controlla la documentazione di quasi tutti i router SoHo. Per esempio, il NetGear WGR614.) Il NAT permissivo è reale ed è popolare. Fa sì che molte cose "funzionino e basta", che è il punto di NAT.
@David Schwartz: Gli scenari che descrivi, a quanto mi risulta, sono quelli in cui il router smette di eseguire il masquerading. Sono sempre disposto a imparare, ma dove mi vengono fornite informazioni che contraddicono esplicitamente ciò che già so voglio avere l'opportunità di verificarle.
@symcbean: È come sostenere che un router è sicuro a meno che non lo si colleghi. È puro sofismo. Il punto è che puoi avere NAT (indirizzi IP privati, accesso a Internet) ma praticamente nessuna sicurezza (se, ad esempio, il NAT è permissivo).
@David Schwartz: Come? Voglio ancora vedere più della tua opinione.
@symcbean Niente di ciò che ho detto è un'opinione. È un fatto molto semplice che puoi avere NAT ma fondamentalmente nessuna sicurezza di sorta. Leggi il secondo paragrafo della mia risposta alcune volte finché non lo ottieni.
@David Schwartz: come sopra, sono disposto a imparare - ma non riesco a trovare prove a sostegno della tua posizione - ma molte fonti affidabili affermano il contrario - vedi risposta altrove.
@symcbean Non so come rispondere a questo. Il mio secondo paragrafo è un fatto semplice e indiscutibile. Puoi accettarlo o infilare le dita nelle orecchie e annunciare che non stai ascoltando.
@DavidSchwartz Supponi di avere un router NAT che esegue NAPT, senza port forwarding. Il router NAT sta bloccando tutte le connessioni in entrata. L'interfaccia del router NAT non ha opzioni firewall, non c'è niente di un firewall nelle specifiche. Q1) Diresti che non è il NAT o il NAPT a bloccarlo, è un firewall nel dispositivo che lo sta bloccando? Q2) Diresti che è stata una sicurezza accidentale? Q3) Diresti che non è sicuro? Perché?
Q1) Probabilmente. Dipenderà precisamente da come il dispositivo ha gestito il traffico impareggiabile. Q2) Dipenderebbe dal fatto che questo comportamento sia stato esplicitamente specificato dal produttore o dalla documentazione. Se non specificato, sì. Se specificato e garantito, no. D3) Se ti affidi solo al dispositivo per soddisfare le sue specifiche documentate, allora va bene. Se ti affidi al dispositivo per continuare a comportarti come l'hai osservato, allora non è sicuro. La sicurezza deriva dalle garanzie, non si basa su comportamenti non documentati / osservati.
"NAT non fornisce alcuna sicurezza" Non sono assolutamente d'accordo.Abbiamo fatto di proposito il double-NAT dove lavoravo, perché era dannatamente quasi impossibile penetrare oltre il primo NAT dall'esterno (come afferma anche Sans Institute).Inoltre, le connessioni Internet serie hanno almeno un dispositivo DMZ configurato (nel NAT esterno), rendendo nulle e prive di valore le scansioni delle porte, poiché nessuno metterebbe altro che dispositivi con la propria protezione / firewall in una DMZ.Double-NAT è più efficiente, impatto delle risorse vicino allo zero rispetto a firewall, ispezioni stateful, ecc.
@Julius Come ho spiegato nella mia risposta, il doppio NAT non fornisce alcuna sicurezza.Leggi il secondo paragrafo.
@DavidSchwartz Fallisce come "spiegazione", argomentare contro di essa non è un buon consiglio di sicurezza generale.Anche i router NAT economici sono preziosi dispositivi di sicurezza della rete e offrono molta più flessibilità rispetto al semplice utilizzo per interfacciare una rete locale a Internet.Possono essere utilizzate come "valvole di sicurezza unidirezionali" per creare strati di sottoreti protette.Nei miei oltre 20 anni di amministrazione di cumuli di reti multi-NAT per piccole imprese e utenti domestici privati, finora non ho visto intrusioni da contare.Nessuno dei (pigri) scansioni / worm e altre sciocchezze fastidiose e dannose di Internet sono riusciti a passare.
@Julius Se uno di quei dispositivi NAT ti ha effettivamente bloccato da un attacco anche se non hai configurato il firewall per farlo, è perché il suo NAT non era abbastanza permissivo da passarlo per caso o per fortuna.Cosa succede se la prossima versione del firmware rende il NAT più permissivo?
"Il NAT permissivo esiste davvero."Capisco se questo è un NAT uno-a-uno (come mappare una rete `/ 24` su un'altra rete` / 24`), ma esiste un NAT permissivo uno-a-molti?
Si prega di ignorare il commento sopra.C'è una cosa chiamata [host DMZ] (https://en.wikipedia.org/wiki/DMZ_ (informatica) #DMZ_host).
@FranklinYu Sì.Esistono router SOHO che instraderanno tutto il traffico in entrata a uno dei loro client utilizzando un algoritmo di "corrispondenza migliore".
@DavidSchwartz Questo è ancora più cattivo, ma c'è qualche esempio per un router del genere?Riesco a trovare solo un esempio per un obiettivo di inoltro predefinito fisso (come ho detto sopra).Non so quale parola chiave cercare;Ho provato "port forwarding del router soho intelligente".
@FranklinYu Perché è quel male?Questo fa sì che molte cose "funzionino e basta" che altrimenti non funzionerebbero.Lo scopo del NAT permissivo è rendersi il più invisibile possibile.L'unico senso in cui è malvagio è che la stessa cosa può funzionare in alcune circostanze e non funzionare in altre.Se desideri funzionalità firewall, configurale come dovresti.
#2
+14
sysadmin1138
2011-11-09 09:47:46 UTC
view on stackexchange narkive permalink

Dopo aver appena trascorso 7 anni in un'università con un netblock / 16 e aver messo tutto su quel netblock che non era specificamente proibito essere su tale (PCI-DSS lo richiedeva, finché non lo risolvevano), ne ho esperienza con reti di questa natura.

NAT non è richiesto. Tutto ciò che fa NAT è rendere un po 'più difficile riconnettere una rete e costringere un'entità a una postura più sicura per impostazione predefinita. Detto questo, è perfettamente possibile costruire una rete sicura su indirizzi IP pubblici. C'erano un paio di sottoreti che erano tecnicamente instradabili, ma niente al di fuori del firewall perimetrale poteva arrivarci.

Ora per gli altri punti:

Richiedi l'IT Dipartimento. blocca tutto il traffico in entrata a ogni IP accessibile wan su qualunque firewall esistente che hanno in atto

Questo dovrebbe essere fatto per impostazione predefinita. Nella mia vecchia università, le postazioni dello Student Computer Lab non avevano bisogno di essere indirizzabili da Internet e non lo erano. Lo stesso valeva per le sottoreti che contenevano i dati dello Student Health Center. Se una macchina doveva essere visibile esternamente per qualche motivo, c'era un documento elettronico che doveva essere passato e firmato prima che potesse essere concesso; anche per i server nello stack IT centralizzato.

Mantieni la LAN dei reparti completamente isolata da Internet. Gli utenti devono condividere macchine dedicate per accedere alla posta elettronica, a Internet e al sistema di monitoraggio del tempo.

Non devi andare così lontano. Il motivo per arrivare a questo punto è se la tua paura dell'esposizione alle informazioni relative al malware è maggiore della necessità di connettività alle risorse di rete. Oggigiorno le cose sono sempre più basate su cloud / rete, quindi tali reti con air gap stanno diventando sempre più difficili da mantenere. Se hai davvero bisogno di arrivare a questo punto, potresti voler esaminare alcune delle opzioni di Application Virtualization disponibili, in quanto ciò può limitare l'esposizione delle violazioni nel caso si verifichino.

Esattamente. Gestisco una rete che utilizza indirizzi instradabili pubblicamente e non è meno sicura a causa della mancanza di NAT. È il firewall che fornisce la sicurezza, non il NAT.
Grazie a entrambi, leggendo tutto questo ora. Estremamente contento di aver chiesto agli esperti invece di esporre al reparto IT quanto sono male informato sull'argomento ...
L'org. consente il traffico su tutte le porte verso questi indirizzi in base ai miei test rudimentali (RDP, SSH, FTP, SQL, 80) ed è stata la cultura da qualche tempo. Preferisco di gran lunga compilare esplicitamente i moduli di richiesta del firewall. In effetti, se questo fosse a posto, probabilmente non avrei nemmeno preso in considerazione il NAT o pubblicandolo, sembra che alla configurazione manchi qualcosa. È chiaro ora che le regole del firewall, non il NAT.
"Avendo appena trascorso 7 anni in un'università con un netblock / 16 e aver messo su quel netblock tutto ciò che non era specificamente proibito su tale (PCI-DSS lo richiedeva, finché non lo risolvevano), ho una certa esperienza con reti di questa natura. ", mi dispiace tanto.
Lavorare con un blocco / 16 in un uni non garantisce alcuna validità di consigli di sicurezza generali contro NAT.Non riesco davvero a vedere come l'oscuramento di una LAN (anche più di una volta in serie) possa mai essere * scontato * come ulteriore livello di sicurezza.Seriamente, dove siete stati tutti negli ultimi decenni?Vediamo cosa dice anche Steve Gibson, vero?https://www.grc.com/nat/nats.htm
#3
+12
Tom Leek
2011-11-09 19:37:23 UTC
view on stackexchange narkive permalink

Come altri hanno sottolineato, NAT non è una funzione di sicurezza . Tuttavia, offre un certo livello di sicurezza come sottoprodotto: un effetto collaterale del NAT è che nessuna delle macchine interne è accessibile "dall'esterno". Lo stesso effetto può essere ottenuto da un firewall che blocca tutte le connessioni in entrata. Questo non è granulare, ma piuttosto efficace nella pratica, e se NAT non fosse dotato di quella protezione "automatica", molte più reti esistenti verrebbero attaccate e zombificate in spam relay (questo è il punto spaventoso di IPv6, tra l'altro : IPv6, quando [se] ampiamente distribuito, avrà la tendenza ad annullare l'effetto di protezione del NAT e ci si può aspettare un aumento medio del successo dell'attacco).

Ora avere un firewall ben configurato presuppone che chi configura il firewall fa correttamente il suo lavoro e, purtroppo, non è un dato di fatto (non voglio presumere sulle capacità del tuo specifico reparto IT, ma sulla qualità media del lavoro dei reparti IT di tutto il mondo, soprattutto in grandi organizzazione, è meno che emozionante). L'alternativa è fare in modo che ogni singola macchina accessibile pubblicamente resista a tutti i tipi di attacchi legati alle connessioni in entrata: chiudi tutti i servizi non necessari, assicurati che i servizi che restano aperti siano adeguatamente aggiornati e ben configurati. Desideri applicare gli aggiornamenti di sicurezza su ogni singola workstation? E sul firmware delle stampanti in grado di connettersi in rete?

Il mio consiglio sarebbe di installare la tua scatola filtro, attraverso la quale passeranno tutte le comunicazioni tra la tua rete e il mondo esterno. Quella casella dovrebbe quindi filtrare le connessioni in entrata; NAT e / o firewall, questa è la tua chiamata. NAT può essere più semplice, soprattutto se il reparto IT è "non collaborativo".

#5
+7
Bradley Kreider
2011-11-10 22:55:15 UTC
view on stackexchange narkive permalink

NAT non è importante come livello di sicurezza e non dovrebbe essere pensato come una garanzia di sicurezza (anche quando inavvertitamente lo rende più sicuro).

Non conosco la conformità HIPPA, ma la conformità PCI richiede configurazioni molto specifiche per i computer che hanno accesso alle informazioni della carta di credito. È necessario progettare prima di soddisfare i requisiti HIPPA e quindi progettare misure di sicurezza aggiuntive. Lo scherzo della conformità PCI è che la conformità riduce il rischio di multe, ma non necessariamente riduce il rischio di exploit di sicurezza.

Le regole HIPPA potrebbero informarti su come devi trattare i computer che hanno accesso ai dati HIPPA.

#6
+4
Antti Rytsölä
2011-11-09 12:40:17 UTC
view on stackexchange narkive permalink

Anche se conosco un po 'di NAT e di port forwarding, non sono d'accordo per la maggior parte di ciò che ha scritto David Schwartz. Potrebbe essere perché era un po 'scortese Leggi il secondo paragrafo della mia risposta .

NAT non è la risposta a tutto. Rende solo difficile per le parti esterne connettersi ai tuoi servizi. La maggior parte delle implementazioni NAT esegue la conversione porta per porta e se l'host nel pacchetto in entrata non viene riconosciuto non ci saranno regole NAT da seguire, quindi connessione negata. Questo lascia ancora alcuni buchi con il client del server appena connesso per riconnettersi.

Più importante è proteggersi dalle connessioni interne così come dalle connessioni esterne. NAT fornisce una falsa sicurezza in questo modo. Hai solo bisogno di un bug da una chiavetta USB e potrebbe esserci un inoltro della connessione che consente a tutti di entrare.

Indipendentemente dal tuo spazio IP, dovresti limitare le connessioni a quelle consentite. Le workstation di solito non dovrebbero essere autorizzate a connettersi al servizio SQL. Personalmente non mi piacciono i firewall con stato ma ognuno per conto suo. Sono più un tipo di tipo router rilascia tutti i pacchetti.

Ovviamente non è una risposta a tutto, specialmente non alla sicurezza, in quanto non è un livello di sicurezza (e se è così, è in qualche modo accidentale). Sono d'accordo con te che è necessario un buon firewall con regole adeguate, NAT o no. (Non penso che tu sia effettivamente in disaccordo con l'altra risposta :))
È interessante notare che qui si discute così poco su a) il rischio derivante da un "peer" compromesso eb) i servizi in stile Akamai disponibili per rendere raggiungibili le macchine non raggiungibili.Google "Raspberry Pi Access over Internet" per alcuni.Se posso eseguire il RDP su un peer, posso eseguire tentativi di attacco sulla sottorete.
#7
+1
VP.
2017-01-10 22:10:20 UTC
view on stackexchange narkive permalink

NAT è un firewall. E non è un'opinione. È un fatto. Esaminando la definizione di Firewall:

Un firewall è "un sistema o una combinazione di sistemi che impone un confine tra due o più reti".

Modello di riepilogo funzionale del firewall standard della National Computer Security Association

Un NAT crea esattamente quel tipo di confine.

Ciò che altri firewall potrebbero fornire è la capacità di bloccare le connessioni in uscita , non solo le connessioni in entrata. Bella caratteristica, ma non quella principale.

Parlando di funzionalità, una DMZ è un buco tra le reti. Normalmente fornisce un modo per esporre un servizio interno a Internet. Anche se tecnicamente non fa parte della definizione NAT, è una caratteristica di tutti i NAT moderni

NAT è un firewall e in alcune situazioni, il migliore. I firewall di ispezione con stato, che non eseguono NAT, eseguono per lo più "fail-open". Ho lavorato per un'azienda di "firewall di nuova generazione" come sviluppatore. Per eseguire il rilevamento del protocollo / dell'applicazione in linea, alcuni pacchetti dovevano passare fino a quando non venivano rilevati. Non c'era modo di bufferizzarlo, senza introdurre ritardi. Quasi tutte le soluzioni DPI funzionano in questo modo.

NAT, d'altra parte, non si chiude. Errori comuni interrompono l'accesso a Internet anziché aprire l'accesso da Internet.

"_Un firewall è" un sistema o una combinazione di sistemi che impone un confine tra due o più reti. "_" In base a questa definizione, un router eBGP standard senza protezione è un firewall perché separa due AS.
Tipo di commento inutile @RonMaupin.Quindi "Per definizione" tagliare il cavo impone un confine tra due o più reti ..
#8
+1
STX Topper MCSE CEH
2019-04-28 18:34:14 UTC
view on stackexchange narkive permalink

Ogni risposta su questo thread riguardo al NAT trascura un aspetto importante del NAT. L'implementazione di NAT crea un intervallo di indirizzi interno, privato e non instradabile . Il termine "non instradabile" è significativo. Gli hacker amano esfiltrare i flussi di dati di rete di un'organizzazione e operare con il traffico di rete interno locale su un intervallo di indirizzi pubblici significa che l'intera nozione di difesa in profondità è notevolmente ridotta. Perché chiunque dovrebbe voler creare condizioni che consentano al tuo traffico locale di essere instradato a Internet globale? Per semplificare le cose, un malintenzionato potrebbe hackerare il dispositivo e aggiungere percorsi, ma perché vorresti dare a tale individuo un ostacolo in meno per eseguire il backhaul dei tuoi flussi di dati di rete interni?

In altre parole, se un contenzioso dovesse sorgere da una violazione HIPAA, ciò che pazzo potrebbe prendere qualsiasi posizione in tribunale e giurare sotto giuramento che dare a un hacker un volo diretto verso le tue informazioni sensibili è stato un decisione sensata? I produttori di router wireless domestici interrompono il NAT come impostazione predefinita perché la loro legge dice loro: "Certo - Lancia i dadi ... Dovremmo bruciare il nostro budget legale per il decennio difendendo un caso in cui abbiamo messo sistemi residenziali personali in innumerevoli famiglie in un affermare che (in pratica) le foglie i loro pantaloni collettivi erano giù intorno alle caviglie! "

Sospetto che ce ne siano troppi che si preoccupano semplicemente di scusare l'implementazione perché non possono o non si prenderanno il tempo per configurare NAT o PAT statico o dinamico appropriato come best practice. PER FAVORE, evita inutili scherni e prigione ignorando gli standard federali. Se accetti un'assicurazione medica federale, i requisiti minimi NIST sono richiesti . Discuti le eccezioni eleganti per un dato valore anomalo tecnologico quanto vuoi, ma non daremo a nessuno l'impressione che sia una buona idea rendere un ambiente più vulnerabile. A parte le ipotesi, fare le cose giuste fa richiede più tempo e impegno ... ma ci sono casi in cui la cosa giusta è la scelta migliore.

#9
  0
gatorback
2016-11-10 21:20:07 UTC
view on stackexchange narkive permalink

Per quanto riguarda la tua domanda "dovrei fare schifo?" Suggerirei di documentare e presentare agli stakeholder una valutazione del rischio (problema, probabilità, impatto, mitigazione). Se prendi una decisione solitaria senza comunicarla e si verifica una violazione significativa, potrebbe essere di cattivo auspicio per te.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...