Con la gran cantidad de Raspberry Pis en estado salvaje, y el hecho de que grandes grupos de ellos están configurados de manera idéntica (cuando se instala una tarjeta SD recién flasheada con una de las pocas imágenes disponibles), es probable que sean un objetivo tentador para malware, incluidas las botnets.

¿Qué se puede hacer para mitigar esto?

Es razonablemente conocido que uno debe cambiar la contraseña para el usuario "pi" (Debian) y "root" (Arch.) Pero, ¿qué hay de otras cuentas del sistema (por ejemplo, "tli", "pnd"?) ¿Alguno de ellos tiene contraseñas universales que presumiblemente son las mismas para todas las unidades?

¿Y existen vulnerabilidades conocidas en otros paquetes que están instalados en las imágenes SD disponibles para el Pi (por ejemplo, debido a limitaciones de hardware o versiones reducidas de esos paquetes)?

En particular, estoy preocupado por sshmysql y cualquier otro servicio que pueda estar ejecutándose en una imagen recién instalada.

Cosas que he notado hasta ahora acerca de la imagen de stock de Debian Squeeze:

• / etc / shadow contiene un montón de hashes de contraseñas para cuentas que no son la cuenta pi (buildbot, etc.). Cambie la contraseña en la cuenta pi, naturalmente, si aún no lo ha hecho (o cree una nueva cuenta de usuario para usted y elimine la cuenta pi), pero también edite las otras entradas y reemplace los hashes con * s. Nota / etc / passwd contiene entradas duplicadas para la cuenta pi, lo que confunde muchísimo adduser / deluser, simplemente elimine una.

• la configuración predeterminada del demonio ssh permite el inicio de sesión raíz remoto. Esto debería estar deshabilitado.

• vale la pena usar netstat para verificar el conjunto de cosas que escuchan conexiones; se está ejecutando una cantidad sorprendente de cosas en comparación con un típico netinst de Debian mínimo. En general, es una buena idea reducir la exposición solo a las cosas que necesita , por lo que primero deshabilite o apague todo el firewall , luego exponga solo los servicios que deliberadamente desea que estén visibles en Internet público (generalmente solo ssh o ssh + http).

• querrá cambiar las claves de host ssh en lugar de usar las de la imagen (AIUI la última imagen realmente las regenera en el primer arranque)

Hay muchas formas de abordar las vulnerabilidades, sin embargo, lo primero que debe saber es que Linux no es tan susceptible a la intrusión como otros sistemas operativos. Esto se debe principalmente a la falta de malware que se dirige a * NIX. Sin embargo, desea conocer las formas en que se puede acceder a su sistema.

Contraseñas

En primer lugar, debe cambiar las contraseñas predeterminadas para cualquier usuario que pueda iniciar sesión. Para Debian, este es solo el usuario predeterminado Pi . Para Arch Linux, esta es la raíz de superusuario . Las contraseñas se cambian al iniciar sesión como usuario escribiendo passwden la línea de comando.

Se recomienda una política de contraseña segura, ya que sería bastante simple ejecutar ataques de diccionario de fuerza bruta en su usuario predeterminado. Elija una contraseña decente, de longitud media.

Oscuridad

El acceso remoto es probablemente el agujero de seguridad más importante. Lo que podemos usar aquí se llama seguridad por oscuridad . Un método común de ataque es escanear un rango de direcciones IP para puertos abiertos. Entonces, una de las contramedidas más simples que podemos tomar es ser un usuario que no utiliza los puertos predeterminados .

Todo lo que debe hacerse aquí es cambiar los puertos predeterminados para los protocolos de uso común. Por ejemplo, el puerto SSH predeterminado es 22 y FTP es 21. En mi sistema, SSH usa 222 y FTP 221, lo que debería ocultar estos protocolos de cualquier ataque automatizado.

Seguridad de conexión

En primer lugar, la preocupación de seguridad más importante es que la cuenta raíz no debería poder iniciar sesión a través de SSH. Puede deshabilitar el inicio de sesión raíz en el /etc/ssh/sshd_configarchivo comentando o eliminando esta línea:

PermitRootLogin yes

Debe establecerse en no de forma predeterminada, pero es mejor asegurarse.

Si usa mucho SSH y le preocupan los ataques de hombre en el medio, los ataques de diccionario contra su contraseña, puede usarlos SSH Keys.

La autenticación basada en clave tiene varias ventajas sobre la autenticación de contraseña, por ejemplo, los valores clave son significativamente más difíciles de aplicar por fuerza bruta que las contraseñas simples.

Para configurar la autenticación de clave SSH, primero debe crear el par de claves. Esto se hace más fácilmente en su máquina cliente (la máquina con la que desea acceder al Pi).

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pi/.ssh/id_rsa):

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/pi/.ssh/id_rsa.
Your public key has been saved in /home/pi/.ssh/id_rsa.pub.

Como puede ver, esto ha creado dos archivos, la clave privada id_rsay la clave pública id_rsa.pub.

