Archivi categoria: Pillole

CentOS 6: verificare la configurazione di Nagios da linea di comando

Configurare Nagios non è sicuramente un’operazione banale. Proprio per questo motivo, prima di restartare il demone in oggetto (affinchè le modifiche diventino effettive), è buona norma controllare sempre la configurazione dello stesso, utilizzando il seguente comando:

nagios -v /etc/nagios/nagios.cfg

Ovviamente tale check può essere effettuato puntando esclusivamente al file di configurazione principale (nagios.cfg), e non ai file che identificano i network element da monitorare (presenti nella directory /etc/nagios/objects).

Alla prossima.

Redirect del traffico in uscita mediante iptables

Iptables, ovvero l’interfaccia a linea di comando del celeberrimo firewall Netfilter, consente di fare dei veri e propri giochi di prestigio.

Ad esempio, potrebbe succedere che, per ragioni di sicurezza, un dato server Web non sia in ascolto sulla classica porta TCP 80, ma su una porta non standard (ad esempio la 9876). Supponiamo, inoltre, che a tale sito debbano accedere gli sviluppatori, che, di volta in volta dovranno forgiare opportune URL con l’estensione :9876.

netfilter.jpg

Per semplicifare loro la vita si può agire direttamente sul firewall/router, facendo un semplice redirect del traffico in uscita diretto alla porta 80 del server Web. Ecco la regola:

iptables -t nat -A OUTPUT -p tcp -d ipserverweb –dport 80 -j DNAT –to-destination ipserverweb:9876
Ovviamente potete lavorare anche di file hosts, aggiungendo dei record A statici che vi possano aiutare a creare le regole più facilmente, senza doversi obbligatoriamente ricordare gli indirizzi IP coinvolti a memoria.
In quest’ultimo caso la suddetta regola diverrebbe:
iptables -t nat -A OUTPUT -p tcp -d miodominio.com --dport 80 -j DNAT --to-destination miodominio.com:9876
Semplice, vero?
A presto.

scp ed i symlinks

Avere a che fare con delle share NFS è un po’ frustrante. Migrare tali share su un altro server lo è ancora di più, soprattutto se si utilizza scp per spostare le directory da condividere sul nuovo server NFS.

Infatti, subito dopo aver completato la copia, mi hanno fatto notare che i symlinks non funzionavano.

 

scp,symlinks,link simbolici,rsync,find

Inizialmente credevo fosse problema di cp, in quanto il trasferimento delle directory via scp non puntava direttamente alla dir target NFS ma ad una di appoggio (per via delle credenziali utilizzate da scp e dei permessi associati all’utente).

In soldoni, ho dapprima spostato le suddette dir sulla mia home e da lì ho lanciato un cp -d (per includere nella copia i link simbolici) verso il target della share. In seguito, mi sono posizionato sulla dir target ed ho lanciato il comando:

[root@nfs2 ~]# find . -type l -exec ls -ld {} +

per cercare eventuali simlynks, ma, come potete immaginare, la ricerca non ha fornito alcun risultato.

Dunque, non essendo problema di cp, l’unico comando responsabile della mancata copia dei link simbolici non poteva che essere scp.

Ed infatti, guardate qui:

http://superuser.com/questions/233036/scp-copy-the-same-links

La soluzione che ho adottato, senza dovermi necessariamente impelagare con rsync, consiste nel creare una tarball contenente le dir da migrare, copiarla via scp ed infine scompattarla sul nuovo server:

[root@nfs1 ~]# tar -cvf dirtomigrate.tar.gz /var/www/html/siti

[root@nfs2 ~]# tar -xvf dirtomigrate.tar.gz /var/www/html/siti

(da lanciare sul nuovo server NFS).

E’ tutto.

A presto.

Linux: packaging tool e proxy HTTP

Usate un packaging tool (aptitude, emerge, yum et similia) per scaricare ed installare i pacchetti sulla vostra macchina Linux? Non avete accesso diretto al Web e quindi necessitate di interfacciarvi con un proxy HTTP? Niente paura, basta seguire questi semplici passi.

variabili di ambiente, aptitude, yum, emerge, export, http proxy

Per prima cosa occorre definire la variabile di ambiente http_proxy, il cui valore dovrà essere simile al seguente:

nightfly@nightbox:~$ export http_proxy=http://192.168.1.1:3128/

dove 192.168.1.1 è l’indirizzo IP del proxy e 3128 la porta su cui è in ascolto.

Se il proxy richiede autentica, è necessario definire la variabile precedentemente citata usando la seguente sintassi:

nightfly@nightbox:~$ export http_proxy=http://username:password@192.168.1.1:3128/

Attenzione però, le variabili di ambiente valgono esclusivamente per l’utente che le definisce. Per fare in modo che una variabile d’ambiente possa essere utilizzata da tutti gli utenti del sistema, è necessario operare sul file /etc/profile:

nightfly@nightbox:~$ sudo nano /etc/profile

ed aggiungere la direttiva:

export http_proxy=http://192.168.1.1:3128/

oppure:

export http_proxy=http://username:password@192.168.1.1:3128/

