Archivi tag: unix

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.

Solaris 10 in single user mode

Che Solaris sia un SO a dir poco “fondamentalista” è risaputo. Ciò significa che un arresto dirty di tale sistema porta a dei malfunzionamenti di una certa gravità, tra cui l’avvio in sigle user mode permanente.

logo_solaris10_upgrade.gif

Per la precisione, l’errore che mi sono beccato più e più volte era il seguente:

/lib/svc/method/fs-usr filed with exit status 96

/system/filesystem/usr:default misconfigured: transitioned to maintenance

quel transitioned to maintenance significa, in soldoni, che il sistema non è riuscito ad avviarsi correttamente e che quindi è stato costretto a partire in single user mode.

Lanciando un:

svcs -xvm

non sono riuscito ad ottenere maggiori dettagli, sicchè ho deciso di addentrarmi nella miriade di file di log di cui è dotato il sistema in questione.

Gira che ti rigira, nella directory /var/svc/log ho trovato il file che mi interessava, ovvero:

system-filesystem-usr:default.log

Dopo un cat ho focalizzato la mia attenzione sulla seguente entry:

[ giu 12 10:19:57 Executing start method ("/lib/svc/method/fs-usr") ]
dumpadm: impossibile aprire /dev/dump: File o directory non trovati
[ giu 12 10:20:00 Method "start" exited with status 96 ]

Si avete capito bene, l’errore è tanto banale quanto rognoso. Mi spiego meglio: quando il sistema è stato arrestato brutalmente, non è riuscito a salvare in un apposito file (leggasi /dev/dump) il dump della memoria volatile (aka RAM), dunque, non trovandolo durante il bootstrap, si avviava in single user mode.

Come ho risolto?

cd /dev

touch dump

Fine dei giochi. Semplice, no?

Alla prossima.

Swatch: un sistema di logging proattivo per ambienti Unix-like

Un sistemista degno di questo nome dedica diverse ore della sua attività lavorativa alla lettura dei log. Ovviamente, poichè tale operazione spesso viene svolta dopo un po’ di tempo dalla generazione dei log stessi, è di fondamentale importanza utilizzare dei sistemi di logging proattivi, in grado cioè di “avvertire” l’amministratore del verificarsi di un qualche tipo di anomalia.

 

sysadmin_mug.jpg

Di software del genere ne esistono a miolioni ma in questo post ho deciso di concentrarmi su swatch per via della sua facilità d’uso e della sua flessibilità.

Infatti, grazie a swatch sarà possibile monitorare i diversi file di log generati sui nostri server, alla ricerca delle entry di nostro interesse.

Per installarlo è sufficiente lanciare il comando:

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

Ad installazione completata verrà creato un file di configurazione all’interno della nostra home dir, il cui nome sarà .swatchrc.

Personalmente credo che per ragioni di sicurezza swatch debba utlizzare un file di configurazione accessibile in lettura ma non in scrittura (ovvero che non possa essere modificato da utenti illegittimi), appartenente a root. Inoltre, consiglio di salvare il file in questione all’interno della directory /etc (per omogeneità).

Generiamo quindi il file di configurazione, il cui nome sarà swatch.conf:

nightfly@nightbox:~$ sudo nano /etc/swatch.conf

in cui inseriremo un’unica regola, poichè ci troviamo ancora in fase di test:

#HTTP Forbidden
watchfor  /401/
       echo 
       mail addressess=vostro.indirizzo@email.it,subject=Failed Authentication

Grazie a questa entry, swatch ci avviserà via email ogniqualvolta si accorgerà che qualcuno ha provato a visualizzare una sezione riservata del sito Web presente sul nostro server (protetta mediante .htaccess).

Per fare in modo che swatch invii un’email immediatamente dopo aver individuato un determinato evento, occorre modificare il file /usr/share/perl5/Swatch/Actions.pm sostituendo:

if (! $args{'MAILER'} ) {
foreach my $mailer (qw(/usr/lib/sendmail /usr/sbin/sendmail)) {
$args{'MAILER'} = $mailer if ( -x $mailer );
}
if ($args{'MAILER'} ne '') {
$args{'MAILER'} .= ' -oi -t -odq';
}
}

con

if (! $args{'MAILER'} ) {
foreach my $mailer (qw(/usr/lib/sendmail /usr/sbin/sendmail)) {
$args{'MAILER'} = $mailer if ( -x $mailer );
}
if ($args{'MAILER'} ne '') {
$args{'MAILER'} .= ' -oi -t -odb';
}
}

Nel caso in cui decideste di non effettuare la modifica indicata in precedenza, swatch invierà le email dopo un lasso di tempo prefissato.

In alternativa, potete utilizzare i comandi bash per inviare gli alert alla vostra casella email. Per fare ciò, dovete creare una configurazione del tipo:

watchfor  /401/
exec echo 'SWATCH HOME: HTTP access forbidden: $_' | mail -iv -s "SWATCH HOME: Failed HTTP Authentication" vostro.indirizzo@email.it

Lanciamo quindi swatch con l’opzione -t (tail), ovvero in monitoraggio costante del file di log che andremo a specificare. Dovremo inoltre indicare qual è il file di configurazione a cui tale software dovrà riferirsi:

nightfly@nightbox:~$ swatch -c /etc/swatch.conf -t /var/log/apache2/ssl_access.log &

La & finale consente di lanciare il processo in background. Esiste anche l’opzione –daemon ma a quanto pare non accetta flag aggiuntive, quali -c o -t e monitorizza soltanto il file /var/log/messages.

Purtroppo swatch non consente di monitorare più file con un’unica istanza, quindi per fare ciò è necessario lanciare più istanze di tale programma, possibilmente utilizzando file di configurazione diversi a seconda del log che si intende tenere sotto osservazione.

Infine, è possibile mandare in esecuzione tale applicativo ad ogni avvio del nostro sistema operativo, semplicemente inserendo la seguente direttiva:

swatch -c /etc/swatch.conf -t /var/log/apache2/ssl_access.log

all’interno del file /etc/rc.local.

Fine del post, a presto.