Mediafire: script Bash per upload di files da console

Di seguito pubblico uno script utile per chi vuole caricare su mediafire uno o più file da console senza dover utilizzare un browser web. Questo script è utile in caso di job notturni o programmi che non richiedono l’intervento dell’utente.

#!/bin/bash

#
# Copyright (c) 2011 vittorio benintende
# (vittorio@lucullo.it - http://www.morzello.com).
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
#
# 3. Neither the name of the Site nor the names of its contributors
#    may be used to endorse or promote products derived from this software
#    without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE SITE AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE SITE OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
#
# --- PARAMS ---
#
# login and password must be url-encoded!
#

MF_LOGIN='mediafire%40morzello.com'
MF_PWD='mypass'

# --- PARAMS ---
#
# DO NOT MODIFY LINES BELOW
#

MF_FILES="$@"

if [ "z${MF_FILES}" = "z" ]; then
	echo
	echo "No file(s) specified."
	echo
	echo "USAGE: $0 : file1 file2 ..."
	echo

	exit 1
fi

OUTPUT_FILE=$(mktemp)
COOKIE_FILE=$(mktemp)

rdom () { local IFS=\> ; read -d \< E C ;}

wget -q --save-cookies ${COOKIE_FILE} --keep-session-cookies -O /dev/null "https://www.mediafire.com/"

wget -q --load-cookies ${COOKIE_FILE} --save-cookies ${COOKIE_FILE} --keep-session-cookies --referer="https://www.mediafire.com/" \
     --post-data "login_email=${MF_LOGIN}&login_pass=${MF_PWD}&login_remember=on&submit_login.x=97&submit_login.y=18" \
     -O /dev/null "https://www.mediafire.com/dynamic/login.php"

wget -q --load-cookies ${COOKIE_FILE} --save-cookies ${COOKIE_FILE} --keep-session-cookies --referer="https://www.mediafire.com/myfiles.php" \
     -O ${OUTPUT_FILE} "https://www.mediafire.com//basicapi/uploaderconfiguration.php?45144"

UPLOAD_SESSION=$(while rdom; do
    if [[ ${E} = "upload_session" ]]; then
        echo ${C}
        exit
    fi
done < ${OUTPUT_FILE})

# echo "Upload Session = ${UPLOAD_SESSION}"

UKEY=$(while rdom; do
    if [[ ${E} = "ukey" ]]; then
        echo ${C}
        exit
    fi
done < ${OUTPUT_FILE})  

# echo "UKey = ${UKEY}"

TRACKKEY=$(while rdom; do
    if [[ ${E} = "trackkey" ]]; then
        echo ${C}
        exit
    fi
done < ${OUTPUT_FILE})

# echo "Track Key = ${TRACKKEY}"

FOLDERKEY=$(while rdom; do
    if [[ ${E} = "folderkey" ]]; then
        echo ${C}
        exit
    fi
done < ${OUTPUT_FILE})  

# echo "Folder Key = ${FOLDERKEY}"

MFULCONFIG=$(while rdom; do
    if [[ ${E} = "MFULConfig" ]]; then
        echo ${C}
        exit
    fi
done < ${OUTPUT_FILE})  

# echo "MFUL Config = ${MFULCONFIG}"

MF_USER=$(while rdom; do
    if [[ ${E} = "user" ]]; then
        echo ${C}
        exit
    fi
done < ${OUTPUT_FILE})  

# echo "User = ${MF_USER}"

for FILENAME in ${MF_FILES}; do

	SHORT_FILENAME=$(basename "${FILENAME}")
	FILESIZE=$(stat -c%s "${FILENAME}")

	wget -q --load-cookies ${COOKIE_FILE} --save-cookies ${COOKIE_FILE} --keep-session-cookies --referer="https://www.mediafire.com/myfile.php" \
	     --header="Content-Type: application/octet-stream" \
	     --header="X-Filename: ${SHORT_FILENAME}" \
	     --header="X-Filesize: ${FILESIZE}" \
	     --post-file="${FILENAME}" \
	     -O ${OUTPUT_FILE} "https://www.mediafire.com/douploadtoapi/?type=basic&ukey=${UKEY}&user=${MF_USER}&uploadkey=${FOLDERKEY}&filenum=0&uploader=0&MFULConfig=${MFULCONFIG}"

	RESKEY=$(while rdom; do
	    if [[ ${E} = "key" ]]; then
	        echo ${C}
	        exit
	    fi
	done < ${OUTPUT_FILE})

	# echo "${FILENAME} > ${RESKEY}" 

	# get result

	RUN=1

	while [ ${RUN} -eq 1 ]; do
		wget -q --load-cookies ${COOKIE_FILE} --save-cookies ${COOKIE_FILE} --keep-session-cookies --referer="https://www.mediafire.com/myfile.php" \
		     -O ${OUTPUT_FILE} "https://www.mediafire.com/basicapi/pollupload.php?key=${RESKEY}&MFULConfig=${MFULCONFIG}"

		QUICKKEY=$(while rdom; do
		    if [[ ${E} = "quickkey" ]]; then
		        echo ${C}
		        exit
		    fi
		done < ${OUTPUT_FILE})

		FILEERROR=$(while rdom; do
		    if [[ ${E} = "fileerror" ]]; then
		        echo ${C}
		        exit
		    fi
		done < ${OUTPUT_FILE})

		# echo "${QUICKKEY} ; ${FILEERROR}" 

		RUN=0
		if [ "z${FILEERROR}" = "z" ] && [ "z${QUICKKEY}" = "z" ]; then
			RUN=1

		fi

		#
		#..

		#...
		#... File too large. 1 0 
		#... File too small. 2 0 
		#... Archive is bad. 3 0 
		#... Archive is bad or password protected. 4 0 
		#... Virus found. 5 0  
		#... File already uploaded. 13 0  
		#... Archive has an unknown problem. 9 0 
		#... Invalid image. 10 0 
		#... File lost. 6 1 
		#... Error scanning file. 7 1 
		#... Disk error. 8,11 1 
		#... Database error. 12 1 
		#..
		#	

		case "${FILEERROR}" in
			1) FILEERROR=" 1 : File too large."
			;;
			2) FILEERROR=" 2 : File too small."
			;;
			3) FILEERROR=" 3 : Archive is bad."
			;;
			4) FILEERROR=" 4 : Archive is bad or password protected."
			;;
			5) FILEERROR=" 5 : Virus found."
			;;
			13) FILEERROR="13 : File already uploaded."
			;;
			9) FILEERROR=" 9 : Archive has an unknown problem."
			;;
			10) FILEERROR="10 : Invalid image."
			;;
			6) FILEERROR=" 6 : File lost."
			;;
			7) FILEERROR=" 7 : Error scanning file."
			;;
		 8) FILEERROR=" 8 : Disk error."
			;;
			11) FILEERROR="11 : Disk error."
			;;
			12) FILEERROR="12 : Database error."
			;;
			*) FILEERROR="0 : Success."
			;;
		esac

	done 

	echo "${FILEERROR} | ${FILENAME} > ${QUICKKEY}"
