actualidad sobre consultoria, normas y seguridad de la informacion
Guias, procesos y manuales sobre Ethical Hacking
Mostrando entradas con la etiqueta CentOS. Mostrar todas las entradas

Autenticacion web basada en certificados SSL (CentOS)


Todos creo que conocemos OpenSSL la navaja suiza del cifrado y el uso que se les da a los certificados SSL al dia de hoy para proporcionar una conexión segura HTTPS.

En este post abarcaremos el uso de estos certificados para autenticarnos en un sitio web. Crearemos un sitio web que solo sea accedido o sea visible para ciertos clientes o personas que posean el certificado llave(Publica).

Este post se ha generado para aquellos que han tenido problemas de realizar esta tarea en servidores CentOS. ;)

Escenario:

OpenSSL
Mod-SSL
Apache
CentOS 6.3

Instalación de OpenSSL
Pasaremos a instalar OpenSSL y el respectivo modulo SSL para el servidor web (APACHE) en nuestro servidor y crearemos los certificados necesario. el modulo es necesario para que apache interactué con Openssl y este viene los repositorios de Centos 6.3 y también en EPEL.


[root@localhost ~]# yum install openssl
[root@localhost ~]# yum install mod_ssl

Una vez tengamos instalado OpenSSL y el modulo SSL para apache pasaremos a crear los certificados (Privada y publica). si sera un cifrado asimetrico, ya que es conveniente para el sistema plantado.

[root@localhost ~]# openssl genrsa -des3 -out server.key 2048
Generating RSA private key, 2048 bit long modulus
............+++
...............................................+++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:

Como ven en el comando estamos solicitando que nuestra clave sea de 2048 bits, una vez ejecutado el comando antes de generar la clave privada nos solicitara ingresar una contraseña, esta es para proteger el archivo de posibles descifrado.

Ya que tenemos nuestra llave privada pasaremos a crear el certificado a firmar y llenarlo con los datos necesarios del servidor, dominio o empresa. este certificado sera el identificador de nuestro servidor, dominio o empresa.

[root@localhost ~]# openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CO
State or Province Name (full name) []:COLOMBIA
Locality Name (eg, city) [Default City]:BOGOTA
Organization Name (eg, company) [Default Company Ltd]:ANTONIOJORZ
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

El comando nos solicitara la contraseña quemada en la llave privada para acceder a el. durante el proceso de creacion se nos solicitaran los datos con los cuales se va identificar nuestro sitio web y/o servidor. como mi servidor es local y obviamente lo voy autofirmar posteriormente, lo llenare con cualquier dato. en caso que se genere en producción el campo "Common Name" debe estar quemado el dominio o subdominio del servidor.

Autofirmamos el certificado
una vez creado nuestro certificado indentificador llega el momento de firmarlo en nuestro caso como mencione anteriormente no sera un ente quien lo firme, sera autofirmado por el server esto debido que es para fines educativos en un ambiente local..

Primero creamos nuestro propio CA (Certification Authority)


[root@localhost ~]# openssl req -x509 -newkey rsa:2048 -keyout ca.key -days 730 -out ca.crt
Generating a 2048 bit RSA private key
.......................+++
.............................+++
writing new private key to 'ca.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CO
State or Province Name (full name) []:COLOMBIA
Locality Name (eg, city) [Default City]:BOGOTA
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Creamos nuestro propio certificado de autoridad de confianza con validez de dos años. Este certifica do ca.crt sera quien firme el certificado de nuestro servidor web.

Firmamos el certificado con el CA


[root@localhost ~]# openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.crt
Signature ok
subject=/C=CO/ST=COLOMBIA/L=BOGOTA/O=ANTONIOJORZ/emailAddress=frenyman@gmail.com
Getting CA Private Key
Enter pass phrase for ca.key:

Con el comando anterior estamos firmando el certificado del servidor web con nuestro CA con una validez de 1 año, este comando nos generara un certificado CRT.

Generación de certificado Cliente

Como decía al comenzar este post, lo buscado es que solo ciertas personas puedan ver nuestro sitio web y para eso crearemos este certificado cliente, como llave de acceso
El proceso es exactamente el mismo que los anteriores.


[root@localhost ~]#openssl genrsa -des3 -out client.key 2048
[root@localhost ~]#openssl req -new -key client.key -out client.csr
[root@localhost ~]#openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -in client.csr -out client.crt

Ya con esto tenemos nuestro certificado cliente.crt y sus respectiva llaves ahora debemos pasar a unir estos archivos y convertirlos en único fichero con formato PKCS#12.


[root@localhost ~]# openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12
Enter pass phrase for client.key:
Enter Export Password:
Verifying - Enter Export Password:

El comando al ejecutar solicita la contraseña para acceder a la llave cliente. y luego una contraseña para el certificado, yo la dejare nula.


Preparando Apache y ModSSL

