[PC] —>[NTLM Proxy aziendale]—>[vostra Shell]—>[Internet]

I requisiti sono:

• Avere una shell/VPS (magari chiedete ad un amico o cercatene una free) con SSH bindato sulla 443 (SSL)
• NTLMAPS
• Putty o un client SSH

Brevemente: il goal è quello di far passare la vostra navigazione (rendendola anche più sicura da nasi indiscreti) attraverso un Tunnel SSH via NTLMAPS (che vi autorizzerà sull’NTLM Proxy) verso la vostra shell, che provvederà in seguito a mandarvi su siti che non potete normalmente raggiungere dalla vostra azienda.

Step 1: Scompattate NTLMAPS e configurate il file server.cfg con la porta locale a cui si connetterà Putty (es. 8888), inoltre valorizzate i campi con i dati che usate sul vostro proxy: Username, Dominio e compagnia, se non volete lasciare nel cfg la vostra password in chiaro non valorizzate il campo password, NTLMAPS ve la chiederà appena runnato. Fatto ciò lanciate lo script .bat che avvierà NTLMAPS.

Step 2: Configurate Putty: Nel menu Proxy settate HTTP, localhost ed 8888 (ovvero verso l’appena configurato NTLMAPS) poi andante nella sezione SSH – Tunnels – valorizzate Source Port con la porta che userete come proxy locale in ascolto (dove si connetterà il vostro browser, es. 1081) e flaggando Dynamic (non scordatevi di clikkare Add!). Fatto ciò memorizzate il tutto nel vostro profilo shell per non ripetere sempre l’operazione e connettetevi sulla porta 443 della vostra shell (il login deve avvenire con successo o il forward non avverrà).

ATTENZIONE: il proxy che vi censura per cui passerete, dovrà avere il metodo HTTP CONNECT abilitato sulla sua porta 443,  che 9 volte su 10 è attivo, altrimenti lavorate per le SS

Step 3: Configurate adesso il vostro browser per navigare attraverso Putty, poi NTLMAPS, poi verso il proxy che vi filtra che a sua volta penserà di mandarvi verso un qualunque sito in HTTPS ma invece vi manderà sul vostro OpenSSH Server. Contorto ma efficace!

Sul browser nelle opzioni Proxy, lasciate vuoto il campo host di Proxy HTTP ma valorizzate la porta (quella in LISTENING di Putty), mettete poi localhost 1081 su Host SOCKS. Questa tecnica funziona solo specificando nel browser che il proxy è SOCKS 5, come nella figura di seguito:

Date l’OK et voilà, state navigando dalla vostra shell, con un pò di fatica e accrocchi vari ma in totale LIBERTA’! Cercate di capire se il posto in cui siete fa uno stretto monitoraggio della navigazione web, ma per problematiche inerenti alla privacy ed il traffico che producete totalmente cifrato non dovrebbero crearvi problemi.

/etc/ssmtp/ssmtp.conf:
root=tuo_username@gmail.com # altrimenti inviando mail da root il mittente e' "root"
mailhub=smtp.gmail.com:465 # o :587
UseTLS=YES
AuthUser=tuo_username # senza @gmail.com
AuthPass=tua_password
FromLineOverride=YES # per settare correttamente il subject

io sto utilizzando questa configurazione per una webapp che invia in automatico delle mail

But vmware-any-any-update patchs do not support bridge networking with wireless network cards. It can be read in the source of module vmnet.tar, smac_linux.x386.c:

KERN_WARNING vmnet: You are trying to use wireless networking bridged together with vmware-any-any-update. This configuration is not supported, and your wireless bridge will probably not work

After investigating a bit, the problem is this function is only supported in vmnet.tar module that comes with the original vmware, which includes precompiled binaries smac_linux.x386.o_shipped and smac_linux.x86_64.o_shipped which support this function. But the original modules are not worth because they do not compile in the kernel 2.6.24

La “soluzione” proposta dalla stessa pagina che ho trovato googlando consiste nel prendere pezzi di vmnet originale e schiaffarci dentro pezzi di any-any-update-115 per generare un micro mostro che pare funzioni; io non l’ho provato, dubito che il micro mostro funzioni sul kernel 2.6.26 (dato che e’ basato sulle patch 115 e a me servivano le 117d)