done

rm ${OUTPUT_FILE}
rm ${COOKIE_FILE}

Prima di iniziare
Prima di utilizzare lo script è necessario impostare i parametri di login e password in uso su medaifire. Bisogna ricordare che questi paramentri sono url-encoded; questo perchè vengono esposti direttamente nell’url di login. Ad esempio:

mediafile@morzello.com -> mediafire%40morzello.com

Usare lo script
Per utilizzare lo script basta indicare il file o i file da inviare al server:

./mfup.sh myfile.txt all.* /root/repo/*

Ricordate però che non verranno prese in considerazione le sottocartelle.

Alla prossima

Come faccio a sapere se il mio ISP blocca il traffico P2P?

Qualche volta le richieste di consulenza informatica che ricevo sono alquanto bizzarre. Non per questo però sono da ritenersi banali.

L’ultima mi è stata rivolta da un amico che, dopo aver sottoscritto un contratto di abbonamento ADSL con un noto gestore di telefonia italiano, mi chiede:

“Ma secondo te, il mio ISP (Internet Service Provider) manipola il traffico P2P (Peer-To-Peer) sul mio account?”

Sembrerebbe una domanda banale, tuttavia da consulente mi sento di dover fare alcune considerazioni in merito.

In primo luogo è necessario comprendere cosa sono e come funzionano i protocolli P2P. Banalmente, quando pensiamo a questi protocolli, salta subito alla mente eDonkey (ampiamente sfruttato dal client eMule) e BitTorrent. In realtà si tratta di protocolli ampiamente utilizzati per la condivisione di file (non necessariamente a scopo di pirateria) che non impiegano una gerarchia fra i nodi. In questi protocolli quindi non esiste una relazione Client-Server ma i nodi sono considerati contemporaneamente Client e Server.

Non tutti i protocolli sono uguali
C’è inoltre da tenere presente che i protocolli P2P possono essere molto diversi tra loro. Ad esempio, il protocollo eDonkey, conosciuto anche come ed2k o swamp, prevede l’impiego di alcuni server con lo scopo mi mantenere una sorta di indice dei file presenti in una rete di nodi. Il bittorrent invece prevede l’uso del tracker, un server a cui i client si collegano periodicamente per aggiornare e coordinare i nodi. Nel tracker vengono mantenuti solo le informazioni utili a reperire le risorse, non le risorse stesse. Queste informazioni sono conservate ed aggiornate in file con estensione torrent.

Poiché i nodi sono contemporaneamente client e server, tutti i nodi sono chiamati a gestire connessioni in ingresso per consentire ad altri client la condivisione delle risorse. Questo vuol dire che di norma, i client ricevono connessioni dall’esterno su alcune porte TCP/IP.

eMule ad esempio, utilizza le porte 4662/TCP e 4772/UDP (a volte anche 4672) per gestire il traffico entrante, mentre il protocollo Bittorrent impiega un range che va da 6881 a 6900. Questi sono i parametri standard che generalmente vengono utilizzati e che comunque possono essere modificati all’occorrenza dall’utente.

Nei panni dell’ISP
Per rispondere alla domanda precedente io ne fare un’altra: “Se fossi chiamato a gestire un ISP, come mi comporterei nei confronti delle comunicazioni P2P?”.

In Italia i provider Internet a carattere nazionale sono dotati di linee commerciali e linee business. Queste ultime sono dedicate a contratti aziendali utilizzati ad esempio da: pubblica amministrazione, ospedali, banche, liberi professionisti, ecc. Le linee commerciali sono invece destinate all’uso domestico. Questa segregazione delle reti aiuta sicuramente ad ovviare al rallentamento che la linea commerciale provoca, specie nelle ore di punta.

QOS
Al di là della banda disponibile, c’è da dire che non tutti i servizi offerti da Internet sono uguali. Dal punto di vista dell’utente che ne deve usufruire, potremmo suddividerli in tre macro gruppi:

- Servizi Batch: sono quei servizi che non necessitano di un intervento da parte dell’utente se non marginalmente: ad esempio all’avvio dello stesso. Pensiamo al servizio di trasferimento dei file come FTP (File Transfer Protocol) oppure ai protocolli P2P. Può sembrare strano ma per questi servizi, i difetti dovuti ad una congestione della banda non sono tanto sentiti poiché l’utente non deve forzatamente stare davanti al PC attendendo la fine delle operazioni. E’ vero quindi che, entro certi limiti, avere una banda larga o piccola fa poca differenza.

- Servizi Interattivi: sono servizi che richiedono una continua iterazione da parte dell’utente. Appartengono a questa famiglia la navigazione sul web, l’invio di posta elettronica (con ovvi limiti), l’uso di ERP (come ad esempio SAP) e così via. In genere sono servizi che occupano poca banda, di contro però necessitano di essere molto veloci perché l’utente poco sopporta anche pochi secondi di ritardo.

- Servizi ad Alta Disponibilità: sono quei servizi per i quali la banda è da considerarsi il driver prioritario. Sono ad esempio i servizi di streaming audio/video ed il VoIP. In questo caso una rete sottodimensionata oppure una banda insufficiente rischia non solo di irritare gli utenti ma addirittura di rendere inutile il servizio stesso.

Fatta questa distinzione possiamo immaginare come sia necessario intervenire in qualche maniera al fine di dare una priorità ad alcuni servizi togliendola ad altri.
Il metodo oggi più utilizzato per priorizzare i servizi è quello che impiega il modello di Qualità del Servizio (QoS). Si tratta di accorgimenti ed algoritmi adottati dai vari dispositivi di rete in tempo reale durante lo smistamento del traffico. Ce ne sono tanti e con nome diverso ma tutti vengono generalmente identificati come QoS.

Restando nell’ambito delle linee commerciali, la prima misura che adotterei è quella di introdurre un modello di qualità del servizio (qos).

Blocco del traffico
Bloccare il traffico su alcune porte è sicuramente il metodo più semplice di intervenire ma è anche il metodo più facile da aggirare. In effetti per bloccare le porte che comunemente vengono utilizzate da questi protocolli non vi è bisogno di hadrware particolarmente dotati in termini di CPU perché è possibile definire delle regole statiche. Non a caso i firewall che adottano questo approccio prendono il nome di stateless cioè senza memoria. In realtà basta modificare le porte usate dal servizio per ovviare al problema. E’ ovvio che se l’interesse dell’ISP è quello di arginare il traffico del 70%-80% degli utenti questo è sicuramente un ottimo metodo.

Analisi del traffico di rete
Il modo più efficace invece consiste nell’adottare un sistema di monitoraggio attivo in grado di discriminare il traffico che attraversa la rete al livello più alto dello strato OSI ossia il livello applicativo. E’ il lavoro svolto dalla maggior parte dei firewall statefull che al contrario dei fratelli minori stateless riassemblano tutti i pacchetti prima di consegnarli al destinatario. Vengono spesso usati per intercettare virus e connessioni pericolose e possono dare i loro frutti anche nel caso di protocolli P2P anche su porte non convenzionali. Il rovescio della medaglia è dato dal fatto che ispezionare tutti i pacchetti in transito mantenendo una velocità adeguata necessita di molta potenza di calcolo e questo implica un costo che potrebbe non essere compensato dalla maggior larghezza di banda a disposzione.

A valle di queste considerazioni vi consiglio un sito web dove poter fare alcuni test e capire effettivamente se il vostro ISP adotta uno o più metodi indicati in precedenza:

http://broadband.mpi-sws.org/transparency/bttest.php

Alla prossima.

Creazione di una Certification Authority con CentOS/Fedora (Parte II)

Continuando il discorso iniziato nell’articolo precedente, di seguito riportiamo i comandi necessari per installare una propria Certification Authority creata con OpenSSL.

Quasi tutte le installazioni di Linux (Fedora e CentOS compresi) fanno uso di OpenSSL. Per accertarsi che sia installato è sufficiente scrivere nella shell:

OpenSSL

Se tutto è ok comparirà il prompt dei comandi del programma (per uscire scrivere quit e premere invio).

Chi dovesse installare il pacchetto può scrivere invece:

yum install openssl

A differenza di altre distribuzioni, in Red Hat i files di configurazione di OpenSSL risiedono nella cartella “/etc/pki/tls”. Il primo passo consiste nel creare una nuova directory dove conservare tutti i files necessari alla nostra CA. Per non incorrere in problemi dovuti alle policy di selinux, in questo esempio utilizzeremo la cartella “/etc/pki/CA” (l’utente può usare comunque un altro percorso).

Una volta scelta la destinazione è necessario creare alcune sottocartelle:

  • certs – cartella in cui verranno sistemati i certificati;
  • crl – cartella dedicata alla revoca dei certificati;
  • newcerts – cartella utilizzata da openssl per creare i certificati nella forma non criptata
  • private – cartella contenente le chiavi private. Questa cartella dovrebbe essere di sola lettura e trattata con estrema cura dal momento che contiene la parte più intima della CA.

Oltre alle cartelle, bisogna creare alcuni file:

  • index.txt – file che fungerà da database;
  • serial – file che contiene il numero progressivo dei certificati segnati;
  • crlnumber – (facoltativo) contiene il numero successivo da utilizzare nella lista dei certificati revocati;

Per comodità, di seguito trovate i comandi necessari per creare l’ambiente:

cd /etc/pki/CA
mkdir certs crl newcerts private
touch index.txt
echo "01" > serial
chmod 0755 *

Fatto questo, passiamo alla modifica del file di configurazione openssl.cnf che si trova nella cartella /etc/pki/tls. Prima di procedere oltre però sarebbe bene fare una copia di backup.

[ CA_default ]
  dir = /etc/pki/CA
  x509_extensions = v3_ca
  countryName_default = IT
  stateOrProvinceName_default = Calabria
  0.organizationName_default = Catanzaro

In alto abbiamo riportato solo le righe che sono state modificate.

Per quanto concerne il parametro x509_extensions vi sono alcune considerazioni da fare. Si tratta di un parametro che indica quale sezione del file di configurazione prendere in considerazione quando vengono creati i certificati (relativamente alle estensioni x509). Poichè la sezione usr_cert (valore di default) contiene alcuni parametri che devono essere correttamente impostati per creare certificati validi in ambiente MS-Windows, si è preferito sostituirla con v3_ca che non necessita di personalizzazioni; ricordiamo che questo articolo non tratta tutti gli argomenti relativi al file di configurazione di openssl.

Se non sono state apportate modifiche al file di configurazione diverse da quelle specificate in precedenza, per creare una CA è sufficiente impartire il seguente comando:

openssl req -config /etc/pki/tls/openssl.cnf \
    -new -x509 -days 7200 -keyout /etc/pki/CA/private/cakey.pem \
    -out /etc/pki/CA/cacert.pem

É ovvio che i percorsi indicati nel comando devono rispecchiare la configurazione altrimenti il certificato non verrà utilizzato dal sistema operativo. Il certificato creato avrà una durata di 20 anni, probabilmente è un periodo di tempo eccessivo.

A questo punto viene richiesta una pass phrase ed i campi del certificato:

Generating a 1024 bit RSA private key
.................++++++
.........++++++
writing new private key to '/etc/pki/CA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:IT
State or Province Name (full name) [Berkshire]:Catanzaro
Locality Name (eg, city) [Newbury]:Catanzaro
Organization Name (eg, company) [My Company Ltd]:Morzello Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:morzello.com
Email Address []:noreply@morzello.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:ScegliUnaPassword
An optional company name []:Morzello Blog

La pass phrase non deve essere intesa come una password, in effetti viene rischiesta una “frase segreta” che dorà essere custodita con cura.

La challenge password invece viene usata per evitare le la chiave privata venga conservata in chiaro sul disco.

Creazione dei certificati

La creazione dei certificati è relativamente semplice e si compone di due fasi: nella prima viene fatta una richiesta di certificazione mentre nella seconda la richiesta viene segnata digitalmente.

In linea di principio non c’è differenza tra i certificati emessi per un server e quelli emessi per un client; a variare è l’uso che se ne fa del certificato. In genere, la chiave privata del certificato non viene conservata in chiaro ma viene anch’essa sottoposta a crittografia mediante la richiesta di una password. Nel caso di servizi server però questa politica è difficilmente applicabile poichè all’avvio del server tipicamente non vi è nessuno in gradi di digitare una password. Conservare la password in chiaro non ha senso e quindi i certificati per i server non contemplano la crittografia per la chiave privata.

Richiesta di certificati server

OpenSSL può essere utilizzato anche per emettere le richieste di certificazione. Di seguito vediamo un esempio applicabile ai certificati server:

openssl req -config /etc/pki/tls/openssl.cnf -new -nodes -days 730 \
     -keyout /etc/pki/CA/private/new.key \
     -out /etc/pki/CA/newcerts/new_req.pem

Il parametro -nodes evita proprio che il certificato venga sottoposto a crittografia triple des.

Dopo aver eseguito il comando si procederà con la compilazione dei campi necessari:

Generating a 1024 bit RSA private key
........++++++
..........++++++
writing new private key to '/etc/pki/CA/private/new.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:IT
State or Province Name (full name) [Berkshire]:Italy
Locality Name (eg, city) [Newbury]:Torino
Organization Name (eg, company) [My Company Ltd]:Morzello Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:www.morzello.com
Email Address []:noreply@morzello.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:test
An optional company name []:

Richiesta di certificati client

Per i client la richiesta è del tutto simile ma in questo caso, possiamo usare la crittografia a protezione della chiave privata:

openssl req -config /etc/pki/tls/openssl.cnf -new -days 730 \
     -keyout /etc/pki/CA/private/new.key \
     -out /etc/pki/CA/newcerts/new_req.pem

A titolo esemplificativo riportiamo l’output del comando precedente:

Generating a 1024 bit RSA private key
.++++++
.......++++++
writing new private key to '/etc/pki/CA/private/new.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:IT
State or Province Name (full name) [Berkshire]:Calabria
Locality Name (eg, city) [Newbury]:Catanzaro
Organization Name (eg, company) [My Company Ltd]:Morzello Blog
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:client.morzello.com
Email Address []:noreply@morzello.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:test
An optional company name []:

Come è possibile notare, in questo caso viene richiesta una pass phrase per il certificato.

Firmare digitalmente le richieste

Dopo aver creato la richiesta possiamo passare alla sua firma (sign). Per farlo possiamo usare la nostra CA:

openssl ca -config /etc/pki/tls/openssl.cnf \
     -policy policy_anything \
     -out /etc/pki/CA/certs/new.crt \
     -infiles /etc/pki/CA/newcerts/new_req.pem

Il risultato sarebbe del tutto simile al seguente:

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Jun 30 09:18:53 20xx GMT
            Not After : Jun 30 09:18:53 20yy GMT
        Subject:
            countryName               = IT
            stateOrProvinceName       = Calabria
            localityName              = Catanzaro
            organizationName          = Morzello Blog
            commonName                = client.morzello.com
            emailAddress              = noreply@morzello.com
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                0A:AF:2C:D3:55:29:86:33:FC:D2:9A:A4:AF:90:42:AB:BD:17:01:29
            X509v3 Authority Key Identifier:
                keyid:30:16:68:ED:CD:61:20:61:F3:D0:BA:17:35:2A:74:87:E4:D3:A1:32
                DirName:/C=IT/ST=Calabria/L=Catanzaro/O=Vittorio Benintende/CN=client.morzello.com/emailAddress=noreply@morzello.com
                serial:09:DB:34:A3:DA:3F:56:BC

            X509v3 Basic Constraints:
                CA:TRUE
Certificate is to be certified until Jun 30 09:18:53 20xx GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

A questo punto possiamo eliminare la richiesta:

rm /etc/pki/CA/newcerts/new_req.pem

Verifiche e test sui certificati

Per visualizzare le informazioni relative ad un certificato basta indicare gli argomenti che interessano, come ad esempio: l’emittente, la data di scadenza, l’hash md5, il fingerprint, …

openssl x509 -noout -subject -issuer -enddate -hash -fingerprint -in /etc/pki/CA/certs/new.crt

Il parametro -noout indica ad openssl che non c’è un output da gestire.

Per verificare la validità di un certificato si può utilizzare il comando:

openssl verify -CAfile /etc/pki/CA/cacert.pem /etc/pki/CA/certs/new.crt
/etc/pki/CA/certs/new.crt: OK

Installare i certificati in Windows

In Windows l’installazione dei certificati merita un po’ di attenzione perchè è necessario fare una conversione se si utilizza l’esempio riportato in alto. Per metabolizzare il certificato infatti Windows ha bisogno del formato PKCS#12. Per ottenere questo possiamo utilizzare il seguente comando:

openssl pkcs12 -export -in /etc/pki/CA/certs/new.crt \
-inkey /etc/pki/CA/private/new.key -out /etc/pki/CA/certs/new.p12 -clcerts

A questo punto viene eventualmente richiesta la password per l’esportazione del certificato.

Per importare i certificati e le CA all’interno del sistema operativo basta cliccare sul file e seguire le istruzioni del wizard proposte a video. Un certificato può essere installato per il singolo utente o per la macchina (con credenziali amministrative).

Se si desidera avere maggior controllo si può invece utilizzare la Microsoft Management Console (mmc.exe)  aggiungendo l’apposito snap-in:

file -> aggiungi/rimuovi snap-in...
aggiungi -> certificati -> account del computer

Dovreste trovarvi in una situazione simile a quella riportata in foto:


Alla prossima.

OpenVPN – NTLM e quel proxy infame

Questo articolo è rivolto a coloro che hanno problemi a far dialogare OpenVPN con proxy che richiedono autenticazione NTLM.

Al momento della stesura di questo articolo, la versione di ovpn è la 2.1.3, versioni successive a questa potrebbero non soffrire dello stesso male.

Utilizzando l’autenticazione di tipo NTLM ho notato che la comunicazione si interrompe subito dopo l’invio del messaggio di tipo 1 da parte del client. In pratica il proxy non si degna di dare una risposta negativa o positiva che sia.

Per maggiori informazioni sulla comunicazione tipo NTLM potete visitare il sito:

http://davenport.sourceforge.net/ntlm.html

Dando uno sguardo al codice sorgente ho notato che la stringa inviata dal client al proxy è la seguente:

TlRMTVNTUAABAAAAAgIAAA==

ed è una costante definita nel file ntlm.c

Dopo aver portato a termine qualche prova con uno sniffer di rete mi sono accorto che altri prorammi come ad esempio firefox, funzionano perfettamente con il proxy così mi sono chiesto quali fossero le differenze. In effetti il messaggio di fase 1 inviato dal browser è sostanzialmente diverso:

TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==

e sembra essere più gradito.

A questo punto ho modificato il codice sorgente nell’unica riga necessaria:

const char *
ntlm_phase_1 (const struct http_proxy_info *p, struct gc_arena *gc)
{
  struct buffer out = alloc_buf_gc (96, gc);
  /* try a minimal NTLM handshake
   *
   * http://davenport.sourceforge.net/ntlm.html
   *
   * This message contains only the NTLMSSP signature,
   * the NTLM message type,
   * and the minimal set of flags (Negotiate NTLM and Negotiate OEM).
   *
   */
  // buf_printf (&out, "%s", "TlRMTVNTUAABAAAAAgIAAA==");
   buf_printf (&out, "%s", "TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==");
  return (BSTR (&out));
}

