Archivi tag: linux

Tracert e traceroute messi a confronto

I comandi tracert (di casa Microsoft) e traceroute (di casa *nix) vengono utilizzati per enumerare gli hop (dispositivi di rete di livello 3, solitamente router) che attraversa un pacchetto fino a giungere a destinazione.

Ad esempio, se volessi individuare il percorso intrapreso da un pacchetto verso una data destinazione, posso lanciare il comando:

C:\Users\eldo>tracert 4.2.2.2

Traccia instradamento verso b.resolvers.Level3.net [4.2.2.2]
su un massimo di 30 punti di passaggio:

  1     3 ms     1 ms     2 ms  192.168.*.*
  2     *        *        *     Richiesta scaduta.
  3    14 ms    18 ms    17 ms  151.6.185.105
  4    32 ms    33 ms    31 ms  151.6.5.15
  5   124 ms   208 ms   218 ms  151.6.1.89
  6    45 ms    45 ms    45 ms  151.6.0.174
  7   117 ms   216 ms    51 ms  212.73.241.161
  8    52 ms    53 ms    54 ms  ae-14-14.ebr1.Frankfurt1.Level3.net [4.69.142.19]
4]
  9    59 ms    54 ms    55 ms  ae-61-61.csw1.Frankfurt1.Level3.net [4.69.140.2]

 10     *        *        *     Richiesta scaduta.
 11    55 ms    54 ms    54 ms  b.resolvers.Level3.net [4.2.2.2]

Traccia completata.

Gli hop non identificati (quelli caratterizzati dall’errore Richiesta Scaduta), non consentono un deteterminato tipo di traffico, nella fattispecie quello ICMP.

Infatti, il comando tracert basa il suo funzionamento sul suddetto protocollo.

Discorso diverso riguarda, invece, il comando traceroute:

 1  vodafone.station (10.*.*.*)  1.269 ms  1.247 ms  1.224 ms
 2  * * *
 3  * * *
 4  83.224.40.185 (83.224.40.185)  76.238 ms  76.338 ms  77.658 ms
 5  85.205.14.105 (85.205.14.105)  88.192 ms  81.755 ms  82.662 ms
 6  212.73.241.21 (212.73.241.21)  120.408 ms  102.599 ms  102.517 ms
 7  ae-0-11.bar2.Milan1.Level3.net (4.69.142.190)  72.483 ms  70.973 ms  69.436 ms
 8  ae-14-14.ebr1.Frankfurt1.Level3.net (4.69.142.194)  77.455 ms  76.717 ms  76.729 ms
 9  ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2)  77.707 ms ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6)  79.677 ms ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2)  77.714 ms
10  * * *
11  b.resolvers.Level3.net (4.2.2.2)  76.517 ms  77.154 ms  76.688 ms

tracert,traceroute,hop,icmp,ttl,windows,unix,linux,udp

Esso, infatti, basa il proprio funzionamento sul protocollo UDP (porta compresa tra 33434 e 33454). Esiste comunque un’opzione per fare in modo che il suddetto comando utilizzi il protocollo ICMP, ovvero -I:

nightfly@nightbox:~$ sudo traceroute -I 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 60 byte packets
 1  vodafone.station (10.1.1.1)  6.259 ms  6.270 ms  6.272 ms
 2  * * *
 3  * * *
 4  83.224.40.185 (83.224.40.185)  75.660 ms  76.495 ms  77.516 ms
 5  85.205.14.105 (85.205.14.105)  84.951 ms  85.111 ms  85.128 ms
 6  212.73.241.21 (212.73.241.21)  81.020 ms  68.027 ms  68.200 ms
 7  ae-0-11.bar2.Milan1.Level3.net (4.69.142.190)  74.880 ms  68.066 ms  68.426 ms
 8  ae-14-14.ebr1.Frankfurt1.Level3.net (4.69.142.194)  77.336 ms  76.738 ms  79.799 ms
 9  ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6)  78.400 ms  78.500 ms  90.106 ms
10  ae-2-70.edge5.Frankfurt1.Level3.net (4.69.154.73)  78.688 ms  76.939 ms  76.813 ms
11  b.resolvers.Level3.net (4.2.2.2)  76.679 ms  76.707 ms  76.957 ms

