Desarrollo y Tecnología

#Transbank y Servidores fuera de #Chile para los #eCommerce

22/06/2015 por Cristian Tala Sánchez

Ya somos muchos los que hemos estado teniendo problemas con conexión de nuestro eCommerce a Transbank. ¿ A que se debe esto ?

Desde ya hace unas semanas, un par antes del #CyberDay en Chile, han habido dificultades con las conexiones de los sitios web a transbank. Ahora existe un comunicado «Algo más oficial» para los que tenemos nuestros propios sitios eCommerce en nuestros propios servidores.

Por políticas de seguridad han bloqueado ciertos IPs del extranjero ( no estoy seguro que sean todos ) y esto es sencillo de arreglar pidiendo que agreguen tu IP a un whitelist para que pueda generar las conexiones en el servidor de producción. Esto se debe a un incremento en la seguridad por parte de Transbank para evitar posibles problemas.

Al parecer el problema crítico es en el servidor de certificación en donde hoy estaba teniendo problemas con la conexión de uno de los sitios y la respuesta fue la siguiente :

Cristian, buenas tardes:
Según lo revisado, te comento que no nos será posible hacer la revisión de este sitio web, debido a que se encuentra en un servidor fuera de Chile y por políticas de seguridad implementadas en el área de comunicaciones, no se tiene acceso desde equipos fuera de chile al ambiente de certificación. Esta medida es de carácter permanente por lo cual recomiendo evaluar la opción de contratar un hosting nacional.
Cabe destacar que esto es solamente para el ambiente de certificación. No hay problemas en mantener un ambiente productivo en un hosting fuera de Chile.
Lamentamos los inconvenientes generados por esta situación.
Quedo atento a tus comentarios.
Saludos cordiales,
XXXX XXXX

Por lo tanto ya sabemos de ante mano que al menos para le certificación debemos tener un servidor nacional. Si aún tienes problemas con tu servidor en producción por favor hablar a Transbank para que agreguen tu IP a un whitelist para no tener problemas.

Si bien esto puede hacer un poco más complejo el proceso de tener nuestros eCommerce con pago con tarjetas de crédito, no olviden que alternativas de pago existen bastantes y que el mayor porcentaje de compras a través de internet aún son por débito y no por crédito. No se asusten de usar medios de pago para transferencias bancarias como lo puede ser Khipu.

Oracle Java (JDK) 7 / 8 / 9 PPA en Ubuntu

12/06/2015 por Cristian Tala Sánchez

Hace ya un tiempo que en Ubuntu no aparece en repositorios la versión de Oracle para Java. Hay algunas aplicaciones que no funcionan con la versión del OpenJDK por lo que agrego la forma como lo he estado haciendo últimamente para mis proyectos.

Si bien la instalación la puedo hacer a través del instalador que aparece en la web, este proceso es mucho más sencillo y veloz.

Detectar el Email Spoofing y no morir en el intento.

26/05/2015 por Cristian Tala Sánchez

Email spoofing es la creación de un mensaje de email en donde el autor o quién lo envía es una falsificación. Es bastante sencillo debido a que los protocolos no tienen ningún mecanismo de autenticación para prevenirlo.

Es por eso que debemos saber detectarlo a tiempo.

Si bien en algunos casos el email spoofing puede ser considerado legal, en muchos otros se usa con el sentido de realizar Phishing o simplemente suplantación de identidad.

A nosotros lamentablemente nos pasó hoy con un mail dirigido aparentemente desde el Banco BBVA. Si bien sistemas de correo como GMail, Outlook y otros filtran este tipo de correos que poseen errores en su encabezado, alguno puede llegar a pasar generando un conflicto mayor, como lo puede ser una estafa.

Antes que todo es bueno aclarar que si el correo recibido llegó a SPAM es muy posible que sea por qué lo es, no importa lo que te digan. El proceso en el cual te convencen de lo contrario se llama Hacking Social y es el tipo de Hacking más efectivo.

Para poder asegurarnos que el correo proviene de quién dice ser, tenemos que tener acceso a las cabeceras del email. En Gmail es muy sencillo, simplemente seleccionamos la opción de ver original.

Una vez abierto el mail original podemos ver algo como lo que tenemos a continuación.

En este caso quiero rescatar algunos datos que claramente no coinciden con lo que debería aparecer.

En el campo Received, aparece que es enviado desde emkei.cz que al parecer es uno de los servicios más populares para enviar emails falsos.
En el Received SPF, aparece un softfail, y lo que significa en este caso que la dirección desde donde se realizó el envío de este correo no está dentro de las permitidas para el dominio. Esto en general no está bien configurado por muchos servidores, por lo que por si solo no puede definir si el correo es sustitución o no, pero las probabilidades que una empresa grande, como lo es un banco, lo tenga mal configurado es poco probable.

Si tomamos los dos puntos anteriores en conjunto, podemos tener una idea más clara de lo que puede estar pasando.

Recuerda además que las probabilidades de que un correo correcto vaya a spam es mucho menor que la de un correo incorrecto lo haga. ¡ Siempre duda en el correo que te llegue a spam y quien te diga que lo revises ! Al menos yo desde el día de hoy lo haré.

Origen: Email spoofing – Wikipedia, the free encyclopedia

Firewall usando UFW en un servidor Ubuntu / Debian

23/05/2015 por Cristian Tala Sánchez

Aprende como configurar un firewall usando UFW ( Uncomplicated Firewall ) en un servidor Ubuntu / Debian.

Soy de las personas que siempre a usado IPTables para configurar el firewall de un servidor, pero la verdad es que no lo se de memoria y siempre debo recordarlo al momento de realizarlo. Esto es debido a que no lo hago muy seguido y no es muy amigable.

