reDuh: TCP sobre HTTP
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)
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.
- ANYTerm: també suporta SSL però treballa a través d’Apache recolzant-se amb mod_proxy.
- 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.
Proxytunnel: connecta un socket a través d’un proxy HTTP i HTTPs
Descrirure tècnicament el que fa proxytunnel és força senzill, ja que l’únic que fa és connectar l’entrada i sortides estàndard a través d’un socket que va del client al servidor a través d’un servidor proxy HTTP o HTTPs; soportant autenticació de diversos tipus en el servidor proxy.
Gràcies a aquesta funcionalitat tan simple es pot aplicar en infinitat de llocs, per exemple, com a backend d’OpenSSH per tal de poder fer connexions SSH a través d’un proxy HTTP. Això si el proxy haurà de suportar el mètode CONNECT.
Un cop ha establert la connexió amb l’extrem desitjat publica un port a través del qual ens podem connectar a través d’un client TCP convencional i enviar/rebre dades de l’altre extrem del túnel.
Quan treballem sobre proxies HTTP aquests no poden fer inspecció de continguts de capa 7 sinó s’adonaran que el tràfic qeu es passa no és legítim, encanvi si fem el túnel sobre HTTPs això no e un problema ja que no es pode inspeccionar les dades que van per sobre de la capa 4 al anar xifrades.
També cal pensar que és habitual que si el mètode CONNECT, que ha de ser suportat pel proxy esta habilitat (cosa rara que passi) segurament estarà restringit a connectar-se al port 80, 8080 i 443 remots, com a molt. Així doncs, si el que volem és fer una connexió SSH el que hem de fer és publicar el servidor SSH per algún d’aquests ports.
Si esteu interessats en aplicar la solució de la connexió SSH sobre proxy HTTP/s ús recomano seguir el manual que hi ha a la pàgina: DAG WIEERS: Tunneling SSH over HTTP(S).
Podcast 2×01: introudcció i descripció detallada del protcol SOCKS5
Després de moltes hores de feina estudiant el protocol SOCKS he decidit publicar un podcast que expliqui el seu RFC, el podcast pretent fer una introducció des de la part meś conceptual fins endinsar-se en el fluxe de paquets, els camps de les peticions llençades arribant a explicacions de nivell de bit. Amb l’ajuda dels diagrames adjunts a aquest article, l’RFC1928 i l’explicació del podcast després hauriem d’estar capacitats per implementar un client/servidor SOCKS5.
El podcast:
[display_podcast]
Esquemes que ajuden a seguir el podcast
esquema 1: petició d’un client SOCKS5 al servidor
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
esquema 2: resposta del servidor SOCKS5 al client
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
mètodes d’autenticació
- X’00’ NO AUTHENTICATION REQUIRED
- X’01’ GSSAPI
- X’02’ USERNAME/PASSWORD
- X’03’ to X’7F’ IANA ASSIGNED
- X’80’ to X’FE’ RESERVED FOR PRIVATE METHODS
- X’FF’ NO ACCEPTABLE METHODS
esquema 3: el client SOCKS5 envia una comanda al servidor
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
camp: ATYP -> address type
- IP V4 address: X’01’
- DOMAINNAME: X’03’
- IP V6 address: X’04’
esquema 4: resposta del servidor SOCKS5 a la comanda del client
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
camp: REP -> reply
- X’00’ succeeded
- X’01’ general SOCKS server failure
- X’02’ connection not allowed by ruleset
- X’03’ Network unreachable
- X’04’ Host unreachable
- X’05’ Connection refused
- X’06’ TTL expired
- X’07’ Command not supported
- X’08’ Address type not supported
- X’09’ to X’FF’ unassigned
esquema 5: encapsulaments per enviaments de paquets UDP
+-----+----+-----+------------------------+------+
| ... | IP | UDP | SOCKS5 UDP ASSOCIATION | DATA |
+-----+----+-----+------------------------+------+
esquema 6: camps de l’encapsulament: UDP ASSOCIATION
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
Referències d’utilitat
- Apunts per fer el podcast: fitxer .txt amb la llista de coses que havia de comentar al podcast és una barreja de català, castellà i anglès… però pot servir-vos per entendre el que intento explicar
- Wikipedia: SOCKS
- RFC’s:
parprouted – ARP daemon
parprouted és un dimoni que fa funcions de proxy ARP, idea per fer unir dues xarxes a nivell 3 quan no estan unides per la capa 2. O sigui, no cal que fem WDS (usant en xarxes Wi-Fi) o que posem un bridge de capa 2 per unir dues xarxes separades físicament però unides a través de routing.
El funcionament del dimoni és el següent: quan es rep una petició ARP i la resposta de la petició és desconeguda llavors aquesta petició ARP es re-envia a la resta d’interficies en busca de la MAC requerida per la IP demanada en la petició ARP. Quan es localitza la IP es creen rutes estàtiques de tipus host (/32) per interconnectar aquella IP que esta en una altre interficie de xarxa diferent de la interficie que la requeria. Així aconseguim fer visible la IP entre les dues interficies de xarxa.
Totes les entrades que es creen amb el dimoni es refresquen cada 50s enviant peticions ARP que validin que encara són vigents. En cas de que les peticions fallin el propi kernel borrarà les entrades de la taula ARP i el dimoni s’encarregarà de borrar les rutes estàtiques.
Normalment es triguen uns 60ms per aconseguir fer visible un host que no esta al propi segment de xarxa degut als processos que s’han comentat, però es considera un temps marginal en comparació al benefici que se’n obté.
cookbook: extreient fitxers d’un .rpm
Coneixer la llista de fitxers al interior d’un paquet .rpm:
rpm2cpio fitxer.rpm | cpio -t
Extreure un o més fitxers del .rpm:
rpm2cpio fitxer.rpm | cpio -ivd [fitxer_a_extreure]