Come potete notare, in quest’ultimo caso il decimo hop ha risposto, proprio perchè su di esso è consentito il traffico ICMP e non quello UDP.

Traceroute come footprinting

Il comando traceroute può essere utilizzato con finalità di footprinting. Ad esempio, se un dato hop non risponde nè al protocollo ICMP nè a quello UDP su una porta alta (compresa nel range che ho riportato in precedenza), si può specificare una determinata porta di destinazione mediante la flag -p. Supponendo che sull’host sia attivo un demone DNS, il comando da utilizzare potrebbe essere il seguente:

nightfly@nightbox:~$ sudo traceroute -p 53 10.1.2.14

Alla prossima.

Wake on LAN su minipc ASUS at-3iont-i

Premesso che il BIOS installato sulla mobo in questione presenta numerose limitazioni, ho deciso comunque di provare ad abilitare il Wake On LAN sul mio server casalingo (Debian).

Per prima cosa, ho provato ad individuare la voce del BIOS che mi consentisse di abilitare la suddetta funzionalità. Purtroppo però, la specifica versione di software presente sulla mia scheda madre non consente di attivare esplicitamente il WOL dalla scheda Gigabit Ethernet integrata, cosa che mi ha lasciato a dir poco sbalordito.

Nonostante ciò è comunque possibile:

1) abilitare il Wake dopo la pressione di un determinato tasto della keyboard PS2 (funzione testata da me personalmente e funzionante);

2) abilitare il Wake da mouse PS2;

3) abilitare il Wake da interfaccia PCI-Express;

4) schedulare il Wake in una data/ora ben precisa.

Ma queste opzioni non includono, ovviamente, il WOL da scheda di rete integrata.

Ho dunque creato uno scrip che consentisse di attivare la suddetta funzione, utilizzando un tool esterno, ovvero ethtool.

Per installarlo è sufficiante digitare:

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

Ad installazione completata, creiamo un file di testo vuoto:

nightfly@nightbox:~$ sudo nano autowol

il cui contenuto dovrà essere:

#!/bin/bash
ethtool -s eth0 wol g
exit 0

salviamo il file e rendiamolo eseguibile:

nightfly@nightbox:~$ sudo chmod a+x autowol

Lanciamo lo scrip e verifichiamo che il WOL mediante magic packet (g) sia effettivamente attivo:

nightfly@nightbox:~$ sudo ethtool eth0

Lo stralcio di output che ci interessa dovrà essere simile al seguente:

Supports Wake-on: pumbg
        Wake-on: g

La prima riga ci conferma che la scheda eth0 supporta il WOL, la seconda riga, invece, ci fornisce informazioni sul tipo di WOL attivo (magic packet).

Fatto ciò, è necessario che tale opzione venga attivata automaticamente ad ogni avvio del sistema (e prima dello spegnimento). Per fare questo si può copiare il suddetto scrip nella directory /etc/init.d e successivamente usare il comando:

nightfly@nightbox:/etc/init.d$ update-rc.d -f autowol defaults

Bene, a questo punto ho deciso di dare inizio ai miei test. Per prima cosa ho scaricato un software gratuito (per ambienti Windows e dotato di GUI) in grado di forgiare i magic packet. Il tool a cui mi riferisco è questo:

http://www.depicus.com/downloads/WakeOnLanGui.zip

La cosa bella di questo software è che ci permette di scegliere la porta (UDP) su cui inoltrare il magic packet, riuscendo dunque ad aggirare eventuali restrizioni imposte dal PAT (in questo modo potremo utilizzare il WOL anche da remoto).

wolgui.jpg

Per accendere il nostro server da remoto sarà sufficiente riempire i campi richiesti dal suddetto tool, ovvero:

1) MAC address della macchina che si vuole avviare;

2) indirizzo IP (oppure hostname) pubblico della macchina;

3) porta (UDP).

Solitamente il WOL si avvale della porta 7 o 9 (UDP) ma vi consiglio di forwardare porte più alte in modo da complicare la vita ad eventuali scrip kiddie (sai che piacere lasciare il server spento e ritrovarselo accesso di punto in bianco?).

In definitiva, i test hanno dato questo esito:

1) se il server è spento (S5) il WOL non funziona;

2) se il server è sospeso (S3, con RAM alimentata), il WOL funziona;

