viernes, 29 de noviembre de 2013

Cómo arreglar el error com.android.phone en Android 4.3 con Pepephone y otras OMV's

Hola de nuevo,

hace un tiempo actualicé por OTA mi Nexus 4 a Android 4.3 (Jelly Bean).
Una vez aplicada la OTA, siempre es recomendable hacer un Factory Reset para borrar todos los datos y evitar conflictos con ficheros antiguos, así que hice el Factory Reset y al reiniciar empezó a salirme una ventana de error de "com.android.phone" que no te permitía hacer nada, ya que al darle al botón de aceptar volvía a salir una nueva ventana inmediatamente.

El problema viene porque la SIM de Pepephone (y otros OMV's) contiene por defecto un montón de APN's que hace que Android 4.3 falle (ojo, con 4.4 no pasa).
Y la solución es bien sencilla, hay que borrar todos los APN's y poner el de tu compañía a mano, pero claro, con la ventana de error saliendo continuamente se hace muy dificil llegar hasta los APN's y borrarlos.
Si pones el móvil en modo avión deja de salirte el error, pero tienes el problema de que estando en modo avión no te permite entrar en los ajustes para borrar los APN's.

Publiqué la solución en HTCMania hace un tiempo en el foro de Nexus 4, pero me consta que ahora ocurre en más teléfonos que se están actualizando a 4.3 y por eso lo publico aquí también.

Los pasos a seguir para arreglar en error sin necesidad de ser root son los siguientes:

1. Instalamos la OTA
2. Factory reset (y perdemos todos los datos, fotos, vídeos, etc)
3. Primer reinicio y no para de darnos el error
4. Salimos del asistente de inicio (ya crearemos la cuenta después)
5. Ponemos modo avión (dejando el botón de power pulsado/modo avión). A partir de aquí ya no nos sale el error.
6. Activamos el Wifi y nos conectamos a nuestra red.
7. Vamos a ajustes/seguridad/origenes desconocidos y lo marcamos.
8. Bajamos el siguiente apk: http://bit.ly/17b3nET (totalmente fiable, lo he hecho yo, no requiere ningún permiso)
9. Lo instalamos, le damos a ejecutar y nos saldrá la lista de APN's (tras 6 segundos mostrando la pantalla de bienvenida)
10. Borramos TODOS los APN's y creamos el de nuestra compañía
11. Quitamos el modo avión y a disfrutar de 4.3

Espero que os sirva.
Saludos.

Incrementar la seguridad de tu servidor (Tercera parte) (Fail2ban)

Hola de nuevo,

después de la primera parte y de la segunda parte, vamos a explicar cómo incrementar la seguridad de nuestro servidor evitando que nos hagan un ataque de fuerza bruta (o de diccionario) a servicios que requieran un usuario y una contraseña.


Cuando hablamos de un ataque de fuerza bruta nos estamos refiriendo a que alguien empiece a probar usuarios y contraseñas en algún servicio que tengamos en nuestro servidor. Por ejemplo, en el servicio SSH, que nos pide usuario y contraseña, alguien podría empezar a probar contraseñas para el usuario "root", empezaría por aaaaaaaa, aaaaaaab, aaaaaaac, etc. Evidentemente, esto se realiza de forma automática mediante un script que va probando distintas contraseñas hasta que da con la nuestra.

De forma análoga tenemos el ataque de diccionario, en el que se prueban contraseñas de un diccionario de contraseñas, el cual contiene las contraseñas más habituales, por ejemplo "12345678", "qwertyuio", "god","password", etc.

Servicios que sean vulnerables a este tipo de ataques son SSH, apache, ftp, wordpress, etc. En general, cualquier servicio que nos pida un usuario y una contraseña.

Fail2ban es una herramienta que nos protege de este tipo de ataques, bloqueando la IP del cliente que nos está haciendo dicho ataque cuando llega a un número de intentos determinados que podemos configurar.

Es decir, podemos poner que como máximo una misma IP pueda equivocarse tres veces poniendo la contraseña de SSH, o la del admin del wordpress, o la de FTP, y al intentar una cuarta vez ya no podría conectar porque estaría bloqueado por el firewall de nuestro servidor.
Que se bloquee a nivel de firewall nos da dos ventajas:
- Que no puede seguir realizando el ataque
- Y que no nos consumirá tanto ancho de banda, ya que ni siquiera puede establecer la conexión para intentar introducir el usuario y la contraseña.
Fail2ban lo que hace es leer los ficheros de log de los distintos servicios para saber qué ip se ha equivocado al hacer login y bloquearla siguiendo unas reglas.


Para instalar fail2ban en Ubuntu tenemos que ejecutar el siguiente comando como root:

 Una vez instalado tenemos que hacer una copia del fichero /etc/fail2ban/jail.conf a jail.local para que si alguna vez se actualiza el paquete fail2ban no nos sobreescriba nuestra configuración:


Y luego hay que editar el fichero /etc/fail2ban/jail.local para activar los servicios que queremos monitorear, en mi caso serían vsftp (FTP), ssh y wordpress:


En la línea 6 (ignoreip) puedes poner IP's que NUNCA serán baneadas, por ejemplo la de tu trabajo (si es IP fija).
En la línea 7 (bantime) se especifica el tiempo de baneo, en mi caso puse 36000 segundos = 10 horas
En la línea 8 pones las veces como máximo que se pueden equivocar al poner la contraseña, he puesto 3 aunque luego en cada servicio se puede especificar las veces que quieres.

Y después tenemos la configuración para cada servicio que se entiende bastante fácil para qué es cada cosa, si tenéis dudas poned un comentario y respondo.

 Para que funcione bien hay que modificar la configuración de ssh para que en el log guarde las IP's y no los nombres de las máquinas que se contectan, para ello añadimos esta línea al final del fichero /etc/ssh/sshd_config:

 
Para que wordpress cree el fichero de log hay que instalar este plugin:
 
http://wordpress.org/plugins/wp-fail2ban/
 
El zip del plugin viene con el fichero wordpress.conf que hay que copiar en la ruta /etc/fail2ban/filter.d
 
Y luego ya podemos reinciar el ssh, el fail2ban y el wordpress:
 
 
A partir de ese momento, fail2ban empezará a banear las IP's.
Este es un ejemplo de IP's baneadas (ficticias):
 
 
 En mi servidor cada día banea unas 10 IP's, sobre todo en el servicio ssh, sobre todo de paises como Tailandia, China, etc.
Espero que os sirva, y si hay dudas, ya sabéis... un comentario ;-)

 

