[Windows] Il comando netstat: come interpretare le connessioni

Analizziamo oggi il comando netstat, uno dei principali comandi per fare troubleshooting delle reti in ambiente Windows e per controllare quali connessioni sono stabilite.

Vediamo i 5 casi di utilizzo più importanti e da tenere sott’occhio.

1 – Lista connessioni e porte in ascolto: netstat -an

Questo è il caso più semplice di utilizzo del comando che elenca tutte le connessioni comprese quelle attive (stato ESTABLISHED), e quelle con una porta in ascolto (stato LISTENING). L’opzione n non è essenziale, ma è secondo me utile perché effettua un DNS lookup andando a mostrare indirizzo IP al posto di ogni hostname. I possibili stati in cui una connessione può trovarsi sono quelli mostrati nella tabella seguente.

Stato Descrizione
CLOSED Indica che il server ha ricevuto dal client un messaggio ACK e la connessione è chiusa.
CLOSE_WAIT Indica che il server ha ricevuto dal client il primo FIN e la connessione è in fase di chiusura.
ESTABLISHED Indica che il server ha ricevuto dal client un SYN e la sessione è stata stabilita.
FIN_WAIT_1 Indica che la connessione è ancora attiva ma al momento non è usata e verrà chiusa.
FIN_WAIT_2 Indica che il client ha ricevuto l’ACK del server, dopo che il server ha ricevuto il primo FIN dal client.
LAST_ACK Indica che il server sta per inviare il proprio messaggio FYN.
LISTENING Indica che il server è in ascolto e pronto ad accettare una nuova connessione.
SYN_RECEIVED Indica che il server ha ricevuto il SYN inviato dal client.
SYN_SEND Indica che la connessione è attiva.
TIME_WAIT Indica che la connessione è in fase di chiusura, ma è ancora attiva.
screen_netstat1

netstat -an

Tutti zero nella colonna “Foreign” significa che ancora non ci sono indirizzi remoti, e pertanto la linea rappresenta un servizio in ascolto. Nel momento in cui un servizio riceve una connessione in ingresso, allora verrà stabilita una nuova connessione e dunque verrà mostrata una linea specifica all’interno della lista di connessioni.

Su questo sito si trova un’ottima spiegazione degli stadi e delle transizioni nel protocollo TCP, e il diagramma mostrato è veramente ben fatto:

TCP-StateTransitionDiagram-NormalTransitions

2 – Fully qualified domain name: netstat -f

Con questo parametro il comando mostra il nome intero (FQDN) di ogni indirizzo IP, risolvendolo internamente o se possibile esternamente.

netstat -f

netstat -f

3 – Tabella di routing: netstat -r

L’opzione permette di mostrare la tabella di routing del sistema, ed è l’analogo del comando route print.

netstat -r

netstat -r

4 – Processo per ogni porta: netstat -aon oppure nestat -b

In questo modo per ogni porta aperta nel sistema vengono elencati lo stato e l’identificativo del processo (PID) che ha aperto la porta. L’opzione b è migliore perché mostra direttamente l’eseguibile del processo in esecuzione ma richiede i permessi di amministratore per poter essere eseguita.

netstat -aon

netstat -aon

5 – Statistiche di rete: netstat -s -p IP

Mostra le statistiche di rete relative al livello 3, ossia IP. E’ possibile in questo modo vedere eventuali errori o problemi di connessione.

netstat -s -p IP

netstat -s -p IP

Sono utili anche la possibilità di mantenere la lista aggiornata ad un certo intervallo (ad esempio ogni 5 secondi):

nestat -an 5

e quella di salvare l’output del comando in un file:

netstat -an >> C:\connections_list.txt

Matteo

[Hacking/sicurezza] Nella tua rete Tor è bloccato? Bypassiamo il blocco!

