Il blog sull'informatica

Premesso che esistono tantissimi mail agent per i sistemi *nix, questa guida ha come scopo quello di illustrare una configurazione minimale (ma funzionale) di postfix su CentOS.

Per prima cosa è necessiario installare tale applicativo. Per semplicità utilizzeremo yum:

[nightfly@centosbox ~]# yum install postfix

Una volta completata l'installazione del pacchetto occorre passare alla sua configurazione. In particolare, vogliamo che postfix invii ad un server SMTP esterno (smarthost) il nostro messaggio di posta, il quale verrà successivamente recapitato sulla nostra mailbox (ad esempio @email.it).

A tal proposito, sarà necessario creare il file sender_canonical all'interno della dir /etc/postfix:

[nightfly@centosbox postfix]# touch sender_canonical

La sintassi da utilizzare all'interno di questo file è la seguente:

<nome utente> <indirizzo di posta da usare come mittente>

Ad esempio:

nightfly nightfly@miodominio.it

Ovviamente il nome del dominio deve essere valido, altrimenti il server SMTP esterno risponderà picche.

A questo punto lanciamo il comando:

[nightfly@centosbox postfix]# postfix sender_canonical

attraverso il quale postfix creerà un file sender_canonical.db da utilizzare per individuare l'indirizzo di posta del mittente in fase di invio.

Modifichiamo infine il file main.cf aggiungendo la seguente stringa:

sender_canonical_maps = hash:/etc/postfix/sender_canonical

Riavviamo postfix:

[nightfly@centosbox postfix]#service postfix restart

ed inviamo una mail di prova utilizzando il comando mail:

[nightfly@centosbox postfix]# mail vostroindirizzo@email.it

Diamo un'occhiata al file messages nella dir /var/log, magari utilizzando un | grep postfix:

[nightfly@centosbox postfix]#cat /var/log/messages | grep postfix

e se otteremo un output simile al seguente:

Oct 29 10:24:42 test-monitor postfix/smtp[7611]: 80FC8301F1: to=<indirizzo@email.it>, relay=mx.email.it[212.97.34.36]:25, delay=0.32, delays=0.07/0/0.04/0.22, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C4F714400C)

vuol dire che la nostra mail è stata inviata con successo.

See ya.

Recentemente ho stotituito l'HD di share sulla mia linux box con uno più capiente. A tal proposito ho dovuto dapprima partizionare e successivamente formattare il nuovo hard disk. Vediamo come.

Per prima cosa ho individuato il nome periferica assegnato dal sistema operativo al disco rigido, semplicemente lanciando un ls nella directory /dev (il nuovo hard disk è stato riconosciuto come sdb).

Ora, conoscendo il nome della periferica, posso procedere con la partizione della stessa utilizzando il tool fdisk, il cui usage è il seguente:

nightfly@nightbox:/dev$ fdisk

Usage:
fdisk [options] <disk>    change partition table
fdisk [options] -l <disk> list partition table(s)
fdisk -s <partition>      give partition size(s) in blocks

Options:
-b <size>                      sector size (512, 1024, 2048 or 4096)
-c                                    switch off DOS-compatible mode
-h                                    print help
-u <size>                      give sizes in sectors instead of cylinders
-v                                    print version
-C <number>               specify the number of cylinders
-H <number>               specify the number of heads
-S <number>               specify the number of sectors per track

Digitiamo dunque:

nightfly@nightbox:/dev$ sudo fdisk /dev/sdb

Visualizziamo il menù di fdisk digitando m ed in seguito digitiamo w che sta per write table to disk and exit

A partizionamento avvenuto possiamo procedere con la formattazione del disco rigido, utilizzando il tool mkfs:

nightfly@nightbox:/dev$ mkfs
Uso: mkfs [-V] [-t tipofs] [opzioni-fs] dispositivo [dimensione]

Da questa breve descrizione è facile intuire che il comando da lanciare sarà il seguente:

nightfly@nightbox:/dev$ sudo mkfs -t ext3 /dev/sdb

dove ext3 è il tipo di filesystem scelto.

Editiamo, infine, il file fstab presente nella directory /etc semplicemente digitando:

nightfly@nightbox:/dev$ sudo nano /etc/fstab

Tale file avrà un aspetto simile al seguente:

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>                     <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid                            0               0
/dev/sda       /              ext3    errors=remount-ro                                0               1
# swap was on /dev/sda5 during installation
UUID=xxx        none            swap    sw                                                      0               0
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8     0               0

Aggiungiamo la seguente stringa:

/dev/sdb       /media/disk     ext3    rw,user,noauto,nosuid,utf8     0               0

Dove /media/disk sarà il punto di mount del nostro hard disk (per i sistemi *buntu tale dir viene creata automaticamete), ext3 è il tipo di partizione presente all'interno del disco rigido, le opzioni rw,user,noauto,nosuid,utf8 indicano rispettivamente che si può accedere al disco sia in lettura che in scrittura (rw), che la partizione è montabile anche da un utente che non ha privilegi di root (user), che la partizione non deve essere montata al boot della macchina (noauto), che i bit del suid non vengono presi in considerazione (nosuid) e che il charset da utilizzare è utf8. Ovviamente queste non sono le uniche opzioni disponibili, per maggiori dettagli vi rimando al man di fstab.