Primero editamos el archivo de configuracion de SSL para agregar los nombres y/o path de los certificados creados.
Abrimos el archivo /etc/httpd/conf.d/ssl.conf
Buscamos
SSLCertificateFile 
SSLCertificateKeyFile 
Y editamos con los nombres de los certificados generados en nuestro caso "server"


SSLCertificateFile /etc/pki/tls/certs/server.crt
SSLCertificateKeyFile /etc/pki/tls/private/server.key

Ahora debemos indicarle ha Apache que debe solicitar dichos certificados.
Estando en el mismo fichero buscamos SSLVerifyClient y SSLVerifyDepth
descomentamos y editamos de la siguiente manera

SSLVerifyClient require
SSLVerifyDepth  1

Donde indicaremos con la primera variable que se requiere de un certificado SSL para poder ver el sitio web y con la segunda variable estamos pasando el parametro del numero de certificadoras autorizadas que firmaron nuestro certificado, en nuestro caso 1 ya que fue autofirmado y no hay mas de 1 ente intermediando.

Ahora buscamos lo siguiente SSLCACertificateFile.
descomentamos y editamos el nombre de nuestro certificado de confianza, en nuestro caso CA.crt


SSLCACertificateFile /etc/pki/tls/certs/ca.crt


Guardamos y reiniciamos Apache.

[root@localhost ~]# service httpd restart
Stopping httpd:                                            [FAILED]
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain for ServerName
Apache/2.2.15 mod_ssl/2.2.15 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.

Server localhost.localdomain:443 (RSA)
Enter pass phrase:

OK: Pass Phrase Dialog successful.
                                                           [  OK  ]

Apache nos solicitara la contraseña quemada en la llave privada del servidor.

Si requieren que no se las solicite cada vez que reinicien deben decifrar con openssl la llave con la misma contraseña quemada. claro esta que esto se considera un riesgo de seguridad.

Una vez reiniciado el servicio de Apache. ingresamos al navegador y digitamos la ip del servidor bajo el protocolo HTTPS.



al intentar ver la web veremos que no es visible y requeriremos del certificado de autenticacion cliente "cliente.p12" el que fue anteriormente empaquetado.

Si nos encontramos en sistemas windows simplemente hacemos doble clic en el archivo cliente.p12 y siga los pasos de importación. este importara y aplicara (Funcional para navegadores chrome e IE)

para navegadores basados en firefox se debe agregar independientemente. Para importarlo simplemente nos vamos a:
Menu-->Opciones-->Avanzado-->Certificados-->Ver Certificados -->Sus Certificados

una vez importado el certificado actualizamos navegador este nos solicitara selecionar un certificado como autenticacion.

Una vez selecionado el Certificado de autenticacion este nos permitira ver nuestra web.





Saludos.

Post basado en la fuente y reformado para CentOS.
Fuente


Read more

Instalación del modSecurity en apache (CentOS)




modSecurity™ es un firewall de aplicaciones Web embebible que se ejecuta como módulo del servidor web Apache, provee protección contra diversos ataques hacia aplicaciones Web y permite monitorizar tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente.1

modSecurity™ para Apache es un producto desarrollado por Breach Security. modSecurity™ está disponible como Software Libre bajo la licencia GNU General Public License, a su vez, se encuentra disponible bajo diversas licencias comerciales.

modSecurity™ filtra ataques por XSS, SQL Injection, comportamientos anómalos en protocolos, robots, troyanos, LFI … incorporando además reglas específicas para algunos de los gestores de contenido o CMS más populares como Joomla o WordPress.
Soporta integración con ModProxy por lo que podemos proteger aplicaciones desplegadas en otros servidores gracias a esta integración.
Además modSecurity™ cuenta con una consola de administración que permite recopilar registros de motorización y alertas en tiempo real así como de opciones automatizadas de mantenimiento, entre otras características


Instalación de modSecurity 

Las descargas necesarias podemos realizar desde la web oficial del proyecto http://www.modsecurity.org/

Lo primero que hacemos es descargarlo cambien la X por la versión Actual en nuestro caso descargaremos la version 2.5.13:
$ wget http://www.modsecurity.org/download/modsecurity-apache_X.X.X.tar.gz
Descomprimimos y nos ubicamos en la carpeta apache2 (para versiones 2 de Apache):
$ tar -xzvf modsecurity-apache_2.5.13.tar.gz 
$cd modsecurity-apache_2.5.13/apache2
Compilamos, en este caso la configuración me ha obligado a especificar la ruta tanto de apxs como de apr-config y apu-config:
A la hora de instalar mod_security en sistemas de 64 bits podemos encontrarnos con problemas al intentar hacerlo a través de apxs. Por ello, tenemos que recurrimos a la instalación mediante compilación.
# ./configure --with-apxs=/usr/local/apache/bin/apxs \
 --with-apr=/usr/local/apache/bin/apr-1-config \
 --with-apu=/usr/local/apache/bin/apu-1-config
