Il blog sull'informatica

Expect script e troubleshooting

noreply@myblog.it (nazarenolatella) — Mon, 21 May 2012 11:21:00 +0200

Potrebbe succedere che uno shell script che fa pesantemente uso di expect vi si pianti senza alcun motivo apparente. Potrebbe anche succedere che passiate delle ore a cercare di capire dove sta l'inghippo senza ottenere risultati.

Ecco allora che ci possono tornare utili alcuni piccoli magheggi da applicare al nostro script (causa di n-mila imprecazioni).

Il primo consiste nell'abilitare l'output dei comandi lanciati da expect. Per fare ciò è sufficente aggiungere exp_internal 1 allo script . Un esempio di output è il seguente:

parent: waiting for sync byte
parent: telling child to go ahead
parent: now unsynchronized from child
spawn: returns {22098}

expect: does "" (spawn_id exp6) match glob pattern "*?assword:*"? no

Inoltre (e sto parlando del secondo magheggio), posso garantirvi che nel 90% dei casi lo script fallisce a causa del timeout di expect. Per definire manualmente tale parametro basta inserire la seguente direttiva all'interno dello script:

set timeout <numero di secondi>

Ciò è necessario soprattutto se i comandi lanciati richiedono parecchio tempo per essere eseguiti (vedi dump di un database e copia dello stesso su una macchina remota).

Fine del post, fatene buon uso.

Siti Web dal design pessimo

noreply@myblog.it (nazarenolatella) — Wed, 16 May 2012 15:06:35 +0200

Se credete che basti saper utilizzare qualche tool WYSIWYG per creare un buon sito Web, allora date un'occhiata a questo link:

http://www.webpagesthatsuck.com/

No comment...

Overview sui linguaggi di programmazione

noreply@myblog.it (nazarenolatella) — Tue, 15 May 2012 11:07:00 +0200

Con il passare del tempo si è assistito ad una massiccia evoluzione dei linguaggi di programmazione, che ha portato ad una loro evidente semplificazione, aumentandone allo stesso tempo le potenzialità.

Esistono diversi criteri per differenziare i vari linguaggi di programmazione, tra cui l'ordine cronologico. Parliamo quindi di:

1) linguaggi di prima generazione, come il linguaggio macchina, piuttosto complesso e strettamente dipendente dall'architettura hardware;

2) linguaggi di seconda generazione, tra cui assembly. Tale linguaggio, molto simile al linguaggio macchina, consente al programmatore di turno di ottenere gli stessi risultati dei linguaggi di prima generazione adoperando, però, un minor numero di istruzioni. Inoltre, affinchè tale linguaggio possa essere tradotto in linguaggio macchina è necessario uno strumento apposito, detto assembler (per l'operazione inversa viene invece utilizzato il cosiddetto disassembler);

3) linguaggi di terza generazione: trovano in C, C++ e Java gli elementi più rappresentativi. Essi hanno come elemento predominante il fatto che si avvicinano molto al linguaggio naturale (english like) e dunque sono molto più semplici da utilizzare rispetto ad assembly o allo stesso linguaggio macchina.

4) linguaggi di quarta generazione: in questa categoria rientrano i cosiddetti linguaggi dichiartativi, come SQL, utilizzato come DDL e DML nell'albito dei DBMS.

Un ulteriore elemento distintivo tra i vari linguaggi di programmazione è sicuramente il metodo attraverso il quale vengono tradotti in linguaggio macchina. Parliamo quindi di:

1) linguaggi compilati: ne sono un'esempio C e C++, linguaggi che per essere tradotti il codice macchina (e dunque in eseguibili) necessitano di un compilatore (come gcc e g++);

2) linguaggi interpretati: essi non vengono compilati, ma interpretati in runtime senza che vi sia la necessità di trasformarli in eseguibili. Un esempio di linguaggi interpretati sono i cosiddetti linguaggi di scripting: da bash a perl, da php ad asp, and so on...

3) linguaggi a compilazione intermedia: sono un tipo di linguaggio ibrido, ovvero soggetti ad una prima fase, in cui si assiste ad una sorta di compilazione, ed una seconda fase, in cui avviene l'interpretazione. Un esempio tipico di questa tipologia di linguaggi è Java: in un primo momento il codice viene compilato, generando il cosiddetto bytecode. Successivamente, tale bytecode verrà interpretato da un software apposito (che funge appunto da interprete), ovvero la Java Virtual Machine (JVM).

Infine, un altro criterio per distinguere i vari linguaggi è la tipologia di programmazione di cui si avvalgono. Esistono infatti i seguenti tipi di programmazione:

