Supporto Tecnico Enterprise : Cristian Crifò

Exchange Server - Verifica della rete con PortQry

itentblg — Tue, 16 Jun 2009 16:00:00 GMT

Dopo il mio post su NMCap vorrei continuare con la parte di troubleshooting relativa ai servizi di rete con PortQry e PortQryUI.

Scenari di utilizzo e Attivazione

Spesso, in configurazioni con i nostri server posti in DMZ, si ha la necessità di dover di verificare se il nostro firewall o switch L3 si stia comportando come noi ci aspetteremmo relativamente al filtraggio degli IP, porte, servizi, ecc. Per alcuni servizi questo può essere banale (es: un telnet alla porta 25 per valutare se SMTP risposte alle nostre richieste) mentre per altri la verifica può non essere altrettanto banale.

Caratteristiche di PortQry

Prendiamo ad esempio il caso del traffico RPC e dell’ EndPoint Mapper. Quando un client (MAPI ad esempio, oppure una console di amministrazione) inizia a dialogare col server di destinazione questo viene rediretto dall’ Endpoint Mapper, in ascolto sulla porta 135, su un'altra porta assegnata dinamicamente tra la 1024 e la 65535.

In casi come questo, dove può essere difficile verificare la disponibilità del servizio richiesto tramite l’utilizzo di un comune port scanner, PortQry (e PortQryUI) possono venirci in soccorso.

PortQry giunto alla versione 2.0, può essere scaricato gratuitamente dal Microsoft Download Center.

Mentre lo stesso tool adesso dotato di una interfaccia grafica è reperibile al seguente indirizzo: PortQryUI - User Interface for the PortQry Command Line Port Scanner

PortQry 2.0 supporta i seguenti session layer e application layer protocols:

Lightweight Directory Access Protocol (LDAP)
Remote Procedure Calls (RPC)
Domain Name System (DNS)
NetBIOS Name Service
Simple Network Management Protocol (SNMP)
Internet Security and Acceleration Server (ISA)
SQL Server 2000 Named Instances
Trivial File Transfer Protocol (TFTP)
Layer Two Tunneling Protocol (L2TP)

Analizzare traffico RPC

Cominciamo proprio con un esempio basato su RPC tramite il seguente comando:

portqry -n myserver -p udp -e 135

PortQry produrrà una query RPC, interpreterà la risposta ottenuta contenente tutti gli endpoint registrati con l’RPC endpoint mapper e verificherà la disponibilità delle varie porte restituite.

Ecco un esempio dell’output del comando:

Querying target system called:

ex2k3-01

Attempting to resolve name to IP address...

Name resolved to 192.168.1.81

querying...

UDP port 135 (epmap service): LISTENING or FILTERED

Using ephemeral source port

Querying Endpoint Mapper Database...

Server's response:

UUID: 3c4728c5-f0ab-448b-bda1-6ce01eb0a6d5 DHCP Client LRPC Endpoint

ncalrpc:[dhcpcsvc]

UUID: 3473dd4d-2e88-4006-9cba-22570909dd10 WinHttp Auto-Proxy Service

ncalrpc:[W32TIME_ALT]

UUID: 3473dd4d-2e88-4006-9cba-22570909dd10 WinHttp Auto-Proxy Service

ncacn_np:\\\\EX2K3-01[\\PIPE\\W32TIME_ALT]

UUID: 2f5f6521-cb55-1059-b446-00df0bce31db Unimodem LRPC Endpoint

ncacn_np:\\\\EX2K3-01[\\pipe\\tapsrv]

[..]

UUID: 9e8ee830-4459-11ce-979b-00aa005ffebe MS Exchange MTA 'Mta' Interface

ncacn_np:\\\\EX2K3-01[\\pipe\\9403671C54CE8F36]

[..]

UUID: a4f1db00-ca47-1067-b31e-00dd010662da Exchange Server STORE ADMIN Interface

ncacn_np:\\\\EX2K3-01[\\pipe\\D1A77AAA93FBC00C]

UUID: a4f1db00-ca47-1067-b31e-00dd010662da Exchange Server STORE ADMIN Interface

