Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.

Temas - Adastra

Páginas: [1]
1

Tomado de: http://thehackerway.com
Publicación original: http://thehackerway.com/2012/07/19/web-hacking-medidas-de-seguridad-en-servidores-web-apache-configurando-openssl-y-php-en-apache-parte-vi/

Cuando se instala un servidor Apache que se expondrá en entornos no seguros como internet, implementar medidas de seguridad básicas como el cifrado de las comunicaciones es una actividad que es altamente recomendable. En esta publicación se hablará de como utilizar Apache con soporte a SSL.

En primer lugar, se explicará como habilitar el soporte de SSL en el servidor web, por lo tanto es necesario instalarlo como se ha indicado en la publicación anterior a esta, los pasos son simples y se pueden resumir así:

Instalar el servidor web
Instalar OpenSSL
Generar un certificado para el servidor utilizando OpenSSL.
Habilitar el soporte que tiene Apache para SSL
Establecer las directivas para SSL en el fichero de configuración del servidor.

Para instalar OpenSSL, se puede descargar el código fuente e instalar desde él o bien, ejecutar el comando apt-get install openssl ssl-cert en este caso concreto se explicará como realizar la instalación desde código fuente.

Uso de OpenSSL para generación de Certificados digitales.
Instalando OpenSSL

En primer lugar, OpenSSL es un Toolkit open source muy robusto que implementa protocolos como SSL v2/v3 y TLS v1 además puede ser utilizada como una potente librería para realizar operaciones criptográficas de propósito general.
Para instalar este toolkit en sistemas basados en Unix es necesario tener cumplidas algunas dependencias entre las que se destacan:

Código: [Seleccionar]
Make.
GCC
Perl 5 o superior.

Ahora bien, para instalar OpenSSL es necesario descargarlo desde aquí: http://www.openssl.org/source/ (elegir la ultima versión estable) y posteriormente proceder a ejecutar el script config. Existen algunas opciones en este script que pueden ser útiles en casos puntuales, entre las que se incluyen algunas tales como excluir determinados tipos de cifrados como SHA, DSA, MD5, RC2,RC3,RC4 etc. Construir el toolkit con o sin soporte a aplicaciones multi-threading, soporte para la compresión y decompresión con zlib, etc. Para entender con mayor detalle todas estas opciones se recomienda leer el fichero INSTALL que viene incluido en el paquete descargado. El comando con las opciones que se utilizarán en este caso es el siguiente.