e dopo aver ricompilato l’eseguibile, tutto funziona correttamente.

Alla prossima.

MySQL – abilitare l’accesso a root dalla rete

Può capitare a volte di voler accedere all’istanza presente su una macchina dalla quale non è possibile utilizzare strumenti visuali quali:

  • MySQL Administrator
  • MySQL Workbench

è ad esempio il caso di CentOS, dove questi strumenti sono difficili da installare. A mio avviso un metodo veloce per arginare il problema è quello di utilizzare il comando mysql in locale per abilitare l’accesso all’utente root dalla rete. Una volta apportate tutte le modifiche del caso, sarà sufficiente ristabilire le restrizioni volute.

Per accedere alla console di mysql basta usare il comando:

mysql -uroot -p

dopo aver digitato la password ci ritroveremo nell’ambiente del db e potremo abilitare l’accesso dall’esterno con due comandi:

grant all privileges on mysql.* to root@"NOMEPC" identified by 'MIA_PASSWORD';
flush privileges;

Dove NOMEPC è l’indirzzo della macchina dalla quale vogliamo accedere (indicando ‘%’ abilitiamo tutta la rete) e MIA_PASSWORD è la password che vogliamo usare per la connessione.

Ora è possibile fare le modifiche del caso da un altro pc.

Alla prossima.