ncalrpc:[MSExchangeIS_LPC]

[..]

Total endpoints found: 154

==== End of RPC Endpoint Mapper query response ====

UDP port 135 is LISTENING

In questo modo possiamo determinare il corretto funzionamento della porta 135, i servizi registrati con l’RPC endpoint mapper database del server di destinazione, i vari Universal Unique IDentifier (UUID) per ogni servizio o programma e il rispettivo protocollo utilizzato.

Le possibili stati riportati da Portqry sono i seguenti:

Listening – Un processo è in ascolto sulla porta indicata e Portqry ha ottenuto una risposta
Not Listening – Nessun processo è in ascolto sulla porta indicata e Portqry ha ottenuto una risposta (ICMP) "Destination Unreachable - Port Unreachable" (porta UDP) oppure un acknowledgement packet (ACK) col Reset flag (RST) impostato ad 1 (Porta TCP).
Filtered - Portqry.exe non riceve nessuna risposta.

Esempi di altri protocolli

Altri esempi di sintassi sono i seguenti:

portqry -n 10.0.0.11 -p tcp -o 143,110,25 -l portqry.log

Effettua un test delle porte 143, 110 e 25 salvando il risultato nel rispettivo file di log.

portqry -n my_server -p udp -r 135:139 -l portqry.log

Come sopra a differenza del fatto che viene testato il range di porte 135-139.

Se non siete degli amanti della command-line, come anticipato all’inizio del post, adesso è disponibile la versione grafica di PortQry: PortQryUI.
Il funzionamento è pressoché identico con l’aggiunta di alcuni comodi set di test preconfigurati: Domain and Trusts, WEB Service, nonché il nostro amato Exchange.

Concludo questo veloce post con un paio di link utili riguardo quanto detto:

Cristian Crifò
Senior Support Engineer
Microsoft Enterprise Exchange Support

Exchange Server – Automatizzare la cattura del traffico di rete con NMCap

itentblg — Mon, 01 Jun 2009 02:00:00 GMT

In questi miei primi post, non strettamente legati al mondo Exchange, vorrei porre la vostra attenzione su alcuni tool di troubleshooting utilizzati per analizzare problematiche che impattano le funzionalità dei server Exchange. Iniziamo quindi con una utility che si è dimostrata spesso indispensabile: NMCap.

Scenari di utilizzo e Attivazione

Spesso capita di avere l’esigenza di effettuare delle catture di traffico di rete in attesa che un determinato problema si presenti nuovamente.

Nella maggior parte delle situazioni non è possibile collegarsi al server e lanciare Network Monitor, o in alternativa il vostro tool di cattura preferito, e lasciarlo semplicemente girare, magari col “circular logging” impostato.

Oltre al fatto d’essere una soluzione molto poco elegante la sessione RDP può andare in timeout, essere richiesta da un altro amministratore, vi ricordo il limite di due sessioni contemporanee insieme a quella “console”, o semplicemente un altro amministratore può avere la necessità di riavviare il server: fermando così la cattura fino a che questa non viene fatta ripartire nuovamente. Infine, col “circular logging” impostato, rischiamo di perdere i dati di nostro interesse se non agiamo velocemente per fermare la cattura.

Fino a qualche tempo fa, quando necessario, automatizzavo la cattura del traffico di rete con netta con qualche limitazione. Con il nuovo Network Monitor, giunto alla versione 3.3, sono state superate alcuni dei vincoli del suo predecessore e sono state introdotte alcune interessanti novità.

Tanto per citarne alcune tramite NMCap è possibile effettuare la cattura del traffico su tutte le interfacce, salvare grandi quantità di dati catturati effettuando lo “split” su più file. E’ possibile impostare un trigger per lo start e stop della cattura, oltre che per una determinata finestra temporale, anche per uno specifico evento (es: un ping inviato al server) e “last but not least” è ovviamente possibile utilizzare NMcap con i filtri creati attraverso la GUI di Network Monitor, fate attenzione ai doppi apici “”!