Nell’attesa che cambi qualcosa (magari con l’uscita di ws 6.5), rimane funzionante il bridge con le ethernet

• procuratevi il file vmware-any-any-update117d.tar.gz da http://groups.google.com/group/vmkernelnewbies/files
• scompattate il tar.gz di vmware dove vi pare
• prendete i file vmmon.tar, vmblock.tar, vmnet.tar da vmware-any-any-update e copiateli in vmware-distrib/lib/modules/source
• fate l’installazione di vmware

a me questa procedura ha funzionato, ricordo di togliere altre eventuali patch messe magari dalla vostra distribuzione

si, mi riferisco di nuovo ad archlinux e al nuovo pacman 3.1

1. non si riesce piu’ a lavorare sui pacchetti solo da root. pazzesco. pacman lavora ancora abbastanza bene da root, makepkg invece e’ ora solo per gli utenti a meno di forzarne l’uso da root con uno switch da riga di comando. a me sfugge il discorso sicurezza se il mio utente e’ in sudoers…
2. abs non e’ piu’ incluso — va installato come pacchetto a parte
3. i mirror sono stati riuniti in un’unica lista — altro lavoro di vim per sistemare pacman.conf
4. il db di pacman e’ stato spostato — utile eh

ora pero’ installando roba mi sono imbattuto in una problematica che affligge tutti gli utenti, tanto che e’ stato aperto un bug che spiega tutto… e a parte la solita scusa degli sviluppatori “This is not a bug, this is a feature” possiamo leggere la cosa che piu’ mi sconcerta di tutto cio’:

Some background: we cannot modify packages to the new provision scheme until users don’t change to the new pacman (i.e. it appears in core).

dunque: fate una nuova versione del programma, abbastanza incompatibile con la struttura del resto (parlo specialmente di AUR), non dite niente a nessuno perche’ per fare le modifiche dovete comunque aspettare che il pacchetto sia marcato “stabile”. e chi usa testing? deve tenersi una roba mezza incompatibile? deve ricordarsi di editare a manina tutti i pacchetti in modo da renderli usufruibili dal nuovo pacman?

e quando verra’ passato in core, tutto sto casino tocchera’ a quelli che non usano testing ovviamente, che si ritrovano a dover fare tutti sti passaggi… mah

perche’ invece esce una versione nuova di portage alla settimana e l’utente non deve fare mai niente?

• superkaramba — se come me avete un widget di superkaramba sul desktop vi sarete accorti che questo non viene moltiplicato sui desktop virtuali (le facce del cubo); per risolvere questo, andate sul ccsm, attivate il plugin regole finestre (categoria gestione finestre) e sul campo Adesive scrivete class=Superkaramba & type=dock et voila’, ora il widget comparira’ su tutti i desktop virtuali
• ALT+F2 non funziona — sempre dal ccsm, su opzioni generali, campo commands, nella riga di comando 0 scrivete dcop kdesktop KDesktopIface popupExecuteCommand e da key bindings, esegui comando 0 associatelo ad alt+f2. attenzione: probabilmente verrete avvertiti di un possibile conflitto, selezionate pure disattiva esegui finestra di dialogo esegui applicazione che tanto non sembra funzionare

ed ora la cosa forse piu’ importante: come avviare compiz-fusion e fusion-icon al login in automatico.

da root eseguite quanto segue:

echo "fusion-icon" > /usr/bin/compiz-fusion
chmod +x /usr/bin/compiz-fusion

poi create il seguente file: /opt/kde/env/start_dbus_session.sh

# test for an existing bus daemon, just to be safe
if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
# if not found, launch a new one
eval `dbus-launch --sh-syntax --exit-with-session`
fi

create poi il seguente file nella home del vostro utente: ~/.kde/Autostart/fusion-icon-tray.desktop

[Desktop Entry]
Encoding=UTF-8
Exec=fusion-icon-tray
StartupNotify=false
Terminal=false
Type=Application
X-KDE-autostart-after=kdesktop

