lunes, 21 de diciembre de 2015

Bitcoin/Cryptocurrencies: ¿Que es lo que estaría ocurriendo realmente con Cryptsy?

Directamente desde reddit acabo de leer una noticia que sigue siendo difusa y complicada. El tema de la solvencia de Cryptsy continúa siendo todo un misterio. Y es que personalmente viví una amarga experiencia con ellos con dos retiros hace dos fines de semana. Intentando hacer algo de profit al caer tontamente en cambiar Doges a BTC a un mejor precio . Compré 3.8 Bitcoins en DOGEcoins (mas de 12.000.000) en BITTREX.   Todo iba bien, se enviaron dicha cantidad de DOGEs a Cryptsy y se vendieron al precio ASK del libro de ordenes que en ese momento estaba en 39/40 satoshis. Por seguridad de la primera compra que habia hecho (aprox. 0.23 BTC) los intenté transferir y noté que al pasar los minutos y luego horas jamás salieron del exchange.  Ya con la compra grande y con mucho temor por el riesgo ya tomado, compré 95 y tantos LTC los cuales igualmente transferí hacia mi wallet en una de mis cuentas Bitfinex. Increiblemente tambien quedarían atascados bajo el lema de "Pending".


Nuevamente cometí el grave error de hacer este tipo de movimientos para ganar algo extra y terminé rajado y decepcionado. Al dia de hoy, todo continúa igual. Hace mas de un año antes de la caída del exchange Mt.GOX, terriblemente me habían quedado retenidos casi 1.8 BTC los cuales con miles de excusas de parte del soporte jamás salieron retirados y hoy dia están en un largo y extensivo pleito para que sean devueltos a sus acreedores.

De todo el run-run que se ha generado alrededor de las fallas en Cryptsy, tomo en resalte el articulo publicado hace unas horas:

Traducción del articulo original:
Por SumatranOrganic:
"Muchos usuarios han reportado el sistema Cryptsy tiene problemas en los retiros mayores produciendo saldo negativo. Alguien logró explotar esa vulnerabilidad a retirar una gran cantidad de bitcoin.
Ahora con bajas reservas de Bitcoin, Paul Vernon creó un plan para tratar de recuperar los fondos perdidos. Ellos cambiaron su sistema de pago de los fee de trading y retiros, alentando así a los usuarios mantener los fondos en el sitio y para mantener más del dinero de aquellos que deciden retirarse.
Al asegurar un valor significativo como altcoins, Paul Vernon decide restringir retiros bitcoin, litecoin y ripple mientras se mantiene la retirada de algunos altcoins. Esto le permitió vender sus propios altcoins como un premio, posiblemente mientras arbitrariamente en otras bolsas. Anuncian que los moderadores no restringen en sus chats acerca de que altcoins puedan usarse para retiros, pero estan baneando a usuarios que estan "alzando la voz" insultandoles por los problemas evidentes en el sitio o gritan "Gox". 
Al acusar su cuenta por inactividad, AML o KYC, son capaces de mantener sus reservas Bitcoin restantes para mantener las operaciones en marcha y filtrar algunos retiros de manera que brinden informes esperanzadores a sus usuarios.
Al leerse vagos tweets acerca de  los  fallos debido a equipos, en las pocas semanas intentando mantener la credibilidad y dar esperanza de liquidez, ya eso no es suficiente y el agravamiento de la situación hace que continúe dañandose su reputación. 
El rumor es que Paul se encuentra actualmente en China, donde se está trabajando en el clon Cryptsy chino 'Bitebi9'.
Si bien es posible que Cryptsy recupera los fondos de los usuarios, su reputación está degradando cada día y aún queda la pregunta de cuán exacto es este artículo."

Esta nueva situación realmente prende las alertas acerca de la forma como estamos manejando las criptomonedas dejandoselas a un tercero (cualquier Exchange). Hay que tener en cuenta que cuando se depositan las coins en un exchange perdemos la capacidad de tenerlos asegurados y es que fuera de la dirección que brinda el exchange para que depositemos, nunca jamas tenemos la llave privada que nos garantice el acceso absoluto al wallet que ellos nos asignan. Pero esa es otra historia y en próximos posts estaré tocando un poco el tema a partir de dicha preocupación.

creación de usuario interno para un servicio específico (sin homedir, sin contraseña, sin login para NFS)