1) programmazione procedurale: il programma viene realizzato attraverso l'uso di apposite procedure (le cosiddette funzioni) che hanno il compito di suddividere lo stesso in parti più elementari, consentendo allo sviluppatore di risolvere il problema mediante il classico approccio divide et impera. Essi, inoltre, permettono l'uso dei salti incondizionati (aka goto), anche se adoperarli potrebbe causare diversi problemi.

2) programmazione strutturata: simile in tutto e per tutto alla programmazione procedurale a differenza che non consente l'uso dei salti incondizionati;

3) programmazione orientata agli ogetti (OOP - Object Oriented Programming): i massimi rappresentanti di questa tipologia di programmazione sono certamente C++ ed il suo successore, ovvero Java. In questo caso parliamo di classe, caratterizzata da dati (attributi) e funzioni (metodi). Un oggetto non è altro che l'istanza di una classe.

4) programmazione dichiarativa, che a sua volta si suddivide in due tipologie, ovvero:

4a) programmazione funzionale, che basa il suo funzionamento su funzioni matematiche (un linguaggio che si avvale di tale tecnica è LISP, utilizzato soprattutto nell'ambito dell'intelligenza artificiale);

4b) programmazione logica, fondata su elementi di logica matematica.

Infine, a prescindere dal tipo di linguaggio e di logica di programmazione che si vuole utilizzare durante lo sviluppo software, è necessario porre particolare attenzione sul concetto di astrazione.

L'astrazione è un'attività svolta quasi automaticamente dalla nostra mente, la quale ci consente di concentrarci solo sui dettagli importanti di un dato problema, tralasciando tutto il resto. Esistono diversi tipi di astrazione:

1) astrazione funzionale: ovvero viene fornita solo l'interfaccia di un dato metodo (o il prototipo di una data funzione), tralasciando i dettagli implementativi della stessa;

2) astrazione dei dati: ovvero vengono considerate solo le informazioni essenziali relative ad una classe (o struttura), evitando quindi di dichiarare attributi che non verranno mai utilizzati;

3) astrazione di sistema: che riguarda l'intero software e lo rende in qualche modo indipendente dalla sua implementazione. Si può affermare che è una diretta conseguenza dell'astrazione dei dati che a sua volta dipende dall'astrazione funzionale.

Alla prossima.

Testing, documentazione e manutenzione del software

noreply@myblog.it (nazarenolatella) — Mon, 14 May 2012 17:44:00 +0200

Testing

Affichè si possa realizzare del software valido, ovvero funzionante ed ottimizzato, occorre effettuare delle campagne di testing rigorose.

A tal proposito è opportuno precisare che esistono diverse metodologie ed approcci per testare il software creato. Tra gli approcci più gettonati vi è il cosiddetto metodo delle white box e quello delle black box. Nel primo caso i test vengono eseguiti tenendo conto del codice sorgente, oltre che del corretto funzionamento del software lato utente. Nel secondo caso, invece, il software viene visto come una vera e propria scatola nera; per la precisione i test si occupano soltanto di verificarne il corretto funzionamento lato utente, tralasciando completamente l'analisi del codice sorgente.

Quando si analizza un software, alla ricerca di eventuali errori, è necessario tenere a mente alcuni termini ricorrenti, quali:

1) failure: ovvero la discrepenza tra il comportamento effettivo di un dato software e quello previsto;

2) fault: malfunzionamento del software causato da uno o più errori;

3) eccezione: ovvero la tecnica attraverso cui il sistema software può segnalare allo sviluppatore (o all'utente) il verificarsi di un dato errore;

4) bug (alias baco): ovvero un errore di programmazione più o meno grave.

In base ai componenti del software da analizzare, esistono diverse tipologie di testing, ad esempio:

1) unit testing, che esamina il funzionamento di un particolare modulo di cui è dotato il sistema;

2) integration testing (conosciuto anche come system testing), ovvero i test immediatamente successivi all'integrazione di uno o più moduli software;

3) acceptance testing, ovvero i test effettuati lato utente che verificano il corretto funzionamento del software e soprattutto la sua conformità con ciò che è stato decretato dall'analisi dei requisiti.

Tornando a bomba sul concetto di integrazione, occorre precisare che esistono diversi approcci per affrontare tale problematica. Il primo approccio consiste essenzialmente nell'integrare dapprima i moduli più importanti, per poi arrivare a quelli più elementari (approccio top-down). Il secondo approccio è speculare al primo, ovvero si parte dall'integrazione dei moduli più elementari per poi arrivare a quelli più importanti (bottom-up). Infine, vi è il cosiddetto approccio a macchia d'olio: si parte da alcuni moduli e si procede con l'integrazione in base alle necessità.

Per i software di grandi dimensioni spesso viene adoperato un approccio leggermente diverso. In particolare, la fase di testing si articola in due sottofasi, quali:

1) alpha testing, in cui gli stessi sviluppatori (o una cerchia ristretta di dipendenti appartenenti alla medesima ditta che ha creato il software), si occupano di verificare il corretto funzionamento del sistema;

2) beta testing, in cui una ristretta cerchia di utenti (esterni alla ditta che ha sviluppato il software) si occupa di verificare la qualità del sistema creato.

Inoltre, poichè spesso esistono più versioni di uno stesso software, magari rilasciate in periodi di tempo successivi, spesso viene adottata la tecnica del cosiddetto testing di regressione. Più precisamente, viene verificato che tutte le componenti funzionanti nelle versioni precedenti del software continuino a funzionare anche nella nuova versione.

Un'importante operazione da effettuare in fase di testing è l'analisi del codice sorgente. Tale analisi può essere di due tipi:

1) analisi statica;

2) analisi dinamica.

Nel primo caso viene controllato il codice dal punto di vista sintattico (definizione delle strutture, uso corretto dei segni di punteggiatura, ecc.) e lessicale (individuazione degli identificatori, delle parole chiave, ecc.). Viene inoltre fatta una verifica sui tipi di dato assegnato alle variabili (e sulle operazioni che le coinvolgono), oltre all'analisi dell'evoluzione temporale delle variabili stesse (dalla laro assegnazione fino al loro flush).

Per ciò che concerne l'analisi dinamica, le operazioni effettuate vengono identificate con il termine di copertura. I tipi di copertura sono molteplici, ovvero:

1) copertura dei comandi, in cui vengono eseguiti, uno per uno, tutti i comandi definiti all'interno del codice;

2) copertura delle decisioni, in cui, a differenza del caso precedente, si tiene conto anche dei costrutti decisionali (if - then - else);

3) copertura dei cammini, che comprende tutti i possibili cammini del programma (definiti dai costrutti decisionali), considerando anche i cicli e le iterazioni.

Documentazione

Alla base di un buon software c'è sempre una buona documentazione. Per documentazione, oltre al manuale dell'utente, si intende:

1) documentazione del progetto, in cui vengono definite le varie fasi da seguire durante la realizzazione del sistema;

2) documentazione del codice, realizzata principalmente attraverso i cosiddetti commenti, presenti all'interno del codice sorgente, oppure attraverso l'uso di librerie apposite (ad esempio JavaDoc).

Per ciò che concerne l'interazione tra le diverse figure professionali che partecipano allo sviluppo del software (analisti, sviluppatori, ecc.) è di vitale importanza utilizzare alcuni strumenti appositi, quali il documento dei requisiti. Esso ha come scopo anche quello di "regolare" lo scambio di informazioni con i clienti e viene realizzato utilizzando dello pseudocodice, meno soggetto ad errori di interpretazione rispetto al linguaggio naturale.

Altri strumenti molto utili per documentare il comportamento del codice sono gli alberi di decisione, le tabelle di decisione e i diagrammi di flusso (flowchart). Un'alternativa ai diagrammi di flusso è rappresentata dal linguaggio UML, i cui diagrammi principali sono i seguenti:

1) diagramma dei casi d'uso, che ha come scopo quello di rappresentare l'interazione dell'utente con il sistema;

2) diagramma degli oggetti;

3) diagramma delle classi;

4) diagramma di sequenza, che rappresenta le modalità con cui entrano in gioco le diverse componenti del sistema;

5) diagramma di deployment, che indica come i vari oggetti vengono distribuiti sui sistemi hardware;

6) diagramma delle attività, che rappresenta l'ordine di esecuzione delle varie attività dell'applicazione;

7) diagramma di collaborazione, che indica come le varie componenti del sistema software interagiscono tra di loro;

8) diagramma degli stati, che specifica l'evoluzione dello stato dei vari oggetti.

Manutenzione

La manutenzione del software è sicuramente una delle operazioni più critiche in assoluto. In particolare essa si occupa delle varie modifiche, evoluzioni ed aggiornamenti a cui il sistema è soggetto durante il corso della sua vita. A tal proposito, per manutenibilità si intende la caratteristica grazie alla quale un dato software può essere modificato senza impattare sulle performance e la funzionalità dello stesso. A ciò si aggiunge un sostanziale risparmio di risorse, sia in termini di denaro e forza lavoro che in termini di tempo.

Altra caratteristica fondamentale di un software è la riusabilità del codice, garantita anche grazie all'uso delle cosiddette API (Application Programming Interface).

Infine, da non sottovalutare è certamente la portabilità del codice, che lo rende teoricamente "indipendente" dall'architettura hardware e dal sistema operativo su cui lo stesso è installato.

Nelle operazioni di manutenzione e sviluppo software il versioning ricopre un ruolo fondamentale. Esso viene realizzato attraverso dei software appositi, detti Concurrent Versioning System (ad esempio Subversion), che consentono a più sviluppatori di lavorare contemporaneamente sullo stesso codice, tenendo traccia delle modifiche apportate da ciascuno di essi.

Le operazioni che vengono eseguite, in soldoni, sono due:

1) check out, ovvero lo sviluppatore accede in scrittura al codice per poterlo modificare;

2) check in, grazie al quale lo sviluppatore, tramite un commit, salva le modifiche apportate al codice.

Ovviamente i CVS devono gestire la concorrenza, quindi nel caso in cui due svuluppatori tentassero di salvare contemporaneamente le modifiche apportate al codice sorgente, il software di versioning li avviserebbe di quanto sta avvenendo generando un errore opportuno e suggerendo le possibili soluzioni al problema.

Più in generale, una corretta manutenzione del codice prevede le seguenti attività:

1) ispezione del codice sorgente;

2) definizione di regole comuni per la scrittura della documentazione;

3) scrittura di documentazione tecnica allegata al software stesso.

E' tutto. A presto.

Linux: packaging tool e proxy HTTP

noreply@myblog.it (nazarenolatella) — Wed, 09 May 2012 15:14:12 +0200

Usate un packaging tool (aptitude, emerge, yum et similia) per scaricare ed installare i pacchetti sulla vostra macchina Linux? Non avete accesso diretto al Web e quindi necessitate di interfacciarvi con un proxy HTTP? Niente paura, basta seguire questi semplici passi.

Per prima cosa occorre definire la variabile di ambiente http_proxy, il cui valore dovrà essere simile al seguente:

nightfly@nightbox:~$ export http_proxy=http://192.168.1.1:3128/

dove 192.168.1.1 è l'indirizzo IP del proxy e 3128 la porta su cui è in ascolto.

Se il proxy richiede autentica, è necessario definire la variabile precedentemente citata usando la seguente sintassi:

nightfly@nightbox:~$ export http_proxy=http://username:password@192.168.1.1:3128/

Attenzione però, le variabili di ambiente valgono esclusivamente per l'utente che le definisce. Per fare in modo che una variabile d'ambiente possa essere utilizzata da tutti gli utenti del sistema, è necessario operare sul file /etc/profile:

nightfly@nightbox:~$ sudo nano /etc/profile

ed aggiungere la direttiva:

export http_proxy=http://192.168.1.1:3128/

oppure:

export http_proxy=http://username:password@192.168.1.1:3128/

in caso di autentica.

Infine, per listare le variabili di ambiente basta lanciare il comando:

nightfly@nightbox:~$ export -p

Done.

Le password robuste...

noreply@myblog.it (nazarenolatella) — Sat, 05 May 2012 19:09:00 +0200

Avere a disposizione grandi budget da investire nella messa in sicurezza della propria infrastruttura informatica non implica l'invulnerabilità della stessa. Con questo voglio dire che nel 90% dei casi, le attività di cracking, anche le più banali, riescono grazie all'incapacità del sistemista, del tecnico di helpdesk o dell'utente vittima.

Basti pensare che su Internet vi sono migliaia di dispositivi le cui interfacce di configurazione sono accessibili digitando username e password di default. Non ci credete? Incominciate ad usare nmap, magari all'interno di qualche script bash che colleziona determinati OS fingerprint e, una volta analizzati i risultati, provate una di queste credenziali di accesso:

http://www.phenoelit-us.org/dpl/dpl.html

"L'essere umano è il vero anello debole della catena".

Alla prossima.

User enumeration mediante nmap

noreply@myblog.it (nazarenolatella) — Wed, 02 May 2012 11:02:41 +0200

Scenario: macchina Windows in ascolto sulla porta 3389 TCP (Il famoso Remote Desktop della Microsoft).

Password nota, nome utente sconosciito. Cosa fare quindi? Semplice, utilizzare un particolare script di nmap.

Vediamo, nello specifico, qual è il comando da lanciare:

nightfly@nightbox:/usr/share/nmap/nselib$ sudo nmap -sT -p445 --script=smb-enum-users <IP macchina Windows>

Come potete notare ho specificato ad nmap lo script da utilizzare, la porta di destinazione (TCP 445, alias SMB) ed il tipo di scan (-sT).

L'outuput sarà simile al seguente:

Starting Nmap 5.00 ( http://nmap.org ) at 2012-05-02 10:38 CEST
Interesting ports on 192.168.*.*:
PORT STATE SERVICE
445/tcp open microsoft-ds
MAC Address: E0:CB:*:*:*:* (Unknown)

Host script results:
| smb-enum-users:
|_ *Administrator, *Guest, *HelpAssistant,*HelpServicesGroup, *Nessuno

Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds

Enjoy.