Usare Ping In Script Batch

Tempo fa avevo presentato un articolo che mostra come utilizzare il comando ping all’interno di un batch script:

http://www.morzello.com/dblog/articolo.asp?articolo=41

Come spiegato, il comando restituisce sempre lo stesso errorlevel, rendendo vano un eventuale tentativo di capire se il ping è andato a buon fine o meno all’interno di uno script.

Oggi presento una variante che consente di ottenere lo stesso risultato senza dover scrivere codice vbscript.

Di seguito trovate un piccolo file .BAT (o .CMD) che potete utilizzare per testare l’esito di un ping:

ping nomeserver | findstr "TTL="
echo %errorlevel%

Mentre il comando ping restituisce sempre lo stesso errorlevel, findstr discrimina l’uscita a seconda che nell’output esista o meno una corrispondenza utile. A questo punto possiamo testare l’uscita del comando findstr invece che di ping.

Alla prossima.

Ternimal Server e l’errore: “il dominio specificato non esiste…”

“The specified domain either does not exist or could not be contacted” è un errore che è possibile riscontrare quando si tenta un logon con utenza di dominio in terminal server (remote desktop). Capita quando ad esempio la macchina a cui si tenta di fare l’accesso è momentaneamente scollegata dal dominio ovvero quando il dominio non è raggiungibile.