lunes, 28 de octubre de 2013

Incrementar la seguridad de tu servidor (Segunda parte)

Hola de nuevo,

después de la primera parte en la que hablamos de cómo conseguir que root no pudiera entrar en nuestro servidor por SSH, vamos con la segunda parte en la que aprenderemos a configurar el firewall que viene integrado en el kernel de linux, hablamos de iptables.

Por defecto una instalación de Linux es bastante segura, pero aún así siempre es mejor configurar el firewall para que sólo tengamos abiertos los puertos que queremos, aunque haya programas escuchando en más puertos.

Esto se hace entrando por SSH, luego obteniendo permisos de root y ejecutando el siguiente script que explicaré paso a paso:



De la línea 5 a la 8 estamos diciendo nuestra política por defecto, en concreto decimos que los paquetes entrantes (INPUT) y que pasen por nuestra máquina en dirección a otra (FORWARD) sean rechazados (DROP), y que los paquetes salientes de nuestra máquina (OUTPUT) sean aceptados (ACCEPT)

De la línea 13 a la 15 lo que hacemos es borrar cualquier regla que pudiera estar definida con anterioridad con la opción -F.

En la línea 18 estamos diciendo que cualquier paquete entrante que venga relacionado con una conexión previamente establecida sea aceptado.

En la línea 19 estamos aceptando cualquier paquete que vaya destinado a la interfaz local para que los programas locales se puedan comunicar entre si.

