Mese: Gennaio 2017

Visual Leak Detector per Visual C++

Fabio Bombardi

Ho utilizzato questo prezioso strumento per diversi progetto durante la mia carriera e mi sono accorto di non aver mai scritto un articolo al riguardi! Gravissimo! 🙂

La pagina del progetto è questa: https://vld.codeplex.com/

Con vld è possibile riconoscere se nel nostro codice nativo (C/C++) abbiamo dei memory leak direttamente dopo un solo ciclo di utilizzo del nostro programma dalla console di Output di Visual Studio.

Sul sito del progetto la documentazione è chiara. Vi mostrerò qui ora un semplice esempio.

Per prima cosa scarichiamo l’eseguibile da https://vld.codeplex.com/ e installiamolo sul PC sul quale abbiamo il nostro Visual Studio (nel mio caso la versione 2015).

A questo punto creo un progetto Win32 Console Application con il seguente main.cpp

Se scrivete il codice prima di impostare i path per gli include di vld, la riga 10 vi darà errore. Non preoccupatevi, la sistemiamo subito.

Come vedete il nostro bel programmino è fatto apposta per sprecare memoria all’infinito. La alloca e non la rilascia mai… che bravo! 😀

La documentazione ufficiale è ben fatta e la trovate qui.

Uma volta lanciato il setup.exe di VLD quello che dovete fare è andare ad impostare sul progetto in cui lo volete utilizzare per la build di Debug che vi interessa (x86, x64 o entrambe) i path delle librerie e dei file di include di VLD.

A questo punto compiliamo in Debug e lanciamo il nostro codice. La riga 10 non darà più errore e in console vediamo l’avvenuto corretto caricamento del nostro Leak Detector prendendo i suoi parametri di configurazione dal vld.ini nella directory di installazioine del VLD.

Al termine del programma ecco quali utili informazioni vld ci offre nella cosole di output di Visual Studio!

E questo è tutto, gente!

Visual Leak Detector per Visual C++

Utilizzare Let’s Encrypt con IIS su Windows

Fabio Bombardi

Finalmente dopo un po’ di tempo qualcuno si è “preso la briga” di fare un wrapper del protocollo Certbot anche per windows integrato con IIS.

Ecco qui il link al progetto su GitHub: https://github.com/Lone-Coder/letsencrypt-win-simple/releases

E’ costruito a sua volta sopra il  .net ACME protocol library.

Basta scaricare lo zip e metterlo in una cartella sul vostro server.

Dopodichè con un prompt dei comandi con diritti di amministratore andate nella cartella e semplicemente lanciate il comando:

Letencrypt.exe

E seguite i vari passaggi.

  • inserire la mail
  • leggere e accettare le condizioni di contratto e policy
  • scegliere il sito IIS su cui richiedere il certificato e aspettare

Fa tutto lui:

  • Chiede il rilascio del certificato
  • Lo salva sul server
  • Crea il bindig sulla porta 443 con il certificato appena richiesto
  • Crea il job schedulato per il rinnovo automatico

Bene! Finalmente la richiesta dei certificati SSL no sarà più un problema anche su IIS! 😀

Utilizzare Let’s Encrypt con IIS su Windows

PHP+Oracle OCI+CLOB

Fabio Bombardi

Oggi ho avuto necessità di leggere e scrivere da PHP un camp CLOB in una tabella di ORACLE.

Nel manuale al seguente indirizzo

http://php.net/manual/en/function.oci-new-descriptor.php

ho trovato subito il mio scenario.

Example #2 oci_new_descriptor() example

<?php
/* Calling PL/SQL stored procedures which contain clobs as input
 * parameters.
 * Example PL/SQL stored procedure signature is:
 *
 * PROCEDURE save_data
 *   Argument Name                  Type                    In/Out Default?
 *   ------------------------------ ----------------------- ------ --------
 *   KEY                            NUMBER(38)              IN
 *   DATA                           CLOB                    IN
 *
 */

$conn = oci_connect($user, $password);
$stmt = oci_parse($conn, "begin save_data(:key, :data); end;");
$clob = oci_new_descriptor($conn, OCI_D_LOB);
oci_bind_by_name($stmt, ':key', $key);
oci_bind_by_name($stmt, ':data', $clob, -1, OCI_B_CLOB);
$clob->write($data);
oci_execute($stmt, OCI_DEFAULT);
oci_commit($conn);
$clob->free();
oci_free_statement($stmt);
?>

Utilizzare PL/SQL permette di superare il limite di 4000 caratteri passati per il CLOB.

