Configurar Nginx para diferentes paginas en subdominios y tomcat



Crear las carpetas para almqcer las paginas web en /usr/share/nginx

Crear carpetas:

$ sudo mkdir institucional //Esta carpeta es donde queda el dominio principal www.empre.com, alli colocamos toda la información corporativa del sistema

$ sudo mkdir empre0

$ sudo mkdir empre1

$ sudo mkdir empre2

cambiar permisos a /var/share/nginx y las carpetas allí depositadas

$sudo chown -R root:root /usr/share/nginx

$ sudo adduser /usr/share/istitucional institucinal

$ sudo adduser /usr/share/empre0 empr0

$ sudo adduser /usr/share/empre1 empr1

$ sudo adduser /usr/share/empre2 empr2


$ sudo passwd institucional

$ sudo passwd empre0

$ sudo passwd empre0

$ sudo passwd empre0


crear carpetas internas dentro de empr0,empr1,empre2

si no existen , porque adduser normalmente crea la jerarquia de carpetas necesarias

/html

/css

/js

/imagenes

/.ssh * Esta carpeta y su conendo autoreize-key se usa para permitir que Sftp pueda adminstrar contenido

crear el archivo index.html en cada una de las carperas

crear el archivo empre?/.ssh/autorized_keys

ingresar la clave de acceso autorizada igual a la que asigno en el paso de asignar passwd

$ sudo emacs institucional.ssh/autrized-key

$ sudo emacs empre0/.ssh/autrized-key

$ sudo emacs empre1/.ssh/autrized-key

$ sudo emacs empre2/.ssh/autrized-key

cambiar el propietario de cada carpeta de nginx:


$ sudo -R institucional:institucional institucional

$ sudo -R empr0:empr0 empr0

$ sudo -R empr0:empr0 empr0

$ sudo -R empr0:empr0 empr0

cambiar los permisos a las carpetas dentro de Nginz

$ sudo chmod 755 /usr/share/nginx

cambiar los permisos a las archivos

de conexión Sftp

$ sudo 700 institucional.ssh

$ sudo 700 empre0/.ssh

$ sudo 700 empre1/.ssh

$ sudo 700 empre2/.ssh

cambiar los permisos de autorized_keys


$ sudo 000 institucional/.ssh/autorized_keys

$ sudo 000 empre0/.ssh/autorized_keys

$ sudo 000 empre1./ssh/autorized_keys

$ sudo 000 empre2/.ssh/autorized_keys

En su administrador de DNS , en mi caso Route 53

Crear los subdominiso de interés en este caso empre1.empr2,empre3 bajo la IP fija del dominio qaue debe exister por ejemplo www.empre.com

Supongamos 18.190.58.28

Entonces crear subsominio :

empr0.empre.com con la ip 18.190.58.28

empr1.empre.com con la ip 18.190.58.28

empr2.empre.com con la ip 18.190.58.28


Para institucional no hay que crear subdominio porque eso lo administra www.empre.com que es

el dominio principal

Asegurarse que el firewall tenga permisos de acceso para el puertos 80 y 443, como vamos a usar también tomcat mas adelante verificar los puertos 8080 y 8443 tengan acceso.