La clave privada solo la conoce usted y debe protegerse de forma segura . Por el contrario, la clave pública se puede compartir libremente con cualquier servidor SSH al que le gustaría conectarse.

Entonces, lo que nos gustaría hacer es copiar la clave pública en la Raspberry Pi. Podemos hacer esto muy fácilmente:

ssh-copy-id pi@address

¿Dónde piestá el nombre de usuario de Raspberry Pi y addresses la dirección IP de Pi?

Reitero, distribuimos la clave pública . La clave privada es tuya. Agárrelo con fuerza, para liberar esa tecla se rompe la seguridad del sistema.

El wiki de Arch tiene una excelente descripción de cómo funciona esto:

Cuando un servidor SSH tiene su clave pública en el archivo y ve que solicita una conexión, utiliza su clave pública para construir y enviarle un desafío. Este desafío es como un mensaje codificado y debe cumplirse con la respuesta adecuada antes de que el servidor le otorgue acceso. Lo que hace que este mensaje codificado sea particularmente seguro es que solo puede ser entendido por alguien con la clave privada. Si bien la clave pública se puede usar para cifrar el mensaje, no se puede usar para descifrar ese mismo mensaje. Solo usted, el titular de la clave privada, podrá comprender correctamente el desafío y producir la respuesta correcta.

Para obtener más información sobre la seguridad de la autenticación de clave pública, Wikipedia tiene una explicación detallada .

Con la seguridad SSH en su lugar, puede realizar una gran cantidad de transferencias de datos cifradas y seguras. Prácticamente cualquier otra conexión de puerto puede enrutarse a través de SSH si es necesario. Incluso puede reenviar la sesión X a través de SSH para que aparezca en otra máquina.

Como un ejemplo interesante, ayer estaba ejecutando Eclipse en mi escritorio, viéndolo en mi Raspberry Pi y controlando el mouse y el teclado desde mi Netbook. Tal es el poder de SSH.

Permisos

Los permisos de archivo son el quid del sistema de seguridad de Linux. Afectan quién puede ver sus archivos y carpetas, y puede ser muy importante para proteger sus datos. Por ejemplo, inicie sesión en Raspberry Pi como usuario normal y ejecute:

cat /etc/shadow

El shadowarchivo contiene contraseñas cifradas para los usuarios del sistema, por lo que no querríamos que cualquiera lo revise. Entonces deberías ver esta respuesta:

cat: /etc/shadow: Permission denied

Podemos ver por qué esto es echando un vistazo a los permisos del archivo:

ls -l /etc/shadow
-rw------- 1 root root 821 Jun 11 22:13 /etc/shadow

Esto nos dice que el archivo es propiedad de root y que solo el propietario tiene permisos de lectura / escritura. Analicemos esa salida.

-rw-------

Este es el estado de los permisos. El primer bit nos dice el tipo de archivo ( -significa archivo normal). Los siguientes tres bits representan las acciones disponibles para el propietario del archivo. Los segundos tres bits representan el grupo , y los tres últimos son para otros o para todos los demás. Por lo tanto, un directorio con permisos completos se vería así:

drwxrwxrwx  10 root root   280 Jun 20 11:40 tmp/

Eso es leer, escribir y ejecutar permisos para el propietario, el grupo y todos los demás.

La siguiente parte importante son los dos nombres. En nuestro caso root root. El primer usuario es el propietario del archivo. El segundo es el grupo de usuarios . Por ejemplo, sería común ver:

drwxr-xr-x  10 pi users   280 Jun 20 11:40 home/pi

Esto permitiría el acceso de lectura / escritura para el usuario pien su directorio personal y el acceso de lectura para todos los demás usuarios.

Los permisos se refieren y controlan con mayor frecuencia utilizando valores octales. Por ejemplo, si queremos establecer rw solo para el propietario, escribiríamos:

chmod 600 /path/to/file

Esta es una descripción básica, para obtener más detalles sobre los permisos de archivos de Linux, aquí hay un buen artículo.

Esta comprensión es importante al proteger archivos y carpetas. Por ejemplo, supongamos que acabamos de configurar las claves SSH. Definitivamente no queremos que otros usuarios vean dentro de nuestro ~/.sshdirectorio, o podrían tomar nuestra clave privada. Así eliminamos sus privilegios de lectura:

chmod 700 ~/.ssh
ls -la ~/.ssh 
drwx------   2 james users  4096 Jun 18 03:05 .

Espero que esto aclare algunas de sus preocupaciones con la seguridad de Linux. A partir de esto, debería poder ver que es un sistema bastante seguro y, si tiene cuidado, no debería tener problemas de seguridad.

Para evitar ataques de fuerza bruta, puede instalar y configurar fail2ban. Analizará los archivos de registro (como /var/log/auth.log) e intentará detectar si varios intentos de inicio de sesión han fallado. Luego, prohibirá automáticamente las direcciones IP de origen con iptables.

Hay un montón de howtos en Internet.