L’esempio nel manuale però dava errore.

Quello che ho dovuto modificare perchè il tutto funzionasse è stato sostituire

$clob->write($data);

con

$clob->writeTemporary($data);

Altrimenti ottenevo l’errore: OCI-Lob::write() : OCI_INVALID_HANDLE

Inoltre sarebbe bene ottenere il valore di ritorno dal oci_execute e fare la commit solo se “true”

$ok = oci_execute($stmt, OCI_DEFAULT);
if ($ok) {
    oci_commit($conn);
} else {
    oci_rollback($conn);
}

Nel caso qualcun altro avesse bisogno di questo scenario 😉

PHP+Oracle OCI+CLOB

Debug Diagnostic Tool

Fabio Bombardi

Oggi vedremo un caso di utilizzo del Debug Diagnostic Tool che è uno strumento molto utile per fare del debugging e del profiling sia in ambiente di Sviluppo ma sopratutto in ambiente di Produzione.

Il caso in particolare è andare ad analizzare una applicaizone ASP che in produzione, sotto stress quindi, ogni tanto manda il processore del server al 100%.

Come primo workaround si è subito messo in linea uno script di Power Shell che andasse a verificare lo stato del processore e nel caso fosse rimasto al 95% per più di 20sec, andasse a fare un IIS Reset.

Poi subito dopo seguendo questo articolo su Debuggin IIS High CPU siamo andati a impostare:

  1. Data Collection con il Performance Monitor
    In particolar modo:

    • Richieste Correnti Totali (ASP .NET)
    • Richieste in Coda (ASP .NET)
  2. Creazione di un Dump tramite Debug Diagnostic Tool 2 Collection
    In particolare:

    • Se il processore rimaneva al 90% per più di 5 secondi

E siamo rimasti ad aspettare che nuovamente succedesse lo scenario incriminato.

Abbiamo lasciato in piedi la cosa per tutta la notte: il data collection continua finchè non lo si stoppa, mentre il dump è one-time (una volta scattato, va riattivato manualmente il trigger, altrimenti si ferma).

Nella notte abbiamo avuto ben 4 casi di processore al 100% e durante il primo caso si è generato il Dump e durante tutti i casi abbiamo collezionato i dati dei contatori per le Richieste Correnti e per le richieste in Coda.

Ecco come abbiamo poi analizzato la cosa.

Per quanto riguarda i dati collezionati dal Performance Monitor si è visto che le richieste correnti schizzavano in occorrenza dell’evento incriminato:

Andando ad analizzare anche le richieste in coda:

si evince che aumentano proporzionalmente alle richieste attive.

Questo ci fa sospettare che sia effettivamente un problema di performance e non un problema di “attacco” in quanto le richieste in coda ci sono solamente durante gli eventi incriminati e quindi IIS non riesce ad evadere le richieste perchè è impegnato nell’operazione che porta il processore al 100% e questo scenario è coerente con il fatto che facendo IIS Reset la situazione ritorno normale.

Andiamo quindi ora ad analizzare il dump con il Debug Diagnosti Tool 2 Analysis.

Vediamo subito che l’analisi del Dump conferma High CPU Usage.

Andando a vedere quindi i Topo 8 Thread scopriamo da dove parte il tutto:

Dalla pagina “RivestimentiDettagli” ed è scatenata dal metodo “.get_data()” (Tutto Codice Utente).

Andando quindi ad analizzare il codice si è scoperto che si era fatto un uso improprio di variabili statiche e quindi c’erano problemi di concorrenza che si vedevano solo in presenza di forte carico del server.

 

 

 

Debug Diagnostic Tool

NMAP – Network Mapping #2 – Port Scanning

Fabio Bombardi

Il port scanning è il “core business” di Nmap.

Esso è l’atto di testare da remoto numerose porte per determinarne lo stato in cui sono.

La semplice esecuzione del comando

nmap <target>

fa la scansione di tutte  le prime 1.000 porte TCP classificandole negli stati

open, closed, filtered, unfiltered, open|filtered o closed|filtered

Lo stato più interessante è ovviamente lo stato “open” che vuol dire che su quella porta vi è in ascolto una applicazione pronta ad accettare connessioni.

NMap fa una distinzione differente delle porte rispetto allo IANA (Internet Assigned Numbers Authority) in base al loro numero.

Per lo standard IANA (http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) abbiamo

  • well-known ports dalla 1 alla porta 1023
  • registered ports dalla 1024 alla 49151 (gli utenti con accesso non privilegiato possono collegare i loro servizi a queste porte)
  • dynamic e/o private ports dalla 49152 alla 65535 (numero massimo di porta: è un campo di 16bit)