Ahora vamos a necesitar crear los certificados de seguridad para el dominio y subsominios del sistema , yo utilizo Letsencript (https://letsencrypt.org/es/) usualmente hay que instalarlo en el sitio explican detalladamente como hacerlo.

Yo voy indicar el gestión de los dominios de interés, importante tener en cuenta que para poder generar los certificados el puerto 80 debe estar disonible y no estar siendo usado por ninguna otra apliación.

$ sudo certboy only -d www.empre.com -d empre.com -d empre0.empre.com -d empre1.empre.com -d empre2.empre.com -d empre3.empre.com -d miTomcat.empre,com

Notar que no se registera institucional porque este equivale al dominio que es: www.empre.com y empre.com

El sistema hace varias preguntas las cuales se pueden contestar por defecto , la contraseña es independiente de todo lo anterior y puede añadir cualquiera de su preferencia, guardar en un lugar seguro porque Letsencript se renueva cada 90 días y puede solicitarla.

En sus sistema puede programarla con un crontab para que lo haga de forma automática.

$ sudo crontab -e

10 0 * * * certbot renew --quiet

Es importante que el certificado quede bien configurado porque los pasos siguientes requieren que queden bien establecidos de lo contrario al iniciar el servidor nginx el sistema falla porque los script usan la etiqueta ssl-certificate que buscan esta configuración por cada subdominio utilizado.

Ahora vamos a la carpeta /etc/nginx y alli encontramos las carpetas sites-avalaible y sites-enabled

sites-avalaible : creamos la configuraciones que vamos a necesitar

sites-enable : son enlaces a sites-avalaible d los sitio que vamos a expones en el servidor nginx

creamos el script para cada uno de los sitios similar a lo siguiente:

$ sudo emacs empre0.emprenex.com

---------------------------------------------------------------------------------------------------------------
server {

listen 80;

server_name empre0.empre.com;

location / {

return 301 https://$host$request_uri;

}

}

server {

listen 443 ssl;

server_name emprenex0.emprenex.com;


ssl_certificate /etc/letsencrypt/live/empre0.empre.com/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/empre0.empre.com/privkey.pem; # managed by Certbot

root /usr/share/nginx/emprenex0/html;

index index.html index.htm;

location / {

try_files $uri $uri/ =404;

}

}


Así para cada un de los sitios teniendo cuidado de asignar el valor correcto de empr# , que se corresponda con las carpetas que creo en /usr/share/nginx.

El script para la administración de la carpeta instititucional del dominio del sistem difiere un poco

y se llama www.empre.com

emacs www.empre.com

---------------------------------------------------------------------------------------------------------------
server {

listen 80;

server_name emprenex.com www.emprenex.com;

location / {

return 301 https://$host$request_uri;

}

}

server {

listen 443 ssl;

server_name emprenex.com www.emprenex.com;


ssl_certificate /etc/letsencrypt/live/www.empre.com/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/www.empre.com/privkey.pem; # managed by Certbot

root /usr/share/nginx/institucional/html;

index index.html index.htm;

location / {

try_files $uri $uri/ =404;

}


adicionalmente como tenemos el servidor tomcat activo y deseamos que Nginx lo admintre,

En nuestro administrador de DNS , Route 53 en mi caso, registro el subdominio del sitio tomcat

que deso exponer mediante Nginx

miTomcat.empre.com con la ip 18.190.58.28

De forma similar a como registeamos los otros subdominio para nginx

No necesitamos crear carpetas para esta entrada (miTomct) en nginx porque esta instalada en un contexto de Tomcat , peo si debemos crear una entrada en /etc/nginx/sites-avalaibles para que pueda ser utilizado por nginx

emacs miTomcat.empre.com
-------------------------------------------------------------------------------------------------------------------
server {

listen 80;

server_name zephyr.emprenex.com;

location / {

return 301 https://$host$request_uri;

}

}

server {

listen 443 ssl;

server_name zephyr.emprenex.com;

ssl_certificate /etc/letsencrypt/live/zephyr.emprenex.com/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/zephyr.emprenex.com/privkey.pem; # managed by Certbot

location / {

proxy_pass http://localhost:8080/miTomcat;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

}


En el caso de tomcat como la pagina ya existe en el contexto de Tomcat llamada /webapps/miTomcat no requerimios crear una carpeta en nginx ya que nginx lo accesa como un proxy_set a una url llamada

http://localhost:8080/miTomcat

Suponemos que en este caso que tomcat corre sobre el puerto:8080 , nouse el puerto 80 en su configuración de tomcat porque es el puerto por defecto de Nginx.

Observar que en este script nos referimos a empre.com y www.empre.com porque no es un subdomnio sino el dominio del sistema, pero si usa /usr/share/nginx/institucional/html; creado previamente en /usr/share/nginx/institucional.


Para habiitar los script en nginx debemos crear enlaces a los script creados de la siguiente forma

$ sudo /etc/nginx/sites/enable

sudo ln -s /etc/nginx/sites-available/www.empre.com /etc/nginx/sites-enabled/

sudo ln -s /etc/nginx/sites-available/empre0.emprenex.com /etc/nginx/sites-enabled/

sudo ln -s /etc/nginx/sites-available/empre1.emprenex.com /etc/nginx/sites-enabled/

sudo ln -s /etc/nginx/sites-available/empre2.emprenex.com /etc/nginx/sites-enabled/

sudo ln -s /etc/nginx/sites-available/miTomcat.empre.com /etc/nginx/sites-enabled/

Ahora vamos a configurar el ssh para que permita conexiones externas y poder administrar los subdominio y cargar en ellos la información de las paginas.

Ingresamos al archivo de configuración de ssh en

agregamos o modificamos las siguientes lineas: colocando a yes las lineas mostradas si es están precedidas del carácter # , retirarlo para que sean activas.

$sudo emacs /etc/ssh/sshd-config

-------------------------------------------------------------------------------------------------------------------
KexAlgorithms ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-s\

ha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Ciphers aes256-ctr,aes192-ctr,aes128-ctr

PubkeyAuthentication yes

PasswordAuthentication yes

Salvar el archivo.

En Tomcat debemos configurar el /conf/server.xml con las etiqueas connector con algo similar a los siguiente para que nginx pueda utilizarlo correctamente, observe el uso nuevamente del certificado generado en letsencript para que el sistema sea seguro ademas del proxyName : www.empre.com de acuerdo al dominio del sistema. Los parámetros adicionales son para optimizar trafico de la información y son opcionales.

emacs /conf/server.xml:

----------------------------------------------------------------------------------------------------------------------
<Connector port="8080" protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="8443"

proxyName="www.empre.com"

proxyPort="443"

scheme="https"

maxThreads="200"

acceptCount="100"

enableLookups="false"

compression="on"

compressionMinSize="1024"

noCompressionUserAgents="gozilla, traviata"

compressibleMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json"

/>


<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"

maxThreads="150"

SSLEnabled="true"

scheme="https"

secure="true"

compression="on"

compressionMinSize="1024"

noCompressionUserAgents="gozilla, traviata"

compressibleMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json"

>

<SSLHostConfig>

<Certificate certificateFile="/etc/letsencrypt/live/www.emprenex.com/fullchain.pem"

certificateKeyFile="/etc/letsencrypt/live/www.emprenex.com/privkey.pem"

certificateChainFile="/etc/letsencrypt/live/www.emprenex.com/chain.pem"

type="RSA" />

</SSLHostConfig>

</Connector>


Ahora debemos iniciar el servidor nginx

$ sudo service nginx start

e iniciamos el servidor sshd para que podamos editar las carpetas de las paginas del sitio

$ sudo service restart sshd

Iniciamos tomcat para que tonme los cambios en server.xml

$ sudo service tomcart restart


Para subir i bajar información de las carpetas nginx puede usar algunos de los agentes conocidos de

sftp como con gFTP, cuteFTP, Putty, Sfto de consola , Filezilla entre otros.

Al hacerlo site la información solicitada la cuales:

servidor:18.190.58.28 (para este ejercicio cambiar por la de su servidor)

usuario: empre1

contraseña:empre1 (la asignada durante la creación de /.ssh/autorize_jey

puerto: normalmente el 22 , pero consulte con su proveedor de servicio por donde esta sirviendo su ssh.

NOTA DE SEGURIDAD EN EL SERVIDOR.

Usualmente los usuario desarrolladores de fronend usan Filezilla con su configuración por defecto, dado que es muy conocido para los servidores del tipo wordpress , el problema es que este  agente SFTP (file transfer bajo ssh) usa los protocolos  basados en diffie-hellman y politicas de seguridad basadas en ssh-rsa,ssh-dss  que comprometen la seguridad del  sistema , creando vulnerabilidades y bajo rendimiento del sistema.

Aquí dejo un archivo /etc/ssh/sshd-config funcional para poder usar Filezilla en servidores con protecciones que no implementan estos protocolos y alguna configuraciones básicas que habilitan a Filezilla en servidores de alta seguridad.

Se recomienda enormemente cambiar/configurar a  Filezila a otros protocolos como Curve , +ssh-rsa,ssh-dsspor entre otros que son  mas eficientes y ofrece  mayor seguridad, si es posible en sus usuarios antes de pensar en relajar sus sistema.

En este archivo las entradas para institucional, empre0,empre1,empre2 hace referencia a la configuración hipotética de usuarios que despliegan sus desarrollos en el servidor por ejemplo apache o nginx, cambie su directorio del contenedor/usr/share/nginx según su conveniencia

$ sudo emacs /etc/ssh/sshd-config

------------------------------------------------------------------------------------------------------------

#       $OpenBSD: sshd_config,v 1.104 2024/07/20 13:16:21 dtucker Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

HostKeyAlgorithms +ssh-rsa,ssh-dss
PubkeyAcceptedKeyTypes +ssh-rsa,ssh-dss

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha\
1,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256

PubkeyAuthentication yes


AuthorizedKeysFile      .ssh/authorized_keys

#AuthorizedPrincipalsFile none

PasswordAuthentication yes
PermitEmptyPasswords no

Subsystem       sftp    /usr/libexec/openssh/sftp-server

HostkeyAlgorithms +ssh-dss
PubkeyAcceptedKeyTypes +ssh-dss

AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys %u %f
AuthorizedKeysCommandUser ec2-instance-connect
Ciphers aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc

Match User institucional
    ChrootDirectory /usr/share/nginx/institucional
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Match User empre0
    ChrootDirectory /usr/share/nginx/empre0
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no


Match User empre1
    ChrootDirectory /usr/share/nginx/empre1
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Match User empre2
    ChrootDirectory /usr/share/nginx/empre2
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

-------------------------------------------------------------------------------------------------------------------
Es necesario hacer un par de paso de configuracion para garantizaar que esta configuración funcione
ya que usa contraseñas externas a los servidores es necesario configurarlas  adecuadamente.

1. Verifique que los siguientes archivos existen , sino crearlos.

$ ls -l /etc/ssh/ssh_host_rsa_key
$ ls -l /etc/ssh/ssh_host_dsa_key

*Nota verifique si en el cliente local existe el archivo /ssh./host-knows con acceso para el servidor,
si lo tiene , eliminar la entrada asignada al servidor que se pretende tener acceso, para evitar que se bloquee el acceso al servidor desde esa terminal.

Crear las claves necesarias para permitir acceso a Filezilla.

$ sudo ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
$ sudo ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''

dar los permisos necesarios a estas claves.

$ sudo chmod 600 /etc/ssh/ssh_host_rsa_key
$ sudo chmod 600 /etc/ssh/ssh_host_dsa_key
$ sudo chown root:root /etc/ssh/ssh_host_rsa_key
$ sudo chown root:root /etc/ssh/ssh_host_dsa_key

iniciar el servidor sshd de seguridad.

sudo service sshd restart

verificar el estado del sertvicio

$ sudo service sshd status

Use esta información con precaución, no se recomienda para servidores de producción.

Se recomienda leer el siguiente texto y buscar mas información de sus sistemas antes de
hacer cualquier cambio en el servidor.

Las prácticas de seguridad y las políticas de criptografía evolucionan con el tiempo para adaptarse a nuevas amenazas y vulnerabilidades descubiertas. Aquí tienes una explicación de por qué algunos protocolos y políticas, como Diffie-Hellman y las claves basadas en ssh-rsa y ssh-dss, pueden no ser recomendados o soportados en los servidores de seguridad modernos:

1. Diffie-Hellman (DH)

Debilidades:

  • Tamaño de clave fijo: Algunos parámetros DH, especialmente aquellos con tamaños de clave pequeños, son vulnerables a ataques de fuerza bruta.
  • Intercambio de claves sin autenticación: El protocolo DH por sí mismo no autentica las partes comunicantes, lo que lo hace susceptible a ataques man-in-the-middle (MitM) si no se combina con otros mecanismos de autenticación.

Alternativas modernas:

  • Elliptic-Curve Diffie-Hellman (ECDH): Proporciona mayor seguridad con tamaños de clave más pequeños y es más eficiente en términos de procesamiento.

2. SSH-RSA

Debilidades:

  • Debilidad en SHA-1: La firma ssh-rsa usa el algoritmo de hash SHA-1, que ha demostrado ser vulnerable a ataques de colisión.
  • Preferencia por algoritmos más seguros: Los algoritmos modernos como rsa-sha2-256 y rsa-sha2-512 usan SHA-2, que es más seguro que SHA-1.

Alternativas modernas:

  • ED25519: Un algoritmo de clave pública basado en curvas elípticas que es más seguro y eficiente.
  • RSA con SHA-2: Utilizar rsa-sha2-256 o rsa-sha2-512 para firmas RSA en lugar de ssh-rsa.

3. SSH-DSS (DSA)

Debilidades:

  • Tamaño de clave fijo y pequeño: DSA tradicionalmente usa un tamaño de clave fijo de 1024 bits, que no es considerado seguro hoy en día.
  • Requerimientos específicos: DSA tiene requisitos específicos sobre el tamaño de la clave y otros parámetros, lo que limita su flexibilidad y seguridad.

Alternativas modernas:

  • ED25519: Proporciona seguridad mejorada con claves más pequeñas.
  • RSA y ECDSA: Ofrecen mayor seguridad y flexibilidad con tamaños de clave más grandes y algoritmos modernos.

Recomendaciones

Para mantener altos niveles de seguridad en servidores SSH y otros sistemas criptográficos, se recomienda:

  1. Actualizar algoritmos y claves:

    • Utilizar claves RSA de al menos 2048 bits, preferentemente 3072 o 4096 bits.
    • Emplear algoritmos modernos como ED25519 y ECDSA.

  2. Políticas de seguridad actualizadas:

    • Deshabilitar algoritmos antiguos y débiles como ssh-dss y ssh-rsa.
    • Implementar políticas que requieran el uso de algoritmos seguros y tamaños de clave adecuados.

  3. Mantener el software actualizado:

    • Asegurarse de que tanto el software del servidor como el cliente SSH estén actualizados para soportar las últimas prácticas y recomendaciones de seguridad.

Implementar estas prácticas ayuda a proteger la comunicación y los datos contra las amenazas más recientes y conocidas.

















Comentarios

Publicar un comentario

Entradas populares