Di solito questo problema viene risolto ripristinando la connessione con il domain controller. Ci sono dei casi in cui la connessione manca per motivi non legati alla funzionalità del server. Poniamo ad esempio il caso in cui volessimo accedere ad un portatile aziendale situato temporaneamente fuori dalla rete aziendale.

Per utilizzare le credenziali presenti sulla macchina evitando l’interruzione della connessione in caso di mancanza del domain controller è possibile mettere mano al file di registro con credenziali amministrative.

E’ sufficiente creare un file di testo con estensione “.reg” e inserire il seguente contenuto:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
"IgnoreRegUserConfigErrors"=dword:00000001



Basta poi cliccare due volte sul file per inserire i dati nel registro di sistema.

Alla prossima.

Sono io oppure il sito è proprio giù?

Ieri mi è capitato di impazzire nel tentativo di capire se il sito di Google fosse giù o se più semplicemente era la mia connessione ad avere problemi.

Poi ho trovato un modo semplice e veloce di fare una verifica.

In pratica ho demandato ad un sito posto dall’altro capo del mondo di fare una richiesta al server da parte mia. Si tratta di un metodo alternativo all’uso di ping e traceroute vari dal momento che non fa uso di traffico icmp.

Per chi volesse fare un giro sul sito in questione, di seguito troverà il link:

http://downforeveryoneorjustme.com/

Per chi volesse testare direttamente la destinazione dall’url può digiare il link nel formato:

http://downforeveryoneorjustme.com/nomesito dove per nomesito si intende il nome dell’host.

Per Google ad esempio potreste scrivere:

http://downforeveryoneorjustme.com/www.google.com

Alla prossima.

IPCop – Come aprire la rete Green alla rete Blue

La Blue Net di IPCop serve ad interfacciare una connettività wifi che si ntende mantenere separata dalla rete locale LAN (Green Net). Questo per consentire una maggiore sicurezza, dal momento che gli endpoint che si collegano ad IPCop tramite wifi non vedranno la rete locale a meno di aprire le porte desiderate per i protocolli TCP ed UDP.

IPCop però non supporta nativamente il bridging delle schede di rete e non risulta agevole simulare il comportamento tipico dei router adsl comunemente in commercio nei negozi al giorno d’oggi. Non c’è modo infatti, tramite interfaccia grafica, di consentire il pieno accesso alla Green Net da parte dei computer che si collegano per mezzo della wifi (vedi ad esempio il trafico ICMP).

Mi è capitato di recente di installare una versione di IPCop con supporto wifi per mezzo dell’addon WLAN-AP e di dover simulare proprio il tipico comportamento dell’Access Point, dove la rete cablata è condivisa con quella senza fili.