Vediamo oggi come usare Tor in presenza di sistemi/reti/ISP che ne bloccano il suo funzionamento. Innanzitutto Tor è un software appartenente alla categoria PET (Privacy Enhaced Technology), che permette di navigare in modo anonimo sul web e di “anonimizzare” una grande quantità di servizi distribuiti (chat, torrent, …).
Il suo utilizzo principale è quello di permettere la consultazione di pagine web e la fruizione di Internet senza vincoli in quei luoghi in cui sono in vigore restrizioni politiche o censure di vario genere. Tuttavia, Tor viene usato piuttosto comunemente anche per bypassare le restrizioni aziendali e poter così navigare su siti “proibiti” perché bloccati dal proxy e/o firewall aziendale. Non è raro, purtroppo, che venga usato esclusivamente per navigare su Facebook o su altri social network durante l’orario di lavoro. Per carità, Tor può essere usato anche per navigare su Facebook, ma i suoi intenti sono ben più nobili!

In ogni caso molte aziende, enti, e organizzazioni, stanno cercando da tempo meccanismi per intercettare e bloccare l’utilizzo di Tor, configurando ACL sui firewall e filtri sui proxy. Inoltre, in alcuni casi ad essere bloccato è anche l’accesso al sito di Tor, in modo da impedire il download del software e la ricerca di documentazione. Bloccare la connessione alla rete Tor non è impossibile, perché viene resa pubblica una lista dei nodi della rete Tor, aggiornata costantemente. La lista è reperibile a questi link:

Tale lista potrebbe essere usata per configurare un proxy (squid ad esempio) in modo da bloccare tutte le connessioni uscenti dirette ad uno degli IP delle lista. Il risultato di un tale blocco (vedere lo screenshot sotto) è che l’utente con il client Tor sarà impossibilitato a collegarsi alla rete Tor, e pertanto al resto della Rete.

tor_blocked

Tor bloccato dalla rete/ISP

Veniamo adesso al reale argomento del post :-): come possiamo fare se la nostra rete/ISP blocca la connessione a Tor? Quello che possiamo fare è ricorrere ad alcune contromisure in grado di bypassare il blocco imposto, garantendo anonimato e privacy, e accesso a tutte le funzionalità di Tor. Può capitare anche che venga bloccata la visualizzazione del sito del progetto Tor, ma in questo caso è possibile facilmente usare un proxy web gratuito per poter visitare il sito (esempi di proxy gratuiti sono www.hidemyass.com e zendproxy.com).

Dunque, se non ci è possibile usare Tor poiché la connessione si blocca dopo aver avviato il software, è possibile agire in 2 modi:

  1. usare obfsproxy;
  2. agire sulla configurazione di Tor.

OPZIONE 1 

Per la prima opzione, è necessario scaricare il software obfsproxy al seguente link:

obfsproxy è un software basato su Tor (è praticamente Tor a tutti gli effetti), ma in via sperimentale e con i bundle al momento non più aggiornati. Il software permette di mascherare i pacchetti inviati alla rete Tor, facendoli sembrare pacchetti “innocenti” (ad esempio semplice pacchetti HTTP) come è visibile in figura.

obfsproxy_diagram

Diagramma di funzionamento di obfsproxy

L’interfaccia e l’utilizzo di obfsproxy sono gli stessi di Tor, mentre a cambiare è la configurazione del software, come si vede in figura.

tor_obfsproxy

obfsproxy

OPZIONE 2 

In questo caso non sono necessari software aggiuntivi ma dobbiamo agire su alcuni parametri di Tor per poter aggirare i blocchi imposti da rete/ISP. I parametri da configurare sono modificabili direttamente dall’interfaccia Vidalia, e si trovano in Settings->Network come visibile in figura.

tor_settings_network

Parametri configurabili di Tor per aggirare i blocchi

Fra questi, il metodo più efficace e affidabile è quello di usare un bridge Tor, ossia la terza possibilità “My ISP blocks connections to the Tor network”. Vediamo comunque in dettaglio le 3 possibilità.

Opzione – “My ISP blocks connections to the Tor network”

Con questa opzione possono essere configurati i bridge Tor. Un bridge Tor è fondamentalmente un nodo della rete Tor che agisce da ponte (similmente a un proxy) per il collegamento tra client/utente e rete Tor. I bridge hanno la particolarità di non essere elencati nelle liste pubbliche di nodi Tor (come visto precedentemente), e pertanto difficilmente saranno rilevati e bloccati dagli amministratori di rete. Per conoscere i bridge disponibili in ogni momento, dobbiamo visitare il seguente link:

Dopo aver trovato i bridge Tor disponibili, è necessario configurarli in Setting->Network, come visibile nella figura seguente.

Add_bridge_to_Tor

Aggiunta di un bridge Tor.

In alternativa, è possibile creare un proprio bridge privato, se abbiamo a disposizione un server o un pc con connessione flat (ad esempio nella propria abitazione), e collegarsi ad esso quando siamo fuori e in una rete in cui Tor è bloccato. Per creare un bridge privato è sufficiente avviare Tor sulla macchina che fungerà da bridge, e selezionare in Settings->Sharing la voce “Help censored users reach the Tor network“, come visibile in figura.

Tor_setting_bridge

Configurazione di un bridge Tor privato.

Opzione – “I use a proxy to access the Internet”

Nel caso in cui la propria rete o il proprio ISP blocchi anche i bridge Tor, è possibile ricorrere all’uso di un proxy. Tramite un proxy i pacchetti uscenti dal proprio sistema, e quindi dal client Tor, sono indirizzati al proxy stesso e non alla rete Tor, e in questo modo viene oltrepassato il blocco imposto dalla rete/ISP. Nella figura sottostante è mostrato il collegamento attraverso un proxy.

tor.e.proxy.visio

Connessione a Tor attraverso un proxy.

Per questa soluzione il punto cruciale è la scelta di un proxy adeguato, che dovrà essere sicuro e affidabile, e supportare inoltre sia il protocollo HTTP che il quello HTTPS. Per ricercare un proxy possiamo usare questa lista (oppure cercare altre liste di proxy semplicemente con google), controllando che il proxy supporti HTTPS, sia di tipo anonymous, e abbia una buona affidabilità. Dopo aver scelto un proxy, dobbiamo controllare che sia attivo e supporti realmente sia HTTP che HTTPS. Quindi configuriamo Tor con le impostazioni del proxy, come visibile nella figura sotto.

Tor_setting_proxy

Configurazione di un proxy in Tor.

Per configurare il proxy sono necessari:

  1. indirizzo IP o hostname del proxy;
  2. porta utilizzata dal proxy;
  3. eventuali username/password se il proxy richiede l’autenticazione.

Questa soluzione è più tediosa rispetto all’utilizzo di un bridge, poiché i proxy open non offrono solitamente grandi garanzie e spesso le performance non sono eccelse. Difatti un proxy potrebbe non essere più attivo nel giro di poche ore o giorni, costringendoci a cercarne e configurarne un altro.

Opzione – “My firewall only lets me connect to certain ports”

L’ultima opzione configurabile deve essere utilizzata solo quando abbiamo la certezza che il firewall della nostra rete blocchi verso l’esterno alcune porte (in genere ad essere bloccate solo le porte esterno per connessioni verso l’interno). In questo caso è possibile selezionare la voce e specificare le porte che sono aperte sul firewall. La connessione alla rete Tor passerà dunque per le porte specificate.

Riepilogando, in questa piccola guida abbiamo visto come sia possibile usare Tor praticamente in ogni situazione, anche quando sono stati creati filtri ad hoc dagli amministratori/provider nel vano tentativo di limitare la libertà e la privacy personale.

“Per ogni blocco esiste sempre una contromisura, basta trovarla o idearla!”

Matteo

[Programmazione][Java] JaXy, un proxy HTTP in Java

Rendo disponibile per il download un proxy HTTP che ho scritto in Java.

Il proxy effettua le operazioni base di un proxy, supportando il protocollo HTTP 1.1 e rispettando l’RFC 2616:

  1. il client (browser) richiede una risorsa (URL);
  2. il proxy intercetta la richiesta;
  3. il proxy controlla la propria memoria cache per vedere se può rispondere al client direttamente oppure se deve richiedere la risorsa (URL) al server finale;
  4. il server finale risponde al proxy;
  5. il proxy aggiorna la propria memoria cache con la risposta del server;
  6. il proxy crea un nuovo pacchetto ed invia la risposta al client.

