Il blog sull'informatica

Recentemente ho installato da un amico un proxy basato su Squid. Ora, per bloccare il traffico diretto alle porte http, https ed http-alt ho utilizzato un firewall (Iptables), mentre per il controllo dei contenuti Web mi sono avvalso di squidGuard.

Dopo aver effettuato diverse prove di navigazione ed aver constatato che tutto funzionava correttamente, lascio la mia postazione e mi dirigo a casa per godermi un po' di meritato riposo. Peccato però che dopo qualche minuto mi chiama il mio amico lamentando l'impossibilità di scaricare gli aggiornamenti di Windows.

Uhm, mi sa che qui abbiamo a che fare con Windows Update 5... bene, vorrà dire che forzerò le workstation (4 Win-XP) ad utilizzare il proxy anche in fase di download degli aggiornamenti.

Ritorno dunque dall'amico e comincio a lanciare tale comando su ciascuna postazione di lavoro:

C:> proxycfg -p proxy.cliente.lan:3128

Successivamente, digito il comando (come ulteriore verifica):

C:> proxycfg

A questo punto procedo con il download degli aggiornamenti e tutto funziona come dovrebbe.

A presto.

PS: ovviamente in nessuna delle 4 macchine coinvolte veniva utilizzato IE come browser predefinito (per ragioni di sicurezza). In caso contrario avrei potuto lanciare il comando:

C:> proxycfg -u

al posto di:

C:> proxycfg -p proxy.cliente.lan:3128

impostando come proxy quello usato da IE.

Molto spesso mi capita di dover cercare una determinata stringa su più file presenti in una directory. Per fare ciò il comando cat * | grep stringa non è sufficiente, in quanto non mi dice in quali file si trova la stringa che sto cercando.

A tal proposito è sufficiente utilizzare soltanto il comando grep con la flag -H:

nightfly@nightbox:~$ grep -H prova *

oppure

nightfly@nightbox:~$ grep -H prova /directory/name

Un'altra flag che spesso mi torna utile è quella relativa alla ricerca inversa:

nightfly@nightbox:~$ grep -v prova nomefile

così facendo individuerò tutte le righe del file in cui non è presente la parola prova.

Tenete bene a mente entrambi i comandi, sicuramente potranno servirvi.

A presto.

Uno dei tuning fondamentali per rendere sicuro il nostro Web server Apache consiste nel disabilitare il directory listing. Infatti, non è raro imbattersi in dei siti su cui è possibile visualizzare il contenuto delle directory in essi contenute, quali images, doc e compagnia bella (i termini Google hacking e la dork intitle:Index of vi dicono qualcosa?).

Bene, per prima cosa è necessario aprire in lettura il file default (default-ssl se il vostro server utilizza il protocollo criptato https) che si trova nella dir /etc/apache2/sites-available:

nightfly@nightbox:/etc/apache2/sites-available$ sudo nano default

Adesso, nella sezione riportata di seguito rimuoviamo l'opzione Indexes:

      <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

In questo modo, tale sezione deventerà:

     <Directory /var/www/>
                Options FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
     </Directory>

Riavviamo Apache per rendere effettive le nuove impostazioni lanciando il comando:

nightfly@nightbox:/etc/apache2/sites-available$ sudo service apache2 restart

ed il gioco è fatto.

A presto.

Che Snort generi una miriade di falsi positivi durante il normale utilizzo della rete è abbastanza risaputo. Ultimamente, però, ho notato la presenza, piuttosto insistente, di notifiche simili alle seguenti:

[**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**]
[Priority: 3]
05/12-21:23:59.624917 192.168.*.*:1299 -> 212.52.84.153:80
TCP TTL:128 TOS:0x0 ID:5340 IpLen:20 DgmLen:98 DF
***AP*** Seq: 0xC593D3E7  Ack: 0x1DDBAA89  Win: 0xFFFF  TcpLen: 20

A quanto pare il preprocessore http_inspect si altera perchè nota la presenza di un doppio meccanismo di codifica mentre si naviga sulla webmail di Libero (per la precisione mailbeta.libero.it). Il fatto che venga utilizzata questa tecnica di codifica non è un'anomalia, semplicemente moltissimi siti Web preferiscono codificare più volte le variabili in modo da garantire un livello di sicurezza più elevato.

Come procedere quindi per disabilitare l'alert in questione?

Una soluzione abbastanza rapida consiste nel modificare il file threshold.conf presente nella directory /etc/snort/:

nightfly@nightbox:/etc/snort$ sudo nano threshold.conf

Aggiungendo la stringa:

suppress gen_id 119, sig_id 2

Adesso verifico che il file threshold.conf venga effettivamente utilizzato da snort.conf:

nightfly@nightbox:/etc/snort$ sudo nano snort.conf

A tal proposito è sufficente decommentare la stringa:

# include threshold.conf

che diventerà:

include threshold.conf

Riavvio infine Snort mediante il comando:

nightfly@nightbox:/etc/snort$ sudo service snort restart

e questo piccolo tuning è stato completato.

A presto.

Questa mattina, analizzando i log di IPTABLES su alcune delle macchine che gestisco, ho notato la presenza di 5 miliardi di messaggi del tipo:

