Sarebbe possibile apparire come se un server non esistesse? È possibile avere tutte le richieste che il nome host non possa essere risolto a meno che nella richiesta non sia stata fornita una frase specifica? Esistono prove dell'esistenza di un server che non possono essere nascoste dal proprietario del server? Ci sarebbe qualche ulteriore sicurezza pratica?
È possibile impostare il server in modo da eliminare normalmente tutti i pacchetti in ingresso e aprire una porta solo dopo aver ricevuto / visualizzato un set di pacchetti che specificano una sequenza specifica di porte (questo è chiamato bussare alla porta). Io uso questa tecnica con il mio server; normalmente non è possibile vedere il server perché cade tutti i pacchetti in entrata. Una volta che i pacchetti knock knock raggiungono il server, il server accetterà i pacchetti dall'indirizzo "knocking" ma continuerà a eliminare pacchetti da altri indirizzi.
La sicurezza è migliore con questo metodo, perché scansioni IP e tentativi di bruti non saranno un gran problema per voi. Per hackerare un server ci deve essere ricognizione, per scoprire quali servizi sono in esecuzione, che tipo di SO hai, ecc. Negando a un utente malintenzionato queste informazioni, rende più difficile per lui realizzare il suo attacco per il tuo dispositivo. La debolezza di questa difesa è che se un attaccante può vedere i pacchetti knocking in entrata, può quindi aprire anche quella porta.
Would it possible to appear as though a server doesn't exist ... unless a specific phrase was provided in the request?
La mia ipotesi è che tu stia parlando di HTTP (ad es. "web") e di una richiesta HTTP qui, sebbene tu non specifichi che tipo di richiesta intendi realmente. Nel caso di una richiesta HTTP tale nascondimento non è possibile perché HTTP è un protocollo applicativo su TCP. Ciò significa che il client deve prima stabilire una connessione TCP che implica una risposta dal server prima che il client invii anche i dati dell'applicazione (cioè la richiesta HTTP) e quindi l'esistenza del server HTTP viene rivelata indipendente dalla richiesta. / p>
Questo può essere diverso con altri protocolli. Ad esempio, il DNS (che risolve i nomi di host in indirizzi IP) viene solitamente gestito in UDP, che è senza connessione contraria a TCP. Ciò significa che la richiesta con il payload è il primo pacchetto inviato dal client. Pertanto, un server può essere creato con UDP che risponde solo se la richiesta DNS è per un dominio specifico e se si elimina qualsiasi altra richiesta. In questo modo il server rivelerebbe la sua esistenza solo se è stata inviata la richiesta corretta. Cose simili potrebbero essere fatte con SIP (telefonia su internet) che di solito viene fatto anche su UDP.
Is it possible to have all requests believe hostname could not be resolved ...?
La risoluzione di un nome host in un indirizzo IP viene eseguita anche prima di inviare la richiesta al server su questo indirizzo IP e in genere il server stesso non è nemmeno coinvolto in questo processo di risoluzione DNS. Ciò significa che anche con i protocolli senza connessione il client non riceve l'informazione che il nome non può essere risolto se la richiesta è sbagliata. Il massimo che otterrà il client è l'informazione che la destinazione non risponde e che potrebbe essere interpretata come nessun server è configurato su questo indirizzo IP o che il server è inattivo, protetto da un firewall o semplicemente facendo cadere pacchetti inaspettati.
Would it possible to appear as though a server doesn't exist?
Sì, anche se questo non è banale. Dipende dal comportamento dell'ISP quando un server non esiste. Alcuni ISP configurano i loro router per eliminare pacchetti quando l'IP che un pacchetto sta tentando di raggiungere non esiste, altri inviano un messaggio di pacchetti rifiutati al mittente. Inoltre, alcuni router hanno un comportamento adattivo e cambiano il loro comportamento se credono che possa essere sotto attacco. Alcuni ISP possono discriminare in base alla provenienza dei pacchetti di rilevamento (ad esempio i pacchetti provenienti da paesi / ISP che ospitano spesso clienti malintenzionati potrebbero essere trattati in modo più ostile rispetto a quelli con buone pratiche di rete).
Se si configura il server in modo da eliminare semplicemente tutti i pacchetti non riconosciuti, questo potrebbe effettivamente essere la prova dell'esistenza del server se il proprio ISP invia normalmente un messaggio di rifiuto. Se il router del tuo ISP modifica in modo adattativo il suo comportamento durante un periodo di attacco attivo e il tuo server non tiene il passo con ciò che sta facendo l'ISP, allora potrebbe essere in realtà una prova del server. Inoltre, il tuo ISP potrebbe avere il proprio ISP di backhaul, che potrebbe avere il proprio set di comportamenti.
Is it possible to have all requests believe host-name could not be resolved
Sì, non registrare i nomi degli host nel sistema DNS pubblico. I nomi host nel sistema DNS pubblico sono volutamente registrati in pubblico. Se è registrato nel DNS pubblico, chiunque può interrogare i record DNS per cercare l'indirizzo IP relativo al nome host. Puoi tuttavia definire nomi host riconosciuti solo dalle tue macchine (ad esempio, utilizzare il file hosts) o eseguire il tuo server DNS privato.
Is there some evidence of a servers existence that could not be hidden by the owner of the server?
Qualsiasi indirizzo IP pubblicamente instradabile ha un record di proprietà pubblica che può essere interrogato utilizzando lo strumento whois per scoprire chi è il tuo fornitore di servizi Internet. Il tuo ISP (o un avversario che compromette o collabora con il tuo ISP) può monitorare tutti i pacchetti che transitano attraverso la loro rete e può vedere i pacchetti in entrata senza un pacchetto in uscita precedente come prova di un server.
Would there be any practical added security?
Se in primo luogo si hanno delle cattive pratiche di sicurezza, allora essere invisibili può effettivamente allontanare molti robot dalla mente semplice e aggressori non sofisticati. Gli attaccanti più sofisticati possono trovare soluzioni per l'invisibilità. Se hai buone pratiche di sicurezza, utilizzando l'autenticazione e la crittografia avanzate, l'essere nascosto non conta molto in termini di sicurezza.
Probabilmente il posto migliore per nascondere una foglia è nasconderlo in un albero / foresta. Se si esegue un server noto pubblicamente e si cripta tutto il traffico verso il server (solo HTTPS), allora c'è poco che gli estranei possano fare per distinguere tra traffico verso il sito anteriore e traffico verso il sito nascosto. L'unica cosa che devi considerare è che TLS perde il nome host di destinazione nell'intestazione SNI. Finché non si falsifica l'intestazione SNI o se si utilizza il nome host del server anteriore, il server nascosto rimane nascosto.
Uso fwknop (" F ire W tutto KN ock OP erator ") verso le porte invisibili:
With fwknop deployed, anyone using nmap to look for SSHD can't even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit.
Funziona anche con % stealthing ssh porte dietro nat .
Se vuoi limitare l'accesso a un singolo ip puoi ottenere lo stesso effetto eseguendo iptables con un criterio di rifiuto predefinito ( iptables -P INPUT DROP ) & aggiungendo le regole di autorizzazione per specifici indirizzi di src ip:
iptables -A INPUT -i eth0 -p tcp -s 1.2.3.4 --dport 80 -j ACCEPT
C'è un altro modo per avere un server nascosto da internet, e questo è l'uso di un sito TOR Hidden. Questi server sono progettati solo per essere disponibili tramite la rete TOR e solo indirizzabili con un indirizzo TOR .onion.
In passato questi tipi di server nascosti sono stati utilizzati per una serie di motivi, come siti di censura, e-mail anonime, e in alcuni casi (come The Silk Road) i siti nascosti sono usati per vendere / acquistare oggetti illegali.
Se sei interessato, guarda qui: link
Come altri hanno sottolineato, questa tecnica è chiamata "port knocking".
Moxie Marlinspike ha creato uno strumento chiamato "knockknock" che fa esattamente questo.
Credo che la spiegazione su come funziona lo strumento è abbastanza buona per capire il concetto. Citando dalla sua pagina:
- Servers run the python app 'knockknock-daemon', and clients open ports on those servers by running the python app 'knockknock'
'knockknock-daemon' simply tails kern.log. It doesn't bind to any sockets, load libpcap and inspect every packet, or send anything onto the network at all.
When you want to open a port from a client, you run 'knockknock', which sends a single SYN packet to the server. The packet's IP and TCP headers are encoded to represent an IND-CCA secure encrypted request to open a specified port from the source IP address.
- Fields from this packet are logged to kern.log and processed by 'knockknock-daemon', which validates them.
- You connect from the client to the now-open port on the server.
- The port closes behind you and doesn't allow any new connections.
Leggi altre domande sui tag network