Seguridad | Blogofsysadmins.com

25/03/2024

Borrar una linea en el fichero known_hosts

Si has reinstalado el sistema operativo en un servidor, o le has cambiado la ip, seguramente cuando vuelvas a intentar acceder a la máquina por ssh te impedirá el acceso y recibiras un mensaje como este:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
b1:3b:85:a5:b3:ab:37:a9:6d:3e:98:7a:d5:9d:78:15.
Please contact your system administrator.
Add correct host key in /home/ghosti/.ssh/known_hosts to get rid of this message.
Offending key in /home/ghosti/.ssh/known_hosts:240
RSA host key for 29.23.11.34 has changed and you have requested strict checking.
Host key verification failed.

La solución es eliminar la linea número 240 del fichero known_hosts, puedes hacerlo con un editor de texto, pero es mas cómodo teclear lo siguiente:

ssh-keygen -R hostname|ip

Si no has tocado nada, ten cuidado, puede que alguien este intentando acceder a tu servidor con técnicas man in the middle.

20/03/2024

Crear un proxy Socks usando un tunel ssh

Si tienes una cuenta ssh en algún ordenador de internet la puedes utilizar como proxy para navegar desde ese ordenador remoto. En esencia un proxy es un ordenador que utilizas como puente para acceder a Internet a través de él. Esto puede ser útil para muchas situaciones. Por ejemplo:

Tienes que conectarte a una página a la que no puedes acceder desde tu red por estar «prohibida».
Quieres conectar a una página pero no quieres que sepan de entrada desde que ordenador estás consultando. Aclaración: siempre, repito, siempre se puede averiguar desde dónde se ha consultado una página, es una cuestión de tiempo y recursos (como los que tiene la policía)
Estas configurando un servidor de páginas web en tu red local y quieres comprobar si funciona desde Internet. Puedes llamar a un amigo para que se conecte o puedes hacerlo tú desde el proxy.

Basta con tener un cliente de ssh instalado y una cuenta en internet. En mi caso tengo una cuenta en el servidor de Hostmonster que permite acceso de ssh. Si no tienes ninguna cuenta y no quieres alquilarla hay muchos sitios en internet que te ofrecen cuentas shell gratuítas con servicios limitados.

Lo primero que haremos será usar el cliente de ssh para crear la conexión y abrir el proxy. En linux lo puedes hacer con el siguiente comando:

ssh -D 9999 usuario@direccion_servidor_ssh

Tras esto y una vez introducida la contraseña ya tendremos preparada la conexión y el puente SOCKS en el puerto 9999 de nuestro ordenador. Por supuesto se puede cambiar el número de puerto y los valores «usuario» y «direccion_servidor_ssh» correponderán con los de nuestra cuenta ssh.

La segunda parte es configurar el navegador web (o cualquier otro programa que queramos usar) para que use el puente SOCKS. En el ejemplo utilizaré el navegador Firefox. Vamos al menú «Editar->Preferencias» y en la ventana que se abre seleccionamos «Avanzado» y la pestaña «Red».

Una vez aquí pinchamos en «Configuración» y introducimos los datos como sigue cambiando el número de puerto 9999 si hemos seleccionado otro al crear el túnel.

Si hemos realizado los pasos correctamente nos conectamos a cualquier página para comprobar si funciona. Será algo más lenta que la navegación directa pero hay veces que no hay otra solución que utilizar este método.

16/03/2024

Ejemplos de reglas para IPtables

Aqui os dejo unos ejemplos de configuración de reglas para IPtables, encontraréis más en la siguiente web:

http://danieldegraaf.afraid.org/info/iptables/examples

Accept-all policy (Aceptar todo)

#!/usr/bin/env iptables-restore
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

Minima:

#!/usr/bin/env iptables-restore
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
COMMIT

Aceptar SSH para un solo host:

#!/usr/bin/env iptables-restore
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 1.8.9.7 -p tcp --dport 22 -j ACCEPT
COMMIT

Muchas más en el enlace mencionado anteriormente.

iptables example rulesets

08/03/2024

Evitar ataques DoS a apache con mod_evasive

El ataque DoS (Denegación de Servicio / Denial of Service) o DDoS (Distributed Denial of Service, denegación de servicio distribuida), es un ataque a un sistema de servidores o red que causa que un servicio o recurso sea inaccesible a usuarios legítimos. El flujo masivo de peticiones (a través del protocolo TCP/IP) al servidor y los ataques de fuerza bruta provocan el colapso de la red, o la saturación del servidor en cuestión.

En esta entrada vamos a tratar de paliar los ataques DoS centrados en el servicio Apache, que consiste básicamente en lanzar peticiones al servidor web de forma masiva hasta colapsar el mismo. Gracias al módulo de apache mod_evasive conseguiremos redirigir el tráfico de esta peticiones ilegítimas hacia un error 403 (prohibido).

La última versión estable de mod_evasive puede descargarse en este enlace.
Compilación:

cd /root/descargas
wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz
tar -zxf mod_evasive_1.10.1.tar.gz
cd mod_evasive

Si usamos apache1, deberemos compilar su módulo correspondiente (adecuad la siguiente línea a vuestra ruta de apache):

/usr/local/apache/bin/apxs -cia mod_evasive.c

Si usamos apache2, deberemos compilar su módulo correspondiente:

/usr/local/apache/bin/apxs -cia mod_evasive20.c

Veremos que tras la compilación, automáticamente ya carga el módulo en nuestro httpd.conf:

LoadModule evasive_module libexec/mod_evasive.so

Configuración:

El fichero de configuración (muestro los valores por defecto) lo cargaremos en un fichero aparte y lo llamaremos desde el httpd.conf (podéis cargar las opciones directamente en el httpd.conf, yo lo pongo separado para una mejor estructuración) :

