Come posso essere sicuro che un'app intranet non sia assolutamente accessibile da internet?

Alcune configurazioni che mi vengono in mente:

• Non posizionare il server in una DMZ
• Accetta le connessioni sugli indirizzi 192.168.0.0 nella configurazione di Apache.
• Inserisci un rifiuto da tutti + accetta da con l'intervallo corretto di IP nella configurazione di apache
• Rifiuta l'inoltro delle connessioni VPN (?) nel firewall (se applicabile).

La tua applicazione web è molto simile a qualsiasi altro servizio (condivisione di file, stampa) che hai in esecuzione sulla tua rete interna.

Di solito i router Internet eseguono funzioni firewall che bloccano il traffico da Internet a qualsiasi indirizzo IP interno, a meno che non sia specificato diversamente (tramite NAT statico o port forwarding), quindi l'accesso diretto da Internet a un servizio interno come il tuo sito web non essere possibile.

Se vuoi verificarlo, puoi eseguire una scansione delle porte del firewall di fronte a Internet. Un modo semplice per iniziare con questo sarebbe utilizzare qualcosa come Shields Up da una macchina sullo stesso rete, che eseguirà una scansione delle porte del tuo indirizzo IP esterno (questo presuppone una rete relativamente piccola con un singolo indirizzo IP esterno).

In termini di accesso indiretto al tuo sito web, è possibile che qualcuno possa accedere tramite malware su una macchina sulla stessa rete o su qualche altro percorso indiretto, ma questo è un po 'un argomento completamente diverso.

La prima cosa da controllare sarebbero le regole del firewall, per assicurarsi che non ci siano regole che consentano l'accesso esterno diretto ai vari servizi sull'host. Controlla sia le regole di "port forwarding" che quelle di "static address translation".

Quindi, controlla la sicurezza di tutti gli host / servizi che sono accessibili da Internet. Se un utente malintenzionato può compromettere un host diverso sulla rete, una volta dietro il firewall, può "ruotare" e accedere ad altri host sulla rete, inclusa la tua app.

Se si vuole essere assolutamente sicuri, è necessario eseguire il airgap del server Intranet. Sarebbe probabilmente troppo pesante da usare però.

Scopri quello che posso pensare di avere a disposizione per assicurarti di utilizzare lo schema di indirizzamento RFC1918 e assicurarti che gli indirizzi interni siano lasciati cadere sull'interfaccia esterna del firewall.

Essere assolutamente certi è molto difficile qui. Ad esempio, qualsiasi macchina sulla rete interna può eseguire proxy HTTP a porte casuali, a volte anche collegando SSH alla rete esterna e collegando il traffico su di essa. A meno che la porta HTTP non sia l'unica porta aperta nel tuo firewall in entrambe le direzioni e Apache sia l'unica macchina nella rete a cui è consentito accettare / avviare connessioni verso il mondo esterno, è difficile essere al 100% certo.

Questo non è solo uno scenario teorico; Ho fatto di proposito setup come questo (cioè proxy HTTP + tunnel SSH) di proposito, per accedere alla intranet aziendale quando si lavora a casa. Devi solo essere a conoscenza delle implicazioni sulla sicurezza quando lo fai.

Secondo me un servizio intranet che deve essere veramente sicuro non dovrebbe dipendere unicamente dall'essere in una rete privata - deve utilizzare SSL, account utente e autorizzazioni specifiche per account per controllare l'accesso anche in remoto.

Partendo dal presupposto che probabilmente intraprenderai iniziative simili nel prossimo futuro, penso che sia necessario un approccio diverso da quello che è stato proposto nelle risposte precedenti. Vorrei suggerire di delineare e stabilire una strategia per "assicurare" le future applicazioni / sistemi. Utilizzando una strategia puoi garantire coerenza, delegare responsabilità e migliorare la tua pratica nel tempo.

Credo che la sicurezza di un server non dovrebbe essere fatta in un modo ad hoc, ma piuttosto metodologicamente e coerentemente. Dovrebbe essere un processo ripetibile con il minor spazio possibile per gli errori. Noi umani siamo notoriamente cattivi nel ricordare i dettagli, spesso mescolando bit di informazione in qualcosa di completamente diverso.