Si no recibimos ningún error compilamos:
# make
E instalamos:
# make install
Llega el momento de añadir a httpd.conf la carga de los módulos necesarios y la llamada al fichero de configuración:
LoadFile /usr/lib/libxml2.so
LoadModule security2_module modules/mod_security2.so
Y la llamada al fichero de configuración que podéis llamar como queráis:
Include conf/modsec2.conf
Ya quedará únicamente crear o copiar el fichero modsec2.conf y copiar las reglas que queramos a la ruta deseada.
modsec2.conf:

SecRuleEngine On
SecFilterCheckURLEncoding On
SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/modsec_audit.log
SecDebugLog logs/modsec_debug_log
SecDebugLogLevel 0
SecDefaultAction "phase:2,deny,log,status:403"
#Redireccion a html de seguridad
ErrorDocument 403 http://rm-rf.es/fallo_seguyridad.html
SecRule REMOTE_ADDR "^127.0.0.1$" nolog,allow
#Includes de configuracion
Include "/usr/local/apache/conf/modsecurity_rules/*.conf"
Finalmente comprobamos que la sintaxis de los ficheros de configuración es correcta y ya podemos arrancar Apache y hacer pruebas con mod_security:
# /etc/init.d/httpd configtest
Syntax OK





Read more

Instalación de metasploit (Linux-Windows)


Hola Gente hoy veremos como instalar Metasploit Framework individualmente de un distro contenedora como son Kali, Backtrack, Etc...

INSTALACIÓN METASPLOIT LINUX (CENTOS 64BITS)

Primero que todo descargamos nuestra versión de Metasploit desde la web oficial para nuestro linux en este caso una distro CntOS 6.3 de 64 bits.

En la web encontraremos lo siguiente selecionamos y descargamos.


[antony@localhost ~]$wget http://downloads.metasploit.com/data/releases/metasploit-latest-linux-x64-installer.run

Una vez descargado otorgamos permisos de ejecución al archivo.


[antony@localhost ~]$chmod +x metasploit-latest-linux-x64-installer.run

Ejecutamos para iniciar la instalación.


[antony@localhost ~]$sudo ./metasploit-latest-linux-x64-installer.run

A continuación se inicia el wizard de instalación.




Hacemos clic en Forward y continuamos con la instalación.




Seleccionamos la ruta de instalación yo optare por la recomendada o default.

Ahora podemos seleccionar si queremos registrar Metasploit como un servicio. De esta manera automáticamente se inicia cada vez que se enciende la máquina.

Nos pide deshabilitar antivirus y firewall para evitar conflictos.


En la siguiente ventana nos pedira seleccionar el puerto SSL de conexion por default es el 3790.

en la siguiente ventana nos pedira generar el certificado SSL y su caducidad. selecionamos que si y en mi caso dejo todo x defecto.
A continuación Metasploit Comenzara a instalarse.


Una vez finalizada la instalación nos pedira acceder a la interfaz web de Metasploit.

En esta nos encontramos con un formulario web en la cual podremos solicitar una licencia de uso a la comunidad. recordemos que metasploit tiene una version pro paga. esta es completamente gratuita soportada por la comunidad de Metasploit.
LLenamos el formulario enviamos y recibimos nuestra licencia





INSTALACIÓN DE METASPLOIT EN WINDOWS 64BITS

Aca tratare de no enfatizar mucho ya que la instalación es similar a la de linux  nos toparemos con las mismas ventanas que lo explicado anteriormente algo común para los amantes windows ;)

En el sitio de descarga mencionado anteriormente descargamos la version para sistemas windows con arquitectura de 64bits

Al igual que en los sistemas linux debemos tener desactivado cualquier AV o Firewall que se encuentre activo. y seguimos los pasos al igual que sistemas basado en unix.




Al igual que en linux entraremos a la interfaz web:
el cual igualmente nos llevara al mismo formulario en la url: localhost:3790/users/new





Read more

Hardening CMS Joomla (CentOS) #Parte2

Continuando con la plantilla de aseguramiento de CMS Joomla
Leer la #Parte1

6.6 Robots

Generalmente, una vez que se implementa un sitio web y se pone en producción, el siguiente paso es la promoción. Ésta generalmente se realiza añadiendo el dominio en los buscadores más populares y aplicando ciertas técnicas (SEO y SEM) para hacer que nuestra página sea mostrada en los primeros puestos de las búsquedas. Para facilitar el rastreo e indexación por los crawlers (arañas o robots de los motores de búsqueda) se debe configurar adecuadamente el archivo robots.txt. A través de este fichero, mediante una serie de directivas, le indicaremos al crawler qué páginas puede indexar el buscador y cuáles no. Por lo general no nos interesa que el buscador añada las páginas de administración, configuración, etc. La última versión de Joomla por defecto genera en la carpeta raíz del sitio web un archivo robots.txt:


Que tiene la siguiente configuración:

   1: Disallow: /administrator/
   2: Disallow: /cache/
   3: Disallow: /cli/
   4: Disallow: /components/
   5: Disallow: /images/
   6: Disallow: /includes/
   7: Disallow: /installation/
   8: Disallow: /language/
   9: Disallow: /libraries/
  10: Disallow: /logs/
  11: Disallow: /media/
  12: Disallow: /modules/
  13: Disallow: /plugins/
  14: Disallow: /templates/
  15: Disallow: /tmp/

Inicialmente es una configuración válida siempre que se cumplan nuestras necesidades. Si queremos añadir un nuevo directorio o ruta a proteger contra la indexación de los buscadores, la incluiremos en la lista.

7 Eliminar Meta Generator de Joomla

Joomla por defecto genera en el código fuente de las web una etiqueta como la siguiente:

< meta name="generator" content="Joomla! - Open Source Content Management" / >

Esto revela la plataforma bajo la cual se encuentra desarrollada la web.

Para esto vamos a modificar el contenido a mostrar, el siguiente ejemplo está basado en Joomla 3.0.X.
Nos dirigimos al archivo “index.php” de la plantilla instalada y usada en el gestor Joomla
Ejemplo:

“/var/www/html/masa/templates/xxx_xxx”

En el buscaremos e insertamos el siguiente código

   1: // Ocultar Generator Tag
   2: $this->setGenerator(null);

8 URL'S Amigables

El usar URL amigables es una gran ayuda para el aseguramiento de Joomla ya que si se deja la opción que trae por defecto el gestor de contenido Joomla genera códigos arbitrarios que pueden llegar a presentar una vulnerabilidad.

Para esto en primer lugar cambiaremos las opciones  por defecto en la  configuración global de Joomla.



Para que surga efecto deberiamos haber ya renombrado el archivo htaccess.txt  a .htaccess. y el archivo web.config.txt a web.config.

9 Respaldo de información

Como todo sistema este no es la excepción y se debe contar con respaldo de la información de la carpeta del sitio como de la base de datos del mismo para cambio de versiones entre otras acciones.
para esto existen diversos modulos y/o Plugins o bien siempre existira ftp y un script.

10 Extensiones de tercero

Uno de los aspectos más atractivos de los gestores de contenidos y por lo tanto de Joomla es que mediante extensiones, plugins o módulos es posible ampliar las funcionalidades del sitio web que se implemente sobre esta plataforma.

En algunos casos estas extensiones son una vulnerabilidad para los sitios web ya que posiblemente se traten de extensión que carecen de procesos de revisión de código y seguridad.
Las premisas esenciales para instalar este tipo de aplicaciones serían:

  • Verificar el historial de vulnerabilidades. Evidentemente lo más recomendable es utilizar aplicaciones que no se encuentren en la lista de extensiones vulnerables (para más antiguas consultar esta otra lista). En caso contrario se está asumiendo un riesgo elevado del compromiso de la seguridad de la web.
  • Comprobar si está incluída en el Directorio de Extensiones de Joomla. En este portal se realiza un primer filtrado comprobando que la aplicación cumple unos estándares mínimos (tanto de usabilidad como de seguridad).
  • Página del desarrollador y comunidad de soporte. Este es un punto a tener en cuenta ya que aportará información acerca de cuánto tiempo lleva desarrollándose y el tipo de soporte con el que cuenta (foros, etc.). Adicionalmente en las web de los desarrolladores es posible comprobar el funcionamiento a través de una Demo antes de su instalación.
  • Versión nativa. Siembre se debe verificar que la extensión esté disponible para la versión de Joomla que se ha instalado. Esto evita tener que activar el modo herencia.
Como siempre realizar un analisis de vulnerabilidades al sitio. existen muchas herramientas para realizar esta accion y algunas especialmente dirigida para este CMS como pueden ser

Entre otros.

11 Servidor web

Para una mayor seguridad de los portales web se debe implementar el aseguramiento del servidor web APACHE en un post anterior comentabamos sobre hardening sobre los servidores web apache y nginx.
En el punto 7 de la #Parte2_Hardening_CentOS podemos encontrar mayor información sobre el aseguramiento en APACHE y en el punto 8 de la #Parte3_Hardening_CentOS podemos encontrar mayor información sobre aseguramiento a NGINX.

12 Actualizaciones

Como en cualquier aplicación o software que se precie, el mantener una política de actualizaciones es esencial con el objetivo de cubrir los agujeros de seguridad que se vayan descubriendo. En el caso de Joomla se debe proceder del mismo modo previa evaluación del impacto que una actualización pueda provocar como la incompatibilidad entre complementos, plugins, plantillas, etc. No obstante se debe considerar adecuadamente estos aspectos primando sobre todas los relacionados con la seguridad.