Nella figura seguente è mostrata la logica del funzionamento di un proxy HTTP.

HTTP_Proxy_architecture

Funzionamento di un proxy HTTP

Da Wikipedia: “In computer networks, a proxy server is a server (a computer system or an application) that acts as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service, such as a file, connection, web page, or other resource available from a different server. The proxy server evaluates the request as a way to simplify and control their complexity.

L’applicazione non è una servlet ma è un server stand-alone, dunque non necessita di servlet engine o container (come Tomcat).

L’applicazione si chiama JaXy, abbreviazione di Java Proxy, ed è scaricabile e utilizzabile secondo la licenza GPLv3 al seguente link:

JaXy-v0.1.tar.gz – Initial release (2012-06-20):

  • supporto per HTTP 1.1, secondo le specifiche dell’RFC 2616
  • interfaccia semplice a linea di comando
  • supporto per IPv4

Matteo

[GNU/Linux] Script per modificare MAC address

Ho scritto uno script bash che permette in Linux di manipolare l’indirizzo MAC di una scheda di rete, la cui operazione in gergo viene detta spoofing. Lo script può essere usato su tutte le principali distribuzioni e permette di cambiare l’indirizzo MAC con uno generato casualmente oppure con uno indicato dall’utente. Le istruzioni per eseguire lo script sono le seguenti:

Usage: macs.sh [OPTIONS]
Spoof your wired or wireless network adapter with a new MAC address.
Options:
-r <interface>: spoof an interface with a random MAC address
-s <interface> <address>: spoof an interface with a new MAC address
-o <interface>: restore an interface with the original MAC address
-v <interface>: show the MAC address and the vendor of an interface
-p <vendor>: show the MAC prefix of a vendor
-a: show the MAC address of every network interface
-h: show this help

—————————————————————-
Examples:
sh macs.sh -r eth0
sh macs.sh -s wlan1 001122334455
sh macs.sh -s eth3 00:1C:39:FB:6C:88
sh macs.sh -o eth0
sh macs.sh -p IBM
sh macs.sh -p Microsoft

Tra le funzionalità vi è anche quella di visualizzare il vendor della scheda di rete, e tutti i prefissi MAC proprietari di uno specifico vendor.

Si tratta di uno script bash, dunque deve essere lanciato con l’interprete sh e con i privilegi di root. Vediamo alcuni esempi:

# sh macs.sh -r eth1 modifica l’indirizzo dell’interfaccia eth1 con uno random
# sh macs.sh -s eth1 00:0C:29:FB:6C:4B modifica l’indirizzo di eth1 con 00:0C:29:FB:6C:4B
# sh macs.sh -o eth3 ripristina l’indirizzo MAC reale di eth3
# sh macs.sh -v eth2 visualizza l’indirizzo MAC e vendor di eth2
# sh macs.sh -a visualizza gli indirizzi MAC e vendor di tutte
# sh macs.sh -p Microsoft visualizza i prefissi MAC proprietari Microsoft

Lo script è rilasciato con licenza GNU GPL v3, ed è scaricabile a questi link:

Matteo

[Reti] Come risolvere i problemi di connessione – parte 1

Spesso capita che la rete non funzioni, e ci chiediamo quale e dove possa essere il problema. E’ il nostro sistema che non va? E’ il server che non risponde? E’ la trasmissione che non funziona? Insomma ci sono sempre tante domande e non sempre è immediato trovare la risposta, e finiamo per cambiare parametri e impostazioni nel tentativo di ripristinare la connessione! Gli utenti più inesperti poi finisco per installare svariati tipi di software che promettono di ripristinare la connessione e di sistemare tutto, come questo Connectivity fixer. Non ci sono programmi più inutili e magari dannosi (chi ha detto spyware?! Io no ;-)…).

Internet connection problem

Questo post rappresenta invece la prima parte di un altro post che avevo scritto qualche tempo fa, in cui spiegavo come fare troubleshooting della rete e verificare il collegamento ad Internet. In questo articolo invece esaminiamo il problema partendo dalla connessione alla rete locale, e senza far uso di risoluzioni DNS.