Nello scenario che descrivi sopra usando una prospettiva di Disponibilità sembra essere per lo più rilevante e utile. Inizia descrivendo stabilire le dipendenze del sistema. Quali altri sistemi devono essere accessibili per il corretto funzionamento dell'applicazione? Dipende da una directory utente esterna? Le dipendenze sono importanti perché aiutano a capire meglio i potenziali "viali", o vettori, di attacco.

Prossimi dettagli di chi deve avere accesso al sistema e al "terminale" di accesso primario (desktop remoto, workstation, laptop, telefono cellulare, ecc.). In questo modo avrai iniziato a stabilire il tuo schema di riferimento o il limite del sistema, se lo desideri.

È molto probabile che ci siano dei limiti organizzativi a cui devi semplicemente obbedire. Questi potrebbero includere metodi di autenticazione obbligatori dell'azienda, algoritmi di crittografia e simili, descrivere e documentare queste limitazioni. Potrebbe anche essere necessario prendere in considerazione i requisiti legali e ora potrebbe essere un buon momento per scoprirlo.

Una volta stabiliti i blocchi fondamentali più "fondamentali" del tuo sistema, è tempo di un po 'di brainstorming creativo. Prova e descrivi tutte le potenziali vie attraverso le quali tu (o un utente malintenzionato) potresti accedere al sistema usando la descrizione di sistema di cui sopra come una sorta di limitazione.

Quello che dovrai fare successivamente è determinare quali controlli di sicurezza garantirebbero la protezione più appropriata. Sì, lo so, è qui che le cose si complicano perché è un processo un po 'soggettivo, ma è necessario. Ogni contromisura che si determina è necessaria sarà associata ad un certo costo (tempo di installazione, configurazione, manutenzione ed eventualmente ritiro).

Dovresti anche provare a descrivere con una sorta di misura quantitativa come "bene" una serie di contromisure attenui un particolare rischio, o "limiti" una via d'attacco. Credo che questo sia importante soprattutto per la "gestione superiore", parla una lingua di numeri. Ad esempio, un'implementazione "buona" delle password salate eliminerà completamente la minaccia degli hash precomputed e potrebbe quindi essere descritta come una contromisura "ad alta sicurezza".

In breve:

1. Determina l'obiettivo / obiettivo di sicurezza principale (riservatezza, integrità e disponibilità)
2. Stabilire le dipendenze del sistema
3. Chi, come e quando?
4. Dettaglio dei requisiti / limitazioni / vincoli organizzativi e / o legali
5. Brainstorm attack vettors (supponiamo che si possa chiamare questa una leggera analisi delle minacce)
6. Scegli le contromisure appropriate per il sistema in questione
7. Crea arcobaleni, carte colorate e unicorni.

Un modo per garantire che i pacchetti originati dalla tua applicazione non raggiungano gli estranei, è manipolando il valore ttl usando iptables. Presumo che tu stia usando Linux per ospitare la tua applicazione.

In un handshake TCP, un utente malintenzionato sarebbe in grado di raggiungere il tuo server web con un pacchetto SYN, ma il router eliminerà i pacchetti destinati all'esterno della rete interna.

Un esempio di questo è avahi-daemon . Ignorerà tutti i pacchetti che non hanno TTL impostato su 255, il che significa che deve provenire dal proprio segmento di rete.

Su un sistema Linux, puoi scegliere di modificare ttl in uscita per porte specifiche o globalmente attraverso sysctl.

Questa soluzione non è infallibile e probabilmente introdurrà alcuni problemi di disponibilità come: i client che si connettono tramite VPN, moltiplicano i percorsi con gli hop di rete non qualificati ai gateway di confine.

Iptables:

Il tutorial iptables per target TTL spiega come creare una regola per questo problema . Questo è anche coperto qui Come impostare ttl .

Sysctl:

echo "1" > / Proc / sys / net / ipv4 / ip_default_ttl

Anche se il server non è accessibile direttamente dall'esterno, gli utenti che si connettono al server hanno un collegamento verso l'esterno.

Non è possibile che alcuni malware vengano installati su un sistema degli utenti, che viene quindi utilizzato per accedere al server?

Ad esempio, (un esempio di non malware, ma continua a dare l'idea)

Teamviewer è installato su un PC degli utenti

Qualcuno si connette a Teamviewer da fuori

Outsider utilizza il PC degli utenti per connettersi al server