Generalmente, los procedimientos para actualizar el CMS Joomla suelen ser sencillos y varían ligeramente en función de si se trata de actualizaciones dentro de la misma rama (por ejemplo de de la v3.0.1 a la v3.0.2), o si es un cambio de versión (de la v3.0x a la 4.0.x). Los primeros únicamente requieren la sustitución de los archivos antiguos por los de la nueva versión. En el caso de la segunda opción, en ocasiones es posible hacerlos directamente pero por lo general requieren de una instalación limpia de la versión de Joomla! que se quiere instalar y realizar una migración de datos.
En el sitio oficial http://docs.joomla.org o en el proyecto en español http://www.joomlaspanish.org/ se puede encontrar información útil acerca de cómo actualizar entre las distintas versiones del gestor de contenidos.

De igual manera en esta plantilla de aseguramiento se recomienda suscribirse a servicios de información que nos permitan estar al día en relación a la aparición de nuevas versiones de Joomla! o el descubrimiento de agujeros de seguridad, que nos permitan actualizar o corregir los problemas lo más rápido posible.



Read more

Hardening CMS Joomla (CentOS) #Parte1

Hola amigos continuando con el tema de hardening. esta vez les traigo una plantilla basica complementada por mi parte para los CMS Joomla en sistemas Linux (CentOS). basada en la guia basica de securizacion de Inteco.
http://www.inteco.es/file/WbpsPPREE7naXKiMJlkT_g


INDICE

1 Introducción
2 Prefijo de la base de datos
3 Usuario y contraseñas de administrador
4 Permiso de directorios y archivos
5 Área de administración (Back-end Administrator)
6 Htaccess y Robots.txt
6.1 Htaccess
6.2 Habilitar Htaccess
6.3 Denegar el acceso a los archivos .htaccess e impedir mostrar el contenido de directorios
6.4 Impedir el acceso no autorizado al back-end de joomla
6.5 Restringir el acceso a dominios e IP’s
6.6 Robots.txt
7 Eliminar Meta Generator de Joomla
8 URL’S Amigables
8 Respaldo de información
9 Extensiones de tercero
10 Servidor web (Apache)
11 Actualizaciones

1 Introducción

Joomla es un gestor de contenidos (CMS) orientado a la realización de páginas web, tanto a nivel público como portales de intranet, distribuido como software libre.
Joomla es una aplicación Open Source o de código abierto programada en lenguaje PHP bajo una licencia GPL y que utiliza una base de datos por default MySQL para almacenar el contenido y los parámetros de configuración del sitio.
Es importante destacar que esta herramienta al ser un software totalmente libre el código fuente es conocido y de aquí parte una parte del compromiso de asegurar los portales diseñados con joomla para evitar posibles vulnerabilidades y ataques.

2 Prefijo de la base de datos

Este es un aspecto de seguridad importante a la hora de crear la estructura de tablas ya que Joomla, hasta la versión 2.X por defecto creaba el prefijo jos_ en el nombre de las tablas por lo que un posible atacante lo tenía muy fácil para conocer el nombre de las mismas ya que el resto del nombre es común para todas las instalaciones (ejemplo: jos_users). A partir de la versión 3.X Joomla genera un prefijo aleatorio, pero es recomendable modificarlo por uno que el usuario considere y que preferiblemente, no tenga relación con el nombre del sitio.

3 Usuario y contraseñas de administrador

Joomla por defecto rellena el formulario correspondiente al Usuario del Administrador con el nombre admin.

Por razones de seguridad es altamente recomendable modificar este nombre por otro diferente. En caso de mantener el usuario admin hay que considerar que si un usuario malintencionado quisiera acceder a la zona de administración, ya conoce la mitad de la barrera existente. Si además no se crea una contraseña robusta, es relativamente fácil que por medio de un ataque de fuerza bruta se acceda a la zona de administración.

4 Permiso de directorios y archivos

Es muy importante proteger los directorios y archivos de joomla con los permisos adecuados todo el árbol de directorios y archivos que componen la estructura de Joomla. Puesto que la aplicación web se encuentra en un directorio con acceso de lectura para todo los usuarios (777), como mínimo se ha de verificar que los permisos se han establecido adecuadamente.

Teniendo en cuenta lo anterior y como medida general, para toda la estructura de carpetas (no archivos) donde está instalado Joomla serían aplicables los permisos 755 que se traducen como:
  • Los propietarios, es decir el usuario que ha facilitado el hosting al contratar el servicio, tendrán control total (lectura, escritura y ejecución) sobre las carpetas del servidor (7).
  • Los miembros del grupo tendrán permisos de lectura y ejecución (5). En el caso de alojamiento web, el grupo (Group) en el caso de un alojamiento web pertenece al propietario (Owner).
  • El resto de usuarios, los que acceder a la página web y sus servicios, tendrán permisos de lectura y ejecución (5).