Prendiamo come esempio l’architettura di rete visibile in figura, e supponiamo di essere il sistema Bob con indirizzo IP 172.17.10.3 e di voler contattare la macchina Server con indirizzo 172.17.30.2. Nell’immagine non ho specificato le subnet per semplificare il tutto e renderlo fruibile anche a chi può avere meno conoscenze informatiche, comunque possiamo assumere che la subnet sia /24, uguale per ogni indirizzo.

diagramma_rete

Diagramma di rete

Come è visibile dal grafico si tratta di una piccola rete, tuttavia il problema può facilmente essere esteso ad una rete molto più grande come anche ad Internet (semplicemente non ci sarà un solo router tra sorgente e destinazione ma una serie di N dispositivi, come backbone, …). Vediamo i passi da fare per controllare il funzionamento della rete dal punto di vista di Bob:

  1. Test del loopback. Apriamo un terminale (prompt cmd in Windows, shell in Linux e MacOS) e facciamo ping verso 127.0.0.1.
    $ ping 127.0.0.1
    PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.773 ms
    64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.125 ms
    64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.080 ms
    64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.083 ms
    --- 127.0.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.080/0.265/0.773/0.293 ms

    Questo è l’indirizzo di loopback e se il risultato è positivo significa che lo stack TCP/IP è stato inizializzato correttamente. In caso invece di fallimento il servizio che gestisce lo stack TCP/IP deve essere ripristinato all’interno del sistema operativo. Per effettuare il ripristino dello stack in Windows è possibile consultare questo link, mentre per Linux quest’altro.

  2. Test della scheda di rete. Adesso facciamo ping verso l’indirizzo IP del sistema locale, nell’esempio 172.17.10.3.
    $ ping 172.17.10.3
    PING 172.17.10.3 (172.17.10.3) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.111 ms
    64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.079 ms
    64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.080 ms
    64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.078 ms
    --- 127.0.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.078/0.087/0.111/0.013 ms

    Se con il ping vengono ricevute le risposte significa che la NIC funziona correttamente così come i driver/moduli di sistema, ma ciò non indica che la rete è esente da problemi quali cavi rotti o collegamenti interrotti. Un esito invece negativo potrebbe essere indice di scheda di rete guasta o di driver/moduli non installati correttamente. Provate a riavviare il sistema e, su Windows, a reinstallare i driver, mentre su Linux ad aggiornare il kernel e riavviare moduli e servizi secondo le istruzioni a questo link.

  3. Test del gateway. Ora è in turno del gateway/router. Effettuate il ping verso il default gateway per testare la comunicazione nella rete locale, nell’esempio 172.17.10.1.
    $ ping 172.17.10.1
    PING 172.17.10.1 (172.17.10.1) 56(84) bytes of data.
    64 bytes from 192.168.139.2: icmp_req=1 ttl=128 time=0.255 ms
    64 bytes from 192.168.139.2: icmp_req=2 ttl=128 time=0.237 ms
    64 bytes from 192.168.139.2: icmp_req=3 ttl=128 time=0.241 ms
    64 bytes from 192.168.139.2: icmp_req=4 ttl=128 time=0.219 ms
    --- 192.168.139.2 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3004ms
    rtt min/avg/max/mdev = 0.219/0.238/0.255/0.012 ms

    Un esito negativo significa che c’è un problema o nella trasmissione dei dati (cavo rotto/scollegato), o nel default gateway che non è in grado di elaborare le richieste, oppure un blocco delle richieste da parte di un firewall o altro dispositivo interconnesso tra Bob e il default gateway (switch, hub, AP, …).

  4. Test del server remoto. Infine, se tutti i 3 punti precedenti hanno avuto esito positivo, testiamo la connessione verso il server remoto, nel nostro esempio  172.17.30.2.
    $ ping 172.17.30.2
    PING 172.17.30.2 (172.17.30.2) 56(84) bytes of data.
    64 bytes from 172.20.0.1: icmp_req=1 ttl=128 time=1.46 ms
    64 bytes from 172.20.0.1: icmp_req=2 ttl=128 time=0.913 ms
    64 bytes from 172.20.0.1: icmp_req=3 ttl=128 time=2.40 ms
    64 bytes from 172.20.0.1: icmp_req=4 ttl=128 time=0.714 ms
    --- 172.20.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3005ms
    rtt min/avg/max/mdev = 0.714/1.375/2.407/0.657 ms

    Se l’esito è negativo significa che il problema è da ricercarsi nella rete remota. Inoltre, nel caso in cui sia possibile raggiungere la rete remota con il ping, sarebbe ideale poter replicare i test partendo dal server remoto verso il sistema sorgente.

