Audit completo del firewall - Internet non è veramente accessibile?

Da quello che stai descrivendo, direi che l'unico modo per raggiungere il tuo obiettivo è un controllo credenziale del server e del firewall, al contrario della scansione di rete dal server.

Il motivo è che il traffico in uscita è consentito solo a una singola porta alta su un singolo host, in nessun modo il tuo approccio di scansione delle porte lo troverà.

Suggerirei di fare una revisione manuale del set di regole del firewall per assicurarmi che le regole funzionino come previsto. A seconda di ciò che viene utilizzato / di quanto tu sia familiare con quel tipo di cose, puoi farlo manualmente o usare qualcosa come nipper per dare una mano .

Per spiegare cosa stai vedendo su Port Scan.

Tutte le porte rispondono come chiuse anziché filtrate. Ciò è alquanto insolito per una connessione firewall poiché molti firewall eliminano il traffico bloccato anziché rifiutarlo esplicitamente.

Tuttavia questo spiega perché nmap pensa che l'host sia attivo. Nmap usa un paio di meccanismi per determinare che un host è vivo e uno di loro è un ping TCP (guarda la sezione -sP di questa pagina ). Se riceve una risposta, presuppone che l'host sia attivo. Visto che il tuo firewall sembra rispondere con RST / ACK (il messaggio chiuso) che farebbe sì che nmap pensi che tutto sia attivo, che lo sia o meno.

In una vita precedente abbiamo usato uno strumento chiamato Firemon per fare questo. Firemon non esegue test fisici basati su host "reali / live" come quelli che stai descrivendo sopra, ma piuttosto analizza le regole del firewall e determina quali porte possono essere aperte.

Uno dei report che siamo riusciti a eseguire sarebbe stato determinare quali porte / protocolli sono permessi tra due host. Potresti anche ampliarlo per confrontare porte / protocolli tra due reti.

Ovviamente questo ti darebbe solo risultati validi se sai che non c'è modo per il tuo traffico del server di bypassare il tuo firewall. Ciò potrebbe richiedere una revisione dell'architettura di rete e quindi alcuni test di base del traffico per determinare il percorso dei pacchetti ecc.

Mettendo insieme alcuni di questi test potresti probabilmente ottenere ciò che stai cercando di fare senza effettuare la scansione su Internet. Non è un vero test fisico, ma ti darebbe un certo livello di sicurezza. (es .: non stai testando che il firewall non abbia perdite). È quindi possibile combinare questo con la registrazione da router e switch e guardare gli elenchi in una soluzione di tipo SIEM. IE: avvisa se l'host di ShouldNotHitInternetList comunica con un ip non locale.

Puoi iniziare a mettere insieme una serie di controlli che ti daranno la sicurezza di cui hai bisogno.

Quindi, una scansione SYN non mostrerà alcuna connessione basata su UDP, porte aperte, ecc., né farà nulla contro il tunneling ICMP. Ma torniamo alle origini qui. Hai un obiettivo, per impedire le connessioni, o piuttosto controllare quelle connessioni. Per questo, dovresti semplicemente controllare le regole FW per i principianti. Per es.

iptables -L -n 

Che mostrerà quali regole sono attualmente in esecuzione su una macchina. Se fossi in me, farei un diagramma completo (Visio). Quali server eseguono quali attività e quali regole firewall sono attualmente implementate su tali server. Corrispondono a ciò che ti serve / vuoi fare / viene fatto?

Io: installerei il syslog remoto (syslog-ng) con TUTTI i pacchetti / connessioni che vengono registrati, a cui posso aggiungere qualcosa come Splunk per l'analisi e l'avviso. Forse anche lanciando AlienVault per avvisarmi di anomalie, ecc. Non mi preoccuperei di scansionare veramente una volta verificate le regole fw, il mio obiettivo sarebbe quello di sapere / capire cosa sta arrivando e lasciare i miei server. Per quello, vorrei avere l'analisi del file di log (syslog remoto) e preferibilmente un SIEM.

Se fossi in me, la mia linea di difesa prima per un server co-localizzato sarebbe sul server stesso. Non ho accesso a tutti gli altri dispositivi coinvolti nello spostamento dei dati nel data center. Non ho il tempo di testare ogni cambiamento applicato nel data center (anche se gli operatori me lo hanno detto).

Ciò che descrivi può essere implementato in alcune regole di iptables senza stato, che offre una dimostrazione per induzione che il sistema si comporterà come definito. Sarei tentato di andare su un altro e assicurarmi che non ci sia alcuna route predefinita configurata sui dispositivi - solo per endpoint definiti in modo esplicito.