Come impostare iptables per eliminare i pacchetti su cui non ascolto?

Se non l'hai mai visto senza uno script, ecco uno script di base per te:

checkht="lsof -c httpd | awk '{print $1}' | uniq | grep h"

if [ -n "$checkht" ]; then

    echo "webserver is running let me shut down uptables rules blocking HTTP"
    iptables -vnL --line-numbers |awk '/tcp dpt:80/{print "iptables -D INPUT "$1}' | sh

else

   iptables -A INPUT -s 0.0.0.0/0 -p tcp --dport 80 -j DROP

fi

Controlla se HTTP è in esecuzione, se lo è, si assicura che IPTABLES non abbia regole che bloccano HTTP. Se non è in esecuzione, impedisce al mondo di raggiungere quella porta. Tuttavia, poiché non stai ascoltando sulla porta, la regola da bloccare non ha molto senso. Non c'è niente per chiunque da attaccare poiché niente è in esecuzione.

La risposta breve è: no di design , ed ecco un esempio di cosa dovrebbe succedere se fosse possibile:

1. netcat apre il socket sulla porta X chiamando il relativo syscall (come listen )
2. il kernel intercetta syscall, esegue il codice di rete (in questo caso, apre la porta)
Il kernel
3. parla al modulo iptables relativo (supponendo che sia disponibile e caricato) e apre un buco nel firewall per consentire al traffico di passare alla porta appena aperta.

Ciò aprirebbe un potenziale buco di sicurezza: come potrebbe il kernel sapere che il programma è legittimo, cioè non è un trojan che vuole aprire una shell remota? Ecco alcune risposte:

• Perché il programma è in whitelist da qualche parte; ma questo sposterebbe la sicurezza in un'altra serie di problemi:
  • come fai a sapere che il programma non è stato compromesso? Potresti usare qualcosa come tripwire, ma questo apre un'altra domanda di sicurezza: come puoi garantire che l'elenco principale non sia compromesso?
  • come gestisci gli aggiornamenti? Per esempio. la versione Z di ssh può perforare il firewall; il tuo sistema si auto-aggiorna, ora l'hash di ssh è cambiato e sei bloccato.
• Poiché l'utente che lo avvia appartiene a un gruppo privilegiato: come gestisci i binari SUID? Dai un'occhiata alle autorizzazioni del programma ping , ad esempio.

Un'altra possibilità di worm ^ W ^ W ^ W set di potenziali problemi sarebbe l'interfaccia tra iptables (a livello di kernel) e syscalls; ogni piccola modifica in iptables richiederebbe una potenziale riscrittura del codice sottostante alle syscalls, introducendo bug, ecc.

In breve, stai descrivendo il problema che i firewall delle applicazioni affrontano (pensa ai firewall Windows o Mac). È fattibile, ma non è semplice.

A livello di rete si potrebbe voler dare un'occhiata a UPnP la cui funzione era quella di consentire ai servizi di eseguire fori attraverso il firewall di un gateway. Con le ovvie conseguenze sulla sicurezza.

Oppure potresti usare uno script invece:)

potresti scrivere un semplice script bash che analizza l'output di netcat e crea di conseguenza un nuovo set di regole iptables ogni volta che è in esecuzione.

Probabilmente devi assicurarti di consentire le connessioni prima di impostare la regola cancella tutte, altrimenti ripristineresti tutte le connessioni in esecuzione ogni volta che viene eseguito lo script.

Quindi potresti impostare un cronjob che eseguirà il tuo script ogni minuto.

Come ha sottolineato Lorenzog, questa potrebbe non essere la configurazione più sicura, d'altra parte se non hai iptables in esecuzione di default allora questo è probabilmente meglio di niente.

Inoltre puoi impostare un intervallo di porte come whitelist e ignorare tutte le altre porte che netstat sputa ...

Dato che si tratta della tua casella Kali (VM?), dovrebbe comunque funzionare solo per attività specifiche. Kali non è pensato per essere utilizzato come sistema operativo client / server predefinito per le attività quotidiane. Quindi ti lascerò andare via con questo tipo di configurazione dinamica del firewall;)