Estos dos servicios son implementados gracias a OpenSSH, un servicio-aplicación instalada casi obligatoriamente para un sin fin de usos. Para los menos dados normalmente tan solo usarán SFTP, para el usuario medio/avanzado usará igualmente SSH. Pero cualquiera de los dos métodos funciona "igual".
El mayor problema de OpenSSH es evidentemente la seguridad. Como cualquier método de acceso remoto, exponer abiertamente nuestro jugete al alcance de cualquier hacker de tres al cuartos puede ser algo peligroso, más si en nuestro dispositivo guardamos datos comprometidos o sensibles. Al tener habilitado OpenSSH implica que cualquier persona que esté en ese momento en nuestra misma red (o en WAN si hay tráfico dirigido) puede intentar acceder (con o sin exito) a nuestro iPod Touch/iPhone. Y a ello podemos sumar además la inseguridad en sí de una conexión wifi.
Aquí no vamos a explicar como securizar una conexión wifi, pero al menos como poner las cosas más complicadas para los demás y más facil para nosotros, a la hora de tener acceso a nuestro dispositivo.
Nos enfrentamos a algunos problemas graves de seguridad:
1º. Contraseñas y nombres de usuario por defecto
Por defecto hay dos cuentas principales de usuarios. La cuenta 'root' (administrador) y la cuenta 'mobile' (limitada). Pero para ambos la contraseña es 'alpine'. El primer problema es que el 90% de las personas no cambian la contraseña por defecto (añadir o cambiar los nombres de usuario es más sucio). Esto significa que cualquier persona conectado a la misma red en ese momento, desde otro iPod/iPhone, PC, PDA... podría conectarse sin problema a nuestro dispositivo con los credenciales por defecto!! Lo que quiere decir es que podrían desde copiarnos datos sensibles, información personal, eliminarnos archivos, agenda, calendario, llamadas...
Tan solo modificando la contraseña de LAS DOS CUENTAS estaremos interponiendo la primera barrera. Tener en cuenta que es muy facil para un hacker mediocre hacer un escaner rápido en una red y ver los iPod/iPhone conectados a ella. Imaginaros en la universidad por ejemplo, o en la empresa. La probabilidad de encontrar alguien con un dispositivo conectado y vulnerable son muy altas, y eso sin contar con otro tipo de técnicas.
Como he dicho es necesario modificar la contraseña de las dos cuentas. Aunque muchos incluso no lo saben, no solo podemos acceder co la cuenta de 'root'. Podemos acceder perfectamente también desde la cuenta 'mobile' aunque evidentemente tendremos ciertas restricciones.
Comenzando por este punto, para modificar la contraseña tan solo necesitamos tener instalado Cydia. Y digo Cydia porque no es posible hacerlo con BSD Subsystem. Las utilidades de BSD Subsystem estan llenas la mayoria de fallos, y en este caso lo está la herramienta 'passwd'. Si lo intentamos con BSD tendremos una bonita "rueda de la muerte". Así que presuponemos que tenemos Cydia. Lo único que tendremos que hacer será entrar por SSH con el usuario root. Una vez hayamos entrado, tan solo tenemos que teclear el comando: "passwd". Una vez tecleado el comando, el dispositivo nos pedirá por la nueva contraseña, la cual deberemos de introducir dos veces. Una vez realizado la contraseña se habrá cambiado con éxito.
Como he dicho sería necesario modificar igualmente la contraseña del usuario 'mobile'. Para ello tan solo tenemo que hacer lo mismo, entrar por SSH pero con el usuario mobile. Una vez dentro teclear de nuevo el mismo comando. En este caso sí nos pedirá antes de permitir cambiar la contraseña la contraseña antigua. Recordar que por defecto, tanto para mobile como para root la contraseña es 'alpine'. Cuando acabemos este simple proceso la contraseña será aquella que elegimos.
2º. WIFI y SSH innecesario las 24 horas
Evidentemente para evitar posibles ataques hay que no dar pie a que puedan entrar. Hay dos "barreras" lógicas. La primera es SSH y la segunda WIFI.
OpenSSH es un demonio que se carga al iniciar el dispositivo y permanece a la escucha sobre el puerto 22, que es el común para transmisiones SSH. Al detectar tráfico por ese puerto se activa. Contrariamente a lo que se cree, OpenSSH NO CONSUME batería por estar el servicio activado, al contrario que si pasaba con el anterior servidor SSH dropbear. Mientras esté tan solo escuchando, el consumo de energía por OpenSSH será de 0%... aunque evidentemente es un riesgo natural. WIFI podemos necesitarlo en cualquier momento, pero nunca sabemos quien pueda estar a la "escucha" en la red. Si el servicio SSH está levantado en nusetra máquina aceptará todas las conexiones entrantes. Luego OpenSSH tan solo debería de estar habilitado cuando realmente lo necesitemos. Para habilitarlo o deshabilitarlo basta con instalar NetServices por ejemplo, que con un simple deslizar se activa o se desactiva.
La segunda barrera es evidentemente WIFI. Tan solo activar WIFI cuando sea necesario, y WIFI si consume batería, al contrario que OpenSSH, luego en caso de WIFI la recomendación de tenerlo apagado es doble. Evidentemente si hay conexion es posible que alguien pueda colarse.
Uno puede pensar que tan solo desactivando wifi cuando no se necesite el problema se resuelve. NO. Si OpenSSH está activado, en cualquier momento que uno se conecte a una red wifi su dispositivo es vulnerable. Normalmente es más facil olvidar desactivar OpenSSH (por comodidad) que WIFI. Lo ideal? desactivar ambos cuando no se requiera. Aunque esto puede llegar a ser muy incómodo, sobre todo para personas que usan muy exaustivamente SSH y SFTP.
3º. Usar una autentificación basada en clave pública en vez de acceso por contraseña
Lo que la mayoría sabe a estas alturas es que SSH permite autorización por contraseña. Un nombre de usuario y una contraseña (que por defecto es alpine) es suficiente para tener acceso ilimitado. Si ademas conocemos de antemano también el nombre de las cuentas... Hemos aprendido a cambiar la contraseña, pero esto tiene algunos problemas, aunque evidentemente es muchisimo más seguro que dejarlo con el pass por defecto:
El primer problema es que si es una contraseña compleja, cada vez que queramos acceder tener que teclearla puede ser un martirio. Aunque esto tampoco llega a ser un problema, en casa se puede configurar Putty o WinSCP para automatizar todo el proceso
El segundo problema es que una contraseña se puede averiguar sin mucho problema (En la tercera parte pondre ejemplos reales). Y no solo averiguar, sino realizar ataques de diccionarios e incluso de fuerza bruta. Incluso con una contraseña compleja.
El tercer problema es que podría ser posible acceder al sistema en un descuido, copiar o sustitur el archivo de contraseñas "master.passwd" y obtener la contraseña.
SSH es en teoría un protocolo seguro y ya de por sí basado en clave pública. La primera vez que nos conectamos a una máquina SSH esta nos manda su clave pública. Todos hemos visto el cartel de confirmación de aceptar la clave pública la primera vez que nso conectamos. Al introducir la contraseña de acceso esta se encripta con la clave publica del servidor, y la manda codificada, de modo que el servidor que es el único que posee la clave privada pareja es capaz de abrir el mensaje, recivir la contraseña e introducirla en la máquina. Así se evitan posbles ataques por medio de sniffers, ya que la contraseña jamás será vista. Pero este proceso no evita ningun posible problema antes comentado.
Para asegurar esto un poco más lo que se hace es en vez de optar por una autentificación basada en contraseña, realizar una basada completamente en clave pública. Ya hemos dicho que el servidor tiene las suyas propias (en este caso el ipod/iphone), pero podemos hacer lo siguiente:
Generamos nosotros otro juego de claves, una privada y su pública
Entregamos nusetra llave pública al servidor y le decimos que puede usarla como cliente autorizado
En la próxima conexion que se realize, el servidor nos enviará un testigo cifrado con nuestra clave publica. Como nosotros tenemos la clave privada le contestamos correctamente. Igualmente el hace lo mismo cno su clave pública para asegurarnos nosotros a la vez que nos estamos conectando al servidor debido. Una vez realizado el proceso se concede el acceso, sin necesidad ya de introducir contraseñas y el problema de ellas.
Todo esto suena más complicado de como es en realidad. Para hacer todo esto tan solo debemos de usar herramientas que ya tenemos en el PC instaladas.
Lo primero como he dicho es genera un par de claves. Los sistemas basados en clave pública son los más robustos ahora mismo del mundo, a día de hoy impenetrables. Se basa en una premisa simple: Es imposible calcular predecir... si un número es primo y factorizarlo. Todo el mundo sabe que es un número primo: 1, 2, 3, 5, 7, 11, 13, 17... solo divisibles por 1 y por ellos mismos. Pero si yo preguntase si el número 123^123 es primo o no y cuales sus factores... la única forma de saberlo sería ir dividiendo ese número por 1, despues por 2, despues por 3... computacionalmente es imposible. Lo que se hace pues es generar dos claves, resumiendo mucho mucho digamos que una es el numero resultante de la multiplicación de otros dos primos, y la clave privada son los dos numeros primos que generan la clave publica (el primo). En resumidas cuentas, es imposible a día de hoy quebrantar este sistema, al menos el sistema en sí. La clave pubica se da libremente, a fin de cuentas nadie será capaz jamas, ni en 100 años de calcular la clave privada. Y la clave privada es lo que se guarda de manera celosa ;). Despues es tan facil como cifrar un mensaje con la clave pública por otros métodos que ahora no vienen al cuento, y la clave que descifra el mensaje no es la misma clave publica, sino tan solo la clave privada, es lo que se conoce como cifrado asimetrico. Normalmente estamos acostumbrados a cifrados simetricos, la misma contraseña con la que protegemos un archivo es la misma que usamos para desprotegerlo.
Bueno dicho esto tan solo queda ponerse manos a la obra:
Primero generaremos el par de caves, lo cual podemos hacer con una utilidad que tendremos ya instalada, si tenemos instalado WinSCP: PutyGen
Es muy simple. Yo he optado en la imagen de generar una clave de 2048 bits, más que suficiente, quien quiera puede usar claves más potentes, incluso de 4096. Y tambien se tiene la opcion de usar RSA como DSA. Los dos son algoritmos de clave públicas, muy similares. Existen los dos porque el algoritmo RSA estaba patentado y no se podía usar, y de ahí salio DSA. A efectos prácticos da igual, DSA funciona con el mismo principio y es casi casi igual que RSA, así que... diría usar DSA por la patente de RSA, pero la verdad es que a día de hoy la patente RSA caducó, y puede ser usada libremente.
Una vez le demos a generate saldrá una barra verde que podemos observar y se nos pedirá que movamos el ratón por la zona justo de debajo. Cuando lo hagamos la clave se irá generando. Por que esto? porque para asegurar la creación de una buena clave, el PC necesita generar datos aleatorios puros, y los algoritmos para generar números aleatorios son predecibles. Así que esto ayuda a generar valores aleatorios.
Una vez terminado el proceso tendremos algo parecido a lo siguiente:
Lo que vemos es la clave pública. Primero tenemos que guardar y poner a buen recaudo la clave privada, y si queremos para mayor seguridad se puede proteger tambien con una clave, de este modo la clave privada se encripta con una clave. Irónico verdad? ;) la guardamos por ejemplo en la misma carpeta de WinSCP y sin cifrado.
Y de paso, hacemos un copy paste de la clave pública. No le damos a save public key, ya que el formato que necesitamos es el de arriba, no el que se genra al darle al botón. En realidad es igual, solo modifica una cosilla. Copiamos ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQ... (en mi caso)
Tambien se puede poner una descripción, en mi caso prueba, podeis poner key ipod/iphone.
Una vez terminado esto creamos en el escritorio, por ejemplo, un archivo de texto y pegamos encima toda la clave pública. Si se hace bien tan solo se verá una sola linea gigante de letras y números (si la opción de Ajuste de Linea del bloc de notas está desactivada evidentemente). Guardamos ese archivo y lo renombramos a: "authorized_keys" sin extensión ninguna,
ese es el archivo que usara nuestro dispositivo para almacenar las claves públicas autorizadas. y será el único archivo que copiaremos al dispositivo. La clave privada en cambio es para nosotros tan solo.
Y ya tan solo queda configurar las dos partes: 1º el servidor y despues el cliente
Para configurar el servidor es muy simple. Quizás el más simple para vosotros sea acceder por WinSCP (aun por el método tradicional) y nos situamos en la carpeta /private/etc/ssh y localizamos el archivo "sshd_config". Lo editamos y tan solo tenemos que habilitar un par de líneas, y habilitar tan solo quiere decir eliminar el símbolo de #. bajamos hasta dnd aparece:
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
Y tan solo tenemos que eliminar las #:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Podemos si queremos deshabilitar tambíen de forma permanente el acceso por contraseña, de modo que tan solo sea posible acceder por este método. De esta forma, a menos que nusetro dispositivo tenga una copia de la clave pública especificada no se tendrá acceso al sistema. Si no se activan las siguientes opciones, lo primero se intentará el acceso por clave pública, pero si este falla se volverá al sistema antiguo, con lo que no se gana demasiado. OJO!!! ESTO SOLO SE DEBE DE MODIFICAR UNA VEZ HEMOS COMPROBADO QUE PODEMOS ACCEDER DESDE NUESTRO PC, SI NO ES ASI MODIFICAR ESTO PUEDE PROBOCAR NO PODER ACCEDER MAS POR SSH, anuq siempre podemos entrar por terminal de forma local o desinstalar SSH.
Luego estas modificaciones tan solo es aconsejable hacerlo despues de todo el proceso, pero dado que estamos con el archivo en cuestion lo pongo ahora, repito, solo cuando hayamos comprobado que el sistema funciona:
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
Si quitamos los # y lo configuramos de esa forma, deshabilitaremos el acceso por contraseña, por PAM y por challenge, luego tan solo nos quedará el acceso por clave pública.
Tambien puede ser muy interesante modificar el puerto por defecto: "22" a otro. El puerto 22 es extensamente barrido en cualquier escaner de puerto, y llama mucho la atención. Es aconsejable moverlo a otro puerto, y para asegurarnos que no usamos alguno del sistema podemos eleguir de manera segura casi cualquier puerto desde el 10000-65000. Hay que recordar el puerto, puesto que a la hora de configurar el cliente deberemos modificar el puerto 22 al seleccionado:
#Port 22
lo modificamos a por ejemplo:
Port 15021
Una vez acabado el archivo editado, lo guardamos y listo.
Tan solo queda copiar el archivo de claves "authorized_keys" que tenemos en el escritorio. Tan solo debemos de copiarlo en :
/private/var/root/.ssh/
Una vez copiado nos aseguramos que los permisos de las siguientes carpetas quedan así: (NO ACTIVAR RECURSIVIDAD)
/private/var/root -> 0644
/private/var/root/.ssh -> 0700
/private/var/root/.ssh/authorized_keys -> 0755
Una vez copiado el archivo tan solo queda comprobar que la conexión funciona perfectamente. Ahora tan solo tenemos que abrir WinSCP por ejemplo. La configuración es igual, exceptuando:
Si hemos modificado el puerto, lo modificamos también.
Ya no hace falta contraseña, así que el campo de password lo eliminamos
Hace falta añadir la clave privada guardada anteriormente, así que en el campo private key file colocamos la clave privada que dijimos la guardábamos en la misma carpeta que WinSCP. Listo:
Como sabemos si funciona? le damos a conectar. Si conecta sin pedirnos contraseña éxito. Nota que el nombre de usuario deberemos de introducirlo de todos modos.
La configuración de putty es exactamente igual, salvo que la clave privada se mete en otro sitio:
En mi caso como podeis ver en las imágenes el proceso es completamente automatizado. ni contraseña ni usuario. Aunque esto se puede tambien automatizar sin necesidad de clave pública. Una vez que el sistema funciona, podemos modificar las opciones citadas anteriormente y así estaremos ante una fortaleza a la que nadie, sin nuestro permiso, podrá entrar. Si deseamos añadir un cliente más, tan solo tendrá que generar su par de claves y copiar la clave publica del cliente en nuestro archivo ya creado "authorized_keys", a continuación ahora sí, de la anterior.
Eso es todo por hoy
Entradas
No hay comentarios:
Publicar un comentario