Algunas veces es necesario definir un usuario para algun servicio del sistema (para este caso un usuario mapeado para NFS exportado a vsFTPd). Para ello vamos a la consola y lo definimos como:

~$ sudo adduser --no-create-home --disabled-password --uid 502 --gid 1001 --disabled-login slonin
~$ sudo chown -R slonin:1002 [carpeta exportada vsFTPd]/

De esta forma luego de utilizar sus respectivos uid y gid el sistema perfectamente puede hacer escritura remota (o los permisos que se le definan).

viernes, 18 de diciembre de 2015

Retomando el blog...

De vuelta nuevamente. Casi se acaba el 2015, y antes de que termine aqui estamos nuevamente despues de 5 años de inactividad. En todo este tiempo he tenido la vocación de registrar trucos y temas interesantes en el manejo diario de GNU/Linux y desde hace mas de un año sumergido en absoluto acerca del tema de Bitcoin y otras criptomonedas en importancia, a la par con el negocio del trading y criptomonedas.  Junto a estos nuevos temas de interés y de la mano de la experiencia por muchos años con el pingüino, estamos de vuelta. Con la venia del señor, retomamos...

jueves, 18 de noviembre de 2010

OpenBSD: Autenticar usuario PPPoE Telefónica ADSL Colombia

Luego de la situación presentada hace dos dias acerca de la no respuesta en la resolución de la conectividad de una LAN atravezando los nat's entre la caja openbsd y el modem ADSL+ ZTE ZXV-W300 publiqué a un foro de OpenBSD-Colombia (hasta este momento no recibi sugerencias o comentarios algunos) y via identi.ca repliqué el mensaje a otras redes sociales. Desde Facebook un amigo y colega de años atrás, el Ing. Manuel Serrano "mañe" me comenta lo siguiente:

"Hola viejo wil, esto que tu estas intentando hacer se conoce como nat sobre nat, aunque te deberia de funcionar sin problemas te recomiendo que configures el modem adsl en modo bridge y le delegues la autenticacion pppoe a la caja con esto la ip publica sera full administrada por la caja y el modem zte solo estara practicamente trabajando en un 20%. Saludos..."

Le comentaba entonces a "Mañe" que estaría averiguando al respecto, que la solución anterior que habia logrado con triple-nat era a medias pero tenia total desinformación acerca de esa técnica. Me di la tarea de averiguarme un poco mas y fue asi cuando encontre información googleando. COn el temor de desconfigurar el modem ZTE, conversé con mi padre para que me facilitara un modelo Billion ADSL cuyos patrones de una tia por parte de papa le obsequiaron por que ya no lo necesitaban. Me traje el router... verifique las configuraciones de los patrones de la conexion ADSL (PVC0 VPI 0  VCI 35) y los registré junto con los MTU y anuncio de la puerta de enlace. Efectivamente ya la luz indicaba enlace DSL  y PPP pero algo ocurría y que habría olvidado, ya tenia el nombre de usuario PPPoE pero la contraseña.. cual sería... ?
Intentando recordar le colocaba los ultimos seis digitos de la cedula del suscriptor, los digitos completos y nada.. Luego de recoger todo entonces recordé algo que tenia que ver con la contraseña default de acceso a la cuenta de correo electrónico asignada pero me acosté a dormir... A la mañana siguiente antes de tomar rumbo a laborar, tomé el modem Billion y efectivamente logró autenticar el PPPoE. Las siguientes pruebas esa noche serían ya para verificar el mecanismo de bridge del modem y como dijo Manuel, hacerlo de tal forma que delegara sus actividades de Autenticación PPPoE, TCP/IP, enrutamiento y cortafuegos a un tercero (router Wi-Fi personal o en este caso la caja servidora con openbsd) [1]

En la próxima entrega, comentaré entonces la experiencia de lograr hacer que OpenBSD a través de la configuración de PPPoE en ella, me permitiese autenticar y/o asignar la dirección ip pública.
Hasta pronto.

[1] http://openbsd-wiki.org/index.php?title=PPPoE_Router_and_Firewall

lunes, 15 de noviembre de 2010

OpenBSD: extraño caso de fallo de nat con PF

Bueno me encuentro en una situación a la que la he denomidado como
curiosamente extraordinaria. Tengo una box OpenBSD 4.7 con kernel
stable "GENERIC" y sistema base actualizado via cvsup:

OpenBSD 4.7-stable (GENERIC) #0: Mon Oct 25 07:25:13 COT 2010
    root@garagbsd.my.domain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) CPU 2.00GHz ("GenuineIntel" 686-class) 2 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 527986688 (503MB)
avail mem = 502870016 (479MB)

imagenes:
http://www.flickr.com/photos/m0n0/4982033658/
http://www.flickr.com/photos/m0n0/4981450139/

Como lo observan es una box con hardware antiguo y limitado, y que el
sistema operativo "lo pone a andar" sin contratiempos y con
personalidad xD. Lo tengo andando en un cafe internet de mi padre como
cortafuegos,proxy y control de contenido, los dos ultimos operan sin
novedad. Ahora mi inquietud es que hay una regla especial dentro de
pf.conf que me está "mamando gallo" en ciertas condiciones.

Topología:
La conexión a internet es via ADSL de Telefónica, un modem ZTE ZXV10
W300 (feo con aspecto desechable!). los puertos LAN se asignan bajo
DHCP ( 32 direcciones a partir de la 192.168.1.2/24). Sigue entonces
la caja OpenBSD con interfaz rl0 (LAN con asignación manual
192.168.3.1/24) y rl1 (WAN asignada via DHCP desde el ZTE)
Efectivamente mi interfaz rl1 via dhcp recibe la dirección y con la
config defacto que viene con PF hace el NAT sin contratiempos desde la
misma caja. Pero si voy a una estación por debajo de la LAN de la caja
no me lo permite!. Este es la config pf.conf minimo qu usé para esto:

/etc/pf.conf
int_if="rl0"
ext_if="rl1"
localnet=$int_if:network
torrent="{ 6881:6999 }"
# scrub incoming packets
match in all scrub (no-df)


# Configuring NAT
# NOTE: This information is for OpenBSD 4.7. NAT configuration was
significantly different in earlier versions.
pass out on $ext_if from $localnet to any nat-to ($ext_if)


# Default deny
block in all
block out all


table const { self }
set skip on lo
antispoof log for $ext_if
block in quick from urpf-failed


# pass all traffic to and from the local network.
# these rules will create state entries due to the default
# "keep state" option which will automatically be applied.


pass in  on $int_if from $localnet
pass out on $int_if to $localnet


pass out on $ext_if proto { tcp, udp, icmp } all modulate state


# pass in log on $ext_if inet proto icmp to $ext_if
pass in log on $ext_if inet proto tcp to ! port { ssh,http
} synproxy state



Resumen hasta ahora: "Pienso que inexplicablemente algo ocurre entre
los "NAT's" del PF y del ZTE que no se entienden pa' nada!"

Debido a ello y revisando el FAQ oficial de openbsd con respecto al
tratamiento de NAT hago un cambio en la linea
pass out on $ext_if from $localnet to any nat-to ($ext_if)
comentandola y ajustandola por
match out on $ext_if from $localnet to any nat-to ($ext_if)

Yupi!, funciona el NAT con la estación debajo de la LAN :D pero pero
pero.. el tratamiento del pf.conf es insuficiente ya que las reglas de
block return out quick on $ext_if subsiguientes no hacen absolutamente
nada, no filtran no bloquean ya que ese cambio de forma para NAT no es
controlable con esos guiones.

==============================================
Topología: Segundo Intento!
No me doy por vencido y agrego entonces un router/AP Linksys por
debajo del ZTE y por encima de la caja openbsd.

ZTE-LAN: DHCP (IP:192-168.1.1) -> Linkys WRT54-RangeBooster WAN
(192.168.1.2), LAN DHCP (IP:192.168.2.1) -> openbsd wan
(IP:192.168.2.107) , LAN DHCP (IP:192.168.3.1)

En firmware propietario del LinkSys agrego una ruta estatica para
resolver la red 192.168.3.0 cuyo gateway es la interfaz wan de la caja
obsd (192.168.2.107). Entonces efectivamente el tratamiento de nat en
pf oficial usando

pass out on $ext_if from $localnet to any nat-to ($ext_if)

en el /etc/pf.conf Funciona permitiendome restringir entonces todo lo
demas y efectivamente poder controlar todo con mi pf

Como la ven, muy complicada la cosa ?.-..
finalmente, a que se deberá eso señores!, comentarios?