En la línea 22 estamos aceptando los paquetes ICMP de tipo ECHO (8), es decir, estamos aceptando paquetes que nos envíe el programa PING que sirve para ver si nuestro servidor está funcionando. Si no hacemos esto, OVH pensará que nuestro servidor ha sufrido un problema y nos abrirán un ticket de reparación automático. Además, siempre es mejor que nuestro servidor responda a los PING. En la línea 23 estamos configurando que nuestros paquetes de respuesta al PING de tipo ECHO REPLY (tipo 0) puedan salir (OUTPUT) de nuestro servidor, esto no haría falta ya que permitimos por defecto cualquier paquete saliente, pero por si acaso algún día cambiamos nuestra política por defecto no está de más incluirlo.

En la línea 24 estamos aceptando paquetes que vayan al puerto de SSH, el puerto 22 por defecto.

En la línea 28 estamos aceptado paquetes destinados al puerto 80 (HTTP) , suponiendo que nuestro servidor vaya a actuar como servidor web, en caso contrario, es mejor quitar esta línea.

De la línea 32 a la 34 estamos aceptando paquetes para el servicio FTP, puertos 21 (FTP) y 20 (FTP-DATA), así como los puertos del 40110 al 40210 cuando sea una conexión pasiva, estos últimos puertos debemos configurarlos en nuestro servidor de FTP.  Si nuestro servidor no va a actuar como servidor FTP es mejor quitar estas tres líneas.

Una vez hayamos ejecutado este script ya estariamos protegidos mediante el firewall, sin embargo, si apagáramos y encendiéramos el servidor todas las reglas se perderían, para evitar esto tenemos muchas maneras de hacerlo, la que yo hice fue la siguiente:

Crear un script en "/etc/network/if-post-down.d/iptablessave" que guarde las reglas al apagar la máquina:




Y creamos un script que cargue las reglas previamente guardadas en "/etc/network/if-pre-up.d/iptablesload"



Y con esto ya tendríamos el firewall de nuestro servidor finalizado.

Tenéis más información sobre todo esto aquí. Y también tenéis la documentación oficial de iptables aquí.

En la siguiente entrega veremos cómo seguir configurando nuestro servidor para conseguir un poco más de seguridad.
Saludos y hasta pronto.

domingo, 27 de octubre de 2013

Incrementar la seguridad de tu servidor (Primera parte)