Include «/usr/local/apache/conf/mod_evasive.conf»

Y el fichero que incluye las configuraciones del módulo:

DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSEmailNotify correo@dominio.com
DosWhitelist 98.54.48.14 # Ip ficticia

Vamos a explicar un poco lo que es cada opción:

Podemos ver lo que es cada cosa en:

DOSHashTableSize

Cuanto más grande sea el tamaño de la tabla de Hash, más memoria requerirá, pero el rastreo de Ips será más rápido. Es útil aumentar su tamaño si nuestro servidor recibe una gran cantidad de peticiones, pero así mismo la memoria del servidor deberá ser también mayor.

DOSPageCount

Número de peticiones a una misma página para que una IP sea añadida a la lista de bloqueo, dentro del intervalo de bloqueo en segundos especificado en el parámetro DOSPageInterval

DOSSiteCount

Igual que ‘DOSPageCount’, pero corresponde al número de peticiones al sitio en general, usa el intervalo de segundos especificado en ‘DOSSiteInterval’.

DOSPageInterval
Intervalo en segundos para el parámetro umbral de DOSPageCount.

DOSSiteInterval
Intervalo en segundos para el parámetro umbral DOSSiteCount.

DOSBlockingPeriod
Periodo de bloqueo para una IP si se supera alguno de los umbrales anteriores.El usuario recibirá un error403 (Forbidden) cuando sea bloqueado, si el atacante lo sigue intentando, este contador se reseteará automáticamente, haciendo que siga más tiempo bloqueada la IP.

DOSEmailNotify
Dirección de correo electrónico que recibirá información sobre los ataques.

DosWhitelist
Podemos especificar una IP o rango que será excluido del rastreo por mod_evasive.

Si alguna de estas opciones no os han quedado claras, indicadmelo y trataré de explicarlo de otra forma. Es fácil comprenderlo en inglés, pero su traducción se hace complicada.

Finalmente reiniciamos apache y ejecutamos el script en perl de testeo (test.pl) que viene incluido en el .tar.gz . Si todo ha ido bien, veremos que al cabo de unas cuantas peticiones, bloqueará el acceso al servicio web:

HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

Con esto ya tendríamos un protector de ataques DDoS a apache funcionando. No obstante, os puede ser de utilidad el siguiente comando, que nos indicará el nº de peticiones al puerto 80 por cada IP en el momento que lo ejecutemos:

netstat -plan|grep :80 | awk {‘print $5’}|cut -d: -f 1|sort|uniq -c|sort -n

Si solo queremos ver las establecidas:

netstat -plan|grep :80 | grep ESTABLISHED | awk {‘print $5’}|cut -d: -f 1|sort|uniq -c|sort -n

Esto es muy útil, pues a partir de dichos comandos, podemos averiguar rápidamente si una o varias IPs están haciendo un exceso de peticiones al servicio apache (fuerza bruta), y directamente filtrar la IP que queramos en nuestro firewall, por ejemplo en APF:

/usr/local/sbin/apf -d

De este modo, junto a la instalación de APF y BFD, nuestro servidor será menos vulnerable a ataques.

07/03/2024

Como instalar y configurar BFD (Brute Force Detector)

BFD (Brute Force Detection), es un script en shell que parsea los logs de los diferentes servicios (ssh, ftp, apache, exim…) y chequea en busca de fallos repetitivos de autenticación, exceso de conexiones desde determinadas IPs, etc.

Combinado con APF (click aquí para acceder a una guía de instalación y configuración) forman un sistema de protección realmente bueno para nuestro sistema, ya que BFD le indicará a APF que IPs debe bloquear para que su acceso al servidor sea denegado (lo explicamos ahora):

Instalación de BFD:

La instalación es extremadamente sencilla:

cd /root/descargas
wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz
tar -xvzf bfd-current.tar.gz
cd bfd-0.7
./install.sh

Una vez hecho esto, nos indicará las rutas a ejecutables y ficheros de configuración:

.: BFD installed
Install path: /usr/local/bfd
Config path: /usr/local/bfd/conf.bfd
Executable path: /usr/local/sbin/bfd

Configuración de BFD:

Editamos el fichero de configuración con nuestro editor favorito:

vi /usr/local/bfd/conf.bfd

Activamos las alertas de ataque (cambiamos de 0 a 1), y configuramos que nos envíe un email por cada una:

ALERT_USR=»1″
EMAIL_USR=»tucuenta@tudominio.com»

Para evitar que el sitema bloquee nuestra IP local, la añadimos al fichero que guarda las IPs a ignorar en el rastreo, añadiremos p.ej. 192.168.1.1 en:

vi /usr/local/bfd/ignore.hosts

Ejecutamos el programa:

/usr/local/sbin/bfd -s

BFD chequeará los logs cada X tiempo, el que le indiquemos en su cron, por defecto cada 10 minutos:

[root@localhost ~]# cat /etc/cron.d/bfd
MAILTO=
SHELL=/bin/sh
#*/5 * * * * root /usr/local/sbin/bfd -q

Una vez comprendido esto, podéis personalizar las reglas que vienen por defecto para cada servicio, se encuentra en la siguiente ubicación:

/usr/local/bfd/rules

Con lo que más podéis jugar es con el valor “TRIG”, que indica el nº de conexiones o intentos permitidos para cada servicio, configuradlo en función de las necesidades de cada servicio:

TRIG=»45″

Con un poco más de paciencia, y estudiando cada regla puede personalizarse completamente, no obstante la seguridad de nuestro servidor, teniendo BFD + APF ha mejorado notablemente.

Fuente: rm-rf.es