UFW es una herramienta o frontend que agrega estas reglas al firewall de iptables de una manera sencillo y casi humana de entender, por lo que para mi ha sido genial debido a que puedo tener la fortaleza de iptables pero de una manera que es muy práctica y difícil de olvidar.

Hace poco menos de un año que comencé a usar UFW para gestionar las reglas de IPTables, y se lo recomendé a muchas personas debido a su simplicidad. Este jueves fui a casa de un amigo y me encontré que estaba configurando un servidor debian usando UFW y empecé a ver el proceso y ayudarlo un poco ( ¡ Pero solo de curioso ! No creo que haya necesitado ayuda en verdad ). Me di cuenta que recordaba todos los comandos de como usarlo y no mucha gente lo conoce, por lo que la recomendación ahora se extiende con un mini tutorial de como usarlo a todo aquel quién le sirva.

En este caso el tutorial lo haré con un ejemplo de un sitio wordpress que corre en un servidor Ubuntu 14.04 que debo configurar.

Ya teniendo el sitio andando, lo primero que quiero hacer es bloquear todas las conexiones por defecto excepto al puerto 80 ( http ) y al 22 ( ssh )

Si no tienes ufw simplemente lo instalamos :

sudo apt-get install ufw

Podemos ver el estado de las reglas actuales ejecutando

sudo ufw status

Si estás partiendo de cero igual que yo, lo más probable que el resultado sea : «Status: inactive»

Para activarlo simplemente ejecutamos :

sudo ufw enable

Antes de hacer cualquier cosa, agreguemos la regla de ssh para las conexiones permitidas en caso de que bloquemos todo por error.

# sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
22 (v6)                    ALLOW       Anywhere (v6)

A esta altura tenemos el servidor de firewall activo, y tenemos dos reglas para acceso ssh por IPV4 y IPV6.

Lo siguiente que me gusta hacer es que por defecto de bloqueen todas las conexiones entrantes, es aquí donde alguien puede diferir conmigo, pero para mi lógica es mejor bloquear todo y luego aceptar que aceptar y luego bloquear. Esto lo hacemos de la siguiente manera :

sudo ufw default deny incoming

Si trabajas con webservices y no coneces los puertos por los que tu servidor se conectará a futuro a ellos, lo más sencillo es dejar que la política de conexiones salientes sea para permitirlas todas. Esto sería bueno cambiarlo a futuro cuando tengas certeza a que servidores te vas a conectar y sus puertos.

sudo ufw default allow outgoing

A esta altura tenemos el servicio andando, aceptando conexiones ssh, pero no podemos acceder a nuestra página web. Para hacerlo lo podemos hacer de dos maneras, especificando el servicio o el puerto. Adjunto las dos formas :

sudo ufw allow http
sudo ufw allow 80/tcp

Si bien, esto es todo lo que quiero incluir en este tutorial, hay otra cosa que se debería hacer que recomiendo. Me gusta cambiar el puerto del ssh a un puerto obviamente que vayas a recordar.

Imaginemos que este puerto es el 2228, lo que haremos es agregar esta regla al firewall y luego lo cambiaremos en la configuración del ssh.

sudo ufw allow 2228

Editamos el archivo de configuración del server ssh :

sudo vim /etc/ssh/sshd_config

Y editamos la línea que dice Port por el puerto que nosotros queramos ocupar y reiniciamos el servicio ssh.

sudo service ssh restart

En estos momento ya necesito el nuevo puerto para acceder, pero tenemos reglas que nos sobran. Ahora podemos eliminar nuestra regla de ssh que creamos en un comienzo debido a que ya no la vamos a utilizar.

sudo ufw delete allow ssh

Ya, ahora tenemos un server PSEUDOSEGURO, o al menos mucho mejor de lo que viene por defecto. Ojala les sirva !

Origen: How To Setup a Firewall with UFW on an Ubuntu and Debian Cloud Server | DigitalOcean

Redireccionar HTTP a HTTPS con ModRewrite y .htaccess

18/04/2015 por Cristian Tala Sánchez

En general cuando manejas wordpress y cambias la dirección del sitio por defecto a HTTPS, se manejan internamente las redirecciones para poder usar las nuevas direcciones.

El problema a veces es simplemente la página de inicio, que no se redirecciona por defecto. Hay plugins que te pueden hacer la vida más sencilla en esto, pero obviamente soy de las personas que no les gusta el camino fácil.

Si tu servidor tiene el mod_rewrite de apache2 activado, lo más sencillo es decirle que «reescriba» las direcciones dependiendo del contenido, y simplemente haga una redirección ( 301 ).

A continuación veremos como redireccionar las url para la que corresponda. Este es el mismo proceso que se usa para cuando cambias tu web de dirección.

Mi situación es la siguiente, y lo más probable es que tu no necesites todas estas condiciones, tengo un servidor cuyo certificado solo es con «www», o sea, «https://www.MISITIO.cl» es el único que está certificado, por lo que no me sirve el «https://MISITIO.cl», tomando esto en consideración, y sabiendo que el tráfico sin SSL ( no https ) no es seguro, tengo las siguientes condiciones.


#PARA LA REDIRECCIÓN HTTPS


#Prendemos el motor modrewrite. Esto es necesario para que las condiciones y reg
las funcionen.
RewriteEngine on

#Primera condición, SI es HTTPS sin wwww, que redireccione a www.
RewriteCond %{HTTPS} on
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

#Segunda condición. Si no es HTTPS y no tiene www, redirecciono a HTTPS con WWW.
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*) https://www.%{SERVER_NAME}/$1 [R,L]

#Tercero, si no es HTTPS y ya tiene www, solo redirecciono a HTTPS
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [R,L]

Eso sería todo, debería abarcar todas las condiciones.