3) se il server è ibernato (S4), ovvero il dump della RAM si trova nell’area swap dell’HD, il WOL non funziona.

Quindi, così come stanno le cose il WOL è quasi inutile. Nei prossimi giorni vedrò di aggiornare il BIOS ed eventualmente di acquistare una scheda Ethernet PCI-Express.

Speriamo bene.

PS: per maggiori dattagli sui power state ACPI potete consultare questa pagina.

PPS: potete operare con i power state direttamente da CLI utilizzando il comando pmi action <stato>.

AGGIORNAMENTO del 16/04/2020

Finalmente ho trovato un po’ di tempo per lavorarci e credo di aver risolto il problema. E’ stato sufficiente modificare un’opzione del BIOS, ovvero:

Power -> Control EuP

portandola da “Enabled” a “Disabled”.

In soldoni, tale opzione (Energy Using Products), se abilitata, disattiva il WOL quando il sistema si trova in S4 (hibernate) oppure in S5 (spento).

Ergo, adesso il WOL funziona anche a PC spento.

DDoS: script bash per individuare la nazionalità degli IP sorgenti dell’attacco

Per arginare un attacco DDoS è necessario, prima di tutto, individuare quali sono gli IP pubblici da cui proviene. In secondo luogo, occorre capire se il sito vittima basa il proprio “business” esclusivamente su visite italiane. In questo caso, per realizzare delle opportune ACL in modo da filtrare il traffico in ingresso, si deve capire quali sono i netblock stranieri da interdire. Per fare ciò ho realizzato un piccolo scrip bash che legge gli IP da un file di testo (ricavati, ad esempio, analizzando i log del Firewall o del Web server) e ne individua il relativo netblock (e la nazionalità).

 

ddos,bash,script,linux,netblock,netmask,ip

Ecco lo scrip:

#!/bin/bash

touch ipinfo
touch target

while read line
do
        whois -F $line >> ipinfo
done < tlog

