Domanda:
Puoi nascondere l'esistenza di un server su Internet?
Goose
2016-12-31 04:08:28 UTC
view on stackexchange narkive permalink

È possibile apparire come se un server non esistesse? È possibile fare in modo che tutte le richieste credano che il nome host non possa essere risolto a meno che non sia stata fornita una frase specifica nella richiesta? Esistono prove dell'esistenza di un server che non possono essere nascoste dal proprietario del server? Ci sarebbe una maggiore sicurezza pratica?

non controlli il nome host in particolare, quindi non in quella parte, ma l'idea generale di ciò che chiedi è possibile con software / hardware personalizzato.devi stare attento a non "sbagliare" qualcosa come quasi tutto ciò che vuole fare per impostazione predefinita.
Potresti chiudere completamente un server web fino a quando una stringa segreta non viene inviata a una porta specifica.Tuttavia le persone sarebbero comunque in grado di sapere che c'è qualcosa lì. Puoi avvicinarti molto alla configurazione di un web server oscuro.
Avere un server su una LAN trasporta dati con un server locale rivolto verso la DMZ soddisferebbe la tua risposta?Tecnicamente esiste un server che a un certo punto sarà esposto, ma non esporrà il server dati effettivo se non possono interfacciarsi direttamente con esso.Questa è in realtà una configurazione molto comune.Il server di applicazioni Web di IE è rivolto verso DMZ e il server SQL no.Tipicamente con i trasporti dettati da un firewall.
Sette risposte:
#1
+82
JShade01
2016-12-31 04:16:17 UTC
view on stackexchange narkive permalink

Puoi impostare il tuo server in modo che normalmente elimini tutti i pacchetti in entrata e apra una porta solo dopo aver ricevuto / visto un insieme di pacchetti che specificano una sequenza specifica di porte (questo è chiamato port knocking). Uso questa tecnica con il mio server; normalmente non puoi vedere il server perché rilascia tutti i pacchetti in arrivo. Una volta che i pacchetti di knocking della porta raggiungono il server, il server accetterà i pacchetti dall'indirizzo 'knocking' ma continuerà a rilasciare pacchetti da altri indirizzi.

La sicurezza è migliore con questo metodo perché le scansioni IP e i bruti tentati hanno vinto non sarà un grosso problema per te. Per hackerare un server deve essere eseguita una ricognizione, per scoprire quali servizi sono in esecuzione, che tipo di sistema operativo hai, ecc. Negando a un utente malintenzionato queste informazioni, diventa più difficile per lui creare il suo attacco per il tuo dispositivo. Il punto debole di questa difesa è che se un utente malintenzionato può vedere i pacchetti knocking in arrivo, può aprire anche quella porta.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/51070/discussion-on-answer-by-jshade01-can-you-hide-a-servers-existence-on-the-stagista).
Ma dovrebbe essere possibile avere un'unica porta UDP in ascolto, dove è necessario inviare un singolo pacchetto UDP contenente l'ora corrente, firmato con la propria chiave privata.- il server apre una connessione tcp solo se la firma viene verificata e l'ora non è più vecchia di 3 secondi non è stata utilizzata prima.- poiché il server non risponderà affatto al pacchetto, è ancora completamente inesistente finché non invii il "knock firmato"
@Falco Dovresti aggiungere alcune altre informazioni, poiché con lo schema che hai descritto sarebbe facile per un attaccante MITM sostituire semplicemente l'indirizzo di origine con il proprio.A causa della natura dell'UDP, potrebbero non essere nemmeno costretti a bloccare il pacchetto originale se quello che falsificano raggiunge per primo il server.
@user buon punto: la firma dovrebbe includere l'indirizzo e la porta di origine.
#2
+17
Steffen Ullrich
2016-12-31 04:30:35 UTC
view on stackexchange narkive permalink

Sarebbe possibile apparire come se un server non esistesse ... a meno che non fosse fornita una frase specifica nella richiesta?

La mia ipotesi è che tu stia parlando di HTTP (cioè "web") e di una richiesta HTTP qui anche se non specifichi che tipo di richiesta intendi effettivamente. In caso di una richiesta HTTP tale occultamento 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 indipendentemente dalla richiesta.

Questo può essere diverso con altri protocolli. Ad esempio, il DNS (risoluzione dei nomi host in un indirizzo IP) viene solitamente gestito in UDP che è senza connessione contrariamente a TCP. Ciò significa che la richiesta con il payload è il primo pacchetto inviato dal client. Pertanto, è possibile creare un server con UDP che risponde solo se la richiesta DNS è per un dominio specifico e rilascia qualsiasi altra richiesta. In questo modo il server rivelerebbe la sua esistenza solo se fosse stata inviata la richiesta appropriata. Cose simili potrebbero essere fatte con SIP (telefonia su Internet) che di solito viene fatto anche su UDP.

