Archivi tag: bug

Reboot script per i router Draytek Vigor

Networking, , , , , , , ,

Premesso che giornalmente devo “scontrarmi” con un Draytek Vigor 3300V, sono pian piano giunto alla conclusione che tale aggeggio abbia più difetti che pregi.

vigor3300.jpg

Ad esempio, il content filtering consente di bloccare al massimo 8 (e dico 8!) keyword e non ne vuole sapere di gestire l’HTTPS; la pagina relativa ai DDNS, nonostante la presenza delle credenziali per aggiornare l’associazione IP – FQDN, non inoltra alcuna richiesta al sito del provider e quindi i record A scadono; il server DHCP integrato non consente di settare delle normalissime exclusion su alcuni IP che rientrano nel pool ma che non devono essere assegnati a nessun utente.

Ora, potrei continuare quasi all’infinito, ma l’ultima bega che mi son dovuto accollare riguarda la gestione delle VPN. Si, esatto, questo fantastico router funge anche da VPN concentrator, riuscendo (per modo di dire) a gestire VPN IPSec, L2TP e PPTP. Peccato che ogni “tot” si incarti miseramente, lasciando fuori alcuni utenti che cercano di atterrare sulla LAN via VPN, mentre altri riescono tranquillamente ad accedere alla rete interna.

Ho provato a cercare una soluzione un pò più pulita rispetto al classico riavvio, ma credetemi se vi dico che non c’è (forse si potrebbe procedere con la disattivazione/riattivazione della VPN ma non sono sicuro che una cosa del genere non preveda comunque un reboot).

In definitiva, ecco lo scrip expect che mi permette di riavviare il router ogni notte:

#!/usr/bin/expect

set password1 "password"

exec date
spawn ssh -l draytek 10.1.10.1
expect "?"
send "yr"
expect "*?assword:*"
send "$password1r"
expect ">"
send "sys rebootr"
expect "?"
send "yr"
expect eof

Ovviamente l’esecuzione di tale scrip avviene mediante cron e non fa altro che connettersi al router, lanciare un sys/reboot ed uscire.

Attenzione però: dopo ogni riavvio il router cambia il proprio fingerprint SSH (non chiedetemi il perchè), quindi il suddetto scrip, dopo il primo riavvio, fallirebbe miseramente in quanto il client SSH, vedendosi cambiare di punto in bianco il fingerprint dell’host a cui sta provando a connettersi, penserebbe in un attacco MITM.

Per evitarè ciò è necessario editare il file /etc/ssh/ssh_config aggiungendo in testa le seguenti direttive:

Host 10.1.10.1
     StrictHostKeyChecking no
     UserKnownHostsFile=/dev/null

Infine, voglio precisare che il router è comunque dotato di un comando in grado di definire il reboot automatico (mi sa che gli stessi costruttori fossero a conoscenza del fatto che tale aggeggio tende ad incartarsi di continuo). Nonostante questo comando bundle, chiamato appunto autoreboot, ho preferito operare come indicato in precedenza per un semplice motivo:

DrayTek> sys autoreboot ?
 Full Name:
    auto reboot function
 Description:
 Syntax:
    autoreboot -s                                (Show status)
    autoreboot -e <Enable>
    autoreboot -t <Hours>
 Parameters:
    <Enable>                                         (0: Disable, 1: Enable)
    <Hours>                                          (Number of hours)

Si, avete capito bene, se volessi riavviare il router ogni mattina alle 3 (quindi esattamente ogni 24 ore) dovrei lanciare i comandi:

DrayTek> sys autoreboot -e 1

DrayTek> sys autoreboot -t 24

indovinate a che ora? ALLE 3 DEL MATTINO. No comment.

Alla prossima.

Varnish Cache ed il bug che non ti aspetti

SO: Linux, , , , , , ,

Qualche giorno fa, uno dei Web develop con cui sono solito lavorare mi ha fatto notare un’anomalia presente in /var/log/messages relativa al demone varnishd.

 

bug1.jpg

 

Tale anomalia si presentava, più o meno, nel modo seguente:

[root@bqweb1 varnish]# tail -f /var/log/messages | grep varnishd

