Hardening Sistema Linux (CentOS) #Parte3
Continuando con la plantilla de aseguramiento de Servidores con sistema CentOS
Leer las: #Parte1 #Parte2
8 Hardening de Nginx
}
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
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
Read more
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,
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
Entradas
.jpg)