Para los archivos la configuración será distinta. Hay que aplicar permisos 644 que se traducirían, siguiendo la información de la tabla, como:

  • Los propietarios tendrán permiso de lectura y escritura sobre los archivos del servidor (6).
  • Los miembros del grupo tendrán permisos de lectura (4).
  • El resto de usuarios, los que acceder a la página web y sus servicios, tendrán permisos de lectura (4).
En resumen y como recomendación, se deben aplicar los permisos:
755 para directorios o carpetas.
644 para archivos.

5 Área de administración (Back-end Administrator)

Joomla como la mayoría de gestores de contenidos, cuenta con dos partes diferentes en su sistema. Por un lado encontramos la parte pública o Front-end y por otro, la parte privada/de administración o Back-end.

La parte de administración está reservada para aquellos usuarios que gestionaran la plataforma como son los administradores o los usuarios que van a publicar contenidos o realizar tareas de mantenimiento. Joomla tiene su propio directorio en el árbol de carpetas donde se ubican todos los archivos necesarios para la presentación web, gestión, etc.

Puesto que la zona de administración debe ser considerara un punto clave a proteger con el objetivo de impedir lo máximo posible accesos no autorizados, es necesario implementar los mecanismos adecuados que aporten seguridad en este aspecto. Como se comentó en el punto de la instalación, la primera acción a tomar sería modificar el nombre de usuario administrador por defecto (admin) y utilizar una contraseña robusta.

Una segunda acción seria esconder el Back-end de administración que por defecto es www.portal.com/administrator
Para esto se recomienda hacer uso de autenticación htaccess o bien del plugin Jsecure.

veremos mas adelante el tema de asegurar el back-end por httaces y/o el plugin jsecure el punto 6.3

6 Htaccess y Robots.txt

En este punto se tratará cómo restringir el acceso a determinados directorios y archivos mediante la configuración de .htaccess y cómo evitar que los buscadores indexen archivos o rutas del sitio web que no queremos que sean visibles a través de las búsquedas como por ejemplo URLs de administración, de configuración, etc.

6.1 Htaccess
La mayoría de opciones de configuración de un servidor web dentro de un alojamiento basado en Apache están solo accesibles para el administrador del servidor en el ISP, es posible aplicar determinadas configuraciones editando el archivo .htaccess. Estas configuraciones, denominadas directivas, permiten aportar funcionalidades que variarán el comportamiento de sitio web pudiendo implementar varios archivos .htaccess sobre distintos directorios y archivos en base a las necesidades.

Cuando se finaliza la instalación de Joomla el CMS crea por defecto el archivo htaccess.txt que no tendrá efecto hasta que se modifique su nombre, de htaccess.txt a .htaccess



Inicialmente en Joomla, este archivo está configurado para facilitar la reescritura de las URL y optimizar el sitio en los motores de búsqueda para el SEO, pero a través de ciertos parámetros, será posible aplicar diferentes configuraciones que aportarán mayor seguridad al sitio web.

6.2 Habilitar Htaccess

Al tratarse de un servidor en ambiente local (No hosting) debemos realizar una modificación a la configuración del apache para la lectura de estos archivos.

Nos ubicamos a la siguiente carpeta /etc/httpd/conf y abrimos el archivo httpd.conf en ella encontraremos que las opciones AllowOverride se encontraran en None, editamos el None por All, guardamos y reiniciamos el servicio de apache.
service httpd restart

6.3 Impedir mostrar el contenido de directorios

En algunas ocasiones también interesará que la estructura de directorios de Joomla, a pesar de ser bastante conocida, no sea mostrada y ocultar así los archivos y carpetas que componen el sitio. Para ello basta con añadir al archivo .htaccess la siguiente línea:

Options All –Indexes.

6.4 Impedir el acceso no autorizado al back-end de joomla

Anteriormente mencionamos y recomendamos el restringir el acceso al back-end por httacces o por elplugins JSecure para darle un segundo factor de protección al acceso del back-end de administración además de otras funcionalidades de seguridad que proporciona el componente. 

Podemos asignar un segundo factor de protección (autenticación HTTP) mediante el archivo .htacces si no se cuenta con el componente JSecure.

Ami realmente me gusta mas el funcionamiento de segundo factor de la autenticacion HTTP y combinarla con los logs de JSecure.

En el archivo .htaccess indicaremos la configuración siguiente
   1: AuthType Basic
   2: AuthName Area de Administracion
   3: AuthUserFile /htpasswds/users.pwd
   4: require valid-user