May  5 13:31:02 fw-scar kernel: [868646.974533] Spoofed traffic detected: IN=eth1 OUT= MAC= SRC=10.*.*.* DST=224.0.0.251 LEN=74 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=54
May  5 13:31:04 fw-scar kernel: [868648.976380] Spoofed traffic detected: IN=eth1 OUT= MAC= SRC=10.*.*.* DST=224.0.0.251 LEN=74 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=54
May  5 13:58:15 fw-scar kernel: [870280.768746] Spoofed traffic detected: IN=eth1 OUT= MAC= SRC=10.*.*.* DST=224.0.0.251 LEN=74 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=54
May  5 13:58:16 fw-scar kernel: [870281.770192] Spoofed traffic detected: IN=eth1 OUT= MAC= SRC=10.*.*.* DST=224.0.0.251 LEN=74 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=54
May  5 13:58:18 fw-scar kernel: [870283.772627] Spoofed traffic detected: IN=eth1 OUT= MAC= SRC=10.*.*.* DST=224.0.0.251 LEN=74 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=54

Uhm, quell'indirizzo di multicast mi ricorda qualcosa... ma certo! E' l'indirizzo utilizzato da mDNS (la m ovviamente sta per multicast). In particolare, tale protocollo viene impiegato dall'utility Zeroconf per consentire "l'autoconfigurazione" delle interfacce di rete, più precisamente per individuare gli hostname delle macchine presenti in LAN e dei record DNS caricati localmente su di esse.

La regola di IPTABLES che ha generato tale log è la seguente:

iptables -A INPUT -s 10.0.0.0/8 -i eth1 -j LOG --log-prefix "Spoofed traffic detected: " --log-level 4

che, per evitare ulteriore entry simili a quelle riportate in precedenza, dovrà diventare:

iptables -A INPUT -s 10.0.0.0/8 ! -d 224.0.0.251 -i eth1 -j LOG --log-prefix "Spoofed traffic detected: " --log-level 4

Così facendo, il packet filtering non identificherà le richieste mDNS come traffico anomalo.

A presto.

Recentemente, tentando di installare alcune regole IPTABLES direttamente sul firewall mediante SCP, ho riscontrato la presenza del seguente messaggio di errore:

debug: Next authentication method: gssapi-with-mic
debug: An invalid name was supplied
Cannot determine realm for numeric host address

debug: An invalid name was supplied
Cannot determine realm for numeric host address

debug: An invalid name was supplied
Cannot determine realm for numeric host address

Uhm, evidentemente il problema sta proprio nel metodo di autenticazione, ovvero nel gssapi-with-mic.

Cosa fare dunque? Bhè, semplice... disabilitare tale metodo di autenticazione. Apro quindi in scrittura il file ssh_config presente nella directory /etc/ssh

nightfly@nightbox:~$ sudo nano /etc/ssh/ssh_config

e modifico la direttiva associata a GSSAPIAuthentication da yes a no.

Salvo il file ed il problema è stato risolto.

A presto.

Qualche giorno fa, mentre scrivevo del codice server-side per un piccolo CRM homemade, ho avuto la necessità di ricavare dei dati mediante la UNION di due SELECT. In particolare, il codice SQL che ho utilizzato è il seguente:

SELECT 'Entrata' AS NomeTabella, O.ID, O.NumeroOperazione, E.Descrizione, E.Tipo, O.Importo, O.DataInserimento, O.DataOperazione FROM entrata AS E, riguarda AS R, operazione AS O WHERE O.ID = R.IDOperazione AND R.IDEntrata = E.ID AND (E.Tipo = 'Cassa' OR E.Tipo = 'Banca') UNION SELECT 'Uscita' AS NomeTabella, O.ID, O.NumeroOperazione, U.Descrizione, U.Tipo, O.Importo, O.DataInserimento, O.DataOperazione FROM uscita AS U, riguarda AS R, operazione AS O WHERE O.ID = R.IDOperazione AND R.IDUscita = U.ID AND (U.Tipo = 'Cassa' OR U.Tipo = 'Banca') ORDER BY DataInserimento

Ora, come potete notare le due SELECT vengono applicate su diversi JOIN ed hanno come obiettivo quello di restituire alcuni informazioni importanti, quali il numero dell'operazione finanziaria, la descrizione dell'operazione stessa, il suo importo, ecc. Ovviamente, affinchè i risultati non venissero ripetuti più volte ho utilizzato solo l'operatore UNION (che prevede un DISTINCT implicito) senza la direttiva ALL. Inoltre, per distinguere la tabella di provenienza dei record selezionati, ho creato un ulteriore campo temporaneo, a cui è stato associato l'alias NomeTabella. Così facendo, la struttura della tabella risultante è diventata la seguente:

Nometabella, ID, NumeroOperazione, Descrizione, Tipo, Importo, DataInserimento, DataOperazione

Da quel momento è stato possibile distinguere piuttosto banalmente la tabella di appartenenza dei record visualizzati.

Bye.

NB: affinchè la UNION possa essere applicata è necessario che le due SELECT riguardino lo stesso numero (e tipologie compatibili) di campi.