Per catture relative a sessioni molto lunghe è addirittura possibile arrivare a “scriptare” il tutto utilizzando in maniera continuativa NMcap (con o senza filtri) e comprimendo via via (sempre via command line) i file prodotti per spostarli poi su volumi “meno pregiati” del server. Volevo ricordare con l’occasione che NMCap, se utilizzato senza filtri, non causa un sostanziale decadimento delle performance del server.

Un’altra idea può essere quella di avviare NMCAp tramire un Alert di Performance Monitor oppure, tramite VBScript col verificarsi di uno specifico evento nel System Log o nell’Application Log (relativamente a questo pubblicherò a breve un post per dettagliare ulteriormente questi aspetti).

Esempi pratici

Dopo questa lunga introduzione passiamo a qualche esempio pratico relativo all’utilizzo ed alla sintassi del comando:

nmcap /network * /capture "(tcp.port == 25)" /file t.chn:100M /stopwhen /timeafter 120min /terminatewhen /keypress x

Nell’esempio di cui sopra NMcap catturerà il traffico relativo a tutte le interfacce (parametro “/network *”) indirizzato alla porta TCP 25 e si fermerà dopo 120 min oppure premendo il tasto “X”. Il comando concatena inoltre i dati catturati in N file t(1).chn e t(2).chn, ognuno di 100MB fino al termine previsto per la cattura (su questo punto vi consiglio di prestare particolare attenzione al esaurimento dello spazio disco a disposizione). Ricordo che per default, per fermare la cattura, è semplicemente necessario utilizzare Ctrl+C o Ctrl+Break. Procediamo con un passo indietro e un esempio più semplice:

nmcap /network * /capture /file test.cap

Il comando di cui sopra cattura il traffico su tutte le interfacce salvando i dati nel file test.cap (cattura circolare per un file con dimensione massima pari ai 20MB di default). Un altro esempio interessante può essere il seguente dove effluiamo la cattura di tutto il traffico escludendo la parte relativa al protocollo RDP (Terminal Services):

nmcap /network * /capture "!(tcp.port == 3389)" /file test.cap

Come anticipato nel primo script è possibile impostare la partenza e lo stop della cattura attraverso gli switch /startwhen e /stopwhen dopo un certo numero di minuti (ad esempio 30) col seguente switch: "/TimeAfter 30 mintues" oppure indicando un orario preciso con lo switch "/Time 10:30:00 am 9/10/2006" (attenzione perché il formato della data/ora dipende dai locale settings impostati) oppure, come ho accennato all’inizio del post, col verificarsi di un determinato evento come nell’esempio di cui sotto dove la cattura terminerà non appena NMCap rileverà i passaggio di un frame dal server locale all’ host con IP 10.20.30.41:

nmcap /network * /capture /file t.cap /stopwhen /frame (ipv4.address == ipconfig.localipv4address) AND (Ipv4.DestinationAddress == 10.20.30.41)

Come ho accennato prima è possibile concatenare i file di output della cattura specificando l’estensione ".chn” e la dimensione massima per ogni file (che consiglio di mantenere al di sotto di 100-200MB al fine di non ritrovarsi a gestire file di dimensioni troppo ampie). Per cui, utilizzando ad esempio lo switch "/file t.chn:1M" verranno creati dei file chiamati files t(1).chn, t(2).chn, ecc. ognuno con dimensione pari ad 1MB.

Relativamente alla salvaguardia dello spazio a disposizione sarà possibile indicare anche una condizione alternativa di stop della trace basata sulla percentuale di spazio libero su disco come nell’esempio di cui sotto dove, al raggiungimento del 5% di spazio libero residuo, la cattura terminerà automaticamente:

nmcap /network * /capture /file result.cap /MinDiskQuotaPercentage 5

Come avete potuto vedere le possibilità offerte sono veramente molte e credo saranno in grado di soddisfare tutte le vostre esigenze.

Altri esempi di utilizzo di NMCap potranno essere valutati digitando il comando con lo switch "/examples" mentre ulteriori informazioni su Network Monitor e il relativo download del tool sono disponibili ai seguenti indirizzi:

Buona cattura a tutti! :)

Cristian Crifò
Senior Support Engineer
Microsoft Enterprise Exchange Support