Bene, digitiamo:

root@nightbox:~# mount /media/disk

e finalmente potremo usare il nostro nuovo HD. Bye.

Mettiamo il caso che si voglia scaricare un file mediante mldonkey, ma che la macchina su cui gira tale applicativo sia raggiungibile solo da remoto. Mettiamo inoltre il caso che tale macchina accetti esclusivamente connessioni cifrate via SSH. Come fare dunque per lanciare un download? La risposta è semplice.

Per prima cosa sarà necessario lanciare una sessione SSH verso la macchina di destinazione, utilizzando ad esempio PuTTY (potete scaricarlo da qui, è gratuito).

A questo punto lanciamo un nmap e verifichiamo che la porta 4000 sia in ascolto su localhost:

nightfly@nightbox:~$ nmap localhost | grep 4000

Dovremmo ottenere un output del tipo:

4000/tcp open  remoteanything

Lanciamo quindi il comando:

nightfly@nightbox:~$ telnet localhost 4000

e visualizzaremo un prompt del tipo:

Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Welcome to MLDonkey 3.0.1
Welcome on mldonkey command-line

Use ? for help

MLdonkey command-line:
>

A questo punto siamo dentro la console dei comandi di mldonkey. Autentichiamoci digitando:

auth <username> <password>

e successivamente lanciamo il download di un link (e2k, ftp, torrent e così via) mediante il comando:

dllink <link>

Verifichiamo infine che il download sia effettivamente attivo scrivendo in console:

vd

Ecco fatto, il download è in esecuzione sulla macchina remota. A presto.

Circa un annetto fa ho sviluppato un piccolo client (scritto interamente in linguaggio C) che si interfaccia ad un database Mysql. Ora, per fare in modo che l'interfacciamento con il database possa avvenire, è necessario utilizzare la libreria mysql.h da inserire all'interno del codice sorgente mediante la classica direttiva #include.

Una volta completata la stesura del codice, è necessario scaricare la libreria che consentirà al nostro client di interrogare il database. Per fare ciò occorrerà utilizzare il comando (su piattaforma *buntu):

nightfly@nightbox:~$ sudo apt-get install libmysqlclient-dev

Installiamo il compilatore per generare l'eseguibile partendo dal sorgente:

nightfly@nightbox:~$ sudo apt-get install gcc

Successivamente, occorrerà compilare il sorgente sfruttando gcc e la libreria mysqlclient:

nightfly@nightbox:~$ sudo gcc -o nome_eseguibile sorgente.c -l mysqlclient

A questo punto possiamo avviare l'eseguibile digitando:

nightfly@nightbox:~$ ./nome_eseguibile

Ecco fatto. A presto.

Recentemente ho notato un'anomalia durante la fase di boot del mio PIX 501. In particolare, questo aggeggino non riusciva a caricare correttamente Finesse (ovvero il sistema operativo integrato) dalla memoria flash, in quanto il file *.bin risultava corrotto.

L'errore riscontrato era il seguente:

Checksum verification on uncompressed PIX image failed.

Poichè i vari tentativi di ping da e verso le interfacce del firewall in questione sono sistematicamente falliti, ho pensato bene di caricare nuovamente l'immagine del PIX OS. Per fare ciò ho dovuto sfruttare il cosiddetto ROM Monitor, il qualche rappresenta una sorta di "modalità provvisoria" per i dispositivi Cisco.

Per accedervi è bastato riavviare il PIX e premere ESC. A questo punto ho provveduto a lanciare i seguenti comandi:

rommon> int 1

per attivare l'interfaccia "inside" del firewall;

rommon> address <indirizzo IP dell'interfaccia interna del PIX>

per assegnare un indirizzo all'interfaccia "inside" del firewall;

rommon> server <indirizzo IP del server TFTP>

in modo da istruire il PIX su quale indirizzo IP utilizzare per contattare il server TFTP;

rommon> file <nomefile.bin>

per specificare il nome dell'immagine relativa al PIX OS;

rommon> tftp

per avviare il trasferimento ed il salvataggio dell'immagine all'interno della memoria flash del PIX.

Una volta completato il salvataggio occorre riavviare il PIX ed il gioco è fatto.

A presto.

PS: tale guida non ha effetto nel caso in cui il checksum errato sia imputabile ad un guasto fisico della memoria flash.

L'analisi dei log rappresenta una delle operazioni più importanti dell'ambito della sicurezza dei sistemi, in quanto consente di individuare eventuali tentativi di attacco provenienti dall'esterno (Internet) o dall'interno (la nostra LAN oppure il nostro stesso PC). Inultile dire che, affinchè l'identificazione degli attacchi ed eventualmente degli attaccanti abbia buon fine, è assolutamente necessario che i log siano integri e non siano soggetti a possibili operazioni di tampering (alterazione), il cui scopo è proprio quello di confondere le acque e rendere più difficile il lavoro del sys/net admin di turno.