while read line
do
        locin=`echo $line | grep "*in"`
        loccy=`echo $line | grep "*cy"`
        if [[ -n "$locin" || -n "$loccy" --; then
                echo "$locin$loccy" >> target
        fi
done < ipinfo

rm ipinfo

exit 0;

Ovviamente è ancora ad una versione alpha (0.1). Appena avrò tempo provvederò ad aggiungere il calcolo automatico delle netmask e la creazione automatizzata della relative ACL Cisco (con un minimo di interattività).

Alla prossima.

NB: il file testuale tlog deve contenere un solo IP sorgente per riga.

Nuovo server casalingo a risparmio energetico: migrazione completata

Finalmente il nuovo server è operativo (dopo aver completato la fase di tuning e di test, durata circa 2 giorni). Just a little pic:

31122011029.jpg

Dai primi esperimenti sembra solido come una roccia e non raggiunge mai carichi eccessivi, nonostante gli n servizi attivi. Staremo a vedere, ma tutti gli indizi portano ad essere ottimisti 😀

A presto.

Script per il backup automatico della configurazione di un router Cisco SOHO 77

Premessa

Un sistemista di rete previdente sa che è di vitale importanza poter contare su di un backup valido delle configurazioni relative ai vari network device. Proprio per questo motivo ho deciso di creare uno scrip che permettesse di automatizzare tale procedura.

soho.JPG

 

Configurare un server TFTP

Occorre precisare che il backup della configurazione del nostro router Cisco SOHO 77 verrà archiviato su di un server TFTP basato su una distribuzione *buntu.

Ma veniamo al dunque. Per prima cosa installiamo il server TFTP digitando:

nightfly@nightbox:~$ sudo apt-get install tftp tftpd xinetd

A questo punto posizioniamoci sulla directory /etc/xinetd.d e creiamo il file tftp il cui contenuto dovrà essere:

service tftp
 {
 protocol        = udp
 port            = 69
 socket_type     = dgram
 wait            = yes
 user            = nobody
 server          = /usr/sbin/in.tftpd
 server_args     = /tftpboot
 disable         = no
 }

Come si può notare dalla direttiva server_args     = /tftpboot il nostro server salverà la configurazione del router nella directory /tftpboot. Inoltre, poichè tale dir non è presente sulla nostra macchina è necessario crearla digitando:

nightfly@nightbox:/$ mkdir tftpboot

posizioniamoci all’interno di /tftpboot e creiamo il file vuoto router.cfg che conterrà la configurazione del SOHO 77:

nightfly@nightbox:/tftpboot$ sudo touch router.cfg

A questo punto lavoriamo sui permessi della directory appena creata e del suo contenuto:

nightfly@nightbox:/$ sudo chmod 777 -R tftpboot

nightfly@nightbox:/$ sudo chown nobody tftpboot

Riavviamo xinetd digitando:

nightfly@nightbox:/$ sudo /etc/init.d/xinetd stop

nightfly@nightbox:/$ sudo /etc/init.d/xinetd start

Infine, verifichiamo che il nostro server TFTP sia in ascolto digitando:

nightfly@nightbox:/$ sudo nmap -sU localhost

se l’output sarà simile al seguente:

69/udp   open|filtered tftp

vuol dire che il server risulta effettivamente in ascolto.

Scrip per il backup automatico della configurazione relativa al SOHO 77

Prima di mostrarvi lo scrip, è necessario installare un tool indispensabile al suo funzionamento. Tale tool prende il nome di expect:

nightfly@nightbox:/$ sudo apt-get install expect

Creiamo ora il file backup_conf_soho77 il cui contenuto dovrà essere il seguente:

#!/usr/bin/expect

set password1 "<pass1>"
set password2 "<pass2>" #necessaria nel caso in cui la password per l'enable sia diversa da quella per l'accesso via telnet

spawn telnet <IP del router>
expect "Password:"
send "$password1r"
expect ">"
send "enar"
expect "Password:"
send "$password2r"
expect "#"
send "copy system:running-config tftp://<IP del server TFTP>/router.cfgr"
expect "?"
send "r"
expect "?"
send "r"
expect "#"
send "exitr"
expect eof

NB: prima della r all’interno delle virgolette ci vuole il backslash, in modo da inviare al router un ritorno a capo (nello scrip non appare in quanto viene automaticamente skippato da myblog per ragioni di sicurezza).

Rendiamo lo scrip eseguibile mediante il comando:

nightfly@nightbox:~$ sudo chmod +x backup_conf_soho77

e successivamente spostiamolo nella directory /usr/bin:

nightfly@nightbox:~$ sudo mv backup_conf_soho77 /usr/bin

Adesso non ci resta che “schedulare” l’esecuzione dello scrip. Per fare questo è sufficiente inserire una entry in /etc/crontab:

00 00   * * * root backup_conf_router

In particolare, ogni mezzanotte verrà eseguito il backup della configurazione mediante lo scrip descritto in precedenza.

Riavviamo cron per rendere effettive le nuove impostazioni:

nightfly@nightbox:~$ sudo /etc/init.d/cron restart

ed abbiamo finito.

A presto.

 

rkhunter ed il rootkit Xzibit

Qualche giorno fa sono rientrato dalle mie meritate ferie (che poi tanto ferie non erano) e mi sono ritrovato con uno un reverse proxy dell’ambiente di test spento.

Ho chiesto ai miei colleghi il perchè di questa cosa e mi è stato detto che proprio su quel proxy era stata pubblicata la porta 25 (SMTP) ed avevano paura che fosse stato ownato. Non chiedetemi per quale motivo è stato fatto questo accrocchio, ma qui i problemi erano altri, ovvero:

1) Essendo il reverse proxy basato su una distro che non viene aggiornata da illo tempore, c’era un’ampia probabilità (diventata certezza dopo ulteriore analisi) che il demone SMTP fosse bacato;

2) La porta 25 è stata lasciata in forwarding per circa una settimana, il che ha aumentato in modo esponenziale il rischio che la macchina venisse ownata da qualche lamer di turno.

rkhunter

Armato dunque di molta pazienza riaccendo la macchina ed effettuo una prima scansione con chkrootkit, che però non segnala nulla di anomalo. Non contento installo anche rkhunter (il cui rpm lo potete scaricare da qui), il quale, alla fine dell’analisi, mi riporta il seguente sommario all’interno del file di log:

[10:10:09] System checks summary
[10:10:09] =====================
[10:10:09]
[10:10:09] File properties checks...
[10:10:09] Required commands check failed
[10:10:09] Files checked: 141
[10:10:09] Suspect files: 6
[10:10:09]
[10:10:09] Rootkit checks...
[10:10:09] Rootkits checked : 253
[10:10:10] Possible rootkits: 1
[10:10:10] Rootkit names    : Xzibit Rootkit
[10:10:10]
[10:10:10] Applications checks...
[10:10:10] Applications checked: 7
[10:10:10] Suspect applications: 4
[10:10:10]
[10:10:10] The system checks took: 13 minutes and 25 seconds
[10:10:10]
[10:10:10] Info: End date is Wed Aug 31 10:10:10 CEST 2011

Uhm, possibile che sia stato installato il rootkit Xzibit? Spulcio ulteriormente il log, alla ricerca del file che ha fatto scattare l’allarme. Il risultato è il seguente:

Found string 'hdparm' in file '/etc/rc.d/init.d/vmware-tools'. Possible rootkit: Xzibit Rootkit

Ebbene, rkhunter ha interpretato come “sospetta” la stringa hdparm presente nei wmware-tools. Ma essendo una macchina virtuale è palese che si tratta di un falso positivo.

Dunque se la vostra macchina è virtuale e ci avete installato i wmware-tools è molto probabile che rkhunter generi questo allarme.

Stay tuned.

PS: per la cronaca, il reverse proxy è ok (o almeno così sembra).

Script per il backup giornaliero di un database remoto

Visto che la ridondanza non è mai troppa (Murphy vi dice qualcosa?), ho pensato di realizzare uno scrip per effettuare il backup di un database hostato su un server remoto.

shell

Ecco lo scrip (basato su expect):

#!/usr/bin/expect -f
set date [exec date +%d_%m_%y]
set password1 "<pass1>"
set password2 "<pass2>"
set database "<nomedb>"
spawn ssh user@hostname
expect "*?assword:*"
send "$passwordr"
send "r"
expect ":~$"
send "mysqldump $database -u root -ppassvostrodb > $database_$date.plr"
send "$database_$date.pl user@hostname:/home/userr"
expect "*?assword:*"
send "$password2r"
send "r"
expect ":~$"
send "rm database_*r"
expect eof

Lo scrip in questione si collega via SSH al server remoto, esegue un dump del database per poi copiarlo tramite SCP sul mio server.

Affinchè tale scrip venga eseguito giornalmente (per la precisione ogni sera alle 22) è necessario editare il file /etc/crontab aggiungendo la seguente direttiva:

00 22   * * * user  cd /home/user/ && ./backupremotedb > /dev/null 2>&1

Per ulteriori info contattatemi.

A presto.

Visualizzare data ed ora di un comando nel file history

Qualche tempo fa, mentre lavoravo per il progetto PIT di Selex Communications, è sorta la necessità di appurare quale degli n-NOC avesse lanciato un reboot su uno dei router di una sala operativa. Poichè l’history non riportava alcuna informazione sulla data e sull’ora di esecuzione del comando, non è stato possibile individuare con certezza il responsabile, quindi la questione si è risolta con un nulla di fatto.

Alla luce di ciò, ho deciso di scrivere questa breve guida in cui viene descritta la procedura per aggiungere il datetime al file history nell’ambito dei sistemi basati su Debian.

bash

Per prima cosa è necessario editare il file nascosto .bashrc presente nella home dell’utente:

nightfly@nightbox:~$ sudo nano .bashrc

e successivamente aggiungere la seguente direttiva:

HISTTIMEFORMAT="%d/%m/%y %T "

In particolare, ogni comando presente nel file history verrà proceduto da giorno (%d), mese (%m), anno (%y) ed ora (%T) (nel formato hh:mm:ss) di esecuzione dello stesso.

Subito dopo esserci riloggati alla macchina digitiamo il comando:

nightfly@nightbox:~$ history

il cui output sarà simile al seguente:

 1995  12/06/11 11:49:57 history
 1996  12/06/11 11:49:57 exit
 1997  12/06/11 11:26:49 history
 1998  12/06/11 11:50:17 sudo nano .bashrc
 1999  12/06/11 11:53:13 history

Ovviamente tale operazione non è retroattiva, nel senso che tutti i comandi precedenti alla modifica del file .bashrc avranno come datetime quello della modifica stessa.

A presto.

grep -H e grep -v

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.

 

grep.jpg

 

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.

Apache2: disabilitare il directory listing

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?).

apache.jpg

 

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.