in caso di autentica.

Infine, per listare le variabili di ambiente basta lanciare il comando:

nightfly@nightbox:~$ export -p

Done.

Le password robuste…

Avere a disposizione grandi budget da investire nella messa in sicurezza della propria infrastruttura informatica non implica l’invulnerabilità della stessa. Con questo voglio dire che nel 90% dei casi, le attività di cracking, anche le più banali, riescono grazie all’incapacità del sistemista, del tecnico di helpdesk o dell’utente vittima.

Privacy_2.jpg

Basti pensare che su Internet vi sono migliaia di dispositivi le cui interfacce di configurazione sono accessibili digitando username e password di default. Non ci credete? Incominciate ad usare nmap, magari all’interno di qualche script bash che colleziona determinati OS fingerprint e, una volta analizzati i risultati, provate una di queste credenziali di accesso:

http://www.phenoelit-us.org/dpl/dpl.html

“L’essere umano è il vero anello debole della catena”.

Alla prossima.

User enumeration mediante nmap

Scenario

Macchina Windows in ascolto sulla porta 3389 TCP (Il famoso Remote Desktop).

Password dell’account RDP nota, nome utente sconosciuto.

user-enumeration-mediante-nmap-L-gnHMmvSoluzione

Utilizzare nmap.

Vediamo, nello specifico, qual è il comando da lanciare:

nightfly@nightbox:/usr/share/nmap/nselib$ sudo nmap -sT -p445 --scrip=smb-enum-users <IP macchina Windows>

Come potete notare ho specificato ad nmap lo l’addon da utilizzare, la porta di destinazione (TCP 445, alias SMB) ed il tipo di scan (-sT).
L’outuput sarà simile al seguente:

Starting Nmap 5.00 ( http://nmap.org ) at 2012-05-02 10:38 CEST
Interesting ports on 192.168.*.*:
PORT   STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: E0:CB:*:*:*:* (Unknown)
Host script results:
|  smb-enum-users:
|_ *Administrator, *Guest, *HelpAssistant,*HelpServicesGroup, *Nessuno
Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds

Enjoy.

Disabilitare il comando su per alcuni utenti su RedHat 5

Per fare in modo che determinati utenti loggati sulla nostra RedHat 5 non possano utilizzare il comando su (per ottenere, ad esempio, privilegi di root), è necessario operare come segue:

1) editare il file /etc/group, aggiungendo al gruppo wheel gli utenti che possono switchare su root:

root@nightbox:/home/nightfly# nano /etc/group

wheel:x:10:utente1,utente2

2) editare il file /etc/pam.d/su, aggiungendo la seguente stringa:

auth           required        /lib/security/$ISA/pam_wheel.so use_uid

 

redhat.jpg

A questo punto non vi resta che effettuare il logout e riaccedere alla shell usando le credenziali dell’utente con permessi limitati.

Lanciate un su – e digitate la password di root: avrete come risposta che la password appena inserita è errata (anche nel caso in cui sia stata digitata la password corretta).

Alla prossima.

Exim4: ripulire i frozen messages

Sempre più spesso mi capita di vedere rigettati dallo smarthost (leggere server SMTP) una miriade di messaggi generati dai sistemi di monitoring attivi sui miei server.

 

mail.jpg

Per intenderci, lanciando un cat /var/log/exim4/mainlog, l’output seguente è costellato da info del tipo:

2011-12-26 23:20:01 1Rehhj-0000tY-BZ Message is frozen
2011-12-26 23:20:01 1Rex2z-0003El-5p Message is frozen
2011-12-26 23:20:01 1RfIpL-0000Pq-Dg Message is frozen
2011-12-26 23:20:01 1ReajD-0001FI-Nb Message is frozen
2011-12-26 23:20:01 1Rf4Wf-0000oG-AG Message is frozen
2011-12-26 23:20:01 1Rf8Ho-0003Ku-Pq Message is frozen
2011-12-26 23:20:01 1ReloA-0003d2-AH Message is frozen
2011-12-26 23:20:01 1ReaZS-00018P-KD Message is frozen

Ok, i messaggi caratterizzati da questi ID sono “bloccati” in coda. Cosa fare dunque? Bhè, se non sono di vitale importanza, possiamo semplicemente cestinarli grazie a questo semplice comando (da eseguire come root):

root@nightbox:~# exiqgrep -z -i | xargs exim -Mrm

Potete anche impostare un job su cron per eliminarli giornalmente ed evitare la formazione delle suddette code.

A presto.

Cancellazione di una regola PAT sul router Cisco 837: %Static entry in use, cannot remove

Recentemente ho dovuto modificare le regole per il PAT presenti sul mio router Cisco 837, provando a rimuovere alcune entry. Poichè esse erano ancora in uso, ogni volta che provavo a cancellarle mi beccavo un messaggio del tipo:

%Static entry in use, cannot remove

Ho risolto semplicemente cancellando il contenuto della tabella relativa alle NAT translations, lanciando il comando:

clear ip nat translation *

e successivamente ho rimosso la regola per il PAT vera e propria.

Bye.