Hola de nuevo queridos lectores, últimamente he estado algo ausente y me disculpo por ello, 6 meses sin escribir es demasiado, mea culpa :-(

Hoy os quería hablar de cómo incrementar la seguridad de un servidor dedicado ya que recientemente alquilé un Kemsirve 2G y nunca está de más hacer que el servidor sea lo más seguro posible.

Lo primero aclarar una máxima en cuanto a seguridad: la seguridad total no existe, así, subrayado para que lo tengamos todos claro. Es imposible conseguir que un servidor sea 100% seguro, siempre habrá algo que se nos escape, algún bug no documentado, algún mecanismo que permita a un cracker (que no hacker) experimentado entrar si dispone de los recursos y el tiempo necesario para hacerlo.

Aclarado este punto, vamos a intentar ponerle lo más dificil posible a nuestro cracker el acceder a nuestro servidor. Cuando digo "acceder" me refiero a que la persona atacante acabe teniendo un intérprete de comandos con nivel de "root" (administrador) o con un nivel inferior pero que le permita ejecutar ciertas acciones.

En este "tutorial" me baso en un servidor dedicado ejecutando Ubuntu Server 13.04. La mayoría de cosas servirán para otras versiones del mismo SO y también para otras distribuciones de Linux como Debian, Mint, etc.

Lo primero que debemos hacer para empezar a tener un servidor seguro es elegir bien la contraseña de root, y con "elegir bien" no me refiero a que si tu hijo se llama Juan Garcia pongas de contraseña "Ju4nG4rc1a", esta contraseña es malísima porque ya todos nos sabemos lo de cambiar letras por números que se parezcan. No, cuando digo contraseñas seguras me refiero a contraseñas del estilo de las que te generan programas como KeePass, por ejemplo esta: W5X{3uGVHwICZ9gxrEl7.

Lo siguiente que hay que hacer es actualizar tu sistema operativo, ya sabemos cómo (apt-get update && apt-get upgrade) ejecutándolo con permisos de root.

Algunas distribuciones de Linux, al instalarlas, te obligan a crear un usuario que mediante "sudo" puede ejecutar programas con permisos de root, este es el caso de Ubuntu Server. Sin embargo, la distribución de Ubuntu Server que te instala OVH no hace esto, sino que te da acceso como root por ssh. Esto es malo por dos motivos: Porque te obliga a entrar como root aunque sea para realizar tareas que no requieran permisos de root, y también es malo porque puedes recibir ataques para intentar encontrar tu contraseña de root entrando por SSH.

Por tanto, lo primero que haremos será NO permitir la entrada del usaurio root por SSH.  Para ello lo primero que tenemos que hacer es crearnos un usuario distinto a root para entrar en nuestro servidor, por ejemplo vamos a crear el usuario de nombre "asterix" con este comando:




Bastará con dejar los datos que nos vengan por defecto.

Luego comprobamos que efectivamente podemos acceder por SSH con nuestro nuevo usuario (asterix en el ejemplo) . También comprobaremos que una vez logados con nuestro usuario podemos hacer un "su -" y pasar a ser root poniendo la contraseña de éste.
Una vez hecho esto es el momento de no permitir que root entre por SSH, ya que siempre lo haremos con nuestro usuario (asterix o el nombre que le hayáis puesto) y una vez dentro haremos "su -" para ejecutar tareas administrativas. Para ello editamos el fichero "/etc/ssh/sshd_config" y añadimos esta línea al final:



Y luego hacemos un:



Ahora probamos a entrar por SSH con nuestro usuario y luego lo intentamos con root, esto último no debería dejarnos, incluso aunque hayamos puesto bien nuestra contraseña de root.

Con esto evitamos ataques de fuerza bruta al puerto SSH ya que la mayoría de estos ataques lo intentan con el usuario root, y eso ahora será imposible, incluso aunque supieran nuestra contraseña de root.
En el caso de mi servidor, nada más instalarlo, recibía ataques diarios durante horas de intentos de entrar por SSH como root, con este truco evitamos que puedan entrar de este modo.

En próximas entregas veremos cómo configurar más parámetros de nuestro servidor para hacerlo (un poco) más seguro.

Hasta pronto, un saludo.

martes, 16 de abril de 2013

Display option en una grid de Dynamics AX (Axapta) y un sólo registro

Imaginemos un formulario de Dynamics AX (Axapta) con una tabla principal en la que mostramos cierta información en modo lectura, por ejemplo registros de ventas:


Para que de un rápido vistazo el usuario pueda ver los registros que están en estado "Cancelado" podemos hacer que éstos aparezcan en rojo, sobrecargando el método "displayOption" del DataSource:

Y el resultado sería este:


Como podemos ver, aparece en rojo el que está cancelado y el resto en blanco o en gris.... hasta aquí todo bien.... ¿pero qué pasa si hay sólo un registro?
Pues efectivamente pasa que no sabemos qué color tiene, porque se resalta en azul por ser el registro activo:


¿Cómo podemos arreglar esto? Pues la solución es bastante fácil, sólo hay que poner el siguiento código en el executeQuery del dataSource:

Y al haber sólo un registro quedaría así:


Lo que estamos haciendo en ese código, es desactivar el resaltado del registro activo si hay un registro, y activarlo cuando hay más de uno. 

De esta manera, teniendo un sólo registro en la tabla, ya sea porque sólo haya un registro en la base de datos o ya sea porque hemos filtrado en el grid, podemos saber en qué estado está ese registro de un golpe de vista, viendo el color que tiene.

¡¡Hasta la próxima!!