Nov 15 20:37:37 bqweb1 varnishd[30485]: Manager got SIGINT
Nov 15 20:37:38 bqweb1 varnishd[20876]: Platform:
Linux,2.6.18-308.13.1.el5,x86_64,-smalloc,-smalloc,-hcritbit
Nov 15 20:37:38 bqweb1 varnishd[20876]: child (20877) Started
Nov 15 20:37:38 bqweb1 varnishd[20876]: Child (20877) said Child starts

ovvero il timestamp degli eventi associati a varnishd risultava sfasato in anticipo di un’ora rispetto al timestamp di sistema.

Ho subito pensato ad un bug ed infatti ho trovato questo link:

https://bugs.launchpad.net/ubuntu/+source/varnish/+bug/843827

In soldoni, varnishd, nelle versioni 3.0.0-4, non prende in considerazione l’ora di sistema ma si basa esclusivamente sull’ora UTC.

Tutto sommato nulla di grave, poichè gli eventi inseriti all’interno del file messages riguardano solo ed esclusivamente il funzionamento del demone (il traffico utente e quello relativo alle comunicazioni con i backend viene registrato a parte).

Alla prossima.

Solaris 10 ed il ping bacato

Networking, , , , , , ,

Qualche giorno fa sono praticamente impazzito nel cercare di individuare un problema che credevo fosse sulla rete. In particolare, una macchina specifica (con addosso Solaris 10) che doveva occuparsi di controllare l’effettiva raggiungibilità di determinati network element (mediante dei semplici ping), ad intervalli di tempo pseudorandomici inviava al default gateway dei frame Ethernet con MAC sorgente 00:00:00:00:00:00.

sol10logo.png

A questo punto, il default gateway memorizzava il suddetto MAC address all’interno della propria tabella ARP e l’unico modo per far ripartire i check consisteva nell’eliminare manualmente tale entry. A cancellazione avvenuta tutto tornava a funzionare correttamente, salvo poi reincartarsi nuovamente.

La soluzione più semplice sarebbe stata quella di inserire una entry statica all’interno della tabella ARP relativa al default gateway, che però si è rivelata inpraticabile dato che il SO di tale macchina non permetteva l’aggiunta della suddetta entry. Quindi il problema andava ricercato all’origine, ovvero sulla macchina Solaris.

Mi armo di pazienza e di sniffer (aka snoop) ed inizio ad analizzare il traffico ICMP. Dopo un po’ di tempo mi accorgo che il ping si incartava nel momento in cui provava a testare la raggiungibilità di due IP ben precisi (mentre funzionava con tutti gli altri).

Controllo la configurazione di rete e mi accorgo che sono presenti delle ACL (posizionate vicino alla destinazione) che bloccano i suddetti ping, provocando (molto probabilmente) un dump dell’applicativo. Tale dump porterà successivamente all’invio di frame con il MAC address anomalo riportato in precedenza.

Poichè stentavo a credere che una macchina robusta come Solaris 10 potesse essere afflitta da un bug di simile fattezza ed entità ho deciso di documentarmi un po’ e di effettuare qualche ricerca su Internet, che mi ha portato su questo link:

http://wesunsolve.net/bugid/id/1219682

Per la serie non considerare mai come impossibile un evento poco probabile.

Alla prossima.

Google Chrome: attributo z-index ignorato per gli *.swf

Web Editing, , , , , , ,

L’attributo z-index, utilizzato nell’ambito dei fogli di stile (CSS), consente di ordinare gli elementi grafici di una pagina Web secondo la coordinata spaziale z. Purtroppo però, quando si ha a che fare con degli *.swf e si utilizza Google Crome come browser, l’attributo z-index viene totalmente ignorato, ragion per cui il filmato sarà sempre posizionato “più in superficie” rispetto agli altri elementi.

 

google_chrome_logo.jpg

Inutile dire che tale comportamento “anomalo” non si verifica nè con Mozilla Firefox nè con IE8 ed IE9.

Esiste tuttavia un workaround. Esso consiste, sostanzialmente, nell’uso dell’attributo wmod relativo al tag embed. Il valore associato all’attributo in questione dovrà essere transparent.