Hay que indicar que esta configuración se debe aplicar en un archivo .htaccess en el directorio /administrator. Para que la configuración funcione correctamente adicionalmente, hay que crear un archivo de texto con los usuarios y contraseñas que podrán acceder al directorio (en el ejemplo users.pwd) y ubicarlo en un directorio, a ser posible oculto y fuera de la carpeta pública (en el ejemplo /.htpasswds). Puesto que el formato de la contraseña para apache se ha de cifrar, el archivo users.pwd que contiene el usuario y contraseña, tendría el siguiente formato:

============================================
antony:$apr1$Exo2qw2s$xG7V/Va.A9w5dMA9J6Wcm/
============================================

Para ayudarnos a generar las listas de usuarios podemos utilizar servicios como http://www.htaccesstools.com/htpasswd-generator/ que convierten la contraseña al formato adecuado o bien usando el comando htpasswd en consola.

Implementando esta medida, cuando un usuario trate de acceder a la URL portal.com/administrator, previa a la aparición del formulario de acceso a la administración del portal, se mostrará otro solicitando las credenciales del archivo users.pwd.

cuando intentemos nuevamente ingresar al back-end veremos algo similar a la imagen:

Recuerden tener la ultima version del apache por que en versiones anteriores existe un bypass para HTTP Authentication

6.5 Restringir el acceso a dominios e IP’S

Cuando nos percatamos en los logs algun ataque a nuestro sitio web lo primero que hacemos es denegar esa IP, esto cuando no contamos con un web firewall que nos automatice el trabajo.

Denegar la IP la podemos realizar mediante el archivo .httaccess  o bien con Jsecure

con JSecure simplemente nos vamos a componente-->JSecure Authentication

y dentro del menu de este seleccionamos IP y agregamos las IP q les vamos a denegar Acceso


Y por un archivo .Htaccess seria con una configuracion como la siguiente:

   1: order deny,allow
   2: deny from xxx.xxx.xxx.xxx
   3: deny from .dominio.com
   4: allow from all

para no extender el post continuamremos con la segunda parte en otro

seguir leyendo #Parte2


Read more

Hardening Sistema Linux (CentOS) #Parte3

Continuando con la plantilla de aseguramiento de Servidores con sistema CentOS
Leer las: #Parte1 #Parte2

8             Hardening de Nginx


Lo primero de asegurar en este servidor web es su versión, para eso eliminaremos información que identifique la versión de nginx lo más posible. Y así evitar buscarle vulnerabilidades a dicha versión.

Para eliminar el número de versión en la configuración especificamos la siguiente directiva en el archivo de configuración de nginx:

nginx.conf

Entre http agregamos lo siguiente:

server_tokens off;

Ejemplo:

http
{
...
server_tokens off;
...
}

Con el comando Curl –I  podemos verificar que la versión del servidor web esta oculta




Para coadyuvar a la seguridad del servidor web se deben haber configurado las siguientes opciones del archivo sysctl.conf.

• Evitar ataques smurf
• Evitar ataques SYN Flood

verificamos el archivo de configuración. con el comando /opt/server/nginx/sbin/nginx -t ó dependiendo de la ubicación de su instalación, 

ahora ademas de la versión ocultemos que usamos web server nginx al atacante, es editar el fichero src/http/ngx_http_header_filter_module.c 
y buscamos las líneas:
static char ngx_http_server_string[] = “Server: nginx” CRLF;
static char ngx_http_server_full_string[] = “Server: ” NGINX_VER CRLF;
Y las cambiamos por ejemplo por estas otras, podemos poner la cabecera que queramos yo por ejemplo simulare tener un webserver Apache.
static char ngx_http_server_string[] = “Server: Apache” CRLF;
static char ngx_http_server_full_string[] = “Server: Apache ” CRLF;
Salvamos el fichero y compilamos de nuevo

8.1             Controlar los ataques de desbordamiento de búfer

Editar nginx.conf y establecer las limitaciones de tamaño de búfer para todos los clientes
   1: ## Start: Size Limits & Buffer Overflows ##
   2: client_body_buffer_size  1K;
   3: client_header_buffer_size 1k;
   4: client_max_body_size 1k;
   5: large_client_header_buffers 2 1k;
   6: ## END: Size Limits & Buffer Overflows ##
Cuando,
client_body_buffer_size  (por defecto es 8k y 16k) La directiva especifica el tamaño del búfer de solicitud.

client_header_buffer_size  establece el tamaño headerbuffer para el encabezado de las solicitudes del cliente. Para la mayoría de las solicitudes un tamaño de búfer de 1K es suficiente. Se puede aumentar este valor si se tiene un header o una cookie grande enviado por el cliente (por ejemplo, el cliente de wap).

client_max_body_size  asigna el tamaño corporal máximo aceptado la petición del cliente, indica la línea Content-Length en el encabezado de la solicitud.