a questo punto non rimane che settare l’ambiente per usare compiz come window-manager:

echo "export KDEWM=compiz-fusion" >> ~/.bashrc

ora quando effettuate il login, dovrebbe partire l’icona di fusion nel tray e compiz-fusion come decoratore delle finestre… potete divertirvi coi temi e coi plugin!

Ora vi spiego cosè successo, anche se mi sto offendendo non è stata colpa mia, sia ben chiaro sto postando questa cosa per i poveracci che si imbatteranno in questa situazione.

Scenario: Hosting Aruba (non dite niente…), piattaforma WordPress, supporto PHP et simili, MySQL.
Uppo il mio nuovo wp, seguo le istruzioni, cancello i files che mi dice l’howto ufficiale, punto alla pagina upgrade.php…e…

500 Internal Server Error

Perbacco mi dico, qualcosa è andato storto, punto all’index.php e ancora…

500 Internal Server Error

uhm… faccio un po’ di prove, ricontrollo i files… niente.

Nel panico più totale decido di fare rollback alla versione di prima, uppo tutto, sistemo le dir e i files…e…

500 Internal Server Error

PERCHE’??! cerco su internet… compaiono post confusi alcuni dicono mod_rewrite, altri .htaccess altri ancora i permessi. Chiedo ad amici, niente, SQL è integro (fiuuu…).

Mi viene una curiosità, dopo aver letto un post dove un ragazzo aveva il mio stesso problema con la stessa situazione e il medesimo Aruba… e dove lo stesso scrive “Risolto, Aruba vuole 755″ mi metto in moto e comincio a controllare tutte le dir e TAC, la dir Avatars ha dei permessi che non sono 755. Provo con il link fornito da Aruba nel pannello per resettare i permessi, niente, provo a manella con lftp…niente… provo a cancellare, rinominare, fuckkare…niente!!!! (l’esaurimento è vicino)

Apro un ticket disperato descrivendo la situazione, stamattina (lunedi) le cose sono tornate a posto, e la dir avatar ha i permessi 755. In bocca al lupo amici, preghiamo.

:: pacman ha rilevato una versione più recente di “pacman”.
:: Si consiglia di consentire a pacman di aggiornarsi
:: prima e poi riavviare l’operazione con la versione più recente.
::
:: Aggiornare pacman adesso? [Y/n]
risoluzione delle dipendenze in corso… fatto.
ricerca dei conflitti incrociati in corso… fatto

Pacchetti: pacman-3.0.6-1

Dimensione totale dei pacchetti: 0,85 MB

Procedere con l’installazione? [Y/n]
:: Recupero dei pacchetti da current…
pacman 872,0K 67,7K/s 00:00:13 [#####################] 100%
controllo dell’integrità dei pacchetti in corso… fatto.
pulizia in corso… fatto.
(1/1) controllo dei conflitti in corso [#####################] 100%
(1/1) aggiornamento in corso di pacman [#####################] 100%
>>> VERY IMPORTANT <<<
>>> We have changed our repo layout:

>>> The current repo is gone and has been replaced by the new core repo.

>>> IT IS IMPORTANT TO CHANGE THE ENTRIES FOR THE CURRENT REPO TO CORE REPO
>>> IN YOUR /etc/pacman.conf to keep on getting updates. This is also
>>> important to satisfy dependencies of new packages in the extra repo.

io DAVVERO non capisco l’utilita’ di cambiare nome a un repository.

installi un linux, crea tutti i suoi bei device, eth0 la scheda di rete ethernet eth1 la firewire eth2 la wireless ok che bello sistemiamo tutti i file di configurazione per la wireless…

aggiorni il kernel, tutto tranquillo. continui ad aggiornare kernel (col passare dei mesi), tutto tranquillo.

aggiorni da 2.6.21 a 2.6.22, la morte: eth2 diventa eth1. cosi’. a caso. non so perche’.

PS: non e’ un grosso problema, si risolve in 3 minuti netti, ma non capisco perche’ i numeri debbano cambiare cosi’, sua sponte

evviva OpenSUSE! evviva KIWI!