Per abilitare tutto il traffico ho inserito alcune righe nel file /etc/rc.d/rc.firewall.local che è il file contenente i comandi da impartire al sistema operativo durante il boot per personalizzare le regole di firewalling senza interferire con la distribuzione:

/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p icmp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p tcp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p udp -j ACCEPT

Queste righe sono state inserite nella sezione start (ovviamente). In linea di principio, per abiitare un protocollo è sufficiente impartire il comando secondo a forma:

/sbin/iptables -A CUSTOMFORWARD -i 'blue device' -o 'green device' -p 'protocollo' -j ACCEPT

Per comodità, di seguito è riportato un esempio di rc.firewall.local che svolge questa attività:

#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
#morzello blue vs green
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p icmp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p tcp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p udp -j ACCEPT
;;
stop)
## add your 'stop' rules here
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac

Spero che questo articolo possa essere utile a chi deve ottenere questo risultato.

Un Domain Controller in CentOS/Fedora per la piccola e media impresa

In questo articolo viene proposto un modo facile e veloce di creare un DC (Domain Controller) per ambienti Windows utilizzando Samba.
Va detto che la soluzione è dimensionata per la piccola e media impresa, dove il numero di utenti generalmente non supera le cento unità.
Facile e veloce perché impiega un solo server e non prevede ridondanza.
Per l’articolo ho scelto di utilizzare CentOS ma dovrebbe funzionare anche con Fedora.

Prerequisiti
La soluzione prevede il deployment all’interno di una rete locale (LAN); si presuppone dunque che i servizi di DNS (per la risoluzione dei nomi) e DHCP (per l’assegnazione automatica degli indirizzi IP) funzionino a dovere.
La lista della spesa Per far girare “il tutto” è necessario installare sulla macchina alcuni pacchetti fondamentali di samba. Per verificare i pacchetti già installati è sufficiente usare yum:

[root@myserver ~]# yum list *samba*
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.fastbull.org
 * updates: centos.fastbull.org
 * addons: centos.fastbull.org
 * extras: centos.kiewel-online.ch base
Installed Packages
 samba.i386	3.0.33-3.7.el5_3.1	installed
 samba-client.i386		3.0.33-3.7.el5_3.1	installed
 samba-common.i386		3.0.33-3.7.el5_3.1	installed
 system-config-samba.noarch	1.2.41-3.el5		installed
 Available Packages
 samba-swat.i386		3.0.33-3.7.el5_3.1	updates
 sblim-cmpi-samba.i386		0.5.2-31.el5_2.1	base
 sblim-cmpi-samba-devel.i386	1-31.el5_2.1		base
 sblim-cmpi-samba-test.i386	1-31.el5_2.1		base

Nel nostro caso samba è già installato. Nel caso in cui fosse necessario installare il software possiamo sempre utilizzare yum:

yum install samba

I pacchetti fondamentali sono:

samba.i386 samba-common.i386system-config-samba.noarch

Degli altri possiamo anche farne a meno.

Personalizzare il servizio
Nel nostro caso, Samba dovrà funzionare come DC, per questo motivo è necessario editare il file /etc/samba/smb.conf indicando le corrette impostazioni. Di seguito un esempio di configurazione possibile:

[global]
        workgroup = MORZELLO
        server string = Samba Server Version %v
        netbios name = MYSERVER
        security = user
        passdb backend = tdbsam
        domain master = yes
        domain logons = yes
        logon script = %m.bat
        logon script = %u.bat
        logon path =
        add user script = /usr/sbin/useradd "%u" -n -g users
        add group script = /usr/sbin/groupadd "%g"
        add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u"
        delete user script = /usr/sbin/userdel "%u"
        delete user from group script = /usr/sbin/userdel "%u" "%g"
        delete group script = /usr/sbin/groupdel "%g"
        username map = /etc/samba/smbusers
        lanman auth = no
        ntlm auth = Yes
        client NTLMv2 auth = Yes
        client lanman auth = no
        client plaintext auth = no
        winbind enum groups = yes
        winbind enum users = yes
        wins support = yes

[homes]
        comment = Home Directories
        browseable = no
        writable = yes

Il file di configurazione contiene solo ed esclusivamente i dati strettamente necessari per far funzionare il servizio come PDC (Primary Domain Controller). Probabilmente il lettore vorrà successivamente attivare altre voci come ad esempio le stampanti di rete e le cartelle di rete. Queste informazioni non sono strettamente necessarie e per questo motivo non sono trattate in questa sede. Per dare un senso al nostro operato cerchiamo di capire il significato delle voci principali che compongono il nostro file di configurazione:

  • workgroup: indica il nome del nostro dominio;
  • passdb backend: indica come samba gestirà le utenze windows. specificando tdbsam samba autenticherà gli utenti e le macchine appartenenti al dominio mediante il proprio database, senza utilizzare servizi esterni come ad esempio LDAP oppure un altro DC;
  • *script: sono le voci che indicano quali script eseguire per gestire gli utenti ed i gruppi;
  • logon path: è il percorso della cartella che contiene informazioni di netlogon di Windows. Nell’esempio si è deciso di non fornire questo servizio;
  • domain logons: indica se il server agirà come DC oppure no;
  • domain master: indica se il server agirà come PDC oppure no.