Código: [Seleccionar]
./config --prefix=/opt/openssl --openssldir=/opt/openssl
Una vez ejecutado el comando anterior, se procede a construir e instalar con make y make install respectivamente. Con esto es suficiente para tener instalado OpenSSL.
Ahora que se tiene OpenSSL instalado, es el momento de crear un certificado auto-firmado en el servidor web. Aquí es importante señalar que un certificado de este estilo no es confiable en un entorno como internet y la mayoría de navegadores modernos enseñarán un mensaje de alerta indicando al usuario que el certificado expuesto por el servidor no se encuentra soportado por ninguna entidad certificadora de confianza (CA) con lo cual cabe la posibilidad que se trate de un ataque MITM sobre SSL tal y como se ha explicado anteriormente este blog (ver aquí: http://thehackerway.com/2012/04/04/wireless-hacking-evil-twin-y-ataques-mitm-sobre-ssl-parte-vi/)

Ahora, para crear un certificado auto-firmado puede ejecutarse el siguiente comando:

Código: [Seleccionar]
>./openssl req -new -x509 -days 365 -sha1 -newkey rsa:2048 -nodes -keyout /opt/WebServerApacheFull/httpd-2.2.22/webserver.key -out /opt/WebServerApacheFull/httpd-2.2.22/webserver.crt -subj ‘/O=Compania de Servidor web seguro/OU=Departamento de Sistemas/CN=www.server-test.com’
Generating a 2048 bit RSA private key
…………………………………………………………………………………………….+++

………………………………………..+++

writing new private key to ‘/opt/WebServerApacheFull/httpd-2.4.2/webserver.key’

—–

Con esto será suficiente para crear el certificado auto-firmado y su correspondiente clave privada. No obstante como se ha mencionado anteriormente, el problema que tienen este tipo de certificados es que navegador que se conecte al sitio no reconocerá una entidad certificadora e interrumpirá la conexión esperando que el usuario confirme una excepción de seguridad para el sitio web una vez verifiqué el certificado emitido por el servidor. Obviamente no es una situación cómoda ni óptima, por ese motivo, cualquier servidor web que tenga un certificado digital para sus clientes, debe de ir acompañado por un certificado externo de una CA de confianza. Sin embargo, para un entorno de pruebas como este, no se hace necesario (aunque se verá más adelante).

El comando ejecutado anteriormente, tiene una serie de opciones que son aceptadas por openssl, sin embargo entender por que y para que se han incluido es importante, por este motivo se explica su funcionamiento y como ha afectado a la generación final del certificado y la clave privada.

req Se trata de uno de los comandos incluidos en OpenSSL que permite crear un certificado X.509 (Certificate Signing Request) CSR.

-new Opción para solicitar la creación de un nuevo certificado digital

-x509 El nuevo certificado generado será un certificado siguiendo el estándar X.509, sin embargo esta opción no solamente sirve para esto, también indica a OpenSSL que un nuevo certificado debe de ser generado, en el caso de que no se incluya esta opción solamente se generará una petición de certificado (CRS)

-days Número de días de vigencia del certificado antes de que este caduque, en este caso concreto tiene una vigencia de 1 año.

-sha1 Indica que el cifrado utilizado será SHA1

-newkey rsa:2048 Genera una clave privada nueva con RSA de 2048 bits

-nodes Indica que no se solicitará passphrase para el certificado.

-keyout Directorio de salida de la clave privada.

-out Directorio de salida para el certificado.

-subj
Datos sobre el certificado que se esta generando, en el caso de que esta opción no se indique, toda esta información es solicitada por OpenSSL de forma interactiva.

Ahora que se ha creado un certificado auto-firmado, este puede ser incluido en Apache, para ello es necesario incluir el modulo de SSL para Apache y activar algunas directivas adicionales, sin embargo antes de hacer esto, resulta conveniente explicar como hacer el proceso anterior pero utilizando una CA valida, por ejemplo Versign, por que razón? Porque en un entorno serio, no deberían lanzarse advertencias de seguridad al usuario final obligándole a aceptar excepciones, ese es un escenario perfecto para aplicar un ataque MITM con cierta facilidad, por este motivo existen los certificados digitales firmados por entidades certificadoras que garantizan que el sitio es seguro. Para esto se siguen los siguientes pasos:

Generar la petición de certificado que deberá enviarse a la CA:

Código: [Seleccionar]
>openssl req -new -sha1 -newkey rsa:2048 -nodes -keyout /opt/WebServerApacheFull/httpd-2.2.22/webserver.key -out /opt/WebServerApacheFull/httpd-2.2.22/www.server-test.com.csr -subj ‘/O=Compania de Servidor web seguro/OU=Departamento de Sistemas/CN=www.server-test.com’
Como puede apreciarse, el comando anterior no es muy diferente del que se ha ejecutado unas lineas arriba, prácticamente la única diferencia es el uso de la opción -x509, que en este caso esta ausente, esto es principalmente para generar una petición de certificado (sin generar uno) dicha petición se almacenará en el directorio /opt/WebServerApacheFull/httpd-2.2.22/ con el nombre www.server-test.com.csr que es la petición propiamente dicha. No es obligatorio que se guarde con el mismo nombre de dominio, sin embargo hacerlo así facilita las cosas a la CA a la hora de procesar la petición.

NOTA: No debe especificarse ni dirección de correo ni password para generar la CRS.

El siguiente paso es enviar la petición (el fichero www.server-test.com.csr) a la CA con el correspondiente pago. Cuando la CA responda, lo hará con un fichero con extensión PEM que posteriormente puede cambiarse su extensión por CRT para seguir con las convenciones definidas de Apache. Posteriormente es necesario verificarlo con OpenSSL de la siguiente forma:

Código: [Seleccionar]
>./openssl verify -CAfile /path/cadir/webserver_ca.crt -purpose sslserver /opt/WebServerApacheFull/httpd-2.2.22/webserver.crt/opt/WebServerApacheFull/httpd-2.4.2/webserver.crt

: OK
En este caso webserver_ca.crt es el certificado que ha devuelto la CA.

Ahora es necesario chequear que el certificado retornado por la CA corresponde con la clave privada.

Código: [Seleccionar]
>openssl x509 -noout -modulus -in /path/cadir/webserver_ca.crt | openssl sha1 399ef8a520b5154c9a63345b8285c4cd8aa921d0
>openssl rsa -noout -modulus -in /opt/WebServerApacheFull/httpd-2.2.22/webserver.key | openssl sha1

399ef8a520b5154c9a63345b8285c4cd8aa921d0
Como puede apreciarse, la salida de los dos comandos ejecutados anteriormente es idéntica, lo que significa que el certificado que ha devuelto la CA es valido y corresponde a la clave privada que se genero desde el principio, por lo tanto ahora es posible estar seguros de que se puede utilizar en el servidor web.

Configurando Apache para utilizar SSL
Apache puede ser configurado que utilice los certificados generados anteriormente con OpenSSL, se trata de una tarea sencilla que consiste simplemente de cargar el modulo SSL incluido en el Apache y utilizar las directivas disponibles para interactuar con dicho modulo.

Resulta muy sencillo, sin embargo lo más frecuente es encontrar un servidor web con Apache ejecutándose en el puerto 80 con HTTP y por el puerto 443 con HTTPS (SSL) este tipo de configuración solamente es posible conseguirla utilizando VirtualServers, tal y como se ha explicado en una publicación anterior.

Ahora bien, para habilitar SSL en Apache se pueden seguir dos caminos, utilizando la utilidad a2enmod (que se incluye cuando se instala Apache desde apt-get) o simplemente recompilando el código fuente en el caso de que se hayan seguido los pasos de instalación de la publicación anterior a esta. En el caso de utilizar a2enmod solamente es necesario ejecutar
Código: [Seleccionar]
>a2enmod sslCon esto, el modulo SSL quedará habilitado en el servidor web. Si se esta trabajando con el código fuente de Apache, es necesario recompilar utilizando la opción --enable-ssl

Código: [Seleccionar]
>./configure --prefix=/opt/WebServerApacheFull/httpd-2.2.22 --enable-ssl
Posteriormente es necesario ejecutar nuevamente el comando make && make install

NOTA1:

En el caso de utilizar Apache 2.2.22 la forma de habilitar SSL en Apache es un poco diferente, ya que se carga directamente utilizando LoadModule en el fichero de configuración del servidor de la siguiente forma:
Código: [Seleccionar]
LoadModule ssl_module modules/mod_ssl.so
No obstante, la configuración de SSL en dicho servidor, a la fecha de escribir este articulo tiene problemas y aunque el servidor arranca correctamente, no permite a ningún cliente acceder al servicio arrojando un error HTTP 500 y registrando el siguiente mensaje de error en el fichero de logs.

Código: [Seleccionar]
[Thu Jun 28 23:02:59.587759 2012] [core:error] [pid 8368:tid 139637927126784] [client 127.0.1.1:37573] AH00027: Buggy authn provider failed to set user for /favicon.ico
Este error se encuentra reportado y próximamente sin duda existirá alguna solución para este problema tal y como se indica aquí: http://wiki.apache.org/httpd/ListOfErrors por esta razón se recomienda utilizar la versión 2.2.22

Ahora que el servidor tiene SSL habilitado, se puede comenzar a configurar los VirtualHosts, el siguiente fichero de configuración puede ser valido para explicar como crear un host virtual que escuchará en el puerto 82 para peticiones HTTP regulares y otro host virtual en el puerto 444 para peticiones HTTPS utilizando SSL.

Código: [Seleccionar]
ServerName Galileo:82Listen 82
Listen 444

User adastra

Group adastra

ServerAdmin [email protected]

<IfModule mpm_worker_module>

StartServers 2

MaxClients 150

MinSpareThreads 25

MaxSpareThreads 75

ThreadsPerChild 25

MaxRequestsPerChild 100

</IfModule>

ErrorLog “logs/error_log”

LogLevel warn

<VirtualHost *:444>

DocumentRoot “/opt/WebServerApacheFull/httpd-2.2.22/htdocs/webssl”

SSLEngine on

<Directory /opt/WebServerApacheFull/httpd-2.2.22/htdocs/webssl>

Options Indexes FollowSymLinks

SSLRequireSSL

</Directory>

SSLCertificateFile /opt/WebServerApacheFull/httpd-2.2.22/webserver.crt

SSLCertificateKeyFile /opt/WebServerApacheFull/httpd-2.2.22/webserver.key

<IfModule mime_module>

AddType application/x-x509-ca-cert .crt

AddType application/x-pkcs7-crl .crl

</IfModule>

</VirtualHost>

<VirtualHost *:82>

DocumentRoot “/opt/WebServerApacheFull/httpd-2.2.22//htdocs/app”

<Directory /opt/WebServerApacheFull/httpd-2.2.22/htdocs/app>

Options Indexes FollowSymLinks

</Directory>

</VirtualHost>

NOTA: Nótese que se ha incluido la directiva Listen para el puerto 444 y 82, esto es obligatorio para que funcionen adecuadamente los dos host virtuales definidos posteriormente.

Ejecutando Apache con el fichero de configuración anterior, dará como resultado, que el servidor web creará dos hosts virtuales, uno para HTTP en el puerto 82 y otro para HTTPS en el puerto 444. Cuando el cliente intenté acceder a http://galileo:82 será atendido por algún fichero de bienvenida como index.* o default.* en el directorio /opt/WebServerApacheFull/httpd-2.2.22//htdocs/app

Si el usuario intenta acceder a https://galileo:444 comenzará una conexión segura con el servidor web y será atendido por algún fichero de bienvenida como index.* o default.* en el directorio /opt/WebServerApacheFull/httpd-2.2.22//htdocs/webssl

De momento, se trata de una configuración muy simple, pero que permite comprender el concepto de host virtuales seguros y no seguros utilizando algunas directivas del modulo SSL disponible en Apache. Las directivas que merece la pena mencionar del fichero de configuración anterior son las siguientes:

SSLEngine on Esta directiva permite activar el soporte de SSL para el host virtual que se encuentra en ejecución en el puerto 444

SSLRequireSSL Esta directiva, que se ha ubicado al interior de la directiva Directory, indica que el recurso en cuestión debe ser asegurado usando SSL en cada petición.

SSLCertificateFile /opt/WebServerApacheFull/httpd-2.2.22/webserver.crt Simplemente se indica la ubicación donde se encuentra el certificado del servidor web

SSLCertificateKeyFile /opt/WebServerApacheFull/httpd-2.2.22/webserver.key Simplemente se indica la ubicación donde se encuentra la clave privada correspondiente al certificado del servidor web

Aunque en el modulo SSL existen muchísimas más opciones de configuración, con estas será suficiente para comenzar a trabajar con SSL

Configurando Apache para ejecutar PHP
Probablemente una de las razones por las que PHP ha sido un lenguaje de programación web tan popular se deba a que se encuentra plenamente soportado en prácticamente todas las versiones del servidor web de Apache, sin embargo esta no es la única razón. Se trata de un lenguaje fácil de manejar, con una gran cantidad de librerías para realizar casi cualquier cosa y sobre todo: Se trata de una herramienta Open Source (esa sin lugar a dudas es otra de las razones por las que es tan popular). Aunque como en todos los lenguajes de programación y prácticamente cualquier herramienta informática que se ha escrito hasta el momento, siempre han existido detractores y benefactores, no se debe subestimar (y obviamente tampoco sobrestimar) el poder de PHP, la mejor forma de tomar una posición, es simplemente probandolo.

Ahora, sin más preámbulos, se explica como instalar PHP en el servidor web que se ha instalado y configurado en esta publicación y en la anterior. En primer lugar es necesario descargar PHP desde su sitio oficial aquí:http://php.net/downloads.php descomprimir el fichero y ejecutar el script configure de la siguiente forma:

Código: [Seleccionar]
>./configure --with-apxs2=/opt/WebServerApacheFull/httpd-2.2.22/bin/apxs --prefix=/opt/WebServerApacheFull/php-5.4.4 --with-openssl-dir=/opt/WebServerApacheFull/openssl --enable-zip --with-curl --with-mysql
Ahora se procede a ejecutar el comando make y make install.

Después de ejecutar el comando anterior automáticamente genera el modulo libphp5.so en el directorio de módulos de Apache, que en este caso se encuentra en el directorio /opt/WebServerApacheFull/httpd-2.2.22/modules ya que al utilizar la opción –with-apx2 se ha indicado la ruta de instalación del servidor web.

Ahora es necesario editar el fichero de configuración de Apache y agregar las siguientes directivas

Código: [Seleccionar]
LoadModule php5_module modules/libphp5.so
<FilesMatch \.php$>
SetHandler application/x-httpd-php

</FilesMatch>
Estas sencillas lineas, simplemente indican que se cargue el modulo php5_module que se ha generado anteriormente de forma automática cuando se inicio el proceso de instalación de PHP. La siguiente directiva indica que todas las peticiones a recursos que terminen con “.php” deberán de ser tratadas por el handler de PHP, que en este caso es application/x-httpd-php de esta forma, el fichero será ejecutado como código PHP.

Para comprobar esta configuración, basta con incluir un fragmento de código en PHP en un fichero con extensión *.php por ejemplo:

Código: [Seleccionar]
<?php phpinfo();phpinfo(INFO_MODULES);
?>

Si todo ha quedado correctamente instalado, con las lineas de código anteriores, se enseñará en el navegador información sobre la versión de PHP y las opciones incluidas en el proceso de compilación e instalación así como también los módulos que se encuentran habilitados, variables de configuración del servidor web, entre otros muchísimos y valiosos detalles de configuración.

En próximas publicaciones se hablará aun más sobre configuraciones y seguridad en servidores web Apache.

2



Medidas de Seguridad y "Hardening" en servidores SSH


Seguramente muchos de vosotros conocéis y controláis el protocolo SSH y seguramente, una de vuestras implementaciones preferidas es OpenSSH, sin embargo, en muchas ocasiones olvidamos o desconocemos que se trata de una herramienta que si bien puede facilitar muchísimo las tareas de un administrador de sistemas, también puede ser una herramienta que en las manos de un hacker, puede llevar no solo a comprometer una máquina, sino también todo el segmento de red. Tener plena conciencia de este hecho, es el primer paso para evitar este tipo de problemas, por este motivo es importante conocer las medidas de seguridad que se deben implementar en un servidor SSH, principalmente cuando este se expone a entornos tan "agresivos" como Internet.

Medidas de seguridad en SSH
Para fortalecer la seguridad de un servicio SSH, existen ciertas medidas que deben implementarse con el fin de evitar (o al menos dificultar) ataques contra la infraestructura del tipo MITM entre otros, algunas de estas medidas se indican a continuación, aunque pueden implementarse muchas otras en función a necesidades especificas, estas son unas medidas básicas y de una “casi” obligatoriedad.
En primer lugar, para implementar casi todas las medidas de seguridad que se mencionan a continuación, se debe conocer el fichero de configuración del servidor SSH, que normalmente se encuentra ubicado en "/etc/ssh/sshd_config". Estamos hablando, evidentemente de servidores Linux o algunas otras distribuciones basadas en Unix, sin embargo las directivas que se incluyen en este fichero, son propias del servidor SSH y funcionan igual en cualquiera de la plataformas soportadas por OpenSSH.

No permitir acceso remoto al usuario Root
No se debería permitir el acceso remoto al usuario root, normalmente debería permitirse el acceso a usuarios que tengan cuentas con privilegios limitados, la razón principal de esto, es debido a que, si el servicio SSH es vulnerable a alguna "0 day" o se implementa una mala política de contraseñas, un atacante puede ganar acceso al servidor y del mismo modo que ocurre con otros servicios como Apache, es conveniente que se garantice solamente los privilegios mínimos al proceso. Tambien anotar, que otra muy buena alternativa es implementar una "jaula" tambien conocida como "chroot jail". Para evitar que el usuario "root" pueda acceder de forma remota, se aplica la siguiente directiva al fichero de configuración:

PermitRootLogin no

Permitir acceso remoto solamente a un listado determinado de usuarios
Siguiendo este mismo orden de ideas, también es posible habilitar solamente aquellos usuarios que utilizaran el servicio, definiendo los nombres de las cuentas que tienen permisos realizar una conexión con el servidor SSH. Del mismo modo también se puede declarar de forma explicita quienes no pueden acceder al servidor SSH aunque cuenten con credenciales de acceso validas:

AllowUsers Adastra
DenyUsers Bernardino Templar


Tiempo de gracia para establecer la conexión
Una medida de seguridad importante consiste en definir el número de segundos máximo que tardará el usuario en ingresar sus credenciales, si realmente es quien dice ser, normalmente no debería tardar mucho, para definir este “tiempo de gracia” la directiva en el fichero sshd_config es:

LoginGraceTime 30
Esto definirá un valor de 30 segundos para ingresar usuario/clave.

Paridad entre usuarios y direcciones IP permitidas
Difinir los usuarios, maquinas y cuentas que pueden conectarse al servicio SSH, es una buena medida en entornos donde se utilizan direcciones IP estaticas, donde se sabe, que un usuario determinado se conecta desde una dirección IP concreta.

AllowUsers [email protected]

Con esto, se denegará la conexión cuando no proceda de la dirección IP indicada, aunque el usuario cuente con las credenciales de acceso correctas.


Número máximo de intentos de conexión.
Definir un número bajo de intentos de autenticación, reduce el riesgo y evidentemente el éxito, de ataques por fuerza bruta.
MaxAuthTries 2
Se definen 2 intentos de autenticación máximos.

No permitir passwords vacíos.
Creo que no necesita muchas explicaciones, el titulo lo dice todo.
PermitEmptyPasswords no

Definir un número máximo de usuarios conectados a la maquina.
En ocasiones resulta interesante limitar el número de usuarios conectados a una máquina para evitar saturar el servidor, para ello esta directiva es útil
 
MaxStartups 10
Permite 10 clientes concurrentes.

Cambiar puerto por defecto.
En algunas ocasiones resulta conveniente cambiar el puerto por defecto (22) por cualquier otro para dificultar las cosas un poco a un atacante, la directiva es:

Port 3334

Cabe anotar que esta opción también es soportada en el fichero de configuración del cliente y en dicho caso, el puerto por el que se intentarán establecer todas las conexiones a servicios SSH será al puerto especificado en el fichero de configuración, a menos que se especifique de forma explicita un puerto distinto por medio de la opción “-p”
Ahora bien, como se ha indicado anteriormente, el fichero de configuración del servidor se encuentra ubicado en /etc/ssh/sshd_config y el fichero de configuración del cliente se encuentra ubicado en /etc/ssh/ssh_config sin embargo, si el cliente tiene el fichero ssh_config ubicado en el directorio ~/.ssh/config ese será el que utilice el cliente de OpenSSH.

No permitir la creación de túneles SSH
Esta medida de seguridad es importante, ya que uno de los vectores de ataque más exitosos para comprometer la red interna desde un segmento de red externo como internet, es por medio del uso de túneles SSH, con los cuales no solamente se puede acceder a máquinas inaccesibles desde el exterior, sino que también, es posible saltarse medidas de seguridad importantes como Firewalls o algún IDS. La directiva para evitar el uso de esta característica en SSH, es:

AllowTcpForwarding no

Autenticación por medio de claves publica/privada
Hasta este punto se ha venido hablando de autenticación por medio de una cuenta de usuario existente en el sistema, sin embargo OpenSSH soporta la autenticación por medio del uso de pares de claves privada/publica, el servidor SSH debe contener la clave publica, mientras que el cliente debe contener la clave privada para realizar la autenticación con el servicio. Si el procedimiento de instalación de las claves en cada uno de los puntos (cliente-servidor) se ha realizado de forma correcta, la autenticación al servicio SSH no será contra un usuario existente en el sistema donde se ejecuta el servicio, sino que será contra la contraseña que se ha empleado para la generación de las claves. Este mecanismo de autenticación es el más robusto y desde luego, el más recomendado para servidores que se encuentran expuestos en internet.
El proceso de generación de las claves publica/privada se detalla a continuación:

Debe existir el directorio .ssh en el directorio personal del usuario que ejecuta el cliente SSH, si no existe, crearlo
>mkdir -p ~/.ssh ; chmod 700 ~/.ssh ;
posteriormente es necesario crear las claves con el uso del comando ssh-keygen.

>ssh-keygen -t rsa

De este modo se crea una clave RSA utilizada para el mecanismo de autenticación.

Ahora es necesario transferir la clave al servicio ssh, para conseguir esto de forma segura se utiliza el comando ssh-copy-id Este comando creará (si no existe) el fichero authorized_keys conteniendo las claves privadas que pueden ser admitidas por el servidor, de este modo, cuando se intente ejecutar una conexión con un servidor SSH, lo primero que se intentará hacer es buscar dicho fichero en el directorio personal de usuario y si este existe, se intentará realizar la conexión utilizando dicha clave, si se intenta realizar la conexión con usuario distinto del que se ha especificado en el comando ssh-copy-id la autenticación se realizará por login y password en la maquina remota.

ssh-copy-id [email protected]
The authenticity of host ’192.168.1.33 (192.168.1.33)’ can’t be established.RSA key fingerprint is ac:ad:22:07:7c:11:b4:49:ee:3f:32:95:5b:5b:d4:99.Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘localhost’ (RSA) to the list of known [email protected]’s password:Now try logging into the machine, with “ssh ‘[email protected]′”, and check in:.ssh/authorized_keysto make sure we haven’t added extra keys that you weren’t expecting.
ssh [email protected]
Enter passphrase for key ‘/root/.ssh/id_rsa’:

Como puede apreciarse desde la maquina donde se encuentra el servicio SSH (192.168.1.33) no se ha tenido que realizar ningún tipo de acción, todo se ha ejecutado desde el lado del cliente, este se encarga de generar las claves y de importarlas al servidor, evidentemente no cualquier usuario puede realizar este tipo de acciones, solamente aquellos que tengan las credenciales de acceso correspondientes en el servidor y privilegios de root.

Consideraciones al momento de utilizar claves publica/privada
Tal como se ha indicado en párrafos anteriores, es necesario tomar ciertas medidas de seguridad con el fin de endurecer un servicio SSH, una de estas medidas sin lugar a dudas es el uso de un mecanismo de clave publica/privada que se ha indicado anteriormente, sin embargo este mecanismo por si solo no garantiza la seguridad del servicio, se deben habilitar algunas opciones adicionales en el fichero de configuración del servidor para que realmente funcione como se espera, estas son:

PasswordAuthentication no

En el caso de que se permita el acceso por clave publica y privada, cabe preguntarse ¿realmente es necesario permitir otro mecanismo de autenticación diferente? En el caso de que la opción PasswordAuthentication no sea establecida a “no” de forma explicita, será posible acceder al servidor por medio de una cuenta de usuario existente en el sistema aunque se indique al servidor SSH que el mecanismo de autenticación será por medio de clave privada, por ejemplo

ssh [email protected]
Enter passphrase for key ‘/root/.ssh/id_rsa’:
Enter passphrase for key ‘/root/.ssh/id_rsa’:
Enter passphrase for key ‘/root/.ssh/id_rsa’:
[email protected]′s password:

En el comando anterior, el servidor SSH solicita la clave privada para realizar la autenticación con el servicio, sin embargo como puede apreciarse, después de tres intentos de autenticación fallidos el servicio solicita la clave correspondiente al usuario root del sistema, en lugar de terminar la conexión de forma automática que será posiblemente lo mas adecuado.

Estas son solamente algunas medidas de seguridad que se pueden implementar en un servidor SSH para evitar que sea un objetivo fácil para un atacante, sin embargo lo más importante para intentar garantizar la seguridad de un servidor SSH, es hacer uso del sentido común y definir unas políticas de acceso  adecuadas dependiendo de las necesidades particulares de cada cual. Esto no siempre es fácil, pero dedicar tiempo a hacerlo, realmente es un trabajo que merece la pena y que puede evitar un gran dolor de cabeza a un administrador de sistemas.

3
Presentaciones / Presentación
« en: Noviembre 15, 2012, 04:27:41 pm »
Hola,
Me presento, soy Adastra y el día de hoy me he registrado en este foro con la intención de aprender de vosotros y aportar en todo lo que pueda.
Pues eso, saludos y espero que entre la colaboración de todos, podamos mejorar nuestras habilidades.

Happy Hack!

Páginas: [1]