Ad esempio:

<embed wmode="transparent">

Inoltre, occorre inserire il seguente codice HTML tra i tag <object></object>:

<param name="wmode" value="transparent" />

Adesso anche Google Chrome sarà in grado di visualizzare gli elementi grafici della pagina nel giusto ordine di profondità.

A presto.

Script per il forward automatico della porta SSH sul router Cisco 837

Networking, , , , , ,

La IOS C837-K9O3Y6-M sviluppata per il router Cisco 837 ha un bug, ovvero è possibile che dopo qualche reload si “dimentichi” di una o più PAT translations che riguardano porte più alte delle well-known (per intenderci, superiori alla 1023).

bug

Nel mio caso, il problema ha iniziato a verificarsi da quando ho deciso di mettere in ascolto SSH su una porta non standard, in modo da risparmiarmi i tentativi di attacco lanciati dagli scrip kiddie di turno.

Inoltre, per motivi di sicurezza, ho consentito l’accesso via SSH al router solo dagli host della LAN, quindi, nel caso in cui dovessi accedere alla sua configurazione, atterro sul server e da lì mi collego al router.

Ovviamente, se la porta SSH non è forwardata non posso atterrare sul server, dunque l’unica soluzione praticabile consiste nell’andare fisicamente dal cliente e ricreare la regola per il PAT.

E qui viene il bello: poichè mi sono stancato di dover perdere almeno un’ora per andare dal cliente, riconfigurare il tutto e tornarmene a casa, ho deciso di creare il seguente scrip, il quale si collega al router tre volte al giorno e ricrea la regola per l’SSH.

Ecco lo scrip:

#!/usr/bin/expect

set password1 "<password1>"
set password2 "<password2>"

spawn ssh -l <username> <IP del router>
expect "*?assword:*"
send "$password1r"
expect ">"
send "enar"
expect "Password:"
send "$password2r"
expect "#"
send "conf tr"
expect "(config)#"
send "no ip nat inside source static tcp <ip> <porta> interface Dialer0 <porta>r"
expect "(config)#"
send "ip nat inside source static tcp <ip> <porta> interface Dialer0 <porta>r"
expect "(config)#"
send "exitr"
expect "#"
send "copy run startr"
expect "?"
send "r"
expect "#"
send "exitr"
expect eof

Come al solito, mancano i backslash prima della r perchè myblog li filtra.

Una volta che avete creato lo scrip, convertitelo in eseguibile lanciando il comando:

nightfly@nightbox:~$ sudo chmod +x ssh_autoforward

e salvatelo nella directory /usr/bin:

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

A questo punto potete creare la regola per cron, in modo da schedulare l’esecuzione dello scrip alle 6, alle 12 ed alle 18:

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

00 06,12,18   * * *     root          ssh_autoforward

Riavviamo cron:

nightfly@nightbox:~$ sudo service cron restart

ed abbiamo finito.

A presto.

PS: non preoccupatevi se lo scrip entra in esecuzione mentre siete loggati sul server: la regola per il forward dell’SSH non verrà rimossa poichè la state già utilizzando, quindi niente perdita di connessione.

DVL (Damn Vulnerable Linux) la distro più vulnerabile che esista

SO: Linux, , ,

Ormai è risaputo di quanto siano sicure alcune distribuzioni *nix, tra cui la celeberrima FreeBSD (un solo exploit da remoto in 10 anni). Eppure vi sono tante altre distribuzioni che non fanno della sicurezza il loro obiettivo primario. Tra queste vi è certamente DVL (Damn Vulnerable Linux – un nome una garanzia), appositamente forgiata per presentare numerosissime falle di sicurezza ed aiutare gli aspiranti “security consultant” durante la loro formazione. Effettivamente l’idea non è male, in quanto tale distribuzione potrebbe anche essere utilizzata come passatempo, per “testare” l’effetto dei vari exploit sui bug presenti.

Ovviamente trattasi di bug arcinoti e piuttosto datati, per cui le ultime versioni dei software dovrebbero esserne immuni (almeno spero). Comunque, bando alle ciance ed enjoy: http://www.damnvulnerablelinux.org/