Mentre NMap distigue le porte in

  • well-known ports 1-1023
  • ephemeral  ports il cui range dipende dal sistema operativo è su Linux va da 32768 a 61000 ed è configurabile (/proc/sys/net/ipv4/ip_local_port_range)

La porta numero 0 (zero) è invalida. Le API delle socket Berkeley, che definiscono come i programmi devono comportarsi per quanto riguarda le comunicazioni di rete, non permettono l’utilizzo della porta numero zero. Invece, interpretano una richiesta sulla porta zero come una wildcard a indicare che al programmatore non interessa quale porta verrà utilizzata per la comunicazione e sarà il sistema operativo a sceglierne una per lui.

Questo non significa che qualche software malevolo non voglia utilizzare proprio questa porta per comunicare esplicitandola nell’heder TCP/IP. Quindi possiamo con NMap scansionare questa porta esplicitamente (e.g. -p0-65535)

Secondo l’autore di NMap, dopo anni di scansioni, queste sono le liste delle Top-20 porte TCP e UDP

Top-20 TCP ports

  1. 80 (HTTP)
  2. 23 (TELNET)
  3. 443 (HTTPS)
  4. 21 (FTP)
  5. 22 (SSH)
  6. 25 (SMTP)
  7. 3389 (ms-term-server) Microsoft Terminal Services Admin port
  8. 110 (POP3)
  9. 445 (Microsoft-DS) Microsoft SMB file/printer sharing
  10. 139 (NetBIOS-SSN)
  11. 143 (IMAP)
  12. 53 (DNS)
  13. 135 (MSRPC)
  14. 3306 (MySQL)
  15. 8080 (HTTP) di solito per fare del proxying
  16. 1723 (PPTP) per VPN
  17. 111 (RPCBind)
  18. 995 (POP3S) pop3 + ssl
  19. 993 (IMAPS) imap + ssl
  20. 5900 (VNC)

Top-20 UDP ports

  1. 631 (IPP) Internet Printing Protocol
  2. 161 (SNMP)
  3. 137 (NetBIOS-NS)
  4. 123 (NTP)
  5. 138 (NetBIOS-DGM)
  6. 1434 (Microsoft-DS) Microsoft SQL Server
  7. 445 (Microsoft-DS)
  8. 135 (MSRPC)
  9. 67 (DHCPS) dhcp + ssl
  10. 53 (DNS)
  11. 139 (NetBIOS-SSN)
  12. 500 (ISAKMP) Internet Security Association and Key Management Protocol
  13. 68 (DHCP client)
  14. 520 (RIP) Routing Information Protocol
  15. 1900 (UPNP)
  16. 4500 (nat-t-ike)
  17. 514 (syslog)
  18. 49152 (Varies)
  19. 162 (SNMPTrap)
  20. 69 (TFTP)

Ad inizio capitolo abbiamo detto che una porta si può trovare in 6 stati differenti

  1. open
    una applicazione è in ascolto e pronta ad accettare connessioni TCP o pacchetti UDP. Qui si può fare breccia.
  2. close
    la porta è accessibile (riceve e risponde alle sonde di NMap) ma non vi è nessuna applicazione in ascolto su di essa. Utile per host discovery o OS detection.
  3. filtered
    non sappiamo se la porta è aperta perché c’è una sorta di packet filtering che non ci permette di raggiungerla (firewall, regole di routing). Queste porte rallentano lo scan perché NMap cerca di ripetere lo scan in caso non abbia ricevuto risposte dovuto al fatto che si ha una rete congestionata. Ma di solito non è così.
  4. unfiltered
    la porta è raggiungibile ma non si riesce a distinguere se è aperta o chiusa. Solo l’ACK scan classifica le porta in questo stato.
  5. open|filtered
    NMap non riesce a capire se la porta è aperta o filtrata. Di solito succede per porte aperte che non danno risposte. La mancanza di risposta potrebbe dipendere anche da un filtro di pacchetto.
  6. closed|filtered
    NMap non riesce a capire se la porta è chiusa o filtrata. Stato impostato solo se si utilizza l’IP ID Idle scan (-sI).

Fare un port scanning della rete non è solo un modo per avere la lista di tutti i servizi aperti per motivi di sicurezza. Alcuni utilizzano il port scanning anche per fare un inventario delle macchine e dei dispositivi di rete e dei loro servizi, per scoprire la topologia della loro rete o per controlli di verifica di politiche di vario genere.

NMAP – Network Mapping #2 – Port Scanning