large_client_header_buffers asigna el número máximo y el tamaño de los búferes de header’s grandes, para leer a partir de la petición del cliente. Por defecto, el tamaño de una memoria intermedia es igual al tamaño de la página, dependiendo de la plataforma ya sea esta 4K o 8K, si al final de la petición de conexión de trabajo convierte al estado de mantenimiento de conexión, a continuación, se liberan estos tampones. 2x1k aceptan URI datos 2kB. Esto también ayudará a combatir el mal bots y ataques de denegación de servicio.

9             Hardening SSH

Para fortalecer la seguridad de un servicio SSH, existen ciertas medidas que deben implementarse con el fin de evitar o dificultar ataques contra la infraestructura.

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".

Usar contraseñas Fuertes:
Comúnmente los primeros intentos de los atacantes es tratar de acceder para adivinar su nombre de usuario/contraseña. Típicamente un atacante escaneará el puerto 22 (el puerto por defecto por el cual ssh escucha) para encontrar máquinas que estén corriendo ssh, y entonces intentarán un ataque de fuerza-bruta contra esta.

Deshabilitar el acceso como root

La configuración del servidor SSH se encuentra almacenada en el fichero /etc/ssh/sshd_config. Para deshabilitar el acceso de root, asegúrese de tener la siguiente entrada

#Prevent root logins:
PermitRootLogin no
Y reiniciar el servicio sshd:
service sshd restart o/etc/init.d/sshd restart

Si se requiere acceder como root, se debe acceder como un usuario normal y hacer uso del comando SU.

Usar un Puerto No-Estándar

Por defecto, SSH escucha las conexiones entrantes en el puerto 22. Para que un atacante determine si SSH se está ejecutando en su máquina, lo más probable es que escanee el puerto 22.
Un método efectivo es ejecutar ssh en un puerto no-estándar. Cualquier puerto sin usar funcionará, pero es preferible usar uno por encima del 1024.
Para hacer los cambios añada una línea como está a su fichero /etc/ssh/sshd_config:
# Ejecutar ssh en un puerto No-Estándar:
Port 2345 
Y reiniciamos el servicio SSH
Service sshd restart
Recuerde hacer cualquier cambio necesario a los puertos de reenvío en su enrutador y a cualquier regla aplicable al cortafuego

Filtrar SSH en el Cortafuegos

Si solamente se requiere tener acceso desde algunas direcciones IP, entonces consideremos la posibilidad de adicionar una regla en el cortafuego de su enrutador o en el de su iptables para limitar el acceso al puerto de SSH a una dirección IP específica. Por ejemplo, en iptables esto podría realizarse con la siguiente regla:
iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
En mi caso simplemente nos dirigimos al administrador de firewalls (FWbuilder) y agregamos la ip y puerto en las políticas del firewall.

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.
Editar el archivo /etc/ssh/sshd_config añadir o modificar:
MaxAuthTries 3
Se definen 3 intentos de autenticación máximos.

10       Actualización de paquetes, Kernel y Sistema Operativo

La aplicación de los parches de seguridad es una parte importante del mantenimiento de servidores Linux.
Haremos uso del gestor de paquetes de yum tratándose de distribuciones basadas en RED HAT
yum –y update

Actualización de paquetes y kernel

Mantener los paquetes y kernel actualizados es un paso que nos ayuda a mantener nuestros servidores en buen estado y con los últimos parches de seguridad.

Antes de realizar una actualización de Kernel se debe realizar un backup de la información necesaria.

• Backup / etc diretory
• Copia de seguridad de los registros importantes / var / log
• Configuraciones de servidor de copia de seguridad y sitios web
• Volcado de bases de datos
• Copia de todos lo que la empresa o el administrador necesita si algo sale mal


1. Para actualizar el kernel de distribuciones basadas en Red Hat.
Primero preparamos el sistema para la descarga y compilacion del kernel con el siguiente comando:
yum -y install gcc glibc-devel ncurses-devel rpm-build

Descargamos el kernel actual.
Ejemplo:
Cd /usr/src
Wget http://www.kernel.org/pub/linux/kernel/vX.X/linux-.X.X.tar.bz2

Descomprimimos el Kernel:
tar xjf linux-3.5.1.tar.bz2
ln -s linux-3.5.1 linux

Configuración del kernel:
cd /usr/src/linux
ls /boot/config*
cp /boot/config-2.6.32-279.el6.i686 /usr/src/linux/.config


Compilamos el Kernel.
sudo make menuconfig
make

Y por último lo instalamos
make modules_install
make binrpm-pkg

rpm -ivh /root/rpmbuild/RPMS/i386/kernel-headers-X.X.X-X.i386.rpm
rpm -ivh /root/rpmbuild/RPMS/i386/kernel-X.X.X-X.i386.rpm


Actualización de paquetes:
Para actualizar los paquetes independientemente 
yum install paquete.arch
Para actualizar todos los paquetes: puede hacer uso de 
Yum – y update
Y reinicia el servidor

Esto es todo hasta aquí espero que les sea de mucha ayuda la plantilla de aseguramiento para Servidores CentOS


Read more