Ora, esistono sostanzialmente due metodi per attaccare direttamente i file di log: il primo consiste nall'alterazione diretta degli stessi attraverso l'inserimento di stringhe forgiate appositamente per rispecchiare la sintassi dei log creati dall'applicazione vittima; il secondo ha come obiettivo quello di inviare un numero molto elevato di attempt in modo da far aumentare le dimensioni dei file di log e provocare una sorta di attacco DoS basato sull'esaurimento di una risorsa fondamentale, ovvero la memoria di massa (leggasi spazio sull'hard disk).

Affinchè la manomissione dei log possa avvenire nonostante l'attaccante non abbia i permessi di scrittura su tale tipo di file, è indispensabile identificare la sintassi utilizzata in fase di logging dall'applicazione che si vuole attaccare.

Facciamo un esempio pratico. Supponiamo che l'attaccante, dopo una scansione mediante nmap, identifichi apache tra i servizi attivi sulla nostra macchina. L'accesso al sito Web è inoltre subordinato e vincolato dall'inserimento delle giuste credenziali (username e password), misura di sicurezza realizzata attraverso un file .htaccess. La prima cosa che farà l'attaccante sarà quella di studiarsi la sintassi che caratterizza i file di log dell'applicazione in questione. Una volta identificata tale sintassi, creerà delle righe apposite da inserire nei campi di input visualizzati dal browser ed il cui scopo è quello di permettere ad un utente di autenticarsi e quindi accedere ai contenuti del sito Web.

Un file di log non alterato potrebbe apparire nel seguente modo:

User login failed for: guest
User login failed for: admin

Nel caso in cui, però, l'attaccante inserisse nei campi di input la seguente stringa:

guest (backslash)nUser login succeeded for: admin

otterrebbe come risultato:

User login failed for: guest
User login succeeded for: admin

proprio grazie all'ausilio del carattere di newline (backslash)n.

Inutile dire che una semplice contromisura a questa tipologia di attacco si basa sulla validazione dell'input e sul whitelisting di determinati caratteri (ad esempio mediante l'uso delle espressioni regolari).

Per ciò che concerne invece gli attacchi DoS menzionati in precedenza, una valida contromisura è rappresentata da un uso corretto del logrotate, il quale consente di archiviare i file di log solo per un certo lasso di tempo, provvedendo anche alla compressione degli stessi per risparmiare spazio sull'hard disk.

Fine del post. See ya.

PS: mi dispiace per l'assenza del carattere backslash, ma a quanto pare myblog lo rifiuta categoricamente (credo per motivi di sicurezza).

In questo post abbiamo visto come configurare LAMP. Adesso vedremo come abilitare SSL sul nostro server Web Apache.

Per prima cosa è necessario generare un certificato SSL. A tale scopo possiamo utilizzare openSSL:

nightfly@nightbox:/etc/apache2$ sudo openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/apache.pem -keyout /etc/apache2/apache.pem

dove il parametro -x509 indica proprio che si tratta di un certificato appartenente allo standard X.509 ed il parametro -days specifica la durata della validità relativa al certificato stesso.

Una volta digitato il comando sopra citato verrà richiesto l'inserimento di tutta una serie di parametri necessari per caratterizzare il certificato stesso, quali nazione, città, nome della società, indirizzo e-mail, ecc.

Ora occorre abilitare il modulo SSL di Apache, sfruttando il tool a2enmod (apache2 enable module):

nightfly@nightbox:/etc/apache2$ sudo a2enmod ssl

E' necessario, inoltre, abilitare il virtual host SSL:

nightfly@nightbox:/etc/apache2$ sudo a2ensite default-ssl

Fatto ciò sarà necessario mettere in ascolto Apache sulla porta 443 (HTTPS), editando il file ports presente nella DIR /etc/apache2/ports. Il file in questione dovrà apparire nel seguente modo:

nightfly@nightbox:/etc/apache2$ cat ports.conf
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

NameVirtualHost *:80
Listen 80

<IfModule mod_ssl.c>
# SSL name based virtual hosts are not yet supported, therefore no
# NameVirtualHost statement here
Listen 443
</IfModule>

Posizioniamoci ora sulla cartella available-sites:

nightfly@nightbox:/etc/apache2$ cd sites-available/

ed editiamo il file default-ssl aggiungendo le seguenti righe di codice:

SSLEngine On
SSLCertificateFile /etc/apache2/apache.pem

e rimuovendo:

SSLCertificateFile /etc/ssl/private/ssl-cert-snakeoil.key

Riavviamo Apache mediante il comando:

nightfly@nightbox:/etc/apache2$ /etc/init.d/apache2 restart

E colleghiamoci al nostro server anteponendo HTTPS (e non HTTP) all'indirizzo. Accettiamo il certificato (anche se il browser lo segnala come inattendibile)... et voilà, siamo dentro il nostro sito Web.

A presto.