Nel caso di connessione a Internet (e non locale) anche se tutti e 4 i punti hanno avuto esito positivo la comunicazione potrebbe non funzionare. In questo caso il problema potrebbe essere il servizio DNS, e rimando alla seconda parte dell’articolo.

Matteo

[Reti] Vantaggi di uno switch layer 2/3

In questo articolo vedremo le differenze che c’è tra uno switch che supporta solo il livello 2 e uno che supporta anche le funzionalità del livello 3, e soprattutto in quali circostanze è consigliato usare l’uno e in quali l’altro.

Prima di addentrarci nell’argomento è bene ricordare brevemente cosa sono le VLAN. Il termine VLAN è acronimo di Virtual Local Area Network, ed indica una rete locale di dispositivi raggruppati in modo logico, ossia senza alcun legame specifico con la posizione fisica. Ad esempio possono appartenere ad una stessa VLAN dispositivi connessi a switch differenti. Inoltre le VLAN operano a livello 2, mentre con le LAN si opera a livello 3.

Nel momento in cui viene fatto il design di un ambiente con VLAN, è opportuno che i dispositivi di una stessa VLAN facciano parte anche della stessa subnet. Questo però non significa che una VLAN è una subnet, e che una subnet è una VLAN! Infatti come ho detto prima, le VLAN sono un concetto relativo al livello 2, mentre le subnet al livello 3 ossia a quello IP. E’ abbastanza ragionevole il fatto che gli stessi device all’interno di una VLAN debbano appartenere anche alla stessa subnet affinché possano comunicare tra di loro.

Studiamo adesso la seguente figura, e supponiamo che un computer della VLAN 10 voglia comunicare con uno della VLAN 20. E’ da notare che i computer delle VLAN si trovano correttamente anche su subnet diverse.

VLAN

Il pc nella VLAN 10, prima di inviare il pacchetto controlla se il destinatario è nella stessa subnet oppure no, e poiché si trova su una differente, il pacchetto deve essere inviato al default router. In pratica il pacchetto viene inviato allo switch, e poi inoltrato al router. A sua volta il router analizza il pacchetto controllando il destinatario, ricostruisce il pacchetto e lo invia indietro allo switch fino al destinatario della VLAN 20.

Come è facile immaginare, quando i pacchetti inviati sono tanti questo processo è oneroso sia in termini di banda utilizzata sia in termini di latenza. E’ qui che entrano in gioco gli switch di livello 3, o meglio di livello 2 e 3, chiamati anche switch multilivello. Questi sono difatti in grado di operare scelte di routing, supportando svariati tipi di protocolli (RIP, OSPF, BGP, …). In una rete con switch di questo tipo infatti i pacchetti non vengono inviati al router per decidere l’instradamento, ma è lo switch stesso ad avere la logica decisionale e a sapere dove inviare i messaggi. Nel mondo Enterprise ormai ogni switch supporta praticamente anche il livello 3.

L’utilizzo degli switch di vecchio stampo che supportano solo il livello 2 è pertanto relegato ad ambienti piccoli/casalinghi, dove non si hanno necessità particolari e dove i dispositivi interconnessi sono pochi. In questo caso solitamente non si ha bisogno neppure di particolari perfomance, e l’aumento della latenza o una minimale perdita di banda non costituiscono grandi problemi, diversamente da ambienti critici e di fascia medio/alta.

Matteo