oriolrius.cat

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.

Reading time: 3 – 5 minutes

El 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

Reading time: 1 – 2 minutes

Finalment l’última entrega de la trilogia de podcasts sobre SOCKS. Com indica el títol i podeu veure amb els links aquest parla d’eines per montar servidors SOCKS i wrappers per montar clients SOCKS5.

El podcast:

Referències:

• Apunts per fer el podcast: fitxer .txt amb les meves notes per fer el podcast, mig en català i anglès.
• Servidors:
  • Dante
  • SS5
• Clients/Wrappers/Proxifiers:
  • tsocks
  • csocks
  • connect-proxy
  • proxychains
  • SocksiPy (python)
• ICP (Internet Cache Protocol)
  • RFC2186 v2 protocol spec
  • RFC2187 v2 apps spec

Reading time: 4 – 7 minutes

La segona part sobre la trilogia de SOCKS5.

El podcast:

Exemples extrets del XEP-0065:

Example 1. Initiator Sends Service Discovery Request to Target

<iq type='get'
    from='initiator@example.com/foo'
    to='target@example.org/bar'
    id='hello'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 2. Target Replies to Service Discovery Request

<iq type='result'
    from='target@example.org/bar'
    to='initiator@example.com/foo'
    id='hello'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='proxy'
        type='bytestreams'
        name='SOCKS5 Bytestreams Service'/>
    <feature var='http://jabber.org/protocol/bytestreams'/>
  </query>
</iq>

Example 3. Initiator Sends Service Discovery Request to Server

<iq type='get'
    from='initiator@example.com/foo'
    to='example.com'
    id='server_items'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

Example 4. Server Replies to Service Discovery Request

<iq type='result'
    from='example.com'
    to='initiator@example.com/foo'
    id='server_items'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='streamhostproxy.example.net' name='Bytestreams Proxy'/>
  </query>
</iq>

Example 5. Initiator Sends Service Discovery Request to Proxy

<iq type='get'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='proxy_info'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 6. Server Replies to Service Discovery Request

<iq type='result'
    from='streamhostproxy.example.net'
    to='initiator@example.com/foo'
    id='proxy_info'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='proxy'
              type='bytestreams'
              name='SOCKS5 Bytestreams Service'/>
    <feature var='http://jabber.org/protocol/bytestreams'/>
  </query>
</iq>

Example 7. Initiator Requests Network Address from Proxy

<iq type='get'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'/>
</iq>

Example 8. Proxy Informs Initiator of Network Address

<iq type='result'
    from='streamhostproxy.example.net'
    to='initiator@example.com/foo'
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'>
         sid='vxf9n471bn46'>
    <streamhost
        jid='streamhostproxy.example.net'
        host='24.24.24.1'
        p
        zeroconf='_jabber.bytestreams'/>
  </query>
</iq>

Example 9. Proxy Returns Error to Initiator

<iq type='error'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'/>
  <error code='403' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Example 10. Proxy Returns Error to Initiator

<iq type='error'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'/>
  <error code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Example 11. Initiation of Interaction

<iq type='set'
    from='initiator@example.com/foo'
    to='target@example.org/bar'
    id='initiate'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'
         mode='tcp'>
    <streamhost
        jid='initiator@example.com/foo'
        host='192.168.4.1'
        port='5086'/>
    <streamhost
        jid='streamhostproxy.example.net'
        host='24.24.24.1'
        zeroconf='_jabber.bytestreams'/>
  </query>
</iq>

Example 12. Target Refuses Bytestream

<iq type='error'
    from='target@example.org/bar'
    to='initiator@example.com/foo'
    id='initiate'>
  <error code='406' type='auth'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Example 13. Target Is Unable to Connect to Any StreamHost and Wishes to End Transaction

<iq type='error'
    from='target@example.org/bar'
    to='initiator@example.com/foo'
    id='initiate'>
  <error code='404' type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Example 16. Target Notifies Initiator of Connection

<iq type='result'
    from='target@example.org/bar'
    to='initiator@example.com/foo'
    id='initiate'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'>
    <streamhost-used jid='streamhostproxy.example.net'/>
  </query>
</iq>

Example 19. Initiator Requests Activation of Bytestream

<iq type='set'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='activate'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'>
    <activate>target@example.org/bar</activate>
  </query>
</iq>

Example 20. Proxy Informs Initiator of Activation

<iq type='result'
    from='streamhostproxy.example.net'
    to='initiator@example.com/foo'
    id='activate'/>

Referències:

• Apunts per fer el podcast: fitxer .txt amb la llista de coses que volia comentar al podcast és una barreja de català, castellà i anglès.
• RFC i XEPs:
  • RFC1928: SOCKS Protocol v5
  • XEP-0065: SOCKS5 Bytestream
  • XEP-0030: Service Discovery
  • Extencions del XMPP: tots els XEPs

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.

Reading time: 2 – 2 minutes

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

Reading time: 2 – 2 minutes

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).

Reading time: 3 – 4 minutes

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:

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:
  • RFC1928: SOCKS Protocol v5
  • RFC1929: Username/Password Authentication for SOCKS V5
  • RFC1961: GSS-API Authentication Method for SOCKS V5

Reading time: 1 – 2 minutes

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é.

Reading time: < 1 minute

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]