È possibile che tutte le richieste credano che il nome host non possa essere risolto ...?

La risoluzione di un nome host in un indirizzo IP viene eseguita prima ancora di inviare la richiesta al server su questo indirizzo IP e di solito 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 era sbagliata. Il massimo che il client otterrà sono le informazioni che il target non risponde, il che potrebbe essere interpretato che nessun server è impostato su questo indirizzo IP o che il server è inattivo, protetto da un firewall o semplicemente che rilascia pacchetti imprevisti.

Se si utilizza TCP Fast Open, i client possono iniziare a inviare il primo pacchetto di dati (con l'intestazione GET) insieme all'handshake TCP nel primo pacchetto.Se è necessario crittografare, TLS False Start + TLS 1.3 potrebbe consentire di inviare pacchetti crittografati insieme all'handshake TCP e TLS.In teoria, dovrebbe essere possibile fare in modo che il primo pacchetto contenga sempre la stringa knocking nelle intestazioni HTTP.
@LieRyan: TCP Fast Open è solo per le riconnessioni perché deve utilizzare un "cookie" da una connessione precedente.TLS 0-RTT simile funziona solo quando si riprende una sessione.Ciò significa che il server deve comunque rispondere al normale traffico TCP e TLS in modo da ottenere la condizione preliminare per l'utilizzo di Fast Open e 0-RTT TLS.E questo significa che il server non può essere nascosto in questo modo con TCP e TLS.
dovrebbe essere possibile configurare il client e il server in modo che il server conservi cookie / ticket di ripresa validi più a lungo di quanto non facciano per impostazione predefinita o addirittura non faccia scadere mai i cookie / ticket.Con una piccola modifica allo stack di rete del client, dovrebbe anche essere possibile consentire al client di avere la chiave del server Fast Open in modo che il client possa generare il proprio cookie.
@LieRyan: ovviamente, se hai la possibilità di cambiare lo stack di rete sia sul client che sul server puoi fare quasi tutto, come avviare ogni connessione con il port knocking.Ma non penso che questo conti ancora come "nascondi ... a meno che non sia stata fornita una frase specifica nella richiesta" perché questaèmolto di più di una semplice frase speciale nella richiesta: è uno stack di rete modificato sia sul client che sul serveranziché.
#3
+4
Lie Ryan
2016-12-31 22:07:03 UTC
view on stackexchange narkive permalink

È possibile apparire come se un server non esistesse?

Sì, anche se questo non è banale. Dipende dal comportamento del tuo ISP quando un server non esiste. Alcuni ISP configurano i loro router per eliminare i pacchetti quando l'IP che un pacchetto sta cercando di raggiungere non esiste, altri inviano un messaggio di rifiuto dei pacchetti al mittente. Inoltre, alcuni router hanno un comportamento adattivo e cambiano il loro comportamento se ritiene che possa essere sotto attacco. Alcuni ISP possono discriminare in base alla provenienza dei pacchetti di sondaggio (ad esempio, i pacchetti provenienti da paesi / ISP che spesso ospitano clienti dannosi possono essere trattati in modo più ostile di quelli con buone pratiche di rete).

Se configuri il tuo server per eliminare semplicemente tutti i pacchetti non riconosciuti, che potrebbe effettivamente essere la prova dell'esistenza del server se il tuo ISP normalmente invia un messaggio di rifiuto. Se il router del tuo ISP cambia in modo adattivo 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 effettivamente una prova del server. Inoltre, il tuo ISP potrebbe avere il proprio ISP di backhaul, che potrebbe avere una propria serie di comportamenti.

È possibile che tutte le richieste credano che il nome host non possa essere risolto

Sì, semplicemente non registrare i tuoi nomi host nel sistema DNS pubblico. I nomi host nel sistema DNS pubblico sono intenzionalmente record pubblici. Se è registrato nel DNS pubblico, chiunque può interrogare i record DNS per cercare l'indirizzo IP relativo al nome host. Tuttavia, puoi definire nomi host che siano riconosciuti solo dalle tue macchine (ad esempio, utilizzare il file hosts) o eseguire il tuo server DNS privato.

Ci sono prove dell'esistenza di un server che non può essere nascosto dal proprietario del server?

Qualsiasi indirizzo IP instradabile pubblicamente ha un record di proprietà pubblica che può essere interrogato utilizzando lo strumento whois per scoprire chi è il tuo provider di servizi Internet. Il tuo ISP (o un avversario che compromette o lavora con il tuo ISP) può monitorare tutti i pacchetti che passano attraverso la loro rete e possono vedere quei pacchetti in entrata senza un precedente pacchetto in uscita come prova di un server.

Ci sarebbe una sicurezza aggiuntiva pratica?

Se si adottano pratiche di sicurezza scadenti in primo luogo, essere invisibili può effettivamente allontanare molti bot ingenui e aggressori non sofisticati. Gli aggressori più sofisticati possono trovare modi per aggirare l'invisibilità. Se hai buone pratiche di sicurezza, utilizzando una forte autenticazione e crittografia, essere nascosti non ha molta importanza in termini di sicurezza.

Probabilmente il posto migliore per nascondere una foglia è nasconderla in un albero / foresta . Se si esegue un server noto pubblicamente e si crittografa tutto il traffico al server (solo HTTPS), gli estranei possono fare ben poco per distinguere tra il traffico verso il sito principale e il traffico verso il sito nascosto. L'unica cosa che devi considerare è che TLS perde il nome host di destinazione nell'intestazione SNI. Finché si falsifica l'intestazione SNI o si utilizza il nome host del server anteriore, il server nascosto rimarrà nascosto.

#4
+3
Stuart Cardall
2017-01-01 02:34:14 UTC
view on stackexchange narkive permalink

Uso fwknop (" F ire W all KN ock OP erator ") alle porte stealth:

Con fwknop distribuito, chiunque utilizzi nmap per cercare SSHD non può nemmeno dire che sta ascoltando - non fa differenza se vogliono eseguire un cracker di password contro SSHD o anche se hanno un exploit 0-day.

Funziona anche per furtivamente le porte ssh dietro nat .

Se desideri limitare l'accesso a un singolo ip puoi ottenere lo stesso effetto eseguendo iptables con un criterio di negazione predefinito ( iptables -P INPUT DROP ) & aggiunge regole di autorizzazione per indirizzi ip src specifici:

iptables - A INPUT -i eth0 -p tcp -s 1.2.3.4 --dport 80 -j ACCETTA

#5
+2
Paolo
2017-01-01 00:27:10 UTC
view on stackexchange narkive permalink
  • prima domanda: un po 'ma non proprio. Puoi rifiutare tutti i pacchetti in entrata ma quelli che ti piacciono ma la connessione riuscita è "visibile" (vedi terzo punto)
  • seconda domanda: no. La risoluzione DNS non gestisce la stringa di query della richiesta, quindi non puoi usarla come filtro
  • terza domanda: sì, il traffico da e verso il server non può essere nascosto ai router e / o proxy tra sorgente e destinazione in modo che l'esistenza di quel server sia nota e non possa essere nascosta (se non sei su una darknet)
  • quarta domanda: forse può essere usata come un livello aggiuntivo ma devono essere in atto saggezza e misure convenzionali comunque
#6
+2
Nik Roby
2017-01-01 11:43:36 UTC
view on stackexchange narkive permalink

C'è un altro modo per avere un server nascosto da Internet, e questo è l'uso di un sito TOR Hidden. Questi server sono progettati per essere disponibili solo tramite la rete TOR e indirizzabili solo con un indirizzo TOR .onion.

In passato questo tipo di server nascosti è stato utilizzato per una serie di motivi come siti anti-censura, e-mail anonime e in alcuni casi (come The Silk Road) i siti nascosti vengono utilizzati per vendere acquista articoli illegali.

Se sei interessato, guarda qui: https://www.torproject.org/docs/tor-hidden-service.html.en

I servizi nascosti non ne nascondono l'esistenza, anzi farebbe esattamente l'opposto e lo confermerebbe tramite i server di directory.* Nasconderebbe * la sua posizione.
#7
+1
Acapulco
2017-01-01 02:47:35 UTC
view on stackexchange narkive permalink

Come altri hanno sottolineato, questa tecnica è chiamata "port knocking".

Moxie Marlinspike ha creato uno strumento chiamato "knockknock" (ultimo aggiornamento 2012) che fa precisamente questo.

Credo che la spiegazione su come funziona lo strumento sia abbastanza buona per comprendere il concetto. Citando dalla sua pagina:

  • I server eseguono l'app python "knockknock-daemon" e i client aprono le porte su quei server eseguendo l'app python "knockknock"

  • "knockknock-daemon" semplicemente accoda kern.log. Non si lega a nessun socket, carica libpcap e ispeziona ogni pacchetto, né invia nulla alla rete.

  • Quando vuoi aprire una porta da un client, eseguire "knockknock", che invia un singolo pacchetto SYN al server. L'IP del pacchetto e le intestazioni TCP sono codificati per rappresentare una richiesta crittografata sicura IND-CCA per aprire una porta specificata dall'indirizzo IP di origine.

  • I campi di questo pacchetto vengono registrati in kern.log ed elaborati da "knockknock-daemon", che li convalida.

  • Ti connetti dal client alla porta ora aperta sul server.

  • La porta si chiude dietro di te e non consente nuove connessioni.



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...