Per capire se la nostra configurazione è valida o meno possiamo usare il comando testparm:

[root@myserver ~]# testparm -s
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Loaded services file OK.
Server role: ROLE_DOMAIN_PDC
[global]
        workgroup = MORZELLO
        server string = Samba Server Version %v
        passdb backend = tdbsam
        username map = /etc/samba/smbusers
        lanman auth = No
        client NTLMv2 auth = Yes
        client lanman auth = No
        client plaintext auth = No
        log level = 2
        log file = /var/log/samba/%m.log
        add user script = /usr/sbin/useradd "%u" -n -g users
        delete user script = /usr/sbin/userdel "%u"
        add group script = /usr/sbin/groupadd "%g"
        delete group script = /usr/sbin/groupdel "%g"
        delete user from group script = /usr/sbin/userdel "%u" "%g"
        add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u"
        logon script = %u.bat
        logon path =
        domain logons = Yes
        domain master = Yes
        wins support = Yes
        winbind enum users = Yes
        winbind enum groups = Yes

[homes]
        comment = Home Directories
        read only = No
        browseable = No

È fondamentale che la voce server role sia quella corretta.

L’utenza amministrativa
Per poter gestire il dominio è necessario aggiungere nel database di samba l’utente amministratore:

[root@myserver samba]# smbpasswd -a root
New SMB password:
Retype new SMB password:
tdbsam_open: Converting version 0 database to version 3....
Added user root.

Gli utenti di dominio
Gli utenti samba sono in realtà utenti linux e bisogna dare una regola per convertire correttamente gli utenti tra linux e windows. Per fare questo personalizziamo il file /etc/samba/smbusers:

# Unix_name = SMB_name1 SMB_name2 ...
root = administrator admin
nobody = guest pcguest smbguest

Nel nostro caso ci limitiamo a dire che l’utente administrator equivale a root e che l’utente guest equivale a nobody. Aggiungiamo anche i gruppi di utenti windows che non esistono ancora in linux:

# Map Windows Domain Groups to UNIX groups
net groupmap add rid=514 ntgroup="Domain Guests" unixgroup="nobody" type=d
net groupmap add rid=513 ntgroup="Domain Users" unixgroup="users" type=d
net groupmap add rid=512 ntgroup="Domain Admins" unixgroup="root" type=d

Si possono aggiungere anche altri gruppi di utenti, quelli specificati in alto sono quelli “canonici”. Per verificare che i gruppi siano stati creati possiamo usare il comando wbinfo:

[root@myserver samba]# wbinfo -g
domain users
domain admins
domain guests

Aggiungendo gli utenti di dominio ricordiamo sempre che questi sono anche utenti Linux. È probabile però che non tutti gli utenti dovranno avere accesso al server come utenti locali. Per inibire l’accesso alla console del server specificheremo una shell non valida. Su CentOS possiamo creare un utente con queste caratteristiche usando il comando adduser:

[root@myserver samba]# adduser -m -s /sbin/nologin testuser
[root@myserver samba]# passwd testuser
[root@myserver samba]# smbpasswd -a testuser

Con precedenti comandi abbiamo creato un utente, assegnato una password per linux ed una per samba.
Un metodo alternativo per creare gli utenti è quello di accodare direttamente gli utenti nel file /etc/passwd senza assegnare la password all’utente.
A pensarci bene non è necessario assegnare una password ad un utente che non può fare il logon. Se invece l’utente deve comunque avere l’accesso al server è sufficiente omettere il parametro “–s”.
Comunque sia per abilitare l’utente al dominio è necessario inserirlo nel database di samba con il comando smbpasswd.
Da notare che la password per linux può essere diversa da quella specificata in samba. Eseguire il servizio all’avvio In CentOS i servizi possono essere gestiti facilmente mediante il comando chkconfig.
Le righe seguenti assicurano l’avvio del servizio all’accensione del nostro server:

chkconfig smb on

Ultimi ritocchi: iptables e selinux
Samba necessita di alcune porte tcp ed udp per poter funzionare correttamente. Queste porte sono chiude per default da iptables. Di seguito le righe da inserire nel file /etc/sysconfig/iptables:

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT

Le righe devono essere inserite nel file prima delle ultime due stringhe:

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Per quanto concerne selinux invece bisogna consentire a samba l’uso dei comandi necessari per svolgere alcuni task:

# Se si intende usare useradd/groupadd è necessario eseguire:
setsebool -P samba_domain_controller on
#
# Se si vuole condividere la home degli utenti eseguire:
setsebool -P samba_enable_home_dirs on

Per condividere una cartella di rete bisogna assegnare alla stessa l’etichetta “samba-share_t”. Evitate le cartelle di sistema perché queste probabilmente hanno una etichetta diversa già applicata. Per verificare i dettagli di una cartella relativa a selinux è possibile usare il comando ls specificando il paramentr “–Z”:

ls -ldZ /percorso_completo

Aggiungere una workstation al dominio
La procedura di Join è totalmente trasparente in windows.
Per aggiungere una macchina al dominio possiamo cliccare con il tasto destro del mouse su “Gestione Risorse” quindi selezionare il percorso :“Proprietà->Nome Computer->Cambia”. Specificare MORZELLO nella casella “dominio” e procedere al logon di root con la password indicata in samba